[Pce] Alvaro Retana's No Objection on draft-ietf-pce-iro-update-06: (with COMMENT)

["Alvaro Retana" <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-iro-update-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-iro-update/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.