Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
draft-ietf-pals-rfc4447bis-05
Yes
(Deborah Brungard)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)
(Terry Manderson)
Abstain
Note: This ballot was opened for revision 05 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(2016-09-26)
Unknown
I would prefer to see the IANA section retained and specify the fields in the IANA registry. It is useful to know which registry to find and where the values are defined.
Deborah Brungard Former IESG member
Yes
Yes
()
Unknown
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2016-09-28)
Unknown
I am glad that you are moving this document to Internet Standard. My earlier DISCUSS below: I have a simple issue with the IANA Considerations section which should be easy to address: The IANA section seem to be suggesting that IANA should do full search of its registries to update all references to RFC 4447 to point to rfc4447bis. I don't think it is easy for IANA to do that. This document is obsoleting RFC 4447, which means that there is no need to ever read RFC 4447 in order to implement this document. For that reason, you should copy and paste content of the original RFC 4447's IANA Considerations into this document. After that, add a sentence saying that the only change is updating references to point to this document.
Alissa Cooper Former IESG member
No Objection
No Objection
()
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
()
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2016-09-26)
Unknown
- It would be nice to see a mention that this advances the status to Internet Standard somewhere near the top of the document. Section 10 is sufficient for that, but it sort of buries the lede. (It's too late to matter now, but it would have been helpful to have the status change called out more strongly in the shepherd writeup and last call announcement. ) I would rather strongly like to see the IANA considerations from the obsoleted RFCs to be copied forward, perhaps with a preface that these were originally in 4447, etc. Especially since this draft requests the references point to it, effectively orphaning the 4447 IANA considerations. There are a few odd uses of 2119 keywords, all of which I think existed in the original text: - 7.1: normative REQUIRED the section title - 7.2: Unattached "NOTs" - 9.1 : "there is a perception that security MUST be " seems like a statement of fact.
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-09-28)
Unknown
I share Stephen's concerns on the use of MD5 and would like to see a deprecation process begin.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-09-19)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2016-09-27)
Unknown
I agree with Alexey's Discuss on bringing the IANA section forward.
Suresh Krishnan Former IESG member
No Objection
No Objection
()
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
Abstain
Abstain
(2016-09-28)
Unknown
It is an embarrassment that we can't do better than TCP MD5. TCP MD5 (from 1998, RFC2385) has been obsoleted by TCP-AO (RFC 5925, from 2010), but that hasn't seen deployment. Back in 1998 (18 years ago!) RFC 2385 included an IESG note that says: "This document describes current existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks." And all these years later we can still do no better when promoting a document to IS. Sigh. However, I see no point in trying to block this document on that basis. I would argue for an IESG note along the above lines if I thought that'd have any impact, but I guess it won't if, as seems to be the case, people won't move until there's a catastrophic break.