I agree with Bob. Also, the world is a bit different than in 1989 and 1995. There are a lot of organizations creating different IPv6 'profiles', 'certifications' and guidelines. I think it has always been our intention to use the Node Requirements to provide some guidelines from the IETF point of view. We can review some of your specific comments, though.
-----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of ext Bob Hinden Sent: Thursday, May 05, 2011 10:31 AM To: Ole Troan Cc: 6man Mailing List; Brian Haberman; Bob Hinden Subject: Re: Short 6MAN WG Last Call: <draft-ietf-6man-node-req-bis-09.txt> Ole, On May 5, 2011, at 6:49 AM, Ole Troan wrote: > I'm on the fence with regards to this document. if this document is > meant to be the RFC1122/1812 document for IPv6, I think we are too early in > the deployment of IPv6 to have gathered enough experience with what works and > what doesn't. > as a profile of an IPv6 node though, it isn't too far off. This is, of course, and update the the current Node Requirements as define in RFC4294. Weither it is the last update, is anyones guess, but I think it clearly better to update it now as we know there are many things that are wrong with RFC4294. I would also note that RFC1122 was written in 1989 and RFC1812 in 1995. Neither of those reflect current practice with IPv4. We might be at the same point of deployment with IPv6 as IPv4 was in 1989 :-) Bob > > a couple of comments: > > * section 5.3. Default Router Preferences and More-Specific Routes - > RFC 4191 this is a "MAY wish" and in conflict with RFC6204, L-3. > please make this a SHOULD or even a MUST (as hosts not supporting it > will not be able to interoperate on networks behind > RFC6204 routers. > > * RFC2675: I would just remove that. > > * 5.9.4 Default Address Selection > As RFC3484 generates IPv6 brokenness. I think we should change this > reference to RFC3484bis. > > * 5.9.5. Stateful Address Autoconfiguration I still disagree with > the MAY for DHCP. I don't think we should state the 'at the present time > SLAAC'. > hosts that cannot do DHCP for address assignment may not be able to > connect to many cable networks (see DOCSIS 3) and access networks specified > by the BBF. > > * 6 DHCP vs. Router Advertisement Options for Host Configuration I > don't understand the purpose of this section. > it should include text explaining how to handle conflicts between multiple > mechanisms if anything. > and make it clear that every node has to implement all mechanisms. > that's the natural consequence of designing multiple ways of doing the same > thing. > > * 8.1. Transition Mechanisms > Just remove the section. it doesn't add value. > > * 12.1.1 Router Alert > not just acknowledge that the HBH option was a bad idea and nuke it? > > cheers, > Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
