George, Wes
2014-07-28 13:28:53 UTC
Based on the discussion that we had during the meeting, and another quick pass I made through the gap-analysis document with an eye toward how to proceed (WGLC or more revisions), I have some comments that can hopefully be incorporated into the next revision to update the expiration date.
These comments are made as an individual, not as a chair:
Right now, I feel that the gap analysis is a bit thin. While it does discuss several issues specifically associated with disabling IPv4 on hosts and in local networks, there is little discussion of any additional gaps, especially in the larger WAN or datacenter space. We need to try to identify things that are missing from a functional parity perspective between IPv4 and IPv6 that today prevents IPv6-only operation due to implementations or due to protocol.
I expect that an IETF document will focus on protocol issues rather than implementation issues, and a gap analysis will always miss something, because otherwise it will never be done. However, I'm not comfortable putting this forward as a definitive discussion of all of the gaps that we know about right now.
Section 2 has a very brief reference to the initial IPv6 gap analysis that was done by IETF 10 (!) years ago, but as suggested in the meeting, I think that simply referencing the documents with no further comment or summary is not helpful since the documents are so broad in scope, and no casual reader is going to review those in detail before proceeding with this document. I think that it makes sense to expand this into a discussion of follow-on work, probably incorporating most of section 3 of draft-george-ipv6-support, and serving as a conclusion to the document. Basically, "here are the things that we know are gaps, but here is a bunch of additional work that needs to be completed before we can really identify all of the gaps that may be outstanding." I think it's perfectly acceptable to acknowledge the work but make it clear that the Sunset4 WG does not have the resources to undertake what is actually necessary to get to a complete gap analysis.
Given the conflict of interest between my role as WG chair and my role as co-author of draft-george, I defer to Marc to call consensus on my suggested integration of the section of draft-george into this draft.
If there is no consensus to integrate the draft section, I think that at a minimum the authors of gap-analysis need to add add a pointer and brief summary to draft-ietf-mpls-ipv6-only-gap, as it is a companion draft to this one dealing with IPv6-only operation of MPLS networks.
It may also be appropriate to add a pointer/discussion of draft-fan-sunset4-router-id, since this is another IPv4 sunset gap that is being discussed in an external draft.
Thanks,
Wes
Anything below this line has been added by my companyâs mail server, I have no control over it.
-----------
________________________________
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.
These comments are made as an individual, not as a chair:
Right now, I feel that the gap analysis is a bit thin. While it does discuss several issues specifically associated with disabling IPv4 on hosts and in local networks, there is little discussion of any additional gaps, especially in the larger WAN or datacenter space. We need to try to identify things that are missing from a functional parity perspective between IPv4 and IPv6 that today prevents IPv6-only operation due to implementations or due to protocol.
I expect that an IETF document will focus on protocol issues rather than implementation issues, and a gap analysis will always miss something, because otherwise it will never be done. However, I'm not comfortable putting this forward as a definitive discussion of all of the gaps that we know about right now.
Section 2 has a very brief reference to the initial IPv6 gap analysis that was done by IETF 10 (!) years ago, but as suggested in the meeting, I think that simply referencing the documents with no further comment or summary is not helpful since the documents are so broad in scope, and no casual reader is going to review those in detail before proceeding with this document. I think that it makes sense to expand this into a discussion of follow-on work, probably incorporating most of section 3 of draft-george-ipv6-support, and serving as a conclusion to the document. Basically, "here are the things that we know are gaps, but here is a bunch of additional work that needs to be completed before we can really identify all of the gaps that may be outstanding." I think it's perfectly acceptable to acknowledge the work but make it clear that the Sunset4 WG does not have the resources to undertake what is actually necessary to get to a complete gap analysis.
Given the conflict of interest between my role as WG chair and my role as co-author of draft-george, I defer to Marc to call consensus on my suggested integration of the section of draft-george into this draft.
If there is no consensus to integrate the draft section, I think that at a minimum the authors of gap-analysis need to add add a pointer and brief summary to draft-ietf-mpls-ipv6-only-gap, as it is a companion draft to this one dealing with IPv6-only operation of MPLS networks.
It may also be appropriate to add a pointer/discussion of draft-fan-sunset4-router-id, since this is another IPv4 sunset gap that is being discussed in an external draft.
Thanks,
Wes
Anything below this line has been added by my companyâs mail server, I have no control over it.
-----------
________________________________
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.