Martin Stiemerling has entered the following ballot position for
draft-ietf-core-groupcomm-21: Discuss

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Updated:

I have objections about this draft being published in its current form
and with its current status. The draft updates protocol behavior of RFC
7252 in at least two Sections: 2.5 and also 2.7. But is never saying so
and legally speaking also not requesting any update of RFC 7252. 

Section 2.5 updates the handling of tokens for the mutlicast usage. 
Section 2.7 adds a completely new functionality to the protocol.

This has also been nicely pointed out by the GENART reviewer:
http://www.ietf.org/mail-archive/web/core/current/msg05535.html

Probably the document is heading for standards track instead of
informational?

Further, I do see multiple playes where the RFC 2119 language is
inappropriate:

2.2.  Group Definition and Naming

[...]

   All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast
   group [RFC7252], Section 12.8) by default to enable CoAP discovery.
   For IPv4, the address is 224.0.1.187 and for IPv6 a server node joins
   at least both the link-local scoped address FF02::FD and the site-
   local scoped address FF05::FD.  IPv6 addresses of other scopes MAY be
   enabled.
Since this is (hopefully) just repeating what RFC 7252 say, it is just
good to say: 
"All CoAP server nodes should/are supposed to join the "All CoAP Nodes"
multicast"
Also the "MAY be" is a "can be" in reality. 

2.7.2.  Membership Configuration RESTful Interface

The " an OPTIONAL CoAP membership configuration RESTful" is misplaced, as
this in informational draft, but this goes back to my general DISCUSS
point above. 

Further:
   To access this interface a client MUST use
   unicast CoAP methods (GET/PUT/POST/DELETE).  This interface is a
This MUST is not correct here. A sentence saying that only the unicast
methods are useful in this respect is sufficient.

And here the contradiction is happening, as I do not see a MUST for DTLS
in RFC 7252 and this text below is also not adding anything useful to the
discussions what is needed to achieve interoperability, i.e.,
inappropriate for MUST in this place:
   Also, a form of authorization (making use of DTLS-secured CoAP
   [RFC7252]) MUST be used such that only authorized controllers are
   allowed by an endpoint to configure its group membership.