Subject: [core] Robert Wilton's No Objection on draft-ietf-core-stateless-06: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 20 Apr 2020 04:51:40 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-core-stateless-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-stateless/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document.  I found the document easy to read and the concept
described easy to understand.

A few minor comments:

2.1 Extended Token Length (TKL) Field

      13:  An 8-bit unsigned integer precedes the Token field and
         indicates the length of the Token field minus 13.

      14:  A 16-bit unsigned integer in network byte order precedes the
         Token field and indicates the length of the Token field minus
         269.

I wonder whether it would be worth changing "precedes" to "directly precedes"
to avoid any doubt of exactly where the length field appears?  Although I note
that the updated message formats are in the appendix anyway.

2.2.1.  Extended-Token-Length Capability Option

 The draft doesn't suggest whether the Extended-Token-Length capability option
 should be used when the server only supports a max-length of 8.  Would it be
 useful to give a recommendation for servers in this case, e.g.  SHOULD they
 only include the capability if they support a max token length larger than 8
 bytes?

3.  Stateless Clients

   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,
   there are a number of significant, non-obvious implications (e.g.,
   related to security and other CoAP protocol features) that client
   implementations need take into consideration.

I found the first sentence somewhat unclear - in that I was wondering if "does
not impact" was intended instead of "does impact"?  Or otherwise, I wasn't
quite sure what this sentence was trying to convey.

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 20 Apr 2020 12:11:14 +0000

Robert Wilton wrote:
> Thanks for this document.  I found the document easy to read and the
> concept described easy to understand.

Thanks a lot for your review!

> to avoid any doubt of exactly where the length field appears?  Although I
> note that the updated message formats are in the appendix anyway.

I've changed "precedes" to "directly precedes".

>  The draft doesn't suggest whether the Extended-Token-Length capability
> option  should be used when the server only supports a max-length of 8.
> Would it be  useful to give a recommendation for servers in this case, e.g.
> SHOULD they  only include the capability if they support a max token length
> larger than 8  bytes?

IMHO it's already clear from RFC 8323 (which describes capability options in general) that the option does not need to be included if the base value is intended.

So, a good implementation would probably not include the option in this case, but there is no interoperability issue if it does that we'd need to prevent with a SHOULD (or MUST).

> I found the first sentence somewhat unclear - in that I was wondering if
> "does not impact" was intended instead of "does impact"?  Or otherwise, I
> wasn't quite sure what this sentence was trying to convey.

Good catch! "does not impact" is intended. Fixed.

Klaus

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 20 Apr 2020 13:06:16 +0000

> -----Original Message-----
> From: Klaus Hartke <[email-masked]>
> Sent: 20 April 2020 13:11
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Carsten Bormann <[email-masked]>
> Subject: RE: Robert Wilton's No Objection on draft-ietf-core-stateless-06:
> (with COMMENT)
> 
> Robert Wilton wrote:
> > to avoid any doubt of exactly where the length field appears?
> > Although I note that the updated message formats are in the appendix
> anyway.
> 
> >  The draft doesn't suggest whether the Extended-Token-Length
> > capability option  should be used when the server only supports a max-
> length of 8.
> > SHOULD they  only include the capability if they support a max token
> > length larger than 8  bytes?
> 
> IMHO it's already clear from RFC 8323 (which describes capability options
> in general) that the option does not need to be included if the base value
> is intended.
[RW] 

Ah okay, then I agree that no clarification is required.  I'm not familiar with RFC 8323, but presume that an implementor of this document would be.

> 
> So, a good implementation would probably not include the option in this
> case, but there is no interoperability issue if it does that we'd need to
> prevent with a SHOULD (or MUST).
[RW] 

I agree.

Regards,
Rob

> > I found the first sentence somewhat unclear - in that I was wondering
> > if "does not impact" was intended instead of "does impact"?  Or
> > otherwise, I wasn't quite sure what this sentence was trying to convey.
>