Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)
draft-cheshire-dnsext-nbp-10
Discuss
Yes
(Jari Arkko)
(Mark Townsley)
(Ralph Droms)
No Objection
(Adrian Farrel)
(David Ward)
(Gonzalo Camarillo)
(Lars Eggert)
(Lisa Dusseault)
(Magnus Westerlund)
(Peter Saint-Andre)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Stewart Bryant)
(Tim Polk)
Note: This ballot was opened for revision 10 and is now closed.
Pasi Eronen Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2008-12-04)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Ralph Droms Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
(2008-12-02)
Unknown
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 IESG member
No Objection
No Objection
(2008-12-01)
Unknown
This needs a ballot.
Dan Romascanu Former IESG member
No Objection
No Objection
(2008-12-04)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2010-12-02)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-12-02)
Unknown
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.