Subject: [babel] Draft BABEL Charter

From: Donald Eastlake <[email-masked]>
Date: Tue, 10 May 2016 12:08:27 -0400

Hi,

Russ White and I came up with the draft below. It is just a minor
rewording and condensation of previous text with some milestones
added.

I have also gone over the mailing list archives and there seem to be
two ideas there for possible additions:
- Calculation of link metrics. Is done by Babel but from the few posts
it seemed like people didn't think the Charter needed to mention this.
- Data/Information Model. There was considerably more interest in
including something about this in the Charter. Something that could
cover interaction with BBF. Perhaps something like "Work on an
Information Model for Babel Management including coordination with any
organizations interested in using this as a basis for their data model
and management" (re-wording of suggested text from Alia Atlas).
Perhaps this could be worked into the "manageability" work item
below...

Comments welcome.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

Charter for Working Group

Babel is a loop-avoiding, distance vector routing protocol with good
provisions for dynamically computed link metrics. It is robust even in
the presence of link metric oscillations and the failure of
transitivity.  The core of the Babel protocol is described in
Experimental Independent Stream RFCs 6126 and 7557, with RFC 7298
describing security extensions.  These RFCs are the basis of three
independent, open source implementations.

Babel has some production deployment, notably in hybrid networks
(networks that include classical, wired parts with meshy radio bits)
and in global overlay networks (networks built out of large numbers of
tunnels spanning continents).

The working group is will focus on moving the Babel protocol to IETF
Proposed Standard with IETF review. This includes clarifying RFC 6126
and integrating RFC 7557 and feedback provided by independent
implementations, and resolving the comments presented at the BABEL BoF
at IETF-95. Other documents which are relevant to such consideration
can also be produced. Particular emphasis will be placed on work
needed for a Proposed Standard routing protocol, such as ensuring
manageability and strong security.

Work Items:

- Produce a revision of RFC 6126 suitable for publication as a
Proposed Standard, and work with the IESG for approval of same
-- incorporate in the revision developments since RFC 6126
-- resolve technical issues found by recent reviews and the working
group discussions
-- include in the base specification the extensibility work in
RFC 7557
-- consider any important changes based on experience with Babel to
date. This may include discussion of issues such as the size of the
default metric.

- Address security needs for BABEL. This may include using the
techniques in RF 7298, or other alternatives. This may be by inclusion
in the base spec or by normative reference to a separate proposed
standard specification. This is required as part of moving Babel to
Proposed Standard.

- Produce an applicability statement for publication as an
Informational RFC. This is highly desirable in conjunction with moving
Babel to Proposed Standard.

- Address manageability of Babel, most likely by producing a YANG
model for Babel consistent with other YANG models produced in the
routing area. This is required as part of moving Babel to Proposed
Standard.

- The working group may choose to publish an Informational RFC on
implementation experience with Babel, so as to enable future readers
to better understand the state that drives this work and the
experience driving changes.

- The working group may choose to work on multicast aspects of Babel
once the initial focus on Proposed Standard is met.

- Coordinate with other working groups as need.

Thus, the working group will produce a proposed standard Babel
specification, including or paired with a suitable security
specification for BABEL. It will also produce a management model for
BABEL as a Proposed Standard RFC. An applicability statement, and
possibly an experience document will be produced as informational
RFC(s).

Milestones

Date  Milestone

 TBD  WG adoption of Babel Applicability draft.

 TBD  WG adoption of rfc6126bis draft.

 TBD  WG adoption of Babel management (probably Yang) draft.

 TBD  Submission of Babel Applicability draft to the IESG as
      Informational.

 TBD  Submission of rfc6126bis draft to the IESG as Proposed Standard.

 TBD  Submission of Babel management draft to IESG as Proposed
      Standard.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 10 May 2016 12:38:46 -0400

Hi Donald & Russ,

Thank you for updating the proposed charter.

I think that it is useful to mention that a sophisticated link metric
algorithm
computed based upon the link qualities (i.e. for wireless) is out of scope
for
the initial charter.

Do you consider that the need for a common path cost computation is included
in the text?

For the management aspects, I believe that Barbara is suggesting an
information model that can be used by BBF as well as a YANG data module; I
would be happiest with them in the same draft, but am ok either way.

I would also be interested in hearing or putting some dates in for the
milestones.  I'd like this to be a WG that moves very quickly to get the
compact amount of work done.

Thanks,
Alia

On Tue, May 10, 2016 at 12:08 PM, Donald Eastlake <[email-masked]> wrote:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 10 May 2016 12:47:39 -0400

I am also a bit concerned that we discuss the assumptions of architecture
and protocols around Babel.  For instance, most IGPs verify that packets of
max MTU can be sent and received to be confident in the link layer.  It may
just be a discussion in the doc about running BFD or the like or it might
be more complex.

Thoughts?
Alia

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 10 May 2016 20:14:49 +0200

Thanks, Donald.

The split between the first and second paragraph is a little weird.
I suggest moving the last sentence of the first paragraph to the beginning
of the second paragraph.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 10 May 2016 20:22:28 +0200

> algorithm computed based upon the link qualities (i.e. for wireless) is
> out of scope for the initial charter.

Does this mean that the WG will not be allowed to work on metrics, or
merely that it will not be required to work on that?

> Do you consider that the need for a common path cost computation is
> included in the text?

Could you please explain?

Another issue -- what happens to the source-specific routing (SADR) work?
Does the current charter mean I will only be able to submit it as an
individual draft?

> compact amount of work done.

Right.

 - TBD  WG adoption of Babel Applicability draft.

I intend to request adoption as soon as there is a WG.

 - TBD  WG adoption of rfc6126bis draft.

I intend to submit rfc6126bis and request adoption as soon as there is a WG.

 - TBD  WG adoption of Babel management (probably Yang) draft.

 - TBD  Submission of Babel Applicability draft to the IESG as
        Informational.

It's a relatively short draft (and I intend to keep it that way), it
shouldn't take long to review.

 - TBD  Submission of rfc6126bis draft to the IESG as Proposed Standard.

That difficult to predict, since it depends very much on whether the WG
intends to keep rfc6126bis backwards compatible, since I'd like this to
happen only after we have at least one full implementation of the new
document.

 - TBD  Submission of Babel management draft to IESG as Proposed
        Standard.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 10 May 2016 20:24:38 +0200

> I am also a bit concerned that we discuss the assumptions of architecture and
> protocols around Babel. For instance, most IGPs verify that packets of max MTU
> can be sent and received to be confident in the link layer. It may just be a
> discussion in the doc about running BFD or the like or it might be more
> complex.

> Thoughts?

This can be done within the current protocol, but AFAIK none of the
existing implementations do this.  Perhaps it deserves an informational
appendix?

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Tue, 10 May 2016 21:48:52 -0400

> > algorithm computed based upon the link qualities (i.e. for wireless)
> > is out of scope for the initial charter.
> 

It means it isn't required. OTOH, we don't want to try to boil the ocean --
we can leave problems for later charter items as we finish what we bite off
in the first round. 

> Could you please explain?

There probably needs to be a "must implement" metric/calculation mechanism. 

> Does the current charter mean I will only be able to submit it as an
individual
> draft?

I would say -- we can decide if we want to adopt it as a WG doc, but leave
it draft form 'til the base work is done. Then we can pick up a second round
of goals/milestones.

>  - TBD  Submission of Babel Applicability draft to the IESG as

I would suggest we give ourselves two IETFs to get these bits done, or one
interim and try to adopt at the next IETF. 

> intends to keep rfc6126bis backwards compatible, since I'd like this to
happen
> only after we have at least one full implementation of the new document.

For this one, I'd give us two/three IETFs to get it done, so we have at
least one cycle to evaluate where the four drafts above in at least some
measure. Again, we might need to pull forward or back as things progress,
but it's a good stake in the ground.

>  - TBD  Submission of Babel management draft to IESG as Proposed

I'd give us three/four IETFs to get this done.

I know, thinking in terms of IETFs might be odd, but it seems useful at the
moment, because we're really only going to be able to progress documents at
or around a meeting, with interims to push things along.

I tend to think this needs/wants to be in a main document someplace, rather
than in an appendix. This is something people are likely to want to actually
implement; putting it in an appendix almost makes it seem like it shouldn't
be implemented somehow.

Finally -- are the drafts up in git someplace? It might be useful to put
them there, so we can draw people who want to make comments into that
mechanism, rather than just into the mailing list. Folks who've worked
mostly on the open source side might be more comfortable tracking comments
through a git repository (?).

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 16:11:31 +0200

Hi Russ,

> we can leave problems for later charter items as we finish what we bite off

You're positive that we can adopt a draft even if it's outside the charter?
Alia, perhaps you could comment?

> There probably needs to be a "must implement" metric/calculation mechanism.

I happen to disagree -- metric calculation is an area of active research
(a difficult and important problem), and better metrics are bound to
appear during Babel's lifetime.  I really like the current structure
(suggested by Joel Halpern), which basically says "do something smart, if
you're not smart, use Appendix A".

>> Another issue -- what happens to the source-specific routing (SADR)
>> work?  Does the current charter mean I will only be able to submit it
>> as an individual draft?

> it draft form 'til the base work is done. Then we can pick up a second round

Again -- are you positive that we can adopt a draft even if it's outside
the charter?

>> [Verifying correct MUT] can be done within the current protocol, but
>> AFAIK none of the existing implementations do this.  Perhaps it
>> deserves an informational appendix?

> implement; putting it in an appendix almost makes it seem like it shouldn't

For what it's worth, we haven't had any requests for such an issue from
our users -- it doesn't look like people are getting MTUs wrong, but then
everyone is using Ethernet-compatible link-layers nowadays.  (What we're
seeing a lot of issues with is wireless interfaces mis-detected as wired.)

> mechanism, rather than just into the mailing list.

I'd much rather draw people to the mailing list, but yeah, active drafts
should have their xml easily available somewhere.

> Folks who've worked mostly on the open source side might be more
> comfortable tracking comments through a git repository (?).

It depends on the folks, obviously.  In the case of the Babel community,
virtually all discussion happens on the babel-users mailing list, not on
github.

(I think you meant github, which is a proprietary website, not git, which
uses open (if undocumented) formats and protocols.  I think the distinction
is relevant for IETF work.)

-- Juliusz

---

From: Bob Hinden <[email-masked]>
Date: Wed, 11 May 2016 08:23:39 -0700

Juliusz,

inline

> On May 11, 2016, at 7:11 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Hi Russ,
> 

In my experience, as long as it’s in the overall scope of the w.g. charter, other related work can be adopted if the w.g. supports it.  Adding new milestones to a charter should be straight forward.

> is relevant for IETF work.)

I think git is great to allow folks to work on a draft (I do it myself), but think in the IETF that discussions should be on the w.g. mailing list.  That mailing list discussion should be about Internet drafts.  That keeps the whole history of the discussion in the mailing list archive and in the data tracker.  It’s an important part of the standards process.

Thanks,
Bob

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 May 2016 17:31:59 +0200

> but think in the IETF that discussions should be on the w.g. mailing
> list.  That mailing list discussion should be about Internet drafts.
> That keeps the whole history of the discussion in the mailing list
> archive and in the data tracker.  It’s an important part of the
> standards process.

Thanks, and agreed.

-- Juliusz

---

From: Dorothy Gellert <[email-masked]>
Date: Wed, 11 May 2016 09:47:56 -0700

+1

> On May 11, 2016, at 8:23 AM, Bob Hinden <[email-masked]> wrote:
> 
> Juliusz,
> 
> inline
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 12 May 2016 07:40:11 -0400

Hi Juliusz,

> I suggest moving the last sentence of the first paragraph to the beginning

Sure but I think that only makes sense if the text asserts that the open
source implementations mentioned are what is used in the depoyment.
Otherwise, it makes more sense to leave the paragraphs as they are.

So the 2nd paragraph could become something like:

These RFCs are the basis of three independent, open source implementations.
There is some production deployment of these implementations, notably in
hybrid networks (networks that include classical, wired parts with meshy
radio bits) and in global overlay networks (networks built out of large
numbers of
tunnels spanning continents).

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 12 May 2016 07:57:05 -0400

Re Charter scope and drafts, see below:

> Alia, perhaps you could comment?

In my experience, it is up to the AD. Brief discussion or mention of
any closely related draft is generally fine. But WG adoption of a
draft or extensive WG discussion of a draft outside the charter should
be cleared with the AD. Depending on circumstances, it may not be all
that important whether the draft is actually adopted. Sometimes WGs
are asked to review and comment on drafts that are not drafts of that
WG. Some discussion of things outside the charter is clearly needed if
the WG is to provide input to a charter update. (The place you run
into real trouble is if you try to advance a draft to the IESG from
the WG when it is outside the WG charter. In the rare cases where that
happens, you should have your AD it with the IESG first.)

Thanks,
Donald

>...

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 12 May 2016 08:02:02 -0400

Hi Juliusz,

> merely that it will not be required to work on that?

I think that Alia is looking for a sentence in the charter something like:

Link metric measurement or calculation procedures significantly more
complex that those currently in Babel are out of scope.

Thanks,
Donald

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 May 2016 15:17:51 +0200

> In my experience, it is up to the AD.

Right.

At some point, I'll want to ask for adoption of

  draft-boutier-babel-source-specific
  draft-jonglez-babel-rtt-extension

both of which are mature specifications that have seen deployment.  If you
think the current charter won't prevent that, then I'm fine.

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Thu, 12 May 2016 11:32:23 -0400

> > archive and in the data tracker.  It’s an important part of the

Sure -- so we need to find a way to allow comments in a git repository while also keeping discussion recorded on the mailing list. I'm thinking that if people comment in git, we should not accept the changes until they are discussed on list. This would allow both sorts of tracking. Thoughts?

:-)

Russ

---

From: Gabriel Kerneis <[email-masked]>
Date: Thu, 12 May 2016 22:49:49 +0200

On Thu, May 12, 2016 at 5:32 PM, Russ White <[email-masked]> wrote:

> Sure -- so we need to find a way to allow comments in a git repository
> while also keeping discussion recorded on the mailing list. I'm thinking
> that if people comment in git, we should not accept the changes until they
> are discussed on list. This would allow both sorts of tracking. Thoughts?
>

I'm not sure what you mean by "comment in git": add comments to the text on
the github/bitbucket/whatever web interface? submit a pull request? comment
on a pull request in a web interface?

Gabriel

---

From: "Russ White" <[email-masked]>
Date: Thu, 12 May 2016 17:14:43 -0400

> I'm not sure what you mean by "comment in git": add comments to the text
> on the github/bitbucket/whatever web interface? submit a pull request?
> comment on a pull request in a web interface?

I'm thinking about adding comments to the text on the github -- the question is -- would folks in the open source community working on this find this sort of interaction and tracking more useful than "just an email list?" Or should we just focus on the mailing list? I'm trying to make certain we're inclusive of what people are already doing, while interacting with the IETF process in a way that makes sense. 

We're kindof on the leading edge of opensource/open standards interaction; this is a chance to see if there are innovative/interesting ways to help the two communities work together better. I don't have specific answers, just brainstorming/trying to think of ways to make this work better.

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 13 May 2016 01:05:41 +0200

> I'm thinking about adding comments to the text on the github -- the
> question is -- would folks in the open source community working on this
> find this sort of interaction and tracking more useful than "just an
> email list?" Or should we just focus on the mailing list?

Let's please focus on the mailing list, which is publicly archived and not
dependent on a single commercial entity.  This should not prevent us from
keeping a copy of our drafts in a public git repository somewhere.

Perhaps we should make sure that the mailing list is archived on gmane, so
we're not dependent on a single archive.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 13 May 2016 08:57:55 +0300

> On 13.5.2016, at 2.05, Juliusz Chroboczek <[email-masked]> wrote:

I think keeping the drafts in github enables mainly pull requests (=someone else than the main authors can provide text which can be conveniently incorporated to the text); for just comments, email works equally well although takes more effort to be precise on which place in the draft you would like to address.

I am not keen about the commercial entity dependency either so for anything for the posterity (e.g. my comments, as I suspect I will not contribute much text as such), I prefer the list.

> we're not dependent on a single archive.

Well, I would imagine IETF one to be reasonably well archived and to stick around ;)

Cheers,

-Markus

---

From: Teco Boot <[email-masked]>
Date: Fri, 13 May 2016 15:16:54 +0200

> Op 13 mei 2016, om 07:57 heeft Markus Stenberg <[email-masked]> het volgende geschreven:
> 

What about IETF to provide a git repo service to draft authors and contributors?

Teco

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 17 May 2016 15:12:39 -0400

It looks like discussion on the Charter has died down so I have
reviewed that discussion and, based on it, produced an updated draft
charter as pasted below after my .sig. Changes are small, just added
milestone dates, tweaked wording at end of first paragraph / beginning
of second paragraph, and added out-of-scope sentence for new complex
link metric stuff just before milestones.

Thanks,
Donald

Charter for the Babel Working Group

describing security extensions.

These RFCs are the basis of three independent, open source
implementations.  There is some production deployment of these
implementations, notably in hybrid networks (networks that include
classical, wired parts with meshy radio bits) and in global overlay
networks (networks built out of large numbers of tunnels spanning
continents).

at IETF-95. Other documents that are relevant to such consideration

Work Items:

Link metric measurement or link metric calculation procedures
significantly more complex that those currently in Babel are out of
scope.

Initial Milestones
("Date" is a month where X is the month of Charter approval)

Date  Milestone

 X+1  WG adoption of Babel Applicability draft.

 X+1  WG adoption of rfc6126bis draft.

 X+4  WG adoption of Babel management (probably Yang) draft.

 X+5  Submission of Babel Applicability draft to the IESG as
      Informational.

X+10  Submission of rfc6126bis draft to the IESG as Proposed Standard.

X+13  Submission of Babel management draft to IESG as Proposed
      Standard.

---

From: Gabriel Kerneis <[email-masked]>
Date: Tue, 17 May 2016 22:51:40 +0200

Thanks for this Donald. Minor typos and comments inline:

> The working group is will focus on moving the Babel protocol to IETF

-is

> techniques in RF 7298, or other alternatives. This may be by inclusion

RFC

> - Coordinate with other working groups as need.

needed (?)

Also, it was suggested that we may need to coordinate with organisations
outside of IETF iirc. Does it need to be mentioned explicitly?

> Thus, the working group will produce a proposed standard Babel

Should it be "Proposed Standard"? (probably for consistency with the
management model below, but I don't know if it really matters)

---

From: Denis Ovsienko <[email-masked]>
Date: Wed, 18 May 2016 13:49:12 +0100

---- On Thu, 12 May 2016 22:14:43 +0100 Russ White  wrote ---- 
>I'm thinking about adding comments to the text on the github -- the question is -- would folks in the open source community working on this find this sort of interaction and tracking more useful tha…

People just use what they can to communicate the point they consider important -- from sophisticated pull requests to screen shots and even videos. That's just the way of life. The difference comes from what they use by default. In my experience mailing lists seem to be a less resource hungry default than web-based ways of communication.

>We're kindof on the leading edge of opensource/open standards interaction; this is a chance to see if there are innovative/interesting ways to help the two communities work together better. I don't…

Free/Open Source developers don't use any special development tools or techniques compared to proprietary developers. One of the principal differences is you can look into the code any time and see yourselves if what you get is what it says on the box. Another is, if you make a bugfix, there is usually a way to incorporate it back into the upstream.

To make those differences work, it would help to recall an old saying: "If a source code needs a comment, put the comment right into that code.". In terms of I-D work it would mean: "If you think this text should say something else, please show your changes making it say exactly that something else.".

With all the modern tools in scope it becomes critical to stay focused on the deliverables, as that's what remains after tools come and go. The only semi-exemption I can tell is the history of changes itself (commit history) and the commit messages as part of it. As another advice goes: "Don't state the obvious telling what you did, instead explain why you did it".

For instance, in a commit changing the default value of a parameter from 0 to 1 a quality comment would explain why it was changed and what was the original problem and how the solution is expected to work better than before. It is a sort of a message to your future self telling: "0 worked perfectly at first but because of this regression it must be bumped up to 1, though beware not to set it to 2 in future as it will trigger another known-bad edge case". The change itself may be tiny so this kind of meta-information is important to retain. In the long run it is easy to help this information survive in a git repository but not in web comments about a repository on a git hosting web site.

To sum it up, to me personally it would make the most sense to discuss on a mailing list and to make annotated changes in a public git repository. BTW, this is how many Free/Open Source projects survive on limited resources.

-- 
    Denis Ovsienko

---

From: "Russ White" <[email-masked]>
Date: Wed, 18 May 2016 12:36:45 -0400

> To sum it up, to me personally it would make the most sense to discuss on
a
> mailing list and to make annotated changes in a public git repository.
BTW,
> this is how many Free/Open Source projects survive on limited resources.

Okay -- this sounds like the right combination of things. Are the drafts
already available in a repository?

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 May 2016 18:41:19 +0200

> already available in a repository?

I want to make the XML available at the same time I submit the -00
versions to the IETF.  (Sorry, I've been bitten before.)

I'm not sure if I can do that before we have a WG.  So let's please have
a WG.

-- Juliusz

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 May 2016 10:04:08 -0700

Juliusz,

> On May 18, 2016, at 9:41 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

I am pretty sure that when you submit a draft with the tool:

  https://datatracker.ietf.org/submit/

it allows for txt and xml to be submitted.  This can be done for individual and w.g. drafts.

Bob

---

From: "Russ White" <[email-masked]>
Date: Wed, 18 May 2016 13:09:11 -0400

> it allows for txt and xml to be submitted.  This can be done for
individual and
> w.g. drafts.

Yep -- it should...

:-)

Russ

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 May 2016 19:17:30 +0200

> it allows for txt and xml to be submitted.

Yes, and all of my drafts were submitted with the XML attached.

What I mean is that I'm waiting for the WG to exist so I can submit
draft-babel-rfc6126bis-00 (just a rebadging of RFC 6126 with the
boilerplate changed).  I'll create a public repository at the same time.

Or do people insist create a repository straight away and submit 
individual drafts so it can be adopted by the WG?  It's double the
administration with little benefit I can see, but who am I to argue.

-- Juliusz

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 May 2016 10:52:49 -0700

Juliusz,

> On May 18, 2016, at 10:17 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

Probably draft-ietf-babel-rfc6126bis-00  :-)

I agree that does require the w.g. to be created.

> administration with little benefit I can see, but who am I to argue.

True, but you might as well submit

  draft-chroboczek-babel-rfc6126bis-00

and the first act of the w.g. can be to adopt the draft.

Hope this helps.

Bob

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 May 2016 20:29:50 +0200

> I agree that does require the w.g. to be created.

[...]

> and the first act of the w.g. can be to adopt the draft.

Donald, Russ, do you have any opinions?

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 May 2016 15:02:09 -0400

You always have to submit a personal draft so that the wg can adopt it.   I
suppose you could send a sample to the mailing list and not publish it on
the datatracker, but I've never seen that done.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 18 May 2016 15:41:18 -0400

Hi Donald,

This looks good in general.  I have a few minor comments - but we should be
good to put this on the IESG telechat for June 2 for internal review.  Then
it will
have a period of 2 weeks for external review - where it is sent to a
mailing list (called
[email-masked]) that includes various other organizations (mostly SDOs);
and
return for a final approval on June 16.

> link metric stuff just before milestones.

"The core of the Babel protocol and security extensions are described in
Experimental Independent Stream RFCs 6126, 7557, and 7298."

> at IETF-95. Other documents that are relevant to such consideration

"This includes clarifying RFC 6126
and integrating RFC 7557 and feedback provided by independent
implementations, and resolving the comments presented at the BABEL BoF
at IETF-95 and during ongoing WG review"

> -- resolve technical issues found by recent reviews and the working

Could this please be updated to
"-- resolve technical issues as found during earlier reviews and ongoing
working group discussions"

to more clearly indicate that the specific set of needed changes isn't
fixed.

> Babel to Proposed Standard.

I would prefer to be extremely clear in the charter that the Applicability
statement
isn't expected to be produced before the Proposed Standard.  How about

" - 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 an RFC.

> routing area. This is required as part of moving Babel to Proposed
"-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."

> experience driving changes.

"- The working group is encouraged to keep its wiki updated with
implementation
experience with Babel so that new WG participants can understand the state
that is driving this work and the experience driving changes."

I would like to understand better the expected value of publishing this as
an RFC.
It feels to me like the kind of information that will be useful during the
WG process
but not after.

> once the initial focus on Proposed Standard is met.

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

> possibly an experience document will be produced as informational

"An applicability statement will be produced as an Informational
RFC.  If multicast aspects are pursued, with AD and WG agreement,
then a milestone may be added for an associated document targeted as
Proposed Standard.

> significantly more complex that those currently in Babel are out of

I'd like to see this better stated - including not focusing on wireless link
measurement.   I think this needs more discussion.

> X+13  Submission of Babel management draft to IESG as Proposed

Please let's not make it a waterfall model.  The Applicability can wait
until the end.

Thanks,
Alia

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 18 May 2016 22:04:58 +0200

> -- resolve technical issues found by recent reviews and the working

technical issues -> technical and editorial issues?

I agree with Alia about "recent" being too specific.

> date. This may include discussion of issues such as the size of the

Too specific.  Please remove this last sentence, or replace it with
multiple items so it's clear it's just an example.  

> once the initial focus on Proposed Standard is met.

Very well put.

> significantly more complex that those currently in Babel are out of

I've already mentioned that this makes me uncomfortable.

-- Juliusz

---

From: Alia Atlas <[email-masked]>
Date: Wed, 18 May 2016 16:24:27 -0400

> we can leave problems for later charter items as we finish what we bite off

The intent is that the WG won't work on sophisticated link metric
algorithms in the first
chartering.  One aspect is that the link metric algorithms can probably be
partitioned
off as something that can feed into different IGPs and not just Babel.
It'll take some
thought to see where the issues are with that.  It's also crawling more
towards
experimental work.

Now, not in scope means that the WG won't accept drafts around it.   There
might be
some discussions on the list or individual drafts but those shouldn't
distract from the
WG's focus and would only be more relevant if and when the time for
rechartering comes
up.

Regards,
Alia

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 May 2016 06:32:56 -0400

Hi Alia and Gabriel,

Thanks for your good inputs.

Attached is an updated draft and a wdiff against the previous version
I sent out.

> measurement.   I think this needs more discussion.

I don't think Babel should be fixed on existing link measurement if
there is some simple improvement and consensus to incorporate it.

Thanks,
Donald

On Wed, May 18, 2016 at 3:41 PM, Alia Atlas <[email-masked]> wrote:
> have a period of 2 weeks for external review - where it is sent to a mailing
> list (called
> Babel.  This Applicability Statement  may include deployment advice and will
> be
> published as an RFC.
>
>>

---

From: Gabriel Kerneis <[email-masked]>
Date: Thu, 19 May 2016 12:54:21 +0200

> Attached is an updated draft and a wdiff against the previous version

This looks good to me, thanks.

Gabriel

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 May 2016 10:01:57 -0700

> On May 19, 2016, at 3:54 AM, Gabriel Kerneis <[email-masked]> wrote:
> 

Fine by me as well.

Bob

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 19 May 2016 19:11:21 +0200

> Fine by me as well.

Yes, thanks.

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Fri, 20 May 2016 09:56:25 +0100

---- On Thu, 19 May 2016 11:32:56 +0100 Donald Eastlake  wrote ---- 
>Attached is an updated draft and a wdiff against the previous version 

To me it looks accomplishable.

-- 
    Denis Ovsienko

---

From: Alia Atlas <[email-masked]>
Date: Mon, 23 May 2016 16:01:17 -0400

Hi Donald,

This looks good to me.  Thanks for your work on it.
I will add it to the next telechat on June 2.

Regards,
Alia

On Thu, May 19, 2016 at 6:32 AM, Donald Eastlake <[email-masked]> wrote:

> mailing
> will

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 31 May 2016 13:48:56 +0000

On 5/23/16, 4:01 PM, "babel on behalf of Alia Atlas" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi!

I'm reviewing the charter for the IESG Telechat this week.  Because the ballot is not yet open, I'm posting comments here.  I'm working off what is posted in the datatracker [1], which I think is the same as the latest discussed on the list.

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...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).

5. What does "multicast aspects of Babel" mean?    (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.

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/charter-ietf-babel/

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 31 May 2016 16:02:07 +0200

"Alvaro Retana (aretana)" <[email-masked]> writes:

> If the intent is to document current implementation experience

I already started a draft on implementation experience:

https://datatracker.ietf.org/doc/draft-hoeiland-joergensen-babel-implementation/

Currently it's just a writeup of my talk at the BoF, but was planning to
revise it and turn it into something slightly more useful if there is
interest in the WG (I already got some pointers to other similar drafts
to use as inspiration).

I seem to have missed that it got demoted to a wiki item in the charter.
If everyone else prefers this in a wiki form, I can certainly contribute
to that, but my own thought was to write it up in draft form...

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 01 Jun 2016 06:41:21 +0200

Hi Alvaro,

> 1. Are there specifics of "earlier reviews" or the "comments presented at the
> BABEL BoF at IETF-95" that should be explicitly called out?

For the potential changes to the protocol, please see my mail of 21 May 2016,
Message-ID <[email-masked]> (my personal list
has grown a little bit since then, mainly thanks to a detailed review by
Alia, to whom thanks).  I'm waiting for people to tell me what I've
missed, then I'll write it up as a wiki page and try to get it discussed
in Berlin.

There's also a growing list of editorial changes.  I hope to clean it up
in time for Berlin, but right now I'm busy with exams and preparing summer
internships.

If that's okay, I'd rather that no specifics be given in the charter, let
the WG decide.  I'm okay with removing the mention from the charter
altogether, as you suggest.

> 5. What does "multicast aspects of Babel" mean? (s/PIM/the PIM WG).

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.

My personal opinion is that I'd love people to experiment with all three
approaches as long as the base spec is not held up by multicast issues.
I don't think it is worth mentioning in the charter, but you're the
professional here.

> 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.

We're already interacting with Homenet (please see
draft-chroboczek-homenet-babel-profile).  We hope to interact with the
source-specific routing work, wherever that happens (it appears to
currently be split between rtgwg and 6man, IMHO with too little
interaction with mptcp).  We'll obviously need to interact with the
security folks at some point.

I have no idea if any of this is worth mentioning in the charter.

Thanks,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 01 Jun 2016 07:21:01 +0200

> to that, but my own thought was to write it up in draft form...

I'd personally be more in favour of a draft, even if it doesn't get promoted.
Wikia volant, scripta manent.

-- Juliusz