Skip to main content

Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)


(Deborah Brungard)

No Objection

Alvaro Retana
(Alissa Cooper)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)
(Terry Manderson)


Note: This ballot was opened for revision 05 and is now closed.

Alvaro Retana
No Objection
Alia Atlas Former IESG member
Yes (2016-09-26)
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 ()

Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2016-09-28)
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 ()

Ben Campbell Former IESG member
No Objection
No Objection (2016-09-26)
- 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 ()

Joel Jaeggli Former IESG member
No Objection
No Objection ()

Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-09-28)
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)
This doc obsoletes RFC6723. RFC6723 upadtes RFC6073 but this doc doesn't. Is that correct?
Spencer Dawkins Former IESG member
No Objection
No Objection (2016-09-27)
I agree with Alexey's Discuss on bringing the IANA section forward.
Suresh Krishnan Former IESG member
No Objection
No Objection ()

Terry Manderson Former IESG member
No Objection
No Objection ()

Stephen Farrell Former IESG member
Abstain (2016-09-28)
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

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.