Routing Over Low power and Lossy networks
charter-ietf-roll-05

I agree with Mirja's comment.  Perhaps describing them as a WG draft based on ....  ?

One more or less editorial comment on the milestones:
Saying something like "Initial submission of draft-name-xy-..." seems wrong given these drafts have not been adopted as wg items yet.

This charter looks fine to me, modulo a few nits I wondered about.

Perhaps "self routing configuration" might be clearer as "routing self-configuration"? 

I was expecting "It will also need to consider the transport characteristic the routing protocol messages will experience" to refer to characteristics, plural. But I wonder if the sentence would be clearer as "The workng group will consider the transport characteristics routing protocol 
messages will experience". 

I'm sure "Additional protocol elements to reduce packet size" is correct, but it seems counter-intuitive. Is there a better way to say what you mean?

Is "the draft about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo" an Applicability Statement, or did this mean something else? But I see that Mirja had a question about the use of draft names that haven't been adopted. Perhaps it's worth a pass substituting clearer descriptions for draft names?

I have one non-blocking question for the IESG and WG 
chairs...

The charter continues to say "The Working Group will pay 
particular attention to routing security..."

How do we think that's going? I'm not sure that it's going 
that well - we seem to have a history where ROLL documents
arrive at the IESG lacking security analysis. I don't think
that's because folks are bad or lazy, but it's maybe more 
down to people assuming that security is someone else's
problem (e.g. will be handled by layer 2, or will be part
of some applicability statement, or will be handled by
some RPL security document etc...)

Anyway, now that we're re-chartering, maybe it's a good
time to review how we've been doing on this, given the
history and see if there's anything we could do to avoid
problems arising for future ROLL documents. (I don't have
any specific suggestion for what to do, I just wanted to
see if a discussion of this might be useful.)

Re: ROLL will coordinate closely with the working groups in other areas that focus 
on constrained networks and/or constrained nodes.

It might be worthwhile adding the following INT  working groups to the list for co-ordination.

6tisch: very closely related because of the extensive use of RPL as well as the OFs
ipwave: as we discussed during chartering of ipwave, there might be use cases that require either co-ordination and/or routing expertise in the future. roll might be an appropriate contact point