Subject: [Gen-art] Fwd: Operations Directorate Review of draft-ietf-core-coap-13.txt

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Apr 2013 00:42:36 +0200

Here is the reply to the ops-dir review I just talked about.

Grüße, Carsten

Begin forwarded message:

> Resent-From: [email-masked]
> From: Carsten Bormann <[email-masked]>
> Subject: Re: Operations Directorate Review of draft-ietf-core-coap-13.txt
> Date: March 11, 2013 22:24:04 +0100
> Resent-To: [email-masked], [email-masked], [email-masked], [email-masked]
> To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, ext Benoit Claise <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> Hi Mehmet,
> 
> thank you for this input.
> 
> I read some of it as guidance for future development of the protocol, and in particular for shaping the next steps the working group needs to take on; it will be quite useful for this even if it is not influencing the base spec at this time.
> 
> I believe we have to address scalability of the environments using the protocol in separate work; how we will scale those up is somewhat orthogonal to the base specification (which, however, is indeed intended to be applicable to trillions of nodes).  Similarly, there are multiple models for the interaction with other protocols such as DNS, and scalability will have to be considered in refining these models.
> 
> NSTART is defined as 1 with a MUST; section 4.7 is specific about the cases where different values will be allowed.  Again, defining congestion control schemes more flexible than the base spec is future work.
> 
> Some specific comments:
> 
>> - The table in Section 4.8 needs a table number and title.
> 
> Fixed in SVN (will be in -14).
> 
>> - Section 4.8.1. "Changing The Parameters" says: "It is recommended that an application environment use consistent values for these parameters." However, it is unclear what the definition of "consistent" is in this context. The values in the table could be seen as an example of consistent set of variables. I would like to suggest to provide "value intervals" for the parameters, within which the entire parameter set appears to be consistent. Also it is unclear what is meant by "congestion-safe in the Internet" or "congestion control safety". Depending on this understanding the user of the protocol will be able to choose the correct values.
> 
> One problem is that it will require some ongoing research to answer these questions.
> So we can't lock them down yet, and instead can just refer to general principles.
> This includes limits on the values.
> 
>> - Concerning default values RFC 5706 states: "It is very useful to understand whether defaults are based on best current practice and are expected to change as technologies advance".
>> In the CoAP draft this has been done only for a few cases and could be further extended.
> 
> The current draft is quite clear that advances in congestion control mechanisms are going to make different values possible.  Those implementations that do not follow those advances are served reasonably well by the standard values.
> 
>> - Section 4.8.2.  "Time Values derived from Transmission Parameters": I would like to suggest to summarize the discussed time values in a table with following column titles: Name, recommended default value, allowed value interval, error code if relevant.
> 
> We don't have the columns 3 and 4 yet.
> I have added a table with columns 1 and 2.
> 
>> ** Concerning the migration path, and future versions of CoAP in the same network:
>> 
>> - It would be useful to state clearly, in which cases it is dangerous to change any of the recommended default values or parameters in future versions of CoAP and would potentially impact the co-existence of two CoAP versions. Thus such a statement would support an incremental deployment to be successful.
> 
> Again, I believe this is future work, which also applies for the configuration and management data model.
> 
> Protocol debugging is aided by the self-describing nature of the protocol messages.
> This has worked pretty well in the (informal and formal) interops so far.
> 
> Future work will have to address management interfaces for CoAP nodes, including management of security related events.
> I think some of this will have to integrate with resource discovery, an active subject in the working group.
> 
> Grüße, Carsten
> 
> 
>