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

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

(Alia Atlas) Yes

Comment (2016-09-26)
No email
send info
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 Yes

(Jari Arkko) No Objection

(Ben Campbell) No Objection

Comment (2016-09-26)
No email
send info
- 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.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Comment (2016-09-27)
No email
send info
I agree with Alexey's Discuss on bringing the IANA section forward.

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Comment (2016-09-19)
No email
send info
This doc obsoletes RFC6723. RFC6723 upadtes RFC6073 but this doc doesn't. Is that correct?

(Terry Manderson) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2016-09-28)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2016-09-28)
No email
send info
I share Stephen's concerns on the use of MD5 and would like to see a deprecation process begin.

Alvaro Retana No Objection

(Stephen Farrell) Abstain

Comment (2016-09-28)
No email
send info
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.