Re: [tcpinc] Secdir telechat review of draft-ietf-tcpinc-tcpcrypt-09

[Daniel B Giffin <[e-mail]>]

Thanks for the review!

Barry Leiba wrote:
> Reviewer: Barry Leiba
> Review result: Has Issues
> 
> I’ve looked at Stephen Kent’s review and the discussion thereof, and have
> little to add to that.  A couple of small things:
> 
> 1. Section 3 says that the subsections “describes the tcpcrypt protocol at an
> abstract level.”  There is no sense in which this description is abstract, and
> I’d prefer that we not try to say it is, because that gives a reader an
> expectation that it will be high-level, and perhaps even non-normative.  Maybe
> this?:
> 
> NEW
>    This section provides details of the operation of the tcpcrypt protocol.
>    The wire format of all messages is specified in Section 4.
> END

Good point, thanks -- for the next draft I've gone with
something very similar:

   This section describes the operation of the tcpcrypt protocol.  The
   wire format of all messages is specified in Section 4.

> 2. In Section 7 (IANA), you say:
> 
>    Tcpcrypt's TEP identifiers will need to be incorporated in IANA's
>    "TCP encryption protocol identifiers" registry under the
>    "Transmission Control Protocol (TCP) Parameters" registry
> 
> I can find no such registry.  Can you help me here, maybe give me a URL?

Right, that registry is defined in TCP-ENO, which I
understand would be published in tandem with this draft.
Does that solve the problem, or ought we provide a reference
to TCP-ENO here?

For now, I've provided at least a hint by mentioning TCP-ENO
at the beginning of that sentence:

   For use with TCP-ENO's negotiation mechanism, tcpcrypt's TEP
   identifiers will need to be incorporated in IANA's "TCP encryption
   protocol identifiers" registry under the "Transmission Control
   Protocol (TCP) Parameters" registry, as in Table 4 below.  The
	 [...]

> Also, with respect to the new “tcpcrypt AEAD Algorithm" registry:
> 
>    Future assignments are to be made under the "RFC Required" policy
> 
> Note that that policy allows for assignments to be made in any RFC stream,
> which includes the IRTF, the IAB, and the Independent Stream.  Do you really
> want people to be able to send documents to the Independent Stream Editor, and
> to have them published and make assignments with minimal review?
> 
> You might consider whether “IETF Review” is more appropriate.  That allows RFCs
> of any type (Standards Track, Informational, Experimental, BCP), but requires
> that they be in the IETF stream and have a formal IETF last call.

Following the discussion about assignment policy in another
thread, I've updated this to use the same policy as TCP-ENO.
The paragraph on the "tcpcrypt AEAD Algorithm" registry now
reads:

   In Section 4.1, this document defines "sym_cipher" specifiers in the
   range 0x0001 to 0xFFFF inclusive, for which IANA is to maintain a new
   "tcpcrypt AEAD Algorithm" registry under the "Transmission Control
   Protocol (TCP) Parameters" registry.  The initial values for this
   registry are given in Table 5 below.  The AEAD algorithms named there
   are defined in Section 6.  Future assignments are to be made upon
   satisfying either of two policies defined in [RFC8126]: "IETF Review"
   or (for non-IETF stream specifications) "Expert Review with RFC
   Required."  IANA will furthermore provide early allocation [RFC7120]
   to facilitate testing before RFCs are finalized.


> It will also help IANA if you make it clear what the valid range of values is
> for the “Value” column.  Is 0x0000 valid?  Is 0xFFFF the maximum?  Explicitly
> saying that values must be in the range 0x0001 to 0xFFFF inclusive will be
> helpful.  (I say this with particular note that you changed how the Value field
> is specified between -07 and -09, so this clearly has not even been clear to
> the spec developers.)

Thanks, I've added that as you can see above.

daniel