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

I agree with Barry's comments and am pleased that he made them so I don't have to.

No objections to this recharter -- just a couple of comments:

1.  I think this paragraph needs some editing; if I may suggest"

OLD
ROLL is  in charge to the maintenance of RPL and protocols developed by the Working Group such as RPL and MPL, previous approval by AD/IESG of each new work proposed.

NEW
ROLL is responsible for maintenance of the protocols that is has developed, including RPL and MPL.  AD approval is required for each new work item that is proposed.

END

2.  In general, I have a strong preference for leaving the division of work into specific documents for the milestones, and to keep the charter for specification of the *work*, without saying how that splits into documents.  Suppose, for example, that the working group should decide that the two work items that are now listed really belong in one document?  Or that there's really a third document hiding in there somewhere.

So why not this?:

OLD
Work Items:

- A document detailing when to use RFC6553, RFC6554 and IPv6-in-IPv6
encapsulation.

- A document detailing how to compress RFC6553, RFC6554 and IP headers in the
6LoWPAN adaptation layer context.

NEW
Work Items:

- Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.

- Details about how to compress RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context.

END

I agree with Barry's comments about work items vs documents.

I agree with Barry's comments on the last paragraph's phrasing. It is currently not understandable.

This sentence seems complex:

"Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been
evaluated by the working group and have in their current form been found to not
satisfy all of these specific routing requirements."

Would it be clearer to say 

"The working group has evaluated the existing routing protocols OSPF, IS-IS, AODV, and OLSR, and these protocols do not satisfy all of these specific routing requirements without changes."

But do the right thing ...