Subject: [Gen-art] Gen-art Telechat review: draft-ietf-pce-vendor-constraints-11

From: Robert Sparks <[email-masked]>
Date: Fri, 13 Dec 2013 13:42:37 -0600

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.
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-masked]>
> To: 	[email-masked], [email-masked]
>
>
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Robert Sparks <[email-masked]>
Date: Fri, 13 Dec 2013 16:21:15 -0600

> 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.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 17 Dec 2013 05:35:24 -0500

Thanks for your review, Robert!

I have balloted no-objection for this draft on the upcoming IESG telechat.

#begin non-blocking-comment

For what it is worth, I agree with Robert's comment that some highlighting of the interoperability challenges of vendor-specific options might have been useful. I don't think it is a big problem in this case (and this seems to be confirmed by Adrian's reply) but some similar RFCs have talked about it. If you want to take a look at what has been done in the past, there's text in RFC 5094 Section 1 last two paragraphs, RFC 4243 Section 3 last paragraph, RFC 3588 Section 11.1.1 two last sentences, for instance. The general thrust is emphasising the local applicability of vendor information, encouraging documentation of vendor's information elements, and recommending standardisation when there's more general interest for the information in question.

Jari