| I support publication of some document like this one. Suggestions for clarification to this document: 1. (section 2 in general) I think it's vague for this document to claim that it "updates" earlier documents as if it's changing the text of those documents. The reader is left with only a vague impression of what is still in place from those documents and what has changed. I suggest that the language in this draft be changed to first state each new or revised requirement, and then state how this changes recommendations/requirements stated in earlier documents. 2. section 2, page 4 reads: implementation details. Rather, it is intended to ensure that those using RFC1812 as a guideline for IP implementations understand that IP nodes SHOULD NOT support IPv4 only, and that they should use the other informative references in this document as a companion guideline for proper IPv6 implementations. suggest instead: implementation details. Rather, it is intended to ensure that those using RFC1812 as a guideline for IP implementations understand that IP nodes SHOULD support IPv6 in addition to any support provided forIPv4, and that they should use the other informative references in this document as a companion guideline for proper IPv6 implementations. reason: to me "SHOULD NOT support IPv4 only" seems potentially confusing. 3. section 2, page 5 reads: New IP implementations MUST support IPv6. Current IP implementations SHOULD support IPv6. Suggest that this be restated. e.g. "Host and router IP implementations MUST support IPv6; to support only IPv4 is insufficient." 4. also section 2, page 5: IPv6 support MUST be equivalent or better in quality and functionality when compared to IPv4 support in an IP implementation. This statement could be taken too broadly, e.g. as applying to service offerings rather than just host and router implementations. Suggest instead: Support for the IPv6 protocol in hosts and routers MUST be equivalent or better in quality and functionality when compared to IPv4 support in the same products. Even then, this strikes me as problematic. Should an implementation that cannot provide support for every IPv6 feature (perhaps because of inherent differences between IPv4 and IPv6, or because some feature hasn't yet been updated to support IPv6) be expected to remove features from its IPv4 stack so that its IPv6 stack is "equivalent or better"? At the very least, I think the MUST should be a SHOULD. Keith |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf