Re: [tcpinc] AD review of tcp-eno

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi David, hi all!

any news? Also regarding draft-ietf-tcpinc-tcpcrypt?

Mirja


> Am 14.08.2017 um 14:39 schrieb Mirja Kuehlewind (IETF) <[e-mail]>:
> 
> Hi once again,
> 
> because I also saw the updated draft just now. Thanks for that! All changes look good!
> 
> The only remaining question, is probably now how to cite tcp-use-tls. The way it is cited right now (as informational) would not block the publication. However, it seems weird to assign a number to an (expired) draft. Again, as explained below, it would actually recommend to just not assign it at all, or you could mark it as reserved and explain in the text what it is reserved for (use with TLS) without referring to a specific doc, if you really want.
> 
> Also again, please update draft-ietf-tcpinc-tcpcrypt as I would like to start their IETF Last Calls together!
> 
> Thanks!
> Mirja
> 
> 
>> Am 14.08.2017 um 14:29 schrieb Mirja Kuehlewind (IETF) <[e-mail]>:
>> 
>> Hi David,
>> 
>> sorry for the delay; I missed this mail. See below.
>> 
>>> Am 28.07.2017 um 22:22 schrieb David Mazieres <[e-mail]>:
>>> 
>>> "Mirja Kuehlewind (IETF)" <[e-mail]> 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.
>> 
>> This text only says that Early Allocation is only possible for "Specification required" if the specification will be an RFC. So if you have „Specification required“ and you have a stable spec somewhere, then you can ask for a code point right away. However, if your spec is a draft, you should wait to ask for the codepoint until this spec is stable, hence published as RFC. However, in this case you can apply the early allocation. While for policies where all final documents are RFC („IETF review“ or „Standards action“), early allocation is always possible.
>> 
>> Again I believe that you want all schemes to be document in RFCs in the IETF stream as a final outcome. Therefore the right policy is „IETF review“. Again, it is not necessary to explicitly mention early allocation for this policy, however, if you want to make sure that people think about using it, you can mention it separately.
>> 
>>> 
>>> So I like the fact that the specification required allows early
>>> allocation *if* an RFC is anticipated.
>> 
>> Again, if your spec is not an RFC/draft this means you can allocation a code point right away. I don’t think this is what you want.
>>> 
>>> Basically I want something in this document to make it clearly easier to
>>> get ENO TEP IDs than TCP option kinds.
>> 
>> It’s actually not that hard to get an option number if you follow the process. Unfortunatey this was a bit a mess from the beginning for tcpinc. Again, we could have asked for early allocation for tcpinc but it didn’t seem necessary, given there is the experimental option and there was no real deployment yet.
>>> 
>>> 
>>> 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.
>> 
>> You shouldn’t cite a draft normatively, also you in theory can if really needed. 
>> 
>>> 
>>> 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?
>> 
>> Yes, I think it would be good to remove the normative reference here. Usually the tcp-use-tls draft should make the assignment request itself. We could mark it in the registry as reserved and make a note in the document that this is reserved for use with TLS (without referring to any document). Or we just leave this open. I’m not expecting any other scheme coming up soon (especially if we go for „IETF review“ and not „Specification required", and in the unlikely case this would happen, then TLS would need to take another number, which I believe would also not be a problem, right?
>> 
>> Mirja
>> 
>> P.S.: Please also check my comments for draft-ietf-tcpinc-tcpcrypt and update accordingly. I would like to start both IETF Last Calls at the same time when updated. Thanks!
>> 
>> 
>> 
>>> 
>>> Thanks,
>>> David
>> 
>