This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This draft sets out to provide a definition of end-to-end encryption for
secure communication systems.  That is indeed a worthy goal, but the
fundamental problem that causes this review to report the draft as
"Not Ready" is that Section 2 strays far and wide from that focused goal,
and gets things seriously confused in doing so.  That alone is sufficient
to render this draft not ready for publication.

The problems in Section 2 include:

- At various points in Section 2, an "end point" is defined as (a) an end
  user, (b) an identity and (c) the well-understood concept of communication
  end point in a communication system.  Needless to say, those are three
  distinct concepts, so implying that they are one and the same is seriously
  confusing, and not helpful to the reader.  Only the latter (c) should be
  used.   An identity (b) is a property of an end point, and the attempt (a)
  to use RFC 8890 to conflate the concepts of end user and communication end
  point does not hold water.  RFC 8890 does support including the end users
  as elements in the design and analysis of any communication system, but
  that RFC does not declare end users to be end points - in fact the term
  "end point" is nowhere to be found in RFC 8890.

- Starting in Section 2.1, there is text that appears to redefine the concept
  of end points in the end-to-end principle and even redefined the end-to-end
  principle itself as stated in RFC 3724.  While this was almost certainly 
  not the authors' intent, that text is not acceptable.

- The discussion of sub-identities is towards the end of Section 2.2 is just
  plain wrong, e.g., as the discussion applies to none of the three examples.
  The problem is not an exposed gap between the identity and a sub-identity
  of the end user, rather the problem is that the "tunnel" (which is not a
  good term to use in this context, BTW) is not end-to-end between end
  points whose (sub-)identities are identities of the end users involved.
  In each case, problems arise because one of the two endpoints of the
  "tunnel" is not associated with the end user who is at the other end of
  the communication.
 
Having reached the proverbial "three strikes" against Section 2, I'll stop
here.  The only portion of section 2 that is reasonable to publish in its
current form under the IETF's good name is the concise adversarial definition
of end-to-end security in Section 2.4.

Beyond Section 2.4, I would encourage the authors to focus on revising
Section 2.3 to provide a solid functional definition of "end-to-end
encryption" without attempting to (re) define either "end-to-end" or the
associated concept of "end point" outside the context of end-to-end encryption
- the attempts to do exactly that in Sections 2.2 and 2.1 (respectively)
are seriously flawed (see above).  There's plenty to be done here, e.g.,
as the first sentence in Section 2.3, "Encryption is fundamental to the
end-to-end principle." is incorrect as written because the end-to-end
principle encompasses designs of numerous systems that use no encryption
whatsoever.

Finally, Section 3.1's use of the word "Features" is wrong - those are
"Security Properties", and that is the appropriate term to use.