Re: [tcpinc] AD review of tcp-eno

> On a related note, I think there might be an inconsistency in the draft
> that I would appreciate some input in resolving.  Section 7.1 says:
> 
>         TLS can currently only be added to legacy applications whose
>         protocols accommodate a STARTTLS command or equivalent.
>         TCP-ENO, because it provides out-of-band signaling, opens the
>         possibility of future TLS revisions being generically applicable
>         to any TCP application.
> 
> Of course what, we really wanted to say was TCP-ENO was designed to
> support TCP-use-TLS.  However, if I recall, there's a citation issue
> because we aren't supposed to cite an internet draft in an RFC unless
> the two will become RFCs at the same time, and TCP-use-TLS has been
> delayed.  But then in 0x30, we still cite TCP-Use-TLS to assign it code
> point 0x30.

This is not an actual problem, as the restriction is that one is not supposed to *normatively* cite an Internet-Draft in an RFC unless that draft is expected to become an RFC soon, otherwise the RFC-to-be spends a long time at the RFC Editor waiting for the normatively referenced draft to catch up to it (I've been there, done that).

Citing an Internet-Draft *informatively* is not a problem, will not cause any delays, and seems appropriate for this situation.

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:tcpinc-bounces@ietf.org] On Behalf Of David Mazieres
> Sent: Friday, July 28, 2017 4:23 PM
> To: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
> Cc: draft-ietf-tcpinc-tcpeno.all@ietf.org; tcpinc <tcpinc@ietf.org>
> Subject: Re: [tcpinc] AD review of tcp-eno
> 
> "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> writes:
> 
> > This is what early allocation is for. We could have also asked for
> > early allocation for tcpinc as soon as the spec was reasonably stable
> > but given there was no-one who was actually about to deploy this in
> > the Internet, it was probably not necessary.
> 
> Is there something I can put in the document to clarify that early
> allocation should be the norm not the exception?  The think I like about
> "Specification required" is that RFC7120 2a says:
> 
>        The code points must be from a space designated as "RFC
>        Required", "IETF Review", or "Standards Action".  Additionally,
>        requests for early assignment of code points from a
>        "Specification Required" registry are allowed if the
>        specification will be published as an RFC.
> 
> So I like the fact that the specification required allows early
> allocation *if* an RFC is anticipated.
> 
> Basically I want something in this document to make it clearly easier to
> get ENO TEP IDs than TCP option kinds.
> 
> 
> On a related note, I think there might be an inconsistency in the draft
> that I would appreciate some input in resolving.  Section 7.1 says:
> 
>         TLS can currently only be added to legacy applications whose
>         protocols accommodate a STARTTLS command or equivalent.
>         TCP-ENO, because it provides out-of-band signaling, opens the
>         possibility of future TLS revisions being generically applicable
>         to any TCP application.
> 
> Of course what, we really wanted to say was TCP-ENO was designed to
> support TCP-use-TLS.  However, if I recall, there's a citation issue
> because we aren't supposed to cite an internet draft in an RFC unless
> the two will become RFCs at the same time, and TCP-use-TLS has been
> delayed.  But then in 0x30, we still cite TCP-Use-TLS to assign it code
> point 0x30.
> 
> Given the work invested in TCP-Use-TLS, should we indeed reserve TEP Id
> 0x30 for that effort in case anyone wants to pick up it up again, and if
> so how should we do that without citing an expired internet draft?  Can
> we just reserve TEP ID 0x30 for future use by TLS and cite TLS?  Or what
> should we do?
> 
> Thanks,
> David
> 
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc