Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)
RFC 6760

Note: This ballot was opened for revision 10 and is now closed.

Lars Eggert No Objection

(Pasi Eronen; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2008-12-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think the document should be clearer whether these requirements
represent some kind of IETF consensus, or just opinions of the
authors.  I'm guessing it's the latter, but this guess is mostly based
on the I-D file name (which won't be visible once this becomes an RFC).

I agree with Chris that Section 6 should be more realistic about the
security goals: things like determining the authenticity of received
information, or authority to request some information, can't usually
be done with zero configuration.  Even with non-zero configuration, a
security solution that's realistically deployable in e.g. enterprise
environment probably has to be able to leverage existing
authentication and authorization infrastructure (things like Active
Directory, Kerberos, or internal PKIs come to mind). Besides, the
problem solved by DNSSEC (authenticating a hierarchical delegation
structure) is quite different from securing an AppleTalk NBP like
protocol (even if the messages re-use DNS formats).

Section 7 should probably be clearer what actions IANA is expected
to take when this document is approved (I'm guessing it's "none", but
then the text should say "This document has no IANA actions.").
[Holding a discuss for IANA]

(Jari Arkko; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Mark Townsley; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ralph Droms; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Chris Newman; former steering group member) No Objection

No Objection (2008-12-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I found the security considerations weak, albeit tolerable for this sort
of informational document.

Some discussion of the usability/deployability/security tradeoffs
between a zeroconf home network and a fully managed DNSSEC
infrastructure would be informative.  Further, I suspect it's a critical
requirement to replace Appletalk NBP that "no security" be a protocol option since there's no way to get something with the same
ease-of-use/ease-of-deployment profile in a home network.

Right now there are two security options proposed: none or manually
configured DNS unicast w/ DNSSEC.  While I consider the "none" option
very important since that's exactly the security I want to deploy on
my home WLAN when it comes to this protocol (WPA2-AES is good
enough for my home WLAN), there are scenarios where I might want
some sort of middle ground without having to administer a
DNS infrastructure.  For example, "make sure I connect
to the same file service as last time", or "make sure I use ipp/tls
to the printer service and it's the same printer service I used last
time".  Has any sort of leap-of-faith SSH-style keying been
considered within this framework?  Indeed, in a large corporation with
outsourced IT, getting competent DNSSEC management is probably not
feasible so "grassroots" security might be more viable.

(Cullen Jennings; former steering group member) No Objection

No Objection (2008-12-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This needs a ballot.

(Dan Romascanu; former steering group member) No Objection

No Objection (2008-12-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I find the name of the document and of the page headers completely misleading. IMO the name should be 'Requirements for Replacing AppleTalk Name Binding Protocol (NBP)'.

(David Ward; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2010-12-02)
No email
send info
The rewritten security considerations include two points a) had the protocol been developed with security in mind then it would have been done differently b) when a new/modern version is designed the requirement is that it have security measures appropriate to the environment in which it will be used.  Based on the changes, I'm changing to no objection.

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection (2008-12-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 3.15 (Immediate and Ongoing Information Presentation) describes user interface requirements rather than the underlying protocol requirements.  I suggest revising this
section in terms of the protocol requirements.