Hi Jon,
I see that WG last call completed in silence. Possibly a function of
people preparing for IETF-98. Maybe just means that everyone thinks
it is obvious to update the RFC and move on.
Anyway, since I'm sitting in a WG meeting where the discussion is a
little too esoteric even for me, here is a quick (but late) review.
Cheers,
Adrian
===
Unfortunate effect of a bis is that the author count has gone OTT.
---
A bit odd to wipe the Acknowledgements of the people who contributed to
RFC 6006.
---
Why has Zafar disappeared from the Authors' Addresses (but remains on
the front page)?
---
Good job picking up the five errata that are on file.
I was a little surprised to see some additional changes that have not
been flagged to the WG nor noted anywhere in the document (e.g., in a
changes section such as Appendix A).
---
I see you added some text to 3.4. I see that this text is to explain
the RBNF that follows, so that is probably OK.
---
I must have missed the discussion of Errata Report 4867. Sorry about
that.
There are three issues, I think
1. Trying to pack all RBNF into the spec as though the RBNF was the
normative definition of the message format. It isn't and was never
intended to be.
Doing this gets infinitely complicated as more objects are added.
Doesn't mean what you have done is wrong, wrt svec-list, just not
necessary.
2. Removal of <BANDWIDTH> from <RRO-List> is wrong, I think.
As I see it:
You can apply <BANDWIDTH> to the whole <RRO-List> by placing it
after the <RRO-List>.
If you want one <RRO> in an <RRO-List> to have a different
<BANDWIDTH> you can include a separate <BANDWIDTH> after the
<RRO>.
I think you have *changed* the specification so that the way this
function is achieved is to pull the <RRO> that has a different
<BANDWIDTH> out into a different <RRO-List>.
That's functional and can be changed if that is what people want
and have discussed, but doing it with an Errata is a mistake because
it was not an error in the document.
3. You also see to think that <BANDWIDTH> cannot be applied to the
<END-POINTS> unless an <RRO-LIST> is present. I think that is
wrong, too. If it makes sense to have <END-POINTS> without an
an <RRO-List> why would you not allow each instance of <END-POINTS>
to have its own <BANDWIDTH>? This also seems to be a change of
substance rather than an error in the document. Again, the WG is
free to make this change, but surely not without discussion.
---
I see you have added some text to 3.5. This also seems to be just
explanation and is probably OK.
---
The fix in 3.12 looks good, but was not flagged to the WG.
From: Pce [mailto:[email protected]] On Behalf Of Jonathan Hardwick
Sent: 10 March 2017 13:55
To: [email protected]
Subject: [Pce] Working group last call for draft-ietf-pce-rfc6006bis-00
Dear PCE working group,
This email starts a working group last call for draft-ietf-pce-rfc6006bis-00.
https://datatracker.ietf.org/doc/draft-ietf-pce-rfc6006bis/
Please read the document and reply to the PCE mailing list whether you believe
this document is ready to be published, or not (including any comments on why
not). The last call will end on Monday 20 March.
Best regards
Jon, JP and Julien
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
