Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-17
Yes
(Adrian Farrel)
No Objection
(Alissa Cooper)
(Barry Leiba)
(Benoît Claise)
(Jari Arkko)
(Kathleen Moriarty)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
(Stephen Farrell)
(Ted Lemon)
Note: This ballot was opened for revision 15 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -15)
Unknown
Alia Atlas Former IESG member
(was Discuss)
Yes
Yes
(2015-02-12 for -16)
Unknown
Thanks for handling my concerns
Alissa Cooper Former IESG member
No Objection
No Objection
(for -15)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -15)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -15)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2015-02-02 for -15)
Unknown
I agree with Joel's (Tim's) question on why a 5036bis was not created. Strictly from a writing perspective, that approach seems straightforward and would make a single LDP specification. But, this is a non-blocking comment and I will happy as long as this information gets published in some fashion.
Jari Arkko Former IESG member
No Objection
No Objection
(for -15)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-02-02 for -15)
Unknown
From Tim Chown's opsdir review. I would like to discuss the possiblility of appendix coving the changes mad by this document or what seems like a minor effort to make this the wholesale replacement of 5036. this does not rise to the level of a discuss, who knows we may get there. Thanks. From Tim Chown: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: this document is Ready with Issues. This document describes updates to the Label Distribution Protocol as described in RFC 5036 (and GTSM elements in RFC 6720), to clarify and correct the described or implied behaviour in IPv4-only, IPv6-only and dual-stack deployments. Issues: * This draft describes a number of ambiguities in particular in dual-stack behaviour, with at least eight such issues being listed in section 1. When reading this draft, in conjunction with RFC 5036, I personally find it quite tricky to apply the updated rules/guidance described here to the existing text in RFC 5036, due to the rather patchy nature of the document. I would therefore suggest that the authors consider a complete revision to RFC 5036 (as happened from RFC 3036), rather than having the clarifications / corrections ‘dangling’ in this additional text. I appreciate that such a revision may be considered overkill, so at the very least this document should include a clear list of changes / updates, perhaps as an appendix. * The general principles of the dual-stack / IPv4 / IPv6 operation should be stated early in the document - these are conveyed piece by piece as you read through the document, but it would be helpful to have them clearly stated up front. * There is an amount of repetition through the document. I suspect that in the 15 revisions there have been changes made which have caused this. If the document progresses as a standalone document, this should be corrected where possible. As it stands, the document feels disjoint in places, and doesn’t flow anywhere near as well as it could. Nits: * The specification language section (section 2) should be moved earlier in the document, given abbreviations described therein are used prior to their definition. * In 5.1 may wish to mention the IANA registry for IPv6 multicast addresses http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml * Last para of 5.1 - why are IPv6 LDP link Hellos to be transmitted first? It would be useful to state the reason. * There are various places in the draft that talk about address selection, e.g. in 5.1 and in 5.2; I think these are all consistent with RFC 6724, so perhaps that RFC should be used / cited here? * The set of rules in 6.1 repeats some parts of the earlier sections, but not entirely, e.g. the rule in the last para of 5.1 is not included in 6.1. * In 6.1.1, para 2, state here that this inclusion of the new TLV is a MUST; this is currently only stated a further page on. * In 6.1.1 point 3a) this is a little confusing because earlier the document talks about sending both IPv4 and IPv6 Hello messages, and part c) seems to duplicate parts a) and b) ? Tim
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -15)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -15)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -15)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -15)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -15)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -15)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -15)
Unknown