From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
To: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard
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.
__________
WEG] We received similar feedback in the intarea last call, the "Updates..." language in section two is an attempt to do this clarification and is far more specific than the 00 version. It was attempting to note that rather than updating the details of the technical specs, it was pointing out that IP as generic could mean IPv4 or IPv6, but these documents are clearly IPv4 documents. Think of it as equivalent to %s/IP/IPv4/g. Since it appears that this was not completely successful, I'd appreciate more specific feedback or text suggestions to make it better.
2. section 2, page 4 reads:
reason: to me "SHOULD NOT support IPv4 only" seems potentially confusing.
__________
WEG] agree, will fix in next rev.
3. section 2, page 5 reads:
New IP implementations MUST support IPv6.
Current IP implementations SHOULD support IPv6.
In general, it's meaningless to impose a requirement on current implementations of anything.
____________
WEG] This is why it's a SHOULD instead of a MUST. Also, generally this document is saying "the IETF recommends that you support IPv6" so it seems a gap to leave out current implementations. This is also why the last paragraph in section 2 is there - we realize that there are going to be limitations to this and are trying to be pragmatic.
Also, it's not clear what is meant by "new implementations" -
does this mean completely new implementations, or revisions of existing implementations?
____________
WEG] I'm wondering if it actually matters in this context? They both need to support IPv6, which is why both requirements are there. Ultimately, this is going to be open to interpretation by implementers regardless of how it is worded. Since the IETF has no control over what they decide to do, if they choose to interpret their implementation as not new and therefore covered by the SHOULD instead of the MUST, IETF has no recourse if they disagree with that interpretation.
That said, I am certainly open to additional text to clarify what "new implementations" are vs "current implementations" if you believe that it'll be helpful.
Suggest that this be restated. e.g. "Host and router IP implementations MUST support IPv6; to support only IPv4 is insufficient."
____________
WEG] This may be a way to solve. We'll consider in the revision.
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.
_____________
WEG] It was intended to be taken as broadly as possible. It's not necessarily limited to host and router implementations, though that is indeed its primary focus. How is it a bad thing if a service offering interprets this to mean that the IETF recommends that they support IPv6?
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"?
______________
WEG] For what it's worth, I'm aware of several businesses that are using language similar to this in their vendor requirements documents. Basically, making it incumbent on the implementer to ensure that their gear supports features in both IPv4 and IPv6 rather than calling out specific features and thus risking missing some. So, I think the answer to your question is that it's a business decision on the part of the implementer. Some of the very early comments we received on this draft indicated a concern that people would implement the bare minimum IPv6 support and call it a day, making it mostly useless by comparison because it was so limited in functionality. This more generic text was chosen to cover this concern without getting us ratholed into a discussion about whether (for example) NAT is required in IPv6 because it's supported in IPv4 today. The larger discussion about feature parity in IPv4 vs IPv6 is a good bit longer I think, but we'd be willing to discuss it brief
ly in this draft if you think it would be useful. Perhaps:
In this context, IPv4-IPv6
feature parity is the absence of gaps where functionality exists
in IPv4 but has no equivalent in IPv6. Note that this does not
mean a direct 1:1 relationship where every feature that exists in
IPv4 will exist in IPv6. This is because IPv6 eliminates the need
for some features that exist in IPv4, IPv4 supports some features
that are no longer in use, and some existing IPv4 features are
integrated into other parts of IPv6. In addition, as new features
and implementations take advantage of the differences between IPv6
and IPv4, it is expected that IPv6 will surpass IPv4 and feature
parity will begin to swing in the other direction as the decision
is made not to implement certain features and protocols with
specific support for IPv4.
At the very least, I think the MUST should be a SHOULD.
__________
WEG] would any of the above clarification change your mind? I think dropping this to a SHOULD leaves a much larger opening for incomplete IPv6 implementations.
Thanks for the comments,
Wes George
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf