ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-intarea-ipv6-required-01.txt> (IPv6 Support Required for all IP-capable nodes) to Proposed Standard

2011-08-22 09:00:44
From: Keith Moore <moore(_at_)network-heretics(_dot_)com>
To: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>