From nobody Tue May 10 09:08:46 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB6C12D515 for ; Tue, 10 May 2016 09:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgttWQUWpVNg for ; Tue, 10 May 2016 09:08:43 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0890F12D51C for ; Tue, 10 May 2016 09:08:43 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id x201so23275941oif.3 for ; Tue, 10 May 2016 09:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=tDcGCz5B4YXq9NEBiC6b4xdi6FLBoZ68BYsem6Wb+mA=; b=gs7kh2hXsn4xf9UcjpDNnG3ZV63HXdW1kuNWhU9lMzWTdYdcuS2GqpbYFRR8zSlmvi 3vC+y0mhuOy96Rmd9bR6hyVmXzz4iHbKbiffMwURr0mT1WXmY1SqYZhKlPZHaJF11yWi BTK9MN1CxEPmsHCROZpN8EqvIxf05DmvKEOo3nOhxLvbnILzGNmj2wGmanLSdKWEO7+W ngNzUjfhh38msqU8AXxp+e1x2CX4doUaCjoqzCsyMIMGSkC8eOjaIRvoSnk7TdyslWYg PA+HxSwkkO8+Hvr2Bvafm96g6UC0JA8aJxlxL3R7BKCpXYI1iTbRV+i+uWe2lLsaVg4r sKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tDcGCz5B4YXq9NEBiC6b4xdi6FLBoZ68BYsem6Wb+mA=; b=YwCFx/9iXdeBB8gD6PpuiBxMWpEfYMGfFqUgJkImSdjkOn+JyOdHCkRxkAFdEYsmPk 2kZSurzum3wE8pbxfmUnCkW7cAqEZi5AF3Cl9+h221RqXe9G36oJUbynipORbYY+H2yE 4uzSweFoJRC4XfJIRDEb4n4dFA1U1hZ5e4rJlYCc0my/EqAAiZXuqo61f3q5yAMIiPkg +hnKdoQqpzOH6OEqInre9NypUx0s107q6aoeBPpYvavLMy77vSH3hEm16q8muju6HNHM L4w3B5VQSWAr/5vNj0IqUPzH7zKbKfJVAISpIToeAWtZ3geeBc3dWrwUHHwCQiLztJul thEg== X-Gm-Message-State: AOPr4FXv/+VxNuTWs7PxX1UZoPjpXpHLuFVC2bWCIKYNofCdlBrzt9jrGBc7mz/vOxymh0sZozro9VJQB+HjGg== X-Received: by 10.157.6.166 with SMTP id 35mr2820220otx.181.1462896522228; Tue, 10 May 2016 09:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Tue, 10 May 2016 09:08:27 -0700 (PDT) From: Donald Eastlake Date: Tue, 10 May 2016 12:08:27 -0400 Message-ID: To: babel@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 16:08:45 -0000 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 d3e3e3@gmail.com 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 nobody Tue May 10 09:38:51 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3F612D766 for ; Tue, 10 May 2016 09:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vI4HZujdcIR for ; Tue, 10 May 2016 09:38:47 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB72612D75F for ; Tue, 10 May 2016 09:38:46 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id k142so24829256oib.1 for ; Tue, 10 May 2016 09:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FH1Y8oOJ161sb8IfntIodjYqaKFbi/+9klz9vr8NRkA=; b=X8AFfCsRB6+DQQ4HNs5K4h6MM9VtNbbQHkQfmWKct4ChWkGF56TNV4NRZONY74ZjbM dtje7aba8KXHbObz9RZyMnUBy4v8YmtJzP5goWVvLodiBt2w6Cbh6OcVb57UNKq7sIWJ iMgDs0E6p4GLMWqQ1FawhBJ7zt7Rl5W4W4ZMJ/pApappgt5/tBZNnS0h1uN4fEnFS2vH rGD7SgZ3BSzRDus2spB5W469RmUvhkikd1YAvheyoVpghH7UwPTy2As/JMUH1BNskd4C UlNHMy7kXIlQqfrcNFAWaf0ZJS+afM3Yez9f/Yx6HWSfo/NTffz4AtaGKz6XOjwoTBBj ifcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FH1Y8oOJ161sb8IfntIodjYqaKFbi/+9klz9vr8NRkA=; b=gaJt36Zrw5h0tZLRRQwG/gM1+RUrNFOQ5vuGvKl67+nLdxcWQ6jJHIZhSeMaQ7Y+M1 2uf6AChJEXux2cxwcBpWv2vSpkvRUH0G4Bftt3d+Uig454zA9oX0vj5nsA3k0FE6HjxD G1se+A1RzUnfg5QbD2h1EO20+lza0NJv4DNcUOhq4m/qz4xujTrbfU9zizYgLrVJZgVc i0ZjcQvpJodf92NIAzycdze3GHzGrUgIfd/WeAMW6OlHpCnQ6Vid1fHq/y3twJkMamOo ZVnkdmOfrbrrQmkEp7eGTcPmiFAWQ0LkGzs/fnSj5DEwZeuklA3ti6re4UXeoM37+zoQ CBCQ== X-Gm-Message-State: AOPr4FXepvEdx7JnddtqN31gNMjO8zUAFh59/r8E0KehDlAujEGDcJVLgBdVB2syOGi2IpHykJ6a9okVh9R5/Q== MIME-Version: 1.0 X-Received: by 10.202.108.144 with SMTP id h138mr18334424oic.2.1462898326209; Tue, 10 May 2016 09:38:46 -0700 (PDT) Received: by 10.60.118.39 with HTTP; Tue, 10 May 2016 09:38:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 May 2016 12:38:46 -0400 Message-ID: From: Alia Atlas To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a1142e94013915405327f8fbf Archived-At: Cc: Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 16:38:49 -0000 --001a1142e94013915405327f8fbf Content-Type: text/plain; charset=UTF-8 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 wrote: > 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 > d3e3e3@gmail.com > > > 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. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --001a1142e94013915405327f8fbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Donald & Russ,

Thank you for upd= ating the proposed charter.

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

Do you consider that t= he need for a common path cost computation is included
in the tex= t?

For the management aspects, I believe that Barb= ara 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 heari= ng or putting some dates in for the milestones.=C2=A0 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, Do= nald Eastlake <d3e3e3@gmail.com> wrote:
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.<= br> - 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com


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.=C2=A0 The core of the Babel protocol is described in
Experimental Independent Stream RFCs 6126 and 7557, with RFC 7298
describing security extensions.=C2=A0 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=C2=A0 Milestone

=C2=A0TBD=C2=A0 WG adoption of Babel Applicability draft.

=C2=A0TBD=C2=A0 WG adoption of rfc6126bis draft.

=C2=A0TBD=C2=A0 WG adoption of Babel management (probably Yang) draft.

=C2=A0TBD=C2=A0 Submission of Babel Applicability draft to the IESG as
=C2=A0 =C2=A0 =C2=A0 Informational.

=C2=A0TBD=C2=A0 Submission of rfc6126bis draft to the IESG as Proposed Stan= dard.

=C2=A0TBD=C2=A0 Submission of Babel management draft to IESG as Proposed =C2=A0 =C2=A0 =C2=A0 Standard.

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

--001a1142e94013915405327f8fbf-- From nobody Tue May 10 09:48:40 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094EF12D789 for ; Tue, 10 May 2016 09:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjScVPToBoyt for ; Tue, 10 May 2016 09:48:37 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76FC12D7A4 for ; Tue, 10 May 2016 09:47:40 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x201so25197528oif.3 for ; Tue, 10 May 2016 09:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rjkS9buQC4vuptX8DHI5Gptauu9ZynD/CMUdWpfiCEo=; b=HbruqzvWu0q4QqRlXCTCXtukM5zjptkRwTQxUypMtENTvFhqenQ86gnrD/CPbzSPvv dYPT1sf2LyzF9/aKleRH7tc+T/mLlAQLrBAlrT3LtmKIfHPWh9kBhuywmxhg+5zhvrHu ifVX+FnZp/0ACz4U6wZRkZ2rm9m/5ygb5k4NsvzWWVf/aXTINxXJ9gYJjUf6yKWGLNJe cHkfQThRw0RLMXB5IFiOyzpFLAJ+Z9NZqw3NNj+pbJXk/cwOHu4//R44D4DEEAMmlasF Qt6Wk4TLPzvhmIksmplvpoALD+LgnpGEv5LkudYIy8nKpR7+2uv7smpSf8Fc93maJpd0 IaWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rjkS9buQC4vuptX8DHI5Gptauu9ZynD/CMUdWpfiCEo=; b=TY4wk0fuclABa970CBWA9nHTs4Pkp1Gz4CI6Xz7ETSdkwMbpZvwNNWpqNUDOBPPTkh mo8Nmdgot5aIoEy65OFkuxgfx8c8OiDMsfCs7qTUuxzxrv7qV59C1jZSvqQspOmyBYdW A2zLsig+2xehzze4goPiJq2TZIG+niIxN0LnEDPb+SlKeQVzhkgznVOjkEKdB2xCYXvb dMH5kaMBbTkDQVlnp4pkVfi73N31aovB+3+vAniWYP/dDvjjOk+vxvG+Q28lBBJchZiC 2j5AELrKYvhDZE5/vKvHcunwzFA8FShbRk2Oaph6kjZFdF0ngkltAYF9kJeUuWAFM5iv YEDA== X-Gm-Message-State: AOPr4FVmzf2L7NCad90eVx2KrDBxgaiPsmipqPuOYyIfJKpte697yGJPg/pPZGz5cxfgPf2C3ovUX0TnMMPYhg== MIME-Version: 1.0 X-Received: by 10.202.44.19 with SMTP id s19mr18128812ois.78.1462898860064; Tue, 10 May 2016 09:47:40 -0700 (PDT) Received: by 10.60.118.39 with HTTP; Tue, 10 May 2016 09:47:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 May 2016 12:47:39 -0400 Message-ID: From: Alia Atlas To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a1137baaee58b2205327fae61 Archived-At: Cc: Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 16:48:39 -0000 --001a1137baaee58b2205327fae61 Content-Type: text/plain; charset=UTF-8 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 On Tue, May 10, 2016 at 12:38 PM, Alia Atlas wrote: > 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 > wrote: > >> 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 >> d3e3e3@gmail.com >> >> >> 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. >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >> > > --001a1137baaee58b2205327fae61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am also a bit concerned that we discuss the assumptions = of architecture and protocols around Babel.=C2=A0 For instance, most IGPs v= erify that packets of max MTU can be sent and received to be confident in t= he link layer.=C2=A0 It may just be a discussion in the doc about running B= FD or the like or it might be more complex.

Thoughts?
Alia

On Tue, May 10, 2016 at 12:38 PM, Alia Atlas <<= a href=3D"mailto:akatlas@gmail.com" target=3D"_blank">akatlas@gmail.com= > wrote:
Hi Do= nald & Russ,

Thank you for updating the proposed cha= rter.

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 cha= rter.

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

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

I would also be interested in hearing or putting some dat= es in for the milestones.=C2=A0 I'd like this to be a WG that moves ver= y quickly to get the compact amount of work done.

= Thanks,
Alia
<= div class=3D"gmail_extra">
On Tue, May 10, 20= 16 at 12:08 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
=
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.<= br> - 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.co= m


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.=C2=A0 The core of the Babel protocol is described in
Experimental Independent Stream RFCs 6126 and 7557, with RFC 7298
describing security extensions.=C2=A0 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=C2=A0 Milestone

=C2=A0TBD=C2=A0 WG adoption of Babel Applicability draft.

=C2=A0TBD=C2=A0 WG adoption of rfc6126bis draft.

=C2=A0TBD=C2=A0 WG adoption of Babel management (probably Yang) draft.

=C2=A0TBD=C2=A0 Submission of Babel Applicability draft to the IESG as
=C2=A0 =C2=A0 =C2=A0 Informational.

=C2=A0TBD=C2=A0 Submission of rfc6126bis draft to the IESG as Proposed Stan= dard.

=C2=A0TBD=C2=A0 Submission of Babel management draft to IESG as Proposed =C2=A0 =C2=A0 =C2=A0 Standard.

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel


--001a1137baaee58b2205327fae61-- From nobody Tue May 10 11:14:54 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995FC12D593 for ; Tue, 10 May 2016 11:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TMpRJW-YPII for ; Tue, 10 May 2016 11:14:51 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7BB12D58D for ; Tue, 10 May 2016 11:14:49 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4AIElxK022391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 May 2016 20:14:47 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4AIEkgf010332; Tue, 10 May 2016 20:14:46 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C61CD62059; Tue, 10 May 2016 20:14:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id SaMxz-OGGiII; Tue, 10 May 2016 20:14:45 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E145C62002; Tue, 10 May 2016 20:14:43 +0200 (CEST) Date: Tue, 10 May 2016 20:14:49 +0200 Message-ID: <871t59bx0m.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Donald Eastlake In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 10 May 2016 20:14:47 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 10 May 2016 20:14:47 +0200 (CEST) X-Miltered: at korolev with ID 57322517.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57322516.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57322517.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57322516.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 57322517.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57322516.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:14:53 -0000 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 nobody Tue May 10 11:22:30 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B134612D7E7 for ; Tue, 10 May 2016 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdvqPF2ba7DH for ; Tue, 10 May 2016 11:22:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9DF12D576 for ; Tue, 10 May 2016 11:22:26 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4AIMPtJ025088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 May 2016 20:22:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4AIMPYd012432; Tue, 10 May 2016 20:22:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1996562064; Tue, 10 May 2016 20:22:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1b6Y9xGz-4mn; Tue, 10 May 2016 20:22:23 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 407CD62060; Tue, 10 May 2016 20:22:23 +0200 (CEST) Date: Tue, 10 May 2016 20:22:28 +0200 Message-ID: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 10 May 2016 20:22:25 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 10 May 2016 20:22:25 +0200 (CEST) X-Miltered: at korolev with ID 573226E1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 573226E1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573226E1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 573226E1.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573226E1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 573226E1.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Donald Eastlake , Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:22:28 -0000 > 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. 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? > 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. 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 nobody Tue May 10 11:24:39 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF8B12D7F3 for ; Tue, 10 May 2016 11:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn6FP9Q9GWUd for ; Tue, 10 May 2016 11:24:36 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A7A12D7F1 for ; Tue, 10 May 2016 11:24:35 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4AIOYL9025804; Tue, 10 May 2016 20:24:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 142226205E; Tue, 10 May 2016 20:24:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id PxI_NdJZNlYk; Tue, 10 May 2016 20:24:32 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7AF4561FFA; Tue, 10 May 2016 20:24:32 +0200 (CEST) Date: Tue, 10 May 2016 20:24:38 +0200 Message-ID: <87y47hahzt.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 10 May 2016 20:24:34 +0200 (CEST) X-Miltered: at korolev with ID 57322762.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57322762.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 57322762.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: [babel] Checking MTU [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 18:24:38 -0000 > 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 nobody Tue May 10 18:49:02 2016 Return-Path: <7riw77@gmail.com> X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B4D12D0A7 for ; Tue, 10 May 2016 18:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcf-UNSynkDp for ; Tue, 10 May 2016 18:48:59 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9011200A0 for ; Tue, 10 May 2016 18:48:59 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id o66so33264184ywc.3 for ; Tue, 10 May 2016 18:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=7KyTAE36i2WdEPNqJcdjz6/S1ejKYIbd1uMcTGUiWt0=; b=AH/Xd08m8F3qSbcU1TH91V6gPe3j3hAUeudkaK6IE54+ZF9I1LUz5dF2dErPXaHSx5 WsrJIAR6MYmFxf1R3gBIO51bGl0nZsbNE5Og9wiyI1CwKQiWUHA0LAyXnCB9UhS+ua2+ ugBdK4cGfFD7V6RKQZM8VMDCrgy5nd55pjKOm8uirlaE5un2vc883knnaPbmStViievB O+1G+aHiMq7j1LUEBKnK5xXB/rnPc9D+XX7AqzfKNKCfXwcFuGheDoiXEZKPjNQdkTbE /CWrIYwtthDhIGXlCrGQkpgKWnc59m9TtZTE4f8jYTIeOry0J06qGD9jgRZChqZEJMVL YstQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=7KyTAE36i2WdEPNqJcdjz6/S1ejKYIbd1uMcTGUiWt0=; b=mW/t+oJe1e2I20IhrRLeNge/LmGgEHhWgBOySTkSN6LKoZolPzcE6IKuKfIXGWrwYH X6YYwcC4Lh6UDkZyCn2Cz6Hv6wUALhoW8HlvqbZSnJRv0AkZb/YSX1BJrrns5H6+I/UI okraFWj6AH5afea3H8NATEc2HAHDBDmbayX+kGaMIY4JOAIeylwIHHOtvtV+DaWDF2sv tKKDtJeb/QICQRztE4bY4YEsX1gy1qJA6TOfzy1P9u9PRIcYEvNGRVkIk3kzui2meyLa b4awzOCRm77DLVImzI6qEDRuDmDYTpco7FRuxJBub0a7H313dYZ68Ft439rcFpsAYi2d Ezxw== X-Gm-Message-State: AOPr4FWZJ4QURraFAoElOxOebWY5/opecP3TaUVr/EZtSyrgPjbHwnJuDljQo2HDlK3JQA== X-Received: by 10.13.205.69 with SMTP id p66mr299526ywd.255.1462931338748; Tue, 10 May 2016 18:48:58 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id w185sm2909620ywe.1.2016.05.10.18.48.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 May 2016 18:48:58 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Juliusz Chroboczek'" , "'Alia Atlas'" References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> Date: Tue, 10 May 2016 21:48:52 -0400 Message-ID: <04e901d1ab27$45831db0$d0895910$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 thread-index: AQFYoAHWEHtoxVT8DhtHOznazgjQXwJ4U7ZaAUvKXsyghupckA== Content-Language: en-us Archived-At: Cc: 'Donald Eastlake' , 'Babel at IETF' Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 01:49:01 -0000 > > 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. > > 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? 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. > > Do you consider that the need for a common path cost computation is > > included in the text? > > Could you please explain? There probably needs to be a "must implement" metric/calculation mechanism. > 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? 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 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. I would suggest we give ourselves two IETFs to get these bits done, or one interim and try to adopt at the next IETF. > - 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. 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 > Standard. 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. > This can be done within the current protocol, but AFAIK none of the existing implementations do this. Perhaps it deserves an informational appendix? 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 nobody Wed May 11 07:11:45 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E799112D6C3 for ; Wed, 11 May 2016 07:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1sDLjFFPHgV for ; Wed, 11 May 2016 07:11:37 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7578412D6D9 for ; Wed, 11 May 2016 07:11:29 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4BEBRoi019085; Wed, 11 May 2016 16:11:27 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6BB2A61F9A; Wed, 11 May 2016 16:11:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id I7MbtZVm4QkN; Wed, 11 May 2016 16:11:25 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5FFFA61FAD; Wed, 11 May 2016 16:11:25 +0200 (CEST) Date: Wed, 11 May 2016 16:11:31 +0200 Message-ID: <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Russ White" <7riw77@gmail.com> In-Reply-To: <04e901d1ab27$45831db0$d0895910$@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 11 May 2016 16:11:27 +0200 (CEST) X-Miltered: at korolev with ID 57333D8F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57333D8F.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 57333D8F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: 'Donald Eastlake' , 'Babel at IETF' , 'Alia Atlas' Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 14:11:44 -0000 Hi Russ, >>> 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. >> 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? > 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. You're positive that we can adopt a draft even if it's outside the charter? Alia, perhaps you could comment? >>> Do you consider that the need for a common path cost computation is >>> included in the text? >> Could you please explain? > 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? > 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. 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? > 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. 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.) > 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. 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 nobody Wed May 11 08:23:49 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5138F12DB40 for ; Wed, 11 May 2016 08:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAY125yw53SW for ; Wed, 11 May 2016 08:23:46 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79E712B068 for ; Wed, 11 May 2016 08:23:45 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j74so45744691ywg.1 for ; Wed, 11 May 2016 08:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=irUi4k8lh8fNWGgBZ8//kCqYCGy0wqW5v6KzwPijxo8=; b=UfEOSWuXvR+pZfX7End68o2Mu9JMZq2d18IScYBkPUaFm9gBWYNd2iPxkKkveFhDPA SAaEq0iPwhpeg82B0NeOKqpfcPxohMUeQIq3lM3+8+VSmspeykNJPpkJ421o+rhNupGs O0NqdqqUV9uJD7xeXwH0j/Ht/eePqkq2Tg8n+BTyKiKnoZWeWSylvc+FXx7hOvEC5CP+ Dc5TLybrdDiiYVv+cc6AV0sSokEPQUtB/Yh9M0EZ7YmOkKSVR2D6KM7hUFHQSdvLB9gp GrV5kn+H0Ldi5z4PLNw86+514HnkYY1RkLkfmctBMGtW/Ouz9eXhQUWWrWpPnMHGPAFD yF5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=irUi4k8lh8fNWGgBZ8//kCqYCGy0wqW5v6KzwPijxo8=; b=Yb/8Q2yv1FL6OMg9rxS42DEjSYuSt9L6YxnKDG4Ol4cVDM8gShsqTlkMq2XFA8Serm XZxOslAA7LlPYAkTw4t8A0SOW9Y9vUb2Ct0ake+cnn9l+M5jG2yUnOcSOmNi0KLEqqGP osgvOLd5O3Xq+9vV7+4oitwbrRTVlJzZCGRb+tHPOj05qphfnBLfUlvwI++wwofzDKzs 4kBRCqjAbnHYUum0Bs5r7rMBChRVWOcj4n5F5gJ5gaV6MOVIo+Dm28QsxyTK4Caj4BqE lX/4gAfe7B6IF2YpJpEZvDSax/Cmba9bQDz5shSuZu0GFJDby+uCqXsEqyTn5K82Le+1 f5NA== X-Gm-Message-State: AOPr4FXkod+CuVy6fNkdWwYkBjT5XxGn9OE8afOlVSXdKaFgTPShg/Lu8B0YtX4pErTjLw== X-Received: by 10.37.230.197 with SMTP id d188mr1720463ybh.128.1462980225067; Wed, 11 May 2016 08:23:45 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:9410:fbb4:f5e9:d4d8? ([2601:647:4d00:abf0:9410:fbb4:f5e9:d4d8]) by smtp.gmail.com with ESMTPSA id z9sm4454419ywz.11.2016.05.11.08.23.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 May 2016 08:23:43 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_22B61ACB-2F0E-426B-AADE-BCE375218D63"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 11 May 2016 08:23:39 -0700 Message-Id: <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Donald Eastlake , Bob Hinden , Babel at IETF , Russ White <7riw77@gmail.com>, Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:23:48 -0000 --Apple-Mail=_22B61ACB-2F0E-426B-AADE-BCE375218D63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Juliusz, inline > On May 11, 2016, at 7:11 AM, Juliusz Chroboczek = wrote: >=20 > Hi Russ, >=20 >>>> 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. >=20 >>> 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? >=20 >> 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. >=20 > You're positive that we can adopt a draft even if it's outside the = charter? > Alia, perhaps you could comment? In my experience, as long as it=E2=80=99s 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. >=20 >>>> Do you consider that the need for a common path cost computation is >>>> included in the text? >=20 >>> Could you please explain? >=20 >> There probably needs to be a "must implement" metric/calculation = mechanism. >=20 > 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". >=20 >>> 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? >=20 >> 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. >=20 > Again -- are you positive that we can adopt a draft even if it's = outside > the charter? >=20 >>> [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? >=20 >> 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. >=20 > 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.) >=20 >> 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. >=20 > I'd much rather draw people to the mailing list, but yeah, active = drafts > should have their xml easily available somewhere. >=20 >> Folks who've worked mostly on the open source side might be more >> comfortable tracking comments through a git repository (?). >=20 > 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. >=20 > (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.) 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=E2=80=99s an important part of the = standards process. Thanks, Bob --Apple-Mail=_22B61ACB-2F0E-426B-AADE-BCE375218D63 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXM058AAoJEK7rdBF357uoKQYIALT1/SRtwTL6It1qvw1kXYl1 V+6E9oBsQ97aLTfR7RiWDqLSybCBb62CtSNojmgKOvbzhm6bGGezCi4rKMOVpO1q 1GuBGU+hAWkAX5EyfYmnaVmQSof25MH5FQ3Nj6eYiHfQ1WI7Hh1+z+xrXnXzkCtx JknXTBKhgCdGKbEdMx7necFI08NjUVNxHtTLVMedZHxihZuKuKuuebtOyzy9zeBT R/9KWwWu4YEPGN18ZMwUphLKvLOn4I/rn0ePm1j1hHhkgHdBVK4vlu1N/JrJpG4L QVREP7rXCPjGS97rfVtu2O+ofVZu4IYPwprrOkRhSkBuPfBM9/BKu064thRbEEo= =eFmq -----END PGP SIGNATURE----- --Apple-Mail=_22B61ACB-2F0E-426B-AADE-BCE375218D63-- From nobody Wed May 11 08:31:59 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8012D1A8 for ; Wed, 11 May 2016 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hri7_B-U_FI6 for ; Wed, 11 May 2016 08:31:57 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2056112D142 for ; Wed, 11 May 2016 08:31:56 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4BFVt6Z001203; Wed, 11 May 2016 17:31:55 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id F3B7D61FBC; Wed, 11 May 2016 17:31:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id e2S_s1U30050; Wed, 11 May 2016 17:31:53 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3640D61FA5; Wed, 11 May 2016 17:31:53 +0200 (CEST) Date: Wed, 11 May 2016 17:31:59 +0200 Message-ID: <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Bob Hinden In-Reply-To: <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 11 May 2016 17:31:55 +0200 (CEST) X-Miltered: at korolev with ID 5733506B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5733506B.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5733506B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Donald Eastlake , Babel at IETF , Russ White <7riw77@gmail.com>, Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:31:59 -0000 > 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 nobody Wed May 11 09:48:02 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE0012D11F for ; Wed, 11 May 2016 09:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCWC-lhYQ_H9 for ; Wed, 11 May 2016 09:48:00 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FEF12D509 for ; Wed, 11 May 2016 09:47:59 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id r5so20188755pag.1 for ; Wed, 11 May 2016 09:47:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2wlNgBWjbKGFDI0hXOZ9YATFUC1qYDQXK56NVheUKDA=; b=KlbwCA9JKbeT+rJJwYYq4GCKJ9BqOh9Vo4lGP8XFyLYekMNwy6lwdfNXi2bBHJWxyF iLLZJkPUOvYCTgKX47WDRkyAq3HdAUo+zGxqZe2vWmPz86e+A1G/08+60uPnRmJyM74Q B8cZH/P6X5ZrrUlMRrLRzeYBDDg3oDpuQpmAf8UCAWl6Kh96ypPs1tB/bkpUzrUoHL5M sla1FnmOZ7J0cHzYLYGpSF93KkD9vPToXBUn0jBODCt/XlG4cNwoBaL3uW29GK483LZY SQkmoaX6jFwH3N5FJBwgWWLwJ8dmkazE8/Q9sIQEhITjiuKrKilcF5Z4rF3ba0zqLKVj 9ygw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2wlNgBWjbKGFDI0hXOZ9YATFUC1qYDQXK56NVheUKDA=; b=kxsVW9xP90aI2HPlvXSNwO4v4UVlA7CtoUXJk7lNtcuI8WPsrWs4VbXtJoTJOCecCl z8Uu8mTbTpUsYOhwczXZ6Z1icuE1mWxF2Vl2gDZNGhot3ranr1e36GWAO90bZoV3SMpr TZRvAN0+Lon2t65AOHjJHs2pCDW9vvYvuPb12b/NZWtq28QQz6T8XWimR11HD/wciAG8 vFR9Gnxhhd/6vVtFbB4uYVS+n0tGapXupMSs66Yxo8Bu4c8w0fVpapvJARqoJ1ihvHwi VUZaBqnh6o95ZAN/bb+bl1zpExLtKoTFaDurtIdMO1zrLAoDkyAnQbOxt1bHYpx0f5FM 2EqQ== X-Gm-Message-State: AOPr4FUOJRmiWQaiZhiWvJ5TB7arLq3CMXIFL+lbfhILA2wtBxVtoeGOquzuBvBxydvfvw== X-Received: by 10.66.43.241 with SMTP id z17mr6519282pal.18.1462985278615; Wed, 11 May 2016 09:47:58 -0700 (PDT) Received: from [192.168.1.40] (c-73-231-87-96.hsd1.ca.comcast.net. [73.231.87.96]) by smtp.gmail.com with ESMTPSA id f16sm13416099pfj.71.2016.05.11.09.47.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 09:47:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dorothy Gellert In-Reply-To: <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> Date: Wed, 11 May 2016 09:47:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CDD94ED-0FA8-4538-8D0A-613C233D14D1@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Donald Eastlake , Alia Atlas , Russ White <7riw77@gmail.com>, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 16:48:01 -0000 +1 > On May 11, 2016, at 8:23 AM, Bob Hinden wrote: >=20 > Juliusz, >=20 > inline >=20 >> On May 11, 2016, at 7:11 AM, Juliusz Chroboczek = wrote: >>=20 >> Hi Russ, >>=20 >>>>> 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. >>=20 >>>> 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? >>=20 >>> 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. >>=20 >> You're positive that we can adopt a draft even if it's outside the = charter? >> Alia, perhaps you could comment? >=20 >=20 > In my experience, as long as it=E2=80=99s 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. >=20 >>=20 >>>>> Do you consider that the need for a common path cost computation = is >>>>> included in the text? >>=20 >>>> Could you please explain? >>=20 >>> There probably needs to be a "must implement" metric/calculation = mechanism. >>=20 >> 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". >>=20 >>>> 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? >>=20 >>> 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. >>=20 >> Again -- are you positive that we can adopt a draft even if it's = outside >> the charter? >>=20 >>>> [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? >>=20 >>> 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. >>=20 >> 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.) >>=20 >>> 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. >>=20 >> I'd much rather draw people to the mailing list, but yeah, active = drafts >> should have their xml easily available somewhere. >>=20 >>> Folks who've worked mostly on the open source side might be more >>> comfortable tracking comments through a git repository (?). >>=20 >> 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. >>=20 >> (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.) >=20 > 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=E2=80=99s an important part of = the standards process. >=20 > Thanks, > Bob >=20 >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Thu May 12 04:40:35 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFB512B01D for ; Thu, 12 May 2016 04:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLhHlmQPkTOW for ; Thu, 12 May 2016 04:40:27 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0691312D66A for ; Thu, 12 May 2016 04:40:26 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v145so114580468oie.0 for ; Thu, 12 May 2016 04:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pdj5GRViCiehmQ3X2EKzVHIqeQhbAvY3xutJlBtJhLk=; b=nUFn/gIk8QCrhgp8gW8kMrrXPxoO/j4xfjBKcVYacZwnr9z2uUeZmzU0gwgAqem6/7 bKIkiGM6bYEPXIgGSPu0XLuyG9aiyR2G1X+7/435ViAuhhAw7uKFMvAjwDFg6kyWtQ1H GupfeQfPo68EyVCb03cz2FKHnQn/b2aLnAyI6virFVBvpA+rJ+qyj5CC9oJXv8WIXYjM Hn/fPXZ2MJSHWBH/chJpbGTua405rnvckrwEkSvF9eOCceRUfBQWl4/U4O2dd0s050oa uKBmmxbcsrdKCqKJEFKVra8vGt1L3lREQ6Z7N+uUu7Jk3+Iuypdxd2lgCEh0coyr/ckM JSNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pdj5GRViCiehmQ3X2EKzVHIqeQhbAvY3xutJlBtJhLk=; b=YbFYQK0ja7zO07D5+ySnUUXR/VgTHXdKJRYmkEe23ZK+rCXqvFzOm1Z9M24xwkA+9U 1CmYwuKF35IPtnab4WKKbfUrh+hJe/Ylutg8nag1A+YdtBlnRUNh7MaJDJ01LXjbcbqX U9gLdgDEUmWuOr60puW+Wh8Q7rOlqwTBLmdIEVavqCyRhRDnKdLtOLSozatYomv8GZjp Du64AFAFF+Uv7qs+egRFh4QvI+kr6pvFOy/LCgmSNnN2XX/yDL7i5XBYUX0ldk51GsQi 14oD8b9+duLmzelHBnHNhkA60Ctt75fDuAEGwiSvuRRiLc6a6eyNFldcyOhpi9cNC40D oSJw== X-Gm-Message-State: AOPr4FWtuGoA9F1P2rt4bRkwAsdxMCIKQwMfvq7t00PcS+7ihHcKXOXGFdlhJClh/s7tNDtQZO3XO5ckZOkJow== X-Received: by 10.202.61.85 with SMTP id k82mr5246837oia.114.1463053226156; Thu, 12 May 2016 04:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Thu, 12 May 2016 04:40:11 -0700 (PDT) In-Reply-To: <871t59bx0m.wl-jch@pps.univ-paris-diderot.fr> References: <871t59bx0m.wl-jch@pps.univ-paris-diderot.fr> From: Donald Eastlake Date: Thu, 12 May 2016 07:40:11 -0400 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a113cd1c0d52b420532a39f38 Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 11:40:34 -0000 --001a113cd1c0d52b420532a39f38 Content-Type: text/plain; charset=UTF-8 Hi Juliusz, On Tue, May 10, 2016 at 2:14 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > 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. 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 d3e3e3@gmail.com > -- Juliusz --001a113cd1c0d52b420532a39f38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

On Tue, May 10, 2016 at 2:14 PM, Julius= z Chroboczek <jch@pps.u= niv-paris-diderot.fr> wrote:
> 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 beginnin= g
> of the second paragraph.

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

So the 2nd paragraph could become somethin= g like:
= These RFCs are the basis of three independent, open source implementations.= There is some production deployment of these implementations, notably in h= ybrid networks (networks that include classical, wired parts with meshy rad= io bits) and in global overlay networks (networks built out of large number= s of
tunnels spanning continents).

Thanks,
Donald
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)<= br>=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

> -- Juliusz
--001a113cd1c0d52b420532a39f38-- From nobody Thu May 12 04:57:24 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55812D935 for ; Thu, 12 May 2016 04:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkz5S2cgOP6z for ; Thu, 12 May 2016 04:57:21 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FCA12D95F for ; Thu, 12 May 2016 04:57:20 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x19so115180532oix.2 for ; Thu, 12 May 2016 04:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kETl1lBK04VwxCamwWqTQ5xNdn26qnVbBaj4McZv6DU=; b=QtXqAT0XtAZGTMl1odikBN+Xjmam57yAGVCGzi/VURID9wCprhIE59Tv6LcZpL1hV2 dEWgeCFtVxHvwZfjdoSHJh5SwOlS12n0YhRPuxpTKrTT6Q90bJmqHeIAEPkLflSBm0/0 yDUqyCgMlrqJ5DYh3en8hJn9n9WFlYDpOfn4NNXFI+gF0v2cQ8N8eawarra3lAqBNOgL VEWSNZVKbiuej3zrqn/C9Ym6+iTjkKi1nvwJmTsKZVgi+zIzgzzNcWgAcONkvtfaarRT JzbOIdQFWS7VluQ5dXRLTA+xi+4Rd1cO85325q3tpR6DaCZVJCpGp2u2st9unC1XL0DX j0UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kETl1lBK04VwxCamwWqTQ5xNdn26qnVbBaj4McZv6DU=; b=f1LbayPP+VOZ5O/fTk3SAh6c0UES/JgOPDILG/+t57N+eyK7CRbguRPcT4JvzI30/9 Oq5OlfaOgD9YlR3ucUcGtVXOkyofwkBqSozdvHumtxMUvaqWPcKH3dfYCPbek6cmRv7x /7yaVXRab4OCq9JvdOT4/YNHxFrONX1xEfW6ugIhvvgN0sbHRtGfUHm3Ao01gUddS4Xr Ffw7m9WDBJ7mqq5RlWqzLzDDUnhUzBbUeyZRCFJ7M1f/1z5S6o4qWEMonIzZXb4i4i15 fi3nEzdpQd8dNqqUyeY5hSDmeCw7Hgmtf9l1snjwT1f9c7FrJdCpFPJhmNAv5p/loZn7 eigw== X-Gm-Message-State: AOPr4FWL6N74CvzlTLJfZctQQMdQpiyZSNOkIlUyjtROmQTx9Tb/T/vEZgR8VFHwBFMDVG02EkIX1b5JnFnzoQ== X-Received: by 10.202.85.2 with SMTP id j2mr4534085oib.6.1463054240271; Thu, 12 May 2016 04:57:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Thu, 12 May 2016 04:57:05 -0700 (PDT) In-Reply-To: <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> From: Donald Eastlake Date: Thu, 12 May 2016 07:57:05 -0400 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Babel at IETF , Russ White <7riw77@gmail.com>, Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 11:57:22 -0000 Re Charter scope and drafts, see below: On Wed, May 11, 2016 at 10:11 AM, Juliusz Chroboczek wrote: > > Hi Russ, > > >>> 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. > > >> 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? > > > 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. > > You're positive that we can adopt a draft even if it's outside the charter? > 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 =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > >... > > -- Juliusz From nobody Thu May 12 05:02:24 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944B712D968 for ; Thu, 12 May 2016 05:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwIYVNk-uiRJ for ; Thu, 12 May 2016 05:02:17 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1958612D1B0 for ; Thu, 12 May 2016 05:02:17 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x19so115368974oix.2 for ; Thu, 12 May 2016 05:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MDiRWx8+YEnhTwttKTkTIgh2gvvLOeoKJcJTMo236wM=; b=jfsWD30pQwgu67VceZ5x4imoY6kmS+SpjlZuCW6gKF3FxE8kgWesP3vJxgIzpLXADl 89tDwkJoDNd5dmUBwKiM7evZXDAQRVGwjDVCFmZ7g/6lyk5mtph5/hKHXkiw/YCI+ocE QzmdL4IbsO7r4HNxVtWhwlmgNmAtvCA4+KHJprJOOoqoChRIEzyr0Bu3WkjRFupSJKog 3YFWGXzKaTSB3u1QhZaL6ppOpBiGRFIPHu47sI1fo6Z80sg9gyIINz6uGSUzycfbqp2/ mLJ82JfF8YbKAfqUHWzyuIUyP7UH7QzoSEUgJylQoEvPQ2OZ+0PScvzmt8sa9ZBwvEjI h9/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MDiRWx8+YEnhTwttKTkTIgh2gvvLOeoKJcJTMo236wM=; b=XtcmHvL6+A1LNIyAdLkG8lCi3WM082BdxdjG44RtNo73XbTXg9Vc2r9+8SlttZRfWD o90RaW/G8CcdPqs+VyJJw3xL27ReCth6TFNTXF4AbWvSo/MRfxDsndX43dqxBTN2Cc5c xw65ZB/hMmJaMrMoVMXoKLgN8KiBw4dzLtTdOOGIebu+CPIMCc3R/bkf33haor2ay8Ai daZ8Uy9nD+nl/GJOQo1/qVeqpVvl15IeTILAlHVDjMSbxjSQMFZEPNRq+mIU/lxqTl4D rbjP2u8w38dHEvIL/H+lLKyC1n+hdggBvxpLwG+Qumw4f5rjo1ZrITLsshr3OTDcHT/d yvFg== X-Gm-Message-State: AOPr4FWFYgqzaC8WRiB3tnRQRIZqPoN/Skx/rF2ipZYQL9gnQtlZ+xQiLF94Vupd06LYKcYseXxQNoVFFHyriw== X-Received: by 10.157.54.203 with SMTP id s11mr5872357otd.102.1463054536479; Thu, 12 May 2016 05:02:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Thu, 12 May 2016 05:02:02 -0700 (PDT) In-Reply-To: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> From: Donald Eastlake Date: Thu, 12 May 2016 08:02:02 -0400 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a113b005aef1b350532a3ed38 Archived-At: Cc: Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 12:02:23 -0000 --001a113b005aef1b350532a3ed38 Content-Type: text/plain; charset=UTF-8 Hi Juliusz, On Tue, May 10, 2016 at 2:22 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: >> 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. > > 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? 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 =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > > ... > > -- Juliusz --001a113b005aef1b350532a3ed38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

On Tue, May 10, 2016 at 2:22 PM, Julius= z Chroboczek <jch@pps.u= niv-paris-diderot.fr> wrote:
>> I think that it is useful t= o mention that a sophisticated link metric
>> algorithm computed b= ased upon the link qualities (i.e. for wireless) is
>> out of scop= e 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 re= quired to work on that?

I think that Alia is looking for a sentence = in the charter something like:
Link metric measurement or calculation procedures si= gnificantly more complex that those currently in Babel are out of scope.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2= =A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver= Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

>
> ...
>
> -- Juliu= sz
--001a113b005aef1b350532a3ed38-- From nobody Thu May 12 06:18:02 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A56012D668 for ; Thu, 12 May 2016 06:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtSlEr4Dfkfe for ; Thu, 12 May 2016 06:17:59 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBC412D125 for ; Thu, 12 May 2016 06:17:58 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4CDHvbm022767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 12 May 2016 15:17:57 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4CDHu5p013002; Thu, 12 May 2016 15:17:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8C84461F9A; Thu, 12 May 2016 15:17:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id rAvLsKPjV7Uu; Thu, 12 May 2016 15:17:51 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D366561FAB; Thu, 12 May 2016 15:17:51 +0200 (CEST) Date: Thu, 12 May 2016 15:17:51 +0200 Message-ID: <8737pns9ds.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Donald Eastlake In-Reply-To: References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 12 May 2016 15:17:57 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 12 May 2016 15:17:56 +0200 (CEST) X-Miltered: at korolev with ID 57348285.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57348284.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57348285.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57348284.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 57348285.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57348284.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Russ White <7riw77@gmail.com>, Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 13:18:01 -0000 >> You're positive that we can adopt a draft even if it's outside the charter? >> Alia, perhaps you could comment? > 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 nobody Thu May 12 08:32:39 2016 Return-Path: <7riw77@gmail.com> X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB1612D1A9 for ; Thu, 12 May 2016 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1QtVhWw2yJd for ; Thu, 12 May 2016 08:32:36 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDBE12D190 for ; Thu, 12 May 2016 08:32:36 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id o66so86006854ywc.3 for ; Thu, 12 May 2016 08:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=5XzjeoEio6MQ0/vO+FzPpbnwamqWHE/ijUQhW53IKfg=; b=Cpc4vPvc2I5Z9KcS3vNg9JGh9VTMOe4JMpaSlO8hBxdrqZ7AOswqPuhotIShS1+DT/ xWZkua8ErpXL3d2UnicGc3UfRrjck602QDR8znjBoUtq0z15A2GokB3BUkCwtd7aNkKF p1LBR1Z/xb/zzJu3GwCY1IqhbJPseKoYMEFjZc+JD2ZqCoLWvCVxIFTWuACeG+ydreN6 TLDEoPuZN/6pCeP5exGNkICx+X1QvCKcckSJRg4/fwTlgD3yRDkwWCe3/nHps9NDoun6 KpI21kYvsnbC1MrSATYBsbsmwGeY2AwG2b2N9A7rzBNt63Py/rTMPV6YJkgYM2qLDxen S/EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=5XzjeoEio6MQ0/vO+FzPpbnwamqWHE/ijUQhW53IKfg=; b=PS8qGDjDy1mHwkAyBcnkJAc94k8AJzTZ/fpgbJgsbJarCjz75CXltJyU6TDASRrbNI l3oskGQhj5NW8wWeIb/HrYdFE8PfpV5ohL0hz416cwiP8vccbyeCynoW5VF8/8Q4f5DQ C/NZLxH3t8j0PPgVynMA7BUENj6L4LayrTYSVDtREANuaqBbc3Ao+BKEdvhdzoYKdPrg r/QskQvgPxhlGgkuJ1gJUzCSCJ5QpiVo+o0/0vB7HixZQbFI3FMFcYrZdEwXDKrhfnpx s/HKI2OtLfZ3k4Jc5rbDggEh2+5VyvcfZ33mGOZZkYLz1c2pu3pZsqAztQgMP2SY0Zrq uJKw== X-Gm-Message-State: AOPr4FVSaRqfT7Vf/ThrTxS1MQ94c8Mg/veIzK2XVBmum6I9haNo5+kzJ4YwLQZKeH/wHA== X-Received: by 10.129.49.72 with SMTP id x69mr4922121ywx.223.1463067155813; Thu, 12 May 2016 08:32:35 -0700 (PDT) Received: from Russ ([12.28.7.254]) by smtp.gmail.com with ESMTPSA id i188sm7532966ywc.19.2016.05.12.08.32.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 May 2016 08:32:35 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Juliusz Chroboczek'" , "'Bob Hinden'" References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 12 May 2016 11:32:23 -0400 Message-ID: <028901d1ac63$7e52cb30$7af86190$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFYoAHWEHtoxVT8DhtHOznazgjQXwJ4U7ZaAUvKXswCxUi1WAILToIYAqgKpE0CUrJiLqA7Cv6w Content-Language: en-us Archived-At: Cc: 'Donald Eastlake' , 'Babel at IETF' , 'Alia Atlas' Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:32:38 -0000 > > 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=E2=80=99s an important part of = the > > standards process. >=20 > Thanks, and agreed. 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=20 From nobody Thu May 12 13:50:33 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CD012D09C for ; Thu, 12 May 2016 13:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dy7vaFHtzKF for ; Thu, 12 May 2016 13:50:30 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B59E12B040 for ; Thu, 12 May 2016 13:50:30 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so274358150wmn.1 for ; Thu, 12 May 2016 13:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8cXERRrGkkwqCm8kG3XVRLTfTpQ62RzVzR+LYX3vIBU=; b=hpJZR5szLcneEXuY+jsBAPOS2bo7oXrDt4iuXWeBZGYlYYv5lsUX0tX3CSP9L93wT7 lBSd8PPnbvRfk3FIheaVBcUtuRtr1wDT/u2XpbAoKgwsuMvmf/OwL8jzRnjL/lXaHJWG VB0i2Bj2VT4vrAUW+uyKy0KuJ/kXTLEfxsInjptBizDV+2tXS1cOE5rg6BE3oUHm2i5j BG2N6epo0OvDNcnqVqS0lNA1SDS6xDeX+MHinCnYLN/FMWl4tuyUfAxxvt4iv2zDlV6b kxFfFB138b1J0dblnBnw/FE3/kca25kV+1jh3BPJVeKYcp/B+pj+dBTNoCl1pFpvr+GS DAlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8cXERRrGkkwqCm8kG3XVRLTfTpQ62RzVzR+LYX3vIBU=; b=IxEWPJbTjC0wDyuCEt9s9Swtv8XcbiT2MOfUshzjxSt2318ggmoE8kMx/HGMZsqccM 8vxLsozipubeBdXtPuwdUMuQKAhkYtsPJGRoE65DEHq24EUtGYuuoPRzEFI+ANoTKooW ksMNgFEy1gmHMJu3vtuQ/vOhDrYdg536w2VYcsxQLoYl3ku8lybp5jZyRp7PqsUQXBbB 4Xyf2h0OO3BA0Afk4jlgo5EVk42uueyw1cwHfhqTXC0ybUrdCtpGJUGMnSk5v9PEcVHi SAVRprm7Hn2xToMXfNGx+A3WTV//U9KrsLabg42va6n1ePUJwR8xVeL0NX9TxuBgLR8a gRrg== X-Gm-Message-State: AOPr4FX+VG36yu7Uy8/Y6UuVrL2wIbNd/j5xkSe3NimfmCipBVaFuM2UiVsIbfsJBhxE4EaLvyS79EIp/eT+VQh/ X-Received: by 10.194.72.103 with SMTP id c7mr12810789wjv.65.1463086228844; Thu, 12 May 2016 13:50:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.34 with HTTP; Thu, 12 May 2016 13:49:49 -0700 (PDT) In-Reply-To: <028901d1ac63$7e52cb30$7af86190$@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> From: Gabriel Kerneis Date: Thu, 12 May 2016 22:49:49 +0200 Message-ID: To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=047d7bdc8fa2f295600532ab4e71 Archived-At: Cc: Donald Eastlake , Alia Atlas , Bob Hinden , Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 20:50:32 -0000 --047d7bdc8fa2f295600532ab4e71 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 12, 2016 at 5:32 PM, Russ White <7riw77@gmail.com> wrote: > > > > 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=E2=80=99s an important part of t= he > > > standards process. > > > > Thanks, and agreed. > > 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 the= y > 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 --047d7bdc8fa2f295600532ab4e71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 12, 2016 at 5:32 PM, Russ White <7riw77@gmail.com> wr= ote:

> > but think in the IETF that discussions should be on the w.g. mail= ing
> > list.=C2=A0 That mailing list discussion should be about Internet= drafts.
> > That keeps the whole history of the discussion in the mailing lis= t
> > archive and in the data tracker.=C2=A0 It=E2=80=99s an important = part of the
> > standards process.
>
> Thanks, and agreed.

Sure -- so we need to find a way to allow comments in a git reposito= ry while also keeping discussion recorded on the mailing list. I'm thin= king 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. Though= ts?

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

Gabriel
--047d7bdc8fa2f295600532ab4e71-- From nobody Thu May 12 14:14:59 2016 Return-Path: <7riw77@gmail.com> X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8283612B034 for ; Thu, 12 May 2016 14:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J99F3ZE8BhZ for ; Thu, 12 May 2016 14:14:56 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FAE12B038 for ; Thu, 12 May 2016 14:14:55 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id g133so85581239ywb.2 for ; Thu, 12 May 2016 14:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=v8YkOYahV3rFURn1/ditHF2AQxVf8Ni3unKeZlSS82M=; b=ESToCldrpRPc6gh5mYmpDEythAlZsHloQUThZ2Wrkpp0Fl9i+sZC/6/mXd1f6t5W7W G3G7YJ5SPD5eeuo5n3CLpMBH2ZlKDtcqAaBgRKqcJcAT2lWIHb/fSydaFdUOEbZ/zzr8 Wbirl5JnYoyMrxZHl/8DKFCTHLoZllUAfJfXoc1pNxf2SBHk+5z1UAa3hrVPceMWpA7M BGJcOJaqvkHnYlXe9Jy2ST0seABcwW0HM54/0DqGycYEJFGl+ST8TutsCwoOgPQ4N2jC U5yhgXBIaAh6T/JR/8F/A2Mva5kuWAGw39S2y1QzPz8NUEAyGNhUN1tBvactKzoyx5Oh EuSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=v8YkOYahV3rFURn1/ditHF2AQxVf8Ni3unKeZlSS82M=; b=gF/0lpj4EBF4K4PO0YznTte35QNB5zSWP8ZsZnOHZLSp0p52YZ4MGdPfplVIF5qTVY ieEYauj7pyZd4tkjpiOI8toAsMrfrA5VqCMp7Xe5mz/vxQcO84Ioh2Brc2xRwYW66QrP aLJ3ieth4L9kv6Lhtk14xTZcXp4z49tzFHQ1bvJESPkJ1ICJ+zrDYH4bYB9lvuVN0/GR yHjRQQ5GlEN9WD7KcfWtCw3T5+v7QjQXXzsSz2B2jtZLmDPKJWmSkRMRpTl0Y60j1mvc HM9s18a3J43pyJ2zs+DWZaSBMcJN+h0hINLRg7137aV5/zPo1TLL/Zd+bSFXkFlayGqp ex6w== X-Gm-Message-State: AOPr4FWj6R2xnzfh6yEkGKu8clxBxxtmCudgC434cGw18wPwTZTGwVpH/ojbdKbkYmEBXw== X-Received: by 10.129.51.216 with SMTP id z207mr6195563ywz.94.1463087695196; Thu, 12 May 2016 14:14:55 -0700 (PDT) Received: from Russ ([12.28.7.254]) by smtp.gmail.com with ESMTPSA id 193sm8320093ywe.38.2016.05.12.14.14.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 May 2016 14:14:54 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Gabriel Kerneis'" References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> In-Reply-To: Date: Thu, 12 May 2016 17:14:43 -0400 Message-ID: <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFYoAHWEHtoxVT8DhtHOznazgjQXwJ4U7ZaAUvKXswCxUi1WAILToIYAqgKpE0CUrJiLgGTn+EtAjiqNvKgHQe80A== Content-Language: en-us Archived-At: Cc: 'Donald Eastlake' , 'Alia Atlas' , 'Bob Hinden' , 'Babel at IETF' , 'Juliusz Chroboczek' Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 21:14:57 -0000 > 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.=20 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=20 From nobody Thu May 12 16:05:56 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78D12D0B4 for ; Thu, 12 May 2016 16:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0O9_UIqnFc7 for ; Thu, 12 May 2016 16:05:52 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA66B12D50E for ; Thu, 12 May 2016 16:05:46 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4CN5h3c029211; Fri, 13 May 2016 01:05:43 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 91F4461F9A; Fri, 13 May 2016 01:05:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fynPO4VGvscb; Fri, 13 May 2016 01:05:42 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id F310B61FA7; Fri, 13 May 2016 01:05:40 +0200 (CEST) Date: Fri, 13 May 2016 01:05:41 +0200 Message-ID: <87ziru3mii.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Russ White" <7riw77@gmail.com> In-Reply-To: <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 13 May 2016 01:05:43 +0200 (CEST) X-Miltered: at korolev with ID 57350C47.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57350C47.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 57350C47.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: 'Donald Eastlake' , 'Bob Hinden' , 'Gabriel Kerneis' , 'Babel at IETF' , 'Alia Atlas' Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 23:05:54 -0000 > 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 nobody Thu May 12 22:58:07 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2D12D0BD for ; Thu, 12 May 2016 22:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj0KYCk01G15 for ; Thu, 12 May 2016 22:58:05 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 66B5912B031 for ; Thu, 12 May 2016 22:58:00 -0700 (PDT) Received: from [192.168.43.129] (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E14E9D0486A3C9; Fri, 13 May 2016 08:57:30 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Markus Stenberg In-Reply-To: <87ziru3mii.wl-jch@pps.univ-paris-diderot.fr> Date: Fri, 13 May 2016 08:57:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <989DFB31-3688-485A-8DEA-11E5CDEF12AA@iki.fi> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <87ziru3mii.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 05:58:07 -0000 > On 13.5.2016, at 2.05, Juliusz Chroboczek = 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 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. I think keeping the drafts in github enables mainly pull requests = (=3Dsomeone 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. > Perhaps we should make sure that the mailing list is archived on = gmane, so > 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 nobody Fri May 13 06:17:10 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80C312D1E3 for ; Fri, 13 May 2016 06:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzZ5WxrKZnGO for ; Fri, 13 May 2016 06:17:05 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA7612D1E7 for ; Fri, 13 May 2016 06:17:04 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id g17so29807656wme.1 for ; Fri, 13 May 2016 06:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=vshMU01c8AGlCsbaWf3bNrH1ygdkFFAMzfL4Wgk1VLk=; b=e6YkyzG8C7jmt3m4P3Hcc2OnoN/2nS4ni8wlflh6G2+gpcsZd569vcKW46KmFHeDSq oJ/EkakNx3D6+yazYtkaN/ipWsCcjdQ7cz/fivcul5yq622o2PWKySBuJcBsJs2jIN2+ isSqeTkBcsFPYErnhsinRj9GeXHGQ3WhMo2C0mlFVARL/762h8R/NshAUogD/Ok7qs1+ DWtN96GAUzFXwNSC+Bf0Ybjces7FIhndygZbKcAi266hLLapMlUi3VG0JylLflw7wiVe X6+OqsJwHFDFJmOhgb3xVv8FQde7w0uvkuG2T8+J/887q8eGk+m+J9J1zZpxF1TbqYW7 Nzmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=vshMU01c8AGlCsbaWf3bNrH1ygdkFFAMzfL4Wgk1VLk=; b=AYRbVHTxiGB44jEfcFjj3WreARAanAJB8LadWfHjtx9aMBsQCrl0Vy2S/fcJuhSc0d xLg3HdvSDygFt3bQS0yEXgKx0RF6VwW2RyDWDizL8HIH342XYM7xbLcuVOMOB9Z3O7f+ PzLTpt/GMstFKdl5NtgdafpEgvkLxYO0gVb9gYbMpxsmiUNUYa3CM8Dh4yv++LiSIT6K V2T+UvOSas8700bdm1lWDu240y2idzK6nudfhpXEI6BijCBbbMNqXnlrGTmDkqoAH8vk +B3Pvy+44gvO+UV1dz+C+oAGO8+w161df3u5x5QOm8SS5zOpKSx2ihKFw9ch4LianYc4 y7QA== X-Gm-Message-State: AOPr4FVGK48e0drilvGZ8nwXOjNPF1RKcl6pMToximcjBGI0I0soiuMhVpz2khgUw+nE8Q== X-Received: by 10.194.106.41 with SMTP id gr9mr15682467wjb.161.1463145422889; Fri, 13 May 2016 06:17:02 -0700 (PDT) Received: from [10.87.1.227] ([145.15.244.19]) by smtp.gmail.com with ESMTPSA id cz3sm18615912wjb.14.2016.05.13.06.17.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 May 2016 06:17:01 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B1F0828B-CD0A-4FAD-A00A-8969BC2A0008"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Teco Boot In-Reply-To: <989DFB31-3688-485A-8DEA-11E5CDEF12AA@iki.fi> Date: Fri, 13 May 2016 15:16:54 +0200 Message-Id: <7F889465-95C8-4486-8DF9-6EEE1031C72A@inf-net.nl> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <87ziru3mii.wl-jch@pps.univ-paris-diderot.fr> <989DFB31-3688-485A-8DEA-11E5CDEF12AA@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 13:17:09 -0000 --Apple-Mail=_B1F0828B-CD0A-4FAD-A00A-8969BC2A0008 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Op 13 mei 2016, om 07:57 heeft Markus Stenberg = het volgende geschreven: >=20 >> On 13.5.2016, at 2.05, Juliusz Chroboczek = 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 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. >=20 > I think keeping the drafts in github enables mainly pull requests = (=3Dsomeone 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. >=20 > 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. >=20 >> Perhaps we should make sure that the mailing list is archived on = gmane, so >> we're not dependent on a single archive. >=20 > Well, I would imagine IETF one to be reasonably well archived and to = stick around ;) What about IETF to provide a git repo service to draft authors and = contributors? Teco >=20 > Cheers, >=20 > -Markus > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_B1F0828B-CD0A-4FAD-A00A-8969BC2A0008 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXNdPGAAoJECQbXIDdIQWqdAkP/RtRBDG8KFFY3mDAcgpg/pz4 12+fH/72FUcTCI40ylGjYXoR1I6yC6slMVNghKX2Ji70eXQGVlXcKPTQvLySRCkT 9RikbT/LWgQGsLGg7DtD8qJl19jUpkykYrB+VWD3Hedkz9JCWVL0nKHYos7AJqhO tJBASyYUpher/Nyb1s3MEBNMhHM48hjJvxoyml1vMgm0UOf9RyVQ5U2LD/PpJ5YB uXhsjwRQEgrOgU8su907rrC6TNgwmSfGnCA9q88lRdgYJ+sAdXL1+kGvSCds8mWg UQB/IzG0rhW3aH+gQaoSiuTVY8RXqk6Q5YckLakO0EUyo23kzW7yyKwH1tNqBi5X WeVYRHgAQy3Y36D+y4oAGYDIR05/79ZeYIV60zZzUycMs208QNT8uAx49YN3bGPX vf5QzddmRP+mvsdbDww5SyGUbjds8ENn/+OvR/TZu2of86xdIwbfHJ1llmDqJuO/ z2bnaVO0xzvdxXTskO4K+4hNBStj5sPQLGjOhm7hohysYpnqTepEiKhwSqQmiSFi Eb7tKOFnlOSitR+BALgOx9qF6+ykj+hcR7x2vzOd8/TYsbi8XUCn0+2jAN95BDW6 1bvUsxw7G0wxMKNFCv4clVvJJpy9osTUqHNuZBlhRi6WXFuCLFaXJZ64eU/TN4d3 PTwP6ORl2M39x00pdyBv =mdcD -----END PGP SIGNATURE----- --Apple-Mail=_B1F0828B-CD0A-4FAD-A00A-8969BC2A0008-- From nobody Mon May 16 10:19:52 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA912D850 for ; Mon, 16 May 2016 10:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OYALLud-Kz5 for ; Mon, 16 May 2016 10:19:49 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4730912D85B for ; Mon, 16 May 2016 10:19:49 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id x201so278568804oif.3 for ; Mon, 16 May 2016 10:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=tOg2k83FovPUGfVikj0gG+xhrdER2NRhF+FVWc4vCEA=; b=aU3DibwwkMHJw8lgXwnA4EW7FqQQg88j5NE6wsK7NuOkASVyHIepWkLr0uhLD2gNDK GKXfxuxBiD36JRwR+lI/exNaG5wlDiFEgehMxX2WfSTLVf80fCNyBq/rv8ooQ4QGDMPi Ww5p/iRIcpOR8lTip+whpvvhi7RzDix7y+FvII20/ty2XUcJ2ewtcwfwEhBL74f7Ippx EGeX8RYhw4CBcTGt7Fz1gwqscBZSN3kaXfNGGGtAPsigKJfUSHNB13A1F1RsuDWVELj0 PbA2zJ0nnoVP7GdTQ0t2Vt99/kUiBIUvjqjzXfA33Gb4CFzEYVKz4tuGsLs9ba40Gd51 gKfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=tOg2k83FovPUGfVikj0gG+xhrdER2NRhF+FVWc4vCEA=; b=IgYJI2HLQ0wnfQHSFMEr0WdtdXiW9pz+8QQWn/RErQ5DC7TohQSoCfTzXAewlNrKVl 1JKQ9eR6Y0Rg/urQn7LjkW9kPv6coCjweMjlgxQ/xv5LCOBV68EniAgZk7QGVCAaiiua zDC6hUkqQowPIUng0oGgsxDdco9EieFibZtLlLbmq9+PqvdeBIu1fjwr5124V9BkVVHS ncZrKu3zaKxdTfWMaYnNUVK6SGNF7xTtlpk5VbtzsMUIZHUOPKe8g5bHTeWNCVguwCMN XRdsmuIkyVYnKWWAfzKVW27zHZWI6HLuOwguznTQluhEzM5flz5RKw09n/PUMC11DtYZ XoTA== X-Gm-Message-State: AOPr4FWfXQIcrsePGcyHzmKGgafrsTdrWelJNZF7fuxYunh+YcEE11VkDGuNlQ0zx8EnEK7EELLx8pu9Y9AVzw== MIME-Version: 1.0 X-Received: by 10.157.4.207 with SMTP id 73mr16246723otm.127.1463419188565; Mon, 16 May 2016 10:19:48 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Mon, 16 May 2016 10:19:48 -0700 (PDT) Date: Mon, 16 May 2016 10:19:48 -0700 Message-ID: From: Dave Taht To: babel@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 17:19:51 -0000 looks interesting: https://tools.ietf.org/html/rfc7779 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Mon May 16 10:54:25 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4FA12D89F for ; Mon, 16 May 2016 10:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X_1bpOiyCzD for ; Mon, 16 May 2016 10:54:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B696112D89C for ; Mon, 16 May 2016 10:54:17 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4GHsFij006738; Mon, 16 May 2016 19:54:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 54F1961F9D; Mon, 16 May 2016 19:54:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KdeWsneS-8lE; Mon, 16 May 2016 19:54:10 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 69A9161FA1; Mon, 16 May 2016 19:54:10 +0200 (CEST) Date: Mon, 16 May 2016 19:54:10 +0200 Message-ID: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 16 May 2016 19:54:15 +0200 (CEST) X-Miltered: at korolev with ID 573A0947.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573A0947.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573A0947.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 17:54:23 -0000 > looks interesting: > https://tools.ietf.org/html/rfc7779 Yeah, I know. Look at the acknowledgments ;-) It's basically a slightly simplified version of ETX (the simplifications make it dependent on OLSRv2, while pure ETX is protocol-agnostic) multiplied by the expected data rate. -- Juliusz From nobody Mon May 16 11:34:32 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A101F12D921 for ; Mon, 16 May 2016 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvCXC8MmdbtX for ; Mon, 16 May 2016 11:34:30 -0700 (PDT) Received: from hupie.dyndns.org (hupie.dyndns.org [80.101.237.101]) by ietfa.amsl.com (Postfix) with ESMTP id 1A90512D917 for ; Mon, 16 May 2016 11:34:29 -0700 (PDT) Received: from stinkpad.internal.hupie.com (s529dac66.adsl.online.nl [82.157.172.102]) by hupie.dyndns.org (Postfix) with ESMTP id 130FC480CB4; Mon, 16 May 2016 20:34:28 +0200 (CEST) To: Juliusz Chroboczek , Dave Taht References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> From: Ferry Huberts Message-ID: Date: Mon, 16 May 2016 20:34:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 18:34:31 -0000 So Juliusz, Is it also implemented in Babel? On 16/05/16 19:54, Juliusz Chroboczek wrote: >> looks interesting: >> https://tools.ietf.org/html/rfc7779 > > Yeah, I know. Look at the acknowledgments ;-) > > It's basically a slightly simplified version of ETX (the simplifications > make it dependent on OLSRv2, while pure ETX is protocol-agnostic) multiplied > by the expected data rate. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > -- Ferry Huberts From nobody Mon May 16 23:21:57 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEDA12D52F for ; Mon, 16 May 2016 23:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myfGNdOZQofr for ; Mon, 16 May 2016 23:21:54 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BEA12D0DB for ; Mon, 16 May 2016 23:21:53 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id jj5so2125657lbc.0 for ; Mon, 16 May 2016 23:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jiS7Z7suvNvEg9Mx7dmroTPeJ2un97sPmPxBvdWQPVU=; b=jorEm2CZIzf7a1eH+Hhi6bIyrNj6MSeQ49lXDSYAWFt0qVWHWM8yphvZ8fHBPO9DTX bdKXSDISnymWsPN6bEVOxOMtCA4FMYIeQex+TdxgQhgYtAu0p/aDW4k/z0hhs9jOJnp/ 93Y11cam4R6BiSi98dbWCw0ZcYtLkzt7+ZJ2TChgh7GhkRID3sIBjXt9TleNZ28FeEFE NOoKT9DtDT7jv48lsZ4SiHnidSl3baEZ31wTUDa/C1oRVEamoh8KgTmd8zc9Xw3q86c/ KTKODZPlC3bP6vMbmxpVM74kbpanEibES0gMViVqxVxQGUAv0+84l9d+Ta4EvW5AAjgv kR1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jiS7Z7suvNvEg9Mx7dmroTPeJ2un97sPmPxBvdWQPVU=; b=btgYd+mdbGYswBXja9GPaTyEcgLwgAHakp5+2C7x26fb9E7DnbC/BIow92pymKBDcC AWSD7UYKupo9qErJO2l7JbR2jXTmdJtgCLpCpiGESMHGBjGMs4Z4bJyvMoSPngPgvQuh 8R7DaSoPrEcwpdo6r14c0h5JYboscQ3xH3u2V3Y3nQTphuZqGECLAkL5OqggptX5c1fx VZXy7My5JUaQkqzYwhc8VqTb23Uybife4FKTG/zpaVrClRhQLCwUsyV5kTq44Y8a/qDN un9Ol/jMltWFsPSrhzsUoRjZjccg7hGrCZKOSttSUXdQXXfwEPs+SEpTPS1ZSfezAJph VOZg== X-Gm-Message-State: AOPr4FV8xndU9o7zwEGxTxhXzlZNORvQKL/IvRGXdqYXJBbaMS0CwilLjSFVR64CV1Lo5cCXydPsFNpxjbZRGw== X-Received: by 10.112.171.198 with SMTP id aw6mr11648056lbc.3.1463466111837; Mon, 16 May 2016 23:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.24.42 with HTTP; Mon, 16 May 2016 23:21:22 -0700 (PDT) In-Reply-To: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Tue, 17 May 2016 08:21:22 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Dave Taht , babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 06:21:56 -0000 On Mon, May 16, 2016 at 7:54 PM, Juliusz Chroboczek wrote: >> looks interesting: >> https://tools.ietf.org/html/rfc7779 > > Yeah, I know. Look at the acknowledgments ;-) > > It's basically a slightly simplified version of ETX (the simplifications > make it dependent on OLSRv2, while pure ETX is protocol-agnostic) multiplied > by the expected data rate. I am not sure I would call a conversion from symmetric to directional a simplification. If your routing protocol calls for a symmetric metric you would go for something like ETT, if it can work with asymmetric metrics for links you can use DAT. Most of the work in the draft is "window dressing" and a sliding window based averager for the frame loss that works reasonable well. Henning Rogge From nobody Tue May 17 12:12:56 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3099012D513 for ; Tue, 17 May 2016 12:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oishmjM_hXFi for ; Tue, 17 May 2016 12:12:55 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0165812D907 for ; Tue, 17 May 2016 12:12:54 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id x201so40999785oif.3 for ; Tue, 17 May 2016 12:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rYR1RXgnBSqXHOwzo/b9PI0Qi/ksaYrTtyeatHfwLb0=; b=Y9/O1l6lJtZpY6KJ7zEKhHhOYCkKbXELPvnhqglOYYY/CymD1sYw1djqWISc91qcK2 cBLgYTl3fRM4N7x6oIacrbRXpPhJZVzswJYwPPgQR051swBcFxR3V+jbVs+ai5UrW/rI 4LYT7C8L9SoT6LesrMruGQmz0ahIjGkypa4TVqnK178tiohT7xGuN4A1Y8E0eYR9aQKr zlu4sq2d1zSjYLRlBHz0g+nA0f7LT2qh8o5uFl6BY/EUhibMdqUWHDVcpAXKjV5N5OFV jPwUcqaqKyNmgZuTQwYRXOGiRkIZ5zuGJZOIX4uplvNfwtCAURrQY+1v93Q1TKPMAHx1 /6kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rYR1RXgnBSqXHOwzo/b9PI0Qi/ksaYrTtyeatHfwLb0=; b=L2cc/GsmYnlOOnqxZfFOoSnrRQMRDlXxmqzwvYMmwOCYErHY02LZmBUWhDFrSXgDKS jS5Q5mqVHlQFHB2rz3aQxK4fUYXB2/i+KOVqgbLisQoHbpq1ArEAmioe1JxLLFNCAULA 9xOHMFI/0wicUFKwbhO2kZXTcRz2JLPVvRLJTaJgqKL1GJAUiTz5E9tjLfAmF7BknTmt eaBd2ORgZJfh7uQDqGKeNCPULZ1BcrIGjZNPN/mZH6de21LJkaEmfeWjr5UCiOnbjzIQ ekJjpSxPLhMXY/C44tADSywnQAJ2eL35tTJBWY6wAZ5aItKZAV1HzqdcUqABOcfus1o9 EJGw== X-Gm-Message-State: AOPr4FUYkNV0bp6JqY+96Xg1o1/mtut/CmpZ8s5smzdwqE4WW9nsC7aWRVTEE9sx71sgOsmUiy83oQiHIJGfGA== X-Received: by 10.202.65.133 with SMTP id o127mr1809031oia.43.1463512374316; Tue, 17 May 2016 12:12:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Tue, 17 May 2016 12:12:39 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Tue, 17 May 2016 15:12:39 -0400 Message-ID: To: Babel at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 19:12:56 -0000 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 =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com Charter for the Babel 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. 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 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 that 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). 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 nobody Tue May 17 13:52:26 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DA212DA10 for ; Tue, 17 May 2016 13:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szwsnPnMt4lI for ; Tue, 17 May 2016 13:52:22 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CE212D5D2 for ; Tue, 17 May 2016 13:52:22 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id g17so50315404wme.1 for ; Tue, 17 May 2016 13:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RlDzBFGwyCjc4R2GgWsVzb4WbzdcA5qThnMudX/TYJg=; b=jVrEGQiAx9kNCol3m3BNKKEOg15B2QcxlBcS3ArMHGuYLpAEdah3oESk1panSW10cq /SBGBLhdExwEDi95eGWXu5CkrHX03g5aXuLDSEmLk2j0JGK4yOgJG7UvNPCcEqWV27aX IxOJ4C7R9N1gjTN2a3j9rz6wEDy8KE6k3UZk1AfFp1AKPVoTUgYaqai89LGUaY4e9ZkL khJZcd6BtiJG/+2PjGGuv5OFr6hcKkHXY79svmhBBmnIeBZ7/Rd5UiHuyEUbd4yT3CC3 aYJ0t88NXJ3m3mPa+PdIq7C3F9ug0ziKnc5DoW54vHxGYuwgBYzba9zz81K+c23bLDEh fJ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RlDzBFGwyCjc4R2GgWsVzb4WbzdcA5qThnMudX/TYJg=; b=ayFyv0PUnviOkxSN+EH22NtVCnGjMDOwggtBh+XXw1z3olNrQjo+9MkraR+fwP58j3 zZt+Eb+JlLL6Emp17DX8ty2ZMhHll9vr9E4a8dUEKOiY76c6v57q9+8KzqvcwM3c9HCf MH4Cd2nRgN6Ilu0IHjR5UOfOEhwnvwOX++AfGOgd/idbiXiBYLhbciQfzV8FGFFhqqy9 6V4bEEnwN0QzLfNsl6X6KyNP4fXoxblDJ3867G4B9w66s3CZFECG+d8gWghuh8cHgXgF p3qhXKFBIhXiQyPC79QxkMIOmt2z5tFPns+9/d1L1I4z9BKLujgnraECcx3jldFw4JjA BZgQ== X-Gm-Message-State: AOPr4FXWSg99Ua3m32xRwvvYi48pxq5+byC+t4jUwG8d6Lf6iJSyFh2W7iFz2bdW426dm1428EMmYkX1ftmEei9f X-Received: by 10.28.48.145 with SMTP id w139mr24458236wmw.51.1463518340641; Tue, 17 May 2016 13:52:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.34 with HTTP; Tue, 17 May 2016 13:51:40 -0700 (PDT) In-Reply-To: References: From: Gabriel Kerneis Date: Tue, 17 May 2016 22:51:40 +0200 Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a11423f32d14e8805330fea3a Archived-At: Cc: Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:52:24 -0000 --001a11423f32d14e8805330fea3a Content-Type: text/plain; charset=UTF-8 Thanks for this Donald. Minor typos and comments inline: On Tue, May 17, 2016 at 9:12 PM, Donald Eastlake wrote: > > The working group is will focus on moving the Babel protocol to IETF > -is > 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 that 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 > RFC > 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. > 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) > 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). > > 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. > --001a11423f32d14e8805330fea3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= ks for this Donald. Minor typos and comments inline:

On Tue, May 17, 2016 at 9:12 PM, D= onald Eastlake=C2=A0<d3e3e3@gmail.com>=C2=A0wrote:
The working group is will focus on moving the Babel protocol to= IETF

-is
=C2=A0
=
Proposed Standard with IETF review.= This includes clarifying RFC 6126
and integrating RFC 7557 and feedback= provided by independent
implementations, and resolving the comments pre= sented at the BABEL BoF
at IETF-95. Other documents that are rele= vant to such consideration
can also be prod= uced. Particular emphasis will be placed on work
needed for a Proposed S= tandard routing protocol, such as ensuring
manageability and strong secu= rity.

Work Items:

- Produce a revision of RFC 6126 suitable f= or publication as a
Proposed Standard, and work with the IESG for approv= al of same
-- incorporate in the revision developments since RFC 6126-- resolve technical issues found by recent reviews and the working
gro= up discussions
-- include in the base specification the extensibility wo= rk in
RFC 7557
-- consider any important changes based on experience = with Babel to
date. This may include discussion of issues such as the si= ze of the
default metric.

- Address security needs for BABEL. Thi= s may include using the
techniques in RF 7298, or other alternatives. Th= is may be by inclusion

RFC<= /div>
=C2=A0
in the base = spec or by normative reference to a separate proposed
standard specifica= tion. This is required as part of moving Babel to
Proposed Standard.
=
- Produce an applicability statement for publication as an
Informati= onal RFC. This is highly desirable in conjunction with moving
Babel to P= roposed Standard.

- Address manageability of Babel, most likely by p= roducing a YANG
model for Babel consistent with other YANG models produc= ed in the
routing area. This is required as part of moving Babel to Prop= osed
Standard.

- The working group may choose to publish an Infor= mational RFC on
implementation experience with Babel, so as to enable fu= ture readers
to better understand the state that drives this work and th= e
experience driving changes.

- The working group may choose to w= ork on multicast aspects of Babel
once the initial focus on Proposed Sta= ndard is met.

- Coordinate with other working groups as need.

needed (?)

Als= o, it was suggested that we may need to coordinate with organisations outsi= de of IETF iirc. Does it need to be mentioned explicitly?
=C2=A0<= /div>
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)
=C2=A0
specificat= ion, including or paired with a suitable security
specification for BABE= L. It will also produce a management model for
BABEL as a Proposed Stand= ard RFC. An applicability statement, and
possibly an experience document= will be produced as informational
RFC(s).

Link metri= c measurement or link metric calculation procedures
significantly more complex that those currently in Babel are out of
s= cope.



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

Date=C2=A0 Milestone
=C2=A0X+1=C2=A0 WG adoption of Babel Applicability draft.

=C2= =A0X+1=C2=A0 WG adoption of rfc6126bis draft.

=C2=A0X+4=C2=A0 WG ado= ption of Babel management (probably Yang) draft.

=C2=A0X+5=C2=A0 Sub= mission of Babel Applicability draft to the IESG as
=C2=A0 =C2=A0 =C2=A0= Informational.

X+10=C2=A0 Submission of rfc6126bis draft to the IES= G as Proposed Standard.

X+13=C2=A0 Submission of Babel management dr= aft to IESG as Proposed
=C2=A0 =C2=A0 =C2=A0 Standard.
--001a11423f32d14e8805330fea3a-- From nobody Wed May 18 05:49:18 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EBF12D0BF for ; Wed, 18 May 2016 05:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqXTBLR1nq0A for ; Wed, 18 May 2016 05:49:14 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6788B12D0ED for ; Wed, 18 May 2016 05:49:14 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 14635757522282.532939254657208; Wed, 18 May 2016 05:49:12 -0700 (PDT) Date: Wed, 18 May 2016 13:49:12 +0100 From: Denis Ovsienko To: Message-ID: <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> In-Reply-To: <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 12:49:16 -0000 ---- On Thu, 12 May 2016 22:14:43 +0100 Russ White wrote ---- > >> 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. > 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 have specific answers, just brainstorming/trying to think of ways to make this work better. > 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 nobody Wed May 18 05:51:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2BD12D0E9 for ; Wed, 18 May 2016 05:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP9J7dXZ8FmG for ; Wed, 18 May 2016 05:51:19 -0700 (PDT) Received: from hupie.dyndns.org (hupie.dyndns.org [80.101.237.101]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6E12D0ED for ; Wed, 18 May 2016 05:51:19 -0700 (PDT) Received: from paul.internal.Hupie.com (hupie.dyndns.org [80.101.237.101]) by hupie.dyndns.org (Postfix) with ESMTP id A4330480CE2; Wed, 18 May 2016 14:51:18 +0200 (CEST) To: Juliusz Chroboczek , Dave Taht References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> From: Ferry Huberts Message-ID: <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> Date: Wed, 18 May 2016 14:51:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 12:51:21 -0000 On 16/05/16 20:34, Ferry Huberts wrote: > So Juliusz, > > Is it also implemented in Babel? This is meant as a serious question. Nothing else. Is it implemented in Babel? > > > On 16/05/16 19:54, Juliusz Chroboczek wrote: >>> looks interesting: >>> https://tools.ietf.org/html/rfc7779 >> >> Yeah, I know. Look at the acknowledgments ;-) >> >> It's basically a slightly simplified version of ETX (the simplifications >> make it dependent on OLSRv2, while pure ETX is protocol-agnostic) >> multiplied >> by the expected data rate. >> >> -- Juliusz >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >> > -- Ferry Huberts From nobody Wed May 18 09:36:45 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E8912D5C9 for ; Wed, 18 May 2016 09:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdIHiQeT2Cqp for ; Wed, 18 May 2016 09:36:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461C312D5C6 for ; Wed, 18 May 2016 09:36:42 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4IGacYv018341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 May 2016 18:36:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4IGacXd032506; Wed, 18 May 2016 18:36:38 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A878561FA1; Wed, 18 May 2016 18:36:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1Hq833d-cWNn; Wed, 18 May 2016 18:36:37 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4708261FA6; Wed, 18 May 2016 18:36:37 +0200 (CEST) Date: Wed, 18 May 2016 18:36:37 +0200 Message-ID: <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ferry Huberts In-Reply-To: <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 18 May 2016 18:36:39 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 18 May 2016 18:36:38 +0200 (CEST) X-Miltered: at korolev with ID 573C9A16.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 573C9A16.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573C9A16.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 573C9A16.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573C9A16.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 573C9A16.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Dave Taht , babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:36:44 -0000 >> Is it also implemented in Babel? Babel is the protocol. Babeld is one of the implementations. Babel (the protocol) is sufficiently extensible to implement DAT or ETT (which I think is a better idea). Babeld (the implementation) currently only implements ETX and Z3, which is a refinement of ETX. I think that doing a metric that takes time into account, such as ETT is a good idea. I'll be glad to implement ETT if somebody volunteers to do the experimental evaluation (which is the bit that takes time when working on metrics). I don't want to be in the same situation as with Z3, which I implemented four years ago but still haven't had time to evaluate. -- Juliusz From nobody Wed May 18 09:37:04 2016 Return-Path: <7riw77@gmail.com> X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984FB12D5DB for ; Wed, 18 May 2016 09:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ElKhLD0GMRv for ; Wed, 18 May 2016 09:37:01 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB0C12D5C6 for ; Wed, 18 May 2016 09:37:01 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id x194so53639109ywd.0 for ; Wed, 18 May 2016 09:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=sfx0mLsbHvaSefD9O+eNkftxQ4/y1eVWGxI+B2aZL2M=; b=TeLhmexpWmMl0eBkZgMYfzVUJvfH0cbIpdPkKZps7Pgg2r23dpmLZHckJu1Z/uIz7F L7eDjS+yni3P+VXUdhg8Qx/M+OE1PNXx29KZxlx8TD1RQSu5rw4pwuae6C1AXUB49CYy bGpqWhG6OTuKmQOTC/pVZZ21P2MDDZ8RPti3tn3qOnwW3Auh9aFaVlFcD23bHJnK1TSG Tcz8GoC0kRajAaLEd3WtZYD1Do2Vsqn5BWQxNXqO5qsEskesIStOLp89IKyBsPMXJbUf U2g6Iw7/N5r1Cr1ZcAQfmUQMuPOzx+0eLllweLAQY3tjYpI9Iu9d9d2vAE5YFt/mOItw 8ymQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=sfx0mLsbHvaSefD9O+eNkftxQ4/y1eVWGxI+B2aZL2M=; b=kB/wPTXsIUZzk1/FvmwmMc40cZqnLz+2+Pmvs06Pjd/sJ1U/kyogGAkYQigfqZVmKS OmFY6Hk6rGgmSuTHvrUguZopjZpnW7acnmPEmcVkM9CnsbkWNcNDwjeQ93PA0UXNAHGD CBwRpXsJ5A24Zx+RawUymKT119ErEQ7unwT1fI0Zfw/QM+LT5Qfke4KcIuLBOSCIT58S KN5a2Jt2etTyKjXkoiUbi37aEpZUdEIQaGKEy+3+xwd8wZyW7DexU+1t59ruW4XXfyT7 7yTCJIkCjRBJmkI4ucRbZnYWl/Mm9/EHTHjbUqB2pj37ja/COqrp46sSQ2CpSZRyoPXO Hvwg== X-Gm-Message-State: AOPr4FUqx976owhABjPJLs/Af89QcpntjPRZ0m7aYSuHilEwGmXL7AWDunqljG6SWnX+hw== X-Received: by 10.37.10.4 with SMTP id 4mr4511105ybk.160.1463589420440; Wed, 18 May 2016 09:37:00 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id 193sm5349728ywe.38.2016.05.18.09.36.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 09:36:59 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Denis Ovsienko'" , References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> In-Reply-To: <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> Date: Wed, 18 May 2016 12:36:45 -0400 Message-ID: <004e01d1b123$77c73250$675596f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFYoAHWEHtoxVT8DhtHOznazgjQXwJ4U7ZaAUvKXswCxUi1WAILToIYAqgKpE0CUrJiLgGTn+EtAjiqNvICBTieSwHqMCMcoAatfTA= Content-Language: en-us Archived-At: Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:37:02 -0000 > 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 nobody Wed May 18 09:39:49 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A413812D5D9 for ; Wed, 18 May 2016 09:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICpC5DVL0Lwy for ; Wed, 18 May 2016 09:39:47 -0700 (PDT) Received: from hupie.dyndns.org (hupie.dyndns.org [80.101.237.101]) by ietfa.amsl.com (Postfix) with ESMTP id B352412D5B7 for ; Wed, 18 May 2016 09:39:46 -0700 (PDT) Received: from paul.internal.Hupie.com (hupie.dyndns.org [80.101.237.101]) by hupie.dyndns.org (Postfix) with ESMTP id 01E68480C9F; Wed, 18 May 2016 18:39:45 +0200 (CEST) To: Juliusz Chroboczek References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> From: Ferry Huberts Message-ID: Date: Wed, 18 May 2016 18:39:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Dave Taht , babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:39:48 -0000 I was asking because at BattleMesh 2015 olsrd2 with ETT seemed to perform much better than other protocols without it. I think batman has also switched to ETT now. Disclaimer: I was not at WBM 2015 but this is what I heard at WBM 2016 On 18/05/16 18:36, Juliusz Chroboczek wrote: >>> Is it also implemented in Babel? > > Babel is the protocol. Babeld is one of the implementations. > > Babel (the protocol) is sufficiently extensible to implement DAT or ETT > (which I think is a better idea). > > Babeld (the implementation) currently only implements ETX and Z3, which is > a refinement of ETX. I think that doing a metric that takes time into > account, such as ETT is a good idea. > > I'll be glad to implement ETT if somebody volunteers to do the experimental > evaluation (which is the bit that takes time when working on metrics). > I don't want to be in the same situation as with Z3, which I implemented > four years ago but still haven't had time to evaluate. > > -- Juliusz > -- Ferry Huberts From nobody Wed May 18 09:41:25 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DED12D1AA for ; Wed, 18 May 2016 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y_JqP1Z6Tcl for ; Wed, 18 May 2016 09:41:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D18A12D194 for ; Wed, 18 May 2016 09:41:21 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4IGfKjs020127; Wed, 18 May 2016 18:41:20 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4CA4B61FA2; Wed, 18 May 2016 18:41:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 7IVBdBB9iUnW; Wed, 18 May 2016 18:41:19 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0460861FA1; Wed, 18 May 2016 18:41:19 +0200 (CEST) Date: Wed, 18 May 2016 18:41:19 +0200 Message-ID: <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Russ White" <7riw77@gmail.com> In-Reply-To: <004e01d1b123$77c73250$675596f0$@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> <004e01d1b123$77c73250$675596f0$@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 18 May 2016 18:41:20 +0200 (CEST) X-Miltered: at korolev with ID 573C9B30.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573C9B30.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573C9B30.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: 'Denis Ovsienko' , babel@ietf.org Subject: [babel] Making the drafts available [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:41:23 -0000 > Okay -- this sounds like the right combination of things. Are the drafts > 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 nobody Wed May 18 10:04:17 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA12412D5DB for ; Wed, 18 May 2016 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXja1DtMfeAf for ; Wed, 18 May 2016 10:04:14 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B62312D5D1 for ; Wed, 18 May 2016 10:04:14 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g133so54446313ywb.2 for ; Wed, 18 May 2016 10:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=fJrG7w/H/QmG9UwqMmEZOli2cmI/2nmCT9iHjyGHnL4=; b=uot77Nrk9AxS9h4R8L5Yq3hGfD3BWv2JjuVnuurdQHlrheapUmsHjCJ2k9YDJe5Iod ypE2nLnEvbqHPMdlIgVNPCMPftjw2gHAxZad43+kOfU6KQtxakS/oSTBZrVDU5wpE3Xj y9cPDfzhrzs1ikeF09TXsGbz2pOAwWMPa/S6Pxzn0Lwfpu0fHzgGcfOyjjSPdshee8tw G41ILnBWZX9d9XMnv5oqZCEcD/xJzPhJUHz5L1DbJDH3KlIOYCTeatl4rsu3Syn+Jji1 ZzRLr6QhOiQ378eLaq9IYBmqVkFASAhKOSiJeJxHuDbY2QKgSbbq6MicwAKybYS85AuY /2vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=fJrG7w/H/QmG9UwqMmEZOli2cmI/2nmCT9iHjyGHnL4=; b=SwtFr3rjH9PBvMihtaJbhb2svJtKBnToQrqk0hLr77N8KuTuTKrRJB2TAHrgRxpBq9 /DAUFU8zny/0FyU9zJpdLPhsihbMZWafVdXE6Pk8WrFDoU2q6x9q4J2pOgmX1nm9LsFI UJBW7907jCP/nY6sRXqQSmzu8LN3fCOLlocSGxsAyfEyu9WSp2SH/K8NbSsjcD+S97qA PDXtsdiqiUztDowWjHLiBSjqzWo0DytYvHy9OwjovedL7MEkqbnOERyV35AW8A2+yoyk d55VwMFNHiH+dqsWVirYZYh5iRVsv/13d712A2Wlhfmi1zqr+eOnPeaCPZrn7hE/U/P+ zrcQ== X-Gm-Message-State: AOPr4FVZizNfT/v3YWHxNVmzOLh39Ql7igoEHf4tbIGLuapZoWVHGqAFqsBEfl8AgwlxHA== X-Received: by 10.37.11.22 with SMTP id 22mr4553677ybl.184.1463591053344; Wed, 18 May 2016 10:04:13 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:5f8:6d92:f864:13fe? ([2601:647:4d00:abf0:5f8:6d92:f864:13fe]) by smtp.gmail.com with ESMTPSA id k80sm5447740ywe.31.2016.05.18.10.04.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 May 2016 10:04:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_35AEF44E-8724-46F6-9872-D0DD0DAB1394"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 18 May 2016 10:04:08 -0700 Message-Id: References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> <004e01d1b123$77c73250$675596f0$@gmail.com> <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Denis Ovsienko , Bob Hinden , babel@ietf.org, Russ White <7riw77@gmail.com> Subject: Re: [babel] Making the drafts available [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:04:16 -0000 --Apple-Mail=_35AEF44E-8724-46F6-9872-D0DD0DAB1394 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Juliusz, > On May 18, 2016, at 9:41 AM, Juliusz Chroboczek = wrote: >=20 >> Okay -- this sounds like the right combination of things. Are the = drafts >> already available in a repository? >=20 > 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.) >=20 > I'm not sure if I can do that before we have a WG. So let's please = have > a WG. 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 >=20 > -- Juliusz >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_35AEF44E-8724-46F6-9872-D0DD0DAB1394 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXPKCIAAoJEK7rdBF357uoRmMIAJQTo+k0jIgXiqwGylV5xgud XuP5KILmbks7Q+ZjQDCJffADWGvD5gS0yef1zmgsJYcgxlPAcK54P1Af/Sdno1tt DnHzbA8oQ9gQr3VEh2DfNoaRHHyqAfogVO3vADV29X7i5Z8Jw7lboaRDjyTOmi3p 3TrwlJnTRbtmpPLUaoTQ53gEXblNeSQ70QRP8GJCrvPiDLRqBkZe0kohU7laUwol qK9g6wWSmjznlpfjVzhn44IdRbuu4eIi+rWgKP6i5nIOuFI9/5AoAuLHYsIADicb q31giuijTvJ+qifES05TXk2SwHd5cXr+LxRyjMww+9VwjK5zciPnXCTsAR2jOWU= =OJSf -----END PGP SIGNATURE----- --Apple-Mail=_35AEF44E-8724-46F6-9872-D0DD0DAB1394-- From nobody Wed May 18 10:09:30 2016 Return-Path: <7riw77@gmail.com> X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C5412D567 for ; Wed, 18 May 2016 10:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TolsjX859oCP for ; Wed, 18 May 2016 10:09:27 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128F612D1A7 for ; Wed, 18 May 2016 10:09:27 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id j74so54679475ywg.1 for ; Wed, 18 May 2016 10:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=GQfbm2aKxR+tvf1jktL3X/u09bgwl3ld0Q866MhPl00=; b=vIG6DB79/0E8pMmfS/dS1EkvNmbVDsvTS4vPAcoj6/BF98cIRccyefyIKOxkc/IMoT 9CCBEl6Kj+gdFahlbMbbIQ0zPRlu8CP6HWYGYls3KjiNf5lh/mHYQ0Dcj6RTt3LN+YmH m76DJwwkkYifxkwL5CxExOo/4/ZGw20d6Pg3JedRob3MySUfy5xHNPuYHLkQ3qbxR4zk LH9ZeY2nPNf7uBFzl+2KBpWX18yPNHaZMFL5NY7gZuJ3hfE6LYm+I5OPahBrH94IuUBo N8D4lOXhBxE6kICJBHvr+k52xzb8y2dRhWzqaQpcYoqIqqF0qpYgksfhxi6QGt6ZGF93 nbBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=GQfbm2aKxR+tvf1jktL3X/u09bgwl3ld0Q866MhPl00=; b=JEFzYEBrzjjMG8w37GhyAvvBiajol/IoVZXULy9TynzJe9XIlbocIw92/c6doo/wO7 n8UC9PeFDFmTicfl1/Ij1dxtgaOKL2RUs1hukYlmvsXsGtxHjGpwMjh8OxkuKTjynozX 3ZhGRvHfWe5pTZtxhq+f3ILfz1R0T8+QwIDBGqahVxqYwDjMsJI6YZ1tpBE4tj7b19/J JSYwKkMyp85Aif/gtziYzDDSmqB5vIUgaeTAv6ItH8dSTjsbiIROQSjFkYbJ4K2uqZXX 64biKlQj9RT6aUciG3iAq9Retve669sTCAvha5oDfZ62usGNpsHcwlUdq54W1wcUIF+K V+2w== X-Gm-Message-State: AOPr4FVh9BPSwCPOXLbzeo7ALzMGfop1mOm6xbFLmPIOQIZ5TSfExsxUUyRBpe8Sqr6aWQ== X-Received: by 10.37.214.150 with SMTP id n144mr4595331ybg.126.1463591366327; Wed, 18 May 2016 10:09:26 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id t133sm5428059ywe.54.2016.05.18.10.09.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 10:09:25 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Bob Hinden'" , "'Juliusz Chroboczek'" References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> <004e01d1b123$77c73250$675596f0$@gmail.com> <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Date: Wed, 18 May 2016 13:09:11 -0400 Message-ID: <028601d1b127$ffbef2c0$ff3cd840$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFYoAHWEHtoxVT8DhtHOznazgjQXwJ4U7ZaAUvKXswCxUi1WAILToIYAqgKpE0CUrJiLgGTn+EtAjiqNvICBTieSwHqMCMcAkOPhtQB8u1AuQHD8f3in9bjSgA= Content-Language: en-us Archived-At: Cc: 'Denis Ovsienko' , babel@ietf.org Subject: Re: [babel] Making the drafts available [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:09:28 -0000 > it allows for txt and xml to be submitted. This can be done for individual and > w.g. drafts. Yep -- it should... :-) Russ From nobody Wed May 18 10:17:38 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE25512D5EB for ; Wed, 18 May 2016 10:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EXMjzlXKNYu for ; Wed, 18 May 2016 10:17:35 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EB812D53B for ; Wed, 18 May 2016 10:17:34 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4IHHW0d001673; Wed, 18 May 2016 19:17:32 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CBCFA61FA2; Wed, 18 May 2016 19:17:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id xbm5ZLDbQosq; Wed, 18 May 2016 19:17:31 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 364AC61FA1; Wed, 18 May 2016 19:17:31 +0200 (CEST) Date: Wed, 18 May 2016 19:17:30 +0200 Message-ID: <87wpmr70b9.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Bob Hinden In-Reply-To: References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> <004e01d1b123$77c73250$675596f0$@gmail.com> <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 18 May 2016 19:17:32 +0200 (CEST) X-Miltered: at korolev with ID 573CA3AC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573CA3AC.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573CA3AC.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: babel@ietf.org, Russ White <7riw77@gmail.com> Subject: Re: [babel] Making the drafts available [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:17:37 -0000 > 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. 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 nobody Wed May 18 10:52:59 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62912D61A for ; Wed, 18 May 2016 10:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFaUSOi5Imtm for ; Wed, 18 May 2016 10:52:55 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922EE12D5F0 for ; Wed, 18 May 2016 10:52:55 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id qe5so95281352igc.1 for ; Wed, 18 May 2016 10:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=BFA0KEfOtpIVFQ2xijK04ZhE49P9i2y0S3Vz/zpTYBg=; b=XxOcRI2XiiyjCa2+NlFXMk3mAzIVcn6AOv1CSB4ZNCeq/xJIXlGK3b2Q3XGmDszWoN YqmHT9esSYgDlOAr+S1/bqVVZPeJm1Hf4xkqXf/T9J3qySDLX9fPFcedXzhzldGkS6Kg A2OeSamGi356Fmhrvn0R64YkRHSBTviwsu3hZFO9Yru5nAcjvChvESEgmeMYNaWCi6BK laHcaS1U6LzRWPvNAnSsho/h3hlRtjhhN9rwtBf7mUOiiYDsVz1TvRmSGNGUKA+RYmTk QPCnT60ktC/+Ig+CMFV4Ii7HvmS8I420TH3Yew7UcfygnNp787xphBRhXKG5NLdsJb1E DV+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=BFA0KEfOtpIVFQ2xijK04ZhE49P9i2y0S3Vz/zpTYBg=; b=H6WYmJTP1UCmzYdHCvJNQ91Sq0K1AZbxI+PagpZsvGV0zg29VcHfpLWDLjqI+lMA+H hl4pVGAChchCxZgCSTVTtOe62wFpIXLTU6M3MUWca19YReQMq+y+jp0a8yxQYurihRTU 6C7bq1pBciaezU8arGu48LZVNqkE857Deup7h3yBg7IJh+d2c8HrQ2K8O8MzCobaPfRP P3lX2A8pJCTRJ5pwlb8CkTe53KiCyUSNkUwFbty2hB3ZHhWKIB9cFhUYGpctDOWexZfi RLpWNf7Ar0Ll/r1PKYrEir2ULATZNEnyDWbyaY1nFiF/TdRY68LaGVsiv2OcgkchapCY +eQA== X-Gm-Message-State: AOPr4FWN88J/X/1vDHygwKl9IoXOIWbpvygO3a+M7POphbW0H53CEmux9Thd1EQ10DRIfQ== X-Received: by 10.50.3.105 with SMTP id b9mr6502875igb.17.1463593974429; Wed, 18 May 2016 10:52:54 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id c200sm9176517itb.4.2016.05.18.10.52.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 May 2016 10:52:53 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F8998EE7-F961-46C0-ADDF-6AA8F2180D80"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <87wpmr70b9.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 18 May 2016 10:52:49 -0700 Message-Id: References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> <004e01d1b123$77c73250$675596f0$@gmail.com> <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> <87wpmr70b9.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Bob Hinden , babel@ietf.org, Russ White <7riw77@gmail.com> Subject: Re: [babel] Making the drafts available [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:52:57 -0000 --Apple-Mail=_F8998EE7-F961-46C0-ADDF-6AA8F2180D80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Juliusz, > On May 18, 2016, at 10:17 AM, Juliusz Chroboczek = wrote: >=20 >> I am pretty sure that when you submit a draft with the tool: >=20 >> https://datatracker.ietf.org/submit/ >=20 >> it allows for txt and xml to be submitted. >=20 > Yes, and all of my drafts were submitted with the XML attached. >=20 > 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. Probably draft-ietf-babel-rfc6126bis-00 :-) I agree that does require the w.g. to be created. >=20 > 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. 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 >=20 > -- Juliusz --Apple-Mail=_F8998EE7-F961-46C0-ADDF-6AA8F2180D80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXPKvyAAoJEK7rdBF357uoGawH/Rgco16elt4PsogDB5CGIvcr Q0P9BPhh68AQkdkTEYkwF/F7F/649uYNYiSN+Hw09YjYyMQdZAg69P2U8TnhBb7d MOoJIR7xVfywTTH97DFVu6BPLMlsIcPHLrs1t/R2gDXKxyb1QSmER2wXV28bezR6 xnPxzf2sQqKLbns3irVk8jCKdkbpPu3SBItMMn44mChp0R7DrCO7zGWu50woIt1/ dPREC6jYukos4FmOT61NzWPII5ewdNQN76KNC7ro+XiyrZ8y1RxH6ZLVlq/y65QO mgpvfCSGuW6bRCOWxcZ2DExh39Ecz1VA+NVv1+STb9VMc3dMgEj/5735OcXXl/4= =NT/g -----END PGP SIGNATURE----- --Apple-Mail=_F8998EE7-F961-46C0-ADDF-6AA8F2180D80-- From nobody Wed May 18 11:29:58 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497E012D63A for ; Wed, 18 May 2016 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gX41X7-Tm07 for ; Wed, 18 May 2016 11:29:56 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42F812D63D for ; Wed, 18 May 2016 11:29:54 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4IITqpt026453; Wed, 18 May 2016 20:29:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5378661FA3; Wed, 18 May 2016 20:29:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id dgGIe-IXfGWO; Wed, 18 May 2016 20:29:51 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 90C1F61FA2; Wed, 18 May 2016 20:29:50 +0200 (CEST) Date: Wed, 18 May 2016 20:29:50 +0200 Message-ID: <87twhv6wyp.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Bob Hinden In-Reply-To: References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> <004e01d1b123$77c73250$675596f0$@gmail.com> <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> <87wpmr70b9.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 18 May 2016 20:29:52 +0200 (CEST) X-Miltered: at korolev with ID 573CB4A0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573CB4A0.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573CB4A0.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Donald Eastlake , babel@ietf.org, Russ White <7riw77@gmail.com> Subject: Re: [babel] Making the drafts available [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 18:29:57 -0000 > Probably draft-ietf-babel-rfc6126bis-00 :-) > I agree that does require the w.g. to be created. [...] > 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. Donald, Russ, do you have any opinions? -- Juliusz From nobody Wed May 18 12:02:55 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DBD12D653 for ; Wed, 18 May 2016 12:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP1ZrYOzlT7n for ; Wed, 18 May 2016 12:02:51 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9134A12D648 for ; Wed, 18 May 2016 12:02:50 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id k7so110520lbm.0 for ; Wed, 18 May 2016 12:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f/IfhvwI0LsMfjakvenpbpvJcXlLufrjdAyippUvvCs=; b=CSmeuvzXPe4sxkREoyfyTU3Z0zEHiak8yju2PxQ/BL1mRW4iXxd7SAutD9ycMumrlr yCzvzxbKoHyUGRW0QgYqosxkdN7u2ROmLszhBtOSwgkv7pLRGLudXy6cOST4H0e2FROO lapijj3CM7R3joIZGT8ucK1M5C/Kt1PB3nnFeAdLevStJv3+D+ZU620/NuxbYKrAGMX0 5UE8KLasE+JksM32TpOFmU8Oulgq9HxpeJcUhTRz4gvmXDa6BnUEuP/wkNnk9eb6kZLd 7mX7EFsMiJ7Y701iILW/asZf9dmzpNPXN3dBW2YxZizDvFhCG/m10VPbZfGISyGPuILq 9uOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f/IfhvwI0LsMfjakvenpbpvJcXlLufrjdAyippUvvCs=; b=fjWpl5pbWqC9qGlIIlnL4cw0IhCOeq7/5KQLDnZZVuP35KiBhG+YsIIvmNvnu/oR+3 ATtSY6y09vg4zi3kPWjyJDOY/QmUQtgbxhSJioLiyTz5UXmARhqdqPT5dDn8w3E4M2/E siByseY9tC+kGMES6bG6rYaId97ksatK/8S5D0ovIuKDGKjIHp3WC1uskpAV+J7E8sDU JTtcq/Mq/xqOvP/luo5kN4WJg2gVPBqgu5P5/syCyuDqY90aRrO8MnORXnJblxhifnK6 236cdR/Yq7aI8SkKvVXby9vIdwKWyirNKLUW00XbNP85nm1zjdIoKaOnzqAEShFqekfd 0rSg== X-Gm-Message-State: AOPr4FXsaIShNDpD8LNiAJIzPFSNx/TlRemJp9wvfRHUdUKx+oB69CiMD9H7WXbbC7U+4Es/Nj+/WCt1T4z4xA== X-Received: by 10.112.169.8 with SMTP id aa8mr3141218lbc.110.1463598168759; Wed, 18 May 2016 12:02:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.153.135 with HTTP; Wed, 18 May 2016 12:02:09 -0700 (PDT) In-Reply-To: <87twhv6wyp.wl-jch@pps.univ-paris-diderot.fr> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> <87zirwhegc.wl-jch@pps.univ-paris-diderot.fr> <34C9F18B-3846-4B3B-BD78-8474451C7217@gmail.com> <87twi4haq8.wl-jch@pps.univ-paris-diderot.fr> <028901d1ac63$7e52cb30$7af86190$@gmail.com> <027b01d1ac93$50a07cc0$f1e17640$@gmail.com> <154c3e9adee.d0fe08b4160817.2231897530781522941@ovsienko.info> <004e01d1b123$77c73250$675596f0$@gmail.com> <87zirn71zk.wl-jch@pps.univ-paris-diderot.fr> <87wpmr70b9.wl-jch@pps.univ-paris-diderot.fr> <87twhv6wyp.wl-jch@pps.univ-paris-diderot.fr> From: Ted Lemon Date: Wed, 18 May 2016 15:02:09 -0400 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a11c3878af1804d05332280bd Archived-At: Cc: Donald Eastlake , Bob Hinden , Russ White <7riw77@gmail.com>, babel@ietf.org Subject: Re: [babel] Making the drafts available [was: Draft BABEL Charter] X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 19:02:53 -0000 --001a11c3878af1804d05332280bd Content-Type: text/plain; charset=UTF-8 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. On Wed, May 18, 2016 at 2:29 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > Probably draft-ietf-babel-rfc6126bis-00 :-) > > > I agree that does require the w.g. to be created. > > [...] > > > 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. > > Donald, Russ, do you have any opinions? > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --001a11c3878af1804d05332280bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You always have to submit a personal draft so that the wg = can adopt it. =C2=A0 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.

On Wed, May 1= 8, 2016 at 2:29 PM, Juliusz Chroboczek <jch@pps.univ-paris-did= erot.fr> wrote:
> Probably draft-ietf-babel-rfc6126bis-00=C2=A0 :-)

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

[...]

> True, but you might as well submit

>=C2=A0 =C2=A0draft-chroboczek-babel-rfc6126bis-00

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

Donald, Russ, do you have any opinions?

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

--001a11c3878af1804d05332280bd-- From nobody Wed May 18 12:41:22 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424A212D659 for ; Wed, 18 May 2016 12:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvI7NNd8uHVQ for ; Wed, 18 May 2016 12:41:19 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F75612B078 for ; Wed, 18 May 2016 12:41:19 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id x189so58837294ywe.3 for ; Wed, 18 May 2016 12:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=qYu5gEVi7XfkRjRQEc7vzdvrPF32OWAWmCC5zUSatc0=; b=RDTGisMLRMuKI1gLMaaL0Scg7B96pA14tliktfMQVQFywslLZ52T+eEAdxFNBmcNTe FB91VlY5geC3jslqRY3rqXYr+v11hU+bK6oTssNgThlh9wb7aoKUXm1BmvajL3c7SMhr mVxuh+9pvqiDvr1QcWc5ToiLoOcgsO511PXttICQmwiDw60/edXf3naxjEg1c1kSMkjE MaNDmVI1c19Iox2DDIR9FjU0VaO4M1ZQoW0IAHuRGxBDk01KUc1fErx91dyqe588nSgO 2N+Joh+9+ixBCTUqEQdAy6heWWW2JnzF/NDL1srgHISFqweq15ezjK/CUlEi/0UDNrUk WLYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qYu5gEVi7XfkRjRQEc7vzdvrPF32OWAWmCC5zUSatc0=; b=YDll4qfSRx5q5b1cLtbYLIIOP3QmDRzl9Qae1KJHYiqeuue7kYGat/u0tT8KNt4yWO UWRLXaoqDNYdxk99rpnivR7k/hGArduVPRmNPTG4loDC3peAK+fz3Xc9wKSjpxe7PURl PjaeSnmyX1eLFczD2QBF7O6MxcR+JnmGH+XaX+S2gU+ktAbo5jBra/Gsu2wR9+1Ic/// 4WkJ1b9rGx4piafOwMy8IBTvzblmy91CQ8+EM3cdbzoakbo58crlK1l1oSGwjQVPaBSm r+iwpY96BViUzkpOHHPQAGQYNmBRNqjG0ji4hcAnTxrpDIOiDC5Wmt0JLKP0/VWWMSkN zOWg== X-Gm-Message-State: AOPr4FXKAWqcUyjT9Mvsu+pZmNx/nVXhzxeaHTBRfpVeJqdO1LcOQbTaMnZDB6hfvSXxAAno9kYsOrThs4fVLg== MIME-Version: 1.0 X-Received: by 10.129.132.83 with SMTP id u80mr5654233ywf.7.1463600478409; Wed, 18 May 2016 12:41:18 -0700 (PDT) Received: by 10.13.217.85 with HTTP; Wed, 18 May 2016 12:41:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2016 15:41:18 -0400 Message-ID: From: Alia Atlas To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a114f2c989bde660533230a6a Archived-At: Cc: Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 19:41:21 -0000 --001a114f2c989bde660533230a6a Content-Type: text/plain; charset=UTF-8 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 new-work@ietf.org) that includes various other organizations (mostly SDOs); and return for a final approval on June 16. On Tue, May 17, 2016 at 3:12 PM, Donald Eastlake wrote: > 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 > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > > Charter for the Babel 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. > "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 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 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" > 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 > 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. > -- 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. > 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. > - 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. > > "-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." > - 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 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. > - The working group may choose to work on multicast aspects of Babel > 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." > - 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). > "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. > Link metric measurement or link metric calculation procedures > significantly more complex that those currently in Babel are out of > scope. > I'd like to see this better stated - including not focusing on wireless link measurement. I think this needs more discussion. > > > 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. > Please let's not make it a waterfall model. The Applicability can wait until the end. Thanks, Alia > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --001a114f2c989bde660533230a6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Donald,

This looks good in general.= =C2=A0 I have a few minor comments - but we should be
good to put= this on the IESG telechat for June 2 for internal review.=C2=A0 Then it wi= ll
have a period of 2 weeks for external review - where it is sen= t to a mailing list (called
= new-work@ietf.org) that includes various other organizations (mostly SD= Os); and
return for a final approval on June 16.

On Tue, May 17, 2016 at 3:1= 2 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.co= m



Charter for the Babel 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.=C2=A0 The core of the Babel protocol is described in
Experimental Independent Stream RFCs 6126 and 7557, with RFC 7298
describing security extensions.

= "The core of the Babel protocol and security extensions are described = in Experimental Independent Stream RFCs 6126, 7557, and 7298."
=C2=A0
These RFCs are the basis of three independent, open source
implementations.=C2=A0 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 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 that are relevant to such consideration<= br>

"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"
=C2=A0
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.
=C2=A0<= br>

=C2=A0
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

Could thi= s please be updated to=C2=A0
"-- resolve technical issues as= found during earlier reviews and ongoing
working group discussio= ns"

to more clearly indicate that the specifi= c set of needed changes isn't fixed.
=C2=A0
-- 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=C2=A0
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.

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

" - As the Proposed= Standard version of Babel is completed, an Applicability
Stateme= nt should be finalized to guide those potentially interested in deploying
Babel.=C2=A0 This Applicability Statement =C2=A0may include deploy= ment advice and will be
published as an RFC.
=C2=A0
- 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.


"-Address manageabili= ty of Babel by producing an informational model, for use
by other= network management, and a YANG module based on it, to be consistent
<= div>with the ongoing effort to use YANG modules in the Routing Area.=C2=A0 = This is required
as part of moving Babel to Proposed Standard.&qu= ot;
=C2=A0
- 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 is encouraged to keep its wiki updated with impl= ementation
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 proce= ss
but not after.
=C2=A0
- The working group may choose to work on multicast aspects of Babel
once the initial focus on Proposed Standard is met.

" - As a secondary focus, the working group m= ay work on multicast aspects
of Babel.=C2=A0 Such work should be = coordinated with PIM."
=C2=A0
- 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).

"An applicabil= ity statement will be produced as an Informational
RFC.=C2=A0 If multi= cast aspects are pursued, with AD and WG agreement,
then a milestone may be added for an associated document targeted = as
Proposed Standard.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
Link metric measurement or link metric calculatio= n procedures
significantly more complex that those currently in Babel are out of scope.

I'd like to see this = better stated - including not focusing on wireless link
measureme= nt. =C2=A0 I think this needs more discussion.=C2=A0

=C2=A0


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

Date=C2=A0 Milestone

=C2=A0X+1=C2=A0 WG adoption of Babel Applicability draft.

=C2=A0X+1=C2=A0 WG adoption of rfc6126bis draft.

=C2=A0X+4=C2=A0 WG adoption of Babel management (probably Yang) draft.

=C2=A0X+5=C2=A0 Submission of Babel Applicability draft to the IESG as
=C2=A0 =C2=A0 =C2=A0 Informational.

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

X+13=C2=A0 Submission of Babel management draft to IESG as Proposed
=C2=A0 =C2=A0 =C2=A0 Standard.
<= br>
Please let's not make it a waterfall model.=C2=A0 The App= licability can wait until the end.

Thanks,
Alia=C2=A0
=C2=A0
_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

--001a114f2c989bde660533230a6a-- From nobody Wed May 18 13:05:03 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FD712D6AA for ; Wed, 18 May 2016 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FslyK83dPkgS for ; Wed, 18 May 2016 13:05:02 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC2712D6A4 for ; Wed, 18 May 2016 13:05:01 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4IK4xnI020873; Wed, 18 May 2016 22:04:59 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BC51761FA1; Wed, 18 May 2016 22:04:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id LkuDuaiVC8IY; Wed, 18 May 2016 22:04:58 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 760F161F9D; Wed, 18 May 2016 22:04:58 +0200 (CEST) Date: Wed, 18 May 2016 22:04:58 +0200 Message-ID: <87inyb6sk5.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Donald Eastlake In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 18 May 2016 22:04:59 +0200 (CEST) X-Miltered: at korolev with ID 573CCAEB.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573CCAEB.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573CCAEB.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 20:05:03 -0000 > -- resolve technical issues found by recent reviews and the working > group discussions technical issues -> technical and editorial issues? I agree with Alia about "recent" being too specific. > -- 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. Too specific. Please remove this last sentence, or replace it with multiple items so it's clear it's just an example. > - The working group may choose to work on multicast aspects of Babel > once the initial focus on Proposed Standard is met. Very well put. > Link metric measurement or link metric calculation procedures > significantly more complex that those currently in Babel are out of > scope. I've already mentioned that this makes me uncomfortable. -- Juliusz From nobody Wed May 18 13:24:37 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404AD12D6E6 for ; Wed, 18 May 2016 13:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p--kFWw9C9G8 for ; Wed, 18 May 2016 13:24:32 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0AB12D6DC for ; Wed, 18 May 2016 13:24:28 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id x194so60144010ywd.0 for ; Wed, 18 May 2016 13:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=dGIy0EHE9Ku9Fwl8H+mgg2cTOZbJftXu9VkRk4uO5fY=; b=OEkYuZQ5W+KbA0YImCNa2/2B8gPhthDm5I8re5nMChWYB+XMyVUxKA/+YY0UqDA5fQ ZXDbX/ypjg2JDJR+5iijHZ7lGDwEyi1u5IKIut4T7pxK1Voa8UiN2Zj3o2ww6p5CjiG7 l6eg49mKtJ5uRMRM5b60BsV7hP+PtaPhi5bojv791yE0+VKA//NeLgIIsMZWqY5HWaPZ FxDmK6PbLJEXxrqMswzCSxVlulXb2uqiiQRPUemkuBxPVBUgcPcl2E8kFCQMk0p/5qDn GRz+kyGikTn+r64Tq9HxbrpX6zmqllj+3KEVlUB2JB40WxRZK6OCYPEK8sKCXVWzrecX NIMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dGIy0EHE9Ku9Fwl8H+mgg2cTOZbJftXu9VkRk4uO5fY=; b=bTLWcCJjuNWB3Evt/y6Xqw3XLMJu6NJIwLDpPtn+iuaWCZsSJiHW3DPot4XxosVZ4U EUz09mJ59+1jQXT/Hm1Tgsn84Mqkz+Vbjdrl4+0AnIxYWhc2vWJvWqEOrCp0AMDUX/Bz PJG4ykAhPNvdTZyj33UXBFLx3bF4tJOeN7Scp067gy2ZTYQPNcxRjFGTXtTQa0rmxlb9 yJrhs4+jgFKu5aPhNQPRpHwBME8clJKyxg76YnExQMNeorXfLQs1JMlQrnrXkrCwVwR5 Q06ptyaNQWbBVdYdP7pj3zaoEfRG6W7WT5Evym/wXlP/M4BxxlfjhmYkyAMOeiRZC/qy UQZw== X-Gm-Message-State: AOPr4FUR7lJigThKdBA8OgoidqO6CKFwSzKqLYXr5a+2noa6yQMZGGON32iOJqK416NuE4e4X/bVYHXU7UOKXA== MIME-Version: 1.0 X-Received: by 10.37.208.75 with SMTP id h72mr5040173ybg.137.1463603067910; Wed, 18 May 2016 13:24:27 -0700 (PDT) Received: by 10.13.217.85 with HTTP; Wed, 18 May 2016 13:24:27 -0700 (PDT) In-Reply-To: <04e901d1ab27$45831db0$d0895910$@gmail.com> References: <87zirxai3f.wl-jch@pps.univ-paris-diderot.fr> <04e901d1ab27$45831db0$d0895910$@gmail.com> Date: Wed, 18 May 2016 16:24:27 -0400 Message-ID: From: Alia Atlas To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=94eb2c055492f48321053323a402 Archived-At: Cc: Donald Eastlake , Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 20:24:35 -0000 --94eb2c055492f48321053323a402 Content-Type: text/plain; charset=UTF-8 On Tue, May 10, 2016 at 9:48 PM, Russ White <7riw77@gmail.com> wrote: > > > > 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. > > > > 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? > > 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. > 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 --94eb2c055492f48321053323a402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 10, 2016 at 9:48 PM, Russ White <7riw77@gmail.com> wr= ote:

> > I think that it is useful to mention that a sophisticated link me= tric
> > algorithm computed based upon the link qualities (i.e. for wirele= ss)
> > is out of scope for the initial charter.
>
> Does this mean that the WG will not be allowed to work on metrics, or<= br> > merely that it will not be required to work on that?

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

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

Now, n= ot in scope means that the WG won't accept drafts around it. =C2=A0 The= re might be
some discussions on the list or individual drafts but= those shouldn't distract from the
WG's focus and would o= nly be more relevant if and when the time for rechartering comes
= up.

Regards,
Alia
--94eb2c055492f48321053323a402-- From nobody Wed May 18 17:50:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6894412D1A9 for ; Wed, 18 May 2016 17:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9hcdJdNyY7D for ; Wed, 18 May 2016 17:50:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1FD912D517 for ; Wed, 18 May 2016 17:50:17 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4J0oF4w029106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 May 2016 02:50:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4J0oFGo000910; Thu, 19 May 2016 02:50:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id F1B1E61FA1; Thu, 19 May 2016 02:50:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id phs1B53nCNOm; Thu, 19 May 2016 02:50:13 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D973661F9D; Thu, 19 May 2016 02:50:12 +0200 (CEST) Date: Thu, 19 May 2016 02:50:12 +0200 Message-ID: <87fute7tx7.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ferry Huberts In-Reply-To: References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 19 May 2016 02:50:15 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 19 May 2016 02:50:15 +0200 (CEST) X-Miltered: at korolev with ID 573D0DC7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 573D0DC7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573D0DC7.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 573D0DC7.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573D0DC7.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 573D0DC7.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 00:50:22 -0000 > I was asking because at BattleMesh 2015 olsrd2 with ETT seemed to perform > much better than other protocols without it. My interpretation is that all protocols performed fine, with the exception of BATMAN. OLSRv2 performed very well under load, which I explain as it being more resilient to loss of control packets, while OLSRv1 collapsed under load, which I'm unable to explain. Perhaps a limitation of the implementation. http://docs.battlemesh.org/v8/1-the-mesh-of-death-adversity.html#results http://docs.battlemesh.org/v8/2-the-crossed-streams-jeopardy.html#results http://docs.battlemesh.org/v8/3-blowing-up-the-network.html#results We didn't do any long-range tests, which is where DAT should shine, so please don't conclude from these tests that DAT is not useful. There's no doubt that DAT performs better than hop count, which is what Standards Track OLSRv2 uses (DAT is experimental). DAT/ETT should in principle perform better than ETX (which is what Babeld uses by default), but we need more empirical data before we take the complexity hit. There's also the metric used by Lamparter in his hacked-up version of IS-IS, which has a lot of potential but tends to mis-estimate the quality of idle links. I could be wrong, but I believe it might be more promising than ETT/DAT, and more fun to implement. I'll definitely be working on this kind of issues, but don't hold your breath -- first item on my TODO is doing a formal evaluation of Z3. -- Juliusz From nobody Wed May 18 22:15:01 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9624712D0BA for ; Wed, 18 May 2016 22:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onxB4BNHg7ph for ; Wed, 18 May 2016 22:14:58 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B8112D0AF for ; Wed, 18 May 2016 22:14:57 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id e126so3049289lfg.2 for ; Wed, 18 May 2016 22:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qa5xsVTKuzuAtVG3QINIwtoXCwjD0Pmy4j39BR4TaeQ=; b=pM3ad9tbxdSPImhgg9af25i4KjqBCGM0vZG5t/0His8jSZadnps2HEmCEtjCxiLbrc r2tWdYChgUszt3WWqH64LKOZlPYqUbnalD3dJmEKlNFJ537Kf/sNk83OxZ0GJGMfyZ/L SJemjSILwS2LOgRAjPIIfHAbPQ9PraWG9vHtCFymFhJs0Ot0pWdRBPmyPEq3+ayEK1pi AY8MOLv/LGkdEWTHXWocOcTTvhNghD6rQ+jGxfkHnu4brnaFenjXVg3CgBIac2RX+73R J0hXqelmqcqUOvWw63cDcYzRuDpzZNjwx1xifvCVYqeBSDYDuLatlki2+EmRWSx6Hwo4 vpWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qa5xsVTKuzuAtVG3QINIwtoXCwjD0Pmy4j39BR4TaeQ=; b=lctM0poeJvFtuPanFNXwZeWK9XOt+EQ94Mr29ZMNK7ztzrOv3pME4Aug3w5nnZd0hC da5N+hMsRHgFtUNmUaNSiaXTzb3o9oZTvPWAJD7zy/2qvveX09bxuCVdsxfmiOOGhYWS qwjBoId8iXu+DPbdQfZtT/OVZp+qfItFNCR3vUXiDPuz66CBbSh//wcD8HbajqXawTON LeN5rERFQmGew3kYyHmDFtko2ZZKemfbB0spHFa67be4ywtS1rfqgUgh6+qcCSzrUmp+ oT37tE0+NfWkBAXBKzW740NIn1kzU1xT3Sxpi+WXIB0rA6DFsdSjEPfdYUH/cIzWgSIx snjg== X-Gm-Message-State: AOPr4FUO3UZzVM74qmxsrf5p/F7tBoUt/Ar/uy1v8z5npW23WDFsWpRPN5OSkmngAJBy+j6ZsAXTNkpYfsHiDA== X-Received: by 10.25.214.234 with SMTP id p103mr3913321lfi.35.1463634895886; Wed, 18 May 2016 22:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.30.73 with HTTP; Wed, 18 May 2016 22:14:26 -0700 (PDT) In-Reply-To: <87fute7tx7.wl-jch@pps.univ-paris-diderot.fr> References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> <87fute7tx7.wl-jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Thu, 19 May 2016 07:14:26 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ferry Huberts , babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 05:14:59 -0000 On Thu, May 19, 2016 at 2:50 AM, Juliusz Chroboczek wrote: > There's no doubt that DAT performs better than hop count, which is what > Standards Track OLSRv2 uses (DAT is experimental). DAT/ETT should in > principle perform better than ETX (which is what Babeld uses by default), > but we need more empirical data before we take the complexity hit. I think you are wrong on this point... OLSRv2 (RFC7181) defines the metric as an external process, it does say nothing about hopcount because everyone in the WG (now) knows that hopcount is really bad. Henning Rogge From nobody Wed May 18 22:51:46 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2207412B071 for ; Wed, 18 May 2016 22:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRCB0rMPSRx2 for ; Wed, 18 May 2016 22:51:42 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E0212B063 for ; Wed, 18 May 2016 22:51:41 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n129so18368222wmn.1 for ; Wed, 18 May 2016 22:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=RiAfJW3sPcUooN2wU0O4jNs1Pgfp+Evn3WVzodc70Dw=; b=RLnyX3fQhF4E5RIRPYHm5KOCwoSrkg0nPi6bCUgsX6YIaYHsVM8EZOip5KGbyT/2AC pDb9DkzojQ1JHFpXcbuxgpbJWeDA5VqiQrRrrD8NcwOD3Cx5QeeXyojqdkXCLhImQjjy 2OBYpvNKW817AKPIfUdEpXETJDoqSITsqinVZmwNpyoFFWrVbn9qRr9WNU3c7SQKx8u2 MuZ+W9cqIhuOG+WxBqwuB++pIXWTEk9a+k09qRuIws3vBtUGG2mnEAfqXeZkjryKMRQm 5au9H+oH6pJ/rHYuLj6eTNJt/xo3ZUUgjv5u/DwdL9c76cYoLcg74RfgMxp25dTt7BuC abxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=RiAfJW3sPcUooN2wU0O4jNs1Pgfp+Evn3WVzodc70Dw=; b=ghk0J/MYMqVETK18rtZK9XuKQCG4TQPp4479dTId5jZUvo+pN7T7604+w/DyJbMNJE EqczDp/YNF4F8WrBao4qiE9IUq8gpP7i7eW1taj1OagC6G2mn2N5QW6y6eAMEiu4+Etc NcMr0B7RThES1YSAzYn5vfBkLP1F+BWYjYU7KkgEtSKq9mCMF4RAD+Qyte5BkZzlWWSI 32DKPpMiVf6ZFR3ip0FUGgs/+apMacYAlrt57c/nZJyOTC3Cg9DIafk692beJU27clfU h7mYX0N69xKwntz+NxCL1SeX7WCTQ/0UuIBZ8eOXXHjspr0L/TvSgiDSrUMu2piXpoev G/Vw== X-Gm-Message-State: AOPr4FXZub1CMqw5X+POjbNZYGS4rqwUKOUUKNrl42707uojDt+k+WHUjjH+HPI1f6zbag== X-Received: by 10.28.188.7 with SMTP id m7mr11108132wmf.37.1463637100193; Wed, 18 May 2016 22:51:40 -0700 (PDT) Received: from [192.168.43.109] ([188.207.72.43]) by smtp.gmail.com with ESMTPSA id y3sm12385005wji.40.2016.05.18.22.51.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 May 2016 22:51:39 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_62A716F8-FE6C-4F89-9BE5-00C6B8229FAC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Teco Boot In-Reply-To: Date: Thu, 19 May 2016 07:51:36 +0200 Message-Id: References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> <87fute7tx7.wl-jch@pps.univ-paris-diderot.fr> To: Henning Rogge X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ferry Huberts , babel@ietf.org, Juliusz Chroboczek Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 05:51:44 -0000 --Apple-Mail=_62A716F8-FE6C-4F89-9BE5-00C6B8229FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Op 19 mei 2016, om 07:14 heeft Henning Rogge het = volgende geschreven: >=20 > On Thu, May 19, 2016 at 2:50 AM, Juliusz Chroboczek > wrote: >> There's no doubt that DAT performs better than hop count, which is = what >> Standards Track OLSRv2 uses (DAT is experimental). DAT/ETT should in >> principle perform better than ETX (which is what Babeld uses by = default), >> but we need more empirical data before we take the complexity hit. >=20 > I think you are wrong on this point... OLSRv2 (RFC7181) defines the > metric as an external process, it does say nothing about hopcount > because everyone in the WG (now) knows that hopcount is really bad. (the WG =3D=3D MANET WG) Without an (external) process providing link metric data, OLSRv2 (and = others...) fall back to hop-count. In fact, RFC7181 specifies hop-count as tie-breaker, if path costs are = equal. Let us not discuss implementation details on MANET stuff and DAT/ETX/ETT = metrics over here, this is the Babel protocol mailing list. We discussed metric encoding a lot in MANET. We decided a 16-bit field = for path costs is not sufficient. So in Babelv2 we could think of a = 32-bit metric field. Teco > Henning Rogge >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_62A716F8-FE6C-4F89-9BE5-00C6B8229FAC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXPVRoAAoJECQbXIDdIQWqS3UP/0+qw8no4oCZ+15y/p6bjtHZ 9hn6eZiA+RRUl/kOog/A/EtMOB/oVOXHbPCjzKAp1du22RzbOp4EcymfUJ+NxpuZ SO8ltCLxcW31jhcNFPAfHKuHeJLe3XDurl8gfQ3vkObpr4LMbhSmM5OMuBtFD85J 3Q+sjtA4bRsgiZfIJCEipTqwjHqi98En9dUfo+Qa91bINu3wCRvdjBBausoDwFev iBjwN0F8dGQeu+GegCy4rfLNMxbvuuFRQvJUGYWIDa3uunWw1bnqERf1KbuW/7/o 0Um3Ai7GqY0EZzZmdR4M3/LLKaqLkuUStskIcrpI8ag/nfRZZQj1UBe3bosayrhJ Jq6AFTzw5LLOYSVaOV7sfpP4JfjrOfVp6EaUU5y47mtNiOBV9pSsnk3ngbRPhAh6 2hQr//Zsz4es6ezw9urdTO5ZdBj7QOgaA/QtFrjt6s1Qa/8kS3PPoRA9oUzhb1qE G41EJkPWJEp2E/z6MrOwGxARKL/a7HBeiHp5shB9zKzr0Ytg7hnQqv2LHP60vG3I W1YtuhBFCyFfb2B9ElUtUIe2IMrWBJNte1IMYaSRYy/xduIqIo0QxKLk6q/NCWXj VkpRvsWcRr5B8vjZseRrxQ80QjhpQMTkRfoIyi7BMLhqQekXn13Dl2q0xcRRu0+l wCU3UM5YCqfUZMRAIvDW =idUa -----END PGP SIGNATURE----- --Apple-Mail=_62A716F8-FE6C-4F89-9BE5-00C6B8229FAC-- From nobody Thu May 19 03:33:19 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1243D12D872 for ; Thu, 19 May 2016 03:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnsANAyUbsEn for ; Thu, 19 May 2016 03:33:14 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EADA12D888 for ; Thu, 19 May 2016 03:33:11 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id v145so121249888oie.0 for ; Thu, 19 May 2016 03:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g2sGzgYd/6fEjppmfYn7kzDuF5xKsNcVR+rNMol/1kM=; b=OtyueU1YDVhjDLisgESE7p1QctxWoiDhqUZMEDyvO/fIf3fsBKiMsVNIvMEit/Mg6d jQgyQb5Xw5k9jeEbQHdjNpsELtvWHPOHnkftTqjAQoDRXq4YIkGbOzdZiXDpPWF0Pvmj Iuc0ODl7ceQqQ6Np7NQnqsVf5p0mWfx9uD6NdCXTuAGuDDpT0+rLXTUeBhyPQTNDT+G8 rRELKwjop1Wv+apPhZ1lX4YB4T5iKX3F9Z6Hs7sU529LKmBZltWryV/d8sIYN2NrRyWu tFIAqiCXf7fsPSF4QhbAC6urbOH3m7yYbiUNPetG0hNJpa+JfUBxmmldv+yJrbowRwRo gR7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g2sGzgYd/6fEjppmfYn7kzDuF5xKsNcVR+rNMol/1kM=; b=CyqsWUSZRTMxFyHg400XrBjo/3CzUzF1KmW9OGXeKGzIdDlMuGus/SH3GIQQspFW6i hInRNWmVw5/Z21oxRjAHm/LwNipe6/ugBtK9hpBrhgZMp04W3pJ+37DBrDkRlHVLOwwR YacPrQUXVtuyyN3pJp9mGdU1zF/KimpfRi2RkSNUQQXzPwqP0Lz4hgNX6Tqr3jvgHUz+ T3/WBlU65QKHkvn7EUnv58fHcztlEVQr3RDAiNPx9X+3iScvz8Dui8dgYg7u1x+7caKX nnHfrpcVrHjYuu8dloHHTW70u3+dq+ErTtckflHkwvOsZqZ72U8Bjtso3RC+FdTvP9yl c+GA== X-Gm-Message-State: AOPr4FXfUxboiXX7ZaFL6Yl/oJ6aLq1vPj77rMrIUMuwK++Ku2pxlDVmLXKWA2rKEuXko3fDp3S4QjxFPR9C+Q== X-Received: by 10.202.65.133 with SMTP id o127mr7443339oia.43.1463653990829; Thu, 19 May 2016 03:33:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.216 with HTTP; Thu, 19 May 2016 03:32:56 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 19 May 2016 06:32:56 -0400 Message-ID: To: Alia Atlas Content-Type: multipart/mixed; boundary=001a113dc862330a9205332f80d5 Archived-At: Cc: Gabriel Kerneis , Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 10:33:18 -0000 --001a113dc862330a9205332f80d5 Content-Type: text/plain; charset=UTF-8 Hi Alia and Gabriel, Thanks for your good inputs. Attached is an updated draft and a wdiff against the previous version I sent out. >> Link metric measurement or link metric calculation procedures >> significantly more complex that those currently in Babel are out of >> scope. > > I'd like to see this better stated - including not focusing on wireless link > 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 =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, May 18, 2016 at 3:41 PM, Alia Atlas wrote: > 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 > new-work@ietf.org) that includes various other organizations (mostly SDOs); > and > return for a final approval on June 16. > > On Tue, May 17, 2016 at 3:12 PM, Donald Eastlake wrote: >> >> 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 >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> >> >> Charter for the Babel 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. > > > "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 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 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" > >> >> 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 > > > 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. > >> >> -- 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. > > > 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. > >> >> - 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. >> > > "-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." > >> >> - 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 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. > >> >> - The working group may choose to work on multicast aspects of Babel >> 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." > >> >> - 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). > > > "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. > >> >> Link metric measurement or link metric calculation procedures >> significantly more complex that those currently in Babel are out of >> scope. > > > I'd like to see this better stated - including not focusing on wireless link > measurement. I think this needs more discussion. > >> >> >> 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. > > > Please let's not make it a waterfall model. The Applicability can wait > until the end. > > Thanks, > Alia --001a113dc862330a9205332f80d5 Content-Type: text/plain; charset=US-ASCII; name="BabelCharter-05.txt" Content-Disposition: attachment; filename="BabelCharter-05.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ioe557uf1 Q2hhcnRlciBmb3IgdGhlIEJhYmVsIFdvcmtpbmcgR3JvdXAKCkJhYmVsIGlzIGEgbG9vcC1hdm9p ZGluZywgZGlzdGFuY2UgdmVjdG9yIHJvdXRpbmcgcHJvdG9jb2wgd2l0aCBnb29kCnByb3Zpc2lv bnMgZm9yIGR5bmFtaWNhbGx5IGNvbXB1dGVkIGxpbmsgbWV0cmljcy4gSXQgaXMgcm9idXN0IGV2 ZW4gaW4KdGhlIHByZXNlbmNlIG9mIGxpbmsgbWV0cmljIG9zY2lsbGF0aW9ucyBhbmQgdGhlIGZh aWx1cmUgb2YKdHJhbnNpdGl2aXR5LiAgVGhlIGNvcmUgb2YgdGhlIEJhYmVsIHByb3RvY29sIGFu ZCBzZWN1cml0eSBleHRlbnNpb25zCmFyZSBkZXNjcmliZWQgaW4gRXhwZXJpbWVudGFsIEluZGVw ZW5kZW50IFN0cmVhbSBSRkNzIDYxMjYsIDc1NTcsIGFuZAo3Mjk4LgoKVGhlc2UgUkZDcyBhcmUg dGhlIGJhc2lzIG9mIHRocmVlIGluZGVwZW5kZW50LCBvcGVuIHNvdXJjZQppbXBsZW1lbnRhdGlv bnMuICBUaGVyZSBpcyBzb21lIHByb2R1Y3Rpb24gZGVwbG95bWVudCBvZiB0aGVzZQppbXBsZW1l bnRhdGlvbnMsIG5vdGFibHkgaW4gaHlicmlkIG5ldHdvcmtzIChuZXR3b3JrcyB0aGF0IGluY2x1 ZGUKY2xhc3NpY2FsLCB3aXJlZCBwYXJ0cyB3aXRoIG1lc2h5IHJhZGlvIGJpdHMpIGFuZCBpbiBn bG9iYWwgb3ZlcmxheQpuZXR3b3JrcyAobmV0d29ya3MgYnVpbHQgb3V0IG9mIGxhcmdlIG51bWJl cnMgb2YgdHVubmVscyBzcGFubmluZwpjb250aW5lbnRzKS4KClRoZSB3b3JraW5nIGdyb3VwIHdp bGwgZm9jdXMgb24gbW92aW5nIHRoZSBCYWJlbCBwcm90b2NvbCB0byBJRVRGClByb3Bvc2VkIFN0 YW5kYXJkIHdpdGggSUVURiByZXZpZXcuIFRoaXMgaW5jbHVkZXMgY2xhcmlmeWluZyBSRkMgNjEy NgphbmQgaW50ZWdyYXRpbmcgUkZDIDc1NTcgYW5kIGZlZWRiYWNrIHByb3ZpZGVkIGJ5IGluZGVw ZW5kZW50CmltcGxlbWVudGF0aW9ucywgYW5kIHJlc29sdmluZyB0aGUgY29tbWVudHMgcHJlc2Vu dGVkIGF0IHRoZSBCQUJFTCBCb0YKYXQgSUVURi05NSBhbmQgZHVyaW5nIG9uZ29pbmcgV0cgcmV2 aWV3LiBPdGhlciBkb2N1bWVudHMgdGhhdCBhcmUKcmVsZXZhbnQgdG8gc3VjaCBjb25zaWRlcmF0 aW9uIGNhbiBhbHNvIGJlIHByb2R1Y2VkLiBQYXJ0aWN1bGFyCmVtcGhhc2lzIHdpbGwgYmUgcGxh Y2VkIG9uIHdvcmsgbmVlZGVkIGZvciBhIFByb3Bvc2VkIFN0YW5kYXJkIHJvdXRpbmcKcHJvdG9j b2wsIHN1Y2ggYXMgZW5zdXJpbmcgbWFuYWdlYWJpbGl0eSBhbmQgc3Ryb25nIHNlY3VyaXR5LgoK V29yayBJdGVtczoKCi0gUHJvZHVjZSBhIHJldmlzaW9uIG9mIFJGQyA2MTI2IHN1aXRhYmxlIGZv ciBwdWJsaWNhdGlvbiBhcyBhClByb3Bvc2VkIFN0YW5kYXJkLCBhbmQgd29yayB3aXRoIHRoZSBJ RVNHIGZvciBpdHMgYXBwcm92YWwKLS0gaW5jb3Jwb3JhdGUgaW4gdGhlIHJldmlzaW9uIGRldmVs b3BtZW50cyBzaW5jZSBSRkMgNjEyNgotLSByZXNvbHZlIHRlY2huaWNhbCBpc3N1ZXMgYXMgZm91 bmQgZHVyaW5nIGVhcmxpZXIgcmV2aWV3cyBhbmQKb25nb2luZyB3b3JraW5nIGdyb3VwIGRpc2N1 c3Npb25zCi0tIGluY2x1ZGUgaW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiB0aGUgZXh0ZW5zaWJp bGl0eSB3b3JrIGluClJGQyA3NTU3Ci0tIGNvbnNpZGVyIGFueSBpbXBvcnRhbnQgY2hhbmdlcyBi YXNlZCBvbiBleHBlcmllbmNlIHdpdGggQmFiZWwgdG8KZGF0ZS4KCi0gQWRkcmVzcyBzZWN1cml0 eSBuZWVkcyBmb3IgQkFCRUwuIFRoaXMgbWF5IGluY2x1ZGUgdXNpbmcgdGhlCnRlY2huaXF1ZXMg aW4gUkZDIDcyOTgsIG9yIG90aGVyIGFsdGVybmF0aXZlcy4gU2VjdXJpdHkgbWF5IGJlCmluY2x1 ZGVkIGluIHRoZSBiYXNlIHNwZWMgb3IgdGhlIGJhc2Ugc3BlYyBtYXkgbm9ybWF0aXZlbHkgcmVm ZXJlbmNlIGEKc2VwYXJhdGUgUHJvcG9zZWQgU3RhbmRhcmQgc3BlY2lmaWNhdGlvbi4gVGhpcyBp cyByZXF1aXJlZCBhcyBwYXJ0IG9mCm1vdmluZyBCYWJlbCB0byBQcm9wb3NlZCBTdGFuZGFyZC4K Ci0gQXMgdGhlIFByb3Bvc2VkIFN0YW5kYXJkIHZlcnNpb24gb2YgQmFiZWwgaXMgY29tcGxldGVk LCBhbgpBcHBsaWNhYmlsaXR5IFN0YXRlbWVudCBzaG91bGQgYmUgZmluYWxpemVkIHRvIGd1aWRl IHRob3NlIHBvdGVudGlhbGx5CmludGVyZXN0ZWQgaW4gZGVwbG95aW5nIEJhYmVsLiAgVGhpcyBB cHBsaWNhYmlsaXR5IFN0YXRlbWVudCBtYXkKaW5jbHVkZSBkZXBsb3ltZW50IGFkdmljZSBhbmQg d2lsbCBiZSBwdWJsaXNoZWQgYXMgYW4gUkZDLgoKLSBBZGRyZXNzIG1hbmFnZWFiaWxpdHkgb2Yg QmFiZWwgYnkgcHJvZHVjaW5nIGFuIGluZm9ybWF0aW9uYWwgbW9kZWwsCmZvciB1c2UgYnkgb3Ro ZXIgbmV0d29yayBtYW5hZ2VtZW50LCBhbmQgYSBZQU5HIG1vZHVsZSBiYXNlZCBvbiBpdCwgdG8K YmUgY29uc2lzdGVudCB3aXRoIHRoZSBvbmdvaW5nIGVmZm9ydCB0byB1c2UgWUFORyBtb2R1bGVz IGluIHRoZQpSb3V0aW5nIEFyZWEuICBUaGlzIGlzIHJlcXVpcmVkIGFzIHBhcnQgb2YgbW92aW5n IEJhYmVsIHRvIFByb3Bvc2VkClN0YW5kYXJkLgoKLSBUaGUgd29ya2luZyBncm91cCBpcyBlbmNv dXJhZ2VkIHRvIGtlZXAgaXRzIHdpa2kgdXBkYXRlZCB3aXRoCmltcGxlbWVudGF0aW9uIGV4cGVy aWVuY2Ugd2l0aCBCYWJlbCBzbyB0aGF0IG5ldyBXRyBwYXJ0aWNpcGFudHMgY2FuCnVuZGVyc3Rh bmQgdGhlIHN0YXRlIHRoYXQgaXMgZHJpdmluZyB0aGlzIHdvcmsgYW5kIHRoZSBleHBlcmllbmNl CmRyaXZpbmcgY2hhbmdlcy4KCi0gQXMgYSBzZWNvbmRhcnkgZm9jdXMsIHRoZSB3b3JraW5nIGdy b3VwIG1heSB3b3JrIG9uIG11bHRpY2FzdAphc3BlY3RzIG9mIEJhYmVsLiAgU3VjaCB3b3JrIHNo b3VsZCBiZSBjb29yZGluYXRlZCB3aXRoIFBJTS4KCi0gQ29vcmRpbmF0ZSB3aXRoIG90aGVyIHdv cmtpbmcgZ3JvdXBzIGFzIG5lZWRlZC4KClRodXMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgcHJv ZHVjZSBhIFByb3Bvc2VkIFN0YW5kYXJkIEJhYmVsCnNwZWNpZmljYXRpb24sIGluY2x1ZGluZyBv ciBwYWlyZWQgd2l0aCBhIHN1aXRhYmxlIHNlY3VyaXR5CnNwZWNpZmljYXRpb24gZm9yIEJBQkVM LiBJdCB3aWxsIGFsc28gcHJvZHVjZSBhIG1hbmFnZW1lbnQgbW9kZWwgZm9yCkJBQkVMIGFzIGEg UHJvcG9zZWQgU3RhbmRhcmQgUkZDLiBBbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCB3aWxsIGJl CnByb2R1Y2VkIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLiAgSWYgbXVsdGljYXN0IGFzcGVjdHMg YXJlIHB1cnN1ZWQsCndpdGggQUQgYW5kIFdHIGFncmVlbWVudCwgdGhlbiBhIG1pbGVzdG9uZSBt YXkgYmUgYWRkZWQgZm9yIGFuCmFzc29jaWF0ZWQgZG9jdW1lbnQgdGFyZ2V0ZWQgYXMgUHJvcG9z ZWQgU3RhbmRhcmQuCgpMaW5rIG1ldHJpYyBtZWFzdXJlbWVudCBvciBsaW5rIG1ldHJpYyBjYWxj dWxhdGlvbiBwcm9jZWR1cmVzCnNpZ25pZmljYW50bHkgbW9yZSBjb21wbGV4IHRoYXQgdGhvc2Ug Y3VycmVudGx5IGluIEJhYmVsIGFyZSBvdXQgb2YKc2NvcGUuCgoKCkluaXRpYWwgTWlsZXN0b25l cwooIkRhdGUiIGlzIGEgbW9udGggd2hlcmUgWCBpcyB0aGUgbW9udGggb2YgQ2hhcnRlciBhcHBy b3ZhbCkKCkRhdGUgIE1pbGVzdG9uZQoKIFgrMSAgV0cgYWRvcHRpb24gb2YgQmFiZWwgQXBwbGlj YWJpbGl0eSBkcmFmdC4KCiBYKzEgIFdHIGFkb3B0aW9uIG9mIHJmYzYxMjZiaXMgZHJhZnQuCgog WCs0ICBXRyBhZG9wdGlvbiBvZiBCYWJlbCBtYW5hZ2VtZW50IChZYW5nIC8gRGF0YSBNb2RlbCkg ZHJhZnQuCgpYKzEwICBTdWJtaXNzaW9uIG9mIHJmYzYxMjZiaXMgZHJhZnQgdG8gdGhlIElFU0cg YXMgUHJvcG9zZWQgU3RhbmRhcmQuCgpYKzEyICBTdWJtaXNzaW9uIG9mIEJhYmVsIG1hbmFnZW1l bnQgZHJhZnQgdG8gSUVTRyBhcyBQcm9wb3NlZAogICAgICBTdGFuZGFyZC4KClgrMTMgIFN1Ym1p c3Npb24gb2YgQmFiZWwgQXBwbGljYWJpbGl0eSBkcmFmdCB0byB0aGUgSUVTRyBhcwogICAgICBJ bmZvcm1hdGlvbmFsLgo= --001a113dc862330a9205332f80d5 Content-Type: text/html; charset=US-ASCII; name="wdiff BabelCharter-04 versus Charter-05.html" Content-Disposition: attachment; filename="wdiff BabelCharter-04 versus Charter-05.html" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ioe54zoh0 CjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwMzApaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm IC0tPgo8aHRtbD48aGVhZD48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+PHRpdGxlPndkaWZmIENoYXJ0ZXIxLTA0LnR4dCBC YWJlbENoYXJ0ZXItMDUudHh0PC90aXRsZT48bGluayByZWw9InN0eWxlc2hlZXQiIHR5cGU9InRl eHQvY3NzIiBocmVmPSJjaHJvbWUtZXh0ZW5zaW9uOi8vcGtlaGdpamNtcGRoZmJkYmJua2lqb2Rt ZGpoYmpsZ3Avc2tpbi9zb2NpYWx3aWRnZXRzLmNzcyI+PC9oZWFkPjxib2R5Pgo8cHJlPkNoYXJ0 ZXIgZm9yIHRoZSBCYWJlbCBXb3JraW5nIEdyb3VwCgpCYWJlbCBpcyBhIGxvb3AtYXZvaWRpbmcs IGRpc3RhbmNlIHZlY3RvciByb3V0aW5nIHByb3RvY29sIHdpdGggZ29vZApwcm92aXNpb25zIGZv ciBkeW5hbWljYWxseSBjb21wdXRlZCBsaW5rIG1ldHJpY3MuIEl0IGlzIHJvYnVzdCBldmVuIGlu CnRoZSBwcmVzZW5jZSBvZiBsaW5rIG1ldHJpYyBvc2NpbGxhdGlvbnMgYW5kIHRoZSBmYWlsdXJl IG9mCnRyYW5zaXRpdml0eS4gIFRoZSBjb3JlIG9mIHRoZSBCYWJlbCBwcm90b2NvbCA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj5pczwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48 Zm9udCBjb2xvcj0iZ3JlZW4iIHNpemU9IisxIj5hbmQgc2VjdXJpdHkgZXh0ZW5zaW9ucwphcmU8 L2ZvbnQ+PC9zdHJvbmc+IGRlc2NyaWJlZCBpbiBFeHBlcmltZW50YWwgSW5kZXBlbmRlbnQgU3Ry ZWFtIFJGQ3MgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+NjEyNiBhbmQ8L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIrMSI+NjEyNiw8 L2ZvbnQ+PC9zdHJvbmc+IDc1NTcsIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCIgc2l6ZT0iKzEi PndpdGggUkZDIDcyOTgKZGVzY3JpYmluZyBzZWN1cml0eSBleHRlbnNpb25zLjwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iIHNpemU9IisxIj5hbmQKNzI5OC48L2Zv bnQ+PC9zdHJvbmc+CgpUaGVzZSBSRkNzIGFyZSB0aGUgYmFzaXMgb2YgdGhyZWUgaW5kZXBlbmRl bnQsIG9wZW4gc291cmNlCmltcGxlbWVudGF0aW9ucy4gIFRoZXJlIGlzIHNvbWUgcHJvZHVjdGlv biBkZXBsb3ltZW50IG9mIHRoZXNlCmltcGxlbWVudGF0aW9ucywgbm90YWJseSBpbiBoeWJyaWQg bmV0d29ya3MgKG5ldHdvcmtzIHRoYXQgaW5jbHVkZQpjbGFzc2ljYWwsIHdpcmVkIHBhcnRzIHdp dGggbWVzaHkgcmFkaW8gYml0cykgYW5kIGluIGdsb2JhbCBvdmVybGF5Cm5ldHdvcmtzIChuZXR3 b3JrcyBidWlsdCBvdXQgb2YgbGFyZ2UgbnVtYmVycyBvZiB0dW5uZWxzIHNwYW5uaW5nCmNvbnRp bmVudHMpLgoKVGhlIHdvcmtpbmcgZ3JvdXAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXpl PSIrMSI+aXM8L2ZvbnQ+PC9zdHJpa2U+IHdpbGwgZm9jdXMgb24gbW92aW5nIHRoZSBCYWJlbCBw cm90b2NvbCB0byBJRVRGClByb3Bvc2VkIFN0YW5kYXJkIHdpdGggSUVURiByZXZpZXcuIFRoaXMg aW5jbHVkZXMgY2xhcmlmeWluZyBSRkMgNjEyNgphbmQgaW50ZWdyYXRpbmcgUkZDIDc1NTcgYW5k IGZlZWRiYWNrIHByb3ZpZGVkIGJ5IGluZGVwZW5kZW50CmltcGxlbWVudGF0aW9ucywgYW5kIHJl c29sdmluZyB0aGUgY29tbWVudHMgcHJlc2VudGVkIGF0IHRoZSBCQUJFTCBCb0YKYXQgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+SUVURi05NS48L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIrMSI+SUVURi05NSBhbmQgZHVyaW5nIG9u Z29pbmcgV0cgcmV2aWV3LjwvZm9udD48L3N0cm9uZz4gT3RoZXIgZG9jdW1lbnRzIHRoYXQgYXJl CnJlbGV2YW50IHRvIHN1Y2ggY29uc2lkZXJhdGlvbiBjYW4gYWxzbyBiZSBwcm9kdWNlZC4gUGFy dGljdWxhcgplbXBoYXNpcyB3aWxsIGJlIHBsYWNlZCBvbiB3b3JrIG5lZWRlZCBmb3IgYSBQcm9w b3NlZCBTdGFuZGFyZCByb3V0aW5nCnByb3RvY29sLCBzdWNoIGFzIGVuc3VyaW5nIG1hbmFnZWFi aWxpdHkgYW5kIHN0cm9uZyBzZWN1cml0eS4KCldvcmsgSXRlbXM6CgotIFByb2R1Y2UgYSByZXZp c2lvbiBvZiBSRkMgNjEyNiBzdWl0YWJsZSBmb3IgcHVibGljYXRpb24gYXMgYQpQcm9wb3NlZCBT dGFuZGFyZCwgYW5kIHdvcmsgd2l0aCB0aGUgSUVTRyBmb3IgPHN0cm9uZz48Zm9udCBjb2xvcj0i Z3JlZW4iIHNpemU9IisxIj5pdHM8L2ZvbnQ+PC9zdHJvbmc+IGFwcHJvdmFsIDxzdHJpa2U+PGZv bnQgY29sb3I9InJlZCIgc2l6ZT0iKzEiPm9mIHNhbWU8L2ZvbnQ+PC9zdHJpa2U+Ci0tIGluY29y cG9yYXRlIGluIHRoZSByZXZpc2lvbiBkZXZlbG9wbWVudHMgc2luY2UgUkZDIDYxMjYKLS0gcmVz b2x2ZSB0ZWNobmljYWwgaXNzdWVzIDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIr MSI+YXM8L2ZvbnQ+PC9zdHJvbmc+IGZvdW5kIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCIgc2l6 ZT0iKzEiPmJ5IHJlY2VudDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3Jl ZW4iIHNpemU9IisxIj5kdXJpbmcgZWFybGllcjwvZm9udD48L3N0cm9uZz4gcmV2aWV3cyBhbmQg PHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+dGhlPC9mb250Pjwvc3RyaWtlPgo8 c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPm9uZ29pbmc8L2ZvbnQ+PC9zdHJv bmc+IHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2lvbnMKLS0gaW5jbHVkZSBpbiB0aGUgYmFzZSBzcGVj aWZpY2F0aW9uIHRoZSBleHRlbnNpYmlsaXR5IHdvcmsgaW4KUkZDIDc1NTcKLS0gY29uc2lkZXIg YW55IGltcG9ydGFudCBjaGFuZ2VzIGJhc2VkIG9uIGV4cGVyaWVuY2Ugd2l0aCBCYWJlbCB0bwpk YXRlLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj5UaGlzIG1heSBpbmNsdWRl IGRpc2N1c3Npb24gb2YgaXNzdWVzIHN1Y2ggYXMgdGhlIHNpemUgb2YgdGhlCmRlZmF1bHQgbWV0 cmljLjwvZm9udD48L3N0cmlrZT4KCi0gQWRkcmVzcyBzZWN1cml0eSBuZWVkcyBmb3IgQkFCRUwu IFRoaXMgbWF5IGluY2x1ZGUgdXNpbmcgdGhlCnRlY2huaXF1ZXMgaW4gPHN0cmlrZT48Zm9udCBj b2xvcj0icmVkIiBzaXplPSIrMSI+UkY8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIiBzaXplPSIrMSI+UkZDPC9mb250Pjwvc3Ryb25nPiA3Mjk4LCBvciBvdGhlciBh bHRlcm5hdGl2ZXMuIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCIgc2l6ZT0iKzEiPlRoaXM8L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIrMSI+U2VjdXJp dHk8L2ZvbnQ+PC9zdHJvbmc+IG1heSBiZSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9 IisxIj5ieSBpbmNsdXNpb248L2ZvbnQ+PC9zdHJpa2U+CjxzdHJvbmc+PGZvbnQgY29sb3I9Imdy ZWVuIiBzaXplPSIrMSI+aW5jbHVkZWQ8L2ZvbnQ+PC9zdHJvbmc+IGluIHRoZSBiYXNlIHNwZWMg b3IgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+Ynkgbm9ybWF0aXZlPC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPnRoZSBiYXNl IHNwZWMgbWF5IG5vcm1hdGl2ZWx5PC9mb250Pjwvc3Ryb25nPiByZWZlcmVuY2UgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+dG88L2ZvbnQ+PC9zdHJpa2U+IGEKc2VwYXJhdGUg PHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+cHJvcG9zZWQKc3RhbmRhcmQ8L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIrMSI+UHJvcG9z ZWQgU3RhbmRhcmQ8L2ZvbnQ+PC9zdHJvbmc+IHNwZWNpZmljYXRpb24uIFRoaXMgaXMgcmVxdWly ZWQgYXMgcGFydCBvZgptb3ZpbmcgQmFiZWwgdG8gUHJvcG9zZWQgU3RhbmRhcmQuCgotIDxzdHJp a2U+PGZvbnQgY29sb3I9InJlZCIgc2l6ZT0iKzEiPlByb2R1Y2U8L2ZvbnQ+PC9zdHJpa2U+IDxz dHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIrMSI+QXMgdGhlIFByb3Bvc2VkIFN0YW5k YXJkIHZlcnNpb24gb2YgQmFiZWwgaXMgY29tcGxldGVkLDwvZm9udD48L3N0cm9uZz4gYW4gPHN0 cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQg Zm9yIHB1YmxpY2F0aW9uPC9mb250Pjwvc3RyaWtlPgo8c3Ryb25nPjxmb250IGNvbG9yPSJncmVl biIgc2l6ZT0iKzEiPkFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IHNob3VsZCBiZSBmaW5hbGl6ZWQg dG8gZ3VpZGUgdGhvc2UgcG90ZW50aWFsbHkKaW50ZXJlc3RlZCBpbiBkZXBsb3lpbmcgQmFiZWwu ICBUaGlzIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IG1heQppbmNsdWRlIGRlcGxveW1lbnQgYWR2 aWNlIGFuZCB3aWxsIGJlIHB1Ymxpc2hlZDwvZm9udD48L3N0cm9uZz4gYXMgYW4KPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+SW5mb3JtYXRpb25hbDwvZm9udD48L3N0cmlrZT4g UkZDLiA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj5UaGlzIGlzIGhpZ2hseSBk ZXNpcmFibGUgaW4gY29uanVuY3Rpb24gd2l0aCBtb3ZpbmcKQmFiZWwgdG8gUHJvcG9zZWQgU3Rh bmRhcmQuPC9mb250Pjwvc3RyaWtlPgoKLSBBZGRyZXNzIG1hbmFnZWFiaWxpdHkgb2YgPHN0cmlr ZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+QmFiZWwsIG1vc3QgbGlrZWx5PC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPkJhYmVsPC9mb250 Pjwvc3Ryb25nPiBieSBwcm9kdWNpbmcgPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iIHNpemU9 IisxIj5hbiBpbmZvcm1hdGlvbmFsIG1vZGVsLApmb3IgdXNlIGJ5IG90aGVyIG5ldHdvcmsgbWFu YWdlbWVudCwgYW5kPC9mb250Pjwvc3Ryb25nPiBhIFlBTkcKPHN0cmlrZT48Zm9udCBjb2xvcj0i cmVkIiBzaXplPSIrMSI+bW9kZWwgZm9yIEJhYmVsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPm1vZHVsZSBiYXNlZCBvbiBpdCwgdG8KYmU8L2Zv bnQ+PC9zdHJvbmc+IGNvbnNpc3RlbnQgd2l0aCA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNp emU9IisxIj5vdGhlcjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4i IHNpemU9IisxIj50aGUgb25nb2luZyBlZmZvcnQgdG8gdXNlPC9mb250Pjwvc3Ryb25nPiBZQU5H IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCIgc2l6ZT0iKzEiPm1vZGVscyBwcm9kdWNlZDwvZm9u dD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iIHNpemU9IisxIj5tb2R1bGVz PC9mb250Pjwvc3Ryb25nPiBpbiB0aGUKPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIr MSI+cm91dGluZyBhcmVhLjwvZm9udD48L3N0cmlrZT4KPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3Jl ZW4iIHNpemU9IisxIj5Sb3V0aW5nIEFyZWEuPC9mb250Pjwvc3Ryb25nPiAgVGhpcyBpcyByZXF1 aXJlZCBhcyBwYXJ0IG9mIG1vdmluZyBCYWJlbCB0byBQcm9wb3NlZApTdGFuZGFyZC4KCi0gVGhl IHdvcmtpbmcgZ3JvdXAgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+bWF5IGNo b29zZTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iIHNpemU9Iisx Ij5pcyBlbmNvdXJhZ2VkPC9mb250Pjwvc3Ryb25nPiB0byA8c3RyaWtlPjxmb250IGNvbG9yPSJy ZWQiIHNpemU9IisxIj5wdWJsaXNoIGFuIEluZm9ybWF0aW9uYWwgUkZDIG9uPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPmtlZXAgaXRzIHdpa2kg dXBkYXRlZCB3aXRoPC9mb250Pjwvc3Ryb25nPgppbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHdp dGggPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+QmFiZWwsPC9mb250Pjwvc3Ry aWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPkJhYmVsPC9mb250Pjwv c3Ryb25nPiBzbyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj5hcyB0byBlbmFi bGUgZnV0dXJlIHJlYWRlcnMKdG8gYmV0dGVyPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250 IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPnRoYXQgbmV3IFdHIHBhcnRpY2lwYW50cyBjYW48L2Zv bnQ+PC9zdHJvbmc+CnVuZGVyc3RhbmQgdGhlIHN0YXRlIHRoYXQgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIiBzaXplPSIrMSI+ZHJpdmVzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSJncmVlbiIgc2l6ZT0iKzEiPmlzIGRyaXZpbmc8L2ZvbnQ+PC9zdHJvbmc+IHRoaXMgd29y ayBhbmQgdGhlIGV4cGVyaWVuY2UKZHJpdmluZyBjaGFuZ2VzLgoKLSA8c3RyaWtlPjxmb250IGNv bG9yPSJyZWQiIHNpemU9IisxIj5UaGU8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s b3I9ImdyZWVuIiBzaXplPSIrMSI+QXMgYSBzZWNvbmRhcnkgZm9jdXMsIHRoZTwvZm9udD48L3N0 cm9uZz4gd29ya2luZyBncm91cCBtYXkgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBzaXplPSIr MSI+Y2hvb3NlIHRvPC9mb250Pjwvc3RyaWtlPiB3b3JrIG9uIG11bHRpY2FzdAphc3BlY3RzIG9m IDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCIgc2l6ZT0iKzEiPkJhYmVsCm9uY2UgdGhlIGluaXRp YWwgZm9jdXMgb24gUHJvcG9zZWQgU3RhbmRhcmQgaXMgbWV0LjwvZm9udD48L3N0cmlrZT4gPHN0 cm9uZz48Zm9udCBjb2xvcj0iZ3JlZW4iIHNpemU9IisxIj5CYWJlbC4gIFN1Y2ggd29yayBzaG91 bGQgYmUgY29vcmRpbmF0ZWQgd2l0aCBQSU0uPC9mb250Pjwvc3Ryb25nPgoKLSBDb29yZGluYXRl IHdpdGggb3RoZXIgd29ya2luZyBncm91cHMgYXMgPHN0cmlrZT48Zm9udCBjb2xvcj0icmVkIiBz aXplPSIrMSI+bmVlZC48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVu IiBzaXplPSIrMSI+bmVlZGVkLjwvZm9udD48L3N0cm9uZz4KClRodXMsIHRoZSB3b3JraW5nIGdy b3VwIHdpbGwgcHJvZHVjZSBhIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCIgc2l6ZT0iKzEiPnBy b3Bvc2VkIHN0YW5kYXJkPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVl biIgc2l6ZT0iKzEiPlByb3Bvc2VkIFN0YW5kYXJkPC9mb250Pjwvc3Ryb25nPiBCYWJlbApzcGVj aWZpY2F0aW9uLCBpbmNsdWRpbmcgb3IgcGFpcmVkIHdpdGggYSBzdWl0YWJsZSBzZWN1cml0eQpz cGVjaWZpY2F0aW9uIGZvciBCQUJFTC4gSXQgd2lsbCBhbHNvIHByb2R1Y2UgYSBtYW5hZ2VtZW50 IG1vZGVsIGZvcgpCQUJFTCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQy4gQW4gYXBwbGljYWJp bGl0eSA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj5zdGF0ZW1lbnQsIGFuZApw b3NzaWJseSBhbiBleHBlcmllbmNlIGRvY3VtZW50PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPnN0YXRlbWVudDwvZm9udD48L3N0cm9uZz4gd2ls bCBiZQpwcm9kdWNlZCBhcyA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj5pbmZv cm1hdGlvbmFsClJGQyhzKS48L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9Imdy ZWVuIiBzaXplPSIrMSI+YW4gSW5mb3JtYXRpb25hbCBSRkMuICBJZiBtdWx0aWNhc3QgYXNwZWN0 cyBhcmUgcHVyc3VlZCwKd2l0aCBBRCBhbmQgV0cgYWdyZWVtZW50LCB0aGVuIGEgbWlsZXN0b25l IG1heSBiZSBhZGRlZCBmb3IgYW4KYXNzb2NpYXRlZCBkb2N1bWVudCB0YXJnZXRlZCBhcyBQcm9w b3NlZCBTdGFuZGFyZC48L2ZvbnQ+PC9zdHJvbmc+CgpMaW5rIG1ldHJpYyBtZWFzdXJlbWVudCBv ciBsaW5rIG1ldHJpYyBjYWxjdWxhdGlvbiBwcm9jZWR1cmVzCnNpZ25pZmljYW50bHkgbW9yZSBj b21wbGV4IHRoYXQgdGhvc2UgY3VycmVudGx5IGluIEJhYmVsIGFyZSBvdXQgb2YKc2NvcGUuCgpJ bml0aWFsIE1pbGVzdG9uZXMKKCJEYXRlIiBpcyBhIG1vbnRoIHdoZXJlIFggaXMgdGhlIG1vbnRo IG9mIENoYXJ0ZXIgYXBwcm92YWwpCgpEYXRlICBNaWxlc3RvbmUKCiBYKzEgIFdHIGFkb3B0aW9u IG9mIEJhYmVsIEFwcGxpY2FiaWxpdHkgZHJhZnQuCgogWCsxICBXRyBhZG9wdGlvbiBvZiByZmM2 MTI2YmlzIGRyYWZ0LgoKIFgrNCAgV0cgYWRvcHRpb24gb2YgQmFiZWwgbWFuYWdlbWVudCA8c3Ry aWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj4ocHJvYmFibHkgWWFuZyk8L2ZvbnQ+PC9z dHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIrMSI+KFlhbmcgLyBEYXRh IE1vZGVsKTwvZm9udD48L3N0cm9uZz4gZHJhZnQuCgogPHN0cmlrZT48Zm9udCBjb2xvcj0icmVk IiBzaXplPSIrMSI+WCs1PC9mb250Pjwvc3RyaWtlPgoKPHN0cm9uZz48Zm9udCBjb2xvcj0iZ3Jl ZW4iIHNpemU9IisxIj5YKzEwPC9mb250Pjwvc3Ryb25nPiAgU3VibWlzc2lvbiBvZiA8c3RyaWtl Pjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj5CYWJlbCBBcHBsaWNhYmlsaXR5PC9mb250Pjwv c3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPnJmYzYxMjZiaXM8 L2ZvbnQ+PC9zdHJvbmc+IGRyYWZ0IHRvIHRoZSBJRVNHIGFzCiAgICAgIDxzdHJpa2U+PGZvbnQg Y29sb3I9InJlZCIgc2l6ZT0iKzEiPkluZm9ybWF0aW9uYWwuCgpYKzEwPC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPlByb3Bvc2VkIFN0YW5kYXJk LgoKWCsxMjwvZm9udD48L3N0cm9uZz4gIFN1Ym1pc3Npb24gb2YgPHN0cmlrZT48Zm9udCBjb2xv cj0icmVkIiBzaXplPSIrMSI+cmZjNjEyNmJpczwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u dCBjb2xvcj0iZ3JlZW4iIHNpemU9IisxIj5CYWJlbCBtYW5hZ2VtZW50PC9mb250Pjwvc3Ryb25n PiBkcmFmdCB0byA8c3RyaWtlPjxmb250IGNvbG9yPSJyZWQiIHNpemU9IisxIj50aGU8L2ZvbnQ+ PC9zdHJpa2U+IElFU0cgYXMgUHJvcG9zZWQKICAgICAgU3RhbmRhcmQuCgpYKzEzICBTdWJtaXNz aW9uIG9mIEJhYmVsIDxzdHJpa2U+PGZvbnQgY29sb3I9InJlZCIgc2l6ZT0iKzEiPm1hbmFnZW1l bnQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9ImdyZWVuIiBzaXplPSIrMSI+ QXBwbGljYWJpbGl0eTwvZm9udD48L3N0cm9uZz4gZHJhZnQgdG8gPHN0cm9uZz48Zm9udCBjb2xv cj0iZ3JlZW4iIHNpemU9IisxIj50aGU8L2ZvbnQ+PC9zdHJvbmc+IElFU0cgYXMgPHN0cmlrZT48 Zm9udCBjb2xvcj0icmVkIiBzaXplPSIrMSI+UHJvcG9zZWQKICAgICAgU3RhbmRhcmQuPC9mb250 Pjwvc3RyaWtlPgogICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSJncmVlbiIgc2l6ZT0iKzEiPklu Zm9ybWF0aW9uYWwuPC9mb250Pjwvc3Ryb25nPgo8L3ByZT4KCjwvYm9keT48L2h0bWw+ --001a113dc862330a9205332f80d5-- From nobody Thu May 19 03:55:05 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136F212D919 for ; Thu, 19 May 2016 03:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHP44uWk84JV for ; Thu, 19 May 2016 03:55:03 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E53B12D917 for ; Thu, 19 May 2016 03:55:02 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id a17so119991365wme.0 for ; Thu, 19 May 2016 03:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mG1RYGHWAG1moFrmi6TmYtm2X3l1yetLWgSO1vxaotU=; b=oKl1hLqDy2PKmirGu7LplpzIMGoO6N3LkIlGcIMP+mb6hMMOuDU6eEo4YdYhCNyn9m rLw0W1VkJpmycmMFnm7GgpoVynI2bs5LPHyW+X74i1CJ7D2fZRAHxUrmyMMR/r1T7AQx kE1fGpl/kQofub93UlRhekA1ip1LCugPr50v5sgxT6L9LWNrHs5f+Nq+Kgk+NkfyOX8Z Y7+S4hOCbuTIV1ABqMYL8tkTeIXXf2VDgMgB+wbQ4KW9MfdNQMtj+DBY2jnIWI52wrWs 3LvSyjf9Q9/5rLiLiM3b6wh/cvbZfjT2S7hyi+87nRWuu5ZiAIXuXgNGZyL4ZERxHdPH DbuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mG1RYGHWAG1moFrmi6TmYtm2X3l1yetLWgSO1vxaotU=; b=mhuNhfv4Vkj39XKKNct+2oCt/qw21V7fFi4wVLdJ5D2KZeVUUxEq9LI8dwWikJh3pE 7dva2I0HiWL73/k5wyZ3+G736AhxQUZ+bXWe51NgAIgxuL4S6s0tjs3dGijpWwHS2vjM vx1ZjWsijmfrnl+dwbth/caRpad78s34ha2cPy7RuHNJ70SNmZZtvsHAaU/Xd1BIveQR N+t+PZn1RGLbffn6nPnvAI8viQOCWMWqm8oWCS8NDRWRW7K+mZ4y5erDttfbJPpaxzH7 vx0stPJbYFosLD4XpVdXFLpFCPjKeQpBjNlcwryZyChs6ZLcatPwsTTgPIeeKtWPzC94 EH7Q== X-Gm-Message-State: AOPr4FWVcw8HHlE8Sc0/xMq6aKxyXPtI0j97grPX54KON4O3kvDpKQnUOK7r0cMFFAPbBZhjwca12IUEkj7NI8wW X-Received: by 10.28.18.11 with SMTP id 11mr12425628wms.51.1463655300890; Thu, 19 May 2016 03:55:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.175.34 with HTTP; Thu, 19 May 2016 03:54:21 -0700 (PDT) In-Reply-To: References: From: Gabriel Kerneis Date: Thu, 19 May 2016 12:54:21 +0200 Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a1146972249007305332fce94 Archived-At: Cc: Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 10:55:04 -0000 --001a1146972249007305332fce94 Content-Type: text/plain; charset=UTF-8 On Thu, May 19, 2016 at 12:32 PM, Donald Eastlake wrote: > Attached is an updated draft and a wdiff against the previous version > I sent out. > This looks good to me, thanks. Gabriel --001a1146972249007305332fce94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 19, 2016 at 12:32 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
Attached is an updated draft a= nd a wdiff against the previous version
I sent out.


This looks good to me, thanks.<= /div>

Gabrie= l
--001a1146972249007305332fce94-- From nobody Thu May 19 10:02:06 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3951012D1A4 for ; Thu, 19 May 2016 10:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs6GTqCX-Y0E for ; Thu, 19 May 2016 10:02:02 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056BF12DAEC for ; Thu, 19 May 2016 10:02:02 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id x189so84326541ywe.3 for ; Thu, 19 May 2016 10:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=o1xogIqHq+VQu0gJJDBIX8yhB8+Q323S2daXmz0r5uk=; b=mPX2CfcFxUUyMk8pd3LldQd0rG3ewW4wZ7sjY2kueNVPQ8CgXTnQVXx1sSpjQLGbn1 wTUGwl8vbaU/6hLq6/4UyTVMP9/NIV/vAIC2WRA0iHnYudpW8sOO6KSfVTpE0+KDPQ6K TsNfmgyvADQ47nTNYTkn3j+nM4J/FXdMZwDd8LIVK5mFnA2egw8e3wiPvgNyxExswBiS B1SCOzFW2SRfqFHZIQ0yS9CgtXarbiiuYf+qELodkHiarzl0JRPcfZctd63cF7fWWqxn Xn2ut/BTFu2rwbc+8Z2AmMIOrGVVJ4IgGyd1PL4gIBMmel/tM/ERLSdeYytRVehFYlQQ opDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=o1xogIqHq+VQu0gJJDBIX8yhB8+Q323S2daXmz0r5uk=; b=DbAJsAS0epV1SgvkSjcxr7+n/zFIh6fSZPXyYXb5wegKxVO+aVqfAfx4WoJd5uhXiV XxHVvC3YlAXbL5taBi8k4gIPsQYPvw4diMOn1eqA1odQ/97bCHz27wIyh1hZW3cTLpEO USMrRFzTgrSOApQqmXTlDlohfiCmWOwZdjmewOU6e4PROj+NTwb/N+WDA9DgA0ji4TND NJxTRAA1BldqVuTcdMEU3vnmIhrX4rsC9XQ8dVvtgtX7IbU9grknREChtFG2RgcwnUG9 OXB8KiT6PqwD+Bf8WBtCWVgYUY1j7HYbtJT2kFOL4v4pA5hfK36ATKGV1ymo+87V7f4O fAbw== X-Gm-Message-State: AOPr4FUs7R8DmZH+uRdbDohjQai8bun96b/DvxmcDdE91om7XwG+MUGOoExus4lAfyDkWg== X-Received: by 10.37.215.20 with SMTP id o20mr7292697ybg.185.1463677321174; Thu, 19 May 2016 10:02:01 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:3d85:84b0:c255:66fc? ([2601:647:4d00:abf0:3d85:84b0:c255:66fc]) by smtp.gmail.com with ESMTPSA id m8sm8691049ywb.18.2016.05.19.10.01.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 May 2016 10:01:59 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4B24B20A-5F44-4CF9-BF96-B0655A1C8B50"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Thu, 19 May 2016 10:01:57 -0700 Message-Id: <8C667B20-D431-4D56-9667-5B80737B080A@gmail.com> References: To: Gabriel Kerneis X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Donald Eastlake , Bob Hinden , Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:02:04 -0000 --Apple-Mail=_4B24B20A-5F44-4CF9-BF96-B0655A1C8B50 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On May 19, 2016, at 3:54 AM, Gabriel Kerneis wrote: > > On Thu, May 19, 2016 at 12:32 PM, Donald Eastlake wrote: > Attached is an updated draft and a wdiff against the previous version > I sent out. > > > This looks good to me, thanks. Fine by me as well. Bob > > Gabriel > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_4B24B20A-5F44-4CF9-BF96-B0655A1C8B50 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXPfGFAAoJEK7rdBF357uozV8H/jjqOi31h5tdCO3Ff0VI5Hsn 2+3cLA467t7qwiEfZr5s71KW+ho+NmCRD21zPzUCEhgWYWYHJ/Hvd5gcpiyp+RbZ NpCZIRLeLh/Qf9zTfMBBuGXTCOM13gmkNMdCQXUa0mMVu26XaQFhaQxl2QCgUgpv 66omZCSAy/wzIb737QjY4HYDLSttrhdXDW+O52rEaL+H6UrhUGtyCITUe77hvCyg 5/lHu+Rvpwvlujwj0R4cQlnVS0HqWjINHA3zpohYsa8aUeWocUoRVRQ/I1iRQCV3 MasObcM1OclBtu+6LsYfcd2L/gkBMDavcHiIQhhqOLqKPNmsR1mrjsmjtZxQCx4= =dOxT -----END PGP SIGNATURE----- --Apple-Mail=_4B24B20A-5F44-4CF9-BF96-B0655A1C8B50-- From nobody Thu May 19 10:11:28 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5779412D109 for ; Thu, 19 May 2016 10:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqfRnk50MSkF for ; Thu, 19 May 2016 10:11:25 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C05412D0C5 for ; Thu, 19 May 2016 10:11:25 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4JHBN16014507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 May 2016 19:11:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4JHBNJP013422; Thu, 19 May 2016 19:11:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0A1BE61FA1; Thu, 19 May 2016 19:11:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id UAUFQlJB--BB; Thu, 19 May 2016 19:11:21 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BD20661F9D; Thu, 19 May 2016 19:11:21 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.87) (envelope-from ) id 1b3RTl-0005YP-IS; Thu, 19 May 2016 19:11:21 +0200 Date: Thu, 19 May 2016 19:11:21 +0200 Message-ID: <7ifute7z2e.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Donald Eastlake In-Reply-To: <8C667B20-D431-4D56-9667-5B80737B080A@gmail.com> References: <8C667B20-D431-4D56-9667-5B80737B080A@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 19 May 2016 19:11:23 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 19 May 2016 19:11:23 +0200 (CEST) X-Miltered: at korolev with ID 573DF3BB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 573DF3BB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573DF3BB.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 573DF3BB.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573DF3BB.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 573DF3BB.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:11:27 -0000 >> This looks good to me, thanks. > Fine by me as well. Yes, thanks. -- Juliusz From nobody Thu May 19 14:34:19 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DEF12D68A for ; Thu, 19 May 2016 14:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6YwLuFvWQQI for ; Thu, 19 May 2016 14:34:15 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EBC12D689 for ; Thu, 19 May 2016 14:34:14 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4JLYB2U014305; Thu, 19 May 2016 23:34:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E9B2261FA1; Thu, 19 May 2016 23:34:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EPwL3oJHj86Q; Thu, 19 May 2016 23:34:10 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3091F61F9D; Thu, 19 May 2016 23:34:10 +0200 (CEST) Date: Thu, 19 May 2016 23:34:10 +0200 Message-ID: <874m9tbulp.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Teco Boot In-Reply-To: References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> <87fute7tx7.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 19 May 2016 23:34:12 +0200 (CEST) X-Miltered: at korolev with ID 573E3153.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 573E3153.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 573E3153.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Ferry Huberts , Henning Rogge , babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:34:18 -0000 > Let us not discuss implementation details on MANET stuff and DAT/ETX/ETT > metrics over here, this is the Babel protocol mailing list. Well, Babel claims to work in hybrid networks, so it's important for us to know of the experiences in the MANET space. I always listen very carefully to what Henning has to say. And then disagree with him ;-) > We discussed metric encoding a lot in MANET. We decided a 16-bit field for > path costs is not sufficient. I'd be interested to read up this discussion, I seem to have missed it. > So in Babelv2 we could think of a 32-bit metric field. RFC 6126 describes Babel version 2 (which is the third incompatible revision, since I started counting at 0). If we're designing an incompatible revision, it's going to be 3. -- Juliusz From nobody Fri May 20 01:20:31 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053A612D534 for ; Fri, 20 May 2016 01:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7rFPURe5hli for ; Fri, 20 May 2016 01:20:26 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51F512D0B0 for ; Fri, 20 May 2016 01:20:25 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id n129so261143824wmn.1 for ; Fri, 20 May 2016 01:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jRG05b0vXPgMryQ0xN/ijuS8IIHqLKQ/sqWJMmU6ZOk=; b=VyA/zGh7eHsFx6bswjzZpKQQXrWjVp232I0QcgCjxVGcS1wpQC6dt5MWO75ApnRAVN Ylx5lkcgEOs2gCMGVhG+01eecIQb9n9uBxk8qRbf5h4gk2hiRhyIDQDg+Bk1xts3vcGR 0wKf+j6DPYPZVlUkZEUUc5D4WS0Eynh6Qy6px6ipG2PZaUrC9MpCuR3CneKDwTQ2Oj5E 7YdD/G0bdqcMpbiVDedqoOOh/A7vFubHTx5DcJep+Zh2qifwD6g4OmbgkCZBzNXIcIFs AwTAlXeATvdnXbS2zKuoaeMkiJJnz2zlIOBoqs4K3Pd8OIHiVolLvWmuwaa7yQX6ZuJ3 HCyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jRG05b0vXPgMryQ0xN/ijuS8IIHqLKQ/sqWJMmU6ZOk=; b=Ztzdn6o50NfwkMX6NB4OBMgKXAsUXHF1U7WyR8Ye0F+KY86jve+1Ug15w34I/38cov tcmKn44HieldcJBv4hiUopL5I6jPet5EoxnIkmrXS4+vI2CX8MWfI69BkG3jcsXWyZ6v hROmXSuPwdGL8ErE+XhokDO6iJQITt0yYafYoa+JnDILwV2pQBkqHWPJti0UgmT4zx5h Hyc66SIHQDlhQt0iCGxBhsTL30nL479UrwDq6P56CjYuBywAoTMLCOeOTPuPH/U/GLRk xhsgRKcrXsS7LOHRj+DUOjKkwQEV+GwQ87dOqT+EShMXCTL/gjsLDls5oqTPBYMTcVH1 LpgA== X-Gm-Message-State: AOPr4FVw8crWTCTt5sqGzewonT4Rg9cmKAGVJRcZ8v/YpU1z64fPxi4cLGp671Z787eESg== X-Received: by 10.28.15.79 with SMTP id 76mr2316811wmp.53.1463732423681; Fri, 20 May 2016 01:20:23 -0700 (PDT) Received: from [192.168.178.95] (524A11D6.cm-4-3a.dynamic.ziggo.nl. [82.74.17.214]) by smtp.gmail.com with ESMTPSA id j6sm18529569wjb.29.2016.05.20.01.20.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 01:20:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Teco Boot In-Reply-To: <874m9tbulp.wl-jch@pps.univ-paris-diderot.fr> Date: Fri, 20 May 2016 10:20:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <236EA711-9039-4633-96DB-AC9B5722E5C2@inf-net.nl> References: <878tz9opml.wl-jch@pps.univ-paris-diderot.fr> <154c37b1-5b9c-bcb3-9e27-0a0a97076b7c@hupie.com> <8737pf8gru.wl-jch@pps.univ-paris-diderot.fr> <87fute7tx7.wl-jch@pps.univ-paris-diderot.fr> <874m9tbulp.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Ferry Huberts , Henning Rogge , babel@ietf.org Subject: Re: [babel] directional airtime metric X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 08:20:30 -0000 > Op 19 mei 2016, om 23:34 heeft Juliusz Chroboczek = het volgende geschreven: >=20 >> Let us not discuss implementation details on MANET stuff and = DAT/ETX/ETT >> metrics over here, this is the Babel protocol mailing list. >=20 > Well, Babel claims to work in hybrid networks, so it's important for = us to > know of the experiences in the MANET space. I always listen very > carefully to what Henning has to say. And then disagree with him ;-) >=20 >> We discussed metric encoding a lot in MANET. We decided a 16-bit = field for >> path costs is not sufficient. >=20 > I'd be interested to read up this discussion, I seem to have missed = it. Henning posted outcome of our private discussions. https://www.ietf.org/mail-archive/web/manet/current/msg11751.html >> Teco Boot mentioned a fourth disadvantage of the constants.=20 >> The range between minimum and maximum metric is only a factor=20 >> of ~ 2^16. If we want to keep the option to calculate all=20 >> metric operations with 32 bit integer, 2^16 is still much=20 >> lower than the maximum single hop metric of (2^32-1)/255 ~=3D 2^24. My reason for having a wider field is that in a highly hybrid network, = links can have very slow and lousy links and having very high-speed and = reliable links. I personally have to deal with handheld satcom and = multi-gig fiber.=20 We ended up in encoded link metrics, uncompressed 24 bits. Path costs = are 32 bits. The OLSRv2 compressed encoding is not appropriate for DV = protocols, although it can be used. >=20 >> So in Babelv2 we could think of a 32-bit metric field. >=20 > RFC 6126 describes Babel version 2 (which is the third incompatible > revision, since I started counting at 0). If we're designing an > incompatible revision, it's going to be 3. Yes, I remembered just after clicking on send :( Teco >=20 > -- Juliusz From nobody Fri May 20 01:56:31 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938E412D599 for ; Fri, 20 May 2016 01:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmUNPaF-I9z4 for ; Fri, 20 May 2016 01:56:28 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4B812D0B0 for ; Fri, 20 May 2016 01:56:27 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1463734585317288.8143571842037; Fri, 20 May 2016 01:56:25 -0700 (PDT) Date: Fri, 20 May 2016 09:56:25 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <154cd6147ab.c1a0b6f437242.7436119219449148788@ovsienko.info> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Cc: Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 08:56:29 -0000 ---- On Thu, 19 May 2016 11:32:56 +0100 Donald Eastlake wrote ---- >Hi Alia and Gabriel, > >Thanks for your good inputs. > >Attached is an updated draft and a wdiff against the previous version >I sent out. > To me it looks accomplishable. -- Denis Ovsienko From nobody Sat May 21 09:33:31 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCEC12D1DA for ; Sat, 21 May 2016 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rDANMv1zsc3 for ; Sat, 21 May 2016 09:33:28 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC0B12D1D8 for ; Sat, 21 May 2016 09:33:28 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4LGXQwK030762; Sat, 21 May 2016 18:33:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 221AD61FA5; Sat, 21 May 2016 18:33:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id b1fe8o7RVJRV; Sat, 21 May 2016 18:33:24 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9034F61F9A; Sat, 21 May 2016 18:33:22 +0200 (CEST) Date: Sat, 21 May 2016 18:33:25 +0200 Message-ID: <87a8jjfk16.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 Mail-Followup-To: babel-users@lists.alioth.debian.org MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 21 May 2016 18:33:26 +0200 (CEST) X-Miltered: at korolev with ID 57408DD6.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57408DD6.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 57408DD6.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: babel-users@lists.alioth.debian.org Subject: [babel] Possible changes to the Babel protocol X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: babel-users@lists.alioth.debian.org List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 16:33:31 -0000 Dear all, Since the creation of a WG is out of our hands right now, I'd like to start a discussion about whether we want to make an incompatible revision. I'm sending this mail to both lists, please follow-up to babel@ietf. I suggest that people express their opinions as followups to this mail, after the discussion has settled I'll summarise and make this into a wiki page. We can adopt one of three approaches. One would be to make an entirely compatible revision -- tighten the spec, make the extension mechanism a MUST, etc. We could make a revision that is technically incompatible, but retain version number 2 and design it so that it is possible to implement both RFC 6126 and IETF Babel at the same time. This would allow us to make some TLV types optional (deprecate them) or to mark them as reserved. The third approach is to make a new, Babel revision 3, which preserves the spirit of Babel to the extent possible but is not compatible with Babel. Unless the semantics are too different, it should be possible to implement both Babel 2 and 3 in a single process with loop avoidance across the two protocols, but at the cost of doubling the amount of control traffic. I hold no opinion at the present time which approach is preferable. I'm just listing the changes that we could envision. Notes of the form [jch:...] indicate my current opinion on each change. Whenever possible, the name of the person who originally suggested the change is indicated in brackets. * Incompatible changes Expand the primary metric to 32 bits (Tony) [jch: don't care, we can carry a 32-bit metric in an extension TLV, but expanding the primary metric is simpler] Expand the TLV size to 16 bits (Tony) [jch: opposed, 8 bits is plenty since TLVs must fit within a worst-case MTU] Expand the TLV/sub-TLV space to 16 bits [jch: opposed, there's already a mechanism for expansion of the TLV/sub-TLV space in RFC 7557] Add a mandatory bit to TLVs (Tony) [jch: unsure] Add a mandatory bit to sub-TLVs (Tony) [jch: in favour, they would simplify the source-specific encoding quite a bit] Clean up the encoding (Joel, Markus) [jch: mildly in favour, but afraid of bikeshedding] * Semi-compatible changes Remove AE 0 and wildcard requests/retractions/IHU (Toke) [jch: in favour, wildcard requests and retractions are confusing and not useful, wildcard IHU can be encoded in a more parsimonious manner] Remove plain (non-seqno) requests (jch) [jch: in favour, they complicate the protocol and are not very useful, can be added as an extension if needed] * Compatible changes Reserve router-ids all-zero and all-ones (Toke). [jch: in favour] Change the treatment of unfeasible updates from the selected neighbour, (Section 3.5.4 of RFC 6126, Ondrej) [jch: not sure] Change the SHOULD send a request when receiving an unfeasible update to MUST (Section 3.8.2.2, Tony) [jch: in favour] Rework the algorithm for sending requests when starving (Section 3.8.2.1, jch). [jch: in favour, but requires some experimental work] -- Juliusz From nobody Mon May 23 13:01:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0272F12D55C for ; Mon, 23 May 2016 13:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7XIOEOUUWyU for ; Mon, 23 May 2016 13:01:19 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA8D12DB07 for ; Mon, 23 May 2016 13:01:18 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id h19so28670664ywc.0 for ; Mon, 23 May 2016 13:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=mVXj3cwDmgHx+YfMmiDBlrpaGqbe4iZnzRSM1p+fcuo=; b=gtscrDN2G9IvjWdPxPv0l++gTD/JzOud3PehYRXrAiBm3jglsZ4xo4qNTyiPI803Di oaBNblH1vvHFZWTJ/ouHM3sEbdtGd73L+vBQdmzPwFTuR3Iool9ff4sjIBzILn3E2Hvw iXM0DwDo+lZIPJadCsctUtI8lKX3V7QrTXRCLfHWFJv7nWuNGsqFE7blddnc8aQcClzX wROFaWdfpt38auHTeiXgbWqaqBNOQKijhhyTS0246/pnsmyvAYXsLlYM7noRQYeU1ZsS V5rHHgF+CgnSeY0Mz1OyS7vraomCdrNAAb8cb4gkG/2HjgK8ofcHzQrkyxHpC11i0ffz hZAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mVXj3cwDmgHx+YfMmiDBlrpaGqbe4iZnzRSM1p+fcuo=; b=DNmKEBJ5FryK+lOAgb2coMy06lzZlIdQuhbeMKFEvTXxpRQRXd06O/66icFK8dawzi GyZKUmhxq1xVIV7mpPw6Gwod7r1Ln36j7+8QckuZvENylJnfox9GqCOFeQUrMMxUNnrG sh5tn1Atw36S6AFePk7Nx2WbnBll+4BXQ7nYKqfuRHwcNlPCtOt6DiRbKi8IvwWXKj51 iaCT9hBT1zUwNkdDBjZWT3tVN2xOKHHDIfANL59Q5hi5FCPGnjaYEPcrILKjndBDK3dk iavqQHPyK3qgjpf1gJb1MGemyVThBEb549XZVcX7wO6XwnBzUfD+Z81SX64wQsDk9KIT 31RQ== X-Gm-Message-State: ALyK8tJsHi0KH/gQk3a1aAaWq51QHMVLc56S04VK/A8qW+wmUcrZqbFRb4q6xaEtyoE2cAX2aE6iPXM2n6r+XA== MIME-Version: 1.0 X-Received: by 10.129.99.86 with SMTP id x83mr376404ywb.220.1464033677302; Mon, 23 May 2016 13:01:17 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Mon, 23 May 2016 13:01:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 May 2016 16:01:17 -0400 Message-ID: From: Alia Atlas To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a1141c546466eda053387e72a Archived-At: Cc: Gabriel Kerneis , Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:01:22 -0000 --001a1141c546466eda053387e72a Content-Type: text/plain; charset=UTF-8 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 wrote: > Hi Alia and Gabriel, > > Thanks for your good inputs. > > Attached is an updated draft and a wdiff against the previous version > I sent out. > > >> Link metric measurement or link metric calculation procedures > >> significantly more complex that those currently in Babel are out of > >> scope. > > > > I'd like to see this better stated - including not focusing on wireless > link > > 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 > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Wed, May 18, 2016 at 3:41 PM, Alia Atlas wrote: > > 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 > > new-work@ietf.org) that includes various other organizations (mostly > SDOs); > > and > > return for a final approval on June 16. > > > > On Tue, May 17, 2016 at 3:12 PM, Donald Eastlake > wrote: > >> > >> 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 > >> =============================== > >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) > >> 155 Beaver Street, Milford, MA 01757 USA > >> d3e3e3@gmail.com > >> > >> > >> > >> Charter for the Babel 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. > > > > > > "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 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 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" > > > >> > >> 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 > > > > > > 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. > > > >> > >> -- 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. > > > > > > 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. > > > >> > >> - 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. > >> > > > > "-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." > > > >> > >> - 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 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. > > > >> > >> - The working group may choose to work on multicast aspects of Babel > >> 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." > > > >> > >> - 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). > > > > > > "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. > > > >> > >> Link metric measurement or link metric calculation procedures > >> significantly more complex that those currently in Babel are out of > >> scope. > > > > > > I'd like to see this better stated - including not focusing on wireless > link > > measurement. I think this needs more discussion. > > > >> > >> > >> 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. > > > > > > Please let's not make it a waterfall model. The Applicability can wait > > until the end. > > > > Thanks, > > Alia > --001a1141c546466eda053387e72a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Donald,

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

Regards,
Alia

On Thu, May 19, 2016 a= t 6:32 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi Alia and Gabriel,

Thanks for your good inputs.

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

>> Link metric measurement or link metric calculation procedures
>> significantly more complex that those currently in Babel are out o= f
>> scope.
>
> I'd like to see this better stated - including not focusing on wir= eless link
> measurement.=C2=A0 =C2=A0I 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com


On Wed, May 18, 2016 at 3:41 PM, Alia Atla= s <akatlas@gmail.com> wrote:=
> Hi Donald,
>
> This looks good in general.=C2=A0 I have a few minor comments - but we= should be
> good to put this on the IESG telechat for June 2 for internal review.= =C2=A0 Then
> it will
> have a period of 2 weeks for external review - where it is sent to a m= ailing
> list (called
> new-work@ietf.org) that inclu= des various other organizations (mostly SDOs);
> and
> return for a final approval on June 16.
>
> On Tue, May 17, 2016 at 3:12 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>>
>> It looks like discussion on the Charter has died down so I have >> reviewed that discussion and, based on it, produced an updated dra= ft
>> charter as pasted below after my .sig. Changes are small, just add= ed
>> milestone dates, tweaked wording at end of first paragraph / begin= ning
>> of second paragraph, and added out-of-scope sentence for new compl= ex
>> link metric stuff just before milestones.
>>
>> Thanks,
>> Donald
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=C2=A0 Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
>>=C2=A0 155 Beaver Street, Milford, MA 01757 USA
>>=C2=A0 d3e3e3@gmail.com
>>
>>
>>
>> Charter for the Babel Working Group
>>
>> Babel is a loop-avoiding, distance vector routing protocol with go= od
>> provisions for dynamically computed link metrics. It is robust eve= n in
>> the presence of link metric oscillations and the failure of
>> transitivity.=C2=A0 The core of the Babel protocol is described in=
>> Experimental Independent Stream RFCs 6126 and 7557, with RFC 7298<= br> >> describing security extensions.
>
>
> "The core of the Babel protocol and security extensions are descr= ibed in
> Experimental Independent Stream RFCs 6126, 7557, and 7298."
>
>>
>> These RFCs are the basis of three independent, open source
>> implementations.=C2=A0 There is some production deployment of thes= e
>> implementations, notably in hybrid networks (networks that include=
>> classical, wired parts with meshy radio bits) and in global overla= y
>> networks (networks built out of large numbers of tunnels spanning<= br> >> continents).
>>
>> The working group is will focus on moving the Babel protocol to IE= TF
>> Proposed Standard with IETF review. This includes clarifying RFC 6= 126
>> and integrating RFC 7557 and feedback provided by independent
>> implementations, and resolving the comments presented at the BABEL= BoF
>> at IETF-95. Other documents that are relevant to such consideratio= n
>
>
> "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"
>
>>
>> can also be produced. Particular emphasis will be placed on work >> needed for a Proposed Standard routing protocol, such as ensuring<= br> >> 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 workin= g
>> group discussions
>
>
> 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&#= 39;t
> fixed.
>
>>
>> -- include in the base specification the extensibility work in
>> RFC 7557
>> -- consider any important changes based on experience with Babel t= o
>> date. This may include discussion of issues such as the size of th= e
>> default metric.
>>
>> - Address security needs for BABEL. This may include using the
>> techniques in RF 7298, or other alternatives. This may be by inclu= sion
>> in the base spec or by normative reference to a separate proposed<= br> >>
>> standard specification. This is required as part of moving Babel t= o
>> Proposed Standard.
>>
>> - Produce an applicability statement for publication as an
>> Informational RFC. This is highly desirable in conjunction with mo= ving
>> Babel to Proposed Standard.
>
>
> I would prefer to be extremely clear in the charter that the Applicabi= lity
> statement
> isn't expected to be produced before the Proposed Standard.=C2=A0 = How about
>
> " - As the Proposed Standard version of Babel is completed, an Ap= plicability
> Statement should be finalized to guide those potentially interested in=
> deploying
> Babel.=C2=A0 This Applicability Statement=C2=A0 may include deployment= advice and will
> be
> published as an RFC.
>
>>
>> - Address manageability of Babel, most likely by producing a YANG<= br> >> model for Babel consistent with other YANG models produced in the<= br> >> routing area. This is required as part of moving Babel to Proposed=
>> Standard.
>>
>
> "-Address manageability of Babel by producing an informational mo= del, for
> use
> by other network management, and a YANG module based on it, to be cons= istent
> with the ongoing effort to use YANG modules in the Routing Area.=C2=A0= This is
> required
> as part of moving Babel to Proposed Standard."
>
>>
>> - The working group may choose to publish an Informational RFC on<= br> >> implementation experience with Babel, so as to enable future reade= rs
>> to better understand the state that drives this work and the
>> experience driving changes.
>
>
> "- The working group is encouraged to keep its wiki updated with<= br> > implementation
> experience with Babel so that new WG participants can understand the s= tate
> that is driving this work and the experience driving changes." >
> I would like to understand better the expected value of publishing thi= s as
> an RFC.
> It feels to me like the kind of information that will be useful during= the
> WG process
> but not after.
>
>>
>> - The working group may choose to work on multicast aspects of Bab= el
>> once the initial focus on Proposed Standard is met.
>
>
> " - As a secondary focus, the working group may work on multicast= aspects
> of Babel.=C2=A0 Such work should be coordinated with PIM."
>
>>
>> - 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 f= or
>> BABEL as a Proposed Standard RFC. An applicability statement, and<= br> >> possibly an experience document will be produced as informational<= br> >> RFC(s).
>
>
> "An applicability statement will be produced as an Informational<= br> > RFC.=C2=A0 If multicast aspects are pursued, with AD and WG agreement,=
> then a milestone may be added for an associated document targeted as > Proposed Standard.
>
>>
>> Link metric measurement or link metric calculation procedures
>> significantly more complex that those currently in Babel are out o= f
>> scope.
>
>
> I'd like to see this better stated - including not focusing on wir= eless link
> measurement.=C2=A0 =C2=A0I think this needs more discussion.
>
>>
>>
>> Initial Milestones
>> ("Date" is a month where X is the month of Charter appro= val)
>>
>> Date=C2=A0 Milestone
>>
>>=C2=A0 X+1=C2=A0 WG adoption of Babel Applicability draft.
>>
>>=C2=A0 X+1=C2=A0 WG adoption of rfc6126bis draft.
>>
>>=C2=A0 X+4=C2=A0 WG adoption of Babel management (probably Yang) dr= aft.
>>
>>=C2=A0 X+5=C2=A0 Submission of Babel Applicability draft to the IES= G as
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Informational.
>>
>> X+10=C2=A0 Submission of rfc6126bis draft to the IESG as Proposed = Standard.
>>
>> X+13=C2=A0 Submission of Babel management draft to IESG as Propose= d
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Standard.
>
>
> Please let's not make it a waterfall model.=C2=A0 The Applicabilit= y can wait
> until the end.
>
> Thanks,
> Alia

--001a1141c546466eda053387e72a-- From nobody Mon May 23 13:10:35 2016 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB67F12DB3F for ; Mon, 23 May 2016 13:10:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523201033.20225.37634.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 13:10:33 -0700 From: IETF Secretariat Archived-At: Subject: [babel] Milestones changed for babel WG X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:10:34 -0000 Added milestone "WG adoption of Babel Applicability draft", due July 2016. Added milestone "WG adoption of rfc6126bis draft", due July 2016. Added milestone "WG adoption of Babel management (Yang / Data Model) draft.", due October 2016. Added milestone "Submission of rfc6126bis draft to IESG as Proposed Standard", due May 2017. Added milestone "Submission of Babel management draft to IESG as Proposed Standard", due July 2017. Added milestone "Submission of Babel Applicability draft to the IESG as Informational", due August 2017. URL: https://datatracker.ietf.org/wg/babel/charter/ From nobody Wed May 25 11:37:37 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006BE12D8C1 for ; Wed, 25 May 2016 11:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvUxNFNqpa1c for ; Wed, 25 May 2016 11:37:34 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9B912D8A0 for ; Wed, 25 May 2016 11:37:34 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id o16so56253440ywd.2 for ; Wed, 25 May 2016 11:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=2noe5Zmnl+lRey0s0e5sdxvSFIu/tXvKJwSbCM8lWwI=; b=vByAL+jbX1C8vFEZEhKbK7k+TZe5nK2KgG8WsJz+9O05PxQ9pokMF+m3/jt09pVTPH Hw3OTNCLqA8mkhlEPv9/arNI/59SmAGkV2I4fWC22erptPhZJRJDaV2f0PS6ChGwI733 byb32L0sTP5DHpmrXditf3LwInzJX5vTj29bfiwDuxW4BJ0Zo3Z3v0zcA6g4AIc+Ehqb SrNkGam3fWLJdrc+gydy0YbD5D8J+6+7gTcrzrrJ91wqAA6KgiC1mFbPSeZYu3Vxeo1y 09sAK+RJOsMRTu0krxzy1kB6tN5/Fo3dh7LxA/y2wSeSvgJ473W9BfCHNx4t/mmjuECn iDuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=2noe5Zmnl+lRey0s0e5sdxvSFIu/tXvKJwSbCM8lWwI=; b=ivilhUCziS19bnkO87o0Mu8A/gHPnVB1JmjC5bXFe3BX9x1SLSDMjgfHINYKwL9cVI khity7vBV1adI5RKZe51nTE3YGhoAC7fN63gELv/+PazbadKHCitR/vOnaMkvLeQ4JFF Axn062bh7Q80Sn17vGYcK/jnzyxbxCyBBZDlIW8PBNDINBX1F91sVh4eumEXFnYvlXCz fKIsP3veaYWJ5jXuYZkkXhD04QpkSb3ipYrmXFK2ucAGkrITIRZf20g7AX78HSC9Ps8n ilxwuHLsLF0383qeMdPZ/nZs9ynZ+bXMhlP49Fz73bRkKTMcllw/pGCxRP+022LyqjNM pakQ== X-Gm-Message-State: ALyK8tLgnY9yY4IfLj2oeyRWqJlAp5lY2xxNQBSf4yMa9XNW3j2N07PD3XXRzVdKb7F49XmwIZM3IKjaOmz3Iw== MIME-Version: 1.0 X-Received: by 10.37.83.131 with SMTP id h125mr3202482ybb.109.1464201453971; Wed, 25 May 2016 11:37:33 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Wed, 25 May 2016 11:37:33 -0700 (PDT) Date: Wed, 25 May 2016 14:37:33 -0400 Message-ID: From: Alia Atlas To: Babel at IETF Content-Type: multipart/alternative; boundary=001a113e60ba8b2e4a0533aef77d Archived-At: Subject: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 18:37:36 -0000 --001a113e60ba8b2e4a0533aef77d Content-Type: text/plain; charset=UTF-8 If I understand the desired requirements discussed in homenet correctly, there is a need for Babel to have a mode that requires no configuration - where it simply handles auto-configuration - perhaps from other information. I don't see this described in RFC 6126 or in draft-chroboczek-homenet-babel-profile-00. What work do you see as necessary and where do you picture this being done? Regards, Alia --001a113e60ba8b2e4a0533aef77d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I understand the desired requirements discussed in home= net correctly, there is a need for Babel to have a mode that requires no co= nfiguration - where it simply handles auto-configuration - perhaps from oth= er information.

I don't see this described in RFC 6126 or in dra= ft-chroboczek-homenet-babel-profile-00.

What work do you see as nece= ssary and where do you picture this being done?

Regards,
Alia
=
--001a113e60ba8b2e4a0533aef77d-- From nobody Wed May 25 12:10:50 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8B712D8BF for ; Wed, 25 May 2016 12:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GirclcjEbep7 for ; Wed, 25 May 2016 12:10:46 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.231]) by ietfa.amsl.com (Postfix) with ESMTP id 475DE12D8FE for ; Wed, 25 May 2016 12:10:44 -0700 (PDT) Received: from poro.lan (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E14E9D04D2EE30; Wed, 25 May 2016 22:10:10 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Markus Stenberg In-Reply-To: Date: Wed, 25 May 2016 22:10:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> References: To: Alia Atlas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 19:10:49 -0000 On 25.5.2016, at 21.37, Alia Atlas wrote: > If I understand the desired requirements discussed in homenet = correctly, there is a need for Babel to have a mode that requires no = configuration - where it simply handles auto-configuration - perhaps = from other information. >=20 > I don't see this described in RFC 6126 or in = draft-chroboczek-homenet-babel-profile-00. >=20 > What work do you see as necessary and where do you picture this being = done? It is mostly there. Only annoyance is the router ID, which is assumed to = be unique based on EUI64-like process. It would be about two sentences to add DNCP-like conflict detection = (+rerandom) logic to the spec, but I am not sure it is worth it. = Juliusz? Cheers, -Markus= From nobody Wed May 25 12:15:22 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB82C12D970 for ; Wed, 25 May 2016 12:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTxQFan-3Y-h for ; Wed, 25 May 2016 12:15:19 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D23E12D967 for ; Wed, 25 May 2016 12:15:19 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id c127so57367642ywb.1 for ; Wed, 25 May 2016 12:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yyrD8EFZ3lh0+viYEdm84ooferW4TsMMbaHUmoThe6A=; b=cXYTvpWWSTASK+IcLfevLAqA+d845iySX9Z9hKXXQIFdD2S62BJmlw/kcp+xlho1lg ySwCFnuKGPJvlfOg/3N3w17l8dsyEbyykKh9/u/NHHq9bSaCn9HZpN58fUi6ICcJFdZP xC2QAVbz97tC7R2qbwLjNt5YjdfXekwlmcIkQj3KwjhFlofcAhrS6lcQtule49jf20hQ hPjdoye4BTza91TueGQ9zAbK7AR0LNZe+tBBLF/o7+cnfMwTuePWFXw8YvxL3RK7hU9m sZfZUrMR984U5BlxcB0ayCJ9sRngVDwwBhYpyTSgbBZZAAGZIVbRO+LLexHiNCN4b6Gj Qbcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yyrD8EFZ3lh0+viYEdm84ooferW4TsMMbaHUmoThe6A=; b=ZeAYOERsyq/dFRldjGhLOxu0htEDEXKdIh+zSTCUzn/Ankv5P5KpBOWSn54RnKpjpM uiC/th1mTCsFfQ1XgVGeQccKRa9V+nDiSlkFgnOd9ViB4D61jiLFg0D3Ki4VVR5GDT4L RTmgX+mXUHQOnK6mNFCxgN/cdBbj78ZEtejIX6jorqUPHWMjg4TK2f699VYCI06HY/UN Yi41Jr+6sQv3YGNGEiR797yVTZQwkiS+Jegm7d32FzkmX34Sc1oykCqAEM4u4/uw/f2H 8yoxyIBIwxn6KuTlYwVX0Uv5+zjA3CRoIg5f8BmsOKqYHLaNtALf/nl392/LJm56uIkY VL2A== X-Gm-Message-State: ALyK8tIAEfKRTXp0OoF7a7HYFgupULfD7d6fCKGsOO021tjgaFxLA78LW4H/uoqDc2d4A9ZWfymbBlJvf1e+UQ== MIME-Version: 1.0 X-Received: by 10.129.89.212 with SMTP id n203mr1668750ywb.102.1464203718504; Wed, 25 May 2016 12:15:18 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Wed, 25 May 2016 12:15:18 -0700 (PDT) In-Reply-To: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> Date: Wed, 25 May 2016 15:15:18 -0400 Message-ID: From: Alia Atlas To: Markus Stenberg Content-Type: multipart/alternative; boundary=001a114916448539790533af7ee6 Archived-At: Cc: Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 19:15:21 -0000 --001a114916448539790533af7ee6 Content-Type: text/plain; charset=UTF-8 On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg wrote: > On 25.5.2016, at 21.37, Alia Atlas wrote: > > If I understand the desired requirements discussed in homenet correctly, > there is a need for Babel to have a mode that requires no configuration - > where it simply handles auto-configuration - perhaps from other information. > > > > I don't see this described in RFC 6126 or in > draft-chroboczek-homenet-babel-profile-00. > > > > What work do you see as necessary and where do you picture this being > done? > > It is mostly there. Only annoyance is the router ID, which is assumed to > be unique based on EUI64-like process. > I thought that it was mostly there, but when I went back with that perspective, I didn't see it called out or discussed. This is a major advantage - and one that extensions and security need to consider and preserve. On the Router ID, I think that it is worth considering making it the same 32 bits that a Router ID is in all the other standardized routing protocols. That'll make it easier for things like management models to be reusable. > It would be about two sentences to add DNCP-like conflict detection > (+rerandom) logic to the spec, but I am not sure it is worth it. Juliusz? > If we want this to be picked up and used with no-config by many people, having it really work and be clearly documented as to how is very important. Regards, Alia > Cheers, > > -Markus --001a114916448539790533af7ee6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 25, 2016 at 3:10 PM, Markus Stenberg <markus.stenberg@iki.fi= > wrote:
O= n 25.5.2016, at 21.37, Alia Atlas <= akatlas@gmail.com> wrote:
> If I understand the desired requirements discussed in homenet correctl= y, there is a need for Babel to have a mode that requires no configuration = - where it simply handles auto-configuration - perhaps from other informati= on.
>
> I don't see this described in RFC 6126 or in draft-chroboczek-home= net-babel-profile-00.
>
> What work do you see as necessary and where do you picture this being = done?

It is mostly there. Only annoyance is the router ID, which is assume= d to be unique based on EUI64-like process.

=
I thought that it was mostly there, but when I went back with that per= spective, I didn't see it called out or discussed.=C2=A0 This is a majo= r advantage - and one that extensions and security need to consider and pre= serve.

On the Router ID, I think that it is worth = considering making it the same 32 bits that a Router ID is in all the other= standardized routing protocols.=C2=A0 That'll make it easier for thing= s like management models to be reusable.=C2=A0
=C2=A0
It would be about two sentences to add DNCP-like conflict detection (+reran= dom) logic to the spec, but I am not sure it is worth it. Juliusz?

If we want this to be picked up and used with n= o-config by many people, having it really work and be clearly documented as= to how is very important.

Regards,
Alia= =C2=A0

=C2=A0
Cheers,

-Markus

--001a114916448539790533af7ee6-- From nobody Wed May 25 22:06:26 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBA312D152 for ; Wed, 25 May 2016 22:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Res8XWp13XBn for ; Wed, 25 May 2016 22:06:22 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D93C12B040 for ; Wed, 25 May 2016 22:06:21 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so208356927wmn.1 for ; Wed, 25 May 2016 22:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=i7r/Fsk/GOqsnSGAeojS6DkLDf0NZnOOpIFmDUSA/k0=; b=Stan2StiSeg3aH8Svg/NJiIyyFIhpDbk8xmUjrDkpQ4bPr4JNQrg2FJEMknJ0kduRg aBTcg8jEZStAYBe6DDW0TaL6dhT9ESm9X14zFb249CQJanjWJoPQhNpWkpUDwFi8jKAr 73R+cW8ID4eJF3S1rw0SH3Xzxq6ERFrTKOBqKIrsuXtDccqDV/mORA3iIaIRDa/85GcE pxcidmlFM1Ur30jb4hE3rp6CeOUdx7ZW/0UITUUO9lzWarqD9b7dZ18lbFpQuQY3Upzb 4ZyMq7Z3+kCLaHzOx0t0KFuzYNi2udEtqud3xWscCM9dFDinn4ap8ewjq3P0+qXPXZli ORXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=i7r/Fsk/GOqsnSGAeojS6DkLDf0NZnOOpIFmDUSA/k0=; b=nLuYkHTuyeDyeAChhGuPXtnAKX9+zHdzCVT+5BC0Q3tW04UvNbW15l6hkqS+Nh3O6k 6bMtxAz5WuQW6rwfAg2Ikirhzmr/4WKcNBV/R5FmtdlSnFAddEMJw+xlMacqdBLHKhKH /YVnIYD/hxfQQUbIX/X9yMDC4VuOy4JZist1QdWwuRFi5++A8yq7scWzp+NtyqyiiUdf zd+P8RtcHhoTbUuQ7W3ac6NwMVZfhfEXKCP0qfD7YDoxGr75bgvZqbyblbBsOrbrnGyl 1VtwX6T4J0T0SatXjpo/3xzo5NM7UkF6KNZcXIqCgKM8AWjL0kL0gUZB48NsmpxeZQ77 WdDA== X-Gm-Message-State: ALyK8tKaE0WO+9RGt80P8vsM4jyid7hRulx0sb9s1CdSqwhGlXncpMxSmoI4UAC5K3P4yg== X-Received: by 10.28.153.80 with SMTP id b77mr1418326wme.71.1464239180032; Wed, 25 May 2016 22:06:20 -0700 (PDT) Received: from [10.87.0.107] ([145.15.244.28]) by smtp.gmail.com with ESMTPSA id hm7sm12198291wjb.41.2016.05.25.22.06.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 May 2016 22:06:19 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D17392BE-A1F5-4FB2-97A5-97A9C6BC462F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Teco Boot In-Reply-To: Date: Thu, 26 May 2016 07:06:18 +0200 Message-Id: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> To: Alia Atlas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Markus Stenberg , Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 05:06:24 -0000 --Apple-Mail=_D17392BE-A1F5-4FB2-97A5-97A9C6BC462F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Op 25 mei 2016, om 21:15 heeft Alia Atlas het = volgende geschreven: >=20 > On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg = wrote: > On 25.5.2016, at 21.37, Alia Atlas wrote: > > If I understand the desired requirements discussed in homenet = correctly, there is a need for Babel to have a mode that requires no = configuration - where it simply handles auto-configuration - perhaps = from other information. > > > > I don't see this described in RFC 6126 or in = draft-chroboczek-homenet-babel-profile-00. > > > > What work do you see as necessary and where do you picture this = being done? >=20 > It is mostly there. Only annoyance is the router ID, which is assumed = to be unique based on EUI64-like process. >=20 > I thought that it was mostly there, but when I went back with that = perspective, I didn't see it called out or discussed. This is a major = advantage - and one that extensions and security need to consider and = preserve. >=20 > On the Router ID, I think that it is worth considering making it the = same 32 bits that a Router ID is in all the other standardized routing = protocols. That'll make it easier for things like management models to = be reusable. This is the wrong direction. It is 64 bits right now. Please keep it (or = extend to 256 :-) RFC 6126 has text that the router-id is assigned. Not how it is assigned = automatically. Although one may assume that an unique MAC address would = be fine. But what if I write an implementation that takes the neighbor's = MAC? Yes, I am the crazy guy. Probably the duplicate router-id topic needs some work. Analyses on = impact and mechanisms for detection. The topic is related to security. Teco >=20 > It would be about two sentences to add DNCP-like conflict detection = (+rerandom) logic to the spec, but I am not sure it is worth it. = Juliusz? >=20 > If we want this to be picked up and used with no-config by many = people, having it really work and be clearly documented as to how is = very important. >=20 > Regards, > Alia >=20 >=20 > Cheers, >=20 > -Markus >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_D17392BE-A1F5-4FB2-97A5-97A9C6BC462F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXRoRLAAoJECQbXIDdIQWqT68QALkmOX0mesMls5aKDpRQQTby /FU8R8cjoDXzq1MWgc+UCQ0BscY5rpJBR3cGae5/0NBOiWKbX0CWheJByVPPTFRO U0oAGquEPzb6gKtltWQGTUt2NjMApBcMyhH5mdmYjYPzDYO9FdrkRkyC0IXSYTJr 7lY5Apf+/9WqEkTm+uj0wSkjst0gGraZKUYP4BEhFjtEAlbdSglXEciV+cyT/6rr 3ZxLCss6D9M7h2bLS6zhfR0JJfVKVBT2dz6iBt1NGYWPNYzns59H3q8VIEmpuXdg WqXqmAuqEhmEm55/qAQgnjBZi+xcwLYCYq2jdyyy7DQl7HJ2kzIr3syFQ3Ewj03B H0bJt4JHM2ogCBTwQE61KC7WifRF7h1rZdU+VraFcrDM5perlpwOjnE7HT84jlpj Ozz8D+Mq09Hk58qqM6JCezRo8/tyKnxx4TlnVyxJ0mrKao/Frn8IVz2zk/ytfB/K nmu2gIDAHx1qJ/ezd3Dj84B1dySzcvmHclADWNYk8HJ46GAuid7Jo3+Z71+V2pgV vLZrkpJm4ysYRmK6ZLgR3YAIKPYUUXdf4qd1mGQDfYvFqWeE8zzUVbjwYSbGaKVM SGxK8GA4hsSGOebQmeMORfsO39/wDIm8EOPxkt+6l99Wa5CVh9B+EhogsXYaZSQ8 CJ1gnxCr+KpicHyWpYgj =XGR4 -----END PGP SIGNATURE----- --Apple-Mail=_D17392BE-A1F5-4FB2-97A5-97A9C6BC462F-- From nobody Wed May 25 22:19:09 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0265C12D5EB for ; Wed, 25 May 2016 22:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGAbE3aFRslF for ; Wed, 25 May 2016 22:19:03 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8243412D5E8 for ; Wed, 25 May 2016 22:19:03 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id c127so66959987ywb.1 for ; Wed, 25 May 2016 22:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yrfXO7zrDyxhzVR5P1sA0N3s4sKUDpnUwNtd8TuGcVY=; b=nZqbGddIVh3UuMyZzNSCAODS7euBZwt9zGqVNR2mLw00m8gbJnyPU+4u/U/6cvC22S E+hqKUVOzZ6SPJp+kOUJGDaSog0Uf43thUhuixjqwSCbkZB2uoFYgmOsPe55kIQ+KSBJ QVf3jCYLkcPSrzRvA/rLDrx/BPo/KZk7cXl0Q+63gPwCJoy64yh+2FjUCUWxhQFJf/Tz /vZgRCBq7iLRGv/PSMXXwSP8ZuBQzHd8SJGrmMDZdpECmfaftCjhPRywBgLUEQrpo6wx hzVEQ5n+LKJZsAm/MVvcj8eAANeIorvRfx7tFU2LOTW6CHHtaZv9j1yDioKl4H6eakEh jk+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yrfXO7zrDyxhzVR5P1sA0N3s4sKUDpnUwNtd8TuGcVY=; b=K2z9CBzTxfgKR1U40lck3tt32zIzjp7PfctIhNVKt+jTthq71VgKr3xagKcHRlM/3a /OxgtfuFHUedjXBEvW8BY/H4apXitMH8wlkp10Mzm3kGOvO9ffZ9/SOhKRz/iwUFElmT +OmikMxUyThViJnuHT1ivbYcm2erOhvy2YR4izv658ijqj8946VcMNmfa9WcYXYKOzm+ hyFq8zB35TGotZe8kueKo6Tb+cSvOvwBoyRzflTkvMbstiqVINonF7lVG7n4gRCjZeCv 7d35GwLX/jGl8Lk3b6KLec8JEhvQXsy6RwciMeRpepp4zCzwp9IC7x5+K8SpvAuvzYV5 8LYw== X-Gm-Message-State: ALyK8tK2XejgaR/vRA5U+ng7pHlSrrO5QlRXQx2RlD6J6MJczb8wjtqxICkxhIbYiFlcS80zFFBez+hxqNCTVA== MIME-Version: 1.0 X-Received: by 10.37.205.132 with SMTP id d126mr4435893ybf.137.1464239942406; Wed, 25 May 2016 22:19:02 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Wed, 25 May 2016 22:19:02 -0700 (PDT) In-Reply-To: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> Date: Thu, 26 May 2016 01:19:02 -0400 Message-ID: From: Alia Atlas To: Teco Boot Content-Type: multipart/alternative; boundary=94eb2c189448a21d400533b7eddd Archived-At: Cc: Markus Stenberg , Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 05:19:06 -0000 --94eb2c189448a21d400533b7eddd Content-Type: text/plain; charset=UTF-8 On Thu, May 26, 2016 at 1:06 AM, Teco Boot wrote: > > > Op 25 mei 2016, om 21:15 heeft Alia Atlas het > volgende geschreven: > > > > On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg > wrote: > > On 25.5.2016, at 21.37, Alia Atlas wrote: > > > If I understand the desired requirements discussed in homenet > correctly, there is a need for Babel to have a mode that requires no > configuration - where it simply handles auto-configuration - perhaps from > other information. > > > > > > I don't see this described in RFC 6126 or in > draft-chroboczek-homenet-babel-profile-00. > > > > > > What work do you see as necessary and where do you picture this being > done? > > > > It is mostly there. Only annoyance is the router ID, which is assumed to > be unique based on EUI64-like process. > > > > I thought that it was mostly there, but when I went back with that > perspective, I didn't see it called out or discussed. This is a major > advantage - and one that extensions and security need to consider and > preserve. > > > > On the Router ID, I think that it is worth considering making it the > same 32 bits that a Router ID is in all the other standardized routing > protocols. That'll make it easier for things like management models to be > reusable. > > This is the wrong direction. It is 64 bits right now. Please keep it (or > extend to 256 :-) > If there's a strong reason for it to be larger - such as trying to ensure uniqueness with randomness, that could be different. My concern is about aspects like MIBs and even YANG modules where the router-id is assumed to be 32 bits. For other protocols, there was a discussion about needing a router-id that was 128 bits so it would be an IPv6 address instead of an IPv4 address, but the general consensus was that the 32-bit router-id isn't intended to be an IPv4 address - even though it is formatted as a dotted quad and operationally frequently assigned to be the IPv4 loopback address. If there are different length router-ids, then correlation between protocols can also be harder. The question is how much these factors apply as the manageability discussion happens. > RFC 6126 has text that the router-id is assigned. Not how it is assigned > automatically. Although one may assume that an unique MAC address would be > fine. But what if I write an implementation that takes the neighbor's MAC? > Yes, I am the crazy guy. > Right - Section 3 just says that the router-id is assigned and assumed unique. MAC addresses can be tempting to use, but they aren't always as unique as assumptions have been. There's work on providing privacy protecting MACs and I have vague memories about MAC reuse in data-centers; I'm sure someone can correct me on the details :-) Maybe those won't apply here and there aren't privacy concerns around tying the identifiers together, but I do think it requires some thought. > Probably the duplicate router-id topic needs some work. Analyses on impact > and mechanisms for detection. The topic is related to security. > I think that would be useful. The question I have for the mailing list and future WG chairs is whether this topic is adequately covered in the proposed charter or needs more text. One of the potential benefits, from a user's perspective, is the potential lack of configuration. If that isn't preserved as a goal and focus, then it is likely to be compromised. Regards, Alia > Teco > > > > > > It would be about two sentences to add DNCP-like conflict detection > (+rerandom) logic to the spec, but I am not sure it is worth it. Juliusz? > > > > If we want this to be picked up and used with no-config by many people, > having it really work and be clearly documented as to how is very important. > > > > Regards, > > Alia > > > > > > Cheers, > > > > -Markus > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > --94eb2c189448a21d400533b7eddd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 26, 2016 at 1:06 AM, Teco Boot <teco@inf-net.nl> wrote= :

> Op 25 mei 2016, om 21:15 heeft Alia Atlas <akatlas@gmail.com> het volgende geschreven:
>
> On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg <markus.stenberg@iki.fi> wrote:
> On 25.5.2016, at 21.37, Alia Atlas <akatlas@gmail.com> wrote:
> > If I understand the desired requirements discussed in homenet cor= rectly, there is a need for Babel to have a mode that requires no configura= tion - where it simply handles auto-configuration - perhaps from other info= rmation.
> >
> > I don't see this described in RFC 6126 or in draft-chroboczek= -homenet-babel-profile-00.
> >
> > What work do you see as necessary and where do you picture this b= eing done?
>
> It is mostly there. Only annoyance is the router ID, which is assumed = to be unique based on EUI64-like process.
>
> I thought that it was mostly there, but when I went back with that per= spective, I didn't see it called out or discussed.=C2=A0 This is a majo= r advantage - and one that extensions and security need to consider and pre= serve.
>
> On the Router ID, I think that it is worth considering making it the s= ame 32 bits that a Router ID is in all the other standardized routing proto= cols.=C2=A0 That'll make it easier for things like management models to= be reusable.

This is the wrong direction. It is 64 bits right now. Please keep it= (or extend to 256 :-)

If there's a= strong reason for it to be larger - such as trying to ensure uniqueness wi= th randomness, that could be different.=C2=A0 My concern is about aspects l= ike MIBs and even YANG modules where the router-id is assumed to be 32 bits= .=C2=A0 For other protocols, there was a discussion about needing a router-= id that was 128 bits so it would be an IPv6 address instead of an IPv4 addr= ess, but the general consensus was that the 32-bit router-id isn't inte= nded to be an IPv4 address - even though it is formatted as a dotted quad a= nd operationally frequently assigned to be the IPv4 loopback address.
=

If there are different length router-ids, then correlat= ion between protocols can also be harder.=C2=A0 The question is how much th= ese factors apply as the manageability discussion happens.
=C2=A0=
RFC 6126 has text that the router-id is assigned. Not how it is assigned au= tomatically. Although one may assume that an unique MAC address would be fi= ne. But what if I write an implementation that takes the neighbor's MAC= ? Yes, I am the crazy guy.

Right - Sect= ion 3 just says that the router-id is assigned and assumed unique.=C2=A0 MA= C addresses can be tempting to use, but they aren't always as unique as= assumptions have been.=C2=A0 There's work on providing privacy protect= ing MACs and I have vague memories about MAC reuse in data-centers; I'm= sure someone can correct me on the details :-) =C2=A0Maybe those won't= apply here and there aren't privacy concerns around tying the identifi= ers together, but I do think it requires some thought.
=C2=A0
Probably the duplicate router-id topic needs some work. Analyses on impact = and mechanisms for detection. The topic is related to security.

I think that would be useful.=C2=A0 The question I= have for the mailing list and future WG chairs is whether this topic is ad= equately covered in the proposed charter or needs more text.

=
One of the potential benefits, from a user's perspective, is= the potential lack of configuration.=C2=A0 If that isn't preserved as = a goal and focus, then it is likely to be compromised.

=
Regards,
Alia

=C2=A0
Teco


>
> It would be about two sentences to add DNCP-like conflict detection (+= rerandom) logic to the spec, but I am not sure it is worth it. Juliusz?
>
> If we want this to be picked up and used with no-config by many people= , having it really work and be clearly documented as to how is very importa= nt.
>
> Regards,
> Alia
>
>
> Cheers,
>
> -Markus
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel


--94eb2c189448a21d400533b7eddd-- From nobody Wed May 25 22:34:58 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9265D12D5A5 for ; Wed, 25 May 2016 22:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-mh8JuQBmv4 for ; Wed, 25 May 2016 22:34:54 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDCA12D13E for ; Wed, 25 May 2016 22:34:54 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n129so209018131wmn.1 for ; Wed, 25 May 2016 22:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=JuZy/GLIqdhWjIW1j7KqrfBN7XtpsD1DQUuTlIkF7sQ=; b=Q8m9J/G/IoByLHZDFwtYjiS8IxDOYguVBB9YYE0wCgnZgXnocOIceI18UYXsZEqaK4 dveDXiX3dEOQf2KZqPbTa9z5YJlkn19PienL3d1jEhafOvnWGB12unRrGClIhpSk21qT gxRARGwq76w8Kvca+7EGVYgFILSw+clpZk+n6aL8MqPLp85xVeWj+DuGFD2MlCMmvKs2 gEVw0ZtOArRGes6HBuK5fBpLD0XmGXKOmjjSlnH2BS4ZLnVj/DeRcf3PTq3ahUFDYLe2 euHI/C7usVh65JCkzqqvMG8yEk7FoqAkwUbs1sZy+QYUndbL0NtV0P3OAO0u7++4dQYL CVsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=JuZy/GLIqdhWjIW1j7KqrfBN7XtpsD1DQUuTlIkF7sQ=; b=U3Fk1RZQIqaUAD8oqXbl9vUXLfmHoJs2SDgEMXgkf2vyK5i0cyQ5qRchavy6Ar+kt2 4zIGrzP9Uf+hLafRatUTkwYGF3JCsv1fPb/8ODQGqExV+dS1+X4EmH8noXnuEDPXQh+S EX4xXkGhJOqL2znU7LRJ2NPy7J6Fijk7hGpC1bXc8lOj2B3jQfKxoD2dzehDE/nZmRa8 zI9Qt30YvRmc28sMVycdfYOPsk4DUM+OYcCY4IbJ7wysQsIH+mYC+gdNUYOOwoJaEhUA jUgenKZ1OqNNBtE3chMuWwEQkcYKGlTQZkpvIzA8G6XIE70lRDFQ7sBPKtWHv9ILs5a1 1i5A== X-Gm-Message-State: ALyK8tLQNZnoiXjUWwzAsj+yKt20A2OlxrpfNAoAQSj5oXF98voDJSwWbUBcl5Y/yuY7Rg== X-Received: by 10.28.62.69 with SMTP id l66mr1493909wma.70.1464240892495; Wed, 25 May 2016 22:34:52 -0700 (PDT) Received: from [172.24.250.201] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id c2sm1566229wme.4.2016.05.25.22.34.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 22:34:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AE67985E-B434-4C38-B339-1FEC2E7B1CA6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: Date: Thu, 26 May 2016 08:34:49 +0300 Message-Id: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> To: Teco Boot X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Markus Stenberg , Bob Hinden , Babel at IETF , Alia Atlas Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 05:34:56 -0000 --Apple-Mail=_AE67985E-B434-4C38-B339-1FEC2E7B1CA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Teco, > On May 26, 2016, at 8:06 AM, Teco Boot wrote: >=20 >=20 >> Op 25 mei 2016, om 21:15 heeft Alia Atlas het = volgende geschreven: >>=20 >> On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg = wrote: >> On 25.5.2016, at 21.37, Alia Atlas wrote: >>> If I understand the desired requirements discussed in homenet = correctly, there is a need for Babel to have a mode that requires no = configuration - where it simply handles auto-configuration - perhaps = from other information. >>>=20 >>> I don't see this described in RFC 6126 or in = draft-chroboczek-homenet-babel-profile-00. >>>=20 >>> What work do you see as necessary and where do you picture this = being done? >>=20 >> It is mostly there. Only annoyance is the router ID, which is assumed = to be unique based on EUI64-like process. >>=20 >> I thought that it was mostly there, but when I went back with that = perspective, I didn't see it called out or discussed. This is a major = advantage - and one that extensions and security need to consider and = preserve. >>=20 >> On the Router ID, I think that it is worth considering making it the = same 32 bits that a Router ID is in all the other standardized routing = protocols. That'll make it easier for things like management models to = be reusable. >=20 > This is the wrong direction. It is 64 bits right now. Please keep it = (or extend to 256 :-) I like the idea of keeping it 64bits, that is a reasonable size and it = won=E2=80=99t be confused with an IP address (v4 or v6). >=20 > RFC 6126 has text that the router-id is assigned. Not how it is = assigned automatically. Although one may assume that an unique MAC = address would be fine. But what if I write an implementation that takes = the neighbor's MAC? Yes, I am the crazy guy. >=20 > Probably the duplicate router-id topic needs some work. Analyses on = impact and mechanisms for detection. The topic is related to security. This is probably going to be challenging. It=E2=80=99s hard enough to = do duplicate detection on a single subnet (like IPv6 DAD), but doing = across an AS will be harder. For example dealing with partitions, = routers being added and deleted, etc. Important to have good = recommendations for selecting a unique router ID in the first place. Bob >=20 > Teco >=20 >=20 >>=20 >> It would be about two sentences to add DNCP-like conflict detection = (+rerandom) logic to the spec, but I am not sure it is worth it. = Juliusz? >>=20 >> If we want this to be picked up and used with no-config by many = people, having it really work and be clearly documented as to how is = very important. >>=20 >> Regards, >> Alia >>=20 >>=20 >> Cheers, >>=20 >> -Markus >>=20 >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_AE67985E-B434-4C38-B339-1FEC2E7B1CA6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXRor5AAoJEK7rdBF357uosdQH/1/Uwb7/5OuXPDAYTBnaFJfa 2S9/YXsFUogeXSWyTZ5IFCHxCln8cemq+NCfkD/rirV5lopRTi24//G2lLBo6gIk vG0kXjXrVir4v86WRx607Ow9SGBvRIcpxCVozmyNewObWs0z54jr0wnTip5Uzk6a iJ4+W3QNffgkfmbtXc0by/+6ap0WRDkVmkLvEpnHj/QH1bTqtGkW++FQ7rMIjmVf RdnY4S/On4xftzlB7HDKawTV4ysWE4/us6aDHRVglancyNrHqGTXtpimfHAFb/R/ iJsN2MiYPtaolAPI8iGXfpnBty4O293mXWBoUxq0i75/xkU1kq7GnTsZBVwyOhs= =Thz/ -----END PGP SIGNATURE----- --Apple-Mail=_AE67985E-B434-4C38-B339-1FEC2E7B1CA6-- From nobody Wed May 25 23:06:11 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3817012D191 for ; Wed, 25 May 2016 23:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 888kGL7HQVCJ for ; Wed, 25 May 2016 23:06:08 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9809012B05E for ; Wed, 25 May 2016 23:06:08 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id l10so41777476igk.0 for ; Wed, 25 May 2016 23:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=x5JFFbb05b/N02oHCykZf+LpHGO1ClkPzYsCwhDdGls=; b=HjxQ9L92QYDBU+/5upwh0VdOP/KsvO71vyXMImKX7xUBd1bAlQPh5sOcbqWGTv2U2E 9FDcxom97ti/80BHhOE8m4NU+1BlvTV/TsS6rRP7amYBuAXlE+LQh4kT0xuCz2zTj285 BWdqgGmiTDQ+Vs+3VoX7W3MrpveUt7xYOpoAa6OILMnlm0wOG39vDAnnh/4IpbEmM+8j Ru/GFawk0/wFzQP1rjVZQunYmDkx0P13JK+pMA80sW1jTRq91i92Zr4YirZQshqz6ZLy QLUSrcJaNLhM9+IZ/a1H1APbsULyf7Dw6tmEqzMzrVRH+ow0wGK7Dxas4Oj4AvHYlORJ R7Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=x5JFFbb05b/N02oHCykZf+LpHGO1ClkPzYsCwhDdGls=; b=lX7gAnVYL0236ILkoVKfOy9uCfuduXVjfElwNvCvKrz8lwmjXj//ehgjAiI6OWQOc9 5nP5VEts2lZwXjlDAYMlj9BSZ6RcMIxL6ZkGQ32aC4cxFhF2FvvoODDEFKOrB1PkLSYR bc1CH0OMwqBeFCkhOZI/Adyh0TmL0LAzjhi32swMtQxpYwpqJs1yR0hAxwOg8s9IPdqD t1gOdI9sxW4vmUuT7tloYOXCqpTP+SXZ9CEVm/d/B8N9WS3JAXTbF8TcQDaQ4xtUeHfq MXzXvnFud4j2J8OuwlJLOHmYjdMmdNvRpKy+/TWGPrHatNsOm3/q4USNz8Mb543fxM1+ 8G8g== X-Gm-Message-State: ALyK8tJr+dC4tgRbm5hnVUt7S9PXpzxgoXD/ILzGnfd+NpyF1Z5fukfl96HjrgrN5gfL2l26sLk0t3YM4nEaJQ== X-Received: by 10.50.29.45 with SMTP id g13mr1593869igh.93.1464242767916; Wed, 25 May 2016 23:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.156 with HTTP; Wed, 25 May 2016 23:05:28 -0700 (PDT) In-Reply-To: References: From: Tony Przygienda Date: Wed, 25 May 2016 23:05:28 -0700 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=047d7bd7528c0c0c100533b8964b Archived-At: Subject: Re: [babel] babel Digest, Vol 9, Issue 19 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 06:06:10 -0000 --047d7bd7528c0c0c100533b8964b Content-Type: text/plain; charset=UTF-8 right, on MACs you loose if you assume they're unique, the IEEE block stuff doesn't hold up anymore with VMs and whatever not and on top you always have to contend with the U/L MAC bit That was one of my original comments, the unique router-ID as anchor for self-config. Well, other people fought the problem so it's probably just finding the right reference. Recent OSPF/ISIS work comes to mind, previous attempts @ ZEROCONF, http://dl.acm.org/citation.cfm?id=2140282.2140307 and so on ... thanks -- tony Alia proclaimed: > > Right - Section 3 just says that the router-id is assigned and assumed > unique. MAC addresses can be tempting to use, but they aren't always as > unique as assumptions have been. There's work on providing privacy > protecting MACs and I have vague memories about MAC reuse in data-centers; > I'm sure someone can correct me on the details :-) Maybe those won't apply > here and there aren't privacy concerns around tying the identifiers > together, but I do think it requires some thought. > > >> Probably the duplicate router-id topic needs some work. Analyses on >> impact and mechanisms for detection. The topic is related to security. >> > > I think that would be useful. The question I have for the mailing list > and future WG chairs is whether this topic is adequately covered in the > proposed charter or needs more text. > > One of the potential benefits, from a user's perspective, is the potential > lack of configuration. If that isn't preserved as a goal and focus, then > it is likely to be compromised. > > Regards, > Alia > > --047d7bd7528c0c0c100533b8964b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
right, on MACs you loose if you assume they're un= ique, the IEEE block stuff doesn't hold up anymore with VMs and whateve= r not and on =C2=A0top you always have to contend with the U/L MAC bit=C2= =A0

That was one of my original comments, the uniq= ue router-ID as anchor for self-config. Well, other people fought the probl= em so it's probably just finding the right reference. Recent OSPF/ISIS = work comes to mind, previous attempts @ ZEROCONF, http://dl.acm.org/citation.cfm?id=3D= 2140282.2140307=C2=A0and so on ...=C2=A0

thank= s=C2=A0

-- tony=C2=A0

Alia proclaimed:

Right - Section 3 just says that the= router-id is assigned and assumed unique.=C2=A0 MAC addresses can be tempt= ing to use, but they aren't always as unique as assumptions have been.= =C2=A0 There's work on providing privacy protecting MACs and I have vag= ue memories about MAC reuse in data-centers; I'm sure someone can corre= ct me on the details :-) =C2=A0Maybe those won't apply here and there a= ren't privacy concerns around tying the identifiers together, but I do = think it requires some thought.
=C2=A0
Probably the duplicate router-id topic needs some work. Analyses on impact = and mechanisms for detection. The topic is related to security.

I think that would be useful.=C2=A0 The question I= have for the mailing list and future WG chairs is whether this topic is ad= equately covered in the proposed charter or needs more text.

=
One of the potential benefits, from a user's perspective, is= the potential lack of configuration.=C2=A0 If that isn't preserved as = a goal and focus, then it is likely to be compromised.

=
Regards,
Alia

--047d7bd7528c0c0c100533b8964b-- From nobody Thu May 26 00:27:38 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5494E12D59D for ; Thu, 26 May 2016 00:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMJnk8G43OLD for ; Thu, 26 May 2016 00:27:35 -0700 (PDT) Received: from hupie.dyndns.org (hupie.dyndns.org [80.101.237.101]) by ietfa.amsl.com (Postfix) with ESMTP id 0634312D0A8 for ; Thu, 26 May 2016 00:27:34 -0700 (PDT) Received: from paul.internal.Hupie.com (hupie.dyndns.org [80.101.237.101]) by hupie.dyndns.org (Postfix) with ESMTP id 0793B4809F1 for ; Thu, 26 May 2016 09:27:33 +0200 (CEST) From: Ferry Huberts To: babel@ietf.org References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> Message-ID: <64c1c24b-55a4-5aa2-b567-5da243f83005@hupie.com> Date: Thu, 26 May 2016 09:27:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 07:27:37 -0000 On 26/05/16 07:19, Alia Atlas wrote: > On Thu, May 26, 2016 at 1:06 AM, Teco Boot > wrote: > > > > Op 25 mei 2016, om 21:15 heeft Alia Atlas > het volgende geschreven: > > > > On Wed, May 25, 2016 at 3:10 PM, Markus Stenberg > wrote: > > On 25.5.2016, at 21.37, Alia Atlas > wrote: > > > If I understand the desired requirements discussed in homenet correctly, there is a need for Babel to have a mode that requires no configuration - where it simply handles auto-configuration - perhaps from other information. > > > > > > I don't see this described in RFC 6126 or in draft-chroboczek-homenet-babel-profile-00. > > > > > > What work do you see as necessary and where do you picture this being done? > > > > It is mostly there. Only annoyance is the router ID, which is assumed to be unique based on EUI64-like process. > > > > I thought that it was mostly there, but when I went back with that perspective, I didn't see it called out or discussed. This is a major advantage - and one that extensions and security need to consider and preserve. > > > > On the Router ID, I think that it is worth considering making it the same 32 bits that a Router ID is in all the other standardized routing protocols. That'll make it easier for things like management models to be reusable. > > This is the wrong direction. It is 64 bits right now. Please keep it > (or extend to 256 :-) > > > If there's a strong reason for it to be larger - such as trying to > ensure uniqueness with randomness, that could be different. My concern > is about aspects like MIBs and even YANG modules where the router-id is > assumed to be 32 bits. For other protocols, there was a discussion > about needing a router-id that was 128 bits so it would be an IPv6 > address instead of an IPv4 address, but the general consensus was that Using IP addresses as router/stack IDs is not a good idea. How would you assign one and how would you make that deterministic, especially on nodes with many such addresses? A better idea would be to use UUIDs combined with a de-deplication mechanism (that would almost never run). UUIDs can be generated and almost never clash, if they're wide enough bit-wise. So making the field 128 bits allows for generic UUIDs to be used as well as IPv6 address if people really want that. My 2 cents Ferry > the 32-bit router-id isn't intended to be an IPv4 address - even though > it is formatted as a dotted quad and operationally frequently assigned > to be the IPv4 loopback address. > > If there are different length router-ids, then correlation between > protocols can also be harder. The question is how much these factors > apply as the manageability discussion happens. > > > RFC 6126 has text that the router-id is assigned. Not how it is > assigned automatically. Although one may assume that an unique MAC > address would be fine. But what if I write an implementation that > takes the neighbor's MAC? Yes, I am the crazy guy. > > > Right - Section 3 just says that the router-id is assigned and assumed > unique. MAC addresses can be tempting to use, but they aren't always as > unique as assumptions have been. There's work on providing privacy > protecting MACs and I have vague memories about MAC reuse in > data-centers; I'm sure someone can correct me on the details :-) Maybe > those won't apply here and there aren't privacy concerns around tying > the identifiers together, but I do think it requires some thought. > > > Probably the duplicate router-id topic needs some work. Analyses on > impact and mechanisms for detection. The topic is related to security. > > > I think that would be useful. The question I have for the mailing list > and future WG chairs is whether this topic is adequately covered in the > proposed charter or needs more text. > > One of the potential benefits, from a user's perspective, is the > potential lack of configuration. If that isn't preserved as a goal and > focus, then it is likely to be compromised. > > Regards, > Alia > > > > Teco > > > > > > It would be about two sentences to add DNCP-like conflict detection (+rerandom) logic to the spec, but I am not sure it is worth it. Juliusz? > > > > If we want this to be picked up and used with no-config by many people, having it really work and be clearly documented as to how is very important. > > > > Regards, > > Alia > > > > > > Cheers, > > > > -Markus > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > -- Ferry Huberts From nobody Thu May 26 03:38:02 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD1E12DA6C for ; Thu, 26 May 2016 03:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn-yE7ew3TTv for ; Thu, 26 May 2016 03:37:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A6212DA59 for ; Thu, 26 May 2016 03:37:58 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4QAbr5n007048; Thu, 26 May 2016 12:37:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8D08061F9A; Thu, 26 May 2016 12:37:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Y-UhqHaliy6s; Thu, 26 May 2016 12:37:52 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9056561FA7; Thu, 26 May 2016 12:37:48 +0200 (CEST) Date: Thu, 26 May 2016 12:37:53 +0200 Message-ID: <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 26 May 2016 12:37:54 +0200 (CEST) X-Miltered: at korolev with ID 5746D201.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5746D201.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5746D201.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Teco Boot , Markus Stenberg , Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 10:38:01 -0000 >> This is the wrong direction. It is 64 bits right now. Please keep it (or >> extend to 256 :-) > If there's a strong reason for it to be larger - such as trying to ensure > uniqueness with randomness, that could be different. The intent here is that router-ids are similar to IPv6 node identifiers, and should be allocated in the same manner. (RFC 6126 was written before modified EUI-64 was deprecated, and the wording reflects that.) In addition, 64 bits is large enough to fit an identifier from some other protocol, such as an OSPF router ID (32 bits) or an amateur radio call-sign (up to 6 ASCII characters). > My concern is about aspects like MIBs and even YANG modules where the > router-id is assumed to be 32 bits. Please fix SNMP and YANG. 32 bits is tiny, not enough to do random allocations with a sufficient probability of uniqueness. > If there are different length router-ids, then correlation between protocols > can also be harder. Right. If you already have an OSPF router-id, then you can just pad it to 64 bits. The other way doesn't work, obviously. > Right - Section 3 just says that the router-id is assigned and assumed unique. > MAC addresses can be tempting to use, but they aren't always as unique as > assumptions have been. Randomly chosen router-ids are fine. In a 64 bit space, the probability of a collision in a network with 10000 routers, assuming a perfect RNG, is roughly 3×10^-12. This means that if you renumber every second, in a network with 10000 routers you'll run into one collision roughly once per 10 millenia. > One of the potential benefits, from a user's perspective, is the potential > lack of configuration. Pick the router-id randomly, and be done with it. Or use a MAC address, and deal with the consequences in case of duplication. Markus wrote: > It would be about two sentences to add DNCP-like conflict detection > (+rerandom) logic to the spec, but I am not sure it is worth > it. Juliusz? Not sure, given the probability of collision. Perhaps describe it in an informational appendix as an optional mechanism? I'm more interested in being able to detect spurious collisions (stale data making routes unfeasible after you reboot and lose your state). I'm not sure if it can be done. – Juliusz From nobody Thu May 26 05:23:51 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD1812DE57 for ; Thu, 26 May 2016 05:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWIrDrQFFg9m for ; Thu, 26 May 2016 05:23:47 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.232]) by ietfa.amsl.com (Postfix) with ESMTP id 7894D12DAEB for ; Thu, 26 May 2016 05:23:45 -0700 (PDT) Received: from [192.168.43.129] (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E14E9D04D76132; Thu, 26 May 2016 15:23:07 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Markus Stenberg In-Reply-To: <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 26 May 2016 15:23:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Teco Boot , Babel at IETF , Alia Atlas Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 12:23:50 -0000 > On 26.5.2016, at 13.37, Juliusz Chroboczek = wrote: >> It would be about two sentences to add DNCP-like conflict detection >> (+rerandom) logic to the spec, but I am not sure it is worth >> it. Juliusz? > Not sure, given the probability of collision. Perhaps describe it in = an > informational appendix as an optional mechanism? Birthday paradox =3D> given real PRNG problems start cropping = _certainly_ near 2^32 devices with 64-bit ids (it is roughly sqrt when = you get 50% chance of collision). That said.. I am not sure I agree with you, given how bad PRNGs can be on embedded = devices etc. _Given_ cryptographically strong PRNG, I agree with your = point, but I have seen (and used) so many broken ones over the time that = I would not count on it. For example, the classic srand(time(NULL)) breaks if you have two = devices starting at same time; that is not a problem unless you want to = reboot your network or electricity goes down. Cheers, -Markus= From nobody Thu May 26 05:48:19 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C0C12DEA4 for ; Thu, 26 May 2016 05:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7WniQLQcElx for ; Thu, 26 May 2016 05:48:16 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1129212DE98 for ; Thu, 26 May 2016 05:48:15 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4QCmDk7029794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 May 2016 14:48:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4QCmDcG025678; Thu, 26 May 2016 14:48:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 48C3661FA7; Thu, 26 May 2016 14:48:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id o9WMCOb0QR-E; Thu, 26 May 2016 14:48:11 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CC49261FA5; Thu, 26 May 2016 14:48:11 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.87) (envelope-from ) id 1b5uhv-0007qb-Jv; Thu, 26 May 2016 14:48:11 +0200 Date: Thu, 26 May 2016 14:48:11 +0200 Message-ID: <7ia8jd6l4k.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Markus Stenberg In-Reply-To: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 26 May 2016 14:48:13 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 26 May 2016 14:48:13 +0200 (CEST) X-Miltered: at korolev with ID 5746F08D.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5746F08D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5746F08D.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5746F08D.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5746F08D.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5746F08D.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Teco Boot , Babel at IETF , Alia Atlas Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 12:48:17 -0000 > I am not sure I agree with you, given how bad PRNGs can be on embedded > devices etc. _Given_ cryptographically strong PRNG, I agree with your > point, but I have seen (and used) so many broken ones over the time that > I would not count on it. > For example, the classic srand(time(NULL)) breaks if you have two > devices starting at same time; that is not a problem unless you want to > reboot your network or electricity goes down. Yes, stupid people will do stupid things. srand(time(NULL)) is obviously stupid. Concatenate tv_sec, tv_usec, all the MAC addresses you can find and all the IP addresses you can find, push that through sha1, truncate to 64 bits, and you've got a serious chance of being unique. This doesn't require any hardware support. IMHO, the fact that it is possible to be stupid doesn't imply that we should be protecting against that in the spec, but we should be detecting collisions in quality implementations. Whether this is possible without getting confused when a node reboots without changing its router-id is something I don't know. -- Juliusz From nobody Thu May 26 05:50:24 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0BC12DB2D for ; Thu, 26 May 2016 05:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYHexOnOG0O0 for ; Thu, 26 May 2016 05:50:21 -0700 (PDT) Received: from hupie.dyndns.org (hupie.dyndns.org [80.101.237.101]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC2512DB1D for ; Thu, 26 May 2016 05:50:21 -0700 (PDT) Received: from paul.internal.Hupie.com (hupie.dyndns.org [80.101.237.101]) by hupie.dyndns.org (Postfix) with ESMTP id 5BCA3480DA9; Thu, 26 May 2016 14:50:20 +0200 (CEST) To: Juliusz Chroboczek , Markus Stenberg References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <7ia8jd6l4k.wl-jch@pps.univ-paris-diderot.fr> From: Ferry Huberts Message-ID: <37a4a8f5-005b-88e7-38e6-40927bbd8c78@hupie.com> Date: Thu, 26 May 2016 14:50:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7ia8jd6l4k.wl-jch@pps.univ-paris-diderot.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Teco Boot , Babel at IETF , Alia Atlas Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 12:50:23 -0000 On 26/05/16 14:48, Juliusz Chroboczek wrote: >> I am not sure I agree with you, given how bad PRNGs can be on embedded >> devices etc. _Given_ cryptographically strong PRNG, I agree with your >> point, but I have seen (and used) so many broken ones over the time that >> I would not count on it. > >> For example, the classic srand(time(NULL)) breaks if you have two >> devices starting at same time; that is not a problem unless you want to >> reboot your network or electricity goes down. > > Yes, stupid people will do stupid things. srand(time(NULL)) is obviously > stupid. > > Concatenate tv_sec, tv_usec, all the MAC addresses you can find and all > the IP addresses you can find, push that through sha1, truncate to 64 > bits, and you've got a serious chance of being unique. This doesn't > require any hardware support. > > IMHO, the fact that it is possible to be stupid doesn't imply that we > should be protecting against that in the spec, but we should be detecting > collisions in quality implementations. Whether this is possible without > getting confused when a node reboots without changing its router-id is > something I don't know. > Easily avoided by 'un-announcing' itself before rebooting > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > -- Ferry Huberts From nobody Thu May 26 06:09:51 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5325C12D0FA for ; Thu, 26 May 2016 06:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJXatVqE-OgG for ; Thu, 26 May 2016 06:09:48 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1690112D633 for ; Thu, 26 May 2016 06:09:48 -0700 (PDT) Received: from [192.168.43.129] (80.220.86.47) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56E14E9D04D7A101; Thu, 26 May 2016 16:09:13 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Markus Stenberg In-Reply-To: <7ia8jd6l4k.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 26 May 2016 16:09:44 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <7ia8jd6l4k.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Teco Boot , Babel at IETF , Alia Atlas Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 13:09:50 -0000 > On 26.5.2016, at 15.48, Juliusz Chroboczek = wrote: >> I am not sure I agree with you, given how bad PRNGs can be on = embedded >> devices etc. _Given_ cryptographically strong PRNG, I agree with your >> point, but I have seen (and used) so many broken ones over the time = that >> I would not count on it. >=20 >> For example, the classic srand(time(NULL)) breaks if you have two >> devices starting at same time; that is not a problem unless you want = to >> reboot your network or electricity goes down. > Yes, stupid people will do stupid things. srand(time(NULL)) is = obviously > stupid. >=20 > Concatenate tv_sec, tv_usec, all the MAC addresses you can find and = all > the IP addresses you can find, push that through sha1, truncate to 64 > bits, and you've got a serious chance of being unique. This doesn't > require any hardware support. tv_* in the power reset case are close to each other given NTP. tv_usec = accuracy is usually far from what you would hope (e.g. 1ms accuracy is = entirely likely -> results are more or less always same given same = hardware and same boot time, +- little). In virtualized case (hello, VM) or cheapo vendor case, MACs uniqueness = is not guaranteeable. I would say your PRNG is not good either. I am fine if we define = idiot-proof PRNG that actually fullfills these criteria in the spec but = I would rather not, and therefore detecting collisions is the lower = hanging fruit (this is why DNCP went that way; of course, HNCP, with the = shorter router ids, is more vulnerable to this as well). Cheers, -Markus= From nobody Thu May 26 07:40:55 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3712D6A0 for ; Thu, 26 May 2016 07:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4bjz5Cf_63A for ; Thu, 26 May 2016 07:40:52 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CCF12D17C for ; Thu, 26 May 2016 07:40:51 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 146427364903223.30373021799585; Thu, 26 May 2016 07:40:49 -0700 (PDT) Date: Thu, 26 May 2016 15:40:48 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <154ed82bd50.c2821e78205515.5581881600247759667@ovsienko.info> In-Reply-To: <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 14:40:54 -0000 ---- On Thu, 26 May 2016 11:37:53 +0100 Juliusz Chroboczek wrote ---- > >> This is the wrong direction. It is 64 bits right now. Please keep it (or > >> extend to 256 :-) > > > If there's a strong reason for it to be larger - such as trying to ensure > > uniqueness with randomness, that could be different. > > The intent here is that router-ids are similar to IPv6 node identifiers, > and should be allocated in the same manner. (RFC 6126 was written before > modified EUI-64 was deprecated, and the wording reflects that.) > > In addition, 64 bits is large enough to fit an identifier from some other > protocol, such as an OSPF router ID (32 bits) or an amateur radio > call-sign (up to 6 ASCII characters). [...] Ham callsigns roughly correspond to BGP AS numbers, not router IDs. And sometimes they may require prefixes and suffixes. But technicalities aside, would it help to try to state the problem the router ID is expected to solve? As far as I recall now, the very minimal requirements to a router ID would be: * must be unique * must remain persistent as long as the protocol instance keeps running * should be persistent across reboots (from a network engineer's point of view to keep troubleshooting simpler) And as far as EUI-64 goes, it does the small job one expects it to do: unique input => unique output. If the expectations from the router ID are higher, can we try to state those? With regard to unique input, in the case of routers the [traditional hard] disk activity and the audio input as discussed in RFC 4086 are out of scope. I don't have the competence to estimate how much entropy flash storage provides, it is quite possible a proper MAC address is still way ahead of PRNG if you have a few hundred small plastic boxes at hand. Of course, in practice hardware MAC addresses do occasionally happen to be duplicate or made-up or both. But that's just a factory defect and is best handled as such. It would be useful for a Babel speaker to detect the situation and "blow the fuse" but going beyond and trying to hide the problem doesn't seem to be quite right. -- Denis Ovsienko From nobody Thu May 26 18:40:36 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87F012B04D for ; Thu, 26 May 2016 18:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQOJN_Vmajqt for ; Thu, 26 May 2016 18:40:33 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B785A12B038 for ; Thu, 26 May 2016 18:40:32 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4R1eU03028535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 May 2016 03:40:30 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4R1eT17024740; Fri, 27 May 2016 03:40:29 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 580FC61FA5; Fri, 27 May 2016 03:40:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KS0e3uI1BlCS; Fri, 27 May 2016 03:40:28 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3E94761F9A; Fri, 27 May 2016 03:40:25 +0200 (CEST) Date: Fri, 27 May 2016 03:40:31 +0200 Message-ID: <87vb20p9bk.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Ferry Huberts In-Reply-To: <37a4a8f5-005b-88e7-38e6-40927bbd8c78@hupie.com> References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <7ia8jd6l4k.wl-jch@pps.univ-paris-diderot.fr> <37a4a8f5-005b-88e7-38e6-40927bbd8c78@hupie.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 27 May 2016 03:40:30 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 27 May 2016 03:40:30 +0200 (CEST) X-Miltered: at korolev with ID 5747A58E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5747A58D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5747A58E.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5747A58D.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5747A58E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5747A58D.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Teco Boot , Markus Stenberg , Babel at IETF , Alia Atlas Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 01:40:35 -0000 >> IMHO, the fact that it is possible to be stupid doesn't imply that we >> should be protecting against that in the spec, but we should be detecting >> collisions in quality implementations. Whether this is possible without >> getting confused when a node reboots without changing its router-id is >> something I don't know. > Easily avoided by 'un-announcing' itself before rebooting We already do, but we're running over an unreliable lower layer. Nothing guarantees that the retraction doesn't get lost. We're also trying to be robust against nodes crashing or being power-cycled uncleanly (which is the normal way to reboot a home router). -- Juliusz From nobody Thu May 26 18:42:56 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6A712D111 for ; Thu, 26 May 2016 18:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMuMQ_LN9isr for ; Thu, 26 May 2016 18:42:54 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D36012B061 for ; Thu, 26 May 2016 18:42:54 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4R1gqFc029257; Fri, 27 May 2016 03:42:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 884F661FA5; Fri, 27 May 2016 03:42:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id V2tQ0UHoxqJp; Fri, 27 May 2016 03:42:51 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 237B261F9A; Fri, 27 May 2016 03:42:51 +0200 (CEST) Date: Fri, 27 May 2016 03:42:57 +0200 Message-ID: <87twhkp97i.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Markus Stenberg In-Reply-To: References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <7ia8jd6l4k.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 27 May 2016 03:42:52 +0200 (CEST) X-Miltered: at korolev with ID 5747A61C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5747A61C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5747A61C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: Teco Boot , Babel at IETF , Alia Atlas Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 01:42:56 -0000 > I am fine if we define idiot-proof PRNG that actually fullfills these > criteria in the spec but I would rather not, and therefore detecting > collisions is the lower hanging fruit (this is why DNCP went that way; > of course, HNCP, with the shorter router ids, is more vulnerable to this > as well). Okay, point duly noted. I think I'm still disagreeing with you, I'll think it over. -- Juliusz From nobody Thu May 26 18:55:28 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A529112B04D for ; Thu, 26 May 2016 18:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4md_I1Yd3j_2 for ; Thu, 26 May 2016 18:55:24 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6AD12D095 for ; Thu, 26 May 2016 18:55:23 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4R1tMxN032021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 May 2016 03:55:22 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4R1tLoE028150; Fri, 27 May 2016 03:55:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E849361FB8; Fri, 27 May 2016 03:55:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id AjtLMPbwlf6T; Fri, 27 May 2016 03:55:20 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7998F61F9A; Fri, 27 May 2016 03:55:20 +0200 (CEST) Date: Fri, 27 May 2016 03:55:26 +0200 Message-ID: <87shx4p8mp.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <154ed82bd50.c2821e78205515.5581881600247759667@ovsienko.info> References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <154ed82bd50.c2821e78205515.5581881600247759667@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 27 May 2016 03:55:22 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 27 May 2016 03:55:22 +0200 (CEST) X-Miltered: at korolev with ID 5747A90A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5747A909.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5747A90A.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5747A909.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5747A90A.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5747A909.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 01:55:25 -0000 > would it help to try to state the problem the router ID is expected to solve? Yes, let's. > As far as I recall now, the very minimal requirements to a router ID would be: > * must be unique Yes. > * must remain persistent as long as the protocol instance keeps running Not necessarily. You can change router-ids gracefully, you just reannounce all of your routes with the new router-id then retract all routes with the old router-id. Everytime you do that, you destroy the loop-avoidance state about you, so you run a small risk of creating transient routing loops if the retraction gets lost and then there's a metric increase. > * should be persistent across reboots (from a network engineer's point > of view to keep troubleshooting simpler) That's a management issue, not something the protocol cares about. In fact, the protocol works better if router-ids are changed at every restart (since it prevents interference of the loop-avoidance state). > Of course, in practice hardware MAC addresses do occasionally happen to > be duplicate or made-up or both. But that's just a factory defect and is > best handled as such. It would be useful for a Babel speaker to detect > the situation and "blow the fuse" but going beyond and trying to hide > the problem doesn't seem to be quite right. So you're suggesting that « A Babel speaker that detects a duplicate router-id SHOULD log the issue to system management and cease functioning. While it MAY pick a new router-id and continue functioning, doing that is NOT RECOMMENDED. » ? No opinion on that, but it leaves open the problem of whether detecting duplicates is REQUIRED or not. I think we should refrain from discussing that until somebody exhibits a suitable implementation and we can see how simple and robust it is. -- Juliusz From nobody Thu May 26 23:10:01 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B9D12D1BD for ; Thu, 26 May 2016 23:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaUece99Fkrn for ; Thu, 26 May 2016 23:09:56 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C71D12D0B6 for ; Thu, 26 May 2016 23:09:55 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so256465173wmn.1 for ; Thu, 26 May 2016 23:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c/S15VTD2DnwoP7l9FRuMmLtiZa1SlAzbwnuH8y3dBY=; b=PiuoSxExdQJUm4S/9iDS06X5DlF+u+lxQI4GZv9zms0i9RMchlL23tA1d8YM/XoUJV I+N61L35kW7/hHot8CY+fAMrGaHb2z37mezcnZ+XzB53DwuS/RtebMT4cw8O5xbfoyAd svL+fHZLrhjST9OR0X99sSQ2Oa2PtFk/TQsQEyxnYJmtYZ/sFQg4PMviuKFIZbM1j0Q7 /oAUewDGrPcDdJqCCbzQfF+3gV5Utx2AzZSDw3enZsOYuI+r336a6fzggh2RTGK3Km7x RO/jWPi8zvb6MGkT82FW4nN/FXu/vBG/hmec4bdymrW4zKbn44vRLPVbusI/Y4kL4ibi cKNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c/S15VTD2DnwoP7l9FRuMmLtiZa1SlAzbwnuH8y3dBY=; b=bs3M1KSq8mgaI39AadzCTNk/6D6yJTWhNVN8r3ppNiiLQSNXrQ3nqf/+EimMVstlsD D2x834gNzIsnsVqekqAwXBmLbUgPgRbICk+tsCTG5uSPM90KxvXSu6xmChTH8AYOlCg3 jN8Ez5n/swIj57TXTNaiQG4j0LMIFNwQ8QJaVMmJkXOXK5tx3/jscwPKSdV3eQekFE7D 7fqa0SE+7UYau/BnNVmBknEmt1i4MTdWX6A+L6ooy9gchkUc967FfQfb0Tu85MdhNPqg H/UkbSuJ8GsqLjMBQw7XFzlEaXjxckq/G8t/U22OB6MCATglmdvNUQE2g0N1wUvoEVno NvXA== X-Gm-Message-State: ALyK8tKMV3l7pUrxt8TD8p+Y65WLCIzTTlm07HXfgTDJwgrDurGAJV9Jk703WYl7SBvkXA== X-Received: by 10.28.147.7 with SMTP id v7mr6887765wmd.37.1464329394372; Thu, 26 May 2016 23:09:54 -0700 (PDT) Received: from [192.168.178.95] (524A11D6.cm-4-3a.dynamic.ziggo.nl. [82.74.17.214]) by smtp.gmail.com with ESMTPSA id 124sm6880933wml.12.2016.05.26.23.09.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2016 23:09:53 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Teco Boot In-Reply-To: <87shx4p8mp.wl-jch@pps.univ-paris-diderot.fr> Date: Fri, 27 May 2016 08:09:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74056AD5-F8AA-465F-9633-E40E37C0576C@inf-net.nl> References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <154ed82bd50.c2821e78205515.5581881600247759667@ovsienko.info> <87shx4p8mp.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Denis Ovsienko , Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 06:09:59 -0000 > Op 27 mei 2016, om 03:55 heeft Juliusz Chroboczek = het volgende geschreven: >=20 >> would it help to try to state the problem the router ID is expected = to solve? >=20 > Yes, let's. >=20 >> As far as I recall now, the very minimal requirements to a router ID = would be: >> * must be unique >=20 > Yes. >=20 >> * must remain persistent as long as the protocol instance keeps = running >=20 > Not necessarily. You can change router-ids gracefully, you just > reannounce all of your routes with the new router-id then retract all > routes with the old router-id. Everytime you do that, you destroy the > loop-avoidance state about you, so you run a small risk of creating > transient routing loops if the retraction gets lost and then there's > a metric increase. >=20 >> * should be persistent across reboots (from a network engineer's = point >> of view to keep troubleshooting simpler) >=20 > That's a management issue, not something the protocol cares about. In > fact, the protocol works better if router-ids are changed at every = restart > (since it prevents interference of the loop-avoidance state). >=20 >> Of course, in practice hardware MAC addresses do occasionally happen = to >> be duplicate or made-up or both. But that's just a factory defect and = is >> best handled as such. It would be useful for a Babel speaker to = detect >> the situation and "blow the fuse" but going beyond and trying to hide >> the problem doesn't seem to be quite right. >=20 > So you're suggesting that =AB A Babel speaker that detects a duplicate > router-id SHOULD log the issue to system management and cease = functioning. > While it MAY pick a new router-id and continue functioning, doing that = is > NOT RECOMMENDED. =BB ? >=20 > No opinion on that, but it leaves open the problem of whether = detecting > duplicates is REQUIRED or not. I think we should refrain from = discussing > that until somebody exhibits a suitable implementation and we can see = how > simple and robust it is. (not postponing my opinion...) Having a mechanisms handling duplicate router-IDs makes the protocol = more robust against a spoofing attack or bugs. Maybe there are unwanted = side effects (network overload, DOS attack vector), so rate limiting in = router_ID changes would be a SHOULD. Teco >=20 > -- Juliusz >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri May 27 02:46:40 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597D212D63A for ; Fri, 27 May 2016 02:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxKd4i9acTk3 for ; Fri, 27 May 2016 02:46:38 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C05112B010 for ; Fri, 27 May 2016 02:46:37 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464342397224687.0358624309769; Fri, 27 May 2016 02:46:37 -0700 (PDT) Date: Fri, 27 May 2016 10:46:37 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <154f19bc0ec.104a0ab61237886.6112477729817879664@ovsienko.info> In-Reply-To: <87shx4p8mp.wl-jch@pps.univ-paris-diderot.fr> References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <154ed82bd50.c2821e78205515.5581881600247759667@ovsienko.info> <87shx4p8mp.wl-jch@pps.univ-paris-diderot.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 09:46:39 -0000 ---- On Fri, 27 May 2016 02:55:26 +0100 Juliusz Chroboczek wrote ---- >> would it help to try to state the problem the router ID is expected to solve? > >Yes, let's. > >> As far as I recall now, the very minimal requirements to a router ID would be: >> * must be unique > >Yes. > >> * must remain persistent as long as the protocol instance keeps running > >Not necessarily. You can change router-ids gracefully, you just >reannounce all of your routes with the new router-id then retract all >routes with the old router-id. Everytime you do that, you destroy the >loop-avoidance state about you, so you run a small risk of creating >transient routing loops if the retraction gets lost and then there's >a metric increase. > >> * should be persistent across reboots (from a network engineer's point >> of view to keep troubleshooting simpler) > >That's a management issue, not something the protocol cares about. In >fact, the protocol works better if router-ids are changed at every restart >(since it prevents interference of the loop-avoidance state). I agree this is a management issue. But with regard to the last two points, in the context of remote troubleshooting and tech support it is generally helpful to look into a packet dump and be able to compare it with a packet dump from yesterday or a month ago. Just my little bit of experience. >> Of course, in practice hardware MAC addresses do occasionally happen to >> be duplicate or made-up or both. But that's just a factory defect and is >> best handled as such. It would be useful for a Babel speaker to detect >> the situation and "blow the fuse" but going beyond and trying to hide >> the problem doesn't seem to be quite right. > >So you're suggesting that « A Babel speaker that detects a duplicate >router-id SHOULD log the issue to system management and cease functioning. >While it MAY pick a new router-id and continue functioning, doing that is >NOT RECOMMENDED. » ? > >No opinion on that, but it leaves open the problem of whether detecting >duplicates is REQUIRED or not. I think we should refrain from discussing >that until somebody exhibits a suitable implementation and we can see how >simple and robust it is. Something along those lines. Maybe just stop routing and flash the alarm LED. Imagine someone buys a new refrigerator, plugs it in and the washing machine stops working immediately. They can correlate the two facts, reproduce it a few more times on their own and decide on the next step: * return the refrigerator to the shop * call an electrician and hand the obvious problem over * just get rid of the washing machine If instead the washing machine goes off a few months later (refrigerator returns no more accepted) for no visible reason and after a long expensive investigation the electrician starts "Do you remember, the refrigerator you added back then, it..." the frustrated end user would reasonably ask: "Why didn't they both just blow their fuses immediately? It would be so much simpler to resolve on the day!". Whatever particular normative clauses and technical means we agree upon, if in the end we manage to signal engineering faults earliest possible and in a way that is difficult to misunderstand just watching the LEDs, it would be a very worthwhile design goal. I agree running code would be a good argument here. -- Denis Ovsienko From nobody Fri May 27 06:28:47 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE1B12DA97 for ; Fri, 27 May 2016 06:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsZTnpFCbqSj for ; Fri, 27 May 2016 06:28:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFC812B019 for ; Fri, 27 May 2016 06:28:41 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u4RDSdaG018744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 May 2016 15:28:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u4RDSXAQ019745; Fri, 27 May 2016 15:28:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E3BB261FA7; Fri, 27 May 2016 15:28:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4CVIhulToJe8; Fri, 27 May 2016 15:28:32 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D9CD061FA5; Fri, 27 May 2016 15:28:29 +0200 (CEST) Date: Fri, 27 May 2016 15:28:36 +0200 Message-ID: <87lh2vtyt7.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Teco Boot In-Reply-To: <74056AD5-F8AA-465F-9633-E40E37C0576C@inf-net.nl> References: <1D572C28-A38D-4D85-8BD0-2ABE023899A3@iki.fi> <87a8jd2jge.wl-jch@pps.univ-paris-diderot.fr> <154ed82bd50.c2821e78205515.5581881600247759667@ovsienko.info> <87shx4p8mp.wl-jch@pps.univ-paris-diderot.fr> <74056AD5-F8AA-465F-9633-E40E37C0576C@inf-net.nl> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 27 May 2016 15:28:39 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 27 May 2016 15:28:39 +0200 (CEST) X-Miltered: at korolev with ID 57484B87.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57484B81.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57484B87.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57484B81.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 57484B87.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57484B81.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Denis Ovsienko , Babel at IETF Subject: Re: [babel] self-configuration and Babel X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 13:28:45 -0000 >> I think we should refrain from discussing that until somebody exhibits >> a suitable implementation and we can see how simple and robust it is. > Having a mechanisms handling duplicate router-IDs makes the protocol > more robust against a spoofing attack or bugs. I agree, but we need running code. -- Juliusz From nobody Sat May 28 09:26:23 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6640112B011 for ; Sat, 28 May 2016 09:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceykRyS9RXQM for ; Sat, 28 May 2016 09:26:17 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EFE12B00F for ; Sat, 28 May 2016 09:26:16 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e62so13592360ita.1 for ; Sat, 28 May 2016 09:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=mVaM/qkgD2o0bo4rohDUrmGhtiXPK62P0jGrcty78r8=; b=cM26vlrIVCU5GDPp45KgZGJ012R1arHWTi2ytevlo/NQ/nrh1uleOOOzUyjTOGjZbk RRfjtC6esiRhKlQsEpzqywZjCGUPxcZrtPc1U2bn8ET27oYgVHr5yLmL6aOvUr2rtk02 wqieKvIvcdXuPpU4r+juValrUGsapiBy5nf3zIHZjqP0E26MqVU000gEpMk41UKMVMCj hYDEEd0dWl/1mFiwjr46teaYJgHqpZ2a8/ZepsyTYRmIRhVc6BEE9BjdG4V3e/5oqbkk Kr7yHtrMxo9poAduGV68K8ivS2PgaKf90HjY2rKFwTahYaT9Foc3cUnCkzzHV6ggJunx +A/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mVaM/qkgD2o0bo4rohDUrmGhtiXPK62P0jGrcty78r8=; b=YcccLjPrFgzUepN98u3V3I/k6dYr34NUoV1+L5d78hiByWV9R2x0jddQQsPtitRrNo ypA7D3kNx30NCJ4YVENuTfZLjItzN6LfSN6RfZjHr9siD75Kb7hlT2pj6gv/pbPw6iUA eA/8ByUCrG+SAsyj8YBOHgiqSh02tFN+RsmZWQ3qHSjl363yR1yq1+h5f5TSxFyoTcOD Lq9r6i7Yo6NQH89tyB+CkQLn98RWUWb4M1VXymUV0gBbjyY1G2xyh4IvCBSWpS2Kb0+T vYrXoD3phxesfGOOwsracZAw5wIIDQ4IsZ4F2XtYRC00K4jcFhNe12mLwy4CmMrJ4H5W ig3g== X-Gm-Message-State: ALyK8tJTlcEwMX1tyUcVdeZqX7DXNOZx2AEcvYggSdMHCfq57EufONVRBvaDUw7tYDguyDiMuQ4IJaqZ5695XQ== MIME-Version: 1.0 X-Received: by 10.36.9.205 with SMTP id 196mr747869itm.75.1464452776187; Sat, 28 May 2016 09:26:16 -0700 (PDT) Received: by 10.107.13.138 with HTTP; Sat, 28 May 2016 09:26:16 -0700 (PDT) In-Reply-To: <87a8jjfk16.wl-jch@pps.univ-paris-diderot.fr> References: <87a8jjfk16.wl-jch@pps.univ-paris-diderot.fr> Date: Sat, 28 May 2016 18:26:16 +0200 Message-ID: From: Mitar To: babel-users Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel@ietf.org Subject: Re: [babel] [Babel-users] Possible changes to the Babel protocol X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 16:26:19 -0000 Hi! I would be in favor of making an incompatible but improved version, but against forking of current main codebase (and resources directed in maintaining it). So in some way I would be that current main codebase should also move to this new "major" version. I see it simply from the open source project perspective as a new major (backwards incompatible version). In addition, there should be a transition path provided for networks with previous major version. For example, by running both Babel versions in parallel (this might require using a different port for a new version?). Mitar On Sat, May 21, 2016 at 6:33 PM, Juliusz Chroboczek wrote: > Dear all, > > Since the creation of a WG is out of our hands right now, I'd like to > start a discussion about whether we want to make an incompatible revision. > > I'm sending this mail to both lists, please follow-up to babel@ietf. > I suggest that people express their opinions as followups to this mail, > after the discussion has settled I'll summarise and make this into a wiki > page. > > We can adopt one of three approaches. One would be to make an entirely > compatible revision -- tighten the spec, make the extension mechanism > a MUST, etc. > > We could make a revision that is technically incompatible, but retain > version number 2 and design it so that it is possible to implement both > RFC 6126 and IETF Babel at the same time. This would allow us to make > some TLV types optional (deprecate them) or to mark them as reserved. > > The third approach is to make a new, Babel revision 3, which preserves the > spirit of Babel to the extent possible but is not compatible with Babel. > Unless the semantics are too different, it should be possible to implement > both Babel 2 and 3 in a single process with loop avoidance across the two > protocols, but at the cost of doubling the amount of control traffic. > > I hold no opinion at the present time which approach is preferable. I'm > just listing the changes that we could envision. Notes of the form > [jch:...] indicate my current opinion on each change. Whenever possible, > the name of the person who originally suggested the change is indicated in > brackets. > > > * Incompatible changes > > Expand the primary metric to 32 bits (Tony) [jch: don't care, we can > carry a 32-bit metric in an extension TLV, but expanding the primary > metric is simpler] > > Expand the TLV size to 16 bits (Tony) [jch: opposed, 8 bits is plenty > since TLVs must fit within a worst-case MTU] > > Expand the TLV/sub-TLV space to 16 bits [jch: opposed, there's already > a mechanism for expansion of the TLV/sub-TLV space in RFC 7557] > > Add a mandatory bit to TLVs (Tony) [jch: unsure] > > Add a mandatory bit to sub-TLVs (Tony) [jch: in favour, they would > simplify the source-specific encoding quite a bit] > > Clean up the encoding (Joel, Markus) [jch: mildly in favour, but afraid of > bikeshedding] > > > * Semi-compatible changes > > Remove AE 0 and wildcard requests/retractions/IHU (Toke) [jch: in favour, > wildcard requests and retractions are confusing and not useful, wildcard > IHU can be encoded in a more parsimonious manner] > > Remove plain (non-seqno) requests (jch) [jch: in favour, they complicate > the protocol and are not very useful, can be added as an extension if > needed] > > > * Compatible changes > > Reserve router-ids all-zero and all-ones (Toke). [jch: in favour] > > Change the treatment of unfeasible updates from the selected neighbour, > (Section 3.5.4 of RFC 6126, Ondrej) [jch: not sure] > > Change the SHOULD send a request when receiving an unfeasible update to > MUST (Section 3.8.2.2, Tony) [jch: in favour] > > Rework the algorithm for sending requests when starving (Section 3.8.2.1, > jch). [jch: in favour, but requires some experimental work] > > -- Juliusz > > _______________________________________________ > Babel-users mailing list > Babel-users@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m From nobody Tue May 31 06:49:03 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0318412D515 for ; Tue, 31 May 2016 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOYxd0EREV-z for ; Tue, 31 May 2016 06:48:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914E512D107 for ; Tue, 31 May 2016 06:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8912; q=dns/txt; s=iport; t=1464702538; x=1465912138; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BKeTADdwoTsz/vLLAZMOnZ2pniF2crTzUcHe9gR5wRI=; b=TxSuLegVJFtZRZ9QmkoYr4adWj/d8VBzOja5sg86qJbiQXM/JBAgZOF7 nXbOOhpDRIN28yIRacfW+7ztCJnbkSv01BiYmEALReGA9BL7WzmvnIDOT jo3/BuJl/Q5tuq2ldPeLCK5Wcg3aRb5engn3GUgZfT0LgXiqgZUodlcct 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgCslU1X/4YNJK1bgm9NVn0GrhSGd?= =?us-ascii?q?oJqgg8BDYF6IoVvAoE+OBQBAQEBAQEBZSeERgEBBHkQAgEIDjEHIREUEQIEDgW?= =?us-ascii?q?IFQMXDrkXDYQfAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNgkOHXwWOHYUah?= =?us-ascii?q?E0zAYV/hieBeYFphE+IZIdkh2cBHgEBQoNtbok5fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,395,1459814400"; d="scan'208,217";a="108174822" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2016 13:48:57 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4VDmv6B016433 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 May 2016 13:48:57 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 31 May 2016 08:48:56 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 31 May 2016 08:48:56 -0500 From: "Alvaro Retana (aretana)" To: Alia Atlas Thread-Topic: [babel] Draft BABEL Charter Thread-Index: AQHRqtY88Om/StKnZEyBVrJ7b4asLJ+93k2AgAGaVgCAAPkeAIAG6B+AgAvnioA= Date: Tue, 31 May 2016 13:48:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D3730BB2129853aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: Babel at IETF Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 13:49:01 -0000 --_000_D3730BB2129853aretanaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 5/23/16, 4:01 PM, "babel on behalf of Alia Atlas" on behalf of akatlas@gmail.com> wrote: Hi! This looks good to me. Thanks for your work on it. I will add it to the next telechat on June 2. I'm reviewing the charter for the IESG Telechat this week. Because the bal= lot is not yet open, I'm posting comments here. I'm working off what is po= sted in the datatracker [1], which I think is the same as the latest discus= sed 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 t= o me that generically mentioning what amounts to the need to address "comme= nts" is not needed...again, unless there are specific items that could be h= ighlighted in the charter. 2. [nit] Maybe reorder the Work Items mentioning first the ones that are re= quired for advancing to PS, and later others. 3. Is the intent for the 3 main work items (base specification, security, m= anagement) to advance together (to IESG review, etc.)? If so, then it woul= d 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 docume= ntation can be held in a wiki - what I'm missing (as a work item) is the in= tended deliverable. If the intent is to document current implementation ex= perience, 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/ --_000_D3730BB2129853aretanaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6EC61E9B6C04EC4EB6C717AA9A32E481@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 5/23/16, 4:01 PM, "babel on behalf of Alia Atlas" <babel-bounces@ietf.org on behalf of akatlas@gmail.com> wrote:

Hi!

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

I'm reviewing the charter for the IESG Telechat this week.  Because th= e 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 lat= est 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 "ear= lier reviews" or the "comments presented at the BABEL BoF at IETF= -95" that should be explicitly called out?  It seems to me that g= enerically mentioning what amounts to the need to address "comments&qu= ot; is not needed…again, unless there are specific items that could be h= ighlighted in the charter.

2. [nit] Maybe reorder the Work Items men= tioning first the ones that are required for advancing to PS, and later oth= ers.

3. Is the intent for the 3 main work= items (base specification, security, management) to advance together (to I= ESG 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&quo= t; a work item?  I agree that support documentation can be held in a w= iki — 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 B= abel" 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? &nbs= p;Please call them out specifically.

Thanks!

Alvaro.

--_000_D3730BB2129853aretanaciscocom_-- From nobody Tue May 31 07:02:20 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531C812D534 for ; Tue, 31 May 2016 07:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5of119UCxBi for ; Tue, 31 May 2016 07:02:14 -0700 (PDT) Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14A912D51D for ; Tue, 31 May 2016 07:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 5877B40472 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1464703328; bh=DynTxHS+MLDvjCQ2648iG7YBTWe42i4srfnljRZ6dbo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OKzOP0b879MsozLEAxFBu7oB0V7tAkdppFUmWQrmqpJC9fWKRTCJFV8igNDrKILB3 1PpQQlsX/Bane4bmADAdv4qFFY3bmIaGOYrXsccfnHbhlsnNLeo4YyY1TBp7Rlr6c/ pdpwPy5PluypzHP2miu/WV9okj9FOHdRLA7EbS/Y= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 78961C4010F; Tue, 31 May 2016 16:02:07 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: "Alvaro Retana \(aretana\)" References: Date: Tue, 31 May 2016 16:02:07 +0200 In-Reply-To: (Alvaro Retana's message of "Tue, 31 May 2016 13:48:56 +0000") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87inxucom8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:02:18 -0000 "Alvaro Retana (aretana)" 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 nobody Tue May 31 07:20:38 2016 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FDA12D7BB; Tue, 31 May 2016 07:20:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531142035.18710.56899.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 07:20:35 -0700 From: IETF Secretariat Archived-At: Subject: [babel] ID Tracker State Update Notice: X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 14:20:35 -0000 State changed to Internal review. ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-babel/ From nobody Tue May 31 21:20:44 2016 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BC212B013; Tue, 31 May 2016 21:20:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601042041.20287.22250.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 21:20:41 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Alissa Cooper's No Objection on charter-ietf-babel-00-02: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 04:20:42 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-babel-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-babel/ ---------------------------------------------------------------------- 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. From nobody Tue May 31 21:40:50 2016 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0691312D16F; Tue, 31 May 2016 21:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601044048.20248.50012.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 21:40:48 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Spencer Dawkins' No Objection on charter-ietf-babel-00-02: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 04:40:49 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-babel-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-babel/ ---------------------------------------------------------------------- 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". From nobody Tue May 31 21:41:31 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C007012D62A for ; Tue, 31 May 2016 21:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlu6US6hN7UA for ; Tue, 31 May 2016 21:41:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1960A12D16F for ; Tue, 31 May 2016 21:41:26 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u514fLpF026143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Jun 2016 06:41:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id u514fLAI010061; Wed, 1 Jun 2016 06:41:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 996A261FA7; Wed, 1 Jun 2016 06:41:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id NgMg4VDSQFJf; Wed, 1 Jun 2016 06:41:20 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1384061FA5; Wed, 1 Jun 2016 06:41:19 +0200 (CEST) Date: Wed, 01 Jun 2016 06:41:21 +0200 Message-ID: <87bn3lo70u.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Alvaro Retana (aretana)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 01 Jun 2016 06:41:21 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 01 Jun 2016 06:41:21 +0200 (CEST) X-Miltered: at korolev with ID 574E6771.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 574E6771.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 574E6771.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 574E6771.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 574E6771.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 574E6771.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 04:41:30 -0000 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 <87a8jjfk16.wl-jch@pps.univ-paris-diderot.fr> (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 nobody Tue May 31 22:21:11 2016 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ED612D988 for ; Tue, 31 May 2016 22:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADk7w4GJXbzu for ; Tue, 31 May 2016 22:21:08 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9667C12D0B5 for ; Tue, 31 May 2016 22:21:07 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u515L3Tx002592; Wed, 1 Jun 2016 07:21:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id EE64561FA5; Wed, 1 Jun 2016 07:21:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qwOpUsaHUsyC; Wed, 1 Jun 2016 07:21:01 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8A90661F9A; Wed, 1 Jun 2016 07:21:00 +0200 (CEST) Date: Wed, 01 Jun 2016 07:21:01 +0200 Message-ID: <8760tto56q.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= In-Reply-To: <87inxucom8.fsf@toke.dk> References: <87inxucom8.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 01 Jun 2016 07:21:03 +0200 (CEST) X-Miltered: at korolev with ID 574E70BF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 574E70BF.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 574E70BF.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: "Alvaro Retana \(aretana\)" , Babel at IETF , Alia Atlas Subject: Re: [babel] Draft BABEL Charter X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 05:21:09 -0000 > 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... I'd personally be more in favour of a draft, even if it doesn't get promoted. Wikia volant, scripta manent. -- Juliusz From nobody Tue May 31 22:43:25 2016 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7448712D993; Tue, 31 May 2016 22:43:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601054321.20179.85145.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 22:43:21 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Terry Manderson's No Objection on charter-ietf-babel-00-02: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 05:43:21 -0000 Terry Manderson has entered the following ballot position for charter-ietf-babel-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-babel/ ---------------------------------------------------------------------- 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?