On 12/13/13 1:42 PM, Robert Sparks wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-pce-vendor-constraints-11
Reviewer: Robert Sparks
Review Date: 13-Dec-2013
IETF LC End Date: 9-Dec-2013
IESG Telechat date: 19-Dec-2013
Summary: Ready
Adrian responded to my LC comments on this version of the draft, but
only copied the authors and the pce wg.
... and that's because he reply-all'ed to the addresses I originally
sent the review to, as the To header below shows.
Totally my fumble that kept his original reply from making it to the
gen-art list. Apologies.
If you're curious, and not already on that wg list, his response is here:
<http://www.ietf.org/mail-archive/web/pce/current/msg03487.html>
-------- Original Message --------
Subject: Gen-art last call review: draft-ietf-pce-vendor-constraints-11
Date: Tue, 26 Nov 2013 14:57:45 -0600
From: Robert Sparks <[email protected]>
To: [email protected], [email protected]
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pce-vendor-constraints-11
Reviewer: Robert Sparks
Review Date: 26 Nov 2013
IETF LC End Date: 9 Dec 2013
IESG Telechat date: not yet scheduled
Summary: Ready (but I have a couple of comments for consideration)
Given a quick scan of the list history for this document, I'm surprised
there's not more discussion about the potential for creating islands of
non-interoperable equipment, and some recommendation for when to define
and how to deploy a standard version of a constraint when a common thing
is found among vendor specific variants of the constraint (are there
implications if an element include both the standard and vendor specific
variants?)
This is probably bigger than this document, and take it for what it's
worth, but the practice of relisting the definition of <svec-list> when
you add objects doesn't seem to be working well. For instance, had XRO
or GC been defined later, you're probably ok with them being used with
these objects too, right? As it is, I'm having a hard time seeing the
value in redefining the grammar this way each time you add a new thing.
It leads to odd artifacts like _this_ document not providing a good
reference to what XRO and GC are (you have to chase through the
registry, or look at 5557 or 5521, neither of which are referenced here.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
