All responses perfect; thanks. I don’t think there’s a need for a formal citation to TCP-ENO for the registry, as it won’t be needed once the registry is created. It’s only needed for review now, so people like me don’t scratch our heads.
Carry on...
Barry
On Fri, Nov 17, 2017 at 12:16 AM Daniel B Giffin <dbg@xxxxxxxxxxxxxxxx> wrote:
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
--