Babel routing protocol
charter-ietf-babel-02

[Ballot comment]
I had a couple of suggestions, but this looks fine.

We all know that applicability statements are standards-track, but perhaps it's worth spelling that out for people who haven't read RFC 2026 lately, since we don't produce many applicability statements. Perhaps "As the Proposed Standard version of Babel is completed, an Applicability Statement should be finalized to guide those potentially interested in deploying Babel. This Applicability Statement may include deployment advice and will be published as a standards-track RFC."

I wasn't sure what you meant by "state" in "The Working Group should document its ongoing implementation experience with Babel, so that new WG participants can understand the state that is driving this work and the experience driving changes." I can guess, but I was guessing.

Changed charter milestone "IESG Submission of RFC6126bis and potentially companion security mechanisms draft", set description to "IESG Submission of RFC6126bis and potentially companion security mechanisms draft (Proposed Standard)"

[Ballot comment]
I just have a couple of nits:

1. The list of Work Items includes a couple of bullets related to coordination and liaisons, which are clearly not "work items".  Please move this text before/after the work items.

2. This text in the first paragraph sounds like marketing to me: "It is robust even in the presence of link metric oscillations and the failure of transitivity."

[Ballot comment]
1. Editorial

Justification:
- TR69 is a management protocol, not "network management"
- I tried to explain that data models are derived from the information model

OLD:
- Address manageability of Babel by producing an informational model
for use by other network management such as the Broadband Forum
TR-069, and a YANG data module based on that information model.  The
former supports the case where the Customer-Premise Equipment (CPE)
is managed by the Service Provider (SP) as is done today.  The latter YANG
model supports management of home gateway routers and is  consistent
with the ongoing effort to use YANG data modules in the Routing Area.
This work is required as part of moving Babel to Proposed Standard.

NEW:
- Address manageability of Babel by producing a Babel informational model
to help provide guidance and derive the data models. To be consistent with
the ongoing effort to use YANG data modules in the Routing Area, a Babel
YANG data model to support management of home gateway routers is required
as part of moving Babel to Proposed Standard. This information model is
useful as a common source of information for the case where the
Customer-Premise Equipment (CPE) is managed by the Service
Provider (SP) with the Broadband Forum TR-069 protocol and its associated
data model.

2.
I don't believe we need this text:
Thus, the Working Group will produce a Proposed Standard Babel
specification, including or paired with a suitable Proposed Standard
specification covering the security mechanism(s) for BABEL. It will
also produce a management information and data model for BABEL as a
Proposed Standard RFC. An applicability statement will be produced as
an Informational RFC.

However, as discussed during the retreat, the deliverables should clearly mention
the expected status: informational, proposed standard

[Ballot comment]
Thanks for addressing my comments from the previous version of the charter. It looks good now. As a minor nit, the charter has two bullet points that mention "As a secondary focus...". I suggest removing the phrase "As a secondary focus," from the second occurrence.

[Ballot comment]
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.

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

[Ballot comment]
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

[Ballot comment]
* 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.

[Ballot comment]
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.

[Ballot comment]
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)

[Ballot comment]
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 WG 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)

[Ballot comment]
"- 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?

[Ballot comment]
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".

[Ballot comment]
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.