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.

I too share the confusion over the intended status. (And I agree with Alissa that this seems like an informational)

I too was wondering why this is listed as BCP rather than Informational.

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

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.

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.

Thanks for addressing the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06560.html

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.