Subject: [Teas] Stephen Farrell's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 15 Jun 2016 16:04:43 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-teas-rsvp-te-srlg-collect-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-teas-rsvp-te-srlg-collect/

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

"It is recommended that domain/layer boundary policies
take the implications of releasing SRLG information into
consideration and behave accordingly during LSP
signaling." Eh, that's a bit opaque for me at least.  Can
you say a bit more about what those implications might be
and how one might take them into account, and why that
doesn't need to be mentioned in the document?  I'm asking
since there is a bit of a breach of the blood-brain
barrier going on here (as is ack'd in the draft) and while
it's hard to envisage that much going wrong if providers
expose this information, I guess there might easily be
something too subtle for this particular reader:-)

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Thu, 16 Jun 2016 00:08:43 +0000

Stephen,

> "It is recommended that domain/layer boundary policies take the
> implications of releasing SRLG information into consideration and behave
> accordingly during LSP signaling." Eh, that's a bit opaque for me at
> least.  Can you say a bit more about what those implications might be and
> how one might take them into account, and why that doesn't need to be
> mentioned in the document?  I'm asking since there is a bit of a breach of
> the blood-brain barrier going on here (as is ack'd in the draft) and while
> it's hard to envisage that much going wrong if providers expose this
> information, I guess there might easily be something too subtle for this
> particular reader:-)

There's no intent here to tell anyone how they ought to run their network. What I was really trying to do when I wrote this was to say, "You should probably think about this before you do it". This is also talked about a bit at the end of section 1. Would it help to re-iterate what's there in this section?

Cheers

Matt