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