Subject: [babel] Revised Babel Charter

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 Jun 2016 12:16:43 -0400

Hi,

Attached is a revision of the Babel Charter which I believe responds
to all the IESG comments except some by Alvaro Retana.

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Jun 2016 20:39:38 +0200

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

Do we really need to specify the technology used for this information?
What about

  "to keep its wiki updated with implementation experience" -> "to
  maintain up-to-date, publicly accessible information about
  implementation experience"

Then the WG can choose whether to do a wiki page, an internet-draft, or
whatever else we find convenient.

-- Juliusz

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Jun 2016 16:39:41 -0400

Hi Donald, Russ, Juliusz, Toke, etc.,

I have read through all the discussion and IESG comments on the charter.
Here is what I have for an updated version.  I do need to get it out for
External
Review soon so that it can come back onto the IESG telechat for final
approval.
The External Review is to give time for comments by those not on the IESG or
WG - and particularly that it goes out to other organizations who might be
interested.  In the case of Babel, that is relevant because of the
potential interaction
with the Broadband Forum on TR-069.

The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ .  I am
including the text below.

=================================================================

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 and security extensions
are described in Experimental Independent Stream RFCs 6126, 7557, and
7298.

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

The Working Group 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 comments. It is not a requirement that
the Babel protocol produced is backwards compatible with RFC 6126.  It
is a requirement that Babel support at least one profile that is
auto-configuring.  Other documents that are relevant to the above work
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. Link metric measurement or
link metric calculation procedures significantly more complex that
those currently in Babel are out of scope.

Work Items:

- Produce a revision of RFC 6126 suitable for publication as a
Proposed Standard
-- incorporate in the revision developments since RFC 6126
-- resolve technical issues found
-- include in the base specification the extensibility work in
RFC 7557
-- support auto-configuration
-- consider any important changes based on experience with Babel to
date.

- Address security needs for BABEL. This may include using the
techniques in RFC 7298, or other alternatives. Security may be
included in the base spec or the base spec may normatively reference a
separate Proposed Standard specification. This is required as part of
moving Babel to Proposed Standard.

- 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. This
YANG data module to be 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.

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

- Coordinate with other Working Groups, such as the HOMENET WG for
likely applicability, the RTGWG and V6OPS WG about Source-Specific
Routing to support IPv6 multihoming, the PIM WG for discussion around
multicast, and the MANET WG for considerations around wireless.

- Liaise as necessary with the Broadband Forum to facilitate use of the
Babel management Information Model for TR-069.

- 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.
This documentation may be on the Working Group's wiki, in
an internet-draft that isn't expected to be published as an RFC, or a
combination.

- As a secondary focus, the Working Group may work on multicast
aspects of Babel.  This may include discussion of any potential issues
for supporting Babel running with PIM-SM in an auto-configuration
profile.  It may include exploring Babel carrying separate metrics for
multicast.  It may even include discussion and consultation with the PIM
WG about Babel providing the ability to build multicast routing
tables.  With AD and WG agreement, once an approach is understood,
then a milestone may be added for an associated document targeted as
Proposed Standard.

- As a secondary focus, the Working Group may work on documents
defining source specific routing extensions for Babel as a way of handling
IPv6 multihoming.

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.

*Proposed Milestones*
DateMilestone
Aug 2017 IESG Submission of Babel Applicability draft
Jul 2017 IESG Submission of Babel Management draft
Jul 2017 IESG Submission of RFC6126bis and potentially companion security
mechanisms draft
Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) draft
Jul 2016 WG adoption of RFC6126bis
Jul 2016 WG adoption of Babel Applicability draft
draft-chroboczek-babel-applicability
<https://datatracker.ietf.org/doc/draft-chroboczek-babel-applicability/>

=================================================================

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Jun 2016 16:40:59 -0400

Incidentally,

https://datatracker.ietf.org/doc/charter-ietf-babel/history/

is very useful for looking at the differences between charters.

Alia

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 5 Jun 2016 23:34:06 -0400

Hi Alia,

This looks good to me. However, the word "even" in the following line reads
a bit odd and I would delete it....

Thanks,
Donald

On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas <[email-masked]> wrote:

>> Jul 2017 IESG Submission of RFC6126bis and potentially companion
>> security mechanisms draft

---

From: Alia Atlas <[email-masked]>
Date: Mon, 6 Jun 2016 09:58:09 -0400

Good point.  I've updated it.
Any other comments or changes before I push the button for external review?

Thanks,
Alia

On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake <[email-masked]> wrote:

> Hi Alia,
>
> This looks good to me. However, the word "even" in the following line
> reads a bit odd and I would delete it....
>
>>> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ .  I
>>> am including the text below.
>>>

---

From: Dave Taht <[email-masked]>
Date: Mon, 6 Jun 2016 12:10:53 -0700

> Any other comments or changes before I push the button for external review?

No objections here, aside from the fact I haven't seen PIM actually work in
years and years...

>>>> Here is what I have for an updated version.  I do need to get it out
>>>> for External
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>
>

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Alia Atlas <[email-masked]>
Date: Mon, 6 Jun 2016 15:20:54 -0400

On Mon, Jun 6, 2016 at 3:10 PM, Dave Taht <[email-masked]> wrote:

> No objections here, aside from the fact I haven't seen PIM actually work
> in years and years...
>

The most recent version - with the clarification around management I
discussed with Benoit and Barbara is at:
https://datatracker.ietf.org/doc/charter-ietf-babel/

As far as PIM, there are a lot of active deployments.  Whether they require
more management than is desirable is an interesting question.  There's
obviously the work in BIER that involves an additional encapsulation.
There's also work in TRILL that uses IS-IS and builds multicast trees.  I
don't have an opinion; I'd like the WG to be able to discuss and determine
what is needed for the real use-cases.  Given that anything you do here
will be backed up by running code and testing it out, I'm comfortable
leaving flexibility for discussion.

Regards,
Alia

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 6 Jun 2016 15:31:21 -0400

This looks good to me.

Margaret

> On Jun 6, 2016, at 3:10 PM, Dave Taht <[email-masked]> wrote:
> 
> 
> 
> No objections here, aside from the fact I haven't seen PIM actually work in years and years...
>  
> Thanks,
> Alia
> 
> This looks good to me. However, the word "even" in the following line reads a bit odd and I would delete it....
> 
> Here is what I have for an updated version.  I do need to get it out for External
> Review soon so that it can come back onto the IESG telechat for final approval.
> interested.  In the case of Babel, that is relevant because of the potential interaction
> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ .  I am including the text below.
> 
> Proposed Milestones
> Date	Milestone
> Jul 2017	IESG Submission of RFC6126bis and potentially companion security mechanisms draft
> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek <[email-masked]> wrote:

---

From: Dave Taht <[email-masked]>
Date: Mon, 6 Jun 2016 12:39:56 -0700

On Mon, Jun 6, 2016 at 12:20 PM, Alia Atlas <[email-masked]> wrote:

> As far as PIM, there are a lot of active deployments.  Whether they
> require more management than is desirable is an interesting question.
> There's obviously the work in BIER that involves an additional
> encapsulation.  There's also work in TRILL that uses IS-IS and builds
> multicast trees.  I don't have an opinion; I'd like the WG to be able to
> discuss and determine what is needed for the real use-cases.  Given that
> anything you do here will be backed up by running code and testing it out,
> I'm comfortable leaving flexibility for discussion.
>

Given that I don't have any hope for improving multicast behavior inside
the current wifi standards, and I don't know where pim would be used inside
the home, I don't care. I can see it being used for multicast tv, but over
wifi it's a lose.

I had made a thrust earlier in these threads for adding into the charter
work to make babel (more generally source specific routing) work well on
common inside-the-home/small business link layers like moca, homeplug, wifi
(802.11, 802.11ad), vpns (more generally, tunnels), and usbnet - as well as
interoperating with pending ones like 6lowpan and 5g, but I seem to be
alone in that.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 6 Jun 2016 15:44:08 -0400

> the home, I don't care. I can see it being used for multicast tv, but over

There is still discussion happening between IEEE and the IETF - primarily I
think in the intarea.  You might take a look there and chat with Suresh
about what's happening.

> interoperating with pending ones like 6lowpan and 5g, but I seem to be

It's true I haven't seen significant interest there.  Getting the basic
protocol done is the first step.  It might help to articulate what the
issues are that you are seeing and what the solutions might look like.  I
know that I haven't been focused in that space and simply don't know.

---

From: Dave Taht <[email-masked]>
Date: Mon, 6 Jun 2016 13:19:28 -0700

On Mon, Jun 6, 2016 at 12:44 PM, Alia Atlas <[email-masked]> wrote:

> There is still discussion happening between IEEE and the IETF - primarily
> I think in the intarea.  You might take a look there and chat with Suresh
> about what's happening.
>

OK.

> know that I haven't been focused in that space and simply don't know.

I have been perhaps too busy fixing wifi to pay attention to the chartering
here. It is ok with me if this stuff remains out of scope for the charter,
but to describe my thinking more fully, as it sort of does affect the
characteristics of the next few billion devices (3 billion wifi last
year)....

...

I basically long ago blurred the distinction between "host" and "router"
years ago. In my world, nearly all hosts are capable of routing, and have 2
or more possible ways to get to each other or to the internet. Bridging
together many of these link layers seems to be a bad idea due to basic
differences in multicast and addressing, but routing less so.

* usbnet: IP over USB has been available since the late 90s, and was, for
example heavily used by linux on the ipaq way back when.

In many of the latest generations of hackerboards and IoT, ethernet is
being dropped and replaced by wifi and usb. On the low end, see the
esp8266, pi zero, etc.

higher end - say on tvs - usb-c has great potential to be a faster
(10gbit!) alternative to local ethernet, with a smaller cable that also
routinely supplies power.

The principal flaw of IP over usb (IMHO) was that neither the client or
host had easy routability, so you were stuck with local connectivity only
between those two devices. You add a routing protocol to the mix, and bang,
any device that supports it, can export IP based services to the rest of
the network [1].

One of the mantras of homenet was "no host changes", which seemed silly
compared to the ease by which babel could be installed and configured (at
least on osx and linux). For 8+ years now I've always been dual connected
over ethernet and wifi, when I got up from my desk, my existing connections
all switched to wifi, when I got back or plugged in elsewhere, they all
migrated back to ethernet eventually.

* HDMI ethernet

HDMI ethernet never took off probably for similar reasons for why usbnet is
not so often used. That said, the raw capability for using it is there, if
only address assignment, routing, and service discovery issues had been
resolved.

* Moca

I see this available in many cable based home gateways (also in gfiber),
bridged, rather than routed. It is usually slower than ethernet by a lot,
as well as flakier, and is an unswitched shared medium much like original
ethernet and present-day wifi. I have no idea how video is shared on top of
it presently.

* Homeplug. (ethernet to wall power) I have seen these heavily used in many
apartments (very common in paris, for example) where the entry point for
access is far from the actual use point, and the wifi spectrum horribly
polluted. It is really flaky and slow, even when compared to Moca - but
still often

I can and do run babel over homeplug, but the multicast behavior is quite
poor in general with more than 2 of them in a home (up to 16 are supported,
and throughput generally much less than 200mbit even on the latest version
of the standards)

* 3-5 G. One primary use for having source specific routing (as well as
multihoming with nat) is the ready availability of a "backup link" - be
that a home router providing two different connections to the internet, or
a handheld with both wifi and 3g access (and some handhelds and laptops are
capable usbnet, and others ethernet)

* 802.11ad has a good feature in that it does not penetrate walls, and thus
you can have a lot of it. It has a bad feature in that it does not
penetrate walls, and you need a lot of it, or some other backhaul (homeplug
or wifi being leading contenders)

* 6lowpan (threads, etc). I honestly don't know a lot about all the
802.11.14 derived standards except that they seem to be inhabiting an
increasingly tiny space vs wifi's ubiquity and devices with increasingly
low power demands, seem to be moving into.

* vpns and tunnels. It is nice to have some means to "choose the right
address" to send though a vpn.

[1] This is for example a wifi+usb gateway running on the 9 dollar "
getchip.com"  device. Same code works on the rpi zero through 3, odroid c2,
etc, and runs at over 90mbit here where the wifi on this board does 20mbit,
tops.

root@chipzilla:~# ip route
default via 172.26.117.50 dev usb0  proto babel onlink
default via 172.26.19.1 dev wlan0  proto static  metric 1024
10.0.0.0/24 via 172.26.117.50 dev usb0  proto babel onlink
73.252.200.0/23 via 172.26.117.50 dev usb0  proto babel onlink
169.254.22.140 via 172.26.117.50 dev usb0  proto babel onlink
172.26.16.0/24 via 172.26.117.50 dev usb0  proto babel onlink
172.26.16.3 via 172.26.117.50 dev usb0  proto babel onlink
172.26.16.5 via 172.26.117.50 dev usb0  proto babel onlink
172.26.17.247 via 172.26.117.50 dev usb0  proto babel onlink
172.26.18.0/24 via 172.26.117.50 dev usb0  proto babel onlink
172.26.18.21 via 172.26.117.50 dev usb0  proto babel onlink
172.26.19.0/24 dev wlan0  proto kernel  scope link  src 172.26.19.23
172.26.64.0/24 via 172.26.117.50 dev usb0  proto babel onlink
172.26.64.5 via 172.26.117.50 dev usb0  proto babel onlink
172.26.128.0/23 via 172.26.117.50 dev usb0  proto babel onlink
172.26.130.0/23 via 172.26.117.50 dev usb0  proto babel onlink
172.26.130.1 via 172.26.117.50 dev usb0  proto babel onlink
192.168.2.0/24 via 172.26.117.50 dev usb0  proto babel onlink

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jun 2016 23:30:14 +0200

> It is ok with me if this stuff remains out of scope for the charter, but
> to describe my thinking more fully, as it sort of does affect the
> characteristics of the next few billion devices

Dave,

Just because they're not in the charter doesn't mean we're not allowed to
work on them.  And I'm sure Alia will help us recharter if we have a good
argument to add new stuff.

> I basically long ago blurred the distinction between "host" and "router" years
> ago. In my world, nearly all hosts are capable of routing, and have 2 or more
> possible ways to get to each other or to the internet.

Yes, i like your work.  However, as I understand it is simply
a consequence of Babel being able to carry host routes and being easy
enough to configure to put it on each device.  Or do you need anything
more from Babel?

> * usbnet: IP over USB

I'm not sure if usbnet needs any support from the routing protocol.  It's
a fast link with low latency and little packet loss, right?  Perhaps
carrier signalling?

> One of the mantras of homenet was "no host changes", which seemed silly

Agreed, but what's done is done -- we failed to convince the WG.  Now is
the time to experiment with host changes.  (As we speak, I've got
a student deploying HNCP on ten routers -- once we have a stable testbed,
we'll be able to experiment with host changes.)

> [1] This is for example a wifi+usb gateway running on the 9 dollar
> "getchip.com" device.

I want one!  Actually, I want twenty.  (Can you get them yet?  How long do
you wait?)

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Mon, 6 Jun 2016 16:29:22 -0700

> enough to configure to put it on each device.  Or do you need anything

World peace?

">> * usbnet: IP over USB
> I'm not sure if usbnet needs any support from the routing protocol.  It's

usbnet tends to come up with a random mac address. You can stablize it
using udev rules.

systemd is (sigh) taking things one step further by creating a random
device name by default, instead of things like usb0, usb1, usb2, etc,
leading to truly "memorable" device names and the style of name chosen
has varied from release to release. For example, until recently, I'd
see usbnet device names generated by systemd like:

enx2a648d5d7941

and just recently it started naming usbnet like

enp0s16u1

I have sometimes thought it would be good (at least on linux) to
either allow device name globbing or monitor /sys/class/net inside of
babel, or to prefer generating the router_id from stablest to least
stable sort of device types. (ethernet, wifi, usbnet)

> a fast link with low latency and little packet loss, right?  Perhaps

Maybe. I'm still looking over the issues I found with routing
asymmetry here: http://blog.cerowrt.org/post/babel_half_fail/

usbnet has worked really well, for me, for over 16 years. I'm bugged
that so few android devices support it out the box.

> we'll be able to experiment with host changes.)

Groovy.

I have not been using hncp as yet except for a brief test here and
there - I have a rant about wanting just *one*
static-unchanging-no-matter-what ipv6 address sitting in my blog's
queue (with tight integration with naming and service discovery).

hncp does seem like "the right thing", but I'm not huge on giving my
lightbulbs global connectivity, and would rather like to ensure
(somehow) certain devices never got anything more robust than a ULA.

> I want one!  Actually, I want twenty.  (Can you get them yet?  How long do

Got mine hand-delivered. :) I think they are ramping up production
now. I'll ask.

There are also a lot of other boards worth looking at - notably the
pi3, but recently this one, also, popped up on my radar.

http://hackerboards.com/open-spec-octa-core-nanopi-m3-sbc-sells-for-35/

the odroid c2, thus far, has been the speed winner for me, but that
lacks wifi, and the usb sticks I've tried thus far were almost
universally miserable. That said, I kind of expect nearly all of the
next generation of hackerboards to include wifi on them.

(I hit reload on hackerboards.com a couple times a week. Just where
things are this year is astonishing, and I kind of expect quad core
boards to drop in cost even more.

*And* I try to remember that the cheap hackerboards appearing
presently tend to be the chips that major manufacturers were shipping
already in their tvs. I am afraid to look up how many crappy, wifi
enabled, tvs shipped last year)

I was always impressed by the build quality of the beaglebones - now
they have a ti wifi chip in them I know nothing about:
http://hackerboards.com/beaglebone-green-wireless-adds-wifi-ble-usbs/

I've also been looking over this one to explore 3g + wifi support.

http://hackerboards.com/open-linux-based-platform-simplifies-wireless-iot/

More choices: http://hackerboards.com/2016-survey-of-open-spec-hacker-friendly-sbcs/

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 07 Jun 2016 01:50:06 +0200

That's really getting off topic for this list -- if anyone wishes to
complain, please do, and we'll move elsewhere.

>> Or do you need anything more from Babel?

> World peace?

Babel, by effectively removing all barriers to communication between
different cultures and races, has caused more and bloodier wars than
anything else in the history of creation.

(And if you miss where the (mis-)quotation is from -- give up your geek card.)

> (somehow) certain devices never got anything more robust than a ULA.

HNCP is pretty flexible.  If your lightbulb is running HNCP, then it can
certainly avoid assigning any global addresses to itself.  If your
lightbulb is not, then you can put it on a link that doesn't announce any
global prefixes and is firewalled away from the Global Internet.

Unfortunately, there's no in-band signalling -- all the routers on the
restricted link must be configured to avoid assigning global prefixes.  If
only one router is mis-configured, you leak.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Mon, 6 Jun 2016 17:05:04 -0700

While I'm mentioning cheap routable devices, I have a couple compute
sticks - where I wish hdmi-ethernet worked - or usbnet:

The previous generation intel ubuntu stick was astonishingly useable
and the wifi was not horrible, and they are down to 58 dollars.

http://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=ubuntu+stick

newer ones have 802.11ac and cost about 148, but amazon only seems to
have windows ones at the moment.

Chromebooks have come a long way, too, and you can get a pretty good
android tablet for under 100. I think getting babel (and hncp) running
on these sorts of devices would be very useful. (I have successfully
worked to get source specific natively supported upstream in the rpi 2
and 3 and odroid c2 thus far)

I am under the impression that there exists a babel port to ios,
somewhere, but their APIs for doing policy routing are different than
anyone elses.

I would very much like to see the ietf, in general, attempt to "close
the loop" by enabling particpants to be able to make new software and
ideas available more quickly across the largest parts of the software
ecosystem. (or participants going the extra mile to test and build
stuff on the largest parts of the ecosystem).

---

From: "Russ White" <[email-masked]>
Date: Tue, 7 Jun 2016 06:29:46 -0400

This looks great to me -- thanks, Alia!

:-)

Russ

> -----Original Message-----
> From: babel [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Friday, June 3, 2016 4:40 PM
> To: Juliusz Chroboczek <[email-masked]>
> Cc: Donald Eastlake <[email-masked]>; [email-masked]; Babel at
> IETF <[email-masked]>
> Subject: Re: [babel] Revised Babel Charter
> 
> External Review soon so that it can come back onto the IESG telechat for final
> approval.
> interested.  In the case of Babel, that is relevant because of the potential
> interaction with the Broadband Forum on TR-069.
> 
> 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 and security extensions are described in Experimental
> Independent Stream RFCs 6126, 7557, and 7298.
> 
> 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).
> 
> The Working Group 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 comments. It is not a requirement that the Babel protocol
> produced is backwards compatible with RFC 6126.  It is a requirement that
> Babel support at least one profile that is auto-configuring.  Other documents
> that are relevant to the above work 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. Link metric
> measurement or link metric calculation procedures significantly more
> complex that those currently in Babel are out of scope.
> 
> Work Items:
> 
> - Produce a revision of RFC 6126 suitable for publication as a Proposed
> Standard
> -- include in the base specification the extensibility work in RFC 7557
> -- consider any important changes based on experience with Babel to date.
> 
> - Address security needs for BABEL. This may include using the techniques in
> RFC 7298, or other alternatives. Security may be included in the base spec or
> the base spec may normatively reference a separate Proposed Standard
> specification. This is required as part of moving Babel to Proposed Standard.
> 
> - 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. This YANG data
> module to be 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.
> 
> - 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.
> 
> - Coordinate with other Working Groups, such as the HOMENET WG for likely
> applicability, the RTGWG and V6OPS WG about Source-Specific Routing to
> support IPv6 multihoming, the PIM WG for discussion around multicast, and
> the MANET WG for considerations around wireless.
> 
> - Liaise as necessary with the Broadband Forum to facilitate use of the Babel
> management Information Model for TR-069.
> 
> This documentation may be on the Working Group's wiki, in an internet-draft
> that isn't expected to be published as an RFC, or a combination.
> 
> - As a secondary focus, the Working Group may work on multicast aspects of
> Babel.  This may include discussion of any potential issues for supporting
> Babel running with PIM-SM in an auto-configuration profile.  It may include
> exploring Babel carrying separate metrics for multicast.  It may even include
> discussion and consultation with the PIM WG about Babel providing the
> ability to build multicast routing tables.  With AD and WG agreement, once an
> approach is understood, then a milestone may be added for an associated
> document targeted as Proposed Standard.
> 
> - As a secondary focus, the Working Group may work on documents defining
> source specific routing extensions for Babel as a way of handling
> IPv6 multihoming.
> 
> 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.
> 
> Proposed Milestones
> 
> Date	Milestone
> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek <[email-masked]
> diderot.fr <mailto:[email-masked]> >
> wrote:
> 
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 7 Jun 2016 13:11:55 -0400

Looks good to me.

Thanks,
Donald

On Tue, Jun 7, 2016 at 6:29 AM, Russ White <[email-masked]> wrote:

> potential
> the
> classical,
> Proposed
> techniques in
> Applicability