Babel routing protocol
charter-ietf-babel-02

Applicability Statement doesn't have to be Informational, it can be Proposed Standard (need to find a reference). But I don't object either way.

The phrase "and work with the IESG for its approval" seems out of place. In a way this is either true for all standards track documents or none of them; either way it seems superfluous.

The Charter in general is ok, but I think there are some pieces that should be clarified.

1.  Are there specifics of "earlier reviews" or the "comments presented at the BABEL BoF at IETF-95" that should be explicitly called out?  It seems to me that generically mentioning what amounts to the need to address "comments" is not needed or useful…again, unless there are specific items that could be highlighted in the charter.

2. [nit] Maybe reorder the Work Items mentioning first the ones that are required for advancing to PS, and later others.

3. Is the intent for the 3 main work items (base specification, security, management) to advance together (to IESG review, etc.)?  If so, then it would be nice to explicitly call it out (and reflect it in the milestones).  If not, then it should be, because they are explicitly mentioned as required for Babel to advance to PS.

4. How is "keep its wiki updated" a work item?  I agree that support documentation can be held in a wiki — what I'm missing (as a work item) is the intended deliverable.  If the intent is to document current implementation experience, then let's explicitly say so (and not just "expect" that it will happen), and set the proper publication expectations.

5. What does "multicast aspects of Babel" mean?   The answer on the babel list [*] indicates a wide variety of possibilities.  I would prefer it if the specifics were included in the charter; or, given that multicast is mentioned as a "secondary focus", that it be left off for re-chartering.   (s/PIM/the PIM WG).

6. Besides the specific call out to pim, are there other WGs with which we might need babel to coordinate with?  Please call them out specifically.



[*] "Some people appear to believe that Babel works fine with PIM-SM as it stands.  Some other people appear to believe that it would be a good thing for Babel to be extended to carry a set of metrics specifically for multicast.  Yet other people would like to see Babel build multicast routing tables with no help from PIM."   (http://www.ietf.org/mail-archive/web/babel/current/msg00289.html)

My comments have already been captured by others.

Not really a DISCUSS, but I would like to at least try to convince you if you disagree.

"Address manageability of Babel by producing an informational model,
for use by other network management, and a YANG module based on it, to
be consistent with the ongoing effort to use YANG modules in the
Routing Area.  This is required as part of moving Babel to Proposed
Standard."

Do the WG really want to focus on an information model first, as opposed to go directly to a data model?
See RFC3444. The end goal is a YANG data model, as you correctly stressed.

Proposal (we used this sentence in SUPA): 
If the working group finds it necessary to work on an information model 
before the data model, to help provide guidance and derive the data 
models, it may do so. The working group will decide later whether the 
information model needs to be published as an RFC.

Also, "This is required as part of moving Babel to Proposed Standard."
I want to make sure we set the right expectations for this.
Babel will not move to Proposed Standard unless we publish the YANG data model at the same time. 
If so, I like that. You might want to make it clear, in the charter text or the milestones.

Editorial: YANG module => YANG data model

This is really just a question and may result in updated text or not...

I think by the following, you mean there will be a draft specific to security:

Thus, the working group will produce a Proposed Standard Babel
specification, including or paired with a suitable security
specification for BABEL.

Or do you mean that you will cover security requirements and considerations in each of the other drafts produced?

Thanks.

I agree with others that some clarifications would help; maybe also try to reduce redundancy for more clarity. But I don't have any additional comments to add.

I had two thoughts. In these bullets:

- As a secondary focus, the working group may work on multicast
aspects of Babel.  Such work should be coordinated with PIM.

- Coordinate with other working groups as needed.

This means "coordinated with the PIM working group", doesn't it?  Perhaps that would be clearer.

Speaking as a past chair of a working group that wasn't great at figuring out what working groups we should have been coordinating with - if you have thoughts about "other working groups as needed", it may be helpful to say, "as needed, including X and Y working groups".

* There is no mention of backward compatibility in the charter. Is the "new" Babel intended to be backward compatible with the deployed experimental version(s)? Might be worth noting either way.

* One of the potential (and I personally think one of the most important) uses of Babel is as a routing protocol in homenets. Two of the things that seem to be interesting improvements to Babel for this use case seem to be a)self-configuration and b)source-specific routing. I do not see either of them in the charter. I would have really liked to see something in the charter to address these two issues.

"- Coordinate with other working groups as needed." Appears like its a secondary focus. Would you mind reordering this such that it is higher in the list, as bebel will primarily exist for the benefit of other WGs. Can the text be expanded to be inclusive of suggested WGs? eg "Coordinate with other working groups as needed, such as HOMENET, PIM, ..."

I agree that complex link metrics should be out of scope of the WG. (last para) Can this be moved up to the end of third paragraph please?