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
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
