Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)
RFC 7896

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

Deborah Brungard Yes

Mirja Kühlewind Yes

Comment (2016-04-20 for -06)
No email
send info
Agree with others that all references to the survey should be removed.

(Jari Arkko) No Objection

(Ben Campbell) No Objection

Comment (2016-04-19 for -06)
No email
send info
Add me to the survey bandwagon.

(Benoît Claise) No Objection

Comment (2016-04-20 for -06)
No email
send info
I'm surprised by this comment, from the write-up:

    There were nine responses to the survey, but the majority of these respondents 
    have not commented on the proposed protocol update.

... even if I also see this in the write-up:

    it was clear that the majority of implementations would either be unaffected, 
    or not significantly affected, by the change in semantics and format that are 
    proposed in this draft.

Anyway, I'll trust the working group did the right thing.

Regarding the survey issue, my first reaction was to include (parts of) https://tools.ietf.org/html/draft-dhody-pce-iro-survey-02 in an appendix.
On second thought, I'm with Alvaro: no need to mention the survey. The WHAT is important to document, not HOW you got there.

Alissa Cooper No Objection

Comment (2016-04-19 for -06)
No email
send info
Agree with Alvaro's point about the survey.

(Stephen Farrell) No Objection

Comment (2016-04-19 for -06)
No email
send info
I agree with Alvaro's 1st comment - while the WG list
does give me the impression that this is all good, the
wording of the current draft is very awkward without
the survey being referenced.

(Joel Jaeggli) No Objection

Comment (2016-04-20 for -06)
No email
send info
Qin Wu performed the opsdir review

Suresh Krishnan No Objection

Comment (2016-04-20 for -06)
No email
send info
I also agree with Alvaro's comments.

(Terry Manderson) No Objection

Alexey Melnikov No Objection

(Kathleen Moriarty) No Objection

Comment (2016-04-20 for -06)
No email
send info
I also agree with Alvaro's comment on the survey.

Alvaro Retana No Objection

Comment (2016-04-18 for -06)
No email
send info
1. WG Consensus

The Abstract talks about this document resulting from an "informal survey".  The Shepherd writeup also mentions the survey and how it was "not unanimous".  However, while the survey itself is mentioned in the document (10 times in 6 pages!), there is no reference, and more importantly nothing is mentioned about WG consensus.

What I'm getting to here is the following:  regardless of what the survey says (or not), this document is on the Standards Track so I expect the update to be the result of WG consensus.  If the survey is not even referenced (which is fine with me), then the document should forget about it and simply point at the updates.  In other words, the survey, like discussion on the mailing list, seems to have been used as a tool to reach consensus — no need to repeatedly mention the tool.

I don't think this point raises to the level of a DISCUSS because it should be an editorial change.  Even though the archives don't provide much in terms of discussion around this document (or draft-dhody-pce-iro-survey), I have to assume that it reached this point because there is in fact consensus on the update.


2. Non conforming implementations

Section 3. (Other Considerations).  Given that other interpretations of rfc5440 were possible, I think that the considerations in this section are operational, so renaming may be a good idea.  I would expect that because this is a Standards Track document that people will eventually conform to it, so I think that the "RECOMMEND" at the bottom is not needed.  [I think that's the only rfc2119 key word.]


3. Section 2.1. (Update to RFC 5440): 

a. Where should the new statements be added?  I'm assuming after the first paragraph.

B. "An abstract node could be a simple abstract node…"  Is there a better way to define "abstract node" than by using it in the definition?  Maybe just point to rfc3209.