Going back to this... Jari Arkko <jari.ar...@piuha.net> writes:
> I have reviewed this draft. In general, this version is well written, > I agree with the recommendations, and I'd like to thank everyone for > working on this much needed update. I think the document is ready to > go to IETF Last Call -- some minor issues below that I think could be > addressed even during the last call. > However, since I was part of the original design team that worked RFC > 4294, I have asked Ralph to formally handle this document. He has > promised to do so. (Thanks!) > > My comments: > > > Consequently, IPv6 Jumbograms [RFC2675 > <http://tools.ietf.org/html/rfc2675>] remain optional at this > time. > > Other sections use RFC 2119 keywords (MAY) to state this. Consider > using that style here as well. I'd rather not make this change. I think MAY sounds stilted. In addtion, the defintion of MAY is "optional": 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) > Static address may be supported as well. > > "Static addresses may be ..." or "Configuration of static address(es) > may be ..." might be a better formulation. Agreed. > For general purpose devices, RFC 4429 is not considered to be > necessary at this time. > > Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more > the norm than exception today. At the very least, I'd again use the > MAY keyword for this specification. The above sounds almost like > recommending to not implement it. Changed last sentence to: For general purpose devices, RFC 4429 remains optional at this time. > Consequently, DNS configuration > information can now be learned either through DHCP or through RAs. > Hosts will need to decide which mechanism (or whether both) should be > implemented. > > I would make a forward reference here and add: "Specific guidance > regarding DNS server discovery is discussed in Section 7." This is > because for that specific issue we do have something stronger to say > than the above text . Done. > (And based on my own experience of running non-IPv4 networks that > desperately need DNS discovery, somewhere in Section 7 I think you > should require that routers with attached hosts actually support both > (stateless) DHCP and RA-based DNS discovery.) New text: 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 Because a single DHCP server can support devices on multiple links, it is not necessary that every router support DHCPv6 directly. However, in order to support DHCPv6 servers on other links, routers SHOULD support relay agent functionality of DHCPv6 [RFC3315]. Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6 server functionality as well. I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't think every router needs to support DHCP, hence the MAY. But SHOULD is also not a MUST, so I'd be OK with SHOULD. Indeed, where one arguably should have a MUST is in relay agent functionality. SHould I elevate it? Thoughts? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
