Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks
RFC 7926
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Alvaro Retana (was Discuss) No Objection
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.
(Deborah Brungard; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
This document is terrifically helpful. Thanks for producing it.
(Alexey Melnikov; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
I too was wondering why this is listed as BCP rather than Informational.
(Ben Campbell; former steering group member) No Objection
I too share the confusion over the intended status. (And I agree with Alissa that this seems like an informational)
(Jari Arkko; former steering group member) No Objection
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.
(Joel Jaeggli; former steering group member) No Objection
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.
(Kathleen Moriarty; former steering group member) No Objection
Thanks for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06560.html
(Mirja Kühlewind; former steering group member) No Objection
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.
(Stephen Farrell; former steering group member) No Objection
- 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.)
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection