Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks
RFC 7926

Note: This ballot was opened for revision 06 and is now closed.

Deborah Brungard Yes

(Spencer Dawkins) Yes

Comment (2016-05-17 for -06)
No email
send info
This document is terrifically helpful. Thanks for producing it.

(Jari Arkko) No Objection

Comment (2016-05-18 for -06)
No email
send info
I believe this document would greatly benefit from clarifying the role of describing the "abstracting" from existing solutions, as discussed in Brian Carpenter's Gen-ART review thread. This will help explain why the document is a BCP rather than Inf.

(Alia Atlas) No Objection

(Ben Campbell) No Objection

Comment (2016-05-18 for -06)
No email
send info
I too share the confusion over the intended status. (And I agree with Alissa that this seems like an informational)

Alissa Cooper No Objection

Comment (2016-05-18 for -06)
No email
send info
I too was wondering why this is listed as BCP rather than Informational.

(Stephen Farrell) No Objection

Comment (2016-05-19 for -06)
No email
send info
- The security considerations says to use IPsec or TCP-AO.  To
what extent do we think that this could help with implementation
and deployment of TCP-AO? If it can, great. If it wouldn't, then I'm
not sure there's much point in mentioning TCP-AO given what I
understand it the current state of play there. 

- IPsec can clearly be used, but I wondered if there's really no
place for using TLS between the domains here? That might need a
bit of work, (e.g. to allocate ports or define a STARTTLS
equivalent), but perhaps there's the opportunity here to get that
kind of thing done? That's maybe less of a question for this 
document, but more for the WG in general. (Though if (D)TLS
made sense as part of this, saying so here would be good
probably.)

- I note that the IPR declaration refers to a "standard." As of
now, this document is aiming for BCP, so I've no idea how to
interpret the text in the declaration unless this reverts to PS.
(That said: I don't care much about what kind of RFC results
here, but I agree with the authors that just picking wihtout
requiring text changes for process reasons is right.)

(Joel Jaeggli) No Objection

Comment (2016-05-18 for -06)
No email
send info
watching the outcome of the state discussion, but I won't belabor the point. I think a clear case can be made of state other than informational on the basis that this is providing guidance to the rest of the teas effort.

(Suresh Krishnan) No Objection

(Mirja K├╝hlewind) No Objection

Comment (2016-05-18 for -06)
No email
send info
I fully support Alvaro's Discuss and I was just in the process of deciding if I want to raise a Discuss or not when his ballot position came in.

Even though this document is well written and provides a lot of interesting information, to be honest, I could not find any recommendation on a best current pratice as this document mainly takes about requirements for future work. For me this document provides a problem statement, use cases, and requirements as well as some survery about the applicability of existing protocols and therefore should be an Informational document.

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-05-16 for -06)
No email
send info

Alvaro Retana (was Discuss) No Objection

Comment (2016-05-19 for -06)
No email
send info
I'm clearing my DISCUSS because it achieved the objective: to get the IESG talking about the Intended State of this document.  I don't think we clearly reached consensus, but I'm sure the responsible AD will make the appropriate decision based on the input.