Subject: [core] Comments on Section 11 of draft-ietf-core-coap-04

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 29 Jan 2011 08:01:34 +0200

Hello all,

I'm forwarding my message to the mailing list, that I've sent to one of 
the authors of draft-ietf-core-coap-04.  I copied  it to the mailing 
list befor before, but Klaus wanted to comment my message, but told me 
it hadn't arrived to mailing list.

Mykyta
> Hello all,
>
> On this week one of the authors of draft-ietf-core-coap-04, that is 
> the 'core' WG doc, wrote to uri-review mailing list to request the 
> review of Section 6 and Section 11.4 of the document.  However I 
> wanted the comment the entire Section 11 of this document.  So these 
> are my comments.
>
> As I've mentioned, comments to Section 11.4 can be found here: 
> http://www.ietf.org/mail-archive/web/uri-review/current/msg01323.html.
>
> As for Section 11.5. [I-D.ietf-tsvwg-iana-ports], that is referenced, 
> says:
>
>>   o  Port Number: If assignment of a port number is desired, either the
>>        port number the requester suggests for assignment or indication of
>>        port range (user or system) MUST be provided.  If only a service
>>        name is to be assigned, this field is left empty.  If a specific
>>        port number is requested, IANA is encouraged to assign the
>>        requested number.  If a range is specified, IANA will choose a
>>        suitable number from the User or System Ports ranges.  Note that
>>        the applicant MUST NOT use the requested port prior to the
>>        completion of the assignment.
> Therefore, mentioning desired port number is acceptable.  What will 
> happen if, e.g. the port 5683 will be assigned before the document 
> processes as the RFC?  So there should be mentioned TBD1 - 
> [USER-REGISTERED PORT] and throughout the document mention TBD1 
> instead 5683.
>
> Now as for the remainder of Section 11.  Firstly, the CoAP Option 
> Numbers registry seems to be underspecified.  What are the boundary 
> values for the registry value 'Number'?  Looking at Section 3.2 does 
> not let me answer this question.  Moreover, I do not understand why 
> did you choose using the Option Delta field instead the Option 
> Number.  Option Deltas will allow the option numbers to be the endless 
> value, and IANA will not be able to track endless registry.  So I 
> cannot say anything definite as for this registry until this issue 
> will not be resolved.
>
> As for Section 11.1.  The registry is underspecified too.  I would 
> like to suggest the following description of the 'CoAP Codes' registry:
>
>
>> IANA is asked to create and maintain the registry called 'CoAP Codes' 
>> following the guidelines below.
>>
>> The registry consists of 3 values: Code, Description and Reference.  
>> They are described below:
>>
>>   Code - an integer; values from 0 to 255 are assigned.  Refers to 
>> the value, used in CoAP messages header.  Values 1-31 are used to 
>> identify the message that contains the CoAP request; values 64-191 - 
>> CoAP response.
>>
>>   Description - a brief description of the code.
>>
>>   Reference - the reference, that specifies the code.
>>
>> Initial values are given below; new assignments are to be made 
>> following the 'IETF Consensus' policies [RFC5226].
>>
>> +---------+---------------------------------------------------------+--------------+
>> |Code     | Description                                             
>> |Reference     |
>> +---------+---------------------------------------------------------+--------------+ 
>>
>> |0        | Empty message (see Section 4.3)                         
>> |This document |
>> |1-31     | Assigned by the "Method Codes" sub-registry             
>> |(everywhere   |
>> |32-63    | Reserved                                                | 
>> below)       |
>> |64-191   | Assigned by the "Response Codes" sub-registry           
>> |              |
>> |192-255  | Reserved                                                
>> |              |
>> +---------+---------------------------------------------------------+--------------+
>
> The same needs to be for two sub-registries.
>
> Secondly, you need to specify all Unassigned and Reserved values or 
> their ranges, per RFC 5226.  Personally I consider mentioning 'All 
> other values are Unassigned, but values xx-yy are Reserved' as not 
> appropriate.
>
> Moreover, Reference should contain the document, but not Section, 
> since this may create the question 'Section of what document?'
>
> The same concerns Section 11.3 as well.
>
> Finally, as a typographical error in Section 5.9.1.3.  The response 
> code description is for 2.04, not 2.02.
>
>> 5.9.1.3. 2.02 Deleted
>>
>>
>>    Like HTTP 204 "No Content", but only used in response to DELETE
>>    requests.
>>
>>    This response is not cacheable.
>
> Thank you in advance for considering my comments in the next version 
> of the draft.  You may feel free to contact me for further information.
>
> All the best,
> Mykyta Yevstifeyev

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 29 Jan 2011 15:47:10 +0100

On Jan 29, 2011, at 07:01, Mykyta Yevstifeyev wrote:

>> What are the boundary values for the registry value 'Number'?  

Due to the way we encode option numbers, there is no really useful upper bound, so we didn't give one.
If we implement the recent discussion about a maximum message size, there can't be more than 1148 options in a normal-sized message, so 17220 may be the highest option number reachable, but this is a rather unlikely number to reach in practice (I'd expect we stay in the two digits even in the long term).
So I don't think IANA needs any guidance here beyond the IETF review policy we already have.

Thanks for reading the IANA-related sections carefully; we will make sure these items are addressed in the next version.

Gruesse, Carsten

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 30 Jan 2011 08:02:49 +0200

> So I don't think IANA needs any guidance here beyond the IETF review policy we already have.
Carsten,

Let me cite RFC 5226:

> < . . . >
> Documents that create a new namespace < . . .> MUST
> provide clear instructions on details of the namespace.  In
> particular, instructions MUST include:
> < . . . >
> 4) The size, format, and syntax of registry entries.  When
> creating a new name/number space, authors must describe any
> technical requirements on registry (and sub-registry) values
> (e.g., valid ranges for integers, length limitations on
> strings, etc.) as well as the exact format in which registry
> values should be displayed.
> < . . . >

That's why mentioning boundary values is actually needed  Moreover, it 
has the MUST requirement.

Mykyta Yevstifeyev

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 31 Jan 2011 16:27:36 +0100

Mykyta Yevstifeyev wrote:
> As for Section 11.1.  The registry is underspecified too.  I would like to
> suggest the following description of the 'CoAP Codes' registry:

The CoAP Codes registry isn't really intended to assign any codes. The
document defines what the different ranges mean. All codes that can be
registered are assigned by the two sub-registries. So I don't think we
need such text.

> Finally, as a typographical error in Section 5.9.1.3.  The response code
> description is for 2.04, not 2.02.

No, this is correct. A CoAP 2.02 (Deleted) response indicates that a
resource was successfully deleted. It has no content, so it's similar
to a HTTP 204 (No Content) response.

I will create a ticket for the other issues shortly. Carsten already
commented on the option numbers.

Klaus

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 01 Feb 2011 07:46:46 +0200

> registered are assigned by the two sub-registries. So I don't think we
However this might be needed for two sub-registries either.
> to a HTTP 204 (No Content) response.
Agreed here.  I just haven't carefully read the section; but I noticed 
this shortly after I posted that message.

Mykyta