Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-stateless-06: (with DISCUSS and COMMENT)

[Klaus Hartke <[e-mail]>]

Hi Ben,

thanks a lot for your detailed review. I'll respond in batches; please see the first batch (some low hanging fruits) below.

One question: Where did you see that "Len (extended)" is 0-4 bytes instead of 0-2 bytes as shown in the appendix?

Best regards,
Klaus


Benjamin Kaduk wrote:
> Section 2.1
>
>    The new definition of the TKL field increases the maximum token
>    length that can be represented in a message to 65804 bytes.  However,
>    the maximum token length that sender and recipient implementations
>    support may be shorter.  For example, a constrained node of Class 1
>    [RFC7228] might support extended token lengths only up to 32 bytes.
>
> Is there anything to say about IP MTU here?

IMHO, nothing that is not already been said in RFC 7252.

>    Since network addresses may change, a client SHOULD NOT assume that
>    extended token lengths are supported by a server later than 60
>    minutes after receiving a response with an extended token length.
>
> nit: maybe "after receiving the most-recent response with [...]"?

Done.

> Section 3
>
>    As servers are just expected to return any token verbatim to the
>    client, this implementation strategy for clients does impact the
>    interoperability of client and server implementations.  However,
>
> nit: is this intended to be "does not impact"?

Yes. Fixed.

> Given the subsequent sentence I might suggest "does not substantially
> impact" instead, though.

Hmm... no, there is really no interoperability issue between some client and some server. Just between the client that sends the token and its future self that receives the token.

> Section 3.2
>
>    A client that depends on support for extended token lengths
>    (Section 2) from the server to avoid keeping request state SHOULD
>    perform a discovery of support (Section 2.2) before it can be
>    stateless.
>
> This feels like a descriptive "needs to" rather than normative "SHOULD".
> Stateless operation just isn't going to work if the server doesn't support
> extended token lengths and the client needs it.

Fixed.

> Section 3.3
>
>    Reset messages, however.  Non-confirmable messages are therefore
>    better suited.  In any case, a client still needs to keep congestion
>
> nit: better suited for what?

Changed to "Non-confirmable messages are therefore better suited for avoiding state."

> Section 4.3
>
> RFC 7252 doesn't really suggest that there's a protocol element that would be
> set to "infinite" here; perhaps we should just say that "in this case, the
> gateway cannot return such a response and as such cannot implement such a
> timeout".

Done.

>    guarantees are voided.  Devices with low-entropy sources -- as is
>    typical with constrained devices, which incidentally happen to be a
>    natural candidate for the stateless mechanism described in this
>
> nit: "low-entropy sources" is a weird phrasing; "low-quality entropy sources"
> would feel more natural to me.

Fixed.

> Also, draft-irtf-cfrg-randomness-improvements may be of interest to at least
> some such devices.

Yes, this is in general interest to such devices.

> Section 6.1
>
> Should the table formatting be consistent between here and Section 2.2.1?

I chose the same formatting as in RFC 8323; see, e.g., https://tools.ietf.org/html/rfc8323#section-5.3.1 and https://tools.ietf.org/html/rfc8323#section-11.2