Here is the reply to the ops-dir review I just talked about. Grüße, Carsten
Begin forwarded message: > Resent-From: [email protected] > From: Carsten Bormann <[email protected]> > Subject: Re: Operations Directorate Review of draft-ietf-core-coap-13.txt > Date: March 11, 2013 22:24:04 +0100 > Resent-To: [email protected], [email protected], [email protected], > [email protected] > To: "Ersue, Mehmet (NSN - DE/Munich)" <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]>, > ext Benoit Claise <[email protected]>, "[email protected]" > <[email protected]> > > 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 > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
