From nobody Wed Jun 1 10:35:15 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 C3AD512B007 for ; Wed, 1 Jun 2016 10:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 AQ0RZbVmfB96 for ; Wed, 1 Jun 2016 10:35:11 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 9863D12D0AE for ; Wed, 1 Jun 2016 10:35:11 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id e62so96959282ita.1 for ; Wed, 01 Jun 2016 10:35: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; bh=jvdXJJ4/haiYWvaEEmOqzjxdRtUjMLDBV3stIh0OkqY=; b=W4s4a8pWefSarpvzdplfYa9iVjPj0cSD/YEuLJIynNA8o6Xs6HW4aOV3pycAq8wpZ6 5BR9VXtOJ3K7DPZ4k1Yydt9o8zjpWUt3eVAX9mV/GIfVCptTeGQ7TeYJY5VI0NKCeldn 9yqm43Hf7eC0D0dOAiXtrUhRyUltb4b5NGeNhhVF/zUrWcfA9CWBqQspZO0ncaZyUBYr 5MqUEzrTD1nPLbWBVAy+fxf4fFCbFmFJxgSUrPyNtpnFvSVR5epXhxGVggmwUtp/p3uL yVy1gu4frcfcFfOgR2iIA1623+2rEBop2ikMmYWXepYwWIyiTAd+okDTHhj3mKDsKe5/ lK4Q== 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=jvdXJJ4/haiYWvaEEmOqzjxdRtUjMLDBV3stIh0OkqY=; b=lRBdbtd5VvL0lbq+1soN1RVQbzKAWjBmN0kfBNDr/B6A623E46B/dk1vkOHtbzTaTm QZS6vOXq0PTQw2xqOQ9qXUancvk4EuAmVE1ilJVHfWKlNrJ5eQb+SjqfcAynPej8BpJe QIaY1sjuuiaxCwmHP0ih7zssLVzJeGZSQ/rahXt1+lgYw77hS82luRjcA2NHw3iWgL2n ecg8Ojgvfe1TgbnKhe+PHmTbPa+TOXW/5jn+cDN6AJ1VQeAY0Q+km1p5nrLmLPVT24me 0oNze8k6Ipzaon1kH7hao+B7rvOhMiGK+JWEDfyXuwRpeQyM5675whf8J1mdAZPIaRWu t0VQ== X-Gm-Message-State: ALyK8tITmAqRn792l6o5Kbi29cWC/HFG3NPCk9/tI2RzK/BHj7FHJRqSkPcH9qdynfg7BrTNvnCn5rNjJRgaew== X-Received: by 10.36.16.67 with SMTP id 64mr7071505ity.88.1464802510935; Wed, 01 Jun 2016 10:35:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.28.81 with HTTP; Wed, 1 Jun 2016 10:34:31 -0700 (PDT) In-Reply-To: References: From: Tony Przygienda Date: Wed, 1 Jun 2016 10:34:31 -0700 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=001a11445b18549b0f05343ae91e 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: Wed, 01 Jun 2016 17:35:14 -0000 --001a11445b18549b0f05343ae91e Content-Type: text/plain; charset=UTF-8 In this context I recommend the lecture of https://tools.ietf.org/html/draft-ietf-isis-auto-conf-01 which deals with lots of those issues already. As in "most sincere form of flattery" and such ;-) -- tony On Wed, May 25, 2016 at 11:05 PM, Tony Przygienda wrote: > 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 >> >> --001a11445b18549b0f05343ae91e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In this context I recommend the lecture of=C2=A0https://tools.ie= tf.org/html/draft-ietf-isis-auto-conf-01=C2=A0which deals with lots of = those issues already. As in "most sincere form of flattery" and s= uch ;-)=C2=A0

-- tony=C2=A0

On Wed, May 25, 2016 at 11:05 PM, Tony P= rzygienda <tonysietf@gmail.com> wrote:
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 =C2=A0top you always have to contend with the U= /L MAC bit=C2=A0

That was one of my original comme= nts, the unique router-ID as anchor for self-config. Well, other people fou= ght the problem so it's probably just finding the right reference. Rece= nt OSPF/ISIS work comes to mind, previous attempts @ ZEROCONF, http:= //dl.acm.org/citation.cfm?id=3D2140282.2140307=C2=A0and so on ...=C2=A0=

thanks=C2=A0

-- tony=C2= =A0


Alia proclaimed:

Righ= t - Section 3 just says that the router-id is assigned and assumed unique.= =C2=A0 MAC addresses can be tempting to use, but they aren't always as = unique as assumptions have been.=C2=A0 There's work on providing privac= y protecting 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= 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




--001a11445b18549b0f05343ae91e-- From nobody Wed Jun 1 13:12: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 23A7E12D1B4 for ; Wed, 1 Jun 2016 13:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-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 lUbfhD87BIWH for ; Wed, 1 Jun 2016 13:12:22 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E5C12D0CA for ; Wed, 1 Jun 2016 13:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2103; q=dns/txt; s=iport; t=1464811942; x=1466021542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PVxhw3NXqBibRRrnev/TWsxeoz7F3e8F5w/j8mUUDOk=; b=YduE/V3GmCq63FxlW0XRgvFuNMVFjgGqa5x7tLsNLzuANo2Ah/C4GX29 np8BiJde/pMeJbmflOPgRCyW93Uno2rafkzJjTniUq+fFW44TA3DZne3U 0uQvsHW5R3tsL4lTnG2QgIADnXzhgqBCCmp1P2fgs37nSXZK0zYPBVggg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCcQE9X/5pdJa1dgz1WfQa4B4IPA?= =?us-ascii?q?Q2BeiKFbwKBMzgUAQEBAQEBAWUnhEYBAQMBOj8QAgEIDigQMiUCBA4FiCcIDsF?= =?us-ascii?q?HAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4RNihoFhXaNQYUAAYV/hWWCO4Fpg?= =?us-ascii?q?niBV4hkj0sBHgEBQoNtbok4fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,403,1459814400"; d="scan'208";a="280629736" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2016 20:12:21 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u51KCLbt005877 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Jun 2016 20:12:21 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; Wed, 1 Jun 2016 15:12:20 -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; Wed, 1 Jun 2016 15:12:20 -0500 From: "Alvaro Retana (aretana)" To: Juliusz Chroboczek Thread-Topic: [babel] Draft BABEL Charter Thread-Index: AQHRqtY88Om/StKnZEyBVrJ7b4asLJ+93k2AgAGaVgCAAPkeAIAG6B+AgAvnioCAATxrgIAAwQmA Date: Wed, 1 Jun 2016 20:12:20 +0000 Message-ID: References: <87bn3lo70u.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87bn3lo70u.wl-jch@pps.univ-paris-diderot.fr> 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: text/plain; charset="us-ascii" Content-ID: <0409B7DAC6CD7E43AB5C71A8EDFD921F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 20:12:24 -0000 On 6/1/16, 12:41 AM, "Juliusz Chroboczek" wrote: Juliusz: Hi! >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? > >... > >> 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. My point with this comment (and #1 above) is really that I rather be specific in the charter if there is something that we want the WG to work on (or not), instead of relying on group history, or some e-mail somewhere with a list. If we can't be specific, then I don't think we should mention it in the charter. > >> 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. It is. It not only jogs the WG memory, but it may attract the attention of others as well. Note that others have made the same comment in the IESG ballot: https://datatracker.ietf.org/doc/charter-ietf-babel/ballot/ Thanks! Alvaro. From nobody Wed Jun 1 13:22:17 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 3336112D0B3; Wed, 1 Jun 2016 13:22:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601202216.16102.85813.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 13:22:16 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Alvaro Retana'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 20:22:16 -0000 Alvaro Retana 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 Charter in general is ok, but I think there are some pieces that should be clarified. 1. Are there specifics of "earlier reviews" or the "comments presented at the BABEL BoF at IETF-95" that should be explicitly called out? It seems to me that generically mentioning what amounts to the need to address "comments" is not needed or useful…again, unless there are specific items that could be highlighted in the charter. 2. [nit] Maybe reorder the Work Items mentioning first the ones that are required for advancing to PS, and later others. 3. Is the intent for the 3 main work items (base specification, security, management) to advance together (to IESG review, etc.)? If so, then it would be nice to explicitly call it out (and reflect it in the milestones). If not, then it should be, because they are explicitly mentioned as required for Babel to advance to PS. 4. How is "keep its wiki updated" a work item? I agree that support documentation can be held in a wiki — what I'm missing (as a work item) is the intended deliverable. If the intent is to document current implementation experience, then let's explicitly say so (and not just "expect" that it will happen), and set the proper publication expectations. 5. What does "multicast aspects of Babel" mean? The answer on the babel list [*] indicates a wide variety of possibilities. I would prefer it if the specifics were included in the charter; or, given that multicast is mentioned as a "secondary focus", that it be left off for re-chartering. (s/PIM/the PIM WG). 6. Besides the specific call out to pim, are there other WGs with which we might need babel to coordinate with? Please call them out specifically. [*] "Some people appear to believe that Babel works fine with PIM-SM as it stands. Some other people appear to believe that it would be a good thing for Babel to be extended to carry a set of metrics specifically for multicast. Yet other people would like to see Babel build multicast routing tables with no help from PIM." (http://www.ietf.org/mail-archive/web/babel/current/msg00289.html) From nobody Wed Jun 1 13:39:16 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 13C4012D19D; Wed, 1 Jun 2016 13:39:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160601203915.16081.7755.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 13:39:15 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Kathleen Moriarty'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 20:39:15 -0000 Kathleen Moriarty 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: ---------------------------------------------------------------------- This is really just a question and may result in updated text or not... I think by the following, you mean there will be a draft specific to security: Thus, the working group will produce a Proposed Standard Babel specification, including or paired with a suitable security specification for BABEL. Or do you mean that you will cover security requirements and considerations in each of the other drafts produced? Thanks. From nobody Wed Jun 1 18:34:47 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 DAF3512B01D; Wed, 1 Jun 2016 18:34:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2016 18:34:42 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Suresh Krishnan'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: Thu, 02 Jun 2016 01:34:43 -0000 Suresh Krishnan 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: ---------------------------------------------------------------------- * There is no mention of backward compatibility in the charter. Is the "new" Babel intended to be backward compatible with the deployed experimental version(s)? Might be worth noting either way. * One of the potential (and I personally think one of the most important) uses of Babel is as a routing protocol in homenets. Two of the things that seem to be interesting improvements to Babel for this use case seem to be a)self-configuration and b)source-specific routing. I do not see either of them in the charter. I would have really liked to see something in the charter to address these two issues. From nobody Wed Jun 1 21:14: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 3C51C12B037 for ; Wed, 1 Jun 2016 21:14: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 6JxfbCtL7Yz1 for ; Wed, 1 Jun 2016 21:14:34 -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 3EC7512D141 for ; Wed, 1 Jun 2016 21:14:34 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h19so39428652ywc.0 for ; Wed, 01 Jun 2016 21:14:34 -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=I2zitMRDcjkIqsJpkyRtZ/ri8roG4UF2S7FFmyHM+EI=; b=LZfFdJejmevA82jyrAnTZJPBuaMRYJhGOmJfcun8s7OxX098Rc/u2UwMz/603DzpoI Tl5kTmh1p2nGMX78EyzAySb+jMUZ87LSJyhKFDUbPHO725wIYxW15AuE0MYDlG+9DcEg gW2elNc8nVfGCzs05zpw0+PjD6Vd3FptxJ1cx+hAi/UfY1HhNd2v5zUBmSxz2a8KoyBt O2J30PlRZDP62jmdJsDmUVy+pgKalAx3LjSXy1Kkmb/UhJyRExIEuHru0OWLh+liVTgf ZkNfivGo4E2Yiu+MJSK63usb6NQhhRUsmuIgXedLRbXQwjrcbeGQUlycpCGLqA30MMnS 5BQw== 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=I2zitMRDcjkIqsJpkyRtZ/ri8roG4UF2S7FFmyHM+EI=; b=iicz3Bu+PdU2/reZAXoIhN614eXsmo7bP3Zw0W85LyISUkroMbjHMLTadonSrLURDa xQE1+eOHIOCWq7EtB5EjahU2VsMxKTDPqPbEAJ0wmlHlI22c7X0pSu3QWq37Hq966bmC W73CM/8d+08FT2NH5YDYeqHNZDp0SEJY7J7siT8H1ORBEsMc1CH+O76Fkhf+HTSkeg1Q 74PDVw8LUw8CBBR+hyziIMbo8FTS8YbIMJ8lu6g3dK41l9H6g93GJOrABIbFVelkyQcK rLysjIAS0dh/t/Kq1+RssY8NE6geYntTt5jUlCVHNVFAKyt1HWvh/rx7Kd9/AW7miX9x OF7A== X-Gm-Message-State: ALyK8tKxe4FyiDB4OdjSga1cNAsX5U44OkkaoRlda0zhOXyjDG/kCNM5nDYPQEwapNqJ6Va7dlgFEObAH4nX2A== MIME-Version: 1.0 X-Received: by 10.129.147.71 with SMTP id k68mr4854972ywg.76.1464840873562; Wed, 01 Jun 2016 21:14:33 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Wed, 1 Jun 2016 21:14:33 -0700 (PDT) In-Reply-To: <8760tto56q.wl-jch@pps.univ-paris-diderot.fr> References: <87inxucom8.fsf@toke.dk> <8760tto56q.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 2 Jun 2016 00:14:33 -0400 Message-ID: From: Alia Atlas To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=94eb2c07e9e8ebdd50053443d779 Archived-At: Cc: "Alvaro Retana \(aretana\)" , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , 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, 02 Jun 2016 04:14:36 -0000 --94eb2c07e9e8ebdd50053443d779 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 1, 2016 at 1:21 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > 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. > My experience is that it's really really hard to tell a WG that a WG draft isn't going to progress to an RFC. The advantage of a wiki is that more folks can add experience and it's easy to update. We could be clear in the charter that it's a draft that won't be published as an RFC, but a wiki with implementation experience that is kept up to date (while the WG is active at least) seems to me to be actually more useful. Regards, Alia --94eb2c07e9e8ebdd50053443d779 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 1, 2016 at 1:21 AM, Juliusz Chroboczek <jch@pps.univ-p= aris-diderot.fr> wrote:
> 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 contribu= te
> 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= 9;t get promoted.
Wikia volant, scripta manent.

My experi= ence is that it's really really hard to tell a WG that a WG draft isn&#= 39;t going to progress
to an RFC.

The ad= vantage of a wiki is that more folks can add experience and it's easy t= o update.=C2=A0

=C2=A0We could be clear in the cha= rter that it's a draft that won't be published as an RFC, but a wik= i
with implementation experience that is kept up to date (while t= he WG is active at least) seems
to me to be actually more useful.=

Regards,
Alia

=

--94eb2c07e9e8ebdd50053443d779-- From nobody Thu Jun 2 02:16:42 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 1A59112D671; Thu, 2 Jun 2016 02:16:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2016 02:16:41 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Benoit Claise'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: Thu, 02 Jun 2016 09:16:41 -0000 Benoit Claise 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: ---------------------------------------------------------------------- Not really a DISCUSS, but I would like to at least try to convince you if you disagree. "Address manageability of Babel by producing an informational model, for use by other network management, and a YANG module based on it, to be consistent with the ongoing effort to use YANG modules in the Routing Area. This is required as part of moving Babel to Proposed Standard." Do the WG really want to focus on an information model first, as opposed to go directly to a data model? See RFC3444. The end goal is a YANG data model, as you correctly stressed. Proposal (we used this sentence in SUPA): If the working group finds it necessary to work on an information model before the data model, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC. Also, "This is required as part of moving Babel to Proposed Standard." I want to make sure we set the right expectations for this. Babel will not move to Proposed Standard unless we publish the YANG data model at the same time. If so, I like that. You might want to make it clear, in the charter text or the milestones. Editorial: YANG module => YANG data model From nobody Thu Jun 2 02:48: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 01B4812D69E; Thu, 2 Jun 2016 02:48:23 -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 cFhUOIrdT_53; Thu, 2 Jun 2016 02:48:21 -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 96BDF12D6A2; Thu, 2 Jun 2016 02:48:17 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1464860890349818.4811923127688; Thu, 2 Jun 2016 02:48:10 -0700 (PDT) Date: Thu, 02 Jun 2016 10:48:10 +0100 From: Denis Ovsienko To: Kathleen Moriarty Message-ID: <15510835475.119eaaf5339191.8000856647775375067@ovsienko.info> In-Reply-To: <20160601203915.16081.7755.idtracker@ietfa.amsl.com> References: <20160601203915.16081.7755.idtracker@ietfa.amsl.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: Cc: babel-chairs@ietf.org, The IESG , babel@ietf.org Subject: Re: [babel] Kathleen Moriarty's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 09:48:23 -0000 >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >This is really just a question and may result in updated text or not... > >I think by the following, you mean there will be a draft specific to >security: > >Thus, the working group will produce a Proposed Standard Babel >specification, including or paired with a suitable security >specification for BABEL. > >Or do you mean that you will cover security requirements and >considerations in each of the other drafts produced? Hello. The sense it makes to me is as follows: 1. The PS must include a security mechanism. 2. The specification of the mechanism may be a standalone document or an appendix in the main document. 3. Particular form is up to WG and depends on the nature of the text that becomes a part of the PS. 4. This may have to do with RFC 7298 or some other specification. To me it seems that a good security mechanism spec would always include two parts. One would just say "To implement this spec do this and this". The other would discuss why it needs to be done and what are the options and possible side-effects and what if... Some authors find it better to include the "do this" part as an appendix of the main document and to make the "let's discuss this" part a standalone security considerations document. Others find it better to put both parts into one standalone document. RFC 6126 and RFC 7298 were produced by different authors at different time, so RFC 7298 naturally combined both those parts. The matter here is, the security considerations are always a part of the work to be done, whichever document they happen to belong. The WG may agree to: * base the work on RFC 7298 and leave it one document (makes perfect sense to me but I am biased), or * idem but put some contents into RFC 6126-bis appendix and the remaining into a new separate "considerations/applicability" document, or * proceed with a different mechanism but still have to have a normative text and a considerations text. The current revision of the charter seems to allow the flexibility for doing that. -- Denis Ovsienko From nobody Thu Jun 2 03:05: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 3E67512D132; Thu, 2 Jun 2016 03:05:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602100522.8756.16629.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2016 03:05:22 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charte?= =?utf-8?q?r-ietf-babel-00-02=3A_=28with_COMMENT=29?= 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: Thu, 02 Jun 2016 10:05:22 -0000 Mirja Kühlewind 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 agree with others that some clarifications would help; maybe also try to reduce redundancy for more clarity. But I don't have any additional comments to add. From nobody Thu Jun 2 06:06:55 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 C934812D190 for ; Thu, 2 Jun 2016 06:06:53 -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 Yah6vNq2tgH6 for ; Thu, 2 Jun 2016 06:06:52 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 5C91112D6CD for ; Thu, 2 Jun 2016 06:06:51 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id h19so49056197ywc.0 for ; Thu, 02 Jun 2016 06:06:51 -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=7JFprZt0+ZcFDo2L5vLhFMcbc+LwKCuWzsFTShqfaAs=; b=QinET79kYGKuCIu5inCZ4l/DCVhwdgrfX9cJic6red+bKmjf0Nx80T4zubV2SqJvRH SY33K9ly5FFOfKd3HJTfGamZdX4tO2MHqa8aTWEOqKRpAjrA5ihlZw/e4kfBRD/AX946 R2oZ7UXrYsp3fdKVfL5dif6qRsTz9+Lj7wnRWmEi3KE94VRk5Lq011H15NTbYB+Tvm60 AjBOmgUgHXs8E8QMWoXfRUIXnGQM67wwB/Ipek+OrWkkECAI3ZhxTGNcKdiLCr5OhwcY cM26aohVtomedCorchO34/dW+PDBQCc8fj9FnU82TBZUVodRn0BJKqL9S/ChVwZUpDoL 7yDg== 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=7JFprZt0+ZcFDo2L5vLhFMcbc+LwKCuWzsFTShqfaAs=; b=Jq2/0j/2UeIQaXHXk2tbMHbtipAD0Z0hLOgNVpDlP6EYqXJ3z9oQwXhVcp/vALc1i8 7i4f3044AuS0KYV67/4Cqgdevdj9kEpDSftp8hW+8h2zpmCifV+H9Tr3+ncJVpmeUvuz goLqj0ia9LfKZP+4y4I89yx0bKsbvwy2LO7vntW2HVOVrs6vTwLTsDl1bMr9MB21zfg0 dHtGBHZOaiemARnv2blAKHu17WfCG+qRCKqclaiGwiKY9FtdQBeKIUngmbes+mDiBEKa iuEa/cGoE3tyyZ7ELRjbn0fYigJs4BWhsSJsLpUnqr1HXZSAIwTNXv1mrsWxsTJ/a2Gt V7kA== X-Gm-Message-State: ALyK8tJ+pjI3vcPdBgquHen05Ccr2b2jWywMGGmAbreqygTzOAAAtJECQz+zZA/PoGogJw== X-Received: by 10.129.93.193 with SMTP id r184mr6164954ywb.326.1464872810644; Thu, 02 Jun 2016 06:06:50 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id i129sm226115ywd.35.2016.06.02.06.06.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jun 2016 06:06:50 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Alia Atlas'" , "'Juliusz Chroboczek'" References: <87inxucom8.fsf@toke.dk> <8760tto56q.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Date: Thu, 2 Jun 2016 09:06:49 -0400 Message-ID: <040901d1bccf$a00d66a0$e02833e0$@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: AQFYoAHWEHtoxVT8DhtHOznazgjQXwKCizlAAcZml3kCbL+UUgKGcIKeAz5LIVQB6VdrywIF7eHuAj03Hl+gMye3wA== Content-Language: en-us Archived-At: Cc: "'Alvaro Retana \(aretana\)'" , =?UTF-8?Q?'Toke_H=C3=B8iland-J=C3=B8rgensen'?= , '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, 02 Jun 2016 13:06:54 -0000 > We could be clear in the charter that it's a draft that won't be = published as an > RFC, but a wiki with implementation experience that is kept up to date = (while > the WG is active at least) seems to me to be actually more useful. It seems to me to be, as well... If, at some point in the future, we = decide to push the information in the wiki as a draft for some reason, = that can always be done... For now, I'd leave it as a wiki. :-) Russ From nobody Thu Jun 2 06:39: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 1A97F12D525; Thu, 2 Jun 2016 06:39:03 -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 qNmxlp6aSygs; Thu, 2 Jun 2016 06:39:01 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 B77C212D70A; Thu, 2 Jun 2016 06:38:46 -0700 (PDT) Received: by mail-qg0-x22c.google.com with SMTP id 52so58526420qgy.0; Thu, 02 Jun 2016 06:38:46 -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=NPkT1Q9Z4A0FLuuY5Wga7fHrr5v0AeQ+UDO0762gfNo=; b=A5NVDXe9ZKINT3xtAqMDCFfaqBqRbIntTIw8MyXsA9nizuiCt9x9uwmSSRPsqeUnfL UOmJlGC6pMPpF8Loz6AtiZ0TykE8QWND16IHsAiOGG10N6yyOPZeT5N3lnIXI+ECH1lh ehSia0ciwW4qW2hcJYVixfi+iyrlRSnBjOwbtMYt+fuZoBUO4h5BFqNVm0ufNgcREBtn uam/XUs5VmDzZe3JHxzV/s8kFhgsRXkwmOubKkFYDdR2tyUBg29uE4l57aIC9s4AH26i Q8/HflfOCa6FBcXqKgUd2Kt0h+26zWuPvRWAQ9mP/qUWs8RDram2w2XrPX5iCd93Amd0 7Egw== 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=NPkT1Q9Z4A0FLuuY5Wga7fHrr5v0AeQ+UDO0762gfNo=; b=FP85nvWRIFPsmKjB1kBA2yiPDK+t0YA7Ci6OsJeM4cNJHgT/x4dWkVQOwWzGkh4bin aD+Khk5KY0ZNHet9APmcUsM/b9fpa77p2vo6mwMK17aO5haYAUetCHS54AlXAvykDcYW /tc+NsXDzm3loxRSRo3b3GDQu7pXg5B/+9fgJdAk+ifdIGlMcP8oapH2J1gIqXZf8t8y 3KFYcXZlKjl3b6Z4BGTP+/BU3vkXYOw1eINf0hdN92ntaQa2IeqGlMRekJFDYVJIx3/i 5IDE3nvTBdW8DUtwosVp+tiDe6uzqH6DbIB14HvMC7+njTgbD/Ou1f63ax0T+fin6CpQ jNjQ== X-Gm-Message-State: ALyK8tI3OM0ktQ9+6MJDZPT6rL0Rkr+OPJDuuxVpBgSg++LLbYBeTMx/1Q6ZYpktZAP2BA== X-Received: by 10.140.195.69 with SMTP id q66mr42589400qha.79.1464874725797; Thu, 02 Jun 2016 06:38:45 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id f135sm7140860qke.37.2016.06.02.06.38.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 06:38:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (12H143) In-Reply-To: <15510835475.119eaaf5339191.8000856647775375067@ovsienko.info> Date: Thu, 2 Jun 2016 09:38:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160601203915.16081.7755.idtracker@ietfa.amsl.com> <15510835475.119eaaf5339191.8000856647775375067@ovsienko.info> To: Denis Ovsienko Archived-At: Cc: "" , The IESG , "" Subject: Re: [babel] Kathleen Moriarty's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 13:39:03 -0000 Sent from my iPhone On Jun 2, 2016, at 5:48 AM, Denis Ovsienko wrote: >> ----------------------------------------------------------------------=20= >> COMMENT:=20 >> ----------------------------------------------------------------------=20= >>=20 >> This is really just a question and may result in updated text or not...=20= >>=20 >> I think by the following, you mean there will be a draft specific to=20 >> security:=20 >>=20 >> Thus, the working group will produce a Proposed Standard Babel=20 >> specification, including or paired with a suitable security=20 >> specification for BABEL.=20 >>=20 >> Or do you mean that you will cover security requirements and=20 >> considerations in each of the other drafts produced? >=20 > Hello. >=20 > The sense it makes to me is as follows: > 1. The PS must include a security mechanism. > 2. The specification of the mechanism may be a standalone document or an a= ppendix in the main document. > 3. Particular form is up to WG and depends on the nature of the text that b= ecomes a part of the PS. > 4. This may have to do with RFC 7298 or some other specification. >=20 > To me it seems that a good security mechanism spec would always include tw= o parts. One would just say "To implement this spec do this and this". The o= ther would discuss why it needs to be done and what are the options and poss= ible side-effects and what if... Some authors find it better to include the "= do this" part as an appendix of the main document and to make the "let's dis= cuss this" part a standalone security considerations document. Others find i= t better to put both parts into one standalone document. RFC 6126 and RFC 72= 98 were produced by different authors at different time, so RFC 7298 natural= ly combined both those parts. >=20 > The matter here is, the security considerations are always a part of the w= ork to be done, whichever document they happen to belong. The WG may agree t= o: > * base the work on RFC 7298 and leave it one document (makes perfect sense= to me but I am biased), or > * idem but put some contents into RFC 6126-bis appendix and the remaining i= nto a new separate "considerations/applicability" document, or > * proceed with a different mechanism but still have to have a normative te= xt and a considerations text. >=20 > The current revision of the charter seems to allow the flexibility for doi= ng that. Ok, thanks for the clarification. It doesn't read as clearly to me, but is f= ine if the proponents and AD don't want to adjust the text. You are coverin= g security and that's what I really care about. Thanks, Kathleen=20 >=20 > --=20 > Denis Ovsienko >=20 From nobody Thu Jun 2 07:01:15 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 EFB2A12D701; Thu, 2 Jun 2016 07:01:09 -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 eWiHyIb3Nnoj; Thu, 2 Jun 2016 07:01:08 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 5297A12D1B1; Thu, 2 Jun 2016 07:01:08 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id j1so78118882oih.3; Thu, 02 Jun 2016 07:01: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 :cc; bh=2jQpXcOVdvLhr2x26nUiZ0YIirXIGC13GAX5xY3xoMI=; b=T/8abAe/kSTYx2UcH+ViTVarQFPxOby+v00zMXhrXKn+HhPfpS98/6jLJYkXgEWVia KwJ4q3tL31GDzYR6rzx67YK102JYjwTINp8LUxk2ZTJpg1UEUHvAcY3h4cKdn8vVteZa NexSioLRYe+sg1NAfx/Z88/zTxATCKB4XmbW0MnQ6/hc+2ZjQppDRjNQy66mkLbYyXok cR+8ORCZnOV6pbvYAsyIlrgsaqpCbH+ncru2Scgs2DyJP+mTY6gMC9Stj/I+lToJWg4J T61AMbXZ29+amsFHDnFP3jMGKI/EqNpJ3nMVLfqArmn9gkJGqidd9yeC+DP8hGsf40R5 0OHw== 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=2jQpXcOVdvLhr2x26nUiZ0YIirXIGC13GAX5xY3xoMI=; b=gB7qjaotbQlvGtx4FQixZd4IRO3tEH84UnNKbytJex/NdHhqMtXqLpWk7JP9cuituf A9IzduWs4eIR+sh3UMf4xmy8DqDJIgswyHt7KcpFg+6uSHDBSIKd/5Bz7kCv52gqIGA9 XRJzMNcDGgC0Q6wtA+WLBWUOcOM48voyMcD+W+d5JrESX1iEwqWl8U9nPmueMDNZjuV5 aknAxoZzJU+/9JIZ4ucUwXhcCSYEcYUTIfR8Y6fICqMU/rwJWLvhZrmeB7ZfqFXnxJD3 oK8NKwhAH7Vel2o3Do2j/BX7DRu+Qt7uQFnMB2MmwG76xki30zRXBN8irxhojoDoYOKC GSHg== X-Gm-Message-State: ALyK8tLi7zDy6Aton2PNLZ9pxje7RITGz5q0JI9gsRUyRPIDQ09pFzqCoZIw6iwRABc1BvLU5amTbqq4dtFebg== X-Received: by 10.157.36.134 with SMTP id z6mr6710849ota.124.1464876067610; Thu, 02 Jun 2016 07:01:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 2 Jun 2016 07:00:53 -0700 (PDT) In-Reply-To: <20160601042041.20287.22250.idtracker@ietfa.amsl.com> References: <20160601042041.20287.22250.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 2 Jun 2016 10:00:53 -0400 Message-ID: To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [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 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, 02 Jun 2016 14:01:10 -0000 Hi On Wed, Jun 1, 2016 at 12:20 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-babel-00-02: No Objection > > ... > > ---------------------------------------------------------------------- > 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. I agree. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Jun 2 07:06: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 ADC5112D724; Thu, 2 Jun 2016 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 U8I01ujRknya; Thu, 2 Jun 2016 07:06:26 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B0F7112D194; Thu, 2 Jun 2016 07:06:26 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u52E3s6C025583; Thu, 2 Jun 2016 10:06:25 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 23andbhkh9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 02 Jun 2016 10:06:25 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u52E6OeE006248; Thu, 2 Jun 2016 10:06:24 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u52E6IeQ006152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jun 2016 10:06:19 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 2 Jun 2016 14:06:09 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.204]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 10:06:08 -0400 From: "STARK, BARBARA H" To: Benoit Claise , The IESG Thread-Topic: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) Thread-Index: AQHRvK9/Fb+UcSAuqEyMNazMBCLod5/WJrdg Date: Thu, 2 Jun 2016 14:06:08 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> In-Reply-To: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-02_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606020165 Archived-At: Cc: "babel-chairs@ietf.org" , "babel@ietf.org" Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 14:06:32 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Not really a DISCUSS, but I would like to at least try to convince you if= you > disagree. >=20 > "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 Are= a. > This is required as part of moving Babel to Proposed Standard." >=20 > Do the WG really want to focus on an information model first, as opposed = to > go directly to a data model? > See RFC3444. The end goal is a YANG data model, as you correctly stressed= . >=20 > Proposal (we used this sentence in SUPA): > If the working group finds it necessary to work on an information model > before the data model, to help provide guidance and derive the data model= s, > it may do so. The working group will decide later whether the information > model needs to be published as an RFC. >=20 > Also, "This is required as part of moving Babel to Proposed Standard." > I want to make sure we set the right expectations for this. > Babel will not move to Proposed Standard unless we publish the YANG data > model at the same time. > If so, I like that. You might want to make it clear, in the charter text = or the > milestones. >=20 > Editorial: YANG module =3D> YANG data model As I mentioned in Buenos Aires... Since Babel is intended for more of an unmanaged home network environment, = and homenet WG intends to create a profile that hopefully will require litt= le to no management;=20 - and any management in such an environment would ideally be done through = a UI by the user;=20 - and the only managed routers that currently exist in this environment ar= e TR-069 managed routers (to the best of knowledge there are no netconf or = restconf managed routers in home networks);=20 - and there are 100s of millions of TR-069 managed routers deployed=20 -> I believe it is very important that the process allows for efficient and= simple derivation of the TR-069 data model. I accept that a YANG model is = necessary from a dogmatic perspective, in spite of the fact that no home ne= twork devices are managed at this time using netconf or restconf. But backi= ng into TR-069 from YANG is more difficult than going into TR-069 from an i= nformation model. I'm having first-hand experience in LMAP where the YANG m= odeler is constantly trying to make changes to the information model to mak= e it exactly match how he wants to do the YANG model, while ignoring the ne= eds of TR-069. I'm willing to work on the information model and to work with whoever does = the YANG data model to make sure the information model meets the needs of b= oth YANG and TR-069. I'm fine if it's in one doc. But if the info model is = just going to be derived from the YANG model, and to heck with TR-069, I'm = not so interested. I will still participate to prevent the model from being= overly bloated with all sorts of unnecessary configuration and statistics = reporting parameters. Whatever model we come up with must be very, very sim= ple.=20 Barbara From nobody Thu Jun 2 07:07: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 09ADF12D723; Thu, 2 Jun 2016 07:07:05 -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 6ekJSD3G5yiY; Thu, 2 Jun 2016 07:07:03 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 718EE12D729; Thu, 2 Jun 2016 07:07:02 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id e72so78673649oib.1; Thu, 02 Jun 2016 07:07:02 -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=Xug1bNsM0TuncrYxn9ktkMwJpcn9X7aRi5qtLe0Bqbo=; b=CNWgEo15wnPf68Rgaa7yY4NCKkI4mKW3+/pgAdCRu+OXfydLH3Jof4P6mW43TFhehW YWK1N7HAq42WXr9xblsoAyjq7NKal5MaNxoLIzhcpos8UKkx5v0SizQHhL/A7ohVDPcS oCXM0HJLxU82K8dpaOI3PjOVBcwJ+RcladEIMHiFisTJoe+nhXFpqLVO3cS5LcIu+QwS hjZBVSj6+5tAJI6Qe379WNgORvESZH6um2mvSigUW2sQEBHEB0sqmJgzkIl5zcWLSRU4 Okr19yhEtDvm+nt/zzCkDmJXjdXMQPARBmoRVVwYocmtzIWFGuAS+T8jm/WBMP0MI3KJ dbOw== 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=Xug1bNsM0TuncrYxn9ktkMwJpcn9X7aRi5qtLe0Bqbo=; b=FoorcFqmRAJ22HWRen5zsigNFgacmw01bqsopoNemiFOQovJhvClOFIY3hnnHx8jS1 xWbOzx7mnVCx4k2dzyoJVPLFHl1nEBGfG6rx8KzByG2Lphsy/b/rnj8SAn+ApZZssfeE UWjS2oBQ3b60o2trpHGNau3jDf4NRCBSfuijVvDNncNGBRFn2wkt8+1ae72TOnX/gbyw HRkwlzqLk7jwt48pNVcwjosLZSrHw23nUtLfOff3OYDedtQQdblvVPwCaEOAS7Z5/yDI OB6SWq7Jskb0UWVplKYK2nH2l0kKzzYYtW7CSJOy4jkqOsqFqT5qBazFxBhV+63VTj0g A4yg== X-Gm-Message-State: ALyK8tKv1E+nip6bzbaQFld2yg9Bx2h9KtTx7+of99sG+Yt3iaqVaKzLX7WMqLnPrP2gPGiKC5KBO7Wn5Fkrrw== X-Received: by 10.202.244.197 with SMTP id s188mr27390664oih.81.1464876421676; Thu, 02 Jun 2016 07:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 2 Jun 2016 07:06:47 -0700 (PDT) In-Reply-To: <20160601044048.20248.50012.idtracker@ietfa.amsl.com> References: <20160601044048.20248.50012.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 2 Jun 2016 10:06:47 -0400 Message-ID: To: Spencer Dawkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [babel] Spencer Dawkins' No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 14:07:05 -0000 HI, Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Wed, Jun 1, 2016 at 12:40 AM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > charter-ietf-babel-00-02: No Objection > > ... > > ---------------------------------------------------------------------- > 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". OK. The reference to PIM could just be moved down to the general reference to coordination with other WGs and any other WGs that get recommended can be added there. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Jun 2 07:12: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 3982312D721; Thu, 2 Jun 2016 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 VWiJ__J7Zv44; Thu, 2 Jun 2016 07:12:18 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 D394012D6A8; Thu, 2 Jun 2016 07:12:17 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x189so50849408ywe.3; Thu, 02 Jun 2016 07:12: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:date:message-id:subject:from:to :cc; bh=pZ0toaHiZ075IiG9xzL0fHwdQId8jF6cXBUvgznI9Kk=; b=BnRYVxdtXiEd7YNBWnpI0IYR/KPGvESpIQjuHgiu43W4M5meW7Cy3c2uSTcbsBukY/ RQShgdLNQ5kWRG//xGQO7At15YTdO0mGkzJipxd62Jeg5cFvVutNn2wKBNXKarlDaDGx TvFrKNDrqo8lEJtsuSqYs32V9WLdQKVhoexwJTEFQpjrJ80WiUYR+2/V9QE2w+y32nGE 3Dn9KQwAgmBZM7Ic3jI3YFKNwFAqedanxlMWswrMcryQ+UWvVfi92H0MDMWTlkwedw2r 0987zQ+/P1palMqZMLs0+mlQp0jXDmxl/ke0c+R/KYk/+n+DUuPDdrvH6iQgnSKxbBQu gQ7A== 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=pZ0toaHiZ075IiG9xzL0fHwdQId8jF6cXBUvgznI9Kk=; b=IP8hPWV5uTg+EktNEXxlSBXu9tDqBMoZiKQROJNH/vdIbiYIVQE6efY/UszHnqAfip oYt2c0TGSOfcMf7z7NA52oZG6k43YBHkrxFuXWxkS0yoSFOEOOT4jyCsez6iemQcx6Rs eqEaBG/TEXWoVYGko8MvdnbGcVe598Fs0z00kPJIySM7eWMKdkjgFeIOlqxup5zbQDj4 zmWeedrzJeCS60yo3RydAbsX5YDNabIi+RI3twiWpgGOSs9uWzy0/SHuawqU7pF+bxYp afyVsY858HsdJdbbqtX3c4NK+iwTsuLsK8K45QcqWwRPTtsKNAccQLb90PANXPZAOUiQ M95A== X-Gm-Message-State: ALyK8tI6bBaK1Uyo07qg0gn8tkrl9XiEdnaJvJnK8VvFJ8ptE33tTKLZ5KIulGKQ2eqrbjA4gNadlN7X4wr8TA== MIME-Version: 1.0 X-Received: by 10.129.122.212 with SMTP id v203mr5681891ywc.219.1464876737046; Thu, 02 Jun 2016 07:12:17 -0700 (PDT) Received: by 10.37.203.139 with HTTP; Thu, 2 Jun 2016 07:12:16 -0700 (PDT) In-Reply-To: References: <20160601044048.20248.50012.idtracker@ietfa.amsl.com> Date: Thu, 2 Jun 2016 09:12:16 -0500 Message-ID: From: Spencer Dawkins at IETF To: Donald Eastlake Content-Type: multipart/alternative; boundary=94eb2c0b163e8d35d205344c31d4 Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [babel] Spencer Dawkins' No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 14:12:24 -0000 --94eb2c0b163e8d35d205344c31d4 Content-Type: text/plain; charset=UTF-8 Hi, Donald, On Thu, Jun 2, 2016 at 9:06 AM, Donald Eastlake wrote: > HI, > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Wed, Jun 1, 2016 at 12:40 AM, Spencer Dawkins > wrote: > > Spencer Dawkins has entered the following ballot position for > > charter-ietf-babel-00-02: No Objection > > > > ... > > > > ---------------------------------------------------------------------- > > 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". > > OK. The reference to PIM could just be moved down to the general > reference to coordination with other WGs and any other WGs that get > recommended can be added there. WFM! > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --94eb2c0b163e8d35d205344c31d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Donald,

On Thu, Jun 2, 2016 at 9:06 AM, Donald Eastlake <d3e3e3@gmail.co= m> wrote:
HI,

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, Jun 1, 2016 at 12:40 AM, Spencer Dawkins
<spencerdawkins.ietf@gm= ail.com> wrote:
> Spencer Dawkins has entered the following ballot position for
> charter-ietf-babel-00-02: No Objection
>
> ...
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I had two thoughts. In these bullets:
>
> - 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 needed.
>
> This means "coordinated with the PIM working group", doesn&#= 39;t it?=C2=A0 Perhaps
> that would be clearer.
>
> Speaking as a past chair of a working group that wasn't great at f= iguring
> 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".

OK. The reference to PIM could just be moved down to the general
reference to coordination with other WGs and any other WGs that get
recommended can be added there.

WFM!
<= div>=C2=A0
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 =C2=A0+1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

--94eb2c0b163e8d35d205344c31d4-- From nobody Thu Jun 2 07:16: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 3962812D735; Thu, 2 Jun 2016 07:16:18 -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 8ruQ5zWMktld; Thu, 2 Jun 2016 07:16:14 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 5A91712D732; Thu, 2 Jun 2016 07:16:07 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id x189so50965478ywe.3; Thu, 02 Jun 2016 07:16:07 -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=05cGv//B39ZLVUolN2VtJ1iiFQPHbeJp/rvq4k8e/DA=; b=p3BfrYPUwmjBH6OuDYkAf8Vjn01VZP/m7IimftaZ6wEBWD7n3mnKSshnuIsMugvrlO UOtzxo3qkB9Ygj/qtF0HQl3y9r92FrbzH+HGMn0BiHPW96MByy0RAVzXb+Q5pqU3WjGJ GSDMCmPRSkySfGgLZOoajvnP8kidj12/Qiq3+ZwpzEpgy2o4K5hoGQ9Li6nty6ap4V7x m+BpVkpb3ZvpFJtudCqMYniIfINAmXCdlYfMpco00ZVXstv1oy7GMWSGksT6I+uHf1ZF yTboxlydtj2S0L7P6YsYqekm46fQxdB58bjMf0NhEXm5ettQVfH3Dl5J05IgYRnpmaGJ LWWQ== 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=05cGv//B39ZLVUolN2VtJ1iiFQPHbeJp/rvq4k8e/DA=; b=XIOhMigzaBoMNVQMZ0pgHCLszJXAOrTOC7uSDmiNDS6LW6iEX1PyuGaSml6uzmY6Kb 6A8EHi0WmF8AGMLq4S54rEmWvtk920mlOQ27g+R2W57cHTzFBy4Kq0V/6+66dHffGZKY swwKbmKwAwODKyu4WrV0mXjWBZXmJClcRBgK7LYPGCRq5nkGMTB97IU0CdtmA+07eEQw j0vGYjKUptIZpC6eHl9uKsbG4dIzU6o22pZMTEpFeYhdCl2YgSztt9Bq/TppMm8m2e9x S3wHZ9ruRWowcVGMPCpahMWWaUeSihr7c7J/JUX8uor0qqh/RM/tfBNhGErB8BCmTyES tjEQ== X-Gm-Message-State: ALyK8tJaF43gQm/o2gWcbJF0FGLqfc4YDGYF9w0vKbQ8gSTiCvjP0F2fKyAm+AUmdkE1m/9kqITLQCSiBJA0ng== MIME-Version: 1.0 X-Received: by 10.129.109.146 with SMTP id i140mr5766406ywc.220.1464876966700; Thu, 02 Jun 2016 07:16:06 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Thu, 2 Jun 2016 07:16:06 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 2 Jun 2016 10:16:06 -0400 Message-ID: From: Alia Atlas To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=001a114dba2c3d7df005344c3fb4 Archived-At: Cc: Benoit Claise , "babel-chairs@ietf.org" , The IESG , "babel@ietf.org" Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 14:16:18 -0000 --001a114dba2c3d7df005344c3fb4 Content-Type: text/plain; charset=UTF-8 Barbara's concern and point about needing TR-069 is why there's an information model instead of just the YANG data model. I don't think we will hold up the main Babel draft for completion of the YANG data model - but both need to be done as part of the process. We can add some text indicating the second expected use. Thanks, Alia On Thu, Jun 2, 2016 at 10:06 AM, STARK, BARBARA H wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Not really a DISCUSS, but I would like to at least try to convince you > if you > > disagree. > > > > "Address manageability of Babel by producing an informational model, for > > use by other network management, and a YANG module based on it, to be > > consistent with the ongoing effort to use YANG modules in the Routing > Area. > > This is required as part of moving Babel to Proposed Standard." > > > > Do the WG really want to focus on an information model first, as opposed > to > > go directly to a data model? > > See RFC3444. The end goal is a YANG data model, as you correctly > stressed. > > > > Proposal (we used this sentence in SUPA): > > If the working group finds it necessary to work on an information model > > before the data model, to help provide guidance and derive the data > models, > > it may do so. The working group will decide later whether the information > > model needs to be published as an RFC. > > > > Also, "This is required as part of moving Babel to Proposed Standard." > > I want to make sure we set the right expectations for this. > > Babel will not move to Proposed Standard unless we publish the YANG data > > model at the same time. > > If so, I like that. You might want to make it clear, in the charter text > or the > > milestones. > > > > Editorial: YANG module => YANG data model > > As I mentioned in Buenos Aires... > Since Babel is intended for more of an unmanaged home network environment, > and homenet WG intends to create a profile that hopefully will require > little to no management; > - and any management in such an environment would ideally be done through > a UI by the user; > - and the only managed routers that currently exist in this environment > are TR-069 managed routers (to the best of knowledge there are no netconf > or restconf managed routers in home networks); > - and there are 100s of millions of TR-069 managed routers deployed > > -> I believe it is very important that the process allows for efficient > and simple derivation of the TR-069 data model. I accept that a YANG model > is necessary from a dogmatic perspective, in spite of the fact that no home > network devices are managed at this time using netconf or restconf. But > backing into TR-069 from YANG is more difficult than going into TR-069 from > an information model. I'm having first-hand experience in LMAP where the > YANG modeler is constantly trying to make changes to the information model > to make it exactly match how he wants to do the YANG model, while ignoring > the needs of TR-069. > > I'm willing to work on the information model and to work with whoever does > the YANG data model to make sure the information model meets the needs of > both YANG and TR-069. I'm fine if it's in one doc. But if the info model is > just going to be derived from the YANG model, and to heck with TR-069, I'm > not so interested. I will still participate to prevent the model from being > overly bloated with all sorts of unnecessary configuration and statistics > reporting parameters. Whatever model we come up with must be very, very > simple. > Barbara > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --001a114dba2c3d7df005344c3fb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barbara's concern and point about needing TR-069 is wh= y there's an information model instead of just the YANG data model.
I don't think we will hold up the main Babel draft for = completion of the YANG data model - but both need to be done as part of the= process.

We can add some text indicating the seco= nd expected use.

Thanks,
Alia

On Thu, Jun 2, 2= 016 at 10:06 AM, STARK, BARBARA H <bs7652@att.com> wrote:
> ------------------------= ----------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------=
>
> Not really a DISCUSS, but I would like to at least try to convince you= if you
> disagree.
>
> "Address manageability of Babel by producing an informational mod= el, for
> use by other network management, and a YANG module based on it, to be<= br> > consistent with the ongoing effort to use YANG modules in the Routing = Area.
> This is required as part of moving Babel to Proposed Standard." >
> Do the WG really want to focus on an information model first, as oppos= ed to
> go directly to a data model?
> See RFC3444. The end goal is a YANG data model, as you correctly stres= sed.
>
> Proposal (we used this sentence in SUPA):
> If the working group finds it necessary to work on an information mode= l
> before the data model, to help provide guidance and derive the data mo= dels,
> it may do so. The working group will decide later whether the informat= ion
> model needs to be published as an RFC.
>
> Also, "This is required as part of moving Babel to Proposed Stand= ard."
> I want to make sure we set the right expectations for this.
> Babel will not move to Proposed Standard unless we publish the YANG da= ta
> model at the same time.
> If so, I like that. You might want to make it clear, in the charter te= xt or the
> milestones.
>
> Editorial: YANG module =3D> YANG data model

As I mentioned in Buenos Aires...
Since Babel is intended for more of an unmanaged home network environment, = and homenet WG intends to create a profile that hopefully will require litt= le to no management;
=C2=A0- and any management in such an environment would ideally be done thr= ough a UI by the user;
=C2=A0- and the only managed routers that currently exist in this environme= nt are TR-069 managed routers (to the best of knowledge there are no netcon= f or restconf managed routers in home networks);
=C2=A0- and there are 100s of millions of TR-069 managed routers deployed
-> I believe it is very important that the process allows for efficient = and simple derivation of the TR-069 data model. I accept that a YANG model = is necessary from a dogmatic perspective, in spite of the fact that no home= network devices are managed at this time using netconf or restconf. But ba= cking into TR-069 from YANG is more difficult than going into TR-069 from a= n information model. I'm having first-hand experience in LMAP where the= YANG modeler is constantly trying to make changes to the information model= to make it exactly match how he wants to do the YANG model, while ignoring= the needs of TR-069.

I'm willing to work on the information model and to work with whoever d= oes the YANG data model to make sure the information model meets the needs = of both YANG and TR-069. I'm fine if it's in one doc. But if the in= fo model is just going to be derived from the YANG model, and to heck with = TR-069, I'm not so interested. I will still participate to prevent the = model from being overly bloated with all sorts of unnecessary configuration= and statistics reporting parameters. Whatever model we come up with must b= e very, very simple.
Barbara

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

--001a114dba2c3d7df005344c3fb4-- From nobody Thu Jun 2 07:30:48 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 B7E7612D73A; Thu, 2 Jun 2016 07:30:46 -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 EVjP3bcrIQx6; Thu, 2 Jun 2016 07:30:45 -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 1AFB812D735; Thu, 2 Jun 2016 07:30:45 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id k23so79852427oih.0; Thu, 02 Jun 2016 07:30:45 -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=wDki+3PRdMPFwZZHYXbpHNEdYdQsErEiSYyldf/25cU=; b=l+Cgs/XIKCDXo2coJ7PfShip9seamJ205NxaVk2sZiTD11C6TQ6jH/7tnV8LsN70LQ fEXgwNklmWSOvZ1GlPPmUMYXyGPQYXUfLPnxbOIKbVMCLF3mXTq71izGNRwQsfDgnDLo BrwSYcDMMAB/G7b3CJeGLX+A+Lks7qxj/osNe6Ulk129zPSq6gxSivkvHWwf757naCBZ 9n4bIQXS1QYSPir3OTnp0jGQ888A1j3WTPvTxdZr0A88DAU8tIHKfQK+CcMUuk4s6R0F 3gBEz1CkL/byQVsgdlBKI7BLXLRdP48tSRKYU67JdnDOg1bJqJPBXPsbpJ2bVjpOWPu8 Qt3Q== 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=wDki+3PRdMPFwZZHYXbpHNEdYdQsErEiSYyldf/25cU=; b=BFAQ0QOBZHTmzxI78d8zBPwZNkYJf/retSAgm9f5JKW7+huCHkqU4U6eLAf6yzWUAc BcoSX6/GpMh8ueVHSgFcYKHPhbBAvjQDLSIqBq51v6e7BHi0f02gbzaO0oopOuRl4HGI p6H3K05vPtOHj0//rQ4IvJ30u3azn/IZ9aSgHIR7f6R03FVTboj0Q6ZoG47lZmttyLr7 /V7bEh4EpiBDBAc6qrofnrMNtt9+Alf32WyMQ8kEM4RTIHRqWlk9r/nvT2qsMypRTQ65 8Wf1lgSUkIPNuFsvAdlw118+7QpTMMGmNVj3mhZwhZRE3/4ZM5ejGS5fu88TDC05n1iP y4wA== X-Gm-Message-State: ALyK8tLUO0lw2nb5Zg4tmt0y8AmvqaGohxg7IFw1tR3jLiaAqgzOeZoFTNBxm6StBRNibgc7K7m7ZdsA0zrkWg== X-Received: by 10.157.36.134 with SMTP id z6mr6823921ota.124.1464877844454; Thu, 02 Jun 2016 07:30:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 2 Jun 2016 07:30:29 -0700 (PDT) In-Reply-To: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 2 Jun 2016 10:30:29 -0400 Message-ID: To: Suresh Krishnan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 14:30:47 -0000 Hi, On Wed, Jun 1, 2016 at 9:34 PM, Suresh Krishnan wrote: > Suresh Krishnan has entered the following ballot position for > charter-ietf-babel-00-02: No Objection > > ... > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * There is no mention of backward compatibility in the charter. Is the > "new" Babel intended to be backward compatible with the deployed > experimental version(s)? Might be worth noting either way. Well, it seems like all you would say is "Backwards compatibility with deployed versions of Babel is desirable but not required." That can certainly be added. > * One of the potential (and I personally think one of the most important) > uses of Babel is as a routing protocol in homenets. Two of the things > that seem to be interesting improvements to Babel for this use case seem > to be a)self-configuration and b)source-specific routing. I do not see > either of them in the charter. I would have really liked to see something > in the charter to address these two issues. HOMENET should be specifically reference as a WG with which to coordinate. Based on IESG discussion that just occurred and HOMNET requirements, auto-configuration should be added as a point. Not as clear about source-specific routing. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Jun 2 07:31: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 BCA6412D554; Thu, 2 Jun 2016 07:31:24 -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 PT6L9N9P8dSe; Thu, 2 Jun 2016 07:31:18 -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 1F0B212D72C; Thu, 2 Jun 2016 07:31:13 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id e72so79883146oib.1; Thu, 02 Jun 2016 07:31:13 -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=VDXnodGUBb55fWk+NvplSk9KtiggI3Z4gZpez1krx1E=; b=tms912/V57LzdeZ2uiRT7m+Re+P6p3qlyGPQXi9l+OYYwRf845wxNvW8uQuldcVaWH S564JJjZ0E7kP8T996/TAyNgseOTh+eDyU3HHYBx6y8Rci9MvARJiG3VzyW3kMo+nWQn MaoblUYV3HK9Ee08G1IMAghVP3FnKJcWjcrY3x+4yneff6jVCIMOd/zgtHNEhBv9wJlc DSzC/cK05Pgt9F2HG2UN+RT8E3v1HD7BxTT3Fr+RYbIVT18iyPhIEXjv1xcMH1Umr6s6 Fqatqf6CN7ZT890B2ivRDTwopuUZZGwd4xOfEmRfE40SiJ4Xm3pMeS7w8GJjDA/GvCXN dj5g== 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=VDXnodGUBb55fWk+NvplSk9KtiggI3Z4gZpez1krx1E=; b=TaFNAI4vfIlIKHbNeOSMB6+LQMDXmETV3gzkj5v9k0zDbZHnIVrX7bDU6Lf5dJ6Xc1 MEEtWqe6lwH1u++7SIHfLJNf5bQY/x6YUciVxyt3PIdDmHUmARs2ki5VxU44RJeO21Cx eDdyaL18FeMsvMUXK1A9O6jBjKQfpEfZjCH/+RJv9aP18OlW0o9GBolm3gvJGXdEtY/I V03gCurHVws9ruvYtfSJTYAr4hXDsgcIjhhbVwjAU0sYP7710YuxhKMsHgt+AX3drFWL uRBkzmgKYMTHRJR4B5RcJobZAb6ZfFsAH7s5gK+yXmA+s10F6kXJQcI6XSrKCyugatg+ XWbg== X-Gm-Message-State: ALyK8tJt4F4Fg70h5qq3snXiOCfnN+8yIzBLvptKQ6hSE4bAslbtFDvOiEJj5J+Zf0P7Ih3QOGDIUKsnyWUrFA== X-Received: by 10.202.205.23 with SMTP id d23mr27589178oig.102.1464877872506; Thu, 02 Jun 2016 07:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 2 Jun 2016 07:30:58 -0700 (PDT) In-Reply-To: <20160601054321.20179.85145.idtracker@ietfa.amsl.com> References: <20160601054321.20179.85145.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 2 Jun 2016 10:30:58 -0400 Message-ID: To: Terry Manderson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [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 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, 02 Jun 2016 14:31:25 -0000 Hi, On Wed, Jun 1, 2016 at 1:43 AM, Terry Manderson wrote: > Terry Manderson has entered the following ballot position for > charter-ietf-babel-00-02: No Objection > > ... > > ---------------------------------------------------------------------- > 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? Those seem like reasonable changes. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Jun 2 07:33: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 809F512D745; Thu, 2 Jun 2016 07:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 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, 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 6uYFkrT2bhRK; Thu, 2 Jun 2016 07:33:14 -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 D2C0112D73A; Thu, 2 Jun 2016 07:33:13 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id x189so51489644ywe.3; Thu, 02 Jun 2016 07:33:13 -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=G5Kpl1wVgeOD9FzDfkvVQ3OITf+ScWwwlnaSS8Nzwqo=; b=WXf3bZ1JlB7SOxuRmUsAaunShV7Tb/vhQPu8ZMX36P8OvtnS1q9rSHtaf/S8tZu1bw ED6tZ6SSvr3wDZxPBe9H5h+Xhu83/slK74fEqhIHzMRX1pWfsqB1FkqFlCWmC80Jhttp eZdOuMM7ZtYiKvv3Gyv7lPYBS7Fqdc8LsS1exVCM4DqqPpMnXkwX2Bv5iXPdiZ/XBzsG 1mC1AyvjnkYV0zCJYD4Pg8kOqyYfH6eyxNgltSDpF1Ck122kDfZIgr4InvcoeAutxHzR 4U79j5vZmImqNwSro0YVoDw+QjElDniKHWL2Mjeo9C/GV0fzsGfODZHEfojx7648UbzR FVmQ== 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=G5Kpl1wVgeOD9FzDfkvVQ3OITf+ScWwwlnaSS8Nzwqo=; b=BRL20COlMrT9DYTs/LpgDWrye1HFeEmaZejE/biHwPrW+AYPRTbnzNiwRBwNqccCNo UsqKq8mAemFuJWhhAHkTPAwIgOXYHLYmDXerlIii6Q8Vpvmr78d1UWhciaigZo66p1YB sn7KyKRWp3tsumvaSGtP4JQYqMBz2PKlybD9UDUu8KMcfj7ulczb63vkvsSFtd2cNY3z T4kdEJw4VSoSH2PkWdro4Gq0B2krIZYU6o2wNCG6tyetgL7HGRkAwVm2sUhxHaKRCNsz fFemcILe68uVSIT7jL3XKqhDfyr2reeP2CWVzX9zESXwEbmqkEphM5IBsv2TTYIg9iwd QgBA== X-Gm-Message-State: ALyK8tKvQrlZ23dmHZe2PdZR93YVG1mGl2CakCDSX6Tf+Z5uJgV/x9ouTkc6dlD3UPhfzgsC/Ht4fGxp3kK1/A== MIME-Version: 1.0 X-Received: by 10.37.201.71 with SMTP id z68mr5696846ybf.124.1464877992195; Thu, 02 Jun 2016 07:33:12 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Thu, 2 Jun 2016 07:33:12 -0700 (PDT) In-Reply-To: References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> Date: Thu, 2 Jun 2016 10:33:12 -0400 Message-ID: From: Alia Atlas To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a114d74f85d436205344c7cc8 Archived-At: Cc: babel-chairs@ietf.org, Suresh Krishnan , Babel at IETF , The IESG Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 14:33:15 -0000 --001a114d74f85d436205344c7cc8 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 2, 2016 at 10:30 AM, Donald Eastlake wrote: > Hi, > > On Wed, Jun 1, 2016 at 9:34 PM, Suresh Krishnan > wrote: > > Suresh Krishnan has entered the following ballot position for > > charter-ietf-babel-00-02: No Objection > > > > ... > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > * There is no mention of backward compatibility in the charter. Is the > > "new" Babel intended to be backward compatible with the deployed > > experimental version(s)? Might be worth noting either way. > > Well, it seems like all you would say is "Backwards compatibility with > deployed versions of Babel is desirable but not required." That can > certainly be added. > > > * One of the potential (and I personally think one of the most important) > > uses of Babel is as a routing protocol in homenets. Two of the things > > that seem to be interesting improvements to Babel for this use case seem > > to be a)self-configuration and b)source-specific routing. I do not see > > either of them in the charter. I would have really liked to see something > > in the charter to address these two issues. > > HOMENET should be specifically reference as a WG with which to coordinate. > > Based on IESG discussion that just occurred and HOMNET requirements, > auto-configuration should be added as a point. Not as clear about > source-specific routing. > Source-specific routing should be added as an item that the WG can do as a secondary focus - very similar to the multicast. Thanks! Alia > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --001a114d74f85d436205344c7cc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Jun 2, 2016 at 10:30 AM, Donald Eastlake <d3e3e3@gmail.com><= /span> wrote:
Hi,

On Wed, Jun 1, 2016 at 9:34 PM, Suresh Krishnan
<suresh.krishnan@ericsso= n.com> wrote:
> Suresh Krishnan has entered the following ballot position for
> charter-ietf-babel-00-02: No Objection
>
> ...
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> * There is no mention of backward compatibility in the charter. Is the=
> "new" Babel intended to be backward compatible with the depl= oyed
> experimental version(s)? Might be worth noting either way.

Well, it seems like all you would say is "Backwards compatibili= ty with
deployed versions of Babel is desirable but not required." That can certainly be added.

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

HOMENET should be specifically reference as a WG with which to coord= inate.

Based on IESG discussion that just occurred and HOMNET requirements,
auto-configuration should be added as a point. Not as clear about
source-specific routing.

Source-specifi= c routing should be added as an item that the WG can do as a secondary
focus - very similar to the multicast.

Thank= s!
Alia=C2=A0

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

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

--001a114d74f85d436205344c7cc8-- From nobody Thu Jun 2 07:56: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 A162B12D1CD; Thu, 2 Jun 2016 07:56: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 j96YmAcncYJx; Thu, 2 Jun 2016 07:56:36 -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 7F6B312D14D; Thu, 2 Jun 2016 07:56:36 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id k23so81140607oih.0; Thu, 02 Jun 2016 07:56:36 -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=xDRKbQOVC4gSpnK2IejUsT3E7g6EYGLnXlmMScJ+Ezg=; b=SnPyiFmmYpDAgAw+ayy4kN0qPy2kcnigPFOE6bDgvNJBRHtkZMkxUnPKqSjY+xP6aJ 4QkWGRDQgBPSVfogNQqCqq++gt6kBUx4qFc/byAMjC8WWn9wndJHDvIkcjFBFqVgUszz fF7UVMTAAdRB6FkGsTPoZndsjtkWvnMlUhDXoyiv4tSDCkZIPjIybqfEASXF1S0k321E dSYJumtfR7hB2chwCOdJlLCHojfVWZIBlF/r99oM4Rxq4WrZm1T5+1IazJ5HdPati8wx d8yw38tlRiSbzIOKEx5GygOSMCsekJRmzEf0/0RGDFVfGG07BH3qM54be5DZ7K8OhiMd 3NfA== 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=xDRKbQOVC4gSpnK2IejUsT3E7g6EYGLnXlmMScJ+Ezg=; b=G7EMYWPeVXEgx2vFaHVBlNLqEgLjHvAMK9UZgL/GRwcXkVT+imK61Cttstdcs0L8As MI+6gaGxdTsdBf/Rqm6r0nzUaNeYAa88bgjLYZKXeMYjN0p0qunfXQuqRL7Zs+KMtl63 SnUY7PUOyriJKtAnlftF1eLdGQUmHDBple6oYD3T9ZV8OMJ5Qo5eADyi5AOp7fjyfyNb vrqsRLwSiNvRmLcF+utWzTfPldw0rGyXK+g1U+c0CAgyioPZxPhMNHcEGQBPbOg2Q8Hg P11ntCUMkPuSh1WlBz7jN3CXtG5WPgKj3hItxrozuhxrxSYxZd3wig8I0VKpceSGnD0k +R3w== X-Gm-Message-State: ALyK8tK6owAtIHSRmBsXaqhSBw9WGWP1kyv1U9mZHy3tmm3sr+6gvAoxoAnKD0otP3hM3rRBX14RFkDi/yIDFw== X-Received: by 10.202.85.73 with SMTP id j70mr27950614oib.114.1464879395751; Thu, 02 Jun 2016 07:56:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 2 Jun 2016 07:56:21 -0700 (PDT) In-Reply-To: References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Donald Eastlake Date: Thu, 2 Jun 2016 10:56:21 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Benoit Claise , "babel-chairs@ietf.org" , "STARK, BARBARA H" , "babel@ietf.org" , The IESG Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 14:56:45 -0000 Hi, On Thu, Jun 2, 2016 at 10:16 AM, Alia Atlas wrote: > Barbara's concern and point about needing TR-069 is why there's an > information model instead of just the YANG data model. > > I don't think we will hold up the main Babel draft for completion of the > YANG data model - but both need to be done as part of the process. > > We can add some text indicating the second expected use. Adding a specific reference to the Broadband Forum TR-069 is straightforward. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thanks, > Alia > > On Thu, Jun 2, 2016 at 10:06 AM, STARK, BARBARA H wrote: >> >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > Not really a DISCUSS, but I would like to at least try to convince you >> > if you >> > disagree. >> > >> > "Address manageability of Babel by producing an informational model, for >> > use by other network management, and a YANG module based on it, to be >> > consistent with the ongoing effort to use YANG modules in the Routing >> > Area. >> > This is required as part of moving Babel to Proposed Standard." >> > >> > Do the WG really want to focus on an information model first, as opposed >> > to >> > go directly to a data model? >> > See RFC3444. The end goal is a YANG data model, as you correctly >> > stressed. >> > >> > Proposal (we used this sentence in SUPA): >> > If the working group finds it necessary to work on an information model >> > before the data model, to help provide guidance and derive the data >> > models, >> > it may do so. The working group will decide later whether the >> > information >> > model needs to be published as an RFC. >> > >> > Also, "This is required as part of moving Babel to Proposed Standard." >> > I want to make sure we set the right expectations for this. >> > Babel will not move to Proposed Standard unless we publish the YANG data >> > model at the same time. >> > If so, I like that. You might want to make it clear, in the charter text >> > or the >> > milestones. >> > >> > Editorial: YANG module => YANG data model >> >> As I mentioned in Buenos Aires... >> Since Babel is intended for more of an unmanaged home network environment, >> and homenet WG intends to create a profile that hopefully will require >> little to no management; >> - and any management in such an environment would ideally be done through >> a UI by the user; >> - and the only managed routers that currently exist in this environment >> are TR-069 managed routers (to the best of knowledge there are no netconf or >> restconf managed routers in home networks); >> - and there are 100s of millions of TR-069 managed routers deployed >> >> -> I believe it is very important that the process allows for efficient >> and simple derivation of the TR-069 data model. I accept that a YANG model >> is necessary from a dogmatic perspective, in spite of the fact that no home >> network devices are managed at this time using netconf or restconf. But >> backing into TR-069 from YANG is more difficult than going into TR-069 from >> an information model. I'm having first-hand experience in LMAP where the >> YANG modeler is constantly trying to make changes to the information model >> to make it exactly match how he wants to do the YANG model, while ignoring >> the needs of TR-069. >> >> I'm willing to work on the information model and to work with whoever does >> the YANG data model to make sure the information model meets the needs of >> both YANG and TR-069. I'm fine if it's in one doc. But if the info model is >> just going to be derived from the YANG model, and to heck with TR-069, I'm >> not so interested. I will still participate to prevent the model from being >> overly bloated with all sorts of unnecessary configuration and statistics >> reporting parameters. Whatever model we come up with must be very, very >> simple. >> Barbara >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel > > From nobody Thu Jun 2 08:03: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 B1C0C12D54D; Thu, 2 Jun 2016 08:03:23 -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 Ixjd6Gm5EAZW; Thu, 2 Jun 2016 08:03:20 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 D384A12D540; Thu, 2 Jun 2016 08:03:19 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id e72so81472984oib.1; Thu, 02 Jun 2016 08:03: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:content-transfer-encoding; bh=Lu5m3BwXSeV84lIB8aowDFeiERX8TYUWjiZizucX/kM=; b=wXfLYS7xhXxGR1og8ZMahsemOMeM239PL6zoKHwGjFCkzbg9+f2R4dRaEnAp5HzBMi /8eBnUqWuZFDUZ3zb3dYy5OOU+coyjuu136YmK8tcXZNGI/oUkxvSfWtC1ztuWbJxX21 bN8+TBnFFGKMXVUxVecUh3lDjxAAHJVpjYyrNyMylNFDCvrxv4Ne08CAL/0nCujTrCI0 5OaMN26eAkYcVIwYA9aWB6RuvP1R0crsRHENzYVOWN9pf57nzBvupcSrO07h/hkUzTAe rqA8Xp+LPF3/oGe/VmO9DhFUMbk4MC5zoOWgHAAAQ5oDnvjzZOQyCPUg4xTur4PLuGoM 6Iyg== 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:content-transfer-encoding; bh=Lu5m3BwXSeV84lIB8aowDFeiERX8TYUWjiZizucX/kM=; b=SmItIPCF79tiNZ5SwidWgsscZZzzLR1kxGUgaYUym1WpYm3acgcETO+KVY33BNN2Rm BYZyMWDSmnbuy1u6J+oO1rN0E9l6lKbgdjOqe9RQxEF3k+6KyyJBO3gNKUsfHJoyno+y wn8XOAtnz0/gCYUejCzhnjSFihsp4qRhYA84oJ13QRtFhHG8wNLOir9sswWLUJFfBcXK Z8Bl6B5+Im+Nl2FIIE/iGm1v+vNioejsOHDyYTqWRjvEyh2NNHrnjlcBO/bBM4VN3CFJ KT/JNk0aL65FjPWCq9X2fOYtDLwBTsj75neERPhhdqEBFHSP/ITIZ7sWP0i7I1CIsu4N 677w== X-Gm-Message-State: ALyK8tLmTIKs8zL+NIesLAc2QHMyyvG7AxZuFHHUGRZduNahrG4fffvUGAjR0EpzcOH0ikNMEOXUd+X+oXPF3Q== MIME-Version: 1.0 X-Received: by 10.202.86.82 with SMTP id k79mr28730850oib.105.1464879799004; Thu, 02 Jun 2016 08:03:19 -0700 (PDT) Received: by 10.202.229.210 with HTTP; Thu, 2 Jun 2016 08:03:18 -0700 (PDT) In-Reply-To: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> Date: Thu, 2 Jun 2016 08:03:18 -0700 Message-ID: From: Dave Taht To: Suresh Krishnan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: babel-chairs@ietf.org, The IESG , babel@ietf.org Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 15:03:24 -0000 On Wed, Jun 1, 2016 at 6:34 PM, Suresh Krishnan wrote: > Suresh Krishnan 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: > ---------------------------------------------------------------------- > > * There is no mention of backward compatibility in the charter. Is the > "new" Babel intended to be backward compatible with the deployed > experimental version(s)? Might be worth noting either way. I tend to think making an entirely incompatible version would be a kiss of death. On the other hand, there are a metric ton of other problems I'd like to be solving. (see below) On the gripping hand, merely getting a "rip replacement" routinely shipping and regularly available would be nice. > * One of the potential (and I personally think one of the most important) > uses of Babel is as a routing protocol in homenets. Two of the things > that seem to be interesting improvements to Babel for this use case seem > to be a)self-configuration and b)source-specific routing. I do not see > either of them in the charter. I would have really liked to see something > in the charter to address these two issues. a) self-configuration should be hardened, agreed. I saw an interesting new approach in bmx7 the other day... http://bmx6.net/news/22 ... Not entirely relevant to the formation of this wg, but stuff I wish had homes elsewhere (do they? most of my issues tend to cross layers these days): b) I'd like to see source specific routing widely available in all routing protocols. I'd even like to see an extension to RA. c) It is not just a homenet thing to want ethernet, homeplug, wifi, 5g, 6lopan, etc, interoperating well with different isps and devices. I'd like to see more interoperable interfaces to other link layers (6lowpan/threads, usb, can, 802.11ad, 5g, homeplug, etc), be they routing, failure mode detection, address assignment, security, or service advertisement. In particular, I could see usb-c one day becoming a short haul ethernet replacement if it spoke IP well and universally, and the tv becoming the network center of the home... I don't know where HDMI-ethernet went wrong... (I routinely use babel to route between wifi, ethernet, and usbnet "gadget"s today - modern hackerboards like the pi, and getchip.com etc, all have this basic support, and many hackerboards are arriving that speak usb and wifi only - and lack ethernet. ) IP over usb is way better than IP over wifi. ( side note: trying to nail down an interesting problem on usbnet/wifi here: http://blog.cerowrt.org/post/babel_half_fail/ ) > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Thu Jun 2 08:52: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 6B1C812D535; Thu, 2 Jun 2016 08:52: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 4XFoEjrqisYL; Thu, 2 Jun 2016 08:52:48 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 BB92F12D538; Thu, 2 Jun 2016 08:52:47 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id z87so75226304wmh.0; Thu, 02 Jun 2016 08:52:47 -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=vvnwUUrr3vxoiVSAPCYlkvMM/YTT8KMuOqpBE/j4Csw=; b=aqfJEsMvzjH7hWn34szD91YKWaNs8EWhhfbRHjEVmP7f7YRnPISEgX+qqUUQ4twcKG ZS8Rj0Op7wJ640l7LVIW5qfm0XuMUGt5dskV0ptWsltmoE2CahJckKTKVdGW/YFJbhWa UyMFDOx1r/OeJc9SaVWfouo3Xx324hXgt+Lvnw7jmtzL/GCtNNua8MvBv6rMnTFy98TE xTWb93E5InN9PaFFbC307gVl5tPSZxJIDKbRKDjXdKRwhdBN8RozXFFGs2btUvru9dYY +SUF1bzonXUIayxyV30DMCgXbcc//QZ//1wmfPV+qhSOTrUKW+PeSxItKM9EqVCx6z3j n52Q== 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=vvnwUUrr3vxoiVSAPCYlkvMM/YTT8KMuOqpBE/j4Csw=; b=Mdfojd920GLhYSBKhcL4qqw04MVS7m7YDNLXMnJUbHmNkW7Zq3e6ISiQ4lxlYV6RSh r5rLv2QT4VHM/FXw8RYqMjnERubP8Tpj27duefA4SJiRnL1kHJ6CdbJgFGHlR5Cdz8yV 4PUg2xMqTidNAcfCQ3sxfqB9Hbl0ZXIW9QAxC4mUogF1Kh3dC4mqInmI8Mv2UuXaep/1 xwfIUbqDK95lGStCDlXwz/O5bz3QLoF05zoeWm2rW7MyJgVptB4nifh61TmVEnbkqmHc dkNJlqRg1c0F8mkaONDRUWpJFyeQQnQOtqCxI9iP7u+Bud6L6UPOusJKqnNb1Y9dTt+W Q1CQ== X-Gm-Message-State: ALyK8tJnINJCAUnSkxKSPZ1lLKvEJi52sYgQ4yPq/cLLohlCIOLwSWe+qMUUoN9Fa71AnQ== X-Received: by 10.28.154.130 with SMTP id c124mr28457699wme.9.1464882766281; Thu, 02 Jun 2016 08:52:46 -0700 (PDT) Received: from ?IPv6:2601:647:4d00:abf0:49fb:da07:b8ec:55e2? ([2601:647:4d00:abf0:49fb:da07:b8ec:55e2]) by smtp.gmail.com with ESMTPSA id c185sm41359197wme.9.2016.06.02.08.52.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 08:52:45 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DA9D925A-5C58-4781-ABA8-EBB456DA2D24"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Bob Hinden In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 2 Jun 2016 08:52:40 -0700 Message-Id: <3910EDD1-CF03-487F-9105-55FD053DC0E0@gmail.com> References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Benoit Claise , "babel-chairs@ietf.org" , Bob Hinden , IESG , "babel@ietf.org" Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 15:52:50 -0000 --Apple-Mail=_DA9D925A-5C58-4781-ABA8-EBB456DA2D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Barbara, > On Jun 2, 2016, at 7:06 AM, STARK, BARBARA H wrote: >=20 > As I mentioned in Buenos Aires... > Since Babel is intended for more of an unmanaged home network = environment, and homenet WG intends to create a profile that hopefully = will require little to no management; > - and any management in such an environment would ideally be done = through a UI by the user; > - and the only managed routers that currently exist in this = environment are TR-069 managed routers (to the best of knowledge there = are no netconf or restconf managed routers in home networks); > - and there are 100s of millions of TR-069 managed routers deployed My understanding is that TR-069 is used by ISPs to manage routers they = deploy at the edge of the customers network, I am not sure it is = appropriate to have an ISP managing routers in a homenet (that is, = homes, small enterprises, etc.). There may be multiple ISP connections = as well. As you point out the environment where Babel appears to be very useful = is in an unmanaged homenet, so I don=E2=80=99t see the need to include a = TR-069 information model in the Babel charter. Thanks, Bob >=20 > -> I believe it is very important that the process allows for = efficient and simple derivation of the TR-069 data model. I accept that = a YANG model is necessary from a dogmatic perspective, in spite of the = fact that no home network devices are managed at this time using netconf = or restconf. But backing into TR-069 from YANG is more difficult than = going into TR-069 from an information model. I'm having first-hand = experience in LMAP where the YANG modeler is constantly trying to make = changes to the information model to make it exactly match how he wants = to do the YANG model, while ignoring the needs of TR-069. >=20 > I'm willing to work on the information model and to work with whoever = does the YANG data model to make sure the information model meets the = needs of both YANG and TR-069. I'm fine if it's in one doc. But if the = info model is just going to be derived from the YANG model, and to heck = with TR-069, I'm not so interested. I will still participate to prevent = the model from being overly bloated with all sorts of unnecessary = configuration and statistics reporting parameters. Whatever model we = come up with must be very, very simple. > Barbara >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_DA9D925A-5C58-4781-ABA8-EBB456DA2D24 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 iQEcBAEBCgAGBQJXUFZIAAoJEK7rdBF357uo0tQH/iT3qZa+fCVoDHuvNsNGntbu joaR/WfaNp/Q3BR/VliKs+4umizwqwWcm9aMyqMq5gjBIRMfhEZdsl7WGpkTyRNh 6TIZ6EUm4tQZ/xmai4ihWpNHMn53NJHDSMIOFulRXKtQWjVaKZDc8QUc9L7Llp6B Ko4T7uENjiUzRNMdHW+tRGZjLZCztGgCkvTOYMcQbnOy6aY7hqCB5AUapk8y1kvD sD9hBJd7umF36pQYbdSKxhLOMyAcBDFlWMe0Mz5OCHFzkj3uRY+RisL263Y09jS/ GfvdvgtQx6RNRDGEwDKf5hsUnmgXDpoLesn6CfPK7Midd68u4XHUZGoQ499c7QA= =as++ -----END PGP SIGNATURE----- --Apple-Mail=_DA9D925A-5C58-4781-ABA8-EBB456DA2D24-- From nobody Thu Jun 2 09:17:04 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 EA1AF12D513; Thu, 2 Jun 2016 09:16: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 3j_Fgwsepa5A; Thu, 2 Jun 2016 09:16:55 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 BEE6012D18B; Thu, 2 Jun 2016 09:16:55 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id j1so84831741oih.3; Thu, 02 Jun 2016 09:16:55 -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:content-transfer-encoding; bh=W2PN2GPu4Vn+k2OpLP5+ZCAjnYcOu/384AAYuiSSPaY=; b=CXQ7bpxhaAVvs5yrQ8dwhEvWyeKSyUnb2EJzsjgK6IVKW3MAR8GgWQtgjKEaD5QcQB GXVkfAGXciKFxdVdNCaUyck3dNg5rjOR3/gBTg4kEMn61gGYeO658MHMrO1H5uV6jFov ZkQMQo9UB3HBazndLT6HEZ6PkH86oxzdKSMLqNTv3XmUF5e6JO4JuDNbQAD0zGr0FyYb 6mHWOEtHjzy2hbHqj/qA3wO7VVsqSm5Cnt7BZ858r9dfVOgt3jIoy4WFV2ocdm7V0OC3 BHGSE6jP3lk9S+B0XF+CT6oAmv6lw8Ua/0Qs/3UX8QNLsfXFk4mI88ptf6J4K/XlJHR+ qPog== 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:content-transfer-encoding; bh=W2PN2GPu4Vn+k2OpLP5+ZCAjnYcOu/384AAYuiSSPaY=; b=R4nAedR2ij5ufXXj/4EdtHvA8en7uyXGw4Acms62v4UJNBii/+cnlIs/apMgn7eT8i wwU1ZrP4Yg80uzrH9jSIFVjw26uBRYUdJxD8AE3oO3dXjKCSMSXKDJa6STcEOJDZW5K3 WTEzeRp90WeZzXV+/ba9jI23R6KJ/neCuSiQRmECrA+KyO/zUKlxPWic3g71ZWQc+zcx 8jqX600o27bQvUxJUUMyEIPFn0pWHr2lGfeoyfqU1oJrVs2pIZ08jJIWHou4odKCjV4D KAvBy+Rf5J/tIkeJlshkqqs7lVXtSya0c0nuOaa3Ug0haYXUPyfb9TYZhuwu38KgA9qP gerg== X-Gm-Message-State: ALyK8tK6bOF3l2cwKhLXAZUtwl4kGD1XGzui6J6KLCiEVjoxu2xh5keikPpScHsWHQS9ekSvIr6i/EVmz7VLnQ== X-Received: by 10.202.65.133 with SMTP id o127mr28159588oia.43.1464884214883; Thu, 02 Jun 2016 09:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 2 Jun 2016 09:16:38 -0700 (PDT) In-Reply-To: <20160601202216.16102.85813.idtracker@ietfa.amsl.com> References: <20160601202216.16102.85813.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 2 Jun 2016 12:16:38 -0400 Message-ID: To: Alvaro Retana Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [babel] Alvaro Retana's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 16:16:58 -0000 Hi, On Wed, Jun 1, 2016 at 4:22 PM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > charter-ietf-babel-00-02: No Objection > > ... > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The Charter in general is ok, but I think there are some pieces that > should be clarified. > > 1. Are there specifics of "earlier reviews" or the "comments presented > at the BABEL BoF at IETF-95" that should be explicitly called out? It > seems to me that generically mentioning what amounts to the need to > address "comments" is not needed or useful=E2=80=A6again, unless there ar= e > specific items that could be highlighted in the charter. I'm OK with deleting almost all of that verbiage. > 2. [nit] Maybe reorder the Work Items mentioning first the ones that are > required for advancing to PS, and later others. There seem be several incompatible requests for re-ordering the work items. I don't think it makes that much difference. > 3. Is the intent for the 3 main work items (base specification, security, > management) to advance together (to IESG review, etc.)? If so, then it > would be nice to explicitly call it out (and reflect it in the > milestones). If not, then it should be, because they are explicitly > mentioned as required for Babel to advance to PS. > > 4. How is "keep its wiki updated" a work item? I agree that support > documentation can be held in a wiki =E2=80=94 what I'm missing (as a work= item) > is the intended deliverable. If the intent is to document current > implementation experience, then let's explicitly say so (and not just > "expect" that it will happen), and set the proper publication > expectations. > > 5. What does "multicast aspects of Babel" mean? The answer on the babel > list [*] indicates a wide variety of possibilities. I would prefer it if > the specifics were included in the charter; or, given that multicast is > mentioned as a "secondary focus", that it be left off for re-chartering. > (s/PIM/the PIM WG). I defer to Alia on responding to the above three points. > 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. HOMENET should be added. 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > [*] "Some people appear to believe that Babel works fine with PIM-SM as > it stands. Some other people appear to believe that it would be a good > thing for Babel to be extended to carry a set of metrics specifically for > multicast. Yet other people would like to see Babel build multicast > routing tables with no help from PIM." > (http://www.ietf.org/mail-archive/web/babel/current/msg00289.html) From nobody Thu Jun 2 09:17: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 EE2A912D543; Thu, 2 Jun 2016 09:17:00 -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 EOpaxSX2bfQ5; Thu, 2 Jun 2016 09:16:59 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 1A58B12D513; Thu, 2 Jun 2016 09:16:59 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id e72so85103567oib.1; Thu, 02 Jun 2016 09:16:59 -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=mzNrxRUHmWSU6t+5CnS31gzaUNfk13kz058jgxerL9k=; b=p6C4qnJfXUsJDx+Oo5HW9JZH/yfjW7zAIrw3Pilv4nI7qnFt9gHH6DTd3Oa410srit IqkjMYPHWzI/nmyjEjD2tyBbcX2AiPykniYvLFGzAdEbeu87bbyRn1A6V/G03+SHao0+ AAvVrtbYJ76/ErkLRgh+ZD5mPMk9HaelAogJnC+yPWNyC0GPXf33l+AL9b1CRCXW0yV1 //zXnI5ae7oRPGB/EQjpY6hi/auwW/53wdNSDUuy08jmY9C9neiql52bE6ASfdHpNdrd 0shPUWTgxdRIJWr2yEwU/7mZXpEwSdUgACvv4RMOhGQBBiPDhNwdyGousRlGXmvFRF4u GqjA== 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=mzNrxRUHmWSU6t+5CnS31gzaUNfk13kz058jgxerL9k=; b=lb+V/ujzpC0ridApbEtW5xMGDH7aOXsPfYOkZOmGcCRJLK7UzO2RPDh+g6nVy3NHuL TeVS+N+F7kbw+RBDZowuGFngDIx3falE70xWVfBE2gM50+i5w08wzmwqbEnWyJsLiqcc 64yJxBQQhHottDy/hCSykcGmuVIpU+urZipx13rp9dXgsr6pvYOXGz9xMGe5FrlI7SP7 l1M9o+HcisaJ1A7KrMTryH1b8gSTMvnOlFtjx2siVj7zUWmQ2c320oKSxcF8CEwDmlCc 73M62qqqoXkZbzxpbiF/1kw+GIUsAGAPy4WjphirUNW7UvZUKOcTCowT7avDR0u8uhRr QyFA== X-Gm-Message-State: ALyK8tIEVcXavvqi01Fa60t2ChX7brFqh7EnpETI+vBAelHAXA/0e34THskBoDcPOxFntdN6bmoJD7BySeNO4A== X-Received: by 10.157.47.248 with SMTP id b53mr7370172otd.102.1464884218545; Thu, 02 Jun 2016 09:16:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.249 with HTTP; Thu, 2 Jun 2016 09:16:43 -0700 (PDT) From: Donald Eastlake Date: Thu, 2 Jun 2016 12:16:43 -0400 Message-ID: To: Babel at IETF , Alia Atlas , babel-chairs@ietf.org Content-Type: multipart/mixed; boundary=001a113a83767bdb0905344def99 Archived-At: Subject: [babel] Revised 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, 02 Jun 2016 16:17:01 -0000 --001a113a83767bdb0905344def99 Content-Type: text/plain; charset=UTF-8 Hi, Attached is a revision of the Babel Charter which I believe responds to all the IESG comments except some by Alvaro Retana. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a113a83767bdb0905344def99 Content-Type: text/plain; charset=US-ASCII; name="BabelCharter-dee3-06.txt" Content-Disposition: attachment; filename="BabelCharter-dee3-06.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ioyi7q380 Q2hhcnRlciBmb3IgV29ya2luZyBHcm91cAoKQmFiZWwgaXMgYSBsb29wLWF2b2lkaW5nLCBkaXN0 YW5jZSB2ZWN0b3Igcm91dGluZyBwcm90b2NvbCB3aXRoIGdvb2QKcHJvdmlzaW9ucyBmb3IgZHlu YW1pY2FsbHkgY29tcHV0ZWQgbGluayBtZXRyaWNzLiBJdCBpcyByb2J1c3QgZXZlbiBpbgp0aGUg cHJlc2VuY2Ugb2YgbGluayBtZXRyaWMgb3NjaWxsYXRpb25zIGFuZCB0aGUgZmFpbHVyZSBvZgp0 cmFuc2l0aXZpdHkuIFRoZSBjb3JlIG9mIHRoZSBCYWJlbCBwcm90b2NvbCBhbmQgc2VjdXJpdHkg ZXh0ZW5zaW9ucwphcmUgZGVzY3JpYmVkIGluIEV4cGVyaW1lbnRhbCBJbmRlcGVuZGVudCBTdHJl YW0gUkZDcyA2MTI2LCA3NTU3LCBhbmQKNzI5OC4KClRoZXNlIFJGQ3MgYXJlIHRoZSBiYXNpcyBv ZiB0aHJlZSBpbmRlcGVuZGVudCwgb3BlbiBzb3VyY2UKaW1wbGVtZW50YXRpb25zLiBUaGVyZSBp cyBzb21lIHByb2R1Y3Rpb24gZGVwbG95bWVudCBvZiB0aGVzZQppbXBsZW1lbnRhdGlvbnMsIG5v dGFibHkgaW4gaHlicmlkIG5ldHdvcmtzIChuZXR3b3JrcyB0aGF0IGluY2x1ZGUKY2xhc3NpY2Fs LCB3aXJlZCBwYXJ0cyB3aXRoIG1lc2h5IHJhZGlvIGJpdHMpIGFuZCBpbiBnbG9iYWwgb3Zlcmxh eQpuZXR3b3JrcyAobmV0d29ya3MgYnVpbHQgb3V0IG9mIGxhcmdlIG51bWJlcnMgb2YgdHVubmVs cyBzcGFubmluZwpjb250aW5lbnRzKS4KClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24g bW92aW5nIHRoZSBCYWJlbCBwcm90b2NvbCB0byBJRVRGClByb3Bvc2VkIFN0YW5kYXJkIHdpdGgg SUVURiByZXZpZXcuIFRoaXMgaW5jbHVkZXMgY2xhcmlmeWluZyBSRkMgNjEyNgphbmQgaW50ZWdy YXRpbmcgUkZDIDc1NTcgYW5kIGZlZWRiYWNrIHByb3ZpZGVkIGJ5IGluZGVwZW5kZW50CmltcGxl bWVudGF0aW9ucywgYW5kIHJlc29sdmluZyBjb21tZW50cy4gT3RoZXIgZG9jdW1lbnRzIHRoYXQg YXJlCnJlbGV2YW50IHRvIHN1Y2ggY29uc2lkZXJhdGlvbiBjYW4gYWxzbyBiZSBwcm9kdWNlZC4g UGFydGljdWxhcgplbXBoYXNpcyB3aWxsIGJlIHBsYWNlZCBvbiB3b3JrIG5lZWRlZCBmb3IgYSBQ cm9wb3NlZCBTdGFuZGFyZCByb3V0aW5nCnByb3RvY29sLCBzdWNoIGFzIGVuc3VyaW5nIG1hbmFn ZWFiaWxpdHkgYW5kIHN0cm9uZyBzZWN1cml0eS4gTGluawptZXRyaWMgbWVhc3VyZW1lbnQgb3Ig bGluayBtZXRyaWMgY2FsY3VsYXRpb24gcHJvY2VkdXJlcyBzaWduaWZpY2FudGx5Cm1vcmUgY29t cGxleCB0aGF0IHRob3NlIGN1cnJlbnRseSBpbiBCYWJlbCBhcmUgb3V0IG9mIHNjb3BlLgoKV29y ayBJdGVtczoKCi0gUHJvZHVjZSBhIHJldmlzaW9uIG9mIFJGQyA2MTI2IHN1aXRhYmxlIGZvciBw dWJsaWNhdGlvbiBhcyBhClByb3Bvc2VkIFN0YW5kYXJkCi0tIGluY29ycG9yYXRlIGluIHRoZSBy ZXZpc2lvbiBkZXZlbG9wbWVudHMgc2luY2UgUkZDIDYxMjYKLS0gcmVzb2x2ZSB0ZWNobmljYWwg aXNzdWVzIGZvdW5kCi0tIGluY2x1ZGUgaW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiB0aGUgZXh0 ZW5zaWJpbGl0eSB3b3JrIGluClJGQyA3NTU3Ci0tIHN1cHBvcnQgYXV0by1jb25maWd1cmF0aW9u Ci0tIGNvbnNpZGVyIGFueSBpbXBvcnRhbnQgY2hhbmdlcyBiYXNlZCBvbiBleHBlcmllbmNlIHdp dGggQmFiZWwgdG8KZGF0ZS4KCi0gQWRkcmVzcyBzZWN1cml0eSBuZWVkcyBmb3IgQkFCRUwuIFRo aXMgbWF5IGluY2x1ZGUgdXNpbmcgdGhlCnRlY2huaXF1ZXMgaW4gUkZDIDcyOTgsIG9yIG90aGVy IGFsdGVybmF0aXZlcy4gU2VjdXJpdHkgbWF5IGJlCmluY2x1ZGVkIGluIHRoZSBiYXNlIHNwZWMg b3IgdGhlIGJhc2Ugc3BlYyBtYXkgbm9ybWF0aXZlbHkgcmVmZXJlbmNlIGEKc2VwYXJhdGUgUHJv cG9zZWQgU3RhbmRhcmQgc3BlY2lmaWNhdGlvbi4gVGhpcyBpcyByZXF1aXJlZCBhcyBwYXJ0IG9m Cm1vdmluZyBCYWJlbCB0byBQcm9wb3NlZCBTdGFuZGFyZC4KCi0gQXMgdGhlIFByb3Bvc2VkIFN0 YW5kYXJkIHZlcnNpb24gb2YgQmFiZWwgaXMgY29tcGxldGVkLCBhbgpBcHBsaWNhYmlsaXR5IFN0 YXRlbWVudCBzaG91bGQgYmUgZmluYWxpemVkIHRvIGd1aWRlIHRob3NlIHBvdGVudGlhbGx5Cmlu dGVyZXN0ZWQgaW4gZGVwbG95aW5nIEJhYmVsLiBUaGlzIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50 IG1heQppbmNsdWRlIGRlcGxveW1lbnQgYWR2aWNlIGFuZCB3aWxsIGJlIHB1Ymxpc2hlZCBhcyBh biBSRkMuCgotIEFkZHJlc3MgbWFuYWdlYWJpbGl0eSBvZiBCYWJlbCBieSBwcm9kdWNpbmcgYW4g aW5mb3JtYXRpb25hbCBtb2RlbApmb3IgdXNlIGJ5IG90aGVyIG5ldHdvcmsgbWFuYWdlbWVudCBz dWNoIGFzIHRoZSBCcm9hZGJhbmQgRm9ydW0KVFItMDY5LCBhbmQgYSBZQU5HIGRhdGEgbW9kdWxl IGJhc2VkIG9uIHRoYXQgaW5mb3JtYXRpb24gbW9kZWwuIFRoaXMKWUFORyBkYXRhIG1vZHVsZSB0 byBiZSBjb25zaXN0ZW50IHdpdGggdGhlIG9uZ29pbmcgZWZmb3J0IHRvIHVzZSBZQU5HCmRhdGEg bW9kdWxlcyBpbiB0aGUgUm91dGluZyBBcmVhLiBUaGlzIGlzIHJlcXVpcmVkIGFzIHBhcnQgb2Yg bW92aW5nCkJhYmVsIHRvIFByb3Bvc2VkIFN0YW5kYXJkLgoKLSBDb29yZGluYXRlIHdpdGggb3Ro ZXIgd29ya2luZyBncm91cHMsIHN1Y2ggYXMgdGhlIEhPTUVORVQgYW5kIHRoZQpQSU0gV0dzLCBh cyBuZWVkZWQuCgotIFRoZSB3b3JraW5nIGdyb3VwIGlzIGVuY291cmFnZWQgdG8ga2VlcCBpdHMg d2lraSB1cGRhdGVkIHdpdGgKaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB3aXRoIEJhYmVsIHNv IHRoYXQgbmV3IFdHIHBhcnRpY2lwYW50cyBjYW4KdW5kZXJzdGFuZCB0aGUgc3RhdGUgdGhhdCBp cyBkcml2aW5nIHRoaXMgd29yayBhbmQgdGhlIGV4cGVyaWVuY2UKZHJpdmluZyBjaGFuZ2VzLgoK LSBBcyBhIHNlY29uZGFyeSBmb2N1cywgdGhlIHdvcmtpbmcgZ3JvdXAgbWF5IHdvcmsgb24gbXVs dGljYXN0CmFzcGVjdHMgb2YgQmFiZWwgYW5kL29yIHNvdXJjZSBzcGVjaWZpYyByb3V0aW5nLgoK VGh1cywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm9kdWNlIGEgUHJvcG9zZWQgU3RhbmRhcmQg QmFiZWwKc3BlY2lmaWNhdGlvbiwgaW5jbHVkaW5nIG9yIHBhaXJlZCB3aXRoIGEgc3VpdGFibGUg c2VjdXJpdHkKc3BlY2lmaWNhdGlvbiBmb3IgQkFCRUwuIEl0IHdpbGwgYWxzbyBwcm9kdWNlIGEg bWFuYWdlbWVudCBtb2RlbCBmb3IKQkFCRUwgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMuIEFu IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHdpbGwgYmUKcHJvZHVjZWQgYXMgYW4gSW5mb3JtYXRp b25hbCBSRkMuIElmIG11bHRpY2FzdCBhc3BlY3RzIGFyZSBwdXJzdWVkLAp3aXRoIEFEIGFuZCBX RyBhZ3JlZW1lbnQsIHRoZW4gYSBtaWxlc3RvbmUgbWF5IGJlIGFkZGVkIGZvciBhbgphc3NvY2lh dGVkIGRvY3VtZW50IHRhcmdldGVkIGFzIFByb3Bvc2VkIFN0YW5kYXJkLgoKCgpNaWxlc3RvbmVz CgpEYXRlICAgICAgICAgICAgTWlsZXN0b25lCkF1ZyAyMDE3CVN1Ym1pc3Npb24gb2YgQmFiZWwg QXBwbGljYWJpbGl0eSBkcmFmdCB0byB0aGUgSUVTRyBhcyBJbmZvcm1hdGlvbmFsCkp1bCAyMDE3 CVN1Ym1pc3Npb24gb2YgQmFiZWwgbWFuYWdlbWVudCBkcmFmdCB0byBJRVNHIGFzIFByb3Bvc2Vk IFN0YW5kYXJkCk1heSAyMDE3CVN1Ym1pc3Npb24gb2YgcmZjNjEyNmJpcyBkcmFmdCB0byBJRVNH IGFzIFByb3Bvc2VkIFN0YW5kYXJkCk9jdCAyMDE2CVdHIGFkb3B0aW9uIG9mIEJhYmVsIG1hbmFn ZW1lbnQgKFlhbmcgLyBEYXRhIE1vZGVsKSBkcmFmdC4KSnVsIDIwMTYJV0cgYWRvcHRpb24gb2Yg cmZjNjEyNmJpcyBkcmFmdApKdWwgMjAxNglXRyBhZG9wdGlvbiBvZiBCYWJlbCBBcHBsaWNhYmls aXR5IGRyYWZ0IAogICAgICAgICAgICAgICAgZHJhZnQtY2hyb2JvY3play1iYWJlbC1hcHBsaWNh YmlsaXR5Cg== --001a113a83767bdb0905344def99-- From nobody Thu Jun 2 09:31: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 9AEDA12D513; Thu, 2 Jun 2016 09:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 XFwroBN6CD0i; Thu, 2 Jun 2016 09:31:31 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D044A12D105; Thu, 2 Jun 2016 09:31:30 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 4D98D1294; Thu, 2 Jun 2016 12:31:29 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 02 Jun 2016 12:31:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=htdNk0z3aN3QjfF n0wbj9Gj4bk8=; b=gXgHPNtMJ9KxzLYSC3Veit+BmOi16WZSXaPltHCgH7b+x48 KJZFljmu8V49FurUyKh8PXH8Cu6WYinzaYr4e8C79sJ4nbMWIZGpItYpbyWSj3An 9K0mNAgtX7uLq9pQUSqPeZqljRnYY+hbcwr8rZm721SxXg8fngrkValxNs/o= X-Sasl-enc: gbxZbuu7u8O2VNnuF12ruEujkV1iyVptjBBpxaKcei8c 1464885088 Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net [108.78.210.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 71124CCD2E; Thu, 2 Jun 2016 12:31:28 -0400 (EDT) From: "Russ White" To: "'Donald Eastlake'" , "'Alvaro Retana'" References: <20160601202216.16102.85813.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 2 Jun 2016 12:31:27 -0400 Message-ID: <06d801d1bcec$36566370$a3032a50$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMNYeD48Phmi7teyiCIVsGyh2iHnwHiUSM4nVAAxYA= Content-Language: en-us Archived-At: Cc: babel-chairs@ietf.org, 'The IESG' , 'Babel at IETF' Subject: Re: [babel] Alvaro Retana's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 16:31:32 -0000 > > 1. Are there specifics of "earlier reviews" or the "comments > > presented at the BABEL BoF at IETF-95" that should be explicitly > > called out? It seems to me that generically mentioning what amounts > > to the need to address "comments" is not needed or = useful=E2=80=A6again, > > unless there are specific items that could be highlighted in the = charter. >=20 > I'm OK with deleting almost all of that verbiage. Maybe we need to open an issue tracker and ask folks to put their = comments there, so we can have a more specific charter item (?). > > 2. [nit] Maybe reorder the Work Items mentioning first the ones that > > are required for advancing to PS, and later others. >=20 > There seem be several incompatible requests for re-ordering the work > items. I don't think it makes that much difference. Agreed. > > 3. Is the intent for the 3 main work items (base specification, > > security, > > management) to advance together (to IESG review, etc.)? If so, then > > it would be nice to explicitly call it out (and reflect it in the > > milestones). If not, then it should be, because they are explicitly > > mentioned as required for Babel to advance to PS. I think it would be better to do this, but I think we should probably = ask the WG... ??=20 > > 4. How is "keep its wiki updated" a work item? I agree that support > > documentation can be held in a wiki =E2=80=94 what I'm missing (as a = work > > item) is the intended deliverable. If the intent is to document > > current implementation experience, then let's explicitly say so (and > > not just "expect" that it will happen), and set the proper = publication > > expectations. I'm not certain we should include this in the charter as a work item -- = rather, maybe we should just mention the existence of the wiki as a = reference point, and then regularly encourage folks on the list to keep = the wiki updated... ?? > > 5. What does "multicast aspects of Babel" mean? The answer on the = babel > > list [*] indicates a wide variety of possibilities. I would prefer = it > > if the specifics were included in the charter; or, given that > > multicast is mentioned as a "secondary focus", that it be left off = for re- > chartering. > > (s/PIM/the PIM WG). I think it's probably better to leave it off for a future recharter, = when folks have a better change to look at these problems specifically = and come up with more defined action plan. :-) Russ From nobody Thu Jun 2 10:17:34 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 0C62712D78B; Thu, 2 Jun 2016 10:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-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 dRShUJxyYuS0; Thu, 2 Jun 2016 10:17:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E074B12D788; Thu, 2 Jun 2016 10:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1030; q=dns/txt; s=iport; t=1464887849; x=1466097449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IjBBK/3ldBT7sPVWQhDm1L12MHcJlb27tXZHwyLfi7Q=; b=euqGoGxiDQmWmUORvmETBNBXujR5SXaj0kBGOP3PBHL01BPbucNRyIC7 ASH8jRcL21JQ/qIG9Xxaoz2u8T7BtNuezjg6AxZ0m/MJu40mn/fI076Iw RxjVzrc1lkkfhiEpiY1h9O24iMiBI1tztdwP4o8O69wo5dYQjS3vsysIr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQCnaVBX/4QNJK1egzqBUwa4HYIPg?= =?us-ascii?q?XmGEgKBMDgUAQEBAQEBAWUnhEYBAQMBOj8QAgEINhAyJQIEAQ0FiCcIwloBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBHoYnhE2KGgEEkzeFAAGOH48cj0sBHjaDbm6JfX8BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.26,407,1459814400"; d="scan'208";a="280267112" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2016 17:17:28 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u52HHSfH026030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Jun 2016 17:17:28 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 2 Jun 2016 12:17:27 -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; Thu, 2 Jun 2016 12:17:27 -0500 From: "Alvaro Retana (aretana)" To: Russ White , "'Donald Eastlake'" Thread-Topic: Alvaro Retana's No Objection on charter-ietf-babel-00-02: (with COMMENT) Thread-Index: AQHRvOovsUhBEAaP4Ey7hSgvA+ial5/WsmiA///JxAA= Date: Thu, 2 Jun 2016 17:17:27 +0000 Message-ID: References: <20160601202216.16102.85813.idtracker@ietfa.amsl.com> <06d801d1bcec$36566370$a3032a50$@riw.us> In-Reply-To: <06d801d1bcec$36566370$a3032a50$@riw.us> 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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "babel-chairs@ietf.org" , 'The IESG' , 'Babel at IETF' Subject: Re: [babel] Alvaro Retana's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 17:17:33 -0000 On 6/2/16, 12:31 PM, "Russ White" wrote: Hi! ... >> > 2. [nit] Maybe reorder the Work Items mentioning first the ones that >> > are required for advancing to PS, and later others. >>=20 >> There seem be several incompatible requests for re-ordering the work >> items. I don't think it makes that much difference. > >Agreed. That's fine with me too. The main point about this is the one below anyway: >> > 3. Is the intent for the 3 main work items (base specification, >> > security, >> > management) to advance together (to IESG review, etc.)? If so, then >> > it would be nice to explicitly call it out (and reflect it in the >> > milestones). If not, then it should be, because they are explicitly >> > mentioned as required for Babel to advance to PS. > >I think it would be better to do this, but I think we should probably ask >the WG... ?? Right now the charter gates the publication, which works for me; security and management I think are a MUST. Thanks! Alvaro. From nobody Thu Jun 2 11:14: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 7F5EC12D7B7 for ; Thu, 2 Jun 2016 11:14:33 -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 nIvRbjQUR9Tf for ; Thu, 2 Jun 2016 11:14:31 -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 25E3112D7BE for ; Thu, 2 Jun 2016 11:14:28 -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 u52IEPxo017739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jun 2016 20:14: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 u52IEPdH004521; Thu, 2 Jun 2016 20:14: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 AAED361FA7; Thu, 2 Jun 2016 20:14: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 Ve2Ip1xmldgl; Thu, 2 Jun 2016 20:14:24 +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 F2A6D61F9A; Thu, 2 Jun 2016 20:14:23 +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 1b8X8R-0002e9-N6; Thu, 02 Jun 2016 20:14:23 +0200 Date: Thu, 02 Jun 2016 20:14:23 +0200 Message-ID: <7ivb1rv4ow.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Tony Przygienda 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]); Thu, 02 Jun 2016 20:14:25 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 02 Jun 2016 20:14:25 +0200 (CEST) X-Miltered: at korolev with ID 57507781.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57507781.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57507781.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57507781.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 : 57507781.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57507781.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] 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, 02 Jun 2016 18:14:35 -0000 Hi Tony, > In this context I recommend the lecture of > https://tools.ietf.org/html/draft-ietf-isis-auto-conf-01 which deals with > lots of those issues already. Tony, please recall the Tao of Babel: we prefer to ensure that the protocol is naturally robust against a kind of pathology rather than defining ad-hoc mechanisms to detect the pathology. Babel is reasonably safe against router-id duplication: if a router-id is duplicated, everything will still work, you'll just get slightly worse behaviour in the presence of route failures (lower route diversity). Suppose that routers A and B have the same router-id. A announces prefixes P and Q, while B announces prefixes Q and R: P --- A / . / . Q -+ ..... C \ . \ . R --- B Then C will correctly route to P through A and R through B. It will also correctly route prefix Q through exactly one of A and B -- however, the feasibility condition will prevent it from routing through the alternate route until the prefix expires from the feasibility table. In other words, you get no catastrophic failures until the chosen router crashes, and then all you get is a spurious blackhole for a few minutes. For this reason, I'd argue that Babel needs a mandatory mechanism for detecting router-id duplication. Of course, this should not prevent a management tool from detecting duplicate ids, and ringing an alarm when it does. Regards, -- Juliusz From nobody Thu Jun 2 11:26: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 0A60412D09A; Thu, 2 Jun 2016 11:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 9-ktJsiENwTO; Thu, 2 Jun 2016 11:26:14 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 8AF9D12B01E; Thu, 2 Jun 2016 11:26:14 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u52GNvJm022892; Thu, 2 Jun 2016 12:26:44 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 23ar5389jb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 02 Jun 2016 12:26:44 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u52GQgHg028611; Thu, 2 Jun 2016 12:26:43 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u52GQYvR028426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jun 2016 12:26:38 -0400 Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 2 Jun 2016 16:26:19 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.204]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 12:26:18 -0400 From: "STARK, BARBARA H" To: Bob Hinden Thread-Topic: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) Thread-Index: AQHRvK9/Fb+UcSAuqEyMNazMBCLod5/WJrdggABwjQD//8LnoA== Date: Thu, 2 Jun 2016 16:26:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114268CB9D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> <3910EDD1-CF03-487F-9105-55FD053DC0E0@gmail.com> In-Reply-To: <3910EDD1-CF03-487F-9105-55FD053DC0E0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-02_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606020193 Archived-At: Cc: Benoit Claise , "babel-chairs@ietf.org" , IESG , "babel@ietf.org" Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 18:26:16 -0000 PiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgVFItMDY5IGlzIHVzZWQgYnkgSVNQcyB0byBtYW5h Z2Ugcm91dGVycyB0aGV5DQo+IGRlcGxveSBhdCB0aGUgZWRnZSBvZiB0aGUgY3VzdG9tZXJzIG5l dHdvcmssIEkgYW0gbm90IHN1cmUgaXQgaXMgYXBwcm9wcmlhdGUNCj4gdG8gaGF2ZSBhbiBJU1Ag bWFuYWdpbmcgcm91dGVycyBpbiBhIGhvbWVuZXQgKHRoYXQgaXMsIGhvbWVzLCBzbWFsbA0KPiBl bnRlcnByaXNlcywgZXRjLikuICBUaGVyZSBtYXkgYmUgbXVsdGlwbGUgSVNQIGNvbm5lY3Rpb25z IGFzIHdlbGwuDQo+IA0KPiBBcyB5b3UgcG9pbnQgb3V0IHRoZSBlbnZpcm9ubWVudCB3aGVyZSBC YWJlbCBhcHBlYXJzIHRvIGJlIHZlcnkgdXNlZnVsIGlzDQo+IGluIGFuIHVubWFuYWdlZCBob21l bmV0LCBzbyBJIGRvbuKAmXQgc2VlIHRoZSBuZWVkIHRvIGluY2x1ZGUgYSBUUi0wNjkNCj4gaW5m b3JtYXRpb24gbW9kZWwgaW4gdGhlIEJhYmVsIGNoYXJ0ZXIuDQoNCkhpIEJvYiwNCkkgZnVsbHkg ZXhwZWN0IHRoZSBJU1AtbWFuYWdlZCBjdXN0b21lciBlZGdlIHJvdXRlciB0byBwYXJ0aWNpcGF0 ZSBpbiBtYW55IGhvbWVuZXRzLiBOYXR1cmFsbHksIHBlb3BsZSBzaG91bGQgYWx3YXlzIGhhdmUg dGhlIG9wdGlvbiBvZiBmaXJld2FsbGluZyBiZXR3ZWVuIHRoZSBob21lbmV0IGFuZCB0aGlzIElT UCByb3V0ZXIgKHdoaWNoIGlzIHdoYXQgSSBkbykuIEJ1dCBtb3N0IHBlb3BsZSBkb24ndCBkbyB0 aGF0LiBUaGUgSVNQLW1hbmFnZWQgcm91dGVyIGlzIGEga2V5IGNvbXBvbmVudCBvZiBtb3N0IGhv bWUgbmV0d29ya3MuIA0KDQpJZiBJU1BzIHdhbnQgdG8gaGVscCB0aGVpciBjdXN0b21lcnMgdHVy biB0aGVpciBob21lIG5ldHdvcmsgaW50byBhICJob21lbmV0IiBob21lIG5ldHdvcmssIHRoZW4g dGhlIElTUCB3aWxsIHB1dCBwcm90b2NvbHMgbGlrZSBCYWJlbCBpbnRvIHRoZSBJU1AtbWFuYWdl ZCBjdXN0b21lciBlZGdlIHJvdXRlci4gSW4gdGhhdCBjYXNlLCB0aGUgSVNQIHdpbGwgZXhwZWN0 IHRvIGJlIGFibGUgdG8gbWFuYWdlIGFzcGVjdHMgb2YgQmFiZWwgaW4gdGhhdCBvbmUgcm91dGVy IC0tIGVuYWJsZS9kaXNhYmxlIGl0LCBlbmFibGUvZGlzYWJsZSBzcGVjaWZpYyBjb21wb25lbnRz IGxpa2UgSVB2NCwgYmUgYWJsZSB0byByZXRyaWV2ZSBzdGF0aXN0aWNzL2luZm8gdG8gaGVscCB3 aXRoIHRyb3VibGVzaG9vdGluZyB3aGVuIHRoZSBjdXN0b21lciBjYWxscyB0aGUgaGVscCBkZXNr LCBldGMuIA0KDQpJIGFic29sdXRlbHkgZG8gbm90IHdhbnQgdG8gc2VlIHRoZSBJU1AgbWFuYWdp bmcgYW55IG90aGVyIHJvdXRlciBpbnNpZGUgdGhlIGhvbWUgbmV0d29yay4NCkJhcmJhcmENCg== From nobody Thu Jun 2 11:33: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 C3AF912B01E for ; Thu, 2 Jun 2016 11:33: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 4rVs8WlxxZeV for ; Thu, 2 Jun 2016 11:33: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 D049412D54A for ; Thu, 2 Jun 2016 11:33: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 u52IXPcr022406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jun 2016 20:33: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 u52IXPD3007985; Thu, 2 Jun 2016 20:33: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 EE59C61FA5; Thu, 2 Jun 2016 20:33:24 +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 DPHBIsh5QZu2; Thu, 2 Jun 2016 20:33:23 +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 87E1861FAD; Thu, 2 Jun 2016 20:33:23 +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 1b8XQp-0002gF-BH; Thu, 02 Jun 2016 20:33:23 +0200 Date: Thu, 02 Jun 2016 20:33:23 +0200 Message-ID: <7ishwvv3t8.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht In-Reply-To: References: <20160602013442.16179.56150.idtracker@ietfa.amsl.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, 02 Jun 2016 20:33:25 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 02 Jun 2016 20:33:25 +0200 (CEST) X-Miltered: at korolev with ID 57507BF5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57507BF5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57507BF5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57507BF5.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 : 57507BF5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57507BF5.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] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 18:33:29 -0000 > I tend to think making an entirely incompatible version would be a > kiss of death. Not necessarily if the implementation speaks both versions, at least initially. (To be clear -- I sort of agree with you, but try to keep an open mind.) (OTOH, I'm increasingly thinking I'm going to redo source-specific routing in an inompatible manner. I'll write up my thoughts on babel-users.) > On the gripping hand, merely getting a "rip replacement" routinely > shipping and regularly available would be nice. Yes. Let's be careful to keep the spec simple. (Defined as "fits in the head of a third year student without swapping".) > a) self-configuration should be hardened, agreed. I'm surprised to hear that from you. You've been running a production Babel network for years, Dave, and providing me with useful bug reports, but I don't recall you having issues with router-id collisions. (See my reply to Tony.) > b) I'd like to see source specific routing widely available in all > routing protocols. I'd even like to see an extension to RA. Rtgwg, I believe. I'm pretty confident the RA extension will happen. > I'd like to see more interoperable interfaces to other link layers > (6lowpan/threads, usb, can, 802.11ad, 5g, homeplug, etc), be they > routing, failure mode detection, address assignment, security, or > service advertisement. I'm pessimistic. -- Juliusz From nobody Thu Jun 2 11:34:21 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 8E0D612D54B for ; Thu, 2 Jun 2016 11:34:19 -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 LuuM8OtfhYmE for ; Thu, 2 Jun 2016 11:34:18 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 D719012D54A for ; Thu, 2 Jun 2016 11:34:17 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id x189so58426551ywe.3 for ; Thu, 02 Jun 2016 11:34:17 -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=L8WlShTnqIauGRwxSWVAIq7qV00PaViYUCvwXwE37dg=; b=rn+qfeT6vOIsD5P9NoBuHtGyXKMFYl0zoRVBWJkb5yfPWNESTAIHZplZOSVPBQsJ08 kseQ8uPhQispkHp/Q1eHDozPjGsIc7gh19Me6pup45xe8W5SyDG8P2D/z9D29C6DucSE mGO/Hus7bLLjlyaTI77TTvbNAnjpqCmsmfGjNrn/zYlpp9oNVHvZKqPCDZGxj8UMHy1L LMMKJ47IsVF8cazS/eYUSz5wsM9HGKrpDiHEDkTbrMKmYNMEdTRAj3Malf6e3eYsabjv mREbpTOs9XgUyh0KGQKVbbDSsi4Ny3l7iOhxdK2BbQ0EF6KudB+cHX/diOtpdy/THNdZ 2mgA== 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=L8WlShTnqIauGRwxSWVAIq7qV00PaViYUCvwXwE37dg=; b=CHnXXBToAXApVIRL94x/IUvaWGkYp7ZDZNTFfdw7umsOajK+to+kvPh8l15QBbguAm 2/nVD/bTKJeDi/oLxFMvAiwaa8WSvf6QYDoH8cBP3oFDdPcYqna7tYhMgtVkkNPW1VbI Ti0ef3/Zpq0Gf1BTFhp6bLvHaxv28KNFJotvhSyhvXx7Xj3L7eCdJvarE8xn3WXhu7XG SxKd5bNE/tTSuxPuRzDPparbPjQSBDPt3P1pnIMPoTAjQP0N3coP8SHrCzs2jiu1j3yd 7aG4nMoBGOCh5F9VlHi29wp2wWdhdUQnKLJwoLySuZ+TWTxveniB1wYmcZfCrOsUwPM2 U/fA== X-Gm-Message-State: ALyK8tKUwy15hA7Jns/fhAZm6ggLBIyj+jww4Yd63i0yy/fUOrkwpFeyCB3cnBYfXgNNvA== X-Received: by 10.13.230.71 with SMTP id p68mr6802725ywe.125.1464892457048; Thu, 02 Jun 2016 11:34:17 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id o4sm962709ywe.22.2016.06.02.11.34.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jun 2016 11:34:16 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Juliusz Chroboczek'" , "'Tony Przygienda'" References: <7ivb1rv4ow.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <7ivb1rv4ow.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 2 Jun 2016 14:34:15 -0400 Message-ID: <07a301d1bcfd$5de5e3f0$19b1abd0$@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: AQGe7Q1jrC8ShR8Or5Jpo+80Zzg8DgHX7e99AYs8tywC5scS6qAJ0D9g Content-Language: en-us Archived-At: Cc: 'Babel at IETF' 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, 02 Jun 2016 18:34:19 -0000 > In other words, you get no catastrophic failures until the chosen router > crashes, and then all you get is a spurious blackhole for a few minutes. Router IDs are much more important in link state than in DUAL based protocols. The one place where this is eventually going to be harder problem to solve is with redistribution, though. Because you lose the original metric in the redistribution process, it's often important/useful to have something like an originator ID in the cluster list of BGP (RR's) to prevent some forms of loops by rejecting things that "I" originated into the routing domain. If you have duplicate router ID's, this is difficult. So far, there's seems to be no consideration of externals in BABEL, though... :-) Russ From nobody Thu Jun 2 11:39: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 BF4DB12B01E; Thu, 2 Jun 2016 11:39:46 -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 XkealMaLt9sU; Thu, 2 Jun 2016 11:39:45 -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 310A812D1E3; Thu, 2 Jun 2016 11:39:45 -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 u52IdhK8023921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jun 2016 20:39:43 +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 u52IdhnL009199; Thu, 2 Jun 2016 20:39: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 513D161F9A; Thu, 2 Jun 2016 20:39: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 slP0ft6n857L; Thu, 2 Jun 2016 20:39:39 +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 F007D61FA7; Thu, 2 Jun 2016 20:39:38 +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 1b8XWs-0002go-Oi; Thu, 02 Jun 2016 20:39:38 +0200 Date: Thu, 02 Jun 2016 20:39:38 +0200 Message-ID: <7ir3cfv3it.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]); Thu, 02 Jun 2016 20:39:43 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 02 Jun 2016 20:39:43 +0200 (CEST) X-Miltered: at korolev with ID 57507D6F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57507D6F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57507D6F.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57507D6F.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 : 57507D6F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57507D6F.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-chairs@ietf.org, Babel at IETF , Alia Atlas Subject: Re: [babel] Revised 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, 02 Jun 2016 18:39:47 -0000 > - The working group is encouraged to keep its wiki updated with > implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience > driving changes. Do we really need to specify the technology used for this information? What about "to keep its wiki updated with implementation experience" -> "to maintain up-to-date, publicly accessible information about implementation experience" Then the WG can choose whether to do a wiki page, an internet-draft, or whatever else we find convenient. -- Juliusz From nobody Thu Jun 2 11:46:14 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 8FEC512D7CF for ; Thu, 2 Jun 2016 11:46:12 -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 f7Q9QdXbFeaP for ; Thu, 2 Jun 2016 11:46:11 -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 505C112D7B3 for ; Thu, 2 Jun 2016 11:46:02 -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 u52Ijvkm025100; Thu, 2 Jun 2016 20:45:57 +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 9E4EE61F9A; Thu, 2 Jun 2016 20:45:57 +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 qmZF5Dhyv4-1; Thu, 2 Jun 2016 20:45:56 +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 307B861FBA; Thu, 2 Jun 2016 20:45:56 +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 1b8Xcx-0002j8-VS; Thu, 02 Jun 2016 20:45:56 +0200 Date: Thu, 02 Jun 2016 20:45:55 +0200 Message-ID: <7iporzv38c.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: <87inxucom8.fsf@toke.dk> <8760tto56q.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, 02 Jun 2016 20:45:57 +0200 (CEST) X-Miltered: at korolev with ID 57507EE5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57507EE5.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 : 57507EE5.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\)" , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , 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, 02 Jun 2016 18:46:12 -0000 > My experience is that it's really really hard to tell a WG that a WG > draft isn't going to progress to an RFC. Point taken. OTOH, BCP-78 doesn't prevent the authors from using the text in a peer-reviewed paper. > The advantage of a wiki is that more folks can add experience and it's > easy to update. Contrariwise, the advantage of an I-D is that it has a well-defined editor who can ensure that the information makes sense. Obviously, this can also be a disadvantage, depending on the editor, but I rather trust Toke. -- Juliusz From nobody Thu Jun 2 11:48: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 7E61612D7D4 for ; Thu, 2 Jun 2016 11:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 Mz59QrjSFeZt for ; Thu, 2 Jun 2016 11:48:23 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 BB9FA12D7D1 for ; Thu, 2 Jun 2016 11:48:23 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id z189so118558369itg.0 for ; Thu, 02 Jun 2016 11:48:23 -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=MHzN8YFglM3fq2y4lSNr7e1/bt7HuHLUbWZrkY+jfVU=; b=jYraj/cqtiXVFPtRel78q36xwaukDFgVYJUbY9NcxPT178aB/ymBGCeJoNXoJ3VbLQ vmTBTUQ8jH8rA2nL6nXPgXzKNOHdBc4M/E1haazNcU3tCDD2S9NNc1d2gjqvEDodlTxJ 9YnwoZcXRQDu1UFKMlpVdbh4ZmiDnAaBg04l8wKgtjH0DXILCqp6uNzaJjWxCHcWdaVp eyCiAH6zyHycXeCM31xneo/Sly/2hRL98lT4JwooeFtz1qeP1J58azoDPy1IxQedC1Tw DT04mOAMXPKK1wloncb7LlHqLc3BXdXllD2L/0t3MW17/Sl7jal062fzwfAkU9CnZ8Iy ofOg== 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=MHzN8YFglM3fq2y4lSNr7e1/bt7HuHLUbWZrkY+jfVU=; b=lt3gqMzcQPKEB/AFtHbh/+6C0Z4vw/qv3JrvmE5nOGqXtcnEHwEgEk39yZLun1fhqT Ayks429vLXdZXcPTggOWjsDYzzT/1Z1rOJ1VL1gWFUBBjMJytlYb7AUfUuD289Zi9c1F NU6F4KaI6HE3Mh9Jc2cTE2+DbeuWoLNfxT/dANZTXisaEGmi/RFabnaFXysFM/DiYmY8 BhrC+l8Op6wEm8aAZHOp/fQuqo6gxbSGNoT2hlLcoTQNyiPL2CmK1mnUuiOsBClpjsOI 03N/j7nSeYRu0uK+nNU0ZghhC3LBvBmPin8WcgGRBzJTzKJHpJeRK4RObvy5vfPtx1yW fLTQ== X-Gm-Message-State: ALyK8tK+Yv5ecgg1qcM4fc5pNzfFB+2nqTgHOmnRKzyyx5EPcIdlC+53KAzMpLnsbUvg5csrGcEbbp74lTB9vw== X-Received: by 10.36.16.67 with SMTP id 64mr313021ity.88.1464893303086; Thu, 02 Jun 2016 11:48:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.28.81 with HTTP; Thu, 2 Jun 2016 11:47:43 -0700 (PDT) In-Reply-To: <07a301d1bcfd$5de5e3f0$19b1abd0$@gmail.com> References: <7ivb1rv4ow.wl-jch@pps.univ-paris-diderot.fr> <07a301d1bcfd$5de5e3f0$19b1abd0$@gmail.com> From: Tony Przygienda Date: Thu, 2 Jun 2016 11:47:43 -0700 Message-ID: To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=001a11445b18f712630534500c8f Archived-At: Cc: Babel at IETF , Juliusz Chroboczek 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, 02 Jun 2016 18:48:25 -0000 --001a11445b18f712630534500c8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pretty radical stuff, this, and I have a hunch from practical experience something will prove completely infeasible in operations/protocol if you go down the path of 'duplicate router-ids are no big deal in the protocol', starting already from trivial DoS attacks or hijacking of traffic which will be undetectable ... --- tony On Thu, Jun 2, 2016 at 11:34 AM, Russ White <7riw77@gmail.com> wrote: > > > In other words, you get no catastrophic failures until the chosen route= r > > crashes, and then all you get is a spurious blackhole for a few minutes= . > > Router IDs are much more important in link state than in DUAL based > protocols. The one place where this is eventually going to be harder > problem > to solve is with redistribution, though. Because you lose the original > metric in the redistribution process, it's often important/useful to have > something like an originator ID in the cluster list of BGP (RR's) to > prevent > some forms of loops by rejecting things that "I" originated into the > routing > domain. If you have duplicate router ID's, this is difficult. > > So far, there's seems to be no consideration of externals in BABEL, > though... > > :-) > > Russ > > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a11445b18f712630534500c8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pretty radical stuff, this, and I have a hunch from practi= cal experience something will prove completely infeasible in operations/pro= tocol if you go down the path of 'duplicate router-ids are no big deal = in the protocol', starting already from trivial DoS attacks or hijackin= g of traffic which will be undetectable ...=C2=A0

--- to= ny=C2=A0

On = Thu, Jun 2, 2016 at 11:34 AM, Russ White <7riw77@gmail.com> w= rote:

> In other words, you get no catastrophic failures until the chosen rout= er
> crashes, and then all you get is a spurious blackhole for a few minute= s.

Router IDs are much more important in link state than in DUAL based<= br> protocols. The one place where this is eventually going to be harder proble= m
to solve is with redistribution, though. Because you lose the original
metric in the redistribution process, it's often important/useful to ha= ve
something like an originator ID in the cluster list of BGP (RR's) to pr= event
some forms of loops by rejecting things that "I" originated into = the routing
domain. If you have duplicate router ID's, this is difficult.

So far, there's seems to be no consideration of externals in BABEL,
though...

:-)

Russ




--
We=E2=80=99ve heard that a million monkeys at a million k= eyboards could produce the complete works of Shakespeare; now, thanks to th= e Internet, we know that is not true.
=E2=80=94Robert Wilensky
--001a11445b18f712630534500c8f-- From nobody Thu Jun 2 11:59: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 02C0512D16F for ; Thu, 2 Jun 2016 11:59:56 -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 uPEy_l9gkk4Q for ; Thu, 2 Jun 2016 11:59: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 768D412D0A8 for ; Thu, 2 Jun 2016 11:59:54 -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 u52IxqbX028344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Jun 2016 20:59:52 +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 u52IxqJK012409; Thu, 2 Jun 2016 20:59: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 3D1D061F9A; Thu, 2 Jun 2016 20:59: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 Fgr41XnbVDr4; Thu, 2 Jun 2016 20:59:50 +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 CFBA261FA7; Thu, 2 Jun 2016 20:59:50 +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 1b8XqQ-0002oh-Kx; Thu, 02 Jun 2016 20:59:50 +0200 Date: Thu, 02 Jun 2016 20:59:50 +0200 Message-ID: <7imvn3v2l5.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Russ White" <7riw77@gmail.com> In-Reply-To: <07a301d1bcfd$5de5e3f0$19b1abd0$@gmail.com> References: <7ivb1rv4ow.wl-jch@pps.univ-paris-diderot.fr> <07a301d1bcfd$5de5e3f0$19b1abd0$@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, 02 Jun 2016 20:59:52 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 02 Jun 2016 20:59:52 +0200 (CEST) X-Miltered: at korolev with ID 57508228.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57508228.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57508228.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57508228.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 : 57508228.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57508228.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: 'Babel at IETF' , 'Tony Przygienda' 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, 02 Jun 2016 18:59:56 -0000 > So far, there's seems to be no consideration of externals in BABEL, Could you please explain? -- Juliusz From nobody Thu Jun 2 12:12: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 4A2AB12D7E3 for ; Thu, 2 Jun 2016 12:12:52 -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 x25tkR8QTjMU for ; Thu, 2 Jun 2016 12:12: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 A210712D7D7 for ; Thu, 2 Jun 2016 12:12:50 -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 u52JCmIs030951; Thu, 2 Jun 2016 21:12:48 +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 A355461FA5; Thu, 2 Jun 2016 21:12:48 +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 PBG0Zsm0tzZH; Thu, 2 Jun 2016 21:12:47 +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 41FBC61F9A; Thu, 2 Jun 2016 21:12:47 +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 1b8Y2x-0002pU-2T; Thu, 02 Jun 2016 21:12:47 +0200 Date: Thu, 02 Jun 2016 21:12:47 +0200 Message-ID: <7ilh2nv1zk.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Tony Przygienda In-Reply-To: References: <7ivb1rv4ow.wl-jch@pps.univ-paris-diderot.fr> <07a301d1bcfd$5de5e3f0$19b1abd0$@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]); Thu, 02 Jun 2016 21:12:48 +0200 (CEST) X-Miltered: at korolev with ID 57508530.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57508530.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 : 57508530.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 , Russ White <7riw77@gmail.com> 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, 02 Jun 2016 19:12:52 -0000 > I have a hunch from practical experience something will prove completely > infeasible in operations/protocol if you go down the path of 'duplicate > router-ids are no big deal in the protocol', starting already from > trivial DoS attacks or hijacking of traffic which will be undetectable > ... I think we're in violent agreement. There's no contradiction: 1. Babel doesn't collapse with duplicate router-ids; 2. duplicate router-ids cause issues. It would certainly be good to work out a reliable way to detect duplicate router-ids (which is more difficult in Babel than in IS-IS, by the way, I'm not sure it's even doable reliably -- recall that we don't flood redundant routes in the whole network). Given a sufficiently elegant procedure (and implementation experience), I'd certainly be in favour of making it a strongly recommended part of the spec. -- Juliusz From nobody Thu Jun 2 12:19: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 9E37512D7DE for ; Thu, 2 Jun 2016 12:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 NHdhe1Ci_cJ1 for ; Thu, 2 Jun 2016 12:19:24 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 DB9B212D518 for ; Thu, 2 Jun 2016 12:19:23 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id z123so60284896itg.0 for ; Thu, 02 Jun 2016 12:19:23 -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=b6U2ojJsDIJIj6iDGrXVOSMlm5K1iKdVU3VJfsja07w=; b=OdUDgeaziYjukwzIzXrssD1uDJQCRXZ08kactCC8Zkhc4avxwSnsTG4ZaZ/+j9tEAH 8GI525nnrEZn1B9OWtPlsHVxERJtH/UcVPuuSmYEuCL8GNe9tTULhNQAe598I7MsJAmI o4ckrMEdUunG95R4410inT8+YyAWv1LemuDRvqf0ZE+bD9HrFbUo+Wy/1Hlzm+HKUWAI Vhd5esB7mrZmh8XhwrTkvJWSQHMEDGph0D10H6rk+rxNHFnAnGpJw6prYh3/T7x76FWp V8KLW60cgwkDBqp/pYpGeA8H0zFwdfIbbeHW6UKC2YaMojAbH8IUKhPLdwwOB5JGvgbE whoQ== 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=b6U2ojJsDIJIj6iDGrXVOSMlm5K1iKdVU3VJfsja07w=; b=PmVO/ES5tiMJoszPTPXrl5imPws+RRByfnOkz3xSOb6Hdc63gG8Zpk517KfUn3Z7WS NljO5Uy5q/xM1Bk2ZWuhQg81ilVrwPLZpa9qBijn3CsgmN9iUxgX7S3F2+v9YpcT/S+6 aYA6dOfcAdpSEokSg12PukoGksJ9zBsVGvOl93u90jRJRnOmZkeJQXNIT5n5lHn9hl1X RIy5YdSZu7i2IymwA1hLycOHe7HMZWAxhewV1U3Z+gUF1TzMOH8Ry/3b68bR4+qVxOrh 2DY0OH3kvJuu272bS5qTmVNBYEt7nyGUsyaGbUud70Sad7nvBzCVvtS9IpKSCG5MSujA WZSA== X-Gm-Message-State: ALyK8tJSik0/C3P5qmYFoPRseXr2MSgSddh0GCuucIz2mRyIEB6mIRT9NvKv1OeNrCutliF3CWXJ81QGzQ7x8A== X-Received: by 10.36.20.196 with SMTP id 187mr5252928itg.83.1464895163259; Thu, 02 Jun 2016 12:19:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.28.81 with HTTP; Thu, 2 Jun 2016 12:18:43 -0700 (PDT) In-Reply-To: <7ilh2nv1zk.wl-jch@pps.univ-paris-diderot.fr> References: <7ivb1rv4ow.wl-jch@pps.univ-paris-diderot.fr> <07a301d1bcfd$5de5e3f0$19b1abd0$@gmail.com> <7ilh2nv1zk.wl-jch@pps.univ-paris-diderot.fr> From: Tony Przygienda Date: Thu, 2 Jun 2016 12:18:43 -0700 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a1143e3c0d6fa180534507b06 Archived-At: Cc: Babel at IETF , Russ White <7riw77@gmail.com> 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, 02 Jun 2016 19:19:25 -0000 --001a1143e3c0d6fa180534507b06 Content-Type: text/plain; charset=UTF-8 +1 here ... On Thu, Jun 2, 2016 at 12:12 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > I have a hunch from practical experience something will prove completely > > infeasible in operations/protocol if you go down the path of 'duplicate > > router-ids are no big deal in the protocol', starting already from > > trivial DoS attacks or hijacking of traffic which will be undetectable > > ... > > I think we're in violent agreement. There's no contradiction: > > 1. Babel doesn't collapse with duplicate router-ids; > 2. duplicate router-ids cause issues. > > It would certainly be good to work out a reliable way to detect duplicate > router-ids (which is more difficult in Babel than in IS-IS, by the way, > I'm not sure it's even doable reliably -- recall that we don't flood > redundant routes in the whole network). Given a sufficiently elegant > procedure (and implementation experience), I'd certainly be in favour of > making it a strongly recommended part of the spec. > > -- Juliusz > --001a1143e3c0d6fa180534507b06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 here ...=C2=A0

On Thu, Jun 2, 2016 at 12:12 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
> I have a hunch from practical expe= rience something will prove completely
> infeasible in operations/protocol if you go down the path of 'dupl= icate
> router-ids are no big deal in the protocol', starting already from=
> trivial DoS attacks or hijacking of traffic which will be undetectable=
> ...

I think we're in violent agreement.=C2=A0 There's no contrad= iction:

=C2=A0 1. Babel doesn't collapse with duplicate router-ids;
=C2=A0 2. duplicate router-ids cause issues.

It would certainly be good to work out a reliable way to detect duplicate router-ids (which is more difficult in Babel than in IS-IS, by the way,
I'm not sure it's even doable reliably -- recall that we don't = flood
redundant routes in the whole network).=C2=A0 Given a sufficiently elegant<= br> procedure (and implementation experience), I'd certainly be in favour o= f
making it a strongly recommended part of the spec.

-- Juliusz


--001a1143e3c0d6fa180534507b06-- From nobody Thu Jun 2 12:45: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 85DFE12D7F9; Thu, 2 Jun 2016 12:45:03 -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 7HRKzVV7Y0-x; Thu, 2 Jun 2016 12:45:01 -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 5C02D12D7F8; Thu, 2 Jun 2016 12:45: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 u52JisZe006385; Thu, 2 Jun 2016 21:44:54 +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 97DC661FA5; Thu, 2 Jun 2016 21:44: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 ZB24OnJSu8AS; Thu, 2 Jun 2016 21:44:53 +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 371CF61F9A; Thu, 2 Jun 2016 21:44:53 +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 1b8YY0-0002tJ-RS; Thu, 02 Jun 2016 21:44:52 +0200 Date: Thu, 02 Jun 2016 21:44:52 +0200 Message-ID: <7iinxrv0i3.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114268CB9D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> <3910EDD1-CF03-487F-9105-55FD053DC0E0@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114268CB9D@GAALPA1MSGUSRBF.ITServices.sbc.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]); Thu, 02 Jun 2016 21:44:54 +0200 (CEST) X-Miltered: at korolev with ID 57508CB6.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57508CB6.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 : 57508CB6.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: Benoit Claise , "babel-chairs@ietf.org" , Bob Hinden , IESG , "babel@ietf.org" Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 02 Jun 2016 19:45:03 -0000 > I fully expect the ISP-managed customer edge router to participate in > many homenets. I've heard both opinions -- that the CPE participates in HNCP/Babel, and that the CPE only announces itself to the Homenet using DHCPv6-PD. Hnetd supports both models out of the box, while shncpd currently only supports the former (without some creative scripting). DHCPv6-PD works fine if there's only one Homenet router directly connected to the CPE. If there are more than one, however, you get as many prefixes assigned to your Homenet as there are successful prefix delegations, which can be as many as there are routers. My take is that while we don't know how Homenet will be deployed, we should certainly anticipate the (desirable) case where the CPE implements HNCP and Babel (possibly a stub subset). TR-069 for Babel would be a goodness. -- Juliusz From nobody Thu Jun 2 13:34: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 6931012D5FF for ; Thu, 2 Jun 2016 13:34: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 MShLalYDVYfq for ; Thu, 2 Jun 2016 13:34:00 -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 9B9CA12D562 for ; Thu, 2 Jun 2016 13:34:00 -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 u52KXwbq018031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 2 Jun 2016 22:33:59 +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 u52KXwu7028861 for ; Thu, 2 Jun 2016 22:33:58 +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 D0D9261FAD for ; Thu, 2 Jun 2016 22:33:58 +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 IFsHwGhLzNHB for ; Thu, 2 Jun 2016 22:33:57 +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 7E9CF61FA7 for ; Thu, 2 Jun 2016 22:33:57 +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 1b8ZJV-0002xM-9y for babel@ietf.org; Thu, 02 Jun 2016 22:33:57 +0200 Date: Thu, 02 Jun 2016 22:33:57 +0200 Message-ID: <7i7fe7uy8a.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Babel at IETF 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, 02 Jun 2016 22:33:59 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 02 Jun 2016 22:33:58 +0200 (CEST) X-Miltered: at korolev with ID 57509836.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57509836.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57509836.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57509836.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 : 57509836.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57509836.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: Subject: [babel] What to do about extension drafts? 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, 02 Jun 2016 20:34:02 -0000 Hi, If I read the current consensus correctly: - source-specific routing is in scope; - exciting metrics are out of scope. I take this to mean that we don't touch the source-specific extension draft, and ask for adoption once the WG is formed. Great. Now what should I do with - draft-jonglez-babel-rtt-extension - draft-chroboczek-babel-diversity-routing ? The former, in particular, is a mature protocol extension that has been evaluated seriously and deployed in production. Is the individual submission process a good way to advance it, or would that be taken as trying to do something behind the back of the WG? (The latter should finally get a formal evaluation this summer, Murphy willing.) -- Juliusz From nobody Thu Jun 2 13:42:16 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 D405012D850 for ; Thu, 2 Jun 2016 13:42:15 -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 qk5V66SQ5R4S for ; Thu, 2 Jun 2016 13:42:13 -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 A942B12D837 for ; Thu, 2 Jun 2016 13:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 3D66B40472 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1464900130; bh=ubd310qWEDvUpnNHk380X9DuT/naGhD4pioGXt4Q2AU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=C3gTDKWcfqYw3xk0juVuVWpktkrHLZ5gEZX03t0eyrokE6koyI8ZXxXH3I6hNuy87 ORYCQCeXdplxiAsvvJEP0XhaFNMicqH8Agk5g4qHh1RH5WNGA8ch7xOWy8iJtBupVM A3e7naqgMqbuQQpC61v91Uld+IlyZoTO8ln7wJxg= Sender: toke@toke.dk Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 6D5C8751E7D; Thu, 2 Jun 2016 22:42:09 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Juliusz Chroboczek References: <87inxucom8.fsf@toke.dk> <8760tto56q.wl-jch@pps.univ-paris-diderot.fr> <7iporzv38c.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 02 Jun 2016 22:42:09 +0200 In-Reply-To: <7iporzv38c.wl-jch@pps.univ-paris-diderot.fr> (Juliusz Chroboczek's message of "Thu, 02 Jun 2016 20:45:55 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874m9btja6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 02 Jun 2016 20:42:16 -0000 Juliusz Chroboczek writes: >> The advantage of a wiki is that more folks can add experience and it's >> easy to update. > > Contrariwise, the advantage of an I-D is that it has a well-defined editor > who can ensure that the information makes sense. Also, for those of us subject to academia's publish-or-perish ethos (ha!), an internet draft is also easier to justify to the bean counters. > Obviously, this can also be a disadvantage, depending on the editor, > but I rather trust Toke. Thanks ;) -Toke From nobody Thu Jun 2 20:40: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 056C012D61D; Thu, 2 Jun 2016 20:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PNqCbbI9zftD; Thu, 2 Jun 2016 20:39:56 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE2A12D62F; Thu, 2 Jun 2016 20:39:56 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-26-5750f30ca0c9 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 04.A0.09012.C03F0575; Fri, 3 Jun 2016 05:01:32 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 23:39:55 -0400 From: Suresh Krishnan To: Alia Atlas , Donald Eastlake Thread-Topic: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) Thread-Index: AQHRvG7zwM/qrb6Kek+CGXjQ2yF5ZQ== Date: Fri, 3 Jun 2016 03:39:54 +0000 Message-ID: References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXSPty7P54Bwg4dnJSw+PbzEbHG69xaL xZZF3SwWB7drWsz4M5HZgdVj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MqYdHcBe8EbwYrt z2ayNDC+5O1i5OCQEDCReLZBsYuRE8gUk7hwbz0biC0kcJRRYtY0jy5GLiB7GaPEvBcfGEES bED1G3Z+ZgKxRQTcJP4u3cAEModZIF/i0IIykLCwQKLErj+7WCBKkiT+/OuCsvUkLp14BtbK IqAicWnFXLBdvAK+Eou3LmCH2HWeUaJp2hF2kAQj0EHfT60Ba2AWEJe49WQ+E8ShAhJL9pxn hrBFJV4+/scKYStJzHl9jRmiXkdiwe5PbBC2tsSyha+ZIZYJSpyc+YRlAqPoLCRjZyFpmYWk ZRaSlgWMLKsYOUqLC3Jy040MNjEC4+SYBJvuDsb70z0PMQpwMCrx8CasCQgXYk0sK67MPcQo wcGsJMIr9gMoxJuSWFmVWpQfX1Sak1p8iFGag0VJnFfskWK4kEB6YklqdmpqQWoRTJaJg1Oq gfHIdPGZtxmf7l3G/fg16+LgRQkfphzI4lE5qrHKWHXLnd/qnrv3et9sYvHf+kbv1Jx3tlI7 yifNtJF5uv64Wbwry1f5AFln3+NfXjlMu7W1/HLRgp7CUm///dlPZ7p07LDc9Xx3m5X4qj8C G1R0lt8I5U2V0RdZ971YeF/FmbA5lUGPPu85cmOVEktxRqKhFnNRcSIAMMTZUY8CAAA= Archived-At: Cc: "babel-chairs@ietf.org" , The IESG , Babel at IETF Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 03 Jun 2016 03:39:59 -0000 Hi Don/Alia,=0A= =0A= On 06/02/2016 10:33 AM, Alia Atlas wrote:=0A= >=0A= > On Thu, Jun 2, 2016 at 10:30 AM, Donald Eastlake > wrote:=0A= >=0A= > Hi,=0A= >=0A= > On Wed, Jun 1, 2016 at 9:34 PM, Suresh Krishnan=0A= > > = wrote:=0A= > > Suresh Krishnan has entered the following ballot position for=0A= > > charter-ietf-babel-00-02: No Objection=0A= > >=0A= > > ...=0A= > >=0A= > > -------------------------------------------------------------------= ---=0A= > > COMMENT:=0A= > > -------------------------------------------------------------------= ---=0A= > >=0A= > > * There is no mention of backward compatibility in the charter. Is = the=0A= > > "new" Babel intended to be backward compatible with the deployed=0A= > > experimental version(s)? Might be worth noting either way.=0A= >=0A= > Well, it seems like all you would say is "Backwards compatibility wit= h=0A= > deployed versions of Babel is desirable but not required." That can= =0A= > certainly be added.=0A= >=0A= > > * One of the potential (and I personally think one of the most impo= rtant)=0A= > > uses of Babel is as a routing protocol in homenets. Two of the thin= gs=0A= > > that seem to be interesting improvements to Babel for this use case= seem=0A= > > to be a)self-configuration and b)source-specific routing. I do not = see=0A= > > either of them in the charter. I would have really liked to see som= ething=0A= > > in the charter to address these two issues.=0A= >=0A= > HOMENET should be specifically reference as a WG with which to coordi= nate.=0A= >=0A= > Based on IESG discussion that just occurred and HOMNET requirements,= =0A= > auto-configuration should be added as a point. Not as clear about=0A= > source-specific routing.=0A= >=0A= >=0A= > Source-specific routing should be added as an item that the WG can do as = a=0A= > secondary=0A= > focus - very similar to the multicast.=0A= =0A= That sounds good to me if there is energy in the community to do that.=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A= From nobody Thu Jun 2 20:47:34 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 C371A12D640; Thu, 2 Jun 2016 20:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0r5xsQFEujjJ; Thu, 2 Jun 2016 20:47:29 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9054212D1CE; Thu, 2 Jun 2016 20:47:29 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-d7-5750fd994e44 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 45.C1.03614.99DF0575; Fri, 3 Jun 2016 05:46:33 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 23:47:27 -0400 From: Suresh Krishnan To: Dave Taht Thread-Topic: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) Thread-Index: AQHRvG7zwM/qrb6Kek+CGXjQ2yF5ZQ== Date: Fri, 3 Jun 2016 03:47:27 +0000 Message-ID: References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPiO7MvwHhBse7ZSxO995isdiyqJvF Ys/GkywWM/5MZHZg8dg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mi7O2sxc8FumYsea68wN jBvEuxg5OSQETCSWHLzPBmGLSVy4tx7I5uIQEjjKKLHoyBZ2CGcZo8SMFa3sIFVsQB0bdn5m ArFFBJQlptw/ARZnFiiSuLHxPguILSyQKLHrzy4WiJokiT//uqBsPYlLJ56B9bIIqEicmbiH GcTmFfCVeHL1CwvEsg5GifXrr4MVMQKd9P3UGiaIBeISt57MZ4I4VUBiyZ7zzBC2qMTLx/9Y IWwliTmvrzFD1OtILNj9iQ3C1pZYtvA11DJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUj R2lxQU5uupHhJkZglByTYHPcwbi31/MQowAHoxIPb8KagHAh1sSy4srcQ4wSHMxKIrwpv4FC vCmJlVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUaGBmrO3KfPTDM XsYaZLkh6z1zfpNg2wsxl8n5uV+K+Ly37TlyomG+7NL7rZ27lPof/nVLz59x6BuP/0fLqPpN ur8aGDgyJrjdPDprOUfFj+j295x72dp3ss7d9E9gVrKbpMOLrdp/WhLKXyq3f5773Lk8SH7K 1OVfLih+chdtMRa69Ov004hLBUosxRmJhlrMRcWJACE1+r6OAgAA Archived-At: Cc: "babel-chairs@ietf.org" , The IESG , "babel@ietf.org" Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 03 Jun 2016 03:47:31 -0000 Hi Dave,=0A= =0A= On 06/02/2016 11:03 AM, Dave Taht wrote:=0A= > On Wed, Jun 1, 2016 at 6:34 PM, Suresh Krishnan=0A= > wrote:=0A= >> Suresh Krishnan has entered the following ballot position for=0A= >> charter-ietf-babel-00-02: No Objection=0A= >>=0A= >> When responding, please keep the subject line intact and reply to all= =0A= >> email addresses included in the To and CC lines. (Feel free to cut this= =0A= >> introductory paragraph, however.)=0A= >>=0A= >>=0A= >>=0A= >> The document, along with other ballot positions, can be found here:=0A= >> https://datatracker.ietf.org/doc/charter-ietf-babel/=0A= >>=0A= >>=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> COMMENT:=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >> * There is no mention of backward compatibility in the charter. Is the= =0A= >> "new" Babel intended to be backward compatible with the deployed=0A= >> experimental version(s)? Might be worth noting either way.=0A= >=0A= > I tend to think making an entirely incompatible version would be a=0A= > kiss of death.=0A= >=0A= > On the other hand, there are a metric ton of other problems I'd like=0A= > to be solving. (see below)=0A= >=0A= > On the gripping hand, merely getting a "rip replacement" routinely=0A= > shipping and regularly available would be nice.=0A= >=0A= >> * One of the potential (and I personally think one of the most importan= t)=0A= >> uses of Babel is as a routing protocol in homenets. Two of the things= =0A= >> that seem to be interesting improvements to Babel for this use case see= m=0A= >> to be a)self-configuration and b)source-specific routing. I do not see= =0A= >> either of them in the charter. I would have really liked to see somethi= ng=0A= >> in the charter to address these two issues.=0A= >=0A= > a) self-configuration should be hardened, agreed. I saw an interesting= =0A= > new approach in bmx7 the other day...=0A= >=0A= > http://bmx6.net/news/22=0A= >=0A= > ...=0A= >=0A= > Not entirely relevant to the formation of this wg, but stuff I wish=0A= > had homes elsewhere (do they? most of my issues tend to cross layers=0A= > these days):=0A= =0A= Interesting read. Thanks for that pointer.=0A= =0A= >=0A= > b) I'd like to see source specific routing widely available in all=0A= > routing protocols. I'd even like to see an extension to RA.=0A= =0A= Something like this?=0A= =0A= https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01=0A= =0A= >=0A= > c) It is not just a homenet thing to want ethernet, homeplug, wifi,=0A= > 5g, 6lopan, etc, interoperating well with different isps and devices.=0A= >=0A= > I'd like to see more interoperable interfaces to other link layers=0A= > (6lowpan/threads, usb, can, 802.11ad, 5g, homeplug, etc), be they=0A= > routing, failure mode detection, address assignment, security, or=0A= > service advertisement.=0A= >=0A= > In particular, I could see usb-c one day becoming a short haul=0A= > ethernet replacement if it spoke IP well and universally, and the tv=0A= > becoming the network center of the home... I don't know where=0A= > HDMI-ethernet went wrong...=0A= >=0A= > (I routinely use babel to route between wifi, ethernet, and usbnet=0A= > "gadget"s today - modern hackerboards like the pi, and getchip.com=0A= > etc, all have this basic support, and many hackerboards are arriving=0A= > that speak usb and wifi only - and lack ethernet. )=0A= =0A= Cool.=0A= =0A= Thanks=0A= Suresh=0A= =0A= =0A= =0A= From nobody Fri Jun 3 09:53:06 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 4939712D729; Fri, 3 Jun 2016 09:53:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603165304.1480.73282.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 09:53:04 -0700 Archived-At: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, akatlas@gmail.com Subject: [babel] babel - New Meeting Session Request for IETF 96 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: Fri, 03 Jun 2016 16:53:04 -0000 A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: homenet trill saag lpwan isis idr rtgwg Second Priority: dnsop Special Requests: --------------------------------------------------------- From nobody Fri Jun 3 10:01:46 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 BFBCC12D5BA; Fri, 3 Jun 2016 10:01:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603170143.1446.29522.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 10:01:43 -0700 Archived-At: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, akatlas@gmail.com Subject: [babel] babel - Update to a Meeting Session Request for IETF 96 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: Fri, 03 Jun 2016 17:01:44 -0000 An update to a meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: homenet trill saag lpwan isis idr rtgwg ospf manet Second Priority: dnsop Special Requests: --------------------------------------------------------- From nobody Fri Jun 3 12:48: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 AD28412D960 for ; Fri, 3 Jun 2016 12:48:01 -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 xrDri0HywFaN for ; Fri, 3 Jun 2016 12:47:59 -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 C259E12D95E for ; Fri, 3 Jun 2016 12:47:53 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id c127so90071532ywb.1 for ; Fri, 03 Jun 2016 12:47: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=ViJfHsAV5jl9Uv7TOibajEQmuxyDufjy3F2nlCBSBVo=; b=V+3+8yDkFP0BnWX4IIsU6aZ0byI1kprAW1rRvfacBCzvbiqIzgILsTUB2P4vWbi8CU LRrYBtGgYBxMEN9l7a5n9+PtbQiL2pnK1i6iU5iRnilPBOT4mVrd5PBcvgTeLaF4P/Ww BOmAo2AiIKtJ6whBfhLk/iaYGjqu5wZ7t4qHZ0fpiwGrHfvzb9yGP4nqfvLvl6Nn8eSV OdPsLitHDsDDPtIijjTavW5nsNQ9sNNxNK/F9CzsJTdVaHMrgXs8jRVaUMc8f3pzSL7Z hdTY5Sw+XUwjsfAR4CxJueU0YHunuMmIWk2e9cBurdSJX9vs7Xs57mVR4ZlNirOIANJs J7uQ== 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=ViJfHsAV5jl9Uv7TOibajEQmuxyDufjy3F2nlCBSBVo=; b=HVpOf5uHzHEB5GikA9OTUjGMENV8NxYAvFygFBQFd74b+P7aYLghe8ZppMF45l1O9n duRUsWerpT32fT2JXsOkj67CuYzEZbF0345QQHPNg0CCH7fiD7c4J8hwthZSz0KiBhO/ oT1uAVMWkUMam6KGVpi0SkHT6678EU8725j1xnS5A9WiYVh8Elt0s2oOxvrSYLTdZGn3 +yRVkB43xjr6jxZ0F7wnq06FG+UT09Q6AOkkvwJXZ4GRZNJW2v2d5/UouWrUNYQqrtN9 HPnaBQZ3BQxX/brXkwkzY22PlRFJUTV+Jm5w6SSUMKnzgYjg+/P64Hqiklyq3dB/viI1 +ITA== X-Gm-Message-State: ALyK8tLpeUD3Ibc0u2uLQZIRk9SX1DqDDkcfMTeQJecmzrLK5VmbJITqXz+ANDzs0BvvhJmBeKknlLD0CYsDIw== X-Received: by 10.37.218.141 with SMTP id n135mr3508100ybf.125.1464983273030; Fri, 03 Jun 2016 12:47:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.74 with HTTP; Fri, 3 Jun 2016 12:47:52 -0700 (PDT) In-Reply-To: <7i7fe7uy8a.wl-jch@pps.univ-paris-diderot.fr> References: <7i7fe7uy8a.wl-jch@pps.univ-paris-diderot.fr> From: Alia Atlas Date: Fri, 3 Jun 2016 15:47:52 -0400 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=94eb2c07f17c9749e7053464ffc4 Archived-At: Cc: Babel at IETF Subject: Re: [babel] What to do about extension drafts? 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, 03 Jun 2016 19:48:02 -0000 --94eb2c07f17c9749e7053464ffc4 Content-Type: text/plain; charset=UTF-8 Hi Juliusz, On Thu, Jun 2, 2016 at 4:33 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > Hi, > > If I read the current consensus correctly: > > - source-specific routing is in scope; > - exciting metrics are out of scope. > > I take this to mean that we don't touch the source-specific extension > draft, and ask for adoption once the WG is formed. Great. > Be prepared for some coordination with RTGWG around the source-dest routing work. The question has come out of v6ops with the idea that it should solve IPv6 multihoming for the small enterprise too. There are a number of assumptions there that still need to be unraveled. But yes, the source-specific work is in scope for adoption. > Now what should I do with > > - draft-jonglez-babel-rtt-extension > - draft-chroboczek-babel-diversity-routing > > ? > > The former, in particular, is a mature protocol extension that has been > evaluated seriously and deployed in production. Is the individual > submission process a good way to advance it, or would that be taken as > trying to do something behind the back of the WG? > Now that there is almost a WG, I don't see any reason that work shouldn't be discussed in the WG. I don't think that you want to take work via the Independent Stream. If there is urgency and interest in additional work, charter revisions do happen and aren't usually (in my experience) that painful. The draft-jonglez-babel-rtt-extension seems to fall into the defining at least one mandatory metric scheme. Regards, Alia > (The latter should finally get a formal evaluation this summer, Murphy > willing.) > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --94eb2c07f17c9749e7053464ffc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

On Thu, Jun 2, 2016 at 4:33 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
Hi,

If I read the current consensus correctly:

=C2=A0 - source-specific routing is in scope;
=C2=A0 - exciting metrics are out of scope.

I take this to mean that we don't touch the source-specific extension draft, and ask for adoption once the WG is formed.=C2=A0 Great.

Be prepared for some coordination with RTGWG aroun= d the source-dest routing
work.=C2=A0 The question has come out o= f v6ops with the idea that it should solve
IPv6 multihoming for t= he small enterprise too.=C2=A0 There are a number of assumptions
= there that still need to be unraveled.

But yes, th= e source-specific work is in scope for adoption. =C2=A0
=C2=A0
Now what should I do with

=C2=A0 - draft-jonglez-babel-rtt-extension
=C2=A0 - draft-chroboczek-babel-diversity-routing

?

The former, in particular, is a mature protocol extension that has been
evaluated seriously and deployed in production.=C2=A0 Is the individual
submission process a good way to advance it, or would that be taken as
trying to do something behind the back of the WG?

=
Now that there is almost a WG, I don't see any reason that w= ork shouldn't=C2=A0
be discussed in the WG.=C2=A0 I don't= think that you want to take work via the
Independent Stream.=C2= =A0 If there is urgency and interest in additional work,
charter = revisions do happen and aren't usually (in my experience) that painful.=

The draft-jonglez-babel-rtt-extension seems to fa= ll into the defining at least one
mandatory metric scheme.
<= div>
Regards,
Alia

=C2=A0<= /div>
(The latter should finally get a formal evaluation this summer, Murphy
willing.)

-- Juliusz

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

--94eb2c07f17c9749e7053464ffc4-- From nobody Fri Jun 3 13:39: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 CBBC512D14B; Fri, 3 Jun 2016 13:39:45 -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 kiiL232rNwrN; Fri, 3 Jun 2016 13:39:43 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 D7C1F12D0B1; Fri, 3 Jun 2016 13:39:42 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h19so91425064ywc.0; Fri, 03 Jun 2016 13:39:42 -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=Tukb1aUhL6JugwlsfMnGdiTynfXINHFbDukOGdnBcbM=; b=ZtFuJ0weTV4vd5nEunR9vcIvQ2VJ0hzc4295CtI2d9Mhtwu7uB+aFr8nK/mja9guaG NpPh/RV9CIDIBBiR/ypNouS0biLTKk49ZVerfHpW3Egv/va9B5sleF9xbtphShvqpD3k huI6NXRO83h+r5I3XNm0D5nMiOwqhvS/YjjfVJqdzHf8EQM4Kc8PnJEauEtdmHzcZuav 3WzUTKJaFkdI3/loHqr209pQFh4OCxKY4G8I9mgbyMyVczPSX8a7wi5r7WSY/U/fcp+0 ff4K574EDi31QrtrAN4l+r5jGHIb3HGbRT5h0mPfM4aPPwVo38mGmxpTAAIyY3we1gaP gGzQ== 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=Tukb1aUhL6JugwlsfMnGdiTynfXINHFbDukOGdnBcbM=; b=FM7APC+8wP7b/6KuE1z4pKLVbKrpyzMdL41LKu8EtNPKYooljx2cbeB3TQHfkM8WuK ayIQTsC2n9PFv3ZiSSiZTRZvYhONdmdXZyzDYP/3nETI8n64f8exXVcX0/eKHlyrJHIo Y4AcLoW0IQ0yzd9Cn4bYtxJT7dMxE3wkQ5OvJLPoDBdIykIJk4jpQbVXRl3J9+7PdExi AkBqrJ8w4kV3JHJskXweF/OyIKEEN1Iq5bdSBz73qDrJzyCWgAAeeZOvTJa3G5TLg1QW Vmpe6MvNJMJaYL7KIF4YKL3d8moTDfw0YX2JSuu80eCnKpvUEHPYrJmPMtZe9eq1cuKW PWwA== X-Gm-Message-State: ALyK8tKxLogbmlYaWpCeR+wo3zrxMFV4379ReBEjML711rosOi5NJ45HD5ZaAd2tXjwFKp60jh/P8OyMxYbN7w== X-Received: by 10.37.83.131 with SMTP id h125mr3653899ybb.109.1464986381868; Fri, 03 Jun 2016 13:39:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.74 with HTTP; Fri, 3 Jun 2016 13:39:41 -0700 (PDT) In-Reply-To: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Alia Atlas Date: Fri, 3 Jun 2016 16:39:41 -0400 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a113e60bae46321053465b835 Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF Subject: Re: [babel] Revised 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, 03 Jun 2016 20:39:46 -0000 --001a113e60bae46321053465b835 Content-Type: text/plain; charset=UTF-8 Hi Donald, Russ, Juliusz, Toke, etc., I have read through all the discussion and IESG comments on the charter. Here is what I have for an updated version. I do need to get it out for External Review soon so that it can come back onto the IESG telechat for final approval. The External Review is to give time for comments by those not on the IESG or WG - and particularly that it goes out to other organizations who might be interested. In the case of Babel, that is relevant because of the potential interaction with the Broadband Forum on TR-069. The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I am including the text below. ================================================================= Babel is a loop-avoiding, distance vector routing protocol with good provisions for dynamically computed link metrics. It is robust even in the presence of link metric oscillations and the failure of transitivity. The core of the Babel protocol and security extensions are described in Experimental Independent Stream RFCs 6126, 7557, and 7298. These RFCs are the basis of three independent, open source implementations. There is some production deployment of these implementations, notably in hybrid networks (networks that include classical, wired parts with meshy radio bits) and in global overlay networks (networks built out of large numbers of tunnels spanning continents). The Working Group will focus on moving the Babel protocol to IETF Proposed Standard with IETF review. This includes clarifying RFC 6126 and integrating RFC 7557 and feedback provided by independent implementations, and resolving comments. It is not a requirement that the Babel protocol produced is backwards compatible with RFC 6126. It is a requirement that Babel support at least one profile that is auto-configuring. Other documents that are relevant to the above work can also be produced. Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security. Link metric measurement or link metric calculation procedures significantly more complex that those currently in Babel are out of scope. Work Items: - Produce a revision of RFC 6126 suitable for publication as a Proposed Standard -- incorporate in the revision developments since RFC 6126 -- resolve technical issues found -- include in the base specification the extensibility work in RFC 7557 -- support auto-configuration -- consider any important changes based on experience with Babel to date. - Address security needs for BABEL. This may include using the techniques in RFC 7298, or other alternatives. Security may be included in the base spec or the base spec may normatively reference a separate Proposed Standard specification. This is required as part of moving Babel to Proposed Standard. - Address manageability of Babel by producing an informational model for use by other network management such as the Broadband Forum TR-069, and a YANG data module based on that information model. This YANG data module to be consistent with the ongoing effort to use YANG data modules in the Routing Area. This work is required as part of moving Babel to Proposed Standard. - As the Proposed Standard version of Babel is completed, an Applicability Statement should be finalized to guide those potentially interested in deploying Babel. This Applicability Statement may include deployment advice and will be published as an RFC. - Coordinate with other Working Groups, such as the HOMENET WG for likely applicability, the RTGWG and V6OPS WG about Source-Specific Routing to support IPv6 multihoming, the PIM WG for discussion around multicast, and the MANET WG for considerations around wireless. - Liaise as necessary with the Broadband Forum to facilitate use of the Babel management Information Model for TR-069. - The Working Group should document its ongoing implementation experience with Babel, so that new WG participants can understand the state that is driving this work and the experience driving changes. This documentation may be on the Working Group's wiki, in an internet-draft that isn't expected to be published as an RFC, or a combination. - As a secondary focus, the Working Group may work on multicast aspects of Babel. This may include discussion of any potential issues for supporting Babel running with PIM-SM in an auto-configuration profile. It may include exploring Babel carrying separate metrics for multicast. It may even include discussion and consultation with the PIM WG about Babel providing the ability to build multicast routing tables. With AD and WG agreement, once an approach is understood, then a milestone may be added for an associated document targeted as Proposed Standard. - As a secondary focus, the Working Group may work on documents defining source specific routing extensions for Babel as a way of handling IPv6 multihoming. Thus, the Working Group will produce a Proposed Standard Babel specification, including or paired with a suitable Proposed Standard specification covering the security mechanism(s) for BABEL. It will also produce a management information and data model for BABEL as a Proposed Standard RFC. An applicability statement will be produced as an Informational RFC. *Proposed Milestones* DateMilestone Aug 2017 IESG Submission of Babel Applicability draft Jul 2017 IESG Submission of Babel Management draft Jul 2017 IESG Submission of RFC6126bis and potentially companion security mechanisms draft Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) draft Jul 2016 WG adoption of RFC6126bis Jul 2016 WG adoption of Babel Applicability draft draft-chroboczek-babel-applicability ================================================================= On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > - The working group is encouraged to keep its wiki updated with > > implementation experience with Babel so that new WG participants can > > understand the state that is driving this work and the experience > > driving changes. > > Do we really need to specify the technology used for this information? > What about > > "to keep its wiki updated with implementation experience" -> "to > maintain up-to-date, publicly accessible information about > implementation experience" > > Then the WG can choose whether to do a wiki page, an internet-draft, or > whatever else we find convenient. > > -- Juliusz > --001a113e60bae46321053465b835 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Donald, Russ, Juliusz, Toke, etc.,

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

The link is=C2=A0https://datatracker.ietf.org/doc/charter-ietf-babel/ .=C2= =A0 I am including the text below.

=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=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=3D=3D=3D

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 prot= ocol and security extensions
are described in Experimental Independent S= tream RFCs 6126, 7557, and
7298.

These RFCs are the basis of thre= e independent, open source
implementations. There is some production dep= loyment of these
implementations, notably in hybrid networks (networks t= hat include
classical, wired parts with meshy radio bits) and in global = overlay
networks (networks built out of large numbers of tunnels spannin= g
continents).

The Working Group will focus on moving the Babel p= rotocol to IETF
Proposed Standard with IETF review.=C2=A0 This includes = clarifying RFC 6126
and integrating RFC 7557 and feedback provided by in= dependent
implementations, and resolving comments. It is not a requireme= nt that
the Babel protocol produced is backwards compatible with RFC 612= 6.=C2=A0 It
is a requirement that Babel support at least one profile tha= t is
auto-configuring.=C2=A0 Other documents that are relevant to the ab= ove work
can also be produced. Particular emphasis will be placed
on = work needed for a Proposed Standard routing protocol, such as
ensuring m= anageability and strong security. Link metric measurement or
link metric= calculation procedures significantly more complex that
those currently = in Babel are out of scope.

Work Items:

- Produce a revision o= f RFC 6126 suitable for publication as a
Proposed Standard
-- incorpo= rate in the revision developments since RFC 6126
-- resolve technical is= sues found
-- include in the base specification the extensibility work i= n
RFC 7557
-- support auto-configuration
-- consider any important= changes based on experience with Babel to
date.

- Address securi= ty needs for BABEL. This may include using the
techniques in RFC 7298, o= r other alternatives. Security may be
included in the base spec or the b= ase spec may normatively reference a
separate Proposed Standard specific= ation. This is required as part of
moving Babel to Proposed Standard.
- Address manageability of Babel by producing an informational modelfor use by other network management such as the Broadband Forum
TR-069= , and a YANG data module based on that information model. This
YANG data= module to be consistent with the ongoing effort to use YANG
data module= s in the Routing Area. This work is required as part of
moving Babel to = Proposed Standard.

- As the Proposed Standard version of Babel is co= mpleted, an
Applicability Statement should be finalized to guide those p= otentially
interested in deploying Babel. This Applicability Statement m= ay
include deployment advice and will be published as an RFC.

- C= oordinate with other Working Groups, such as the HOMENET WG for
likely a= pplicability, the RTGWG and V6OPS WG about Source-Specific
Routing to su= pport IPv6 multihoming, the PIM WG for discussion around
multicast, and = the MANET WG for considerations around wireless.

- Liaise as necessa= ry with the Broadband Forum to facilitate use of the
Babel management I= nformation Model for TR-069.

- The Working Group should document its= ongoing implementation
experience with Babel, so that new WG participan= ts can understand the
state that is driving this work and the experience= driving changes.
This documentation may be on the Working Group's w= iki, in
an internet-draft that isn't expected to be published as an= RFC, or a
combination.

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

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

Thus,= the Working Group will produce a Proposed Standard Babel
specification,= including or paired with a suitable Proposed Standard
specification cov= ering the security mechanism(s) for BABEL. It will
also produce a manage= ment information and data model for BABEL as a
Proposed Standard RFC. An= applicability statement will be produced as
an Informational RFC.
Proposed Milestones
<= tr style=3D""><= tr style=3D"">
Date= Milestone
Aug 2017IESG Submission of Babel App= licability draft
Jul 2017IESG = Submission of Babel Management draft
Jul 2017IESG Submission of RFC6126b= is and potentially companion security mechanisms draft
Oct 2016WG adoption of Babel Management (Info Mo= del & YANG Model) draft
Jul 2016WG adoption of RFC6126bis
Jul 2016WG adoption of Babel Applicabili= ty draft=C2=A0
draft-chroboczek-babel-applicabi= lity


=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=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=3D=3D=3D


=

On Th= u, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek <jch@pps.univ-pa= ris-diderot.fr> wrote:
>= - The working group is encouraged to keep its wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz

--001a113e60bae46321053465b835-- From nobody Fri Jun 3 13:41: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 6ED3812D992; Fri, 3 Jun 2016 13:41:03 -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 CR_EVxcsuaVY; Fri, 3 Jun 2016 13:41:00 -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 431A112D975; Fri, 3 Jun 2016 13:41:00 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id c127so91319004ywb.1; Fri, 03 Jun 2016 13:41:00 -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=xIGL5MhTtPAzciHOdNC2A6fxQfxHYKhejXmLkS18hoQ=; b=zyOUrgv/N0pvV5PA16dwj+t44r+fHHXbV1qHwk88R9YEEAy8G2v23C4ApVPPaPLnsX sVy2ijZB0BJvqAxg+Lv9twou69dx3TZGDSwS17vOKv/8UpPIfIxDrnf1kGhRAErzKZJ9 45g0EC39rUgi72P+QeaIPQpgnQp+ZRTMy/Egu3uldHyH3+KocASfs5puBwrA7DpXyh3E urORnLAts9JS02qT3dLBSRZ8XqkoIVGv5lT4S6Pemqv5yLAbA0BXi8rTEBPqEm8GVgmc PiDy9orVB/1czuE9tDKjK6cVFmDgu5uD2ia+Y8FbfdR6DviLojzZSi4cOSZswWJVmyem 5N2g== 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=xIGL5MhTtPAzciHOdNC2A6fxQfxHYKhejXmLkS18hoQ=; b=RFYfzCePruq5+dpGhL2yHNzS/tiXc6g1aLnSrUpT3t7J//FXslgwVLKDdLaP33dbzG nuGAUfkNqvg0csYr5uY7COtHbas4RjRVK99F1WtXlPvIf4mG/rRnE8r8Hfcl2YRDILKj HQtEVo98gD739IDTjGMhpeuet5EWBpiA0Qkr5weGzJIE2Ii0GRTkLuEsHaBaNMoBkjsh O/0Xp/Yw/6uNq7jBQt9f9sEkb1dycuR7DAZsUlx4N6F1xzZAjJ8VHJW/9Ss2ouHeuZcv vC1yZJCzXqtRD4ER5bOmJVoXWK8ca3mvDWM3rrmGhbdDDqULDu+yV48ytHgQ5QQxRwb3 v2EA== X-Gm-Message-State: ALyK8tJG+/+Vm9o0+PrB/CfJQjeGcFUQZfyzn+ZBJPvfwGK0Xf+in4n8urssU3fRTEyVydVofMIShmoXLJBjeA== X-Received: by 10.129.109.146 with SMTP id i140mr3694052ywc.220.1464986459521; Fri, 03 Jun 2016 13:40:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.74 with HTTP; Fri, 3 Jun 2016 13:40:59 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Alia Atlas Date: Fri, 3 Jun 2016 16:40:59 -0400 Message-ID: To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a114dba2c854b7e053465bd97 Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF Subject: Re: [babel] Revised 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, 03 Jun 2016 20:41:03 -0000 --001a114dba2c854b7e053465bd97 Content-Type: text/plain; charset=UTF-8 Incidentally, https://datatracker.ietf.org/doc/charter-ietf-babel/history/ is very useful for looking at the differences between charters. Alia On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote: > Hi Donald, Russ, Juliusz, Toke, etc., > > I have read through all the discussion and IESG comments on the charter. > Here is what I have for an updated version. I do need to get it out for > External > Review soon so that it can come back onto the IESG telechat for final > approval. > The External Review is to give time for comments by those not on the IESG > or > WG - and particularly that it goes out to other organizations who might be > interested. In the case of Babel, that is relevant because of the > potential interaction > with the Broadband Forum on TR-069. > > The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I am > including the text below. > > ================================================================= > > Babel is a loop-avoiding, distance vector routing protocol with good > provisions for dynamically computed link metrics. It is robust even in > the presence of link metric oscillations and the failure of > transitivity. The core of the Babel protocol and security extensions > are described in Experimental Independent Stream RFCs 6126, 7557, and > 7298. > > These RFCs are the basis of three independent, open source > implementations. There is some production deployment of these > implementations, notably in hybrid networks (networks that include > classical, wired parts with meshy radio bits) and in global overlay > networks (networks built out of large numbers of tunnels spanning > continents). > > The Working Group will focus on moving the Babel protocol to IETF > Proposed Standard with IETF review. This includes clarifying RFC 6126 > and integrating RFC 7557 and feedback provided by independent > implementations, and resolving comments. It is not a requirement that > the Babel protocol produced is backwards compatible with RFC 6126. It > is a requirement that Babel support at least one profile that is > auto-configuring. Other documents that are relevant to the above work > can also be produced. Particular emphasis will be placed > on work needed for a Proposed Standard routing protocol, such as > ensuring manageability and strong security. Link metric measurement or > link metric calculation procedures significantly more complex that > those currently in Babel are out of scope. > > Work Items: > > - Produce a revision of RFC 6126 suitable for publication as a > Proposed Standard > -- incorporate in the revision developments since RFC 6126 > -- resolve technical issues found > -- include in the base specification the extensibility work in > RFC 7557 > -- support auto-configuration > -- consider any important changes based on experience with Babel to > date. > > - Address security needs for BABEL. This may include using the > techniques in RFC 7298, or other alternatives. Security may be > included in the base spec or the base spec may normatively reference a > separate Proposed Standard specification. This is required as part of > moving Babel to Proposed Standard. > > - Address manageability of Babel by producing an informational model > for use by other network management such as the Broadband Forum > TR-069, and a YANG data module based on that information model. This > YANG data module to be consistent with the ongoing effort to use YANG > data modules in the Routing Area. This work is required as part of > moving Babel to Proposed Standard. > > - As the Proposed Standard version of Babel is completed, an > Applicability Statement should be finalized to guide those potentially > interested in deploying Babel. This Applicability Statement may > include deployment advice and will be published as an RFC. > > - Coordinate with other Working Groups, such as the HOMENET WG for > likely applicability, the RTGWG and V6OPS WG about Source-Specific > Routing to support IPv6 multihoming, the PIM WG for discussion around > multicast, and the MANET WG for considerations around wireless. > > - Liaise as necessary with the Broadband Forum to facilitate use of the > Babel management Information Model for TR-069. > > - The Working Group should document its ongoing implementation > experience with Babel, so that new WG participants can understand the > state that is driving this work and the experience driving changes. > This documentation may be on the Working Group's wiki, in > an internet-draft that isn't expected to be published as an RFC, or a > combination. > > - As a secondary focus, the Working Group may work on multicast > aspects of Babel. This may include discussion of any potential issues > for supporting Babel running with PIM-SM in an auto-configuration > profile. It may include exploring Babel carrying separate metrics for > multicast. It may even include discussion and consultation with the PIM > WG about Babel providing the ability to build multicast routing > tables. With AD and WG agreement, once an approach is understood, > then a milestone may be added for an associated document targeted as > Proposed Standard. > > - As a secondary focus, the Working Group may work on documents > defining source specific routing extensions for Babel as a way of handling > IPv6 multihoming. > > Thus, the Working Group will produce a Proposed Standard Babel > specification, including or paired with a suitable Proposed Standard > specification covering the security mechanism(s) for BABEL. It will > also produce a management information and data model for BABEL as a > Proposed Standard RFC. An applicability statement will be produced as > an Informational RFC. > > *Proposed Milestones* > DateMilestone > Aug 2017 IESG Submission of Babel Applicability draft > Jul 2017 IESG Submission of Babel Management draft > Jul 2017 IESG Submission of RFC6126bis and potentially companion security > mechanisms draft > Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) draft > Jul 2016 WG adoption of RFC6126bis > Jul 2016 WG adoption of Babel Applicability draft > draft-chroboczek-babel-applicability > > > > ================================================================= > > > > On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < > jch@pps.univ-paris-diderot.fr> wrote: > >> > - The working group is encouraged to keep its wiki updated with >> > implementation experience with Babel so that new WG participants can >> > understand the state that is driving this work and the experience >> > driving changes. >> >> Do we really need to specify the technology used for this information? >> What about >> >> "to keep its wiki updated with implementation experience" -> "to >> maintain up-to-date, publicly accessible information about >> implementation experience" >> >> Then the WG can choose whether to do a wiki page, an internet-draft, or >> whatever else we find convenient. >> >> -- Juliusz >> > > --001a114dba2c854b7e053465bd97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Incidentally,


is very = useful for looking at the differences between charters.

Alia

On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas <akatlas@gmail.com>= wrote:
Hi Donald= , Russ, Juliusz, Toke, etc.,

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

The link is=C2=A0https://datatracker.ietf.org/doc/charter-ietf-babel/ .=C2=A0 I am = including the text below.

=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=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=3D=3D=3D

Babel is a loop-avoiding, distanc= e vector routing protocol with good
provisions for dynamically computed = link metrics. It is robust even in
the presence of link metric oscillati= ons and the failure of
transitivity. The core of the Babel protocol and = security extensions
are described in Experimental Independent Stream RFC= s 6126, 7557, and
7298.

These RFCs are the basis of three indepen= dent, open source
implementations. There is some production deployment o= f these
implementations, notably in hybrid networks (networks that inclu= de
classical, wired parts with meshy radio bits) and in global overlaynetworks (networks built out of large numbers of tunnels spanning
cont= inents).

The Working Group will focus on moving the Babel protocol t= o IETF
Proposed Standard with IETF review.=C2=A0 This includes clarifyin= g RFC 6126
and integrating RFC 7557 and feedback provided by independent=
implementations, and resolving comments. It is not a requirement thatthe Babel protocol produced is backwards compatible with RFC 6126.=C2=A0 = It
is a requirement that Babel support at least one profile that is
a= uto-configuring.=C2=A0 Other documents that are relevant to the above work<= br>can also be produced. Particular emphasis will be placed
on work need= ed for a Proposed Standard routing protocol, such as
ensuring manageabil= ity and strong security. Link metric measurement or
link metric calculat= ion procedures significantly more complex that
those currently in Babel = are out of scope.

Work Items:

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

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

- Ad= dress manageability of Babel by producing an informational model
for use= by other network management such as the Broadband Forum
TR-069, and a Y= ANG data module based on that information model. This
YANG data module t= o be consistent with the ongoing effort to use YANG
data modules in the = Routing Area. This work is required as part of
moving Babel to Proposed = Standard.

- As the Proposed Standard version of Babel is completed, = an
Applicability Statement should be finalized to guide those potentiall= y
interested in deploying Babel. This Applicability Statement may
inc= lude deployment advice and will be published as an RFC.

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

- Liaise as necessary with t= he Broadband Forum to facilitate use of the
Babel management Informatio= n Model for TR-069.

- The Working Group should document its ongoing = implementation
experience with Babel, so that new WG participants can un= derstand the
state that is driving this work and the ex= perience driving changes.
This documentation may be on the Workin= g Group's wiki, in
an internet-draft that isn't expected to be = published as an RFC, or a
combination.

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

- As a sec= ondary focus, the Working Group may work on documents
defining source sp= ecific routing extensions for Babel as a way of handling
IPv6 multihomin= g.

Thus, the Working Group will produce a Proposed Standard Babelspecification, including or paired with a suitable Proposed Standard
sp= ecification covering the security mechanism(s) for BABEL. It will
also p= roduce a management information and data model for BABEL as a
Proposed S= tandard RFC. An applicability statement will be produced as
an Informati= onal RFC.

Proposed Milestones
<= /tr>
DateMilestone
Aug 2017IESG Submission of Babel Appli= cability draft
Jul 2017IESG Submission of Babel Mana= gement draft
Jul 2017IESG Submission of RFC6126bis and potentially companion securi= ty mechanisms draft
Oct 2016WG adoption of Babel Man= agement (Info Model & YANG Model) draft
Jul 2016WG adoption of RFC6126bis
Jul 2016WG adoption of Babel Applicability draft=C2=A0draft-chroboczek-babel-applicability

=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=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=3D=3D=3D



<= div class=3D"gmail_quote">On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chrobocze= k <jch@pps.univ-paris-diderot.fr> wrote:
> - The working group is encouraged to keep i= ts wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz


--001a114dba2c854b7e053465bd97-- From nobody Fri Jun 3 14:27:10 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 4FC5012D9BD; Fri, 3 Jun 2016 14:27:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603212706.1430.76805.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 14:27:06 -0700 Archived-At: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, akatlas@gmail.com Subject: [babel] babel - Update to a Meeting Session Request for IETF 96 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: Fri, 03 Jun 2016 21:27:06 -0000 An update to a meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: rtgwg idr isis lpwan saag trill homenet ospf manet 6man dnssd v6ops i2rs netmod netconf Second Priority: dnsop Special Requests: --------------------------------------------------------- From nobody Fri Jun 3 17:23: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 E015012D09B for ; Fri, 3 Jun 2016 17:23:52 -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 wfxoQkFUKc-A for ; Fri, 3 Jun 2016 17:23: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 DC89F12B00F for ; Fri, 3 Jun 2016 17:23:50 -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 u540NmUg028480; Sat, 4 Jun 2016 02:23:48 +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 68F9961FA7; Sat, 4 Jun 2016 02:23:48 +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 PNBExrO2-FPs; Sat, 4 Jun 2016 02:23:47 +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 5F42561FA5; Sat, 4 Jun 2016 02:23:44 +0200 (CEST) Date: Sat, 04 Jun 2016 02:23:44 +0200 Message-ID: <87d1nx7qen.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: <7i7fe7uy8a.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]); Sat, 04 Jun 2016 02:23:48 +0200 (CEST) X-Miltered: at korolev with ID 57521F94.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57521F94.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 : 57521F94.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 at IETF Subject: Re: [babel] What to do about extension drafts? 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, 04 Jun 2016 00:23:53 -0000 > I take this to mean that we don't touch the source-specific extension > draft, and ask for adoption once the WG is formed. Great. > Be prepared for some coordination with RTGWG around the source-dest routing > work. Excellent, I'm looking forward to that. > The draft-jonglez-babel-rtt-extension seems to fall into the defining at > least one mandatory metric scheme. It should perhaps not be mandatory (it's not completely trivial to implement, since it requires some careful timing), but I'm glad you think that it might fall under the aegis of the WG. I'll wait, then. -- Juliusz From nobody Fri Jun 3 17: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 26D8712D19F for ; Fri, 3 Jun 2016 17:52:24 -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 514M4z6yAwbG for ; Fri, 3 Jun 2016 17:52:22 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 8990712B05D for ; Fri, 3 Jun 2016 17:52:22 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h19so95726053ywc.0 for ; Fri, 03 Jun 2016 17:52:22 -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=SuazfOAOvMrFr7n6AzTEBWycqrrTcilisOGZFO7wIJk=; b=NwhChnbyFs/Wcx5f4QVTLcRdqvoMoWAAJSKwCg0Y44y+xHPTGX4u/JJPA3ZKbKSMfT XrF8JnsxWXIVpW9aujoecx3sxigsKsJZ4VxMaI9BE7gRlfp8qA0MJC0cWS54t9xL0r8t 1DNnxDCHMsPikm1RwrUIpO7z4mEyng8j+YqFIQlUEkXDbyPTINYIx21uMo6YiR4nSEQw LZYKUvLgwqqmu4SU3kpIZUklZIRJ76vEMiKlM47obdFith1p0BZFASK9ocKkgRBfUNNI NCxBCJfCe77oiwyhXAUouZZwQloz6Kfl5bhBvkRxv/gfuVeNpqJO7CyHeWiGhXoXdPHm HEgg== 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=SuazfOAOvMrFr7n6AzTEBWycqrrTcilisOGZFO7wIJk=; b=V1SXtILgGAPN+zaTR0eot12JIOKDNIwjL7QfOIgA+WOYXV3RmXKuu1t+MOi/SjXTWY zIZ6tm0JZm/YTs+AgBj1MMpKbB4M7p3NpKPpo5osZjEQqMtKKvrNMMcTfdO6Ve4zXWzW zKtOdTE7OehmjoUDZZmkOvM0mCb4jQE211FcBe9JQyd7V7+lSzU0g/ke0suwG6nV+3J4 Fd6LHYxh2nZpDh9QpIaeQfOspKZ/JYVniY2xycGMKwllplijWlGiYPHJOGA7alIiXosq KDSYoV1/CPe2Nfkyd9UONZY/5gmjH+jyz9SnXgAwol70zBxtDyeUokNyeF1K7D2aP8EF R7bA== X-Gm-Message-State: ALyK8tKkl1cDbkOxRGyZVI6QBl89i0ptIvbQEWQRNvpefSxLaTTtRax1VBG5a5GeuBT7fan2S2PwTMyTlOfXIg== MIME-Version: 1.0 X-Received: by 10.129.109.146 with SMTP id i140mr4267562ywc.220.1465001541838; Fri, 03 Jun 2016 17:52:21 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Fri, 3 Jun 2016 17:52:21 -0700 (PDT) Received: by 10.13.221.74 with HTTP; Fri, 3 Jun 2016 17:52:21 -0700 (PDT) In-Reply-To: <87d1nx7qen.wl-jch@pps.univ-paris-diderot.fr> References: <7i7fe7uy8a.wl-jch@pps.univ-paris-diderot.fr> <87d1nx7qen.wl-jch@pps.univ-paris-diderot.fr> Date: Fri, 3 Jun 2016 20:52:21 -0400 Message-ID: From: Alia Atlas To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a114dba2c7f2e570534694025 Archived-At: Cc: Babel at IETF Subject: Re: [babel] What to do about extension drafts? 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, 04 Jun 2016 00:52:24 -0000 --001a114dba2c7f2e570534694025 Content-Type: text/plain; charset=UTF-8 On Jun 3, 2016 8:23 PM, "Juliusz Chroboczek" wrote: > > > I take this to mean that we don't touch the source-specific extension > > draft, and ask for adoption once the WG is formed. Great. > > > Be prepared for some coordination with RTGWG around the source-dest routing > > work. > > Excellent, I'm looking forward to that. > > > The draft-jonglez-babel-rtt-extension seems to fall into the defining at > > least one mandatory metric scheme. > > It should perhaps not be mandatory (it's not completely trivial to > implement, since it requires some careful timing), but I'm glad you think > that it might fall under the aegis of the WG. Right. Metrics, at least not too complicated ones, are in scope. I want implying that this one would be mandatory. > I'll wait, then. Sounds good. Any freddy's on the revised charter? > -- Juliusz > > > > --001a114dba2c7f2e570534694025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jun 3, 2016 8:23 PM, "Juliusz Chroboczek" <jch@pps.univ-paris-diderot.fr> wrot= e:
>
> >=C2=A0 =C2=A0 =C2=A0I take this to mean that we don't touch th= e source-specific extension
> >=C2=A0 =C2=A0 =C2=A0draft, and ask for adoption once the WG is for= med. Great.
>
> > Be prepared for some coordination with RTGWG around the source-de= st routing
> > work.
>
> Excellent, I'm looking forward to that.
>
> > The draft-jonglez-babel-rtt-extension seems to fall into the defi= ning at
> > least one mandatory metric scheme.
>
> It should perhaps not be mandatory (it's not completely trivial to=
> implement, since it requires some careful timing), but I'm glad yo= u think
> that it might fall under the aegis of the WG.

Right.=C2=A0 Metrics, at least not too complicated ones, are= in scope.=C2=A0 I want implying that this one would be mandatory.

> I'll wait, then.

Sounds good.=C2=A0 Any freddy's on the revised charter? =

> -- Juliusz
>
>
>
>

--001a114dba2c7f2e570534694025-- From nobody Fri Jun 3 23:53: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 A1E2312D0AD for ; Fri, 3 Jun 2016 23:53:48 -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 9P9Q8eTwOOp1 for ; Fri, 3 Jun 2016 23:53:47 -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 D5E6C12B069 for ; Fri, 3 Jun 2016 23:53:46 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id a136so23463367wme.0 for ; Fri, 03 Jun 2016 23:53:46 -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=n+M5RfHXPPzHVRE5uKmeMboCI1KbqfYUQjBKOz/89ng=; b=gP17KybHR/1PWvSlpELhGM0vwo+8V5D1Q7nZ/HkQ2X8WGtStauQ1jmqkSObOQgTxRS YLBaQNgYtBrHTgQ9XcvsKEtiCDLShxnl7qKR0XuRRjtKkYy0k/eLtfzuz+OZIRElvw4/ Uc7AAqV1t61PE+gF4mTWEJqqJDGZ/jCJTs8GDqDs17Z26/DdngNYizOvVsOB9nWOIDIo 3Qgk+nh8msdgT1mYG14u+8sf915EGHv73jVkeY09NfLnl03SPBjN++mvejELuJiqEBHF q8hY0YsyuG+QeUfie+kvK32zihqNlux/NPq6GHEbLXhlU3d17DE6E/vVymTYgFDxKQEv COxA== 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=n+M5RfHXPPzHVRE5uKmeMboCI1KbqfYUQjBKOz/89ng=; b=iCIaoROsCv9xpkHVTqwTxFhNzgorrzHdF6zgXj1RPB3ztEdj9Wx5Imia7HIIuXKYlm XsRTr1vGUXDSGO6t/FmUp2+p2aWiDES3hmfympu6Eg2GNMvb66p2+QyaZJrSYaXhaAxA XTg9L0WXeSd3clHTd2DV1ZgvdCXNmKDp969BiIvWB0NUcNEey1TW7WXq4EtXWk/FUnay jpF7Fb9NgqHo0tayAnhSSzZUacYmCNhqOWqD9tAY6wrFoRK0gaWzwzsZXcAqu5Jcvuoy 7Meciq/XQ2D8EFFDwYimQN2WJlzoBk4+4eLvMgmArYy6HPdO1m5WYHrJqrri/DM1D4YL shZA== X-Gm-Message-State: ALyK8tIxmSu1wx+bmxvGFTGY6GbeQbdw9MkwgjAFCAlEQEqVXjFKINOEQr37vhdy1nPCXQ== X-Received: by 10.28.10.65 with SMTP id 62mr2534320wmk.81.1465023224680; Fri, 03 Jun 2016 23:53:44 -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 d4sm9167894wjk.11.2016.06.03.23.53.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 23:53:43 -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: Date: Sat, 4 Jun 2016 08:53:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E27F4F6-BC77-4F96-9FB8-701F1FBBFD13@inf-net.nl> References: <7i7fe7uy8a.wl-jch@pps.univ-paris-diderot.fr> <87d1nx7qen.wl-jch@pps.univ-paris-diderot.fr> To: Alia Atlas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] What to do about extension drafts? 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, 04 Jun 2016 06:53:48 -0000 >=20 > Op 4 jun. 2016, om 02:52 heeft Alia Atlas het = volgende geschreven: >=20 /// > Any freddy's on the revised charter? I'm quite happy with the progress being made. I'm in favor having source specific routing a more than a secondary = focus. HOMENET relies on that it is out there. Let's do it right and = quick. I prefer it is part of the core protocol and not an extension. Teco= From nobody Sat Jun 4 08:15:34 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 6567912D146; Sat, 4 Jun 2016 08:15:28 -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 ZD0DN1lpXnEM; Sat, 4 Jun 2016 08:15:26 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 8486F12D1A9; Sat, 4 Jun 2016 08:15:24 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id w184so168593078oiw.2; Sat, 04 Jun 2016 08:15:24 -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:content-transfer-encoding; bh=WXGWajhvBBPgSXURRasotQ50MrlHbjZGm2J/LxuplOo=; b=zakiK3uEjUTlJ4Qdk24QFVbdrJ+w2v0LCbLl6S5/yNwKZJ3ZHwc/+A79/jDpVkeSEf 6219HRExaUnHiITQA67zKq2TVWGJgXAC2JTJEt0OJLIooDKXCUbMZX4FyrWZwG1KqM2I TUlef0/4+ET5ObnziOnkiMmigPNxVugJiEfxA0Eca/BXw05J0rEEJyM3IAOXPyQRcxoG Vx1ZtlIL0zrVNSG4NkaoSNASzpv7axGz9pOtq7O7mWpEnzcRvKHou9tdYPuhO4L6W5GC 0YRAQDuNoYF0YAFxrx1ECU50e/Yx25ahAc0lOOU60agmUPDyOR1hCvv9BBWh8XWWH3Kq StTA== 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:content-transfer-encoding; bh=WXGWajhvBBPgSXURRasotQ50MrlHbjZGm2J/LxuplOo=; b=ZhXJY6DXRA2nwAiHb8xothJuuoVNywcPfQUlg0Gt8Ua4JqleOOSO3+p8aoOZLCLRQu LILFS0QODwOMlifDAiWL2+sJ2kJSACjZjeFABwWfUU1CGFuN0LCKzZNXpjYNWlzVtwhs s22d3w1tI3LEcRPmZbm6DcMtWToTqj7YBFf7NvxJ8LayDhTXmNY3/iYr66qKsYztER9e iePOCNTnO8EiGQJvEHaPqMXXzPCO1kaksV2WkiPZC+6BssO+pR39Fa/+UomfmbOOX+nf ObAeOuV0c5XLummJyKGJjTsYAGC03CYXyyyFo+W1OsXz15Ei3h0Qq+BpLs7OPPLv4Xeq vydQ== X-Gm-Message-State: ALyK8tLVG3wWbJdFjtQyJUb67US2pLnDaD4nGKk6KA38y0xCnoVDQvhfBsR0PhSjUEOyPP6/G7mBkyYoQdHUZA== X-Received: by 10.202.186.193 with SMTP id k184mr4943089oif.66.1465053323816; Sat, 04 Jun 2016 08:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Sat, 4 Jun 2016 08:15:23 -0700 (PDT) In-Reply-To: References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> From: Dave Taht Date: Sat, 4 Jun 2016 08:15:23 -0700 Message-ID: To: Suresh Krishnan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "babel-chairs@ietf.org" , Pierre Pfister , The IESG , "babel@ietf.org" , Pierre Pfister Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 04 Jun 2016 15:15:28 -0000 On Thu, Jun 2, 2016 at 8:47 PM, Suresh Krishnan wrote: > Hi Dave, > > On 06/02/2016 11:03 AM, Dave Taht wrote: > > On Wed, Jun 1, 2016 at 6:34 PM, Suresh Krishnan > > wrote: > >> Suresh Krishnan 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 th= is > >> introductory paragraph, however.) > >> > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/charter-ietf-babel/ > >> > >> > >> > >> ---------------------------------------------------------------------= - > >> COMMENT: > >> ---------------------------------------------------------------------= - > >> > >> * There is no mention of backward compatibility in the charter. Is th= e > >> "new" Babel intended to be backward compatible with the deployed > >> experimental version(s)? Might be worth noting either way. > > > > I tend to think making an entirely incompatible version would be a > > kiss of death. > > > > On the other hand, there are a metric ton of other problems I'd like > > to be solving. (see below) > > > > On the gripping hand, merely getting a "rip replacement" routinely > > shipping and regularly available would be nice. > > > >> * One of the potential (and I personally think one of the most import= ant) > >> uses of Babel is as a routing protocol in homenets. Two of the things > >> that seem to be interesting improvements to Babel for this use case s= eem > >> to be a)self-configuration and b)source-specific routing. I do not se= e > >> either of them in the charter. I would have really liked to see somet= hing > >> in the charter to address these two issues. > > > > a) self-configuration should be hardened, agreed. I saw an interesting > > new approach in bmx7 the other day... > > > > http://bmx6.net/news/22 > > > > ... > > > > Not entirely relevant to the formation of this wg, but stuff I wish > > had homes elsewhere (do they? most of my issues tend to cross layers > > these days): > > Interesting read. Thanks for that pointer. > > > > > b) I'd like to see source specific routing widely available in all > > routing protocols. I'd even like to see an extension to RA. > > Something like this? > > https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01 Is the expired state of that draft an indicator that it died? Getting an implementation that worked did strike me as very little code, which I'd gladly patch in if it existed somewhere. > > > > > c) It is not just a homenet thing to want ethernet, homeplug, wifi, > > 5g, 6lopan, etc, interoperating well with different isps and devices. > > > > I'd like to see more interoperable interfaces to other link layers > > (6lowpan/threads, usb, can, 802.11ad, 5g, homeplug, etc), be they > > routing, failure mode detection, address assignment, security, or > > service advertisement. > > > > In particular, I could see usb-c one day becoming a short haul > > ethernet replacement if it spoke IP well and universally, and the tv > > becoming the network center of the home... I don't know where > > HDMI-ethernet went wrong... > > > > (I routinely use babel to route between wifi, ethernet, and usbnet > > "gadget"s today - modern hackerboards like the pi, and getchip.com > > etc, all have this basic support, and many hackerboards are arriving > > that speak usb and wifi only - and lack ethernet. ) > > Cool. > > Thanks > Suresh > > > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Sat Jun 4 08:52: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 DC8EE12D152 for ; Sat, 4 Jun 2016 08:52:21 -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 3GGE_SZ-SMs4 for ; Sat, 4 Jun 2016 08:52:19 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 31649128E19 for ; Sat, 4 Jun 2016 08:52:19 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w184so169390181oiw.2 for ; Sat, 04 Jun 2016 08:52:19 -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:cc :content-transfer-encoding; bh=86quavPebjey2SSex7TwRoNxvULY5b9R6AkXonI48cQ=; b=nMxsfBpcKvLVbD+PFecNRBE3SEPgUkd4IIyBBHADUqeogPLhp66AhM+6sd1410yRn9 Q5n8VmgpYExi+WFeIPRmS7HYLbEL80o2s2AGUutUyRH1cmrbsPNoonGoyeKneywCLhNt yAsgXC2dSx6cD0MZyIv0QZndRIpL5IqE+J19IOzg9UI9bereunoj3VhZQQhbGTK4000J bC9Cqs6AvGc41ce9ihEt+UFKpGg0ZAei7VVoL6F0u/yutPg/CceerBNeLewT+tSHQgRz M/SYQpptPgwhsI8k6GUXw2WLAYtggvNXvjkEL4LiE0b3Vo4euUeZjl0TrmY4B6MLcIde T1eQ== 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:cc :content-transfer-encoding; bh=86quavPebjey2SSex7TwRoNxvULY5b9R6AkXonI48cQ=; b=l3y2FMQML8gF3i1G1tCW5qrgzGSv8XRs48bh1MwO/SDsP+xo9YWjIslgJJzl6KvvDD qb9ZxCvMUkngdyYrGOjN4RG9AYMyhdFYgySOaCNsfFFq3UUfIs7bgWoDZSL1F43PIn1Y HRqH0BgpkS32Y5w9DLIf2DKs5xsvnlqv/+JzrfdQWROyLygaT7SNRfm1FeTEH8KzBY3i E56a7ZN6l8n7re+cqyCWc3A6u1v3KzYtkKCLTFXw2eaheycofZJzGPMY4SzyLGHNiEFS QrYiM1tD6AbWmrrlI96e7OL5JZiFYhCMQ/HbR7X7sFvzAvMyHRGvn7g7Fj/2fsHntj9z UBOQ== X-Gm-Message-State: ALyK8tIgpaqntkNkOaDCeRJ1XrmNPDOl3OYLaCNQ7HbgDiawYf5qA6ehAsF7IxA7nIB/2eMDP7RPJNuXs0qkAA== X-Received: by 10.157.9.226 with SMTP id 31mr5016211otz.165.1465055538547; Sat, 04 Jun 2016 08:52:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Sat, 4 Jun 2016 08:52:17 -0700 (PDT) From: Dave Taht Date: Sat, 4 Jun 2016 08:52:17 -0700 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: babel@ietf.org Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 04 Jun 2016 15:52:22 -0000 On Thu, Jun 2, 2016 at 11:33 AM, Juliusz Chroboczek wrote: >> I tend to think making an entirely incompatible version would be a >> kiss of death. > > Not necessarily if the implementation speaks both versions, at least > initially. (To be clear -- I sort of agree with you, but try to keep an > open mind.) > > (OTOH, I'm increasingly thinking I'm going to redo source-specific routin= g > in an inompatible manner. I'll write up my thoughts on babel-users.) > >> On the gripping hand, merely getting a "rip replacement" routinely >> shipping and regularly available would be nice. > > Yes. Let's be careful to keep the spec simple. (Defined as "fits in the > head of a third year student without swapping".) > >> a) self-configuration should be hardened, agreed. > > I'm surprised to hear that from you. I said "self-configuration should be hardened". It was not entirely related to router_id generation, which may well be robust enough. (proof that stuff came from a given router_id is not as yet - (see C, below). Most of my issues tend to cross layers these days... To give three examples of things that make me mildly crazy. I wish I'd been paying attention to the evolution of some ipv6 thinking long, long ago. If there is a place on a wiki for stuff like this... or elsewhere? A) Why can you preserve from what source a route came from but not where an address came from? ip route add fd01::/64 dev eth0 proto static # boot, dhcp, babel, quagga, whatever and not ip addr add fd01::1/64 dev eth0 proto dhcp # hncp, static, 6to4, SLAAC, privacy, somevpn, etc B) The tyranny of the default route Everywhere I go I turn off the default route supplied by dhcp whenever I can. Sometimes that is the wrong thing - one source specific network I have (3 exit nodes) has gateways perpetually putting in a babel default route in (to some other device already up) long before it's external interface to the world fetches an address and a good default route. source specific routing saves the day on ipv6, but the ipv4 dhcp supplied default route fails to insert in the race. C) Security I would like to be able to have a basic secured "core" network, and unsecured leafs (and new as yet to be configured boxes) allowed to announce their existence, listen and do some limited routing themselves - but not provide default routes, or anything at all that overrides the secured routes. This partially permissionless innovation would make the local routing I do - to usbnet from any given host - "just work" for anything that wants to see that sort of resource on the network. Same goes for a lightbulb announcing itself... (and was why I so liked that bmx7 paper) > You've been running a production > Babel network for years, Dave, and providing me with useful bug reports, > but I don't recall you having issues with router-id collisions. (See my > reply to Tony.) I got my first ones last month when I tested some of toke's bird patches on arm, where there was some alignment issue (?) causing the router_id generation to fail to 0. The results were "interesting". I have not poked into it again since getting back from vacation. Good description to tony... (but see comments above) I have long planned to write up the deployment experiences (lessons learned) I've had thus far with multiple wireless-related routing protocols in difficult layer-2 environments and 3rd world conditions, starting with 802.11s... I have notes and logs all over the place for that (10 years worth), and I think I'd have to write it all out (sigh) to figure out what was most important. One of the consistent errors I've done for myself is providing a persistent default route to somewhere that isn't working right... still the most important thing to me right now is to get wifi's per station behavior and fq/aqm stuff fixed, and after that worry about how the routing protocol(s) work on top of that. >> b) I'd like to see source specific routing widely available in all >> routing protocols. I'd even like to see an extension to RA. > > Rtgwg, I believe. I'm pretty confident the RA extension will happen. > >> I'd like to see more interoperable interfaces to other link layers >> (6lowpan/threads, usb, can, 802.11ad, 5g, homeplug, etc), be they >> routing, failure mode detection, address assignment, security, or >> service advertisement. > > I'm pessimistic. You!?? (I am too) > > -- Juliusz --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Sat Jun 4 09:37:43 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 67C9C12D528 for ; Sat, 4 Jun 2016 09:37:42 -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 5DBc-tq3APJr for ; Sat, 4 Jun 2016 09:37:40 -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 17EC812D517 for ; Sat, 4 Jun 2016 09:37:39 -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 u54Gbc3u018509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Jun 2016 18:37:38 +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 u54GbbMC025565; Sat, 4 Jun 2016 18:37:37 +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 A6ABC61FA7; Sat, 4 Jun 2016 18:37:37 +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 ZxrbZsqrhV8x; Sat, 4 Jun 2016 18:37:36 +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 3F4B461FA5; Sat, 4 Jun 2016 18:37:36 +0200 (CEST) Date: Sat, 04 Jun 2016 18:37:37 +0200 Message-ID: <87a8j0j4fi.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 [IPv6:2001:660:3301:8000::1:2]); Sat, 04 Jun 2016 18:37:38 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 04 Jun 2016 18:37:37 +0200 (CEST) X-Miltered: at korolev with ID 575303D2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 575303D1.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 575303D2.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 575303D1.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 : 575303D2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 575303D1.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: babel@ietf.org Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 04 Jun 2016 16:37:42 -0000 > ip addr add fd01::1/64 dev eth0 proto dhcp # hncp, static, 6to4, > SLAAC, privacy, somevpn, etc That's a good point, but it's a purely local Linux issue (it's not visible on the wire). I'd certainly use such an interface in shncpd. Speak to netdev, perhaps? > but the ipv4 dhcp supplied default route fails to insert in the race. Babeld supports source-specific routing for IPv4. Insert the right source-specific route for IPv4, and it will be more specific than the default route. You'll want to speak to Matthieu, or to babel-users. -- Juliusz From SRS0=h1pR=R5=darou.fr=pierre.pfister@bounces.m4x.org Sun Jun 5 02:28: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 12AEB12D0A6; Sun, 5 Jun 2016 02:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 AcvFh6fFUIFx; Sun, 5 Jun 2016 02:27:57 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B84C12B027; Sun, 5 Jun 2016 02:27:56 -0700 (PDT) Received: from dhcp-10-61-104-8.cisco.com (unknown [173.38.220.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 658EE564D87; Sun, 5 Jun 2016 11:27:53 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_16CB8A12-F5A4-4DB7-81F5-64364A76DB69" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pierre Pfister In-Reply-To: Date: Sun, 5 Jun 2016 11:27:53 +0200 Message-Id: <2CABD72C-A8CA-4B1D-8015-D7D6E7131A89@darou.fr> References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> To: Dave Taht X-Mailer: Apple Mail (2.3124) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Sun Jun 5 11:27:54 2016 +0200 (CEST)) Archived-At: Cc: "babel-chairs@ietf.org" , Suresh Krishnan , "babel@ietf.org" , The IESG Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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: Sun, 05 Jun 2016 09:37:49 -0000 --Apple-Mail=_16CB8A12-F5A4-4DB7-81F5-64364A76DB69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Dave, > Le 4 juin 2016 =C3=A0 17:15, Dave Taht a =C3=A9cri= t : >=20 > On Thu, Jun 2, 2016 at 8:47 PM, Suresh Krishnan > > = wrote: >> Hi Dave, >>=20 >> On 06/02/2016 11:03 AM, Dave Taht wrote: >>> On Wed, Jun 1, 2016 at 6:34 PM, Suresh Krishnan >>> wrote: >>>> Suresh Krishnan has entered the following ballot position for >>>> charter-ietf-babel-00-02: No Objection >>>>=20 >>>> 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.) >>>>=20 >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/charter-ietf-babel/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> * There is no mention of backward compatibility in the charter. Is = the >>>> "new" Babel intended to be backward compatible with the deployed >>>> experimental version(s)? Might be worth noting either way. >>>=20 >>> I tend to think making an entirely incompatible version would be a >>> kiss of death. >>>=20 >>> On the other hand, there are a metric ton of other problems I'd like >>> to be solving. (see below) >>>=20 >>> On the gripping hand, merely getting a "rip replacement" routinely >>> shipping and regularly available would be nice. >>>=20 >>>> * One of the potential (and I personally think one of the most = important) >>>> uses of Babel is as a routing protocol in homenets. Two of the = things >>>> that seem to be interesting improvements to Babel for this use case = seem >>>> to be a)self-configuration and b)source-specific routing. I do not = see >>>> either of them in the charter. I would have really liked to see = something >>>> in the charter to address these two issues. >>>=20 >>> a) self-configuration should be hardened, agreed. I saw an = interesting >>> new approach in bmx7 the other day... >>>=20 >>> http://bmx6.net/news/22 >>>=20 >>> ... >>>=20 >>> Not entirely relevant to the formation of this wg, but stuff I wish >>> had homes elsewhere (do they? most of my issues tend to cross layers >>> these days): >>=20 >> Interesting read. Thanks for that pointer. >>=20 >>>=20 >>> b) I'd like to see source specific routing widely available in all >>> routing protocols. I'd even like to see an extension to RA. >>=20 >> Something like this? >>=20 >> https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01 >=20 > Is the expired state of that draft an indicator that it died? >=20 > Getting an implementation that worked did strike me as very little > code, which I'd gladly patch in if it existed somewhere. I did implemented it, and it was very little changes in the kernel (<100 = LoC). I can try to dig that out if it helps you. This draft started as an alternative to = https://www.ietf.org/archive/id/draft-sarikaya-6man-sadr-ra-03.txt. But I received push-backs due to on-wire changes in my proposal. 6man chairs asked Brian to propose a solution without on-wire changes: = https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf Then, Fred accepted to draft such an option, which has now become this: = https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-06 So I guess unless the working group comes to a conclusion that a = protocol change is required in order to address the problem, the draft = is effectively dead. Cheers, - Pierre >=20 >>=20 >>>=20 >>> c) It is not just a homenet thing to want ethernet, homeplug, wifi, >>> 5g, 6lopan, etc, interoperating well with different isps and = devices. >>>=20 >>> I'd like to see more interoperable interfaces to other link layers >>> (6lowpan/threads, usb, can, 802.11ad, 5g, homeplug, etc), be they >>> routing, failure mode detection, address assignment, security, or >>> service advertisement. >>>=20 >>> In particular, I could see usb-c one day becoming a short haul >>> ethernet replacement if it spoke IP well and universally, and the tv >>> becoming the network center of the home... I don't know where >>> HDMI-ethernet went wrong... >>>=20 >>> (I routinely use babel to route between wifi, ethernet, and usbnet >>> "gadget"s today - modern hackerboards like the pi, and getchip.com >>> etc, all have this basic support, and many hackerboards are arriving >>> that speak usb and wifi only - and lack ethernet. ) >>=20 >> Cool. >>=20 >> Thanks >> Suresh >>=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org --Apple-Mail=_16CB8A12-F5A4-4DB7-81F5-64364A76DB69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Dave,

Le = 4 juin 2016 =C3=A0 17:15, Dave Taht <dave.taht@gmail.com>= a =C3=A9crit :

On Thu, Jun 2, 2016 at 8:47 PM, Suresh = Krishnan
<suresh.krishnan@ericsson.com> wrote:
Hi Dave,

On 06/02/2016 = 11:03 AM, Dave Taht wrote:
On Wed, Jun 1, 2016 at 6:34 PM, Suresh Krishnan
<suresh.krishnan@ericsson.com> wrote:
Suresh Krishnan 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:
---------------------------------------------------------------= -------

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

I tend to think making an = entirely incompatible version would be a
kiss of death.

On the other hand, there are a metric ton of = other problems I'd like
to be solving. (see below)

On the gripping hand, merely getting a "rip = replacement" routinely
shipping and regularly available = would be nice.

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

a) self-configuration = should be hardened, agreed. I saw an interesting
new = approach in bmx7 the other day...

http://bmx6.net/news/22
...

Not entirely = relevant to the formation of this wg, but stuff I wish
had = homes elsewhere (do they? most of my issues tend to cross layers
these days):

Interesting read. Thanks for that pointer.


b) =  I'd like to see source specific routing widely available in all
routing protocols. I'd even like to see an extension to = RA.

Something like this?

https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01

Is the expired state of that draft an = indicator that it died?

Getting an implementation that worked did strike = me as very little
code, which I'd gladly patch in if it existed = somewhere.

I did = implemented it, and it was very little changes in the kernel (<100 = LoC).
I can try to dig that out if it helps you.

But I received push-backs due to on-wire changes in = my proposal.
6man chairs asked Brian to propose a solution = without on-wire changes: https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf=
Then, Fred accepted to draft such an option, which has = now become this: https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-06=

So I guess unless the working = group comes to a conclusion that a protocol change is required in order = to address the problem, the draft is effectively dead.

Cheers,

- = Pierre




c) It is = not just a homenet thing to want ethernet, homeplug, wifi,
5g, 6lopan, etc, interoperating well with different isps and = devices.

I'd like to see more interoperable = interfaces to other link layers
(6lowpan/threads, usb, = can, 802.11ad, 5g, homeplug, etc), be they
routing, = failure mode detection, address assignment, security, or
service advertisement.

In = particular, I could see usb-c one day becoming a short haul
ethernet replacement if it spoke IP well and universally, and = the tv
becoming the network center of the home... I don't = know where
HDMI-ethernet went wrong...

(I routinely use babel to route between wifi, ethernet, and = usbnet
"gadget"s today - modern hackerboards like the pi, = and getchip.com
etc, all have this basic support, and many hackerboards are = arriving
that speak usb and wifi only - and lack ethernet. = )

Cool.

Thanks
Suresh






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

= --Apple-Mail=_16CB8A12-F5A4-4DB7-81F5-64364A76DB69-- From nobody Sun Jun 5 07:03:00 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 D81BA12B033; Sun, 5 Jun 2016 07:02: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 XFFprmIUwtlt; Sun, 5 Jun 2016 07:02: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 9250512B02C; Sun, 5 Jun 2016 07:02:51 -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 u55E2mRq032225; Sun, 5 Jun 2016 16:02:48 +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 4A09E61F9A; Sun, 5 Jun 2016 16:02:48 +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 5ZETU8T3dMqH; Sun, 5 Jun 2016 16:02:46 +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 8017161FA7; Sun, 5 Jun 2016 16:02:46 +0200 (CEST) Date: Sun, 05 Jun 2016 16:02:48 +0200 Message-ID: <87shwr7myf.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Suresh Krishnan" In-Reply-To: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> References: <20160602013442.16179.56150.idtracker@ietfa.amsl.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]); Sun, 05 Jun 2016 16:02:48 +0200 (CEST) X-Miltered: at korolev with ID 57543108.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57543108.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 : 57543108.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-chairs@ietf.org, The IESG , babel@ietf.org Subject: Re: [babel] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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: Sun, 05 Jun 2016 14:02:54 -0000 > * There is no mention of backward compatibility in the charter. Is the > "new" Babel intended to be backward compatible with the deployed > experimental version(s)? Might be worth noting either way. I've been refraining from answering this point, since I wanted to hear people's opinions. I guess the discussion has died now. The answer is -- we haven't decided yet. On the one hand, there are some improvements that we could make if we decide to be incompatible (notably adding a mandatory bit to sub-TLVs and making metrics wider -- they're currently 16 bits). On the other hand, making an incompatible version will be an inconvenience for our current users (Dave goes so far as to speak of a "kiss of death"), and runs the risk of not being able to decide on the right bikeshed colour. My current opinion -- likely to change as we discuss stuff some more -- is that the base protocol should remain compatible, but we'll want to make an incompatible (and much better) encoding for the source-specific routing extension. However, I am listening to people who think otherwise, especially if they have implementation experience. Please note that keeping the packet format compatible doesn't mean we cannot make changes to the protocol that are technically incompatible -- we can tighten the specification, and we can remove undesirable features as long as we mark the removed codepoints as reserved for backwards compatibility. (For example, I'm considering removing AE 0, but implementations will be free to continue implementing it indefinitely.) -- Juliusz From nobody Sun Jun 5 10:18: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 E8CAD12D0B2 for ; Sun, 5 Jun 2016 10:18: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 L8kZbxzC40Th for ; Sun, 5 Jun 2016 10:18:28 -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 A10CE12B040 for ; Sun, 5 Jun 2016 10:18:28 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1465147105383469.02051294142177; Sun, 5 Jun 2016 10:18:25 -0700 (PDT) Date: Sun, 05 Jun 2016 18:18:25 +0100 From: Denis Ovsienko To: Message-ID: <1552192a030.f699d78686419.1337407248371299888@ovsienko.info> In-Reply-To: <87shwr7myf.wl-jch@pps.univ-paris-diderot.fr> References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> <87shwr7myf.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] Suresh Krishnan's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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: Sun, 05 Jun 2016 17:18:30 -0000 ---- On Sun, 05 Jun 2016 15:02:48 +0100 Juliusz Chroboczek wrote ---- >> * There is no mention of backward compatibility in the charter. Is the >> "new" Babel intended to be backward compatible with the deployed >> experimental version(s)? Might be worth noting either way. > >I've been refraining from answering this point, since I wanted to hear >people's opinions. I guess the discussion has died now. [...] Hello all. That's an important question and I have been considering this for a while too. Not as much expressively but I am inclined in roughly the same direction as Dave (maybe learned similar lessons). Running code is important, and same important is to keep the right amount of running code in the scope. In this sense it would seem reasonable for the WG to start with a compatible version and be able to use the working codebase. At the same time, it would make sense to start a list of incompatible changes to consider for Babel version 3 (with the stated impact and gain of each change). Then a few months later it would be easier to see the expected balance of the switch and the amount of work required and to make further plans based on that. I would have a small encoding change suggestion for that list too. Nobody has to make it in Babel v3 and nobody has to specify Babel version 3 ASAP, but I could explain and we could discuss (time permitting). -- Denis Ovsienko From nobody Sun Jun 5 14:36: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 2A3C312D0DB for ; Sun, 5 Jun 2016 14:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 dev5tOzrCkjx for ; Sun, 5 Jun 2016 14:36: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 2E84612B022 for ; Sun, 5 Jun 2016 14:36: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 u55Laquw023693; Sun, 5 Jun 2016 23:36: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 3A42A61FA7; Sun, 5 Jun 2016 23:36: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 GnfkSFVO7uFo; Sun, 5 Jun 2016 23:36:50 +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 A92B461FA5; Sun, 5 Jun 2016 23:36:50 +0200 (CEST) Date: Sun, 05 Jun 2016 23:36:52 +0200 Message-ID: <87shwrmi6j.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Denis Ovsienko In-Reply-To: <1552192a030.f699d78686419.1337407248371299888@ovsienko.info> References: <20160602013442.16179.56150.idtracker@ietfa.amsl.com> <87shwr7myf.wl-jch@pps.univ-paris-diderot.fr> <1552192a030.f699d78686419.1337407248371299888@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=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 05 Jun 2016 23:36:52 +0200 (CEST) X-Miltered: at korolev with ID 57549B74.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57549B74.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 : 57549B74.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 Subject: [babel] Running code [was: Suresh Krishnan's...] 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: Sun, 05 Jun 2016 21:36:56 -0000 > That's an important question and I have been considering this for > a while too. Not as much expressively but I am inclined in roughly the > same direction as Dave (maybe learned similar lessons). Noted. > Running code is important, and same important is to keep the right > amount of running code in the scope. We're not going to standardise anything without implementation experience. As soon as we start making changes, I branch babeld and we implement anything that we're considering for standardisation. (This includes you and me, but also Matthieu and Toke, and hopefully a number of people who lurk on this list and who used to help with babeld before they sold their souls to the private sector.) Most IETF WGs are doing their homework, and implementing everything that they consider for standardisation. Some other WGs have been standardising stuff that's never been implemented, with the results that you imagine. Let's be very vigilant, and make sure we belong to the former category. -- Juliusz From nobody Sun Jun 5 20:34: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 ED16C12D143; Sun, 5 Jun 2016 20:34: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 Pz9V0-dqNu9B; Sun, 5 Jun 2016 20:34:21 -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 6099012D12D; Sun, 5 Jun 2016 20:34:21 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id p204so11979289oih.3; Sun, 05 Jun 2016 20:34:21 -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=5Ph/dNp7XnneqmproxoUIxVC+qNo3jn+8175r+Pl4Vw=; b=qa+s9meqkW6iAA26LJYht8+b+iI4FMWKEjBMAVuO4oDSmX9TRSRCfPSwBjkdG7JFUg ZegPo4WS4+QOBBdwLnuDq2ouCPQqqc2eGaPjItpPMJy2wyf2GidPOVPOJFyMqjdxASvQ RXz8OgOyqPG/PtKxQd0zOidX2TggeE0URqixoPCQ6x/Lt2AKko4jVCrQxeTpznDRQm1K xjy2QLara/iX4JqZU7cuP/KslFM7AcPEtauXotFm8HXhpqhBp3YGLfKPDq650k7DPC2n 0ubua1e6NDdFCPd9H5RrJBde81fDPafkb/hBodzezmlq2Jd+zohuRcZekhcxRypf837e eA8A== 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=5Ph/dNp7XnneqmproxoUIxVC+qNo3jn+8175r+Pl4Vw=; b=VRLVEZDqmTI4Fry7DGdx6rGXiLUM0APtXZYWR7ZfxoesXgGGVSCQR1X9K0oaJMDkqa HsNI4hWt0eNUUjecq1D3fjLhEBY/JEEZaJvgjEzaCnOn3OuTp7BCO9wC7t4YNq7NBNdv ytrGoVOhpT/5VHVy2UeCwV/r+JQMM2sw9mK91Dn5Y/7L8WYTu5JnPc9W49gFscJ810Zz gTDX9WCHFmhE9YcbFoRk7T2V3QJ4K6PZX+sem3JIvdgL+TBwqWi/eau35/vUnxvgfd+p +Cxk39HNnHgVF1eL81GHiJd/JKd59+/9V2H0+Np9WzrjNXK+dqti00RENtVFARvfzV+9 DFUw== X-Gm-Message-State: ALyK8tLQls7zRwlPYIAcnI3/uz9l2vufO7GLr529oP+mPeXuKDKPGEG9PVvt0e7+lauZG9tQCxcJOMNNdXUwng== X-Received: by 10.202.177.134 with SMTP id a128mr6328982oif.37.1465184060738; Sun, 05 Jun 2016 20:34:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.66 with HTTP; Sun, 5 Jun 2016 20:34:06 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Donald Eastlake Date: Sun, 5 Jun 2016 23:34:06 -0400 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113cea70789204053493bf7d Archived-At: Cc: babel-chairs@ietf.org, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Revised 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, 06 Jun 2016 03:34:24 -0000 --001a113cea70789204053493bf7d Content-Type: text/plain; charset=UTF-8 Hi Alia, This looks good to me. However, the word "even" in the following line reads a bit odd and I would delete it.... multicast. It may even include discussion and consultation with the PIM Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote: > Incidentally, > > https://datatracker.ietf.org/doc/charter-ietf-babel/history/ > > is very useful for looking at the differences between charters. > > Alia > > On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote: > >> Hi Donald, Russ, Juliusz, Toke, etc., >> >> I have read through all the discussion and IESG comments on the charter. >> Here is what I have for an updated version. I do need to get it out for >> External >> Review soon so that it can come back onto the IESG telechat for final >> approval. >> The External Review is to give time for comments by those not on the IESG >> or >> WG - and particularly that it goes out to other organizations who might be >> interested. In the case of Babel, that is relevant because of the >> potential interaction >> with the Broadband Forum on TR-069. >> >> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I am >> including the text below. >> >> ================================================================= >> >> Babel is a loop-avoiding, distance vector routing protocol with good >> provisions for dynamically computed link metrics. It is robust even in >> the presence of link metric oscillations and the failure of >> transitivity. The core of the Babel protocol and security extensions >> are described in Experimental Independent Stream RFCs 6126, 7557, and >> 7298. >> >> These RFCs are the basis of three independent, open source >> implementations. There is some production deployment of these >> implementations, notably in hybrid networks (networks that include >> classical, wired parts with meshy radio bits) and in global overlay >> networks (networks built out of large numbers of tunnels spanning >> continents). >> >> The Working Group will focus on moving the Babel protocol to IETF >> Proposed Standard with IETF review. This includes clarifying RFC 6126 >> and integrating RFC 7557 and feedback provided by independent >> implementations, and resolving comments. It is not a requirement that >> the Babel protocol produced is backwards compatible with RFC 6126. It >> is a requirement that Babel support at least one profile that is >> auto-configuring. Other documents that are relevant to the above work >> can also be produced. Particular emphasis will be placed >> on work needed for a Proposed Standard routing protocol, such as >> ensuring manageability and strong security. Link metric measurement or >> link metric calculation procedures significantly more complex that >> those currently in Babel are out of scope. >> >> Work Items: >> >> - Produce a revision of RFC 6126 suitable for publication as a >> Proposed Standard >> -- incorporate in the revision developments since RFC 6126 >> -- resolve technical issues found >> -- include in the base specification the extensibility work in >> RFC 7557 >> -- support auto-configuration >> -- consider any important changes based on experience with Babel to >> date. >> >> - Address security needs for BABEL. This may include using the >> techniques in RFC 7298, or other alternatives. Security may be >> included in the base spec or the base spec may normatively reference a >> separate Proposed Standard specification. This is required as part of >> moving Babel to Proposed Standard. >> >> - Address manageability of Babel by producing an informational model >> for use by other network management such as the Broadband Forum >> TR-069, and a YANG data module based on that information model. This >> YANG data module to be consistent with the ongoing effort to use YANG >> data modules in the Routing Area. This work is required as part of >> moving Babel to Proposed Standard. >> >> - As the Proposed Standard version of Babel is completed, an >> Applicability Statement should be finalized to guide those potentially >> interested in deploying Babel. This Applicability Statement may >> include deployment advice and will be published as an RFC. >> >> - Coordinate with other Working Groups, such as the HOMENET WG for >> likely applicability, the RTGWG and V6OPS WG about Source-Specific >> Routing to support IPv6 multihoming, the PIM WG for discussion around >> multicast, and the MANET WG for considerations around wireless. >> >> - Liaise as necessary with the Broadband Forum to facilitate use of the >> Babel management Information Model for TR-069. >> >> - The Working Group should document its ongoing implementation >> experience with Babel, so that new WG participants can understand the >> state that is driving this work and the experience driving changes. >> This documentation may be on the Working Group's wiki, in >> an internet-draft that isn't expected to be published as an RFC, or a >> combination. >> >> - As a secondary focus, the Working Group may work on multicast >> aspects of Babel. This may include discussion of any potential issues >> for supporting Babel running with PIM-SM in an auto-configuration >> profile. It may include exploring Babel carrying separate metrics for >> multicast. It may even include discussion and consultation with the PIM >> WG about Babel providing the ability to build multicast routing >> tables. With AD and WG agreement, once an approach is understood, >> then a milestone may be added for an associated document targeted as >> Proposed Standard. >> >> - As a secondary focus, the Working Group may work on documents >> defining source specific routing extensions for Babel as a way of handling >> IPv6 multihoming. >> >> Thus, the Working Group will produce a Proposed Standard Babel >> specification, including or paired with a suitable Proposed Standard >> specification covering the security mechanism(s) for BABEL. It will >> also produce a management information and data model for BABEL as a >> Proposed Standard RFC. An applicability statement will be produced as >> an Informational RFC. >> >> *Proposed Milestones* >> DateMilestone >> Aug 2017 IESG Submission of Babel Applicability draft >> Jul 2017 IESG Submission of Babel Management draft >> Jul 2017 IESG Submission of RFC6126bis and potentially companion >> security mechanisms draft >> Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) draft >> Jul 2016 WG adoption of RFC6126bis >> Jul 2016 WG adoption of Babel Applicability draft >> draft-chroboczek-babel-applicability >> >> >> >> ================================================================= >> >> >> >> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < >> jch@pps.univ-paris-diderot.fr> wrote: >> >>> > - The working group is encouraged to keep its wiki updated with >>> > implementation experience with Babel so that new WG participants can >>> > understand the state that is driving this work and the experience >>> > driving changes. >>> >>> Do we really need to specify the technology used for this information? >>> What about >>> >>> "to keep its wiki updated with implementation experience" -> "to >>> maintain up-to-date, publicly accessible information about >>> implementation experience" >>> >>> Then the WG can choose whether to do a wiki page, an internet-draft, or >>> whatever else we find convenient. >>> >>> -- Juliusz >>> >> >> > --001a113cea70789204053493bf7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,

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

multicast.=C2=A0 = It may even include discussion and consultation with the PIM

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. East= lake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford,= MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas <= span dir=3D"ltr"><akatlas@gmail.com> wrote:
=
Incidentally,


<= /div>
is very useful for looking at the differences between charters.

Alia=

On Fri, Jun 3, 2016 at 4:3= 9 PM, Alia Atlas <akatlas@gmail.com> wrote:
Hi Donald, Russ, Juliusz, Toke, etc.,
I have read through all the discussion and IESG comments o= n the charter.
Here is what I have for an updated version.=C2=A0 = I do need to get it out for External
Review soon so that it can c= ome back onto the IESG telechat for final approval.
The External = Review is to give time for comments by those not on the IESG or
W= G - and particularly that it goes out to other organizations who might be
interested.=C2=A0 In the case of Babel, that is relevant because o= f the potential interaction
with the Broadband Forum on TR-069.

The link is=C2=A0https://datatracker.ietf.o= rg/doc/charter-ietf-babel/ .=C2=A0 I am including the text below.
=

=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=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=3D=3D=3D

Babel is a loop-avoiding, distance vector routing protocol with= good
provisions for dynamically computed link metrics. It is robust eve= n in
the presence of link metric oscillations and the failure of
tran= sitivity. The core of the Babel protocol and security extensions
are des= cribed in Experimental Independent Stream RFCs 6126, 7557, and
7298.
=
These RFCs are the basis of three independent, open source
implement= ations. There is some production deployment of these
implementations, no= tably in hybrid networks (networks that include
classical, wired parts w= ith meshy radio bits) and in global overlay
networks (networks built out= of large numbers of tunnels spanning
continents).

The Working Gr= oup will focus on moving the Babel protocol to IETF
Proposed Standard wi= th IETF review.=C2=A0 This includes clarifying RFC 6126
and integrating = RFC 7557 and feedback provided by independent
implementations, and resol= ving comments. It is not a requirement that
the Babel protocol produced = is backwards compatible with RFC 6126.=C2=A0 It
is a requirement that Ba= bel support at least one profile that is
auto-configuring.=C2=A0 Other d= ocuments that are relevant to the above work
can also be produced. Parti= cular emphasis will be placed
on work needed for a Proposed Standard rou= ting protocol, such as
ensuring manageability and strong security. Link = metric measurement or
link metric calculation procedures significantly m= ore complex that
those currently in Babel are out of scope.

Work = Items:

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

- Address security needs for BABEL. This may include us= ing the
techniques in RFC 7298, or other alternatives. Security may beincluded in the base spec or the base spec may normatively reference aseparate Proposed Standard specification. This is required as part of
m= oving Babel to Proposed Standard.

- Address manageability of Babel b= y producing an informational model
for use by other network management s= uch as the Broadband Forum
TR-069, and a YANG data module based on that = information model. This
YANG data module to be consistent with the ongoi= ng effort to use YANG
data modules in the Routing Area. This work is req= uired as part of
moving Babel to Proposed Standard.

- As the Prop= osed Standard version of Babel is completed, an
Applicability Statement = should be finalized to guide those potentially
interested in deploying B= abel. This Applicability Statement may
include deployment advice and wil= l be published as an RFC.

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

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

- T= he Working Group should document its ongoing implementation
experience w= ith Babel, so that new WG participants can understand the
state th= at is driving this work and the experience driving changes.
This = documentation may be on the Working Group's wiki, in
an internet-dr= aft that isn't expected to be published as an RFC, or a
combination.=

- As a secondary focus, the Working Group may work on multicastaspects of Babel.=C2=A0 This may include discussion of any potential issue= s
for supporting Babel running with PIM-SM in an auto-configuration
p= rofile.=C2=A0 It may include exploring Babel carrying separate metrics for<= br>multicast.=C2=A0 It may even include discussion and consultation with th= e PIM
WG about Babel providing the ability to build multicast routingtables.=C2=A0 With AD and WG agreement, once an approach is understood,then a milestone may be added for an associated document targeted as
Pr= oposed Standard.

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

Thus, the Working Group will pr= oduce a Proposed Standard Babel
specification, including or paired with = a suitable Proposed Standard
specification covering the security mechani= sm(s) for BABEL. It will
also produce a management information and data = model for BABEL as a
Proposed Standard RFC. An applicability statement w= ill be produced as
an Informational RFC.

Proposed Milestones
DateMilestoneAu= g 2017IESG Submission of Babel Applicability draftJ= ul 2017IESG Submission of Babel Management draftJul 2017IESG Submission of RFC6126bi= s and potentially companion security mechanisms draftOct 2016WG adoption of Babel Management (Info Model & YANG Model) dra= ftJul= 2016WG adoption of RFC6126bisJul 2016WG adoption of = Babel Applicability draft=C2=A0
draft-ch= roboczek-babel-applicability


=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=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=3D=3D=3D
=


On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chrobo= czek <jch@pps.univ-paris-diderot.fr> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> - The working group is encouraged to kee= p its wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz



--001a113cea70789204053493bf7d-- From nobody Mon Jun 6 03:45: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 70DC812D0DA; Mon, 6 Jun 2016 03:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gVcAg3F9C9cO; Mon, 6 Jun 2016 03:45:16 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192B112D5A9; Mon, 6 Jun 2016 03:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3859; q=dns/txt; s=iport; t=1465209915; x=1466419515; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EidqNeeU0BV2ZX7z8KmZIkzpZP/U5HT54ClxetD0D70=; b=jFoFAyatSTVtuWt6ZhMCBwqGuuOz37r0aWRpRXFabuebi4CBbVCCerBE WA6hG0Frq3cCj3YvA5eVdtPFSSj8s5L+yGbyOW9D5f6boZe8SIgCC0Kjo Rx91BELV/0xALYMUGLLu+YI7SI5rcj7OUzAHedWnFf8gh0YgJWf+lqvQD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5BgANU1VX/xbLJq1bhBAruRyECR6Fd?= =?us-ascii?q?AKBfAEBAQEBAWYnhEYBAQMBJxE2CwULC0ZXBgEMCAEBBYgeCLovAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAR6GJ4F3CIJOihoBBIgFkEOOJolChVyPWlSCOYE3OopLAQEB?= X-IronPort-AV: E=Sophos;i="5.26,426,1459814400"; d="scan'208";a="637858078" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 10:45:13 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u56AjCKR031434; Mon, 6 Jun 2016 10:45:12 GMT To: "STARK, BARBARA H" , The IESG References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Benoit Claise Message-ID: <5a1c5794-08af-f065-9827-6f63c6463d15@cisco.com> Date: Mon, 6 Jun 2016 12:45:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "babel-chairs@ietf.org" , "babel@ietf.org" Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 06 Jun 2016 10:45:17 -0000 Barbara, >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Not really a DISCUSS, but I would like to at least try to convince you if you >> disagree. >> >> "Address manageability of Babel by producing an informational model, for >> use by other network management, and a YANG module based on it, to be >> consistent with the ongoing effort to use YANG modules in the Routing Area. >> This is required as part of moving Babel to Proposed Standard." >> >> Do the WG really want to focus on an information model first, as opposed to >> go directly to a data model? >> See RFC3444. The end goal is a YANG data model, as you correctly stressed. >> >> Proposal (we used this sentence in SUPA): >> If the working group finds it necessary to work on an information model >> before the data model, to help provide guidance and derive the data models, >> it may do so. The working group will decide later whether the information >> model needs to be published as an RFC. >> >> Also, "This is required as part of moving Babel to Proposed Standard." >> I want to make sure we set the right expectations for this. >> Babel will not move to Proposed Standard unless we publish the YANG data >> model at the same time. >> If so, I like that. You might want to make it clear, in the charter text or the >> milestones. >> >> Editorial: YANG module => YANG data model > As I mentioned in Buenos Aires... > Since Babel is intended for more of an unmanaged home network environment, and homenet WG intends to create a profile that hopefully will require little to no management; > - and any management in such an environment would ideally be done through a UI by the user; > - and the only managed routers that currently exist in this environment are TR-069 managed routers (to the best of knowledge there are no netconf or restconf managed routers in home networks); > - and there are 100s of millions of TR-069 managed routers deployed Disclaimer: I was not in the BoF, I'm not following the mailing list, and I'm not that familiar with Babel. So I worked from the charter text. So those Babel use cases are new to me. A sentence or two in the charter justifying this information model this way would have helped me. > > -> I believe it is very important that the process allows for efficient and simple derivation of the TR-069 data model. I accept that a YANG model is necessary from a dogmatic perspective, in spite of the fact that no home network devices are managed at this time using netconf or restconf. FYI. http://www.sysrepo.org/. In one sentence: NETCONF YANG-based management of home gateway routers running on LINUX OS (OpenWRT). > But backing into TR-069 from YANG is more difficult than going into TR-069 from an information model. That sounds logical. > I'm having first-hand experience in LMAP where the YANG modeler is constantly trying to make changes to the information model to make it exactly match how he wants to do the YANG model, while ignoring the needs of TR-069. > > I'm willing to work on the information model and to work with whoever does the YANG data model to make sure the information model meets the needs of both YANG and TR-069. I'm fine if it's in one doc. But if the info model is just going to be derived from the YANG model, ... then we have a problem. The IM should be start, the DM the more specific information derived from the IM. See RFC3444. Regards, Benoit > and to heck with TR-069, I'm not so interested. I will still participate to prevent the model from being overly bloated with all sorts of unnecessary configuration and statistics reporting parameters. Whatever model we come up with must be very, very simple. > Barbara > > . > From nobody Mon Jun 6 06:58: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 BD93412D7AD; Mon, 6 Jun 2016 06:58:15 -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 gSW8CX5-dc2L; Mon, 6 Jun 2016 06:58:13 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 11B3412D7BA; Mon, 6 Jun 2016 06:58:11 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id h19so140701300ywc.0; Mon, 06 Jun 2016 06:58: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=QSH6Te4Bb81ymOWKmaqR5tohhM3bnWmNaXc9WCBZJJ0=; b=KPf7ASuA7aJF6KiQ/IKLa6tZewgFFDdUKQmCOwXIZHMDIKq4g47qPWoxdmo/l/B6+k n6jPmFZ9W5SgNVaS+AZ4ze9c0z9rIdA+72p1eYGoTIBfXyDZyjHP3v/jifrNKBZ6l5U+ QXNeZmiw3yxochjXia7d2Ohi+axgHPmnV+8ubWdcdgZvEmd2YRy71mBMKzl42lvUuJQd zoSnNAhqkqPR6YG9aTcgNL8GVEYMd3lukrcLZFKrOyXwaM7g+1lYskbgRMhD6iO7rLUd 1SJJyz4qGubzOJ3xoYXbpAVvdE4ZrvuEgg3C/Io6WXKWcR19rS83KoAzZ2+QX+Qj+Czv oDDA== 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=QSH6Te4Bb81ymOWKmaqR5tohhM3bnWmNaXc9WCBZJJ0=; b=dSjLzsP8Gc/2KNYbKEKoiwRRS3J5nbUeS2YUN7KV+18/g1ptUB4eCyqto+FrPthKeX wlKHXYotttoz8EO2LqSW9q/+3baP32074w44Ad1xXHf84uVlIYpTYwWBn4QCabDqsJre twGKnhkLZI6YDrX0FK2UQCIiPbBZNphQDvgk5jfj+1aATsz2Eu5AUnIQZQ5GGgSJcj2f 9X15HydpQ+p399BaiT9gn5ivNgBC0UqnVDeFTqdhQZLeQ4Cce4SPY6pQADWLFC6lAcYw eGEZ1Hi/isKwVGf5YUrKTxkpDaiaWfLUok7k6M1V615mbOfpV/sjFNJXQ+PztpeZUkFR N2BQ== X-Gm-Message-State: ALyK8tKxCx6thE0NmwZyMvXb/iMYWu8Fomjc4mACXsm6I1oHVer0HJ26iO5pMA8JLp5xyIhcPhG/1kHmjsA43g== X-Received: by 10.37.83.131 with SMTP id h125mr10879209ybb.109.1465221490314; Mon, 06 Jun 2016 06:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.74 with HTTP; Mon, 6 Jun 2016 06:58:09 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Alia Atlas Date: Mon, 6 Jun 2016 09:58:09 -0400 Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a113e60ba7295bf05349c7647 Archived-At: Cc: babel-chairs@ietf.org, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Revised 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, 06 Jun 2016 13:58:16 -0000 --001a113e60ba7295bf05349c7647 Content-Type: text/plain; charset=UTF-8 Good point. I've updated it. Any other comments or changes before I push the button for external review? Thanks, Alia On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake wrote: > Hi Alia, > > This looks good to me. However, the word "even" in the following line > reads a bit odd and I would delete it.... > > multicast. It may even include discussion and consultation with the PIM > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote: > >> Incidentally, >> >> https://datatracker.ietf.org/doc/charter-ietf-babel/history/ >> >> is very useful for looking at the differences between charters. >> >> Alia >> >> On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote: >> >>> Hi Donald, Russ, Juliusz, Toke, etc., >>> >>> I have read through all the discussion and IESG comments on the charter. >>> Here is what I have for an updated version. I do need to get it out for >>> External >>> Review soon so that it can come back onto the IESG telechat for final >>> approval. >>> The External Review is to give time for comments by those not on the >>> IESG or >>> WG - and particularly that it goes out to other organizations who might >>> be >>> interested. In the case of Babel, that is relevant because of the >>> potential interaction >>> with the Broadband Forum on TR-069. >>> >>> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I >>> am including the text below. >>> >>> ================================================================= >>> >>> Babel is a loop-avoiding, distance vector routing protocol with good >>> provisions for dynamically computed link metrics. It is robust even in >>> the presence of link metric oscillations and the failure of >>> transitivity. The core of the Babel protocol and security extensions >>> are described in Experimental Independent Stream RFCs 6126, 7557, and >>> 7298. >>> >>> These RFCs are the basis of three independent, open source >>> implementations. There is some production deployment of these >>> implementations, notably in hybrid networks (networks that include >>> classical, wired parts with meshy radio bits) and in global overlay >>> networks (networks built out of large numbers of tunnels spanning >>> continents). >>> >>> The Working Group will focus on moving the Babel protocol to IETF >>> Proposed Standard with IETF review. This includes clarifying RFC 6126 >>> and integrating RFC 7557 and feedback provided by independent >>> implementations, and resolving comments. It is not a requirement that >>> the Babel protocol produced is backwards compatible with RFC 6126. It >>> is a requirement that Babel support at least one profile that is >>> auto-configuring. Other documents that are relevant to the above work >>> can also be produced. Particular emphasis will be placed >>> on work needed for a Proposed Standard routing protocol, such as >>> ensuring manageability and strong security. Link metric measurement or >>> link metric calculation procedures significantly more complex that >>> those currently in Babel are out of scope. >>> >>> Work Items: >>> >>> - Produce a revision of RFC 6126 suitable for publication as a >>> Proposed Standard >>> -- incorporate in the revision developments since RFC 6126 >>> -- resolve technical issues found >>> -- include in the base specification the extensibility work in >>> RFC 7557 >>> -- support auto-configuration >>> -- consider any important changes based on experience with Babel to >>> date. >>> >>> - Address security needs for BABEL. This may include using the >>> techniques in RFC 7298, or other alternatives. Security may be >>> included in the base spec or the base spec may normatively reference a >>> separate Proposed Standard specification. This is required as part of >>> moving Babel to Proposed Standard. >>> >>> - Address manageability of Babel by producing an informational model >>> for use by other network management such as the Broadband Forum >>> TR-069, and a YANG data module based on that information model. This >>> YANG data module to be consistent with the ongoing effort to use YANG >>> data modules in the Routing Area. This work is required as part of >>> moving Babel to Proposed Standard. >>> >>> - As the Proposed Standard version of Babel is completed, an >>> Applicability Statement should be finalized to guide those potentially >>> interested in deploying Babel. This Applicability Statement may >>> include deployment advice and will be published as an RFC. >>> >>> - Coordinate with other Working Groups, such as the HOMENET WG for >>> likely applicability, the RTGWG and V6OPS WG about Source-Specific >>> Routing to support IPv6 multihoming, the PIM WG for discussion around >>> multicast, and the MANET WG for considerations around wireless. >>> >>> - Liaise as necessary with the Broadband Forum to facilitate use of the >>> Babel management Information Model for TR-069. >>> >>> - The Working Group should document its ongoing implementation >>> experience with Babel, so that new WG participants can understand the >>> state that is driving this work and the experience driving changes. >>> This documentation may be on the Working Group's wiki, in >>> an internet-draft that isn't expected to be published as an RFC, or a >>> combination. >>> >>> - As a secondary focus, the Working Group may work on multicast >>> aspects of Babel. This may include discussion of any potential issues >>> for supporting Babel running with PIM-SM in an auto-configuration >>> profile. It may include exploring Babel carrying separate metrics for >>> multicast. It may even include discussion and consultation with the PIM >>> WG about Babel providing the ability to build multicast routing >>> tables. With AD and WG agreement, once an approach is understood, >>> then a milestone may be added for an associated document targeted as >>> Proposed Standard. >>> >>> - As a secondary focus, the Working Group may work on documents >>> defining source specific routing extensions for Babel as a way of >>> handling >>> IPv6 multihoming. >>> >>> Thus, the Working Group will produce a Proposed Standard Babel >>> specification, including or paired with a suitable Proposed Standard >>> specification covering the security mechanism(s) for BABEL. It will >>> also produce a management information and data model for BABEL as a >>> Proposed Standard RFC. An applicability statement will be produced as >>> an Informational RFC. >>> >>> *Proposed Milestones* >>> DateMilestone >>> Aug 2017 IESG Submission of Babel Applicability draft >>> Jul 2017 IESG Submission of Babel Management draft >>> Jul 2017 IESG Submission of RFC6126bis and potentially companion >>> security mechanisms draft >>> Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) draft >>> Jul 2016 WG adoption of RFC6126bis >>> Jul 2016 WG adoption of Babel Applicability draft >>> draft-chroboczek-babel-applicability >>> >>> >>> >>> ================================================================= >>> >>> >>> >>> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < >>> jch@pps.univ-paris-diderot.fr> wrote: >>> >>>> > - The working group is encouraged to keep its wiki updated with >>>> > implementation experience with Babel so that new WG participants can >>>> > understand the state that is driving this work and the experience >>>> > driving changes. >>>> >>>> Do we really need to specify the technology used for this information? >>>> What about >>>> >>>> "to keep its wiki updated with implementation experience" -> "to >>>> maintain up-to-date, publicly accessible information about >>>> implementation experience" >>>> >>>> Then the WG can choose whether to do a wiki page, an internet-draft, or >>>> whatever else we find convenient. >>>> >>>> -- Juliusz >>>> >>> >>> >> > --001a113e60ba7295bf05349c7647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good point.=C2=A0 I've updated it.
Any other comme= nts or changes before I push the button for external review?

=
Thanks,
Alia
On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlak= e <d3e3e3@gmail.com> wrote:
Hi Alia,

This looks good to me. Howeve= r, the word "even" in the following line reads a bit odd and I wo= uld delete it....

multicast.=C2=A0 It may even include discussion and consultation with the = PIM

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 Be= aver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Fri, Jun 3,= 2016 at 4:40 PM, Alia Atlas <akatlas@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Incidentally,

=

is very useful for looking at the d= ifferences between charters.

Alia

On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas = <akatlas@gmail.com> wrote:
Hi Donald, Russ, Juliusz, Toke, etc.,

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

The link is=C2=A0https://datatracker.ietf.org/doc/charter-ie= tf-babel/ .=C2=A0 I am including the text below.

=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=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=3D=3D=3D

Babel = is a loop-avoiding, distance vector routing protocol with good
provision= s for dynamically computed link metrics. It is robust even in
the presen= ce of link metric oscillations and the failure of
transitivity. The core= of the Babel protocol and security extensions
are described in Experime= ntal Independent Stream RFCs 6126, 7557, and
7298.

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

The Working Group will focus on = moving the Babel protocol to IETF
Proposed Standard with IETF review.=C2= =A0 This includes clarifying RFC 6126
and integrating RFC 7557 and feedb= ack provided by independent
implementations, and resolving comments. It = is not a requirement that
the Babel protocol produced is backwards compa= tible with RFC 6126.=C2=A0 It
is a requirement that Babel support at lea= st one profile that is
auto-configuring.=C2=A0 Other documents that are = relevant to the above work
can also be produced. Particular emphasis wil= l be placed
on work needed for a Proposed Standard routing protocol, suc= h as
ensuring manageability and strong security. Link metric measurement= or
link metric calculation procedures significantly more complex thatthose currently in Babel are out of scope.

Work Items:

- Pr= oduce a revision of RFC 6126 suitable for publication as a
Proposed Stan= dard
-- incorporate in the revision developments since RFC 6126
-- re= solve technical issues found
-- include in the base specification the ex= tensibility work in
RFC 7557
-- support auto-configuration
-- cons= ider any important changes based on experience with Babel to
date.
- Address security needs for BABEL. This may include using the
techniq= ues in RFC 7298, or other alternatives. Security may be
included in the = base spec or the base spec may normatively reference a
separate Proposed= Standard specification. This is required as part of
moving Babel to Pro= posed Standard.

- Address manageability of Babel by producing an inf= ormational model
for use by other network management such as the Broadba= nd Forum
TR-069, and a YANG data module based on that information model.= This
YANG data module to be consistent with the ongoing effort to use Y= ANG
data modules in the Routing Area. This work is required as part ofmoving Babel to Proposed Standard.

- As the Proposed Standard vers= ion of Babel is completed, an
Applicability Statement should be finalize= d to guide those potentially
interested in deploying Babel. This Applica= bility Statement may
include deployment advice and will be published as = an RFC.

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

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

- The Working Group s= hould document its ongoing implementation
experience with Babel, so that= new WG participants can understand the
state that is driving this= work and the experience driving changes.
This documentation may = be on the Working Group's wiki, in
an internet-draft that isn't= expected to be published as an RFC, or a
combination.

- As a se= condary focus, the Working Group may work on multicast
aspects of Babel.= =C2=A0 This may include discussion of any potential issues
for supportin= g Babel running with PIM-SM in an auto-configuration
profile.=C2=A0 It m= ay include exploring Babel carrying separate metrics for
multicast.=C2= =A0 It may even include discussion and consultation with the PIM
WG abou= t Babel providing the ability to build multicast routing
tables.=C2=A0 W= ith AD and WG agreement, once an approach is understood,
then a mileston= e may be added for an associated document targeted as
Proposed Standard.=

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

Thus, the Working Group will produce a Proposed= Standard Babel
specification, including or paired with a suitable Propo= sed Standard
specification covering the security mechanism(s) for BABEL.= It will
also produce a management information and data model for BABEL = as a
Proposed Standard RFC. An applicability statement will be produced = as
an Informational RFC.

Proposed Milestones
DateMilestone
Aug 2017IESG Submiss= ion of Babel Applicability draft
Jul 2017IESG Submis= sion of Babel Management draft
Jul 2017IESG Submission of RFC6126bis and potentiall= y companion security mechanisms draft
Oct 2016WG ado= ption of Babel Management (Info Model & YANG Model) draft
Jul 2016WG adoption o= f RFC6126bis
Jul 2016WG adoption of Babel Applicabil= ity draft=C2=A0
draft-chroboczek-babel-a= pplicability


=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=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=3D=3D=3D

=


On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
> - The working group is encouraged to keep its wiki upd= ated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz




--001a113e60ba7295bf05349c7647-- From nobody Mon Jun 6 07:14: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 4DA6D12D7C8; Mon, 6 Jun 2016 07:14:15 -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 nFPZprJv8qpe; Mon, 6 Jun 2016 07:14:13 -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 E380D12D7C5; Mon, 6 Jun 2016 07:14:12 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id h19so141184973ywc.0; Mon, 06 Jun 2016 07:14:12 -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=sECgIXcB773p+nldxnumxFLbkyNyzgoMsCXj8KH8NB0=; b=Kv2x+/rgeMpyMLyh/76OkYiF+a7HEiwQT5YF2GXk+YpaUL1ttjcHPTenOUu/AoXE7w eEnqd3zZD0RsyT9LCDCeDf21q1kTgq7HEfNIDCW/QskeoYnH/bZdCNLxcbQXg39nJSVW Y4059/C3E/ymJs25EQwIzblddzPFr6W3XRMuzXJbxCjUdDClYELeHnYZQNvEae4v65QD sqTD1mWAlVl6bYcd7EBD828XCeSA++TcBUSl3OwCXNtCuDAe4susoorlJLXQ/t0MQNLv l0OKaqykYVH+AWeY7TiwFRvk6VtBPydskpgaOLxjr0fFJjKm/FS1FKewukQAia/XJcn6 FuoQ== 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=sECgIXcB773p+nldxnumxFLbkyNyzgoMsCXj8KH8NB0=; b=H3nFo1ooJcuN+6lbBwGoIOYM7P1N0qCTaSjUf8CBM5HA5QBzb7RppzeWJKJnHwuWhD iHaMsMKin7Il7qGHH1PygQvIIvleskVI6Mv5yvb06WS0I5Sj24uHLKzlppmZ/73KsncG +2IIaAecKzt3Ijvcjk/PC7imfZs6B8FdrObw+5NbqgQ69Eutb4vU61wh2iOWhMQONJJj lp05GGapRUlBJ9+s37D5/jaIC2Vc/wtPju0wVFITdC0pxFfCWx6h5aH+TDK414yvh+Kj /ER39OmVVeUSu+6u+OHDRskVRFFu7dpNq+kK4qvqQPQCuqXBeCqxl5aGO8qrjIMHcGrx ShFw== X-Gm-Message-State: ALyK8tIaKcQECBwOayG6lacHjMKtqZsKSTvo5CCWTTxnSGFZAhlwtRnAmKUGP4tJ+Q5UXXmWo9ZUxsawphCACA== X-Received: by 10.37.198.86 with SMTP id k83mr6504120ybf.134.1465222452139; Mon, 06 Jun 2016 07:14:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.74 with HTTP; Mon, 6 Jun 2016 07:14:11 -0700 (PDT) In-Reply-To: <5a1c5794-08af-f065-9827-6f63c6463d15@cisco.com> References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> <5a1c5794-08af-f065-9827-6f63c6463d15@cisco.com> From: Alia Atlas Date: Mon, 6 Jun 2016 10:14:11 -0400 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=94eb2c08d0d6c6ddce05349caf7b Archived-At: Cc: "babel-chairs@ietf.org" , "STARK, BARBARA H" , "babel@ietf.org" , The IESG Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 06 Jun 2016 14:14:15 -0000 --94eb2c08d0d6c6ddce05349caf7b Content-Type: text/plain; charset=UTF-8 Hi Benoit, Do you see additional text changes desired from https://datatracker.ietf.org/doc/charter-ietf-babel/? I've updated it to say: - Address manageability of Babel by producing an informational model for use by other network management such as the Broadband Forum TR-069, and a YANG data module based on that information model. The former supports the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) as is done today. The latter YANG model supports management of home gateway routers and is consistent with the ongoing effort to use YANG data modules in the Routing Area. This work is required as part of moving Babel to Proposed Standard. Thanks, Alia On Mon, Jun 6, 2016 at 6:45 AM, Benoit Claise wrote: > Barbara, > > ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Not really a DISCUSS, but I would like to at least try to convince you >>> if you >>> disagree. >>> >>> "Address manageability of Babel by producing an informational model, for >>> use by other network management, and a YANG module based on it, to be >>> consistent with the ongoing effort to use YANG modules in the Routing >>> Area. >>> This is required as part of moving Babel to Proposed Standard." >>> >>> Do the WG really want to focus on an information model first, as opposed >>> to >>> go directly to a data model? >>> See RFC3444. The end goal is a YANG data model, as you correctly >>> stressed. >>> >>> Proposal (we used this sentence in SUPA): >>> If the working group finds it necessary to work on an information model >>> before the data model, to help provide guidance and derive the data >>> models, >>> it may do so. The working group will decide later whether the information >>> model needs to be published as an RFC. >>> >>> Also, "This is required as part of moving Babel to Proposed Standard." >>> I want to make sure we set the right expectations for this. >>> Babel will not move to Proposed Standard unless we publish the YANG data >>> model at the same time. >>> If so, I like that. You might want to make it clear, in the charter text >>> or the >>> milestones. >>> >>> Editorial: YANG module => YANG data model >>> >> As I mentioned in Buenos Aires... >> Since Babel is intended for more of an unmanaged home network >> environment, and homenet WG intends to create a profile that hopefully will >> require little to no management; >> - and any management in such an environment would ideally be done >> through a UI by the user; >> - and the only managed routers that currently exist in this environment >> are TR-069 managed routers (to the best of knowledge there are no netconf >> or restconf managed routers in home networks); >> - and there are 100s of millions of TR-069 managed routers deployed >> > Disclaimer: I was not in the BoF, I'm not following the mailing list, and > I'm not that familiar with Babel. So I worked from the charter text. > So those Babel use cases are new to me. A sentence or two in the charter > justifying this information model this way would have helped me. > >> >> -> I believe it is very important that the process allows for efficient >> and simple derivation of the TR-069 data model. I accept that a YANG model >> is necessary from a dogmatic perspective, in spite of the fact that no home >> network devices are managed at this time using netconf or restconf. >> > FYI. http://www.sysrepo.org/. In one sentence: NETCONF YANG-based > management of home gateway routers running on LINUX OS (OpenWRT). > > But backing into TR-069 from YANG is more difficult than going into TR-069 >> from an information model. >> > That sounds logical. > >> I'm having first-hand experience in LMAP where the YANG modeler is >> constantly trying to make changes to the information model to make it >> exactly match how he wants to do the YANG model, while ignoring the needs >> of TR-069. >> >> I'm willing to work on the information model and to work with whoever >> does the YANG data model to make sure the information model meets the needs >> of both YANG and TR-069. I'm fine if it's in one doc. But if the info model >> is just going to be derived from the YANG model, >> > ... then we have a problem. > The IM should be start, the DM the more specific information derived from > the IM. > See RFC3444. > > Regards, Benoit > >> and to heck with TR-069, I'm not so interested. I will still participate >> to prevent the model from being overly bloated with all sorts of >> unnecessary configuration and statistics reporting parameters. Whatever >> model we come up with must be very, very simple. >> Barbara >> >> . >> >> > --94eb2c08d0d6c6ddce05349caf7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

Do you see additional text c= hanges desired from=C2=A0https://datatracker.ietf.org/doc/charter-ietf-babel/?

I've updated it to say:

- Ad= dress manageability of Babel by producing an informational model for use by= other network management such as the Broadband Forum TR-069, and a YANG da= ta module based on that information model.=C2=A0 The former supports the ca= se where the Customer-Premise Equipment (CPE) is managed by the Service Pro= vider (SP) as is done today.=C2=A0 The latter YANG model supports managemen= t of home gateway routers and is =C2=A0consistent with the ongoing effort t= o use YANG data modules in the Routing Area. This work is required as part = of moving Babel to Proposed Standard.

Thanks,
= Alia

O= n Mon, Jun 6, 2016 at 6:45 AM, Benoit Claise <bclaise@cisco.com> wrote:
Barbara,

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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

Do the WG really want to focus on an information model first, as opposed to=
go directly to a data model?
See RFC3444. The end goal is a YANG data model, as you correctly stressed.<= br>
Proposal (we used this sentence in SUPA):
If the working group finds it necessary to work on an information model
before the data model, to help provide guidance and derive the data models,=
it may do so. The working group will decide later whether the information model needs to be published as an RFC.

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

Editorial: YANG module =3D> YANG data model
As I mentioned in Buenos Aires...
Since Babel is intended for more of an unmanaged home network environment, = and homenet WG intends to create a profile that hopefully will require litt= le to no management;
=C2=A0 - and any management in such an environment would ideally be done th= rough a UI by the user;
=C2=A0 - and the only managed routers that currently exist in this environm= ent are TR-069 managed routers (to the best of knowledge there are no netco= nf or restconf managed routers in home networks);
=C2=A0 - and there are 100s of millions of TR-069 managed routers deployed<= br>
Disclaimer: I was not in the BoF, I'm not following the mailing list, a= nd I'm not that familiar with Babel. So I worked from the charter text.=
So those Babel use cases are new to me. A sentence or two in the charter ju= stifying this information model this way would have helped me.

-> I believe it is very important that the process allows for efficient = and simple derivation of the TR-069 data model. I accept that a YANG model = is necessary from a dogmatic perspective, in spite of the fact that no home= network devices are managed at this time using netconf or restconf.
 FYI.=C2=A0 http://www.sysrepo.org/. In one sentence: NETCONF=C2=A0 YANG-b= ased management of home gateway routers running on LINUX OS (OpenWRT).

But backing into TR-069 from YANG is more difficult than going into TR-069 = from an information model.
That sounds logical.
I'm having first-hand experience in LMAP where the YANG modeler is cons= tantly trying to make changes to the information model to make it exactly m= atch how he wants to do the YANG model, while ignoring the needs of TR-069.=

I'm willing to work on the information model and to work with whoever d= oes the YANG data model to make sure the information model meets the needs = of both YANG and TR-069. I'm fine if it's in one doc. But if the in= fo model is just going to be derived from the YANG model,
 ... then we have a problem.
The IM should be start, the DM the more specific information derived from t= he IM.
See RFC3444.

Regards, Benoit
and to heck with TR-069, I'm not so interested. I will still participat= e to prevent the model from being overly bloated with all sorts of unnecess= ary configuration and statistics reporting parameters. Whatever model we co= me up with must be very, very simple.
Barbara

 .



--94eb2c08d0d6c6ddce05349caf7b-- From nobody Mon Jun 6 07:59:34 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 022A312D7D9 for ; Mon, 6 Jun 2016 07:59: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: <20160606145933.20854.80808.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 07:59: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, 06 Jun 2016 14:59:33 -0000 Changed milestone "Submission of rfc6126bis draft to IESG as Proposed Standard", set description to "Submission of rfc6126bis draft and associated Security Mechanisms draft to IESG as Proposed Standard", set due date to July 2017 from May 2017. URL: https://datatracker.ietf.org/wg/babel/charter/ From nobody Mon Jun 6 08:07:34 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 237B312D7D4; Mon, 6 Jun 2016 08:07:33 -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 ppt29Hk1RroP; Mon, 6 Jun 2016 08:07:31 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F7612D7CF; Mon, 6 Jun 2016 08:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15475; q=dns/txt; s=iport; t=1465225650; x=1466435250; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=MKOTOxG4oT0yXbYxwrqnXG1pV2/XyaN5r6FYz9ok0/Y=; b=A/oG6zVvXk5NhHNITeQ1nytCb1i7GU4FuUO+a5KgJZW0Iv5OfEa38udn fgRdWtuihSvi9g8zYvOYaSJ4K7e/5lpfY2B8Vrs+6vxUhJgNu7plL/0Ni eTXiiMdPWJYtfNTwEVKEjC0Fqmt4hpc37lvGHP0SmKbw0NUM8ub6CGbFH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COBQBmkFVX/xbLJq1bhBErUrVcgm6EC?= =?us-ascii?q?SKFcAKBfwEBAQEBAWYnhEYBAQQjBEcLEAsOCicDAgJGEQYNBgIBAQWIJg6qKZE?= =?us-ascii?q?IAQEBAQEBAQECAQEBAQEBAQEBAQEchieBd4JWh0GCWQWIBYszhRCGA4gjiUKFX?= =?us-ascii?q?I9aVII5gTc6MooZAQEB?= X-IronPort-AV: E=Sophos;i="5.26,427,1459814400"; d="scan'208,217";a="637862487" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 15:07:27 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u56F7R2h025034; Mon, 6 Jun 2016 15:07:27 GMT To: Alia Atlas References: <20160602091641.8785.2968.idtracker@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114268C6F6@GAALPA1MSGUSRBF.ITServices.sbc.com> <5a1c5794-08af-f065-9827-6f63c6463d15@cisco.com> From: Benoit Claise Message-ID: <622bcd54-d9da-db98-43b5-29ba01dcba2f@cisco.com> Date: Mon, 6 Jun 2016 17:07:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------63A07542B0C78B82D3FDA515" Archived-At: Cc: "babel-chairs@ietf.org" , "STARK, BARBARA H" , "babel@ietf.org" , The IESG Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-02: (with COMMENT) 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, 06 Jun 2016 15:07:33 -0000 This is a multi-part message in MIME format. --------------63A07542B0C78B82D3FDA515 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit That works for me. Thanks Alia. Regards, Benoit > Hi Benoit, > > Do you see additional text changes desired from > https://datatracker.ietf.org/doc/charter-ietf-babel/? > > I've updated it to say: > > - Address manageability of Babel by producing an informational model > for use by other network management such as the Broadband Forum > TR-069, and a YANG data module based on that information model. The > former supports the case where the Customer-Premise Equipment (CPE) is > managed by the Service Provider (SP) as is done today. The latter > YANG model supports management of home gateway routers and is > consistent with the ongoing effort to use YANG data modules in the > Routing Area. This work is required as part of moving Babel to > Proposed Standard. > > Thanks, > Alia > > On Mon, Jun 6, 2016 at 6:45 AM, Benoit Claise > wrote: > > Barbara, > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Not really a DISCUSS, but I would like to at least try to > convince you if you > disagree. > > "Address manageability of Babel by producing an > informational model, for > use by other network management, and a YANG module based > on it, to be > consistent with the ongoing effort to use YANG modules in > the Routing Area. > This is required as part of moving Babel to Proposed > Standard." > > Do the WG really want to focus on an information model > first, as opposed to > go directly to a data model? > See RFC3444. The end goal is a YANG data model, as you > correctly stressed. > > Proposal (we used this sentence in SUPA): > If the working group finds it necessary to work on an > information model > before the data model, to help provide guidance and derive > the data models, > it may do so. The working group will decide later whether > the information > model needs to be published as an RFC. > > Also, "This is required as part of moving Babel to > Proposed Standard." > I want to make sure we set the right expectations for this. > Babel will not move to Proposed Standard unless we publish > the YANG data > model at the same time. > If so, I like that. You might want to make it clear, in > the charter text or the > milestones. > > Editorial: YANG module => YANG data model > > As I mentioned in Buenos Aires... > Since Babel is intended for more of an unmanaged home network > environment, and homenet WG intends to create a profile that > hopefully will require little to no management; > - and any management in such an environment would ideally be > done through a UI by the user; > - and the only managed routers that currently exist in this > environment are TR-069 managed routers (to the best of > knowledge there are no netconf or restconf managed routers in > home networks); > - and there are 100s of millions of TR-069 managed routers > deployed > > Disclaimer: I was not in the BoF, I'm not following the mailing > list, and I'm not that familiar with Babel. So I worked from the > charter text. > So those Babel use cases are new to me. A sentence or two in the > charter justifying this information model this way would have > helped me. > > > -> I believe it is very important that the process allows for > efficient and simple derivation of the TR-069 data model. I > accept that a YANG model is necessary from a dogmatic > perspective, in spite of the fact that no home network devices > are managed at this time using netconf or restconf. > > FYI. http://www.sysrepo.org/. In one sentence: NETCONF YANG-based > management of home gateway routers running on LINUX OS (OpenWRT). > > But backing into TR-069 from YANG is more difficult than going > into TR-069 from an information model. > > That sounds logical. > > I'm having first-hand experience in LMAP where the YANG > modeler is constantly trying to make changes to the > information model to make it exactly match how he wants to do > the YANG model, while ignoring the needs of TR-069. > > I'm willing to work on the information model and to work with > whoever does the YANG data model to make sure the information > model meets the needs of both YANG and TR-069. I'm fine if > it's in one doc. But if the info model is just going to be > derived from the YANG model, > > ... then we have a problem. > The IM should be start, the DM the more specific information > derived from the IM. > See RFC3444. > > Regards, Benoit > > and to heck with TR-069, I'm not so interested. I will still > participate to prevent the model from being overly bloated > with all sorts of unnecessary configuration and statistics > reporting parameters. Whatever model we come up with must be > very, very simple. > Barbara > > . > > > --------------63A07542B0C78B82D3FDA515 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
That works for me.
Thanks Alia.

Regards, Benoit
Hi Benoit,

Do you see additional text changes desired from https://datatracker.ietf.org/doc/charter-ietf-babel/?

I've updated it to say:

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

Thanks,
Alia

On Mon, Jun 6, 2016 at 6:45 AM, Benoit Claise <bclaise@cisco.com> wrote:
Barbara,

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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

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

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

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

Editorial: YANG module => YANG data model
As I mentioned in Buenos Aires...
Since Babel is intended for more of an unmanaged home network environment, and homenet WG intends to create a profile that hopefully will require little to no management;
  - and any management in such an environment would ideally be done through a UI by the user;
  - and the only managed routers that currently exist in this environment are TR-069 managed routers (to the best of knowledge there are no netconf or restconf managed routers in home networks);
  - and there are 100s of millions of TR-069 managed routers deployed
Disclaimer: I was not in the BoF, I'm not following the mailing list, and I'm not that familiar with Babel. So I worked from the charter text.
So those Babel use cases are new to me. A sentence or two in the charter justifying this information model this way would have helped me.

-> I believe it is very important that the process allows for efficient and simple derivation of the TR-069 data model. I accept that a YANG model is necessary from a dogmatic perspective, in spite of the fact that no home network devices are managed at this time using netconf or restconf.
 FYI.  http://www.sysrepo.org/. In one sentence: NETCONF  YANG-based management of home gateway routers running on LINUX OS (OpenWRT).

But backing into TR-069 from YANG is more difficult than going into TR-069 from an information model.
 That sounds logical.
I'm having first-hand experience in LMAP where the YANG modeler is constantly trying to make changes to the information model to make it exactly match how he wants to do the YANG model, while ignoring the needs of TR-069.

I'm willing to work on the information model and to work with whoever does the YANG data model to make sure the information model meets the needs of both YANG and TR-069. I'm fine if it's in one doc. But if the info model is just going to be derived from the YANG model,
 ... then we have a problem.
The IM should be start, the DM the more specific information derived from the IM.
See RFC3444.

Regards, Benoit
and to heck with TR-069, I'm not so interested. I will still participate to prevent the model from being overly bloated with all sorts of unnecessary configuration and statistics reporting parameters. Whatever model we come up with must be very, very simple.
Barbara

 .




--------------63A07542B0C78B82D3FDA515-- From nobody Mon Jun 6 12:11: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 6673112D80C; Mon, 6 Jun 2016 12:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 bB_OpmCME0Uj; Mon, 6 Jun 2016 12:10:55 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 2D04212D784; Mon, 6 Jun 2016 12:10:55 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id e72so241569768oib.1; Mon, 06 Jun 2016 12:10:55 -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=z5Ud6uisWD7X9Y/i9TAk/C0LWKeGghU9PtdCs1wyJhg=; b=Duqtqqjokcwk/duxU2XpjMdREyevPtn/SMslHJIeUVHpsKw1m17BZauUcWPn6IPqzg b8YizsXaU7EoVgYPzEv3U5+/cx/yrh0Dc2cPSyxcdC3pmxXx6gy8N3/ZCwwryXNRsrhU DwP7ArwnMID1FgKXbouLmZ/Kz/PpRiZqbVIMHAn1PZ9tvYHKOZKVSUKFvIW77REiVwOo MFKnz8GYP2Y6B0NuInX78RmI/B+0tPlK8S+QYORrOd1ysa+Yo90tlSPKRSbCsjSFkJjz 1Q7FKBUBOmSUhiRzX2ail/OLjjP+uEpVZTrLXUVfbGmNawXpR/w2119D59F5yY7nvLXe aGRg== 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=z5Ud6uisWD7X9Y/i9TAk/C0LWKeGghU9PtdCs1wyJhg=; b=TgPfl0YbROVi3yCam1hQvuMN4KVJLRNZd26SgwoqxHuNN0AeVWQC7K4jtTXJeF2LrD hzhgLOfMHYPsXpsbm00D8w+DsCwu0F5xyidR0SQ9ezHU4EiPhNTKYc7L8EZ+YzmZRRtr 6Jce0RRGLmcoqKt/zEuWdgz64zGs4vzOHJ5hgqi+LVbMIaTl+mQPV76t9QoYAWr4AArX zLotHdZkNR8hGdnuN3Z1qDzCXS9HY59DtapVLdSRgLWytq72gp22C2ovm6jzhQLPkQRB tnfW7O686R5IeeFqDV01oM38hrRDV19/ktPjT6kL1YmZGNBKthQXfEJ+Phj2jyQ/9r8S E5Vw== X-Gm-Message-State: ALyK8tIsPJqJ+4RIw9PZkmitJeacLFAQkXoF6MLl+UFxiuIBe/nxy5qBGwmMR0JIp6hK8J/ada90zJoB49h52A== X-Received: by 10.157.37.6 with SMTP id k6mr9078604otb.115.1465240254315; Mon, 06 Jun 2016 12:10:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Mon, 6 Jun 2016 12:10:53 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Dave Taht Date: Mon, 6 Jun 2016 12:10:53 -0700 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a1140a4aade865e0534a0d4a0 Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Revised 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, 06 Jun 2016 19:10:59 -0000 --001a1140a4aade865e0534a0d4a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas wrote: > Good point. I've updated it. > Any other comments or changes before I push the button for external revie= w? > No objections here, aside from the fact I haven't seen PIM actually work in years and years... > Thanks, > Alia > > On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake wrote= : > >> Hi Alia, >> >> This looks good to me. However, the word "even" in the following line >> reads a bit odd and I would delete it.... >> >> multicast. It may even include discussion and consultation with the PIM >> >> 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 >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote: >> >>> Incidentally, >>> >>> https://datatracker.ietf.org/doc/charter-ietf-babel/history/ >>> >>> is very useful for looking at the differences between charters. >>> >>> Alia >>> >>> On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote: >>> >>>> Hi Donald, Russ, Juliusz, Toke, etc., >>>> >>>> I have read through all the discussion and IESG comments on the charte= r. >>>> Here is what I have for an updated version. I do need to get it out >>>> for External >>>> Review soon so that it can come back onto the IESG telechat for final >>>> approval. >>>> The External Review is to give time for comments by those not on the >>>> IESG or >>>> WG - and particularly that it goes out to other organizations who migh= t >>>> be >>>> interested. In the case of Babel, that is relevant because of the >>>> potential interaction >>>> with the Broadband Forum on TR-069. >>>> >>>> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I >>>> am including the text below. >>>> >>>> =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=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=3D=3D=3D >>>> >>>> Babel is a loop-avoiding, distance vector routing protocol with good >>>> provisions for dynamically computed link metrics. It is robust even in >>>> the presence of link metric oscillations and the failure of >>>> transitivity. The core of the Babel protocol and security extensions >>>> are described in Experimental Independent Stream RFCs 6126, 7557, and >>>> 7298. >>>> >>>> These RFCs are the basis of three independent, open source >>>> implementations. There is some production deployment of these >>>> implementations, notably in hybrid networks (networks that include >>>> classical, wired parts with meshy radio bits) and in global overlay >>>> networks (networks built out of large numbers of tunnels spanning >>>> continents). >>>> >>>> The Working Group will focus on moving the Babel protocol to IETF >>>> Proposed Standard with IETF review. This includes clarifying RFC 6126 >>>> and integrating RFC 7557 and feedback provided by independent >>>> implementations, and resolving comments. It is not a requirement that >>>> the Babel protocol produced is backwards compatible with RFC 6126. It >>>> is a requirement that Babel support at least one profile that is >>>> auto-configuring. Other documents that are relevant to the above work >>>> can also be produced. Particular emphasis will be placed >>>> on work needed for a Proposed Standard routing protocol, such as >>>> ensuring manageability and strong security. Link metric measurement or >>>> link metric calculation procedures significantly more complex that >>>> those currently in Babel are out of scope. >>>> >>>> Work Items: >>>> >>>> - Produce a revision of RFC 6126 suitable for publication as a >>>> Proposed Standard >>>> -- incorporate in the revision developments since RFC 6126 >>>> -- resolve technical issues found >>>> -- include in the base specification the extensibility work in >>>> RFC 7557 >>>> -- support auto-configuration >>>> -- consider any important changes based on experience with Babel to >>>> date. >>>> >>>> - Address security needs for BABEL. This may include using the >>>> techniques in RFC 7298, or other alternatives. Security may be >>>> included in the base spec or the base spec may normatively reference a >>>> separate Proposed Standard specification. This is required as part of >>>> moving Babel to Proposed Standard. >>>> >>>> - Address manageability of Babel by producing an informational model >>>> for use by other network management such as the Broadband Forum >>>> TR-069, and a YANG data module based on that information model. This >>>> YANG data module to be consistent with the ongoing effort to use YANG >>>> data modules in the Routing Area. This work is required as part of >>>> moving Babel to Proposed Standard. >>>> >>>> - As the Proposed Standard version of Babel is completed, an >>>> Applicability Statement should be finalized to guide those potentially >>>> interested in deploying Babel. This Applicability Statement may >>>> include deployment advice and will be published as an RFC. >>>> >>>> - Coordinate with other Working Groups, such as the HOMENET WG for >>>> likely applicability, the RTGWG and V6OPS WG about Source-Specific >>>> Routing to support IPv6 multihoming, the PIM WG for discussion around >>>> multicast, and the MANET WG for considerations around wireless. >>>> >>>> - Liaise as necessary with the Broadband Forum to facilitate use of th= e >>>> Babel management Information Model for TR-069. >>>> >>>> - The Working Group should document its ongoing implementation >>>> experience with Babel, so that new WG participants can understand the >>>> state that is driving this work and the experience driving changes. >>>> This documentation may be on the Working Group's wiki, in >>>> an internet-draft that isn't expected to be published as an RFC, or a >>>> combination. >>>> >>>> - As a secondary focus, the Working Group may work on multicast >>>> aspects of Babel. This may include discussion of any potential issues >>>> for supporting Babel running with PIM-SM in an auto-configuration >>>> profile. It may include exploring Babel carrying separate metrics for >>>> multicast. It may even include discussion and consultation with the P= IM >>>> WG about Babel providing the ability to build multicast routing >>>> tables. With AD and WG agreement, once an approach is understood, >>>> then a milestone may be added for an associated document targeted as >>>> Proposed Standard. >>>> >>>> - As a secondary focus, the Working Group may work on documents >>>> defining source specific routing extensions for Babel as a way of >>>> handling >>>> IPv6 multihoming. >>>> >>>> Thus, the Working Group will produce a Proposed Standard Babel >>>> specification, including or paired with a suitable Proposed Standard >>>> specification covering the security mechanism(s) for BABEL. It will >>>> also produce a management information and data model for BABEL as a >>>> Proposed Standard RFC. An applicability statement will be produced as >>>> an Informational RFC. >>>> >>>> *Proposed Milestones* >>>> DateMilestone >>>> Aug 2017 IESG Submission of Babel Applicability draft >>>> Jul 2017 IESG Submission of Babel Management draft >>>> Jul 2017 IESG Submission of RFC6126bis and potentially companion >>>> security mechanisms draft >>>> Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) >>>> draft >>>> Jul 2016 WG adoption of RFC6126bis >>>> Jul 2016 WG adoption of Babel Applicability draft >>>> draft-chroboczek-babel-applicability >>>> >>>> >>>> >>>> =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=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=3D=3D=3D >>>> >>>> >>>> >>>> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < >>>> jch@pps.univ-paris-diderot.fr> wrote: >>>> >>>>> > - The working group is encouraged to keep its wiki updated with >>>>> > implementation experience with Babel so that new WG participants ca= n >>>>> > understand the state that is driving this work and the experience >>>>> > driving changes. >>>>> >>>>> Do we really need to specify the technology used for this information= ? >>>>> What about >>>>> >>>>> "to keep its wiki updated with implementation experience" -> "to >>>>> maintain up-to-date, publicly accessible information about >>>>> implementation experience" >>>>> >>>>> Then the WG can choose whether to do a wiki page, an internet-draft, = or >>>>> whatever else we find convenient. >>>>> >>>>> -- Juliusz >>>>> >>>> >>>> >>> >> > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org --001a1140a4aade865e0534a0d4a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas <akatlas@gmail.com><= /span> wrote:
Good point= .=C2=A0 I've updated it.
Any other comments or changes before I pus= h the button for external review?

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

On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake <d3e3e3@gmail.com= > wrote:
H= i Alia,

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

multicast.=C2=A0 It may even = include discussion and consultation with the PIM

Thanks,
Dona= ld
=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=A0= d3e3e3@gmail.com<= /div>

On Fri, Jun 3, 2016 at 4:40= PM, Alia Atlas <akatlas@gmail.com> wrote:
Incidentally,


is very useful for looking at the differences b= etween charters.

Ali= a

On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas <akatlas@gm= ail.com> wrote:
Hi Donald, Russ, Juliusz, Toke, etc.,

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



Babel is a loop-av= oiding, distance vector routing protocol with good
provisions for dynami= cally computed link metrics. It is robust even in
the presence of link m= etric oscillations and the failure of
transitivity. The core of the Babe= l protocol and security extensions
are described in Experimental Indepen= dent Stream RFCs 6126, 7557, and
7298.

These RFCs are the basis o= f three independent, open source
implementations. There is some producti= on deployment of these
implementations, notably in hybrid networks (netw= orks that include
classical, wired parts with meshy radio bits) and in g= lobal overlay
networks (networks built out of large numbers of tunnels s= panning
continents).

The Working Group will focus on moving the B= abel protocol to IETF
Proposed Standard with IETF review.=C2=A0 This inc= ludes clarifying RFC 6126
and integrating RFC 7557 and feedback provided= by independent
implementations, and resolving comments. It is not a req= uirement that
the Babel protocol produced is backwards compatible with R= FC 6126.=C2=A0 It
is a requirement that Babel support at least one profi= le that is
auto-configuring.=C2=A0 Other documents that are relevant to = the above work
can also be produced. Particular emphasis will be placed<= br>on work needed for a Proposed Standard routing protocol, such as
ensu= ring manageability and strong security. Link metric measurement or
link = metric calculation procedures significantly more complex that
those curr= ently in Babel are out of scope.

Work Items:

- Produce a revi= sion of RFC 6126 suitable for publication as a
Proposed Standard
-- i= ncorporate in the revision developments since RFC 6126
-- resolve techni= cal issues found
-- include in the base specification the extensibility = work in
RFC 7557
-- support auto-configuration
-- consider any imp= ortant changes based on experience with Babel to
date.

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

- Address manageability of Babel by producing an informational m= odel
for use by other network management such as the Broadband Forum
= TR-069, and a YANG data module based on that information model. This
YAN= G data module to be consistent with the ongoing effort to use YANG
data = modules in the Routing Area. This work is required as part of
moving Bab= el to Proposed Standard.

- As the Proposed Standard version of Babel= is completed, an
Applicability Statement should be finalized to guide t= hose potentially
interested in deploying Babel. This Applicability State= ment may
include deployment advice and will be published as an RFC.
<= br>- Coordinate with other Working Groups, such as the HOMENET WG for
li= kely applicability, the RTGWG and V6OPS WG about Source-Specific
Routing= to support IPv6 multihoming, the PIM WG for discussion around
multicast= , and the MANET WG for considerations around wireless.

- Liaise as n= ecessary with the Broadband Forum to facilitate use of the
Babel manage= ment Information Model for TR-069.

- The Working Group should docume= nt its ongoing implementation
experience with Babel, so that new WG part= icipants can understand the
state that is driving this work and th= e experience driving changes.
This documentation may be on the Wo= rking Group's wiki, in
an internet-draft that isn't expected to= be published as an RFC, or a
combination.

- As a secondary focu= s, the Working Group may work on multicast
aspects of Babel.=C2=A0 This = may include discussion of any potential issues
for supporting Babel runn= ing with PIM-SM in an auto-configuration
profile.=C2=A0 It may include e= xploring Babel carrying separate metrics for
multicast.=C2=A0 It may eve= n include discussion and consultation with the PIM
WG about Babel provid= ing the ability to build multicast routing
tables.=C2=A0 With AD and WG = agreement, once an approach is understood,
then a milestone may be added= for an associated document targeted as
Proposed Standard.

- As a= secondary focus, the Working Group may work on documents
defining sourc= e specific routing extensions for Babel as a way of handling
IPv6 multih= oming.

Thus, the Working Group will produce a Proposed Standard Babe= l
specification, including or paired with a suitable Proposed Standardspecification covering the security mechanism(s) for BABEL. It will
al= so produce a management information and data model for BABEL as a
Propos= ed Standard RFC. An applicability statement will be produced as
an Infor= mational RFC.

Proposed Milestones
Milestone<= td style=3D"padding:3px;white-space:nowrap;line-height:1.42857;vertical-ali= gn:top;border-top-width:1px;border-top-style:solid;border-top-color:rgb(221= ,221,221)">Jul 2017
Date
Aug 2017IESG Submission of Babel A= pplicability draft
Jul 2017IESG Submission of Babel = Management draft
IESG Submission of RFC6126bis and potentially companion se= curity mechanisms draft
Oct 2016WG adoption of Babel= Management (Info Model & YANG Model) draft
Jul 2016WG adoption of RFC6126bis
Jul 2016WG adoption of Babel Applicability draft=C2= =A0
draft-chroboczek-babel-applicability=


=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=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=3D=3D=3D



On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek <= jch@pps.= univ-paris-diderot.fr> wrote:
> - The working group is encouraged to keep its wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz





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




--
Dave T=C3=A4htLet's go make home routers and wifi faster! With better software!
<= a href=3D"http://blog.cerowrt.org" target=3D"_blank">http://blog.cerowrt.or= g
--001a1140a4aade865e0534a0d4a0-- From nobody Mon Jun 6 12:21: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 4C60B12B02C; Mon, 6 Jun 2016 12:20:58 -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 zkjMipgMTd6z; Mon, 6 Jun 2016 12:20:56 -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 052E912B02A; Mon, 6 Jun 2016 12:20:56 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h19so149683932ywc.0; Mon, 06 Jun 2016 12:20:55 -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=hHuibmGbqRJ7iMnhHiioul34xYmZ+t0y5rBgFXpx3Qs=; b=mRajS5bDUDHdeVTDqbkX1/5XreuZoIItnSHTHuh6c0rfm3aniZHZvPHYrJk/vRiak9 nZtGNC5xCBYllm3eheK7R3kWJpty6c1b2O/VRSVMSoyos8ybyebE2wJdjSKkr4ME+HKY ZRhI4PW1Uyth4tQU0cKHHDZN9FeF3PPvf/JqUApeUvkePSb7pBQG/Hl43U7Q0B7uIDg2 Ld/3d+hXyECovSmpZif2+C/R0O5dMFgsSmBA8WRoJRIZaPjnnf6+mVXtfsqZ3diURcKV NO05nNcEz1dSAdb6RJU88FXQDQHj0rZtpGUKIOJA4uFuxu/EuAKQ1yQLG357YP2yGQUf eQTA== 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=hHuibmGbqRJ7iMnhHiioul34xYmZ+t0y5rBgFXpx3Qs=; b=RiLMtuTPeKDIPl1OUeOdRM+8g0mwB3poIp6/XJRZqrutb8VxrCSb+jFa022QXlvCrN SezdeFntd2eMRRoFNfc8o1qRMcF0Uhip5D51d+skUPJS0EFMggrKwv8XzAt3qG/VxE12 I+ibHe3ECJb6FJ/j0wsGeZfpvuDM7ztbbCjc2vW+lhAITqOjTI73iSO0qiExS0Et3FL3 yzt2O9xtp6w1GwHVwArncvyDfljTC0DCPRenqIQL03j4nqntRY5+cdTiHDJ+0x9QARPO pORfKyDmRrzjROynavcQULy1njBekxl99Q6nDHFXCbDruMHbe+4DMZ6S3m3ASqSMI/xK uAWw== X-Gm-Message-State: ALyK8tLx2bCzf2Ac0D4LS3Bo0FOEtqN/gGNpIbhlOTnvA4RLYMO0VAnRXGMzB2KtPEkfYsNuxAGq5iCID7l/Qw== X-Received: by 10.13.254.130 with SMTP id o124mr12992823ywf.30.1465240855264; Mon, 06 Jun 2016 12:20:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.74 with HTTP; Mon, 6 Jun 2016 12:20:54 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Alia Atlas Date: Mon, 6 Jun 2016 15:20:54 -0400 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=94eb2c06c36eb046340534a0f8d5 Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Revised 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, 06 Jun 2016 19:20:58 -0000 --94eb2c06c36eb046340534a0f8d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 6, 2016 at 3:10 PM, Dave Taht wrote: > > > On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas wrote: > >> Good point. I've updated it. >> Any other comments or changes before I push the button for external >> review? >> > > No objections here, aside from the fact I haven't seen PIM actually work > in years and years... > The most recent version - with the clarification around management I discussed with Benoit and Barbara is at: https://datatracker.ietf.org/doc/charter-ietf-babel/ As far as PIM, there are a lot of active deployments. Whether they require more management than is desirable is an interesting question. There's obviously the work in BIER that involves an additional encapsulation. There's also work in TRILL that uses IS-IS and builds multicast trees. I don't have an opinion; I'd like the WG to be able to discuss and determine what is needed for the real use-cases. Given that anything you do here will be backed up by running code and testing it out, I'm comfortable leaving flexibility for discussion. Regards, Alia > > >> Thanks, >> Alia >> >> On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake >> wrote: >> >>> Hi Alia, >>> >>> This looks good to me. However, the word "even" in the following line >>> reads a bit odd and I would delete it.... >>> >>> multicast. It may even include discussion and consultation with the PI= M >>> >>> 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 >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> d3e3e3@gmail.com >>> >>> On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote: >>> >>>> Incidentally, >>>> >>>> https://datatracker.ietf.org/doc/charter-ietf-babel/history/ >>>> >>>> is very useful for looking at the differences between charters. >>>> >>>> Alia >>>> >>>> On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote: >>>> >>>>> Hi Donald, Russ, Juliusz, Toke, etc., >>>>> >>>>> I have read through all the discussion and IESG comments on the >>>>> charter. >>>>> Here is what I have for an updated version. I do need to get it out >>>>> for External >>>>> Review soon so that it can come back onto the IESG telechat for final >>>>> approval. >>>>> The External Review is to give time for comments by those not on the >>>>> IESG or >>>>> WG - and particularly that it goes out to other organizations who >>>>> might be >>>>> interested. In the case of Babel, that is relevant because of the >>>>> potential interaction >>>>> with the Broadband Forum on TR-069. >>>>> >>>>> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I >>>>> am including the text below. >>>>> >>>>> =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=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=3D=3D=3D >>>>> >>>>> Babel is a loop-avoiding, distance vector routing protocol with good >>>>> provisions for dynamically computed link metrics. It is robust even i= n >>>>> the presence of link metric oscillations and the failure of >>>>> transitivity. The core of the Babel protocol and security extensions >>>>> are described in Experimental Independent Stream RFCs 6126, 7557, and >>>>> 7298. >>>>> >>>>> These RFCs are the basis of three independent, open source >>>>> implementations. There is some production deployment of these >>>>> implementations, notably in hybrid networks (networks that include >>>>> classical, wired parts with meshy radio bits) and in global overlay >>>>> networks (networks built out of large numbers of tunnels spanning >>>>> continents). >>>>> >>>>> The Working Group will focus on moving the Babel protocol to IETF >>>>> Proposed Standard with IETF review. This includes clarifying RFC 612= 6 >>>>> and integrating RFC 7557 and feedback provided by independent >>>>> implementations, and resolving comments. It is not a requirement that >>>>> the Babel protocol produced is backwards compatible with RFC 6126. I= t >>>>> is a requirement that Babel support at least one profile that is >>>>> auto-configuring. Other documents that are relevant to the above wor= k >>>>> can also be produced. Particular emphasis will be placed >>>>> on work needed for a Proposed Standard routing protocol, such as >>>>> ensuring manageability and strong security. Link metric measurement o= r >>>>> link metric calculation procedures significantly more complex that >>>>> those currently in Babel are out of scope. >>>>> >>>>> Work Items: >>>>> >>>>> - Produce a revision of RFC 6126 suitable for publication as a >>>>> Proposed Standard >>>>> -- incorporate in the revision developments since RFC 6126 >>>>> -- resolve technical issues found >>>>> -- include in the base specification the extensibility work in >>>>> RFC 7557 >>>>> -- support auto-configuration >>>>> -- consider any important changes based on experience with Babel to >>>>> date. >>>>> >>>>> - Address security needs for BABEL. This may include using the >>>>> techniques in RFC 7298, or other alternatives. Security may be >>>>> included in the base spec or the base spec may normatively reference = a >>>>> separate Proposed Standard specification. This is required as part of >>>>> moving Babel to Proposed Standard. >>>>> >>>>> - Address manageability of Babel by producing an informational model >>>>> for use by other network management such as the Broadband Forum >>>>> TR-069, and a YANG data module based on that information model. This >>>>> YANG data module to be consistent with the ongoing effort to use YANG >>>>> data modules in the Routing Area. This work is required as part of >>>>> moving Babel to Proposed Standard. >>>>> >>>>> - As the Proposed Standard version of Babel is completed, an >>>>> Applicability Statement should be finalized to guide those potentiall= y >>>>> interested in deploying Babel. This Applicability Statement may >>>>> include deployment advice and will be published as an RFC. >>>>> >>>>> - Coordinate with other Working Groups, such as the HOMENET WG for >>>>> likely applicability, the RTGWG and V6OPS WG about Source-Specific >>>>> Routing to support IPv6 multihoming, the PIM WG for discussion around >>>>> multicast, and the MANET WG for considerations around wireless. >>>>> >>>>> - Liaise as necessary with the Broadband Forum to facilitate use of >>>>> the >>>>> Babel management Information Model for TR-069. >>>>> >>>>> - The Working Group should document its ongoing implementation >>>>> experience with Babel, so that new WG participants can understand the >>>>> state that is driving this work and the experience driving changes. >>>>> This documentation may be on the Working Group's wiki, in >>>>> an internet-draft that isn't expected to be published as an RFC, or a >>>>> combination. >>>>> >>>>> - As a secondary focus, the Working Group may work on multicast >>>>> aspects of Babel. This may include discussion of any potential issue= s >>>>> for supporting Babel running with PIM-SM in an auto-configuration >>>>> profile. It may include exploring Babel carrying separate metrics fo= r >>>>> multicast. It may even include discussion and consultation with the >>>>> PIM >>>>> WG about Babel providing the ability to build multicast routing >>>>> tables. With AD and WG agreement, once an approach is understood, >>>>> then a milestone may be added for an associated document targeted as >>>>> Proposed Standard. >>>>> >>>>> - As a secondary focus, the Working Group may work on documents >>>>> defining source specific routing extensions for Babel as a way of >>>>> handling >>>>> IPv6 multihoming. >>>>> >>>>> Thus, the Working Group will produce a Proposed Standard Babel >>>>> specification, including or paired with a suitable Proposed Standard >>>>> specification covering the security mechanism(s) for BABEL. It will >>>>> also produce a management information and data model for BABEL as a >>>>> Proposed Standard RFC. An applicability statement will be produced as >>>>> an Informational RFC. >>>>> >>>>> *Proposed Milestones* >>>>> DateMilestone >>>>> Aug 2017 IESG Submission of Babel Applicability draft >>>>> Jul 2017 IESG Submission of Babel Management draft >>>>> Jul 2017 IESG Submission of RFC6126bis and potentially companion >>>>> security mechanisms draft >>>>> Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) >>>>> draft >>>>> Jul 2016 WG adoption of RFC6126bis >>>>> Jul 2016 WG adoption of Babel Applicability draft >>>>> draft-chroboczek-babel-applicability >>>>> >>>>> >>>>> >>>>> =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=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=3D=3D=3D >>>>> >>>>> >>>>> >>>>> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < >>>>> jch@pps.univ-paris-diderot.fr> wrote: >>>>> >>>>>> > - The working group is encouraged to keep its wiki updated with >>>>>> > implementation experience with Babel so that new WG participants c= an >>>>>> > understand the state that is driving this work and the experience >>>>>> > driving changes. >>>>>> >>>>>> Do we really need to specify the technology used for this informatio= n? >>>>>> What about >>>>>> >>>>>> "to keep its wiki updated with implementation experience" -> "to >>>>>> maintain up-to-date, publicly accessible information about >>>>>> implementation experience" >>>>>> >>>>>> Then the WG can choose whether to do a wiki page, an internet-draft, >>>>>> or >>>>>> whatever else we find convenient. >>>>>> >>>>>> -- Juliusz >>>>>> >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >> >> > > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > --94eb2c06c36eb046340534a0f8d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 6, 2016 at 3:10 PM, Dave Taht <dave.taht@gmail.com> wrote:


On Mon, Jun 6, 2016 at 6:= 58 AM, Alia Atlas <akatlas@gmail.com> wrote:
Good point.=C2=A0 I've updated it.
Any other = comments or changes before I push the button for external review?

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

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

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

Regards,
Alia

= =C2=A0
=C2=A0
=C2=A0
Thanks,
Alia

= On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake <d3e3e3@gmail.com><= /span> wrote:
Hi Alia,

<= div>This looks good to me. However, the word "even" in the follow= ing line reads a bit odd and I would delete it....

multicast.=C2=A0 It may even include discussio= n and consultation with the PIM

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

On Fri, Jun 3, 2016 at 4:40= PM, Alia Atlas <akatlas@gmail.com> wrote:
Incidentally,

is very useful for looking at the differences between charters= .

Alia
<= /span>

On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas <akatlas@gmail.com>= wrote:
Hi Donald, Russ, Julius= z, Toke, etc.,

I have read through all the discussion an= d IESG comments on the charter.
Here is what I have for an update= d version.=C2=A0 I do need to get it out for External
Review soon= so that it can come back onto the IESG telechat for final approval.
<= div>The External Review is to give time for comments by those not on the IE= SG or
WG - and particularly that it goes out to other organizatio= ns who might be
interested.=C2=A0 In the case of Babel, that is r= elevant because of the potential interaction
with the Broadband F= orum on TR-069.

The link is=C2=A0https://d= atatracker.ietf.org/doc/charter-ietf-babel/ .=C2=A0 I am including the = text below.

=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=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= =3D=3D=3D

Babel is a loop-avoiding, distance vector rou= ting protocol with good
provisions for dynamically computed link metrics= . It is robust even in
the presence of link metric oscillations and the = failure of
transitivity. The core of the Babel protocol and security ext= ensions
are described in Experimental Independent Stream RFCs 6126, 7557= , and
7298.

These RFCs are the basis of three independent, open s= ource
implementations. There is some production deployment of these
i= mplementations, notably in hybrid networks (networks that include
classi= cal, wired parts with meshy radio bits) and in global overlay
networks (= networks built out of large numbers of tunnels spanning
continents).
=
The Working Group will focus on moving the Babel protocol to IETF
Pr= oposed Standard with IETF review.=C2=A0 This includes clarifying RFC 6126and integrating RFC 7557 and feedback provided by independent
implemen= tations, and resolving comments. It is not a requirement that
the Babel = protocol produced is backwards compatible with RFC 6126.=C2=A0 It
is a r= equirement that Babel support at least one profile that is
auto-configur= ing.=C2=A0 Other documents that are relevant to the above work
can also = be produced. Particular emphasis will be placed
on work needed for a Pro= posed Standard routing protocol, such as
ensuring manageability and stro= ng security. Link metric measurement or
link metric calculation procedur= es significantly more complex that
those currently in Babel are out of s= cope.

Work Items:

- Produce a revision of RFC 6126 suitable f= or publication as a
Proposed Standard
-- incorporate in the revision = developments since RFC 6126
-- resolve technical issues found
-- incl= ude in the base specification the extensibility work in
RFC 7557
-- s= upport auto-configuration
-- consider any important changes based on exp= erience with Babel to
date.

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

- Address manage= ability of Babel by producing an informational model
for use by other ne= twork management such as the Broadband Forum
TR-069, and a YANG data mod= ule based on that information model. This
YANG data module to be consist= ent with the ongoing effort to use YANG
data modules in the Routing Area= . This work is required as part of
moving Babel to Proposed Standard.
- As the Proposed Standard version of Babel is completed, an
Applic= ability Statement should be finalized to guide those potentially
interes= ted in deploying Babel. This Applicability Statement may
include deploym= ent advice and will be published as an RFC.

- Coordinate with other = Working Groups, such as the HOMENET WG for
likely applicability, the RTG= WG and V6OPS WG about Source-Specific
Routing to support IPv6 multihomin= g, the PIM WG for discussion around
multicast, and the MANET WG for cons= iderations around wireless.

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

- The Working Group should document its ongoing implementati= on
experience with Babel, so that new WG participants can understand the=
state that is driving this work and the experience driving change= s.
This documentation may be on the Working Group's wiki, in =
an internet-draft that isn't expected to be published as an RFC, or= a
combination.

- As a secondary focus, the Working Group may wo= rk on multicast
aspects of Babel.=C2=A0 This may include discussion of a= ny potential issues
for supporting Babel running with PIM-SM in an auto-= configuration
profile.=C2=A0 It may include exploring Babel carrying sep= arate metrics for
multicast.=C2=A0 It may even include discussion and co= nsultation with the PIM
WG about Babel providing the ability to build mu= lticast routing
tables.=C2=A0 With AD and WG agreement, once an approach= is understood,
then a milestone may be added for an associated document= targeted as
Proposed Standard.

- As a secondary focus, the Worki= ng Group may work on documents
defining source specific routing extensio= ns for Babel as a way of handling
IPv6 multihoming.

Thus, the Wor= king Group will produce a Proposed Standard Babel
specification, includi= ng or paired with a suitable Proposed Standard
specification covering th= e security mechanism(s) for BABEL. It will
also produce a management inf= ormation and data model for BABEL as a
Proposed Standard RFC. An applica= bility statement will be produced as
an Informational RFC.

Pro= posed Milestones
= <= tr style=3D"background-color:rgb(249,249,249)">IESG Submi= ssion of RFC6126bis and potentially companion security mechanisms draft
DateMil= estone
Aug 2017IESG Submission of Babel Applicability draft
Jul 2017IESG Submission of Babel Management draft
Jul 2017
Oct 2016WG adoption of Babel Management (Info Model &am= p; YANG Model) draft
Jul 2016WG adoption of RFC6126bis
Jul= 2016WG adoption of Babel Applicability draft=C2=A0
draft-chroboczek-babel-applicability


=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=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= =3D=3D=3D



On Thu, Jun 2, 2016 at 2:= 39 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr&g= t; wrote:
> - The working group is encouraged= to keep its wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz





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




--
Da= ve T=C3=A4ht
Let's go make home routers and wifi faster! With better= software!
http://= blog.cerowrt.org
--94eb2c06c36eb046340534a0f8d5-- From nobody Mon Jun 6 12:31: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 C8EA212D5C9; Mon, 6 Jun 2016 12:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, FSL_HELO_HOME=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 8ybUKmualbjO; Mon, 6 Jun 2016 12:31:24 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 0CAF012D197; Mon, 6 Jun 2016 12:31:23 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id o16so149884085ywd.2; Mon, 06 Jun 2016 12:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t91QBabRVsXRsx6nQEfkhtGu2sDlhZ6FXTda480+/W0=; b=u+PaCpbfy60vT9o7Qk98/POuBwfkSRz8AWaj82ba1Uy/irpQsnUaCYAdPrQdIE+Xge +Ezdomcgb+CbB5+nx2Y8MyIIBYZAvG1jQ/0OZoMcpVMRNf51CPyqjjIgneqAh3bRRAEh NDLP/uNlwnBDvCmqN+2p7MxLHoXFsJSRA0L1gdab9r51RJN1yBrSRGP0nfiQloAiSjHk fDZ4VGRTreLZp8R/UATLFJZmNaM59Z40svqHrobWPGZYLVERxaKtRXkEL9+DaCnZ16xs QyucCRMRbFfscAN1jPJ34cqg9ueBe7TLyhcEAnuXU6tnr5ELFIhQvLgX5Y9MS/ykwPI2 Nl6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=t91QBabRVsXRsx6nQEfkhtGu2sDlhZ6FXTda480+/W0=; b=dDBPwGFvud8IBN0olYZTfaib+uo64KuVZuBvJT0GtV6P/h/Bi+2eDgJ6GFkzSVSPIk yzTVmQaYRWGVZHbKFeD82jnjZrYvS+1cOyWKerny7UWSzqp38M0xqdwvpCZ2c16ZyGXr MI7AKD4B8mqFIHdWWhrRVyBmbo9t29aOpsiS0MunqEE705tZ1lX1Em1jy0gEYKUvhgN1 AfpiFWX1MJjFT0OHjYGmKnX6Qcb6IQhRn0RFfHkQ/npwTpTDzaL5TxO8AJvQ2PmaPLW9 hrf2c9Q5nCGxReeJt8hw2N+oYhJsKoydK+0JyXYzjgb5xQ6rKdeSqHVlGQIl8NvscQUv Punw== X-Gm-Message-State: ALyK8tKG1JkkScgDJBumdXuULohlLZba8EypXfarGOJTTOsxezynuD3KQ89yqaz/ekUayQ== X-Received: by 10.129.27.6 with SMTP id b6mr13632817ywb.205.1465241483066; Mon, 06 Jun 2016 12:31:23 -0700 (PDT) Received: from margarets-air-3.home (pool-72-74-19-153.bstnma.fios.verizon.net. [72.74.19.153]) by smtp.gmail.com with ESMTPSA id t65sm12368691ywg.21.2016.06.06.12.31.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Jun 2016 12:31:22 -0700 (PDT) Sender: Margaret Cullen Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Margaret Cullen In-Reply-To: Date: Mon, 6 Jun 2016 15:31:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <645FA361-75D4-417A-AB26-5ACDD2D7C836@gmail.com> References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> To: Dave Taht X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Juliusz Chroboczek , Babel at IETF , Alia Atlas Subject: Re: [babel] Revised 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, 06 Jun 2016 19:31:26 -0000 This looks good to me. Margaret > On Jun 6, 2016, at 3:10 PM, Dave Taht wrote: >=20 >=20 >=20 > On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas wrote: > Good point. I've updated it. > Any other comments or changes before I push the button for external = review? >=20 > No objections here, aside from the fact I haven't seen PIM actually = work in years and years... > =20 > Thanks, > Alia >=20 > On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake = wrote: > Hi Alia, >=20 > This looks good to me. However, the word "even" in the following line = reads a bit odd and I would delete it.... >=20 > multicast. It may even include discussion and consultation with the = PIM >=20 > 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 > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com >=20 > On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote: > Incidentally, >=20 > https://datatracker.ietf.org/doc/charter-ietf-babel/history/ >=20 > is very useful for looking at the differences between charters. >=20 > Alia >=20 > On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote: > Hi Donald, Russ, Juliusz, Toke, etc., >=20 > I have read through all the discussion and IESG comments on the = charter. > Here is what I have for an updated version. I do need to get it out = for External > Review soon so that it can come back onto the IESG telechat for final = approval. > The External Review is to give time for comments by those not on the = IESG or > WG - and particularly that it goes out to other organizations who = might be > interested. In the case of Babel, that is relevant because of the = potential interaction > with the Broadband Forum on TR-069. >=20 > The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I = am including the text below. >=20 > =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=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=3D=3D=3D >=20 > Babel is a loop-avoiding, distance vector routing protocol with good > provisions for dynamically computed link metrics. It is robust even in > the presence of link metric oscillations and the failure of > transitivity. The core of the Babel protocol and security extensions > are described in Experimental Independent Stream RFCs 6126, 7557, and > 7298. >=20 > 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). >=20 > The Working Group will focus on moving the Babel protocol to IETF > Proposed Standard with IETF review. This includes clarifying RFC 6126 > and integrating RFC 7557 and feedback provided by independent > implementations, and resolving comments. It is not a requirement that > the Babel protocol produced is backwards compatible with RFC 6126. It > is a requirement that Babel support at least one profile that is > auto-configuring. Other documents that are relevant to the above work > can also be produced. Particular emphasis will be placed > on work needed for a Proposed Standard routing protocol, such as > ensuring manageability and strong security. Link metric measurement or > link metric calculation procedures significantly more complex that > those currently in Babel are out of scope. >=20 > Work Items: >=20 > - Produce a revision of RFC 6126 suitable for publication as a > Proposed Standard > -- incorporate in the revision developments since RFC 6126 > -- resolve technical issues found > -- include in the base specification the extensibility work in > RFC 7557 > -- support auto-configuration > -- consider any important changes based on experience with Babel to > date. >=20 > - Address security needs for BABEL. This may include using the > techniques in RFC 7298, or other alternatives. Security may be > included in the base spec or the base spec may normatively reference a > separate Proposed Standard specification. This is required as part of > moving Babel to Proposed Standard. >=20 > - Address manageability of Babel by producing an informational model > for use by other network management such as the Broadband Forum > TR-069, and a YANG data module based on that information model. This > YANG data module to be consistent with the ongoing effort to use YANG > data modules in the Routing Area. This work is required as part of > moving Babel to Proposed Standard. >=20 > - 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. >=20 > - Coordinate with other Working Groups, such as the HOMENET WG for > likely applicability, the RTGWG and V6OPS WG about Source-Specific > Routing to support IPv6 multihoming, the PIM WG for discussion around > multicast, and the MANET WG for considerations around wireless. >=20 > - Liaise as necessary with the Broadband Forum to facilitate use of = the=20 > Babel management Information Model for TR-069. >=20 > - The Working Group should document its ongoing implementation > experience with Babel, so that new WG participants can understand the > state that is driving this work and the experience driving changes. > This documentation may be on the Working Group's wiki, in=20 > an internet-draft that isn't expected to be published as an RFC, or a > combination.=20 >=20 > - As a secondary focus, the Working Group may work on multicast > aspects of Babel. This may include discussion of any potential issues > for supporting Babel running with PIM-SM in an auto-configuration > profile. It may include exploring Babel carrying separate metrics for > multicast. It may even include discussion and consultation with the = PIM > WG about Babel providing the ability to build multicast routing > tables. With AD and WG agreement, once an approach is understood, > then a milestone may be added for an associated document targeted as > Proposed Standard. >=20 > - As a secondary focus, the Working Group may work on documents > defining source specific routing extensions for Babel as a way of = handling > IPv6 multihoming. >=20 > Thus, the Working Group will produce a Proposed Standard Babel > specification, including or paired with a suitable Proposed Standard > specification covering the security mechanism(s) for BABEL. It will > also produce a management information and data model for BABEL as a > Proposed Standard RFC. An applicability statement will be produced as > an Informational RFC. >=20 > Proposed Milestones > Date Milestone > Aug 2017 IESG Submission of Babel Applicability draft > Jul 2017 IESG Submission of Babel Management draft > Jul 2017 IESG Submission of RFC6126bis and potentially companion = security mechanisms draft > Oct 2016 WG adoption of Babel Management (Info Model & YANG = Model) draft > Jul 2016 WG adoption of RFC6126bis > Jul 2016 WG adoption of Babel Applicability draft=20 > draft-chroboczek-babel-applicability >=20 >=20 > =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=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=3D=3D=3D >=20 >=20 >=20 > On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek = wrote: > > - 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. >=20 > Do we really need to specify the technology used for this information? > What about >=20 > "to keep its wiki updated with implementation experience" -> "to > maintain up-to-date, publicly accessible information about > implementation experience" >=20 > Then the WG can choose whether to do a wiki page, an internet-draft, = or > whatever else we find convenient. >=20 > -- Juliusz >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel >=20 >=20 >=20 >=20 > --=20 > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Jun 6 12:40: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 CA39712D8CD; Mon, 6 Jun 2016 12:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 k3bpdRZTTHQV; Mon, 6 Jun 2016 12:39:57 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 ADCE512D11B; Mon, 6 Jun 2016 12:39:57 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id s139so3791976oie.2; Mon, 06 Jun 2016 12:39: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=kB+5CtggB+lfyHUMbrkGZX/itoIIyWNPXkVq31XW1kg=; b=Im5Wc6wL1lauq9mYAYqyuN39BmUYuLFHoMp5p3rHqiH+RCJHKZk/H9b9rejfE8RMB/ N29FbTNmEPYWlQ5ABRo6W3zuPl93nTDowNIDv8AVAEa5q0mhyBG4lzTSpKGsPpoWOAu6 RocesvFtJiTWMFg4ughBBVpdniKXuvJ8+FvAa+B898rvZpQjw6SWbKwEiQrHzKOuGfdb k7KEBJgNhj+NCSBFqCenncwV1sWSOyaKny3FkjjXZEUI0JTtu1LT1EzWhHhjzQReYyxZ 8bmB6MAgBZ7xtPHQ3RwmDcKmvJhsLCYd5FQU3dnaT6upVFSPSocH9+U6EF6On5qaBdth aD8A== 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=kB+5CtggB+lfyHUMbrkGZX/itoIIyWNPXkVq31XW1kg=; b=ZPaMucb9betaZV/nTgAlzMzEsYIhCajk3QXyqEERB1m8A30UqXfPhfmLOUpFu3EXn9 qBPymiSi2iccm8pxrWlXwP2WECseWT1nrMvAlpEw3LC/lxqpy4VvgWTSu0mCL3We0DIa QEE8yXX5BEBQgquCQ1InpK9FctYQmSYpXG6Dy8ezEJbDLgw6mCIliuhmjpVWbBce/1c4 uaNNlLl5W71CBB/pOkvg9kV069HBS3v+/4kTYCnF1qFVIyI8p4RIDmbItLtW4uRBdxyt Z8SUFUi3QSO62dJBnpHk7U5f+/3wfGzoc0rexTfyTyk6+HNOHLL0maUgobcTN1gjoaWG 9fgA== X-Gm-Message-State: ALyK8tL51uaqZW7s2XiaIRIt/JF0/tAwDvQ9Bd297SxjnEwliOF681VI2SexgJygqS1rwolWJ5V/SCgUNqc/+A== X-Received: by 10.202.190.8 with SMTP id o8mr9620752oif.151.1465241996805; Mon, 06 Jun 2016 12:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Mon, 6 Jun 2016 12:39:56 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Dave Taht Date: Mon, 6 Jun 2016 12:39:56 -0700 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113ddbe0bad5c80534a13c5a Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Revised 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, 06 Jun 2016 19:40:00 -0000 --001a113ddbe0bad5c80534a13c5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 6, 2016 at 12:20 PM, Alia Atlas wrote: > On Mon, Jun 6, 2016 at 3:10 PM, Dave Taht wrote: > >> >> >> On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas wrote: >> >>> Good point. I've updated it. >>> Any other comments or changes before I push the button for external >>> review? >>> >> >> No objections here, aside from the fact I haven't seen PIM actually work >> in years and years... >> > > The most recent version - with the clarification around management I > discussed with Benoit and Barbara is at: > https://datatracker.ietf.org/doc/charter-ietf-babel/ > > As far as PIM, there are a lot of active deployments. Whether they > require more management than is desirable is an interesting question. > There's obviously the work in BIER that involves an additional > encapsulation. There's also work in TRILL that uses IS-IS and builds > multicast trees. I don't have an opinion; I'd like the WG to be able to > discuss and determine what is needed for the real use-cases. Given that > anything you do here will be backed up by running code and testing it out= , > I'm comfortable leaving flexibility for discussion. > Given that I don't have any hope for improving multicast behavior inside the current wifi standards, and I don't know where pim would be used inside the home, I don't care. I can see it being used for multicast tv, but over wifi it's a lose. I had made a thrust earlier in these threads for adding into the charter work to make babel (more generally source specific routing) work well on common inside-the-home/small business link layers like moca, homeplug, wifi (802.11, 802.11ad), vpns (more generally, tunnels), and usbnet - as well as interoperating with pending ones like 6lowpan and 5g, but I seem to be alone in that. > > Regards, > Alia > > > > >> >> >>> Thanks, >>> Alia >>> >>> On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake >>> wrote: >>> >>>> Hi Alia, >>>> >>>> This looks good to me. However, the word "even" in the following line >>>> reads a bit odd and I would delete it.... >>>> >>>> multicast. It may even include discussion and consultation with the P= IM >>>> >>>> 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 >>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>> 155 Beaver Street, Milford, MA 01757 USA >>>> d3e3e3@gmail.com >>>> >>>> On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote: >>>> >>>>> Incidentally, >>>>> >>>>> https://datatracker.ietf.org/doc/charter-ietf-babel/history/ >>>>> >>>>> is very useful for looking at the differences between charters. >>>>> >>>>> Alia >>>>> >>>>> On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote: >>>>> >>>>>> Hi Donald, Russ, Juliusz, Toke, etc., >>>>>> >>>>>> I have read through all the discussion and IESG comments on the >>>>>> charter. >>>>>> Here is what I have for an updated version. I do need to get it out >>>>>> for External >>>>>> Review soon so that it can come back onto the IESG telechat for fina= l >>>>>> approval. >>>>>> The External Review is to give time for comments by those not on the >>>>>> IESG or >>>>>> WG - and particularly that it goes out to other organizations who >>>>>> might be >>>>>> interested. In the case of Babel, that is relevant because of the >>>>>> potential interaction >>>>>> with the Broadband Forum on TR-069. >>>>>> >>>>>> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . >>>>>> I am including the text below. >>>>>> >>>>>> =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=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=3D=3D=3D >>>>>> >>>>>> Babel is a loop-avoiding, distance vector routing protocol with good >>>>>> provisions for dynamically computed link metrics. It is robust even = in >>>>>> the presence of link metric oscillations and the failure of >>>>>> transitivity. The core of the Babel protocol and security extensions >>>>>> are described in Experimental Independent Stream RFCs 6126, 7557, an= d >>>>>> 7298. >>>>>> >>>>>> These RFCs are the basis of three independent, open source >>>>>> implementations. There is some production deployment of these >>>>>> implementations, notably in hybrid networks (networks that include >>>>>> classical, wired parts with meshy radio bits) and in global overlay >>>>>> networks (networks built out of large numbers of tunnels spanning >>>>>> continents). >>>>>> >>>>>> The Working Group will focus on moving the Babel protocol to IETF >>>>>> Proposed Standard with IETF review. This includes clarifying RFC 61= 26 >>>>>> and integrating RFC 7557 and feedback provided by independent >>>>>> implementations, and resolving comments. It is not a requirement tha= t >>>>>> the Babel protocol produced is backwards compatible with RFC 6126. = It >>>>>> is a requirement that Babel support at least one profile that is >>>>>> auto-configuring. Other documents that are relevant to the above wo= rk >>>>>> can also be produced. Particular emphasis will be placed >>>>>> on work needed for a Proposed Standard routing protocol, such as >>>>>> ensuring manageability and strong security. Link metric measurement = or >>>>>> link metric calculation procedures significantly more complex that >>>>>> those currently in Babel are out of scope. >>>>>> >>>>>> Work Items: >>>>>> >>>>>> - Produce a revision of RFC 6126 suitable for publication as a >>>>>> Proposed Standard >>>>>> -- incorporate in the revision developments since RFC 6126 >>>>>> -- resolve technical issues found >>>>>> -- include in the base specification the extensibility work in >>>>>> RFC 7557 >>>>>> -- support auto-configuration >>>>>> -- consider any important changes based on experience with Babel to >>>>>> date. >>>>>> >>>>>> - Address security needs for BABEL. This may include using the >>>>>> techniques in RFC 7298, or other alternatives. Security may be >>>>>> included in the base spec or the base spec may normatively reference= a >>>>>> separate Proposed Standard specification. This is required as part o= f >>>>>> moving Babel to Proposed Standard. >>>>>> >>>>>> - Address manageability of Babel by producing an informational model >>>>>> for use by other network management such as the Broadband Forum >>>>>> TR-069, and a YANG data module based on that information model. This >>>>>> YANG data module to be consistent with the ongoing effort to use YAN= G >>>>>> data modules in the Routing Area. This work is required as part of >>>>>> moving Babel to Proposed Standard. >>>>>> >>>>>> - As the Proposed Standard version of Babel is completed, an >>>>>> Applicability Statement should be finalized to guide those potential= ly >>>>>> interested in deploying Babel. This Applicability Statement may >>>>>> include deployment advice and will be published as an RFC. >>>>>> >>>>>> - Coordinate with other Working Groups, such as the HOMENET WG for >>>>>> likely applicability, the RTGWG and V6OPS WG about Source-Specific >>>>>> Routing to support IPv6 multihoming, the PIM WG for discussion aroun= d >>>>>> multicast, and the MANET WG for considerations around wireless. >>>>>> >>>>>> - Liaise as necessary with the Broadband Forum to facilitate use of >>>>>> the >>>>>> Babel management Information Model for TR-069. >>>>>> >>>>>> - The Working Group should document its ongoing implementation >>>>>> experience with Babel, so that new WG participants can understand th= e >>>>>> state that is driving this work and the experience driving changes. >>>>>> This documentation may be on the Working Group's wiki, in >>>>>> an internet-draft that isn't expected to be published as an RFC, or = a >>>>>> combination. >>>>>> >>>>>> - As a secondary focus, the Working Group may work on multicast >>>>>> aspects of Babel. This may include discussion of any potential issu= es >>>>>> for supporting Babel running with PIM-SM in an auto-configuration >>>>>> profile. It may include exploring Babel carrying separate metrics f= or >>>>>> multicast. It may even include discussion and consultation with the >>>>>> PIM >>>>>> WG about Babel providing the ability to build multicast routing >>>>>> tables. With AD and WG agreement, once an approach is understood, >>>>>> then a milestone may be added for an associated document targeted as >>>>>> Proposed Standard. >>>>>> >>>>>> - As a secondary focus, the Working Group may work on documents >>>>>> defining source specific routing extensions for Babel as a way of >>>>>> handling >>>>>> IPv6 multihoming. >>>>>> >>>>>> Thus, the Working Group will produce a Proposed Standard Babel >>>>>> specification, including or paired with a suitable Proposed Standard >>>>>> specification covering the security mechanism(s) for BABEL. It will >>>>>> also produce a management information and data model for BABEL as a >>>>>> Proposed Standard RFC. An applicability statement will be produced a= s >>>>>> an Informational RFC. >>>>>> >>>>>> *Proposed Milestones* >>>>>> DateMilestone >>>>>> Aug 2017 IESG Submission of Babel Applicability draft >>>>>> Jul 2017 IESG Submission of Babel Management draft >>>>>> Jul 2017 IESG Submission of RFC6126bis and potentially companion >>>>>> security mechanisms draft >>>>>> Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) >>>>>> draft >>>>>> Jul 2016 WG adoption of RFC6126bis >>>>>> Jul 2016 WG adoption of Babel Applicability draft >>>>>> draft-chroboczek-babel-applicability >>>>>> >>>>>> >>>>>> >>>>>> =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=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=3D=3D=3D >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < >>>>>> jch@pps.univ-paris-diderot.fr> wrote: >>>>>> >>>>>>> > - The working group is encouraged to keep its wiki updated with >>>>>>> > implementation experience with Babel so that new WG participants >>>>>>> can >>>>>>> > understand the state that is driving this work and the experience >>>>>>> > driving changes. >>>>>>> >>>>>>> Do we really need to specify the technology used for this >>>>>>> information? >>>>>>> What about >>>>>>> >>>>>>> "to keep its wiki updated with implementation experience" -> "to >>>>>>> maintain up-to-date, publicly accessible information about >>>>>>> implementation experience" >>>>>>> >>>>>>> Then the WG can choose whether to do a wiki page, an internet-draft= , >>>>>>> or >>>>>>> whatever else we find convenient. >>>>>>> >>>>>>> -- Juliusz >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> babel mailing list >>> babel@ietf.org >>> https://www.ietf.org/mailman/listinfo/babel >>> >>> >> >> >> -- >> Dave T=C3=A4ht >> Let's go make home routers and wifi faster! With better software! >> http://blog.cerowrt.org >> > > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org --001a113ddbe0bad5c80534a13c5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 6, 2016 at 12:20 PM, Alia Atlas <akatlas@gmail.com>= wrote:
On Mon, Jun 6= , 2016 at 3:10 PM, Dave Taht <dave.taht@gmail.com> wrote:<= br>


On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas <= akatlas@gmail.com> wrote:
Good point.=C2=A0 I've updated it.
Any other comments or changes = before I push the button for external review?
=
No objections here, aside from the fact I haven't= seen PIM actually work in years and years...

The most recent version - with the clarif= ication around management I discussed with Benoit and Barbara is at: =C2=A0= https://datatracker.ietf.org/doc/charter-ietf-babel/
=
As far as PIM, there are a lot of active deployments.=C2=A0 = Whether they require more management than is desirable is an interesting qu= estion.=C2=A0 There's obviously the work in BIER that involves an addit= ional encapsulation.=C2=A0 There's also work in TRILL that uses IS-IS a= nd builds multicast trees.=C2=A0 I don't have an opinion; I'd like = the WG to be able to discuss and determine what is needed for the real use-= cases.=C2=A0 Given that anything you do here will be backed up by running c= ode and testing it out, I'm comfortable leaving flexibility for discuss= ion.

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

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

Regards,
Ali= a

=C2=A0
=C2=A0
=C2=A0
Thanks,
Alia

On Sun, Jun 5, 2016 at 11:34 PM, Donal= d Eastlake <d3e3e3@gmail.com> wrote:
Hi Alia,

This looks good to me. However, th= e word "even" in the following line reads a bit odd and I would d= elete it....

multicast= .=C2=A0 It may even include discussion and consultation with the PIM=

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 3= rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford,= MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Fri, Jun 3, 2016 at 4:40= PM, Alia Atlas <akatlas@gmail.com> wrote:
Incidentally,

is very useful for looking at the differences between charters= .

Alia
<= /span>

On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas <akatlas@gmail.com>= wrote:
Hi Donald, Russ, Julius= z, Toke, etc.,

I have read through all the discussion an= d IESG comments on the charter.
Here is what I have for an update= d version.=C2=A0 I do need to get it out for External
Review soon= so that it can come back onto the IESG telechat for final approval.
<= div>The External Review is to give time for comments by those not on the IE= SG or
WG - and particularly that it goes out to other organizatio= ns who might be
interested.=C2=A0 In the case of Babel, that is r= elevant because of the potential interaction
with the Broadband F= orum on TR-069.

The link is=C2=A0https://d= atatracker.ietf.org/doc/charter-ietf-babel/ .=C2=A0 I am including the = text below.

=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=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= =3D=3D=3D

Babel is a loop-avoiding, distance vector rou= ting protocol with good
provisions for dynamically computed link metrics= . It is robust even in
the presence of link metric oscillations and the = failure of
transitivity. The core of the Babel protocol and security ext= ensions
are described in Experimental Independent Stream RFCs 6126, 7557= , and
7298.

These RFCs are the basis of three independent, open s= ource
implementations. There is some production deployment of these
i= mplementations, notably in hybrid networks (networks that include
classi= cal, wired parts with meshy radio bits) and in global overlay
networks (= networks built out of large numbers of tunnels spanning
continents).
=
The Working Group will focus on moving the Babel protocol to IETF
Pr= oposed Standard with IETF review.=C2=A0 This includes clarifying RFC 6126and integrating RFC 7557 and feedback provided by independent
implemen= tations, and resolving comments. It is not a requirement that
the Babel = protocol produced is backwards compatible with RFC 6126.=C2=A0 It
is a r= equirement that Babel support at least one profile that is
auto-configur= ing.=C2=A0 Other documents that are relevant to the above work
can also = be produced. Particular emphasis will be placed
on work needed for a Pro= posed Standard routing protocol, such as
ensuring manageability and stro= ng security. Link metric measurement or
link metric calculation procedur= es significantly more complex that
those currently in Babel are out of s= cope.

Work Items:

- Produce a revision of RFC 6126 suitable f= or publication as a
Proposed Standard
-- incorporate in the revision = developments since RFC 6126
-- resolve technical issues found
-- incl= ude in the base specification the extensibility work in
RFC 7557
-- s= upport auto-configuration
-- consider any important changes based on exp= erience with Babel to
date.

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

- Address manage= ability of Babel by producing an informational model
for use by other ne= twork management such as the Broadband Forum
TR-069, and a YANG data mod= ule based on that information model. This
YANG data module to be consist= ent with the ongoing effort to use YANG
data modules in the Routing Area= . This work is required as part of
moving Babel to Proposed Standard.
- As the Proposed Standard version of Babel is completed, an
Applic= ability Statement should be finalized to guide those potentially
interes= ted in deploying Babel. This Applicability Statement may
include deploym= ent advice and will be published as an RFC.

- Coordinate with other = Working Groups, such as the HOMENET WG for
likely applicability, the RTG= WG and V6OPS WG about Source-Specific
Routing to support IPv6 multihomin= g, the PIM WG for discussion around
multicast, and the MANET WG for cons= iderations around wireless.

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

- The Working Group should document its ongoing implementati= on
experience with Babel, so that new WG participants can understand the=
state that is driving this work and the experience driving change= s.
This documentation may be on the Working Group's wiki, in =
an internet-draft that isn't expected to be published as an RFC, or= a
combination.

- As a secondary focus, the Working Group may wo= rk on multicast
aspects of Babel.=C2=A0 This may include discussion of a= ny potential issues
for supporting Babel running with PIM-SM in an auto-= configuration
profile.=C2=A0 It may include exploring Babel carrying sep= arate metrics for
multicast.=C2=A0 It may even include discussion and co= nsultation with the PIM
WG about Babel providing the ability to build mu= lticast routing
tables.=C2=A0 With AD and WG agreement, once an approach= is understood,
then a milestone may be added for an associated document= targeted as
Proposed Standard.

- As a secondary focus, the Worki= ng Group may work on documents
defining source specific routing extensio= ns for Babel as a way of handling
IPv6 multihoming.

Thus, the Wor= king Group will produce a Proposed Standard Babel
specification, includi= ng or paired with a suitable Proposed Standard
specification covering th= e security mechanism(s) for BABEL. It will
also produce a management inf= ormation and data model for BABEL as a
Proposed Standard RFC. An applica= bility statement will be produced as
an Informational RFC.

Pro= posed Milestones
= <= tr style=3D"background-color:rgb(249,249,249)">IESG Submi= ssion of RFC6126bis and potentially companion security mechanisms draft
DateMil= estone
Aug 2017IESG Submission of Babel Applicability draft
Jul 2017IESG Submission of Babel Management draft
Jul 2017
Oct 2016WG adoption of Babel Management (Info Model &am= p; YANG Model) draft
Jul 2016WG adoption of RFC6126bis
Jul= 2016WG adoption of Babel Applicability draft=C2=A0
draft-chroboczek-babel-applicability


=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=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= =3D=3D=3D



On Thu, Jun 2, 2016 at 2:= 39 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr&g= t; wrote:
> - The working group is encouraged= to keep its wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz





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



=

--
Dave T=C3=A4h= t
Let's go make home routers and wifi faster! With better software!<= br>http://blog.cerowr= t.org




--
Dave T=C3=A4ht
L= et's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org<= /a>
--001a113ddbe0bad5c80534a13c5a-- From nobody Mon Jun 6 12:44:15 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 E670212D8DF; Mon, 6 Jun 2016 12:44:12 -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 DSEPO5sZrXBy; Mon, 6 Jun 2016 12:44:10 -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 88D8812D8D3; Mon, 6 Jun 2016 12:44:10 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id o16so150205207ywd.2; Mon, 06 Jun 2016 12:44:10 -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=/2+fIBAW/QtPNT9cnrUuQ0b+Th/WnUU/6z0iR7YX7wQ=; b=piYuSSzuX2mNLN96PsaPkRF84e8nu1mYWGCe1YDqsBdXdU0GZvqR9k4PaagpDXa+FK rTVZ+SYwxPKfGiDhjxjpq5YNIPjXb+bLuTg7ODwFNgKk8LHclA4SIEGoOH1nyLk0yBH0 jTNVr4pI9YhV6J/ohMnS90ZKToG+dhRBdeZqe9f6lQ/Oq9KIv1Or7pQF1l8yXWmAjiiA PrwmAvx9Ac2FrCcwdYvpIKMpm4aC9MF54B8bjohhS76t2FVqkeV3zrwN32aze4Nex/lv qr20hlskoImYwSvgua2V2VveHlmoyAMPAptUHnp3yDHz64Wjf7kSsE2WaYSdSdNRhI1k xFrA== 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=/2+fIBAW/QtPNT9cnrUuQ0b+Th/WnUU/6z0iR7YX7wQ=; b=TDKTMcWmJlOcr1UJmChxzTMTpYY0Fgfkd8a9pHpPjFT/1nfsm75Y6e25Qkv8cYWpsO 6w5PFQChQ1vqjPTVMSc71yKQfHsgYJgJ0uTmFKcB3LtENFkZoKJ50/ArWm5nvY/XEoJf CGRqIXm9eUHTxVgrZ9HEG6ouUmNWVhWMDAbtgtePJ8BKtfkG8yi76eVUGmlKRai3PovS 9a9Jh8PSEJQY2Ed9R2HPKrfRBvrCoY5Z1PU6AXBC1i4VV7FWrHxHc6Rhy69M3qRQnqsd hn7xkSbzeZlB0In6QTjfJaJ2xI1EtYJRxku10vpVvHdFzUmfGG3T5uGa3i1DvOYFsjiW tDRA== X-Gm-Message-State: ALyK8tK1Y8eaDX/i8pRjNsxKPVKtlLBK4767dJC12HVt/MGB8KcXDVYYCSs6mkdyx0QONNptyZ9ScgCexQdk1Q== X-Received: by 10.37.201.71 with SMTP id z68mr11758151ybf.124.1465242249591; Mon, 06 Jun 2016 12:44:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.221.74 with HTTP; Mon, 6 Jun 2016 12:44:08 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Alia Atlas Date: Mon, 6 Jun 2016 15:44:08 -0400 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=001a114d74f8cc12300534a14bb5 Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Revised 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, 06 Jun 2016 19:44:13 -0000 --001a114d74f8cc12300534a14bb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 6, 2016 at 3:39 PM, Dave Taht wrote: > > > On Mon, Jun 6, 2016 at 12:20 PM, Alia Atlas wrote: > >> On Mon, Jun 6, 2016 at 3:10 PM, Dave Taht wrote: >> >>> >>> >>> On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas wrote: >>> >>>> Good point. I've updated it. >>>> Any other comments or changes before I push the button for external >>>> review? >>>> >>> >>> No objections here, aside from the fact I haven't seen PIM actually wor= k >>> in years and years... >>> >> >> The most recent version - with the clarification around management I >> discussed with Benoit and Barbara is at: >> https://datatracker.ietf.org/doc/charter-ietf-babel/ >> >> As far as PIM, there are a lot of active deployments. Whether they >> require more management than is desirable is an interesting question. >> There's obviously the work in BIER that involves an additional >> encapsulation. There's also work in TRILL that uses IS-IS and builds >> multicast trees. I don't have an opinion; I'd like the WG to be able to >> discuss and determine what is needed for the real use-cases. Given that >> anything you do here will be backed up by running code and testing it ou= t, >> I'm comfortable leaving flexibility for discussion. >> > > Given that I don't have any hope for improving multicast behavior inside > the current wifi standards, and I don't know where pim would be used insi= de > the home, I don't care. I can see it being used for multicast tv, but ove= r > wifi it's a lose. > There is still discussion happening between IEEE and the IETF - primarily I think in the intarea. You might take a look there and chat with Suresh about what's happening. > I had made a thrust earlier in these threads for adding into the charter > work to make babel (more generally source specific routing) work well on > common inside-the-home/small business link layers like moca, homeplug, wi= fi > (802.11, 802.11ad), vpns (more generally, tunnels), and usbnet - as well = as > interoperating with pending ones like 6lowpan and 5g, but I seem to be > alone in that. > It's true I haven't seen significant interest there. Getting the basic protocol done is the first step. It might help to articulate what the issues are that you are seeing and what the solutions might look like. I know that I haven't been focused in that space and simply don't know. > >> Regards, >> Alia >> >> >> >> >>> >>> >>>> Thanks, >>>> Alia >>>> >>>> On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake >>>> wrote: >>>> >>>>> Hi Alia, >>>>> >>>>> This looks good to me. However, the word "even" in the following line >>>>> reads a bit odd and I would delete it.... >>>>> >>>>> multicast. It may even include discussion and consultation with the >>>>> PIM >>>>> >>>>> 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 >>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>>> 155 Beaver Street, Milford, MA 01757 USA >>>>> d3e3e3@gmail.com >>>>> >>>>> On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote: >>>>> >>>>>> Incidentally, >>>>>> >>>>>> https://datatracker.ietf.org/doc/charter-ietf-babel/history/ >>>>>> >>>>>> is very useful for looking at the differences between charters. >>>>>> >>>>>> Alia >>>>>> >>>>>> On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas wrote= : >>>>>> >>>>>>> Hi Donald, Russ, Juliusz, Toke, etc., >>>>>>> >>>>>>> I have read through all the discussion and IESG comments on the >>>>>>> charter. >>>>>>> Here is what I have for an updated version. I do need to get it ou= t >>>>>>> for External >>>>>>> Review soon so that it can come back onto the IESG telechat for >>>>>>> final approval. >>>>>>> The External Review is to give time for comments by those not on th= e >>>>>>> IESG or >>>>>>> WG - and particularly that it goes out to other organizations who >>>>>>> might be >>>>>>> interested. In the case of Babel, that is relevant because of the >>>>>>> potential interaction >>>>>>> with the Broadband Forum on TR-069. >>>>>>> >>>>>>> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . >>>>>>> I am including the text below. >>>>>>> >>>>>>> =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=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=3D=3D=3D >>>>>>> >>>>>>> Babel is a loop-avoiding, distance vector routing protocol with goo= d >>>>>>> provisions for dynamically computed link metrics. It is robust even >>>>>>> in >>>>>>> the presence of link metric oscillations and the failure of >>>>>>> transitivity. The core of the Babel protocol and security extension= s >>>>>>> are described in Experimental Independent Stream RFCs 6126, 7557, a= nd >>>>>>> 7298. >>>>>>> >>>>>>> These RFCs are the basis of three independent, open source >>>>>>> implementations. There is some production deployment of these >>>>>>> implementations, notably in hybrid networks (networks that include >>>>>>> classical, wired parts with meshy radio bits) and in global overlay >>>>>>> networks (networks built out of large numbers of tunnels spanning >>>>>>> continents). >>>>>>> >>>>>>> The Working Group will focus on moving the Babel protocol to IETF >>>>>>> Proposed Standard with IETF review. This includes clarifying RFC >>>>>>> 6126 >>>>>>> and integrating RFC 7557 and feedback provided by independent >>>>>>> implementations, and resolving comments. It is not a requirement th= at >>>>>>> the Babel protocol produced is backwards compatible with RFC 6126. >>>>>>> It >>>>>>> is a requirement that Babel support at least one profile that is >>>>>>> auto-configuring. Other documents that are relevant to the above >>>>>>> work >>>>>>> can also be produced. Particular emphasis will be placed >>>>>>> on work needed for a Proposed Standard routing protocol, such as >>>>>>> ensuring manageability and strong security. Link metric measurement >>>>>>> or >>>>>>> link metric calculation procedures significantly more complex that >>>>>>> those currently in Babel are out of scope. >>>>>>> >>>>>>> Work Items: >>>>>>> >>>>>>> - Produce a revision of RFC 6126 suitable for publication as a >>>>>>> Proposed Standard >>>>>>> -- incorporate in the revision developments since RFC 6126 >>>>>>> -- resolve technical issues found >>>>>>> -- include in the base specification the extensibility work in >>>>>>> RFC 7557 >>>>>>> -- support auto-configuration >>>>>>> -- consider any important changes based on experience with Babel to >>>>>>> date. >>>>>>> >>>>>>> - Address security needs for BABEL. This may include using the >>>>>>> techniques in RFC 7298, or other alternatives. Security may be >>>>>>> included in the base spec or the base spec may normatively referenc= e >>>>>>> a >>>>>>> separate Proposed Standard specification. This is required as part = of >>>>>>> moving Babel to Proposed Standard. >>>>>>> >>>>>>> - Address manageability of Babel by producing an informational mode= l >>>>>>> for use by other network management such as the Broadband Forum >>>>>>> TR-069, and a YANG data module based on that information model. Thi= s >>>>>>> YANG data module to be consistent with the ongoing effort to use YA= NG >>>>>>> data modules in the Routing Area. This work is required as part of >>>>>>> moving Babel to Proposed Standard. >>>>>>> >>>>>>> - As the Proposed Standard version of Babel is completed, an >>>>>>> Applicability Statement should be finalized to guide those >>>>>>> potentially >>>>>>> interested in deploying Babel. This Applicability Statement may >>>>>>> include deployment advice and will be published as an RFC. >>>>>>> >>>>>>> - Coordinate with other Working Groups, such as the HOMENET WG for >>>>>>> likely applicability, the RTGWG and V6OPS WG about Source-Specific >>>>>>> Routing to support IPv6 multihoming, the PIM WG for discussion arou= nd >>>>>>> multicast, and the MANET WG for considerations around wireless. >>>>>>> >>>>>>> - Liaise as necessary with the Broadband Forum to facilitate use of >>>>>>> the >>>>>>> Babel management Information Model for TR-069. >>>>>>> >>>>>>> - The Working Group should document its ongoing implementation >>>>>>> experience with Babel, so that new WG participants can understand t= he >>>>>>> state that is driving this work and the experience driving changes. >>>>>>> This documentation may be on the Working Group's wiki, in >>>>>>> an internet-draft that isn't expected to be published as an RFC, or= a >>>>>>> combination. >>>>>>> >>>>>>> - As a secondary focus, the Working Group may work on multicast >>>>>>> aspects of Babel. This may include discussion of any potential >>>>>>> issues >>>>>>> for supporting Babel running with PIM-SM in an auto-configuration >>>>>>> profile. It may include exploring Babel carrying separate metrics >>>>>>> for >>>>>>> multicast. It may even include discussion and consultation with th= e >>>>>>> PIM >>>>>>> WG about Babel providing the ability to build multicast routing >>>>>>> tables. With AD and WG agreement, once an approach is understood, >>>>>>> then a milestone may be added for an associated document targeted a= s >>>>>>> Proposed Standard. >>>>>>> >>>>>>> - As a secondary focus, the Working Group may work on documents >>>>>>> defining source specific routing extensions for Babel as a way of >>>>>>> handling >>>>>>> IPv6 multihoming. >>>>>>> >>>>>>> Thus, the Working Group will produce a Proposed Standard Babel >>>>>>> specification, including or paired with a suitable Proposed Standar= d >>>>>>> specification covering the security mechanism(s) for BABEL. It will >>>>>>> also produce a management information and data model for BABEL as a >>>>>>> Proposed Standard RFC. An applicability statement will be produced = as >>>>>>> an Informational RFC. >>>>>>> >>>>>>> *Proposed Milestones* >>>>>>> DateMilestone >>>>>>> Aug 2017 IESG Submission of Babel Applicability draft >>>>>>> Jul 2017 IESG Submission of Babel Management draft >>>>>>> Jul 2017 IESG Submission of RFC6126bis and potentially companion >>>>>>> security mechanisms draft >>>>>>> Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) >>>>>>> draft >>>>>>> Jul 2016 WG adoption of RFC6126bis >>>>>>> Jul 2016 WG adoption of Babel Applicability draft >>>>>>> draft-chroboczek-babel-applicability >>>>>>> >>>>>>> >>>>>>> >>>>>>> =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=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=3D=3D=3D >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < >>>>>>> jch@pps.univ-paris-diderot.fr> wrote: >>>>>>> >>>>>>>> > - 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 experienc= e >>>>>>>> > driving changes. >>>>>>>> >>>>>>>> Do we really need to specify the technology used for this >>>>>>>> information? >>>>>>>> What about >>>>>>>> >>>>>>>> "to keep its wiki updated with implementation experience" -> "to >>>>>>>> maintain up-to-date, publicly accessible information about >>>>>>>> implementation experience" >>>>>>>> >>>>>>>> Then the WG can choose whether to do a wiki page, an >>>>>>>> internet-draft, or >>>>>>>> whatever else we find convenient. >>>>>>>> >>>>>>>> -- Juliusz >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> babel mailing list >>>> babel@ietf.org >>>> https://www.ietf.org/mailman/listinfo/babel >>>> >>>> >>> >>> >>> -- >>> Dave T=C3=A4ht >>> Let's go make home routers and wifi faster! With better software! >>> http://blog.cerowrt.org >>> >> >> > > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > --001a114d74f8cc12300534a14bb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 6, 2016 at 3:39 PM, Dave Taht <dave.taht@gmail.com> wrote:


On Mon, Ju= n 6, 2016 at 12:20 PM, Alia Atlas <akatlas@gmail.com> wrote:=
On Mon, Jun 6, 2016 at 3:10 PM, Dave T= aht <dave.taht@gmail.com> wrote:


<= span>On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas <akatlas@gmail.com>= wrote:
Good point.=C2=A0 I'= ;ve updated it.
Any other comments or changes before I push the button = for external review?

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

The most recent version - with the clarification around management= I discussed with Benoit and Barbara is at: =C2=A0https://datatrack= er.ietf.org/doc/charter-ietf-babel/

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

Given that I don't have an= y hope for improving multicast behavior inside the current wifi standards, = and I don't know where pim would be used inside the home, I don't c= are. I can see it being used for multicast tv, but over wifi it's a los= e.

There is still d= iscussion happening between IEEE and the IETF - primarily I think in the in= tarea.=C2=A0 You might take a look there and chat with Suresh about what= 9;s happening.=C2=A0
=C2=A0
<= div dir=3D"ltr">
=
I had made a thrust earlier in these threads for adding into the= charter work to make babel (more generally source specific routing) work w= ell on common inside-the-home/small business link layers like moca, homeplu= g, wifi (802.11, 802.11ad), vpns (more generally, tunnels), and usbnet - as= well as interoperating with pending ones like 6lowpan and 5g, but I seem t= o be alone in that.=C2=A0

It's true I haven't seen significant interest there.=C2=A0 G= etting the basic protocol done is the first step.=C2=A0 It might help to ar= ticulate what the issues are that you are seeing and what the solutions mig= ht look like.=C2=A0 I know that I haven't been focused in that space an= d simply don't know.
=C2=A0
=C2=A0
<= div dir=3D"ltr">
=
Regards,
Alia

= =C2=A0
=C2=A0
=C2=A0
Thanks,
Alia
<= div>

On Sun, Jun 5= , 2016 at 11:34 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:=
Hi Alia,

This look= s good to me. However, the word "even" in the following line read= s a bit odd and I would delete it....

multicast.=C2=A0 It may even include discussion and consult= ation with the PIM

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

On Fri, Jun 3, 2016 at 4:40= PM, Alia Atlas <akatlas@gmail.com> wrote:
Incidentally,

is very useful for looking at the differences between charters= .

Alia
<= /span>

On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas <akatlas@gmail.com>= wrote:
Hi Donald, Russ, Julius= z, Toke, etc.,

I have read through all the discussion an= d IESG comments on the charter.
Here is what I have for an update= d version.=C2=A0 I do need to get it out for External
Review soon= so that it can come back onto the IESG telechat for final approval.
<= div>The External Review is to give time for comments by those not on the IE= SG or
WG - and particularly that it goes out to other organizatio= ns who might be
interested.=C2=A0 In the case of Babel, that is r= elevant because of the potential interaction
with the Broadband F= orum on TR-069.

The link is=C2=A0https://d= atatracker.ietf.org/doc/charter-ietf-babel/ .=C2=A0 I am including the = text below.

=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=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= =3D=3D=3D

Babel is a loop-avoiding, distance vector rou= ting protocol with good
provisions for dynamically computed link metrics= . It is robust even in
the presence of link metric oscillations and the = failure of
transitivity. The core of the Babel protocol and security ext= ensions
are described in Experimental Independent Stream RFCs 6126, 7557= , and
7298.

These RFCs are the basis of three independent, open s= ource
implementations. There is some production deployment of these
i= mplementations, notably in hybrid networks (networks that include
classi= cal, wired parts with meshy radio bits) and in global overlay
networks (= networks built out of large numbers of tunnels spanning
continents).
=
The Working Group will focus on moving the Babel protocol to IETF
Pr= oposed Standard with IETF review.=C2=A0 This includes clarifying RFC 6126and integrating RFC 7557 and feedback provided by independent
implemen= tations, and resolving comments. It is not a requirement that
the Babel = protocol produced is backwards compatible with RFC 6126.=C2=A0 It
is a r= equirement that Babel support at least one profile that is
auto-configur= ing.=C2=A0 Other documents that are relevant to the above work
can also = be produced. Particular emphasis will be placed
on work needed for a Pro= posed Standard routing protocol, such as
ensuring manageability and stro= ng security. Link metric measurement or
link metric calculation procedur= es significantly more complex that
those currently in Babel are out of s= cope.

Work Items:

- Produce a revision of RFC 6126 suitable f= or publication as a
Proposed Standard
-- incorporate in the revision = developments since RFC 6126
-- resolve technical issues found
-- incl= ude in the base specification the extensibility work in
RFC 7557
-- s= upport auto-configuration
-- consider any important changes based on exp= erience with Babel to
date.

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

- Address manage= ability of Babel by producing an informational model
for use by other ne= twork management such as the Broadband Forum
TR-069, and a YANG data mod= ule based on that information model. This
YANG data module to be consist= ent with the ongoing effort to use YANG
data modules in the Routing Area= . This work is required as part of
moving Babel to Proposed Standard.
- As the Proposed Standard version of Babel is completed, an
Applic= ability Statement should be finalized to guide those potentially
interes= ted in deploying Babel. This Applicability Statement may
include deploym= ent advice and will be published as an RFC.

- Coordinate with other = Working Groups, such as the HOMENET WG for
likely applicability, the RTG= WG and V6OPS WG about Source-Specific
Routing to support IPv6 multihomin= g, the PIM WG for discussion around
multicast, and the MANET WG for cons= iderations around wireless.

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

- The Working Group should document its ongoing implementati= on
experience with Babel, so that new WG participants can understand the=
state that is driving this work and the experience driving change= s.
This documentation may be on the Working Group's wiki, in =
an internet-draft that isn't expected to be published as an RFC, or= a
combination.

- As a secondary focus, the Working Group may wo= rk on multicast
aspects of Babel.=C2=A0 This may include discussion of a= ny potential issues
for supporting Babel running with PIM-SM in an auto-= configuration
profile.=C2=A0 It may include exploring Babel carrying sep= arate metrics for
multicast.=C2=A0 It may even include discussion and co= nsultation with the PIM
WG about Babel providing the ability to build mu= lticast routing
tables.=C2=A0 With AD and WG agreement, once an approach= is understood,
then a milestone may be added for an associated document= targeted as
Proposed Standard.

- As a secondary focus, the Worki= ng Group may work on documents
defining source specific routing extensio= ns for Babel as a way of handling
IPv6 multihoming.

Thus, the Wor= king Group will produce a Proposed Standard Babel
specification, includi= ng or paired with a suitable Proposed Standard
specification covering th= e security mechanism(s) for BABEL. It will
also produce a management inf= ormation and data model for BABEL as a
Proposed Standard RFC. An applica= bility statement will be produced as
an Informational RFC.

Pro= posed Milestones
= <= tr style=3D"background-color:rgb(249,249,249)">IESG Submi= ssion of RFC6126bis and potentially companion security mechanisms draft
DateMil= estone
Aug 2017IESG Submission of Babel Applicability draft
Jul 2017IESG Submission of Babel Management draft
Jul 2017
Oct 2016WG adoption of Babel Management (Info Model &am= p; YANG Model) draft
Jul 2016WG adoption of RFC6126bis
Jul= 2016WG adoption of Babel Applicability draft=C2=A0
draft-chroboczek-babel-applicability


=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=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= =3D=3D=3D



On Thu, Jun 2, 2016 at 2:= 39 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr&g= t; wrote:
> - The working group is encouraged= to keep its wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz





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



=

--
Dave T=C3=A4h= t
Let's go make home routers and wifi faster! With better software!<= br>http://blog.cerowr= t.org




--
Dave T=C3=A4= ht
Let's go make home routers and wifi faster! With better software!=
http://blog.cerow= rt.org

--001a114d74f8cc12300534a14bb5-- From nobody Mon Jun 6 13:19: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 6397D12D871; Mon, 6 Jun 2016 13:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 kjFJU0lPoSi7; Mon, 6 Jun 2016 13:19:30 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 0CC3012D83B; Mon, 6 Jun 2016 13:19:30 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k23so244583181oih.0; Mon, 06 Jun 2016 13:19:30 -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=MqYFWVAbA/2fM4lU83N+IX/PRgp/UmmN2SkLajnYXtA=; b=ZaeO5K5c0Aw64tppFKLo1/ng2kAsz0ssUnFMdCfVtJEz7t71U220bOjcLLijwlwRcZ J7ZLzE8I9xvFfxf1LGlcPjU3ZGafpfEhSrLi39SnVrKBE0kZ8BRoEmCu2musi4cX49i7 z/zVW9ZXVEkpUvSuxoexKL0DM65i8fWRoR7I979MwCcXhL1xu1BEIn80Z6agB3SgWkjF MTkvhkYQNEvikD0wMsy4+Jor+n7XVq7e62iETewlBj8mQ97jpFFDszTUo7FvwuBmKFo+ oZ6UbLqHRzN+Tdfs7KKzfksyi2YN3fl/Pn5+Qr51kRJajHG6tIhoGjNr7Gxlg2QeqYcw EUqA== 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=MqYFWVAbA/2fM4lU83N+IX/PRgp/UmmN2SkLajnYXtA=; b=QsH67MbZpO/74EXQqNE1GhJAFR5lim6gOb9HsHLsmwtNBLRW2QId+1YKVZpctOjcvs obDWQ7wtZF8V4QRICkcs8QGBPUFTEJFDkQhMEogYw9OaNan9RIEwlltdYgMd2VxWFjDD 1Laje6ed2YFp4FWo2kVqGpy7HPwZHSU8JCKmH5kOSyTzS3qBzIrMxHq9mIkkigolL4y0 ZfRgnz7KlQI4etrA7x6qj7MckBLw9tbFZohSGOcVnBd5AEU2DGBgZWKuc7VKYDYySXr8 Y7Y92dtUzqRXw0tyIo/Yb1+kG/cI2CUmCWxqkrm1WNyI83+a3j4HN95E/tKkcso8uc1l RodQ== X-Gm-Message-State: ALyK8tL0d8fgx13Z9Q1wlUAlf4DNJoVy/YYs8Sf11/L0nIRQuf/AXgrCmXnA5XLwOj2k//+diyb+dw3Jj9+FUA== X-Received: by 10.202.186.193 with SMTP id k184mr10214288oif.66.1465244369111; Mon, 06 Jun 2016 13:19:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Mon, 6 Jun 2016 13:19:28 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> From: Dave Taht Date: Mon, 6 Jun 2016 13:19:28 -0700 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113ce2182157210534a1caaf Archived-At: Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Revised 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, 06 Jun 2016 20:19:33 -0000 --001a113ce2182157210534a1caaf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 6, 2016 at 12:44 PM, Alia Atlas wrote: > On Mon, Jun 6, 2016 at 3:39 PM, Dave Taht wrote: > >> >> >> On Mon, Jun 6, 2016 at 12:20 PM, Alia Atlas wrote: >> >>> On Mon, Jun 6, 2016 at 3:10 PM, Dave Taht wrote: >>> >>>> >>>> >>>> On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas wrote: >>>> >>>>> Good point. I've updated it. >>>>> Any other comments or changes before I push the button for external >>>>> review? >>>>> >>>> >>>> No objections here, aside from the fact I haven't seen PIM actually >>>> work in years and years... >>>> >>> >>> The most recent version - with the clarification around management I >>> discussed with Benoit and Barbara is at: >>> https://datatracker.ietf.org/doc/charter-ietf-babel/ >>> >>> As far as PIM, there are a lot of active deployments. Whether they >>> require more management than is desirable is an interesting question. >>> There's obviously the work in BIER that involves an additional >>> encapsulation. There's also work in TRILL that uses IS-IS and builds >>> multicast trees. I don't have an opinion; I'd like the WG to be able t= o >>> discuss and determine what is needed for the real use-cases. Given tha= t >>> anything you do here will be backed up by running code and testing it o= ut, >>> I'm comfortable leaving flexibility for discussion. >>> >> >> Given that I don't have any hope for improving multicast behavior inside >> the current wifi standards, and I don't know where pim would be used ins= ide >> the home, I don't care. I can see it being used for multicast tv, but ov= er >> wifi it's a lose. >> > > There is still discussion happening between IEEE and the IETF - primarily > I think in the intarea. You might take a look there and chat with Suresh > about what's happening. > OK. > > >> I had made a thrust earlier in these threads for adding into the charter >> work to make babel (more generally source specific routing) work well on >> common inside-the-home/small business link layers like moca, homeplug, w= ifi >> (802.11, 802.11ad), vpns (more generally, tunnels), and usbnet - as well= as >> interoperating with pending ones like 6lowpan and 5g, but I seem to be >> alone in that. >> > > It's true I haven't seen significant interest there. Getting the basic > protocol done is the first step. It might help to articulate what the > issues are that you are seeing and what the solutions might look like. I > know that I haven't been focused in that space and simply don't know. > I have been perhaps too busy fixing wifi to pay attention to the chartering here. It is ok with me if this stuff remains out of scope for the charter, but to describe my thinking more fully, as it sort of does affect the characteristics of the next few billion devices (3 billion wifi last year).... ... I basically long ago blurred the distinction between "host" and "router" years ago. In my world, nearly all hosts are capable of routing, and have 2 or more possible ways to get to each other or to the internet. Bridging together many of these link layers seems to be a bad idea due to basic differences in multicast and addressing, but routing less so. * usbnet: IP over USB has been available since the late 90s, and was, for example heavily used by linux on the ipaq way back when. In many of the latest generations of hackerboards and IoT, ethernet is being dropped and replaced by wifi and usb. On the low end, see the esp8266, pi zero, etc. higher end - say on tvs - usb-c has great potential to be a faster (10gbit!) alternative to local ethernet, with a smaller cable that also routinely supplies power. The principal flaw of IP over usb (IMHO) was that neither the client or host had easy routability, so you were stuck with local connectivity only between those two devices. You add a routing protocol to the mix, and bang, any device that supports it, can export IP based services to the rest of the network [1]. One of the mantras of homenet was "no host changes", which seemed silly compared to the ease by which babel could be installed and configured (at least on osx and linux). For 8+ years now I've always been dual connected over ethernet and wifi, when I got up from my desk, my existing connections all switched to wifi, when I got back or plugged in elsewhere, they all migrated back to ethernet eventually. * HDMI ethernet HDMI ethernet never took off probably for similar reasons for why usbnet is not so often used. That said, the raw capability for using it is there, if only address assignment, routing, and service discovery issues had been resolved. * Moca I see this available in many cable based home gateways (also in gfiber), bridged, rather than routed. It is usually slower than ethernet by a lot, as well as flakier, and is an unswitched shared medium much like original ethernet and present-day wifi. I have no idea how video is shared on top of it presently. * Homeplug. (ethernet to wall power) I have seen these heavily used in many apartments (very common in paris, for example) where the entry point for access is far from the actual use point, and the wifi spectrum horribly polluted. It is really flaky and slow, even when compared to Moca - but still often I can and do run babel over homeplug, but the multicast behavior is quite poor in general with more than 2 of them in a home (up to 16 are supported, and throughput generally much less than 200mbit even on the latest version of the standards) * 3-5 G. One primary use for having source specific routing (as well as multihoming with nat) is the ready availability of a "backup link" - be that a home router providing two different connections to the internet, or a handheld with both wifi and 3g access (and some handhelds and laptops are capable usbnet, and others ethernet) * 802.11ad has a good feature in that it does not penetrate walls, and thus you can have a lot of it. It has a bad feature in that it does not penetrate walls, and you need a lot of it, or some other backhaul (homeplug or wifi being leading contenders) * 6lowpan (threads, etc). I honestly don't know a lot about all the 802.11.14 derived standards except that they seem to be inhabiting an increasingly tiny space vs wifi's ubiquity and devices with increasingly low power demands, seem to be moving into. * vpns and tunnels. It is nice to have some means to "choose the right address" to send though a vpn. [1] This is for example a wifi+usb gateway running on the 9 dollar " getchip.com" device. Same code works on the rpi zero through 3, odroid c2, etc, and runs at over 90mbit here where the wifi on this board does 20mbit, tops. root@chipzilla:~# ip route default via 172.26.117.50 dev usb0 proto babel onlink default via 172.26.19.1 dev wlan0 proto static metric 1024 10.0.0.0/24 via 172.26.117.50 dev usb0 proto babel onlink 73.252.200.0/23 via 172.26.117.50 dev usb0 proto babel onlink 169.254.22.140 via 172.26.117.50 dev usb0 proto babel onlink 172.26.16.0/24 via 172.26.117.50 dev usb0 proto babel onlink 172.26.16.3 via 172.26.117.50 dev usb0 proto babel onlink 172.26.16.5 via 172.26.117.50 dev usb0 proto babel onlink 172.26.17.247 via 172.26.117.50 dev usb0 proto babel onlink 172.26.18.0/24 via 172.26.117.50 dev usb0 proto babel onlink 172.26.18.21 via 172.26.117.50 dev usb0 proto babel onlink 172.26.19.0/24 dev wlan0 proto kernel scope link src 172.26.19.23 172.26.64.0/24 via 172.26.117.50 dev usb0 proto babel onlink 172.26.64.5 via 172.26.117.50 dev usb0 proto babel onlink 172.26.128.0/23 via 172.26.117.50 dev usb0 proto babel onlink 172.26.130.0/23 via 172.26.117.50 dev usb0 proto babel onlink 172.26.130.1 via 172.26.117.50 dev usb0 proto babel onlink 192.168.2.0/24 via 172.26.117.50 dev usb0 proto babel onlink > > >> >>> Regards, >>> Alia >>> >>> >>> >>> >>>> >>>> >>>>> Thanks, >>>>> Alia >>>>> >>>>> On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake >>>>> wrote: >>>>> >>>>>> Hi Alia, >>>>>> >>>>>> This looks good to me. However, the word "even" in the following lin= e >>>>>> reads a bit odd and I would delete it.... >>>>>> >>>>>> multicast. It may even include discussion and consultation with the >>>>>> PIM >>>>>> >>>>>> 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 >>>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>>>> 155 Beaver Street, Milford, MA 01757 USA >>>>>> d3e3e3@gmail.com >>>>>> >>>>>> On Fri, Jun 3, 2016 at 4:40 PM, Alia Atlas wrote= : >>>>>> >>>>>>> Incidentally, >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/charter-ietf-babel/history/ >>>>>>> >>>>>>> is very useful for looking at the differences between charters. >>>>>>> >>>>>>> Alia >>>>>>> >>>>>>> On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Donald, Russ, Juliusz, Toke, etc., >>>>>>>> >>>>>>>> I have read through all the discussion and IESG comments on the >>>>>>>> charter. >>>>>>>> Here is what I have for an updated version. I do need to get it >>>>>>>> out for External >>>>>>>> Review soon so that it can come back onto the IESG telechat for >>>>>>>> final approval. >>>>>>>> The External Review is to give time for comments by those not on >>>>>>>> the IESG or >>>>>>>> WG - and particularly that it goes out to other organizations who >>>>>>>> might be >>>>>>>> interested. In the case of Babel, that is relevant because of the >>>>>>>> potential interaction >>>>>>>> with the Broadband Forum on TR-069. >>>>>>>> >>>>>>>> The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ >>>>>>>> . I am including the text below. >>>>>>>> >>>>>>>> =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=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=3D=3D=3D >>>>>>>> >>>>>>>> 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. The core of the Babel protocol and security extensio= ns >>>>>>>> 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 overla= y >>>>>>>> networks (networks built out of large numbers of tunnels spanning >>>>>>>> continents). >>>>>>>> >>>>>>>> The Working Group will focus on moving the Babel protocol to IETF >>>>>>>> Proposed Standard with IETF review. This includes clarifying RFC >>>>>>>> 6126 >>>>>>>> and integrating RFC 7557 and feedback provided by independent >>>>>>>> implementations, and resolving comments. It is not a requirement >>>>>>>> that >>>>>>>> the Babel protocol produced is backwards compatible with RFC 6126. >>>>>>>> It >>>>>>>> is a requirement that Babel support at least one profile that is >>>>>>>> auto-configuring. Other documents that are relevant to the above >>>>>>>> work >>>>>>>> can also be produced. Particular emphasis will be placed >>>>>>>> on work needed for a Proposed Standard routing protocol, such as >>>>>>>> ensuring manageability and strong security. Link metric measuremen= t >>>>>>>> or >>>>>>>> link metric calculation procedures significantly more complex that >>>>>>>> those currently in Babel are out of scope. >>>>>>>> >>>>>>>> Work Items: >>>>>>>> >>>>>>>> - Produce a revision of RFC 6126 suitable for publication as a >>>>>>>> Proposed Standard >>>>>>>> -- incorporate in the revision developments since RFC 6126 >>>>>>>> -- resolve technical issues found >>>>>>>> -- include in the base specification the extensibility work in >>>>>>>> RFC 7557 >>>>>>>> -- support auto-configuration >>>>>>>> -- consider any important changes based on experience with Babel t= o >>>>>>>> date. >>>>>>>> >>>>>>>> - Address security needs for BABEL. This may include using the >>>>>>>> techniques in RFC 7298, or other alternatives. Security may be >>>>>>>> included in the base spec or the base spec may normatively >>>>>>>> reference a >>>>>>>> separate Proposed Standard specification. This is required as part >>>>>>>> of >>>>>>>> moving Babel to Proposed Standard. >>>>>>>> >>>>>>>> - Address manageability of Babel by producing an informational mod= el >>>>>>>> for use by other network management such as the Broadband Forum >>>>>>>> TR-069, and a YANG data module based on that information model. Th= is >>>>>>>> YANG data module to be consistent with the ongoing effort to use >>>>>>>> YANG >>>>>>>> data modules in the Routing Area. This work is required as part of >>>>>>>> moving Babel to Proposed Standard. >>>>>>>> >>>>>>>> - As the Proposed Standard version of Babel is completed, an >>>>>>>> Applicability Statement should be finalized to guide those >>>>>>>> potentially >>>>>>>> interested in deploying Babel. This Applicability Statement may >>>>>>>> include deployment advice and will be published as an RFC. >>>>>>>> >>>>>>>> - Coordinate with other Working Groups, such as the HOMENET WG for >>>>>>>> likely applicability, the RTGWG and V6OPS WG about Source-Specific >>>>>>>> Routing to support IPv6 multihoming, the PIM WG for discussion >>>>>>>> around >>>>>>>> multicast, and the MANET WG for considerations around wireless. >>>>>>>> >>>>>>>> - Liaise as necessary with the Broadband Forum to facilitate use o= f >>>>>>>> the >>>>>>>> Babel management Information Model for TR-069. >>>>>>>> >>>>>>>> - The Working Group should document its ongoing implementation >>>>>>>> experience with Babel, so that new WG participants can understand >>>>>>>> the >>>>>>>> state that is driving this work and the experience driving changes= . >>>>>>>> This documentation may be on the Working Group's wiki, in >>>>>>>> an internet-draft that isn't expected to be published as an RFC, o= r >>>>>>>> a >>>>>>>> combination. >>>>>>>> >>>>>>>> - As a secondary focus, the Working Group may work on multicast >>>>>>>> aspects of Babel. This may include discussion of any potential >>>>>>>> issues >>>>>>>> for supporting Babel running with PIM-SM in an auto-configuration >>>>>>>> profile. It may include exploring Babel carrying separate metrics >>>>>>>> for >>>>>>>> multicast. It may even include discussion and consultation with >>>>>>>> the PIM >>>>>>>> WG about Babel providing the ability to build multicast routing >>>>>>>> tables. With AD and WG agreement, once an approach is understood, >>>>>>>> then a milestone may be added for an associated document targeted = as >>>>>>>> Proposed Standard. >>>>>>>> >>>>>>>> - As a secondary focus, the Working Group may work on documents >>>>>>>> defining source specific routing extensions for Babel as a way of >>>>>>>> handling >>>>>>>> IPv6 multihoming. >>>>>>>> >>>>>>>> Thus, the Working Group will produce a Proposed Standard Babel >>>>>>>> specification, including or paired with a suitable Proposed Standa= rd >>>>>>>> specification covering the security mechanism(s) for BABEL. It wil= l >>>>>>>> also produce a management information and data model for BABEL as = a >>>>>>>> Proposed Standard RFC. An applicability statement will be produced >>>>>>>> as >>>>>>>> an Informational RFC. >>>>>>>> >>>>>>>> *Proposed Milestones* >>>>>>>> DateMilestone >>>>>>>> Aug 2017 IESG Submission of Babel Applicability draft >>>>>>>> Jul 2017 IESG Submission of Babel Management draft >>>>>>>> Jul 2017 IESG Submission of RFC6126bis and potentially companion >>>>>>>> security mechanisms draft >>>>>>>> Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) >>>>>>>> draft >>>>>>>> Jul 2016 WG adoption of RFC6126bis >>>>>>>> Jul 2016 WG adoption of Babel Applicability draft >>>>>>>> draft-chroboczek-babel-applicability >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =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=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=3D=3D=3D >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek < >>>>>>>> jch@pps.univ-paris-diderot.fr> wrote: >>>>>>>> >>>>>>>>> > - The working group is encouraged to keep its wiki updated with >>>>>>>>> > implementation experience with Babel so that new WG participant= s >>>>>>>>> can >>>>>>>>> > understand the state that is driving this work and the experien= ce >>>>>>>>> > driving changes. >>>>>>>>> >>>>>>>>> Do we really need to specify the technology used for this >>>>>>>>> information? >>>>>>>>> What about >>>>>>>>> >>>>>>>>> "to keep its wiki updated with implementation experience" -> "t= o >>>>>>>>> maintain up-to-date, publicly accessible information about >>>>>>>>> implementation experience" >>>>>>>>> >>>>>>>>> Then the WG can choose whether to do a wiki page, an >>>>>>>>> internet-draft, or >>>>>>>>> whatever else we find convenient. >>>>>>>>> >>>>>>>>> -- Juliusz >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> babel mailing list >>>>> babel@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/babel >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dave T=C3=A4ht >>>> Let's go make home routers and wifi faster! With better software! >>>> http://blog.cerowrt.org >>>> >>> >>> >> >> >> -- >> Dave T=C3=A4ht >> Let's go make home routers and wifi faster! With better software! >> http://blog.cerowrt.org >> > > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org --001a113ce2182157210534a1caaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 6, 2016 at 12:44 PM, Alia Atlas <akatlas@gmail.com>= wrote:
On Mon, Jun 6, 2016 at 3:39= PM, Dave Taht <dave.taht@gmail.com> wrote:


On Mon, Jun 6, 2016 at 12:20 PM, Alia Atlas <akatlas@gmail= .com> wrote:
On Mon, Jun 6, 2016 at 3:= 10 PM, Dave Taht <dave.taht@gmail.com> wrote:


On Mon, Jun 6, 2016 at 6:58 AM, Alia Atlas <akatlas@gmai= l.com> wrote:
Good point= .=C2=A0 I've updated it.
Any other comments or changes before I pus= h the button for external review?

No objections here, aside from the fact I haven't seen PIM ac= tually work in years and years...
=
The most recent version - with the clarification arou= nd management I discussed with Benoit and Barbara is at: =C2=A0http= s://datatracker.ietf.org/doc/charter-ietf-babel/

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

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

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

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

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

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

<= div>...

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

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

In man= y of the latest generations of hackerboards and IoT, ethernet is being drop= ped and replaced by wifi and usb. On the low end, see the esp8266, pi zero,= etc.

higher end - say on tvs - usb-c has great po= tential to be a faster (10gbit!) alternative to local ethernet, with a smal= ler cable that also routinely supplies power.=C2=A0

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

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

* HDMI ethernet

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

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

* Homeplug. (ethernet to wall power) I ha= ve seen these heavily used in many apartments (very common in paris, for ex= ample) where the entry point for access is far from the actual use point, a= nd the wifi spectrum horribly polluted. It is really flaky and slow, even w= hen compared to Moca - but still often=C2=A0

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

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

* 802.11ad has a good feature in that i= t does not penetrate walls, and thus you can have a lot of it. It has a bad= feature in that it does not penetrate walls, and you need a lot of it, or = some other backhaul (homeplug or wifi being leading contenders)
<= br>
* 6lowpan (threads, etc). I honestly don't know a lot abo= ut all the 802.11.14 derived standards except that they seem to be inhabiti= ng an increasingly tiny space vs wifi's ubiquity and devices with incre= asingly low power demands, seem to be moving into.=C2=A0

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


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

<= /div>
root@chipzilla:~# ip route
default via 172.26.117.= 50 dev usb0 =C2=A0proto babel onlink=C2=A0
default via 172.26.19.= 1 dev wlan0 =C2=A0proto static =C2=A0metric 1024=C2=A0
10.0.0.0/24 via 172.26.117.50 dev usb0 =C2=A0proto= babel onlink=C2=A0
73.252.200= .0/23 via 172.26.117.50 dev usb0 =C2=A0proto babel onlink=C2=A0
169.254.22.140 via 172.26.117.50 dev usb0 =C2=A0proto babel onlink=C2=A0=
172.26.16.0/24 via 172.26.= 117.50 dev usb0 =C2=A0proto babel onlink=C2=A0
172.26.16.3 via 17= 2.26.117.50 dev usb0 =C2=A0proto babel onlink=C2=A0
172.26.16.5 v= ia 172.26.117.50 dev usb0 =C2=A0proto babel onlink=C2=A0
172.26.1= 7.247 via 172.26.117.50 dev usb0 =C2=A0proto babel onlink=C2=A0
<= a href=3D"http://172.26.18.0/24">172.26.18.0/24 via 172.26.117.50 dev u= sb0 =C2=A0proto babel onlink=C2=A0
172.26.18.21 via 172.26.117.50= dev usb0 =C2=A0proto babel onlink=C2=A0
172.26.19.0/24 dev wlan0 =C2=A0proto kernel =C2=A0scope link = =C2=A0src 172.26.19.23=C2=A0
17= 2.26.64.0/24 via 172.26.117.50 dev usb0 =C2=A0proto babel onlink=C2=A0<= /div>
172.26.64.5 via 172.26.117.50 dev usb0 =C2=A0proto babel onlink= =C2=A0
172.26.128.0/23 via= 172.26.117.50 dev usb0 =C2=A0proto babel onlink=C2=A0
172.26.130.0/23 via 172.26.117.50 dev usb0 =C2= =A0proto babel onlink=C2=A0
172.26.130.1 via 172.26.117.50 dev us= b0 =C2=A0proto babel onlink=C2=A0
192.168.2.0/24 via 172.26.117.50 dev usb0 =C2=A0proto babel onlink= =C2=A0

=C2=A0
=C2=A0

Regards,
Alia<= /div>

=C2=A0
=C2=A0
=C2=A0
Thanks,=
Alia

On Sun, Jun 5, 2016 at 11:34 PM, Donald Eastlake <d3e3e= 3@gmail.com> wrote:
Hi A= lia,

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

multicast.=C2=A0 It may ev= en include discussion and consultation with the PIM

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-50= 8-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
= =C2=A0d3e3e3@gmail.co= m

On Fri, Jun 3, 2016 at 4:40= PM, Alia Atlas <akatlas@gmail.com> wrote:
Incidentally,

is very useful for looking at the differences between charters= .

Alia
<= /span>

On Fri, Jun 3, 2016 at 4:39 PM, Alia Atlas <akatlas@gmail.com>= wrote:
Hi Donald, Russ, Julius= z, Toke, etc.,

I have read through all the discussion an= d IESG comments on the charter.
Here is what I have for an update= d version.=C2=A0 I do need to get it out for External
Review soon= so that it can come back onto the IESG telechat for final approval.
<= div>The External Review is to give time for comments by those not on the IE= SG or
WG - and particularly that it goes out to other organizatio= ns who might be
interested.=C2=A0 In the case of Babel, that is r= elevant because of the potential interaction
with the Broadband F= orum on TR-069.

The link is=C2=A0https://d= atatracker.ietf.org/doc/charter-ietf-babel/ .=C2=A0 I am including the = text below.

=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=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= =3D=3D=3D

Babel is a loop-avoiding, distance vector rou= ting protocol with good
provisions for dynamically computed link metrics= . It is robust even in
the presence of link metric oscillations and the = failure of
transitivity. The core of the Babel protocol and security ext= ensions
are described in Experimental Independent Stream RFCs 6126, 7557= , and
7298.

These RFCs are the basis of three independent, open s= ource
implementations. There is some production deployment of these
i= mplementations, notably in hybrid networks (networks that include
classi= cal, wired parts with meshy radio bits) and in global overlay
networks (= networks built out of large numbers of tunnels spanning
continents).
=
The Working Group will focus on moving the Babel protocol to IETF
Pr= oposed Standard with IETF review.=C2=A0 This includes clarifying RFC 6126and integrating RFC 7557 and feedback provided by independent
implemen= tations, and resolving comments. It is not a requirement that
the Babel = protocol produced is backwards compatible with RFC 6126.=C2=A0 It
is a r= equirement that Babel support at least one profile that is
auto-configur= ing.=C2=A0 Other documents that are relevant to the above work
can also = be produced. Particular emphasis will be placed
on work needed for a Pro= posed Standard routing protocol, such as
ensuring manageability and stro= ng security. Link metric measurement or
link metric calculation procedur= es significantly more complex that
those currently in Babel are out of s= cope.

Work Items:

- Produce a revision of RFC 6126 suitable f= or publication as a
Proposed Standard
-- incorporate in the revision = developments since RFC 6126
-- resolve technical issues found
-- incl= ude in the base specification the extensibility work in
RFC 7557
-- s= upport auto-configuration
-- consider any important changes based on exp= erience with Babel to
date.

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

- Address manage= ability of Babel by producing an informational model
for use by other ne= twork management such as the Broadband Forum
TR-069, and a YANG data mod= ule based on that information model. This
YANG data module to be consist= ent with the ongoing effort to use YANG
data modules in the Routing Area= . This work is required as part of
moving Babel to Proposed Standard.
- As the Proposed Standard version of Babel is completed, an
Applic= ability Statement should be finalized to guide those potentially
interes= ted in deploying Babel. This Applicability Statement may
include deploym= ent advice and will be published as an RFC.

- Coordinate with other = Working Groups, such as the HOMENET WG for
likely applicability, the RTG= WG and V6OPS WG about Source-Specific
Routing to support IPv6 multihomin= g, the PIM WG for discussion around
multicast, and the MANET WG for cons= iderations around wireless.

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

- The Working Group should document its ongoing implementati= on
experience with Babel, so that new WG participants can understand the=
state that is driving this work and the experience driving change= s.
This documentation may be on the Working Group's wiki, in =
an internet-draft that isn't expected to be published as an RFC, or= a
combination.

- As a secondary focus, the Working Group may wo= rk on multicast
aspects of Babel.=C2=A0 This may include discussion of a= ny potential issues
for supporting Babel running with PIM-SM in an auto-= configuration
profile.=C2=A0 It may include exploring Babel carrying sep= arate metrics for
multicast.=C2=A0 It may even include discussion and co= nsultation with the PIM
WG about Babel providing the ability to build mu= lticast routing
tables.=C2=A0 With AD and WG agreement, once an approach= is understood,
then a milestone may be added for an associated document= targeted as
Proposed Standard.

- As a secondary focus, the Worki= ng Group may work on documents
defining source specific routing extensio= ns for Babel as a way of handling
IPv6 multihoming.

Thus, the Wor= king Group will produce a Proposed Standard Babel
specification, includi= ng or paired with a suitable Proposed Standard
specification covering th= e security mechanism(s) for BABEL. It will
also produce a management inf= ormation and data model for BABEL as a
Proposed Standard RFC. An applica= bility statement will be produced as
an Informational RFC.

Pro= posed Milestones
= <= td style=3D"padding:3px;white-space:nowrap;line-height:1.42857;vertical-ali= gn:top;border-top-width:1px;border-top-style:solid;border-top-color:rgb(221= ,221,221)">Jul 2016
=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=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=3D=3D= =3D



On Thu, Jun 2, 2016 at 2:39 PM,= Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
> - The working group is encouraged to ke= ep its wiki updated with
> implementation experience with Babel so that new WG participants can > understand the state that is driving this work and the experience
> driving changes.

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

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

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

-- Juliusz





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



=

--
Dave T=C3=A4h= t
Let's go make home routers and wifi faster! With better software!<= br>http://blog.cerowr= t.org




--
Dave T=C3=A4ht
Let'= ;s go make home routers and wifi faster! With better software!
http://blog.cerowrt.org<= /div>




--
Dave T=C3=A4ht
L= et's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org<= /a>
--001a113ce2182157210534a1caaf-- From nobody Mon Jun 6 14:30: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 7198312D92E for ; Mon, 6 Jun 2016 14:30:19 -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 G5BzVCBRwREo for ; Mon, 6 Jun 2016 14:30: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 D6EFC12B00D for ; Mon, 6 Jun 2016 14:30:15 -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 u56LUDnO026839; Mon, 6 Jun 2016 23:30: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 9DCEA61FA5; Mon, 6 Jun 2016 23:30: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 58luxUdOmVlK; Mon, 6 Jun 2016 23:30:12 +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 4C59F61F9A; Mon, 6 Jun 2016 23:30:11 +0200 (CEST) Date: Mon, 06 Jun 2016 23:30:14 +0200 Message-ID: <87lh2ic8ex.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht In-Reply-To: References: <7ir3cfv3it.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]); Mon, 06 Jun 2016 23:30:13 +0200 (CEST) X-Miltered: at korolev with ID 5755EB65.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5755EB65.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 : 5755EB65.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 at IETF Subject: [babel] Beyond the charter [was: Revised 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, 06 Jun 2016 21:30:19 -0000 > It is ok with me if this stuff remains out of scope for the charter, but > to describe my thinking more fully, as it sort of does affect the > characteristics of the next few billion devices Dave, Just because they're not in the charter doesn't mean we're not allowed to work on them. And I'm sure Alia will help us recharter if we have a good argument to add new stuff. > I basically long ago blurred the distinction between "host" and "router" years > ago. In my world, nearly all hosts are capable of routing, and have 2 or more > possible ways to get to each other or to the internet. Yes, i like your work. However, as I understand it is simply a consequence of Babel being able to carry host routes and being easy enough to configure to put it on each device. Or do you need anything more from Babel? > * usbnet: IP over USB I'm not sure if usbnet needs any support from the routing protocol. It's a fast link with low latency and little packet loss, right? Perhaps carrier signalling? > One of the mantras of homenet was "no host changes", which seemed silly Agreed, but what's done is done -- we failed to convince the WG. Now is the time to experiment with host changes. (As we speak, I've got a student deploying HNCP on ten routers -- once we have a stable testbed, we'll be able to experiment with host changes.) > [1] This is for example a wifi+usb gateway running on the 9 dollar > "getchip.com" device. I want one! Actually, I want twenty. (Can you get them yet? How long do you wait?) -- Juliusz From nobody Mon Jun 6 16:29:27 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 6CDDD12D66A for ; Mon, 6 Jun 2016 16:29:25 -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 jkRrB7d7Kpei for ; Mon, 6 Jun 2016 16:29:24 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 C362A12D13A for ; Mon, 6 Jun 2016 16:29:23 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id p204so55367710oih.3 for ; Mon, 06 Jun 2016 16:29:23 -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:content-transfer-encoding; bh=PHPyCKwYASOIbeaWmrAQTRysdbp9/56xHkr4utb2xbw=; b=J840QBhi9ghXfY+sSsGIPxW0mgRwo3hTIDN86oIna5o/BmXiST+2wa6YY4YRBYABc8 AK9L2ulovcsHphVyoJneZBRyIHet+RP9PCaHB7gkNbDnGJrhRxpi3LQRUC05UsFinDWe TXaYtlM2jc6F7kngJ8mlcDT8nGbBsRJgcsYA9qbKllC7NM0jXw7ch5QnbpFmqh1WUQPU tHX5S4IWemq8auY9tav+AaapioN6x8PtChM4mx2rV/8l7gtYuY6Als31iMHz0a1gw068 /9uOvkg5O3k0vgq85RvxB/m67dJ47/LDxKODw9ehhgV6JdFPmY7UaU65y9RwKLN5cxaw tljQ== 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:content-transfer-encoding; bh=PHPyCKwYASOIbeaWmrAQTRysdbp9/56xHkr4utb2xbw=; b=B+ZRLHRcl5ZhWGdYlYPvBc8jX0WSw+gJIHL7IRv5e8uFcmQIgw5JHS2w2MbU4Oq21K iHqu/WSMl0GmHgBekhlwFNnNtqU8cHNJxYi6J9Jc8zVb+1l+JLncwTJE2lpGqXfsE6vX qT4KhTxAHGVqHx3IPCM4SDvlg2/DtlTIaIVhl3jvjvdYCf4juLKHlVxVqHfz765SbJGa Gi03uz7eJvkjxN4kQXU4vlAk+jIhI/Xbj/8aj3xyafgvSLZk7WZRi7vWT8ZfgzciPpoU 3REYA1Hv09OzshieV256K6vcnbgO5sz1xLY/EPiWc9eb+cLoSGuPxSq+xsYJpLEdJMnq y2Zw== X-Gm-Message-State: ALyK8tL0GyVrqjCiCUriwPO8D5nX4wRTDpZpmsfIW6zfPGGTzIciQKlsTCQwDptctioPcbyxSfGHkc6IcqBIdw== X-Received: by 10.157.9.226 with SMTP id 31mr10693919otz.165.1465255763098; Mon, 06 Jun 2016 16:29:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Mon, 6 Jun 2016 16:29:22 -0700 (PDT) In-Reply-To: <87lh2ic8ex.wl-jch@pps.univ-paris-diderot.fr> References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> <87lh2ic8ex.wl-jch@pps.univ-paris-diderot.fr> From: Dave Taht Date: Mon, 6 Jun 2016 16:29:22 -0700 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Babel at IETF Subject: Re: [babel] Beyond the charter [was: Revised 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, 06 Jun 2016 23:29:25 -0000 On Mon, Jun 6, 2016 at 2:30 PM, Juliusz Chroboczek wrote: > >> I basically long ago blurred the distinction between "host" and "router"= years >> ago. In my world, nearly all hosts are capable of routing, and have 2 or= more >> possible ways to get to each other or to the internet. > > Yes, i like your work. However, as I understand it is simply > a consequence of Babel being able to carry host routes and being easy > enough to configure to put it on each device. Or do you need anything > more from Babel? World peace? > ">> * usbnet: IP over USB > > I'm not sure if usbnet needs any support from the routing protocol. It's usbnet tends to come up with a random mac address. You can stablize it using udev rules. systemd is (sigh) taking things one step further by creating a random device name by default, instead of things like usb0, usb1, usb2, etc, leading to truly "memorable" device names and the style of name chosen has varied from release to release. For example, until recently, I'd see usbnet device names generated by systemd like: enx2a648d5d7941 and just recently it started naming usbnet like enp0s16u1 I have sometimes thought it would be good (at least on linux) to either allow device name globbing or monitor /sys/class/net inside of babel, or to prefer generating the router_id from stablest to least stable sort of device types. (ethernet, wifi, usbnet) > a fast link with low latency and little packet loss, right? Perhaps > carrier signalling? Maybe. I'm still looking over the issues I found with routing asymmetry here: http://blog.cerowrt.org/post/babel_half_fail/ usbnet has worked really well, for me, for over 16 years. I'm bugged that so few android devices support it out the box. > >> One of the mantras of homenet was "no host changes", which seemed silly > > Agreed, but what's done is done -- we failed to convince the WG. Now is > the time to experiment with host changes. (As we speak, I've got > a student deploying HNCP on ten routers -- once we have a stable testbed, > we'll be able to experiment with host changes.) Groovy. I have not been using hncp as yet except for a brief test here and there - I have a rant about wanting just *one* static-unchanging-no-matter-what ipv6 address sitting in my blog's queue (with tight integration with naming and service discovery). hncp does seem like "the right thing", but I'm not huge on giving my lightbulbs global connectivity, and would rather like to ensure (somehow) certain devices never got anything more robust than a ULA. >> [1] This is for example a wifi+usb gateway running on the 9 dollar >> "getchip.com" device. > > I want one! Actually, I want twenty. (Can you get them yet? How long d= o > you wait?) Got mine hand-delivered. :) I think they are ramping up production now. I'll ask. There are also a lot of other boards worth looking at - notably the pi3, but recently this one, also, popped up on my radar. http://hackerboards.com/open-spec-octa-core-nanopi-m3-sbc-sells-for-35/ the odroid c2, thus far, has been the speed winner for me, but that lacks wifi, and the usb sticks I've tried thus far were almost universally miserable. That said, I kind of expect nearly all of the next generation of hackerboards to include wifi on them. (I hit reload on hackerboards.com a couple times a week. Just where things are this year is astonishing, and I kind of expect quad core boards to drop in cost even more. *And* I try to remember that the cheap hackerboards appearing presently tend to be the chips that major manufacturers were shipping already in their tvs. I am afraid to look up how many crappy, wifi enabled, tvs shipped last year) I was always impressed by the build quality of the beaglebones - now they have a ti wifi chip in them I know nothing about: http://hackerboards.com/beaglebone-green-wireless-adds-wifi-ble-usbs/ I've also been looking over this one to explore 3g + wifi support. http://hackerboards.com/open-linux-based-platform-simplifies-wireless-iot/ More choices: http://hackerboards.com/2016-survey-of-open-spec-hacker-frien= dly-sbcs/ > > -- Juliusz --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Mon Jun 6 16:50: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 57A4A12D630 for ; Mon, 6 Jun 2016 16:50: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 5iYGhW1NBR-I for ; Mon, 6 Jun 2016 16:50:07 -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 62E2D12D5E8 for ; Mon, 6 Jun 2016 16:50:07 -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 u56No5xl018305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Jun 2016 01:50:05 +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 u56No56a022116; Tue, 7 Jun 2016 01:50:05 +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 752E661FA5; Tue, 7 Jun 2016 01:50:05 +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 uU_6B1DQHyIF; Tue, 7 Jun 2016 01:50:04 +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 0AD0261FA7; Tue, 7 Jun 2016 01:50:04 +0200 (CEST) Date: Tue, 07 Jun 2016 01:50:06 +0200 Message-ID: <87r3c9x4gh.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> <87lh2ic8ex.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]); Tue, 07 Jun 2016 01:50:05 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 07 Jun 2016 01:50:05 +0200 (CEST) X-Miltered: at korolev with ID 57560C2D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57560C2D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57560C2D.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57560C2D.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 : 57560C2D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57560C2D.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: [babel] HNCP on hosts [was: Beyond the 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, 06 Jun 2016 23:50:09 -0000 That's really getting off topic for this list -- if anyone wishes to complain, please do, and we'll move elsewhere. >> Or do you need anything more from Babel? > World peace? Babel, by effectively removing all barriers to communication between different cultures and races, has caused more and bloodier wars than anything else in the history of creation. (And if you miss where the (mis-)quotation is from -- give up your geek card.) > hncp does seem like "the right thing", but I'm not huge on giving my > lightbulbs global connectivity, and would rather like to ensure > (somehow) certain devices never got anything more robust than a ULA. HNCP is pretty flexible. If your lightbulb is running HNCP, then it can certainly avoid assigning any global addresses to itself. If your lightbulb is not, then you can put it on a link that doesn't announce any global prefixes and is firewalled away from the Global Internet. Unfortunately, there's no in-band signalling -- all the routers on the restricted link must be configured to avoid assigning global prefixes. If only one router is mis-configured, you leak. -- Juliusz From nobody Mon Jun 6 17:05:13 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 9C85C12D14A for ; Mon, 6 Jun 2016 17:05:11 -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 2rQCC0R-sbmS for ; Mon, 6 Jun 2016 17:05:06 -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 106E612D1A1 for ; Mon, 6 Jun 2016 17:05:06 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id k23so252030310oih.0 for ; Mon, 06 Jun 2016 17:05:06 -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=G6/sl338eb/lJeWvl0KKHM+lSjPbPBhWBo9ZtTfzIKI=; b=T90UXWoB+ORFIw2duDjv4lwIOcWv9Wo/+NYG2eHAT7KmaYjI8PB/t+wfipJr7TCkfv mk2/XFJkW2TT7d4v3Anlv4OADJWuGFO8MTOiy1AxUu9ejFuj+xTP4+Rt3JtDibQlO7yO HBWHZJRIW4VOO7Dujt7EJ/QfLN5/i6HRkdzLaMdvf/0MXm8vnqY1QJZuCXKP5of+V6LG 3zIr2aRQ9hojERHgHJcG5QyT5MT7jDX19emjIJsTqnyh5dXS8yFx0oCW8Lp5n1NdVUPr zTzPw+qjmrdfvRo+A7VVUWHHZb7wB/Ud3qECcY6d8eaEg/OzVaSj5Vc9nQoNx32a6iyH 9nwQ== 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=G6/sl338eb/lJeWvl0KKHM+lSjPbPBhWBo9ZtTfzIKI=; b=UIYrJJXKJvjcepsh0Pvqt5wXnCKFKQmuxEsI4YaRaB97IqIV1iJZ04I239/EOpLn3x 6xCC7MbMt67gOBYIqE9lP/bYwA1bjRpT1mJJq2OvTJems7oM6bFQ1yz1J5TRbHrGbZ/Z thzexbekfN8FERti+TY6o7+q5p1zPwlNw+ygFtsqOWL5Q532H8RupIG1xCQ/Mz+pdZtr dja26xTUBS14hQT3RP63Epli59f18640mgNuN4/SvURtHFW00MN94bTSGiynXn7SNXNp mdXcDmMEPHItbMH+boUPT6mBdlMvf7GlYUhUjZilis4bqrLTGpYL1ocnr8Sy0gbWYH8x X17w== X-Gm-Message-State: ALyK8tL7nQIa7IH/RVqJ5v1mSVdGTgitZ84cz834+AORDPJI43tFhdgjUJIKvkfXj9W1pShl+x0NmbE74TazVA== X-Received: by 10.202.83.82 with SMTP id h79mr8455615oib.139.1465257905454; Mon, 06 Jun 2016 17:05:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Mon, 6 Jun 2016 17:05:04 -0700 (PDT) In-Reply-To: References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> <87lh2ic8ex.wl-jch@pps.univ-paris-diderot.fr> From: Dave Taht Date: Mon, 6 Jun 2016 17:05:04 -0700 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Babel at IETF Subject: Re: [babel] Beyond the charter [was: Revised 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, 07 Jun 2016 00:05:11 -0000 While I'm mentioning cheap routable devices, I have a couple compute sticks - where I wish hdmi-ethernet worked - or usbnet: The previous generation intel ubuntu stick was astonishingly useable and the wifi was not horrible, and they are down to 58 dollars. http://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=ubuntu+stick newer ones have 802.11ac and cost about 148, but amazon only seems to have windows ones at the moment. Chromebooks have come a long way, too, and you can get a pretty good android tablet for under 100. I think getting babel (and hncp) running on these sorts of devices would be very useful. (I have successfully worked to get source specific natively supported upstream in the rpi 2 and 3 and odroid c2 thus far) I am under the impression that there exists a babel port to ios, somewhere, but their APIs for doing policy routing are different than anyone elses. I would very much like to see the ietf, in general, attempt to "close the loop" by enabling particpants to be able to make new software and ideas available more quickly across the largest parts of the software ecosystem. (or participants going the extra mile to test and build stuff on the largest parts of the ecosystem). From nobody Tue Jun 7 03:29:57 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 EE76A12B03E; Tue, 7 Jun 2016 03:29:55 -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 bjyz-uENCryt; Tue, 7 Jun 2016 03:29:53 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 B5B8A12B009; Tue, 7 Jun 2016 03:29:53 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o16so165474333ywd.2; Tue, 07 Jun 2016 03:29:53 -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=Lb16vwHQDHdiwM+B5ge620eaFUpNRHk+NtgBE64s6PQ=; b=sGzZYs8f9WhkNWZech2mL7NOcYc0savMj8Y0ST0Fs3GTXtAb9fRl3qDTHr0cMxWaCb ra3gRkW+Fr1rAGsBy4ELiEkJutw3JD52Z+Ayvutx+BxIDq96E7+xUgUqj7dQnWblyi2z +l7/PVvgghLlOn0QYCeCmb3Y3RFQT0deABnzGeugPWTLe2cWp5ctH5C3zVI3fTR4+RXT r760YBK0vTD1hUQ22zjweuEpdRUUb9GMbzA7+kxLTTVKfmxZTrF0uCFr2Gkc5nlJ642U rErscCOjSO+iruY736OZUMmzcqFl+DhJfdHUeRRnuAvjK8m4dn3ZjZ87r1NcTDUsa4Lh 7RwQ== 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=Lb16vwHQDHdiwM+B5ge620eaFUpNRHk+NtgBE64s6PQ=; b=ilbKIXhqdg9jEtWtJSjMxqe0I/yDaXmZJBEa3LMmJeweu31MKClvZOv//lXpj2wf4v B5CkuckflZneBz/S05tw4T6f7yP66eMyfuCRMeBjj0Psc2uXMZ3Q3+3Gpy16gGfeWDtu 5rqhWU2wA9wl1CCbnLoXYpq73vnORCSzH3ARPbCm5s5wg89WUK77d8WRuVzeX9ThjEPI T+5uGAOCmLch2zr1LErTjZc6WgJTU3go0H30irlMNro54eEZUsLwF+v8KpsdYVjOlGFF qzJah7+yS8PUx4lgpZIw4vJl6rywCrS79FHdM+zHBQfzEimaB8B0AxrCuU71VbSqZ2Gg aPFA== X-Gm-Message-State: ALyK8tLAC7stf/AlM7AGoipdoWifIEN2FRt0qsRm4iDHHIu/fZQJrboaj8OXC/ITuOn/DA== X-Received: by 10.129.72.129 with SMTP id v123mr13009407ywa.97.1465295392870; Tue, 07 Jun 2016 03:29:52 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id u188sm14072958ywf.8.2016.06.07.03.29.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jun 2016 03:29:52 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Alia Atlas'" , "'Juliusz Chroboczek'" References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Date: Tue, 7 Jun 2016 06:29:46 -0400 Message-ID: <00db01d1c0a7$83e35440$8ba9fcc0$@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: AQFcRnA/wfbQn35MdR1vqp4a5XaTCgKsS2R1AngE+X2gn5+VMA== Content-Language: en-us Archived-At: Cc: 'Donald Eastlake' , babel-chairs@ietf.org, 'Babel at IETF' Subject: Re: [babel] Revised 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, 07 Jun 2016 10:29:56 -0000 This looks great to me -- thanks, Alia! :-) Russ > -----Original Message----- > From: babel [mailto:babel-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Friday, June 3, 2016 4:40 PM > To: Juliusz Chroboczek > Cc: Donald Eastlake ; babel-chairs@ietf.org; Babel = at > IETF > Subject: Re: [babel] Revised Babel Charter >=20 > Hi Donald, Russ, Juliusz, Toke, etc., >=20 > I have read through all the discussion and IESG comments on the = charter. > Here is what I have for an updated version. I do need to get it out = for > External Review soon so that it can come back onto the IESG telechat = for final > approval. > The External Review is to give time for comments by those not on the = IESG or > WG - and particularly that it goes out to other organizations who = might be > interested. In the case of Babel, that is relevant because of the = potential > interaction with the Broadband Forum on TR-069. >=20 > The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I = am > including the text below. >=20 > = =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=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=3D=3D=3D >=20 > Babel is a loop-avoiding, distance vector routing protocol with good > provisions for dynamically computed link metrics. It is robust even in = the > presence of link metric oscillations and the failure of transitivity. = The core of > the Babel protocol and security extensions are described in = Experimental > Independent Stream RFCs 6126, 7557, and 7298. >=20 > 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). >=20 > The Working Group will focus on moving the Babel protocol to IETF = Proposed > Standard with IETF review. This includes clarifying RFC 6126 and = integrating > RFC 7557 and feedback provided by independent implementations, and > resolving comments. It is not a requirement that the Babel protocol > produced is backwards compatible with RFC 6126. It is a requirement = that > Babel support at least one profile that is auto-configuring. Other = documents > that are relevant to the above work can also be produced. Particular > emphasis will be placed on work needed for a Proposed Standard routing > protocol, such as ensuring manageability and strong security. Link = metric > measurement or link metric calculation procedures significantly more > complex that those currently in Babel are out of scope. >=20 > Work Items: >=20 > - Produce a revision of RFC 6126 suitable for publication as a = Proposed > Standard > -- incorporate in the revision developments since RFC 6126 > -- resolve technical issues found > -- include in the base specification the extensibility work in RFC = 7557 > -- support auto-configuration > -- consider any important changes based on experience with Babel to = date. >=20 > - Address security needs for BABEL. This may include using the = techniques in > RFC 7298, or other alternatives. Security may be included in the base = spec or > the base spec may normatively reference a separate Proposed Standard > specification. This is required as part of moving Babel to Proposed = Standard. >=20 > - Address manageability of Babel by producing an informational model = for > use by other network management such as the Broadband Forum TR-069, > and a YANG data module based on that information model. This YANG data > module to be consistent with the ongoing effort to use YANG data = modules > in the Routing Area. This work is required as part of moving Babel to > Proposed Standard. >=20 > - 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. >=20 > - Coordinate with other Working Groups, such as the HOMENET WG for = likely > applicability, the RTGWG and V6OPS WG about Source-Specific Routing to > support IPv6 multihoming, the PIM WG for discussion around multicast, = and > the MANET WG for considerations around wireless. >=20 > - Liaise as necessary with the Broadband Forum to facilitate use of = the Babel > management Information Model for TR-069. >=20 > - The Working Group should document its ongoing implementation > experience with Babel, so that new WG participants can understand the > state that is driving this work and the experience driving changes. > This documentation may be on the Working Group's wiki, in an = internet-draft > that isn't expected to be published as an RFC, or a combination. >=20 > - As a secondary focus, the Working Group may work on multicast = aspects of > Babel. This may include discussion of any potential issues for = supporting > Babel running with PIM-SM in an auto-configuration profile. It may = include > exploring Babel carrying separate metrics for multicast. It may even = include > discussion and consultation with the PIM WG about Babel providing the > ability to build multicast routing tables. With AD and WG agreement, = once an > approach is understood, then a milestone may be added for an = associated > document targeted as Proposed Standard. >=20 > - As a secondary focus, the Working Group may work on documents = defining > source specific routing extensions for Babel as a way of handling > IPv6 multihoming. >=20 > Thus, the Working Group will produce a Proposed Standard Babel > specification, including or paired with a suitable Proposed Standard > specification covering the security mechanism(s) for BABEL. It will = also > produce a management information and data model for BABEL as a = Proposed > Standard RFC. An applicability statement will be produced as an = Informational > RFC. >=20 > Proposed Milestones >=20 > Date Milestone > Aug 2017 IESG Submission of Babel Applicability draft > Jul 2017 IESG Submission of Babel Management draft > Jul 2017 IESG Submission of RFC6126bis and potentially companion > security mechanisms draft > Oct 2016 WG adoption of Babel Management (Info Model & YANG > Model) draft > Jul 2016 WG adoption of RFC6126bis > Jul 2016 WG adoption of Babel Applicability draft > draft-chroboczek-babel-applicability > = > = =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=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=3D=3D=3D >=20 >=20 >=20 > On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek = diderot.fr > > wrote: >=20 >=20 > > - 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. >=20 > Do we really need to specify the technology used for this > information? > What about >=20 > "to keep its wiki updated with implementation experience" -> "to > maintain up-to-date, publicly accessible information about > implementation experience" >=20 > Then the WG can choose whether to do a wiki page, an internet- > draft, or > whatever else we find convenient. >=20 > -- Juliusz >=20 >=20 From nobody Tue Jun 7 10:12:16 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 3A68B12D7F7; Tue, 7 Jun 2016 10:12:14 -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 7-TZaRT95AAm; Tue, 7 Jun 2016 10:12:11 -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 6EF0812D7EE; Tue, 7 Jun 2016 10:12:11 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id s139so48230285oie.2; Tue, 07 Jun 2016 10:12: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=hPhPXqsL37sNRQDwDNc8Tw4uS5CAOSM3pfzqauAWXfQ=; b=mHXKxUObVNkX4r4KPhXdNi+iiSxyQn6LmlH2jPqloi0OhTKZXNSq2fvClyxdgKNCgr qNjFfoHsXM4tX1iisatZVSBOqfXOkIX8GgbkxzNMPe0aOkvdHsIv5oX2a/MlX/CdXJom ssxNbGux0jAOg6N6K3HuOhAs/CmckkjDeX1xU+yebTLjLvZ7y0fLs5XS3cL6wEYuANHP aUShNvOugKoEjOKDdoJhj185AqZJHXIQQfO+MbcUYLZt6ixRErEDDl6BDfTq843A4dYa Olc3uKPtwAEdC3ZBuyeofIXx+k9qPe81onrG2t40qmxBswoB+JLSouhCOD1kzC4hNvi6 ogfg== 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=hPhPXqsL37sNRQDwDNc8Tw4uS5CAOSM3pfzqauAWXfQ=; b=Q18LfZdDNGVK7bPg4BdMDQgP2xgO/0oRyewrI4zVve/gnb/C9O2fnKTOXTgZ0uiTrV GwpaIhOqpLLvaBzAas0jbXw4YonvqQZVmcZ9QYvtez9apJEHMn2lv4RvzNtKjI+AdDOd Bv6knyepKpffutZMMsR0cUEntTm9AcJjFilirFa4jfRcF8aNcpM9iLohRM7qdLOQPpD1 AOKOHIeIoN6O8wINwwEoOChh46sfSpdsG6QbNhLo8QZ0iTWlk5i1zgrzywp94FQ2nf8f iBfBHvHXS3vkKWgccLp+gs7GFE6sZA9EMAcePl+P6u2KmdWAB2e1bTvFEh9vv5Hpzq2J TJ3Q== X-Gm-Message-State: ALyK8tKVursnxaGJ2W4E+qs4VLvhOPrbGOahBLJ743K1y46NT4NpwxPWAvzpgwid2lam92WScwukad/cdKS87A== X-Received: by 10.157.51.74 with SMTP id u10mr387710otd.124.1465319530517; Tue, 07 Jun 2016 10:12:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.38.66 with HTTP; Tue, 7 Jun 2016 10:11:55 -0700 (PDT) In-Reply-To: <00db01d1c0a7$83e35440$8ba9fcc0$@gmail.com> References: <7ir3cfv3it.wl-jch@pps.univ-paris-diderot.fr> <00db01d1c0a7$83e35440$8ba9fcc0$@gmail.com> From: Donald Eastlake Date: Tue, 7 Jun 2016 13:11:55 -0400 Message-ID: To: Russ White <7riw77@gmail.com> Content-Type: multipart/alternative; boundary=001a113e27fa195d160534b34ac2 Archived-At: Cc: babel-chairs@ietf.org, Juliusz Chroboczek , Babel at IETF , Alia Atlas Subject: Re: [babel] Revised 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, 07 Jun 2016 17:12:14 -0000 --001a113e27fa195d160534b34ac2 Content-Type: text/plain; charset=UTF-8 Looks good to me. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jun 7, 2016 at 6:29 AM, Russ White <7riw77@gmail.com> wrote: > > This looks great to me -- thanks, Alia! > > :-) > > Russ > > > -----Original Message----- > > From: babel [mailto:babel-bounces@ietf.org] On Behalf Of Alia Atlas > > Sent: Friday, June 3, 2016 4:40 PM > > To: Juliusz Chroboczek > > Cc: Donald Eastlake ; babel-chairs@ietf.org; Babel at > > IETF > > Subject: Re: [babel] Revised Babel Charter > > > > Hi Donald, Russ, Juliusz, Toke, etc., > > > > I have read through all the discussion and IESG comments on the charter. > > Here is what I have for an updated version. I do need to get it out for > > External Review soon so that it can come back onto the IESG telechat for > final > > approval. > > The External Review is to give time for comments by those not on the > IESG or > > WG - and particularly that it goes out to other organizations who might > be > > interested. In the case of Babel, that is relevant because of the > potential > > interaction with the Broadband Forum on TR-069. > > > > The link is https://datatracker.ietf.org/doc/charter-ietf-babel/ . I am > > including the text below. > > > > ========================================================== > > ======= > > > > Babel is a loop-avoiding, distance vector routing protocol with good > > provisions for dynamically computed link metrics. It is robust even in > the > > presence of link metric oscillations and the failure of transitivity. > The core of > > the Babel protocol and security extensions are described in Experimental > > Independent Stream RFCs 6126, 7557, and 7298. > > > > These RFCs are the basis of three independent, open source > > implementations. There is some production deployment of these > > implementations, notably in hybrid networks (networks that include > classical, > > wired parts with meshy radio bits) and in global overlay networks > (networks > > built out of large numbers of tunnels spanning continents). > > > > The Working Group will focus on moving the Babel protocol to IETF > Proposed > > Standard with IETF review. This includes clarifying RFC 6126 and > integrating > > RFC 7557 and feedback provided by independent implementations, and > > resolving comments. It is not a requirement that the Babel protocol > > produced is backwards compatible with RFC 6126. It is a requirement that > > Babel support at least one profile that is auto-configuring. Other > documents > > that are relevant to the above work can also be produced. Particular > > emphasis will be placed on work needed for a Proposed Standard routing > > protocol, such as ensuring manageability and strong security. Link metric > > measurement or link metric calculation procedures significantly more > > complex that those currently in Babel are out of scope. > > > > Work Items: > > > > - Produce a revision of RFC 6126 suitable for publication as a Proposed > > Standard > > -- incorporate in the revision developments since RFC 6126 > > -- resolve technical issues found > > -- include in the base specification the extensibility work in RFC 7557 > > -- support auto-configuration > > -- consider any important changes based on experience with Babel to date. > > > > - Address security needs for BABEL. This may include using the > techniques in > > RFC 7298, or other alternatives. Security may be included in the base > spec or > > the base spec may normatively reference a separate Proposed Standard > > specification. This is required as part of moving Babel to Proposed > Standard. > > > > - Address manageability of Babel by producing an informational model for > > use by other network management such as the Broadband Forum TR-069, > > and a YANG data module based on that information model. This YANG data > > module to be consistent with the ongoing effort to use YANG data modules > > in the Routing Area. This work is required as part of moving Babel to > > Proposed Standard. > > > > - As the Proposed Standard version of Babel is completed, an > Applicability > > Statement should be finalized to guide those potentially interested in > > deploying Babel. This Applicability Statement may include deployment > advice > > and will be published as an RFC. > > > > - Coordinate with other Working Groups, such as the HOMENET WG for likely > > applicability, the RTGWG and V6OPS WG about Source-Specific Routing to > > support IPv6 multihoming, the PIM WG for discussion around multicast, and > > the MANET WG for considerations around wireless. > > > > - Liaise as necessary with the Broadband Forum to facilitate use of the > Babel > > management Information Model for TR-069. > > > > - The Working Group should document its ongoing implementation > > experience with Babel, so that new WG participants can understand the > > state that is driving this work and the experience driving changes. > > This documentation may be on the Working Group's wiki, in an > internet-draft > > that isn't expected to be published as an RFC, or a combination. > > > > - As a secondary focus, the Working Group may work on multicast aspects > of > > Babel. This may include discussion of any potential issues for > supporting > > Babel running with PIM-SM in an auto-configuration profile. It may > include > > exploring Babel carrying separate metrics for multicast. It may even > include > > discussion and consultation with the PIM WG about Babel providing the > > ability to build multicast routing tables. With AD and WG agreement, > once an > > approach is understood, then a milestone may be added for an associated > > document targeted as Proposed Standard. > > > > - As a secondary focus, the Working Group may work on documents defining > > source specific routing extensions for Babel as a way of handling > > IPv6 multihoming. > > > > Thus, the Working Group will produce a Proposed Standard Babel > > specification, including or paired with a suitable Proposed Standard > > specification covering the security mechanism(s) for BABEL. It will also > > produce a management information and data model for BABEL as a Proposed > > Standard RFC. An applicability statement will be produced as an > Informational > > RFC. > > > > Proposed Milestones > > > > Date Milestone > > Aug 2017 IESG Submission of Babel Applicability draft > > Jul 2017 IESG Submission of Babel Management draft > > Jul 2017 IESG Submission of RFC6126bis and potentially companion > > security mechanisms draft > > Oct 2016 WG adoption of Babel Management (Info Model & YANG > > Model) draft > > Jul 2016 WG adoption of RFC6126bis > > Jul 2016 WG adoption of Babel Applicability draft > > draft-chroboczek-babel-applicability > > > > ========================================================== > > ======= > > > > > > > > On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek > diderot.fr > > > wrote: > > > > > > > - The working group is encouraged to keep its wiki updated with > > > implementation experience with Babel so that new WG > > participants can > > > understand the state that is driving this work and the experience > > > driving changes. > > > > Do we really need to specify the technology used for this > > information? > > What about > > > > "to keep its wiki updated with implementation experience" -> "to > > maintain up-to-date, publicly accessible information about > > implementation experience" > > > > Then the WG can choose whether to do a wiki page, an internet- > > draft, or > > whatever else we find convenient. > > > > -- Juliusz > > > > > > > --001a113e27fa195d160534b34ac2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good to me.


On Tue, Jun 7, 2016 at 6:29 AM, Russ White <= span dir=3D"ltr"><= 7riw77@gmail.com> wrote:
This looks great to me -- thanks, Alia!

:-)

Russ

> -----Original Message-----
> From: babel [mailto:babel-bo= unces@ietf.org] On Behalf Of Alia Atlas
> Sent: Friday, June 3, 2016 4:40 PM
> To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
> Cc: Donald Eastlake <d3e3e3@gma= il.com>; babel-chairs@ietf.= org; Babel at
> IETF <babel@ietf.org>
> Subject: Re: [babel] Revised Babel Charter
>
> Hi Donald, Russ, Juliusz, Toke, etc.,
>
> I have read through all the discussion and IESG comments on the charte= r.
> Here is what I have for an updated version.=C2=A0 I do need to get it = out for
> External Review soon so that it can come back onto the IESG telechat f= or final
> approval.
> The External Review is to give time for comments by those not on the I= ESG or
> WG - and particularly that it goes out to other organizations who migh= t be
> interested.=C2=A0 In the case of Babel, that is relevant because of th= e potential
> interaction with the Broadband Forum on TR-069.
>
> The link is https://datatracker.ietf.org/do= c/charter-ietf-babel/ .=C2=A0 I am
> including the text below.
>
> =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=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=3D=3D=3D
>
> Babel is a loop-avoiding, distance vector routing protocol with good > provisions for dynamically computed link metrics. It is robust even in= the
> presence of link metric oscillations and the failure of transitivity. = The core of
> the Babel protocol and security extensions are described in Experiment= al
> 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 cla= ssical,
> wired parts with meshy radio bits) and in global overlay networks (net= works
> built out of large numbers of tunnels spanning continents).
>
> The Working Group will focus on moving the Babel protocol to IETF Prop= osed
> Standard with IETF review.=C2=A0 This includes clarifying RFC 6126 and= integrating
> RFC 7557 and feedback provided by independent implementations, and
> resolving comments. It is not a requirement that the Babel protocol > produced is backwards compatible with RFC 6126.=C2=A0 It is a requirem= ent that
> Babel support at least one profile that is auto-configuring.=C2=A0 Oth= er documents
> that are relevant to the above work can also be produced. Particular > emphasis will be placed on work needed for a Proposed Standard routing=
> protocol, such as ensuring manageability and strong security. Link met= ric
> measurement or link metric calculation procedures significantly more > complex that those currently in Babel are out of scope.
>
> Work Items:
>
> - Produce a revision of RFC 6126 suitable for publication as a Propose= d
> Standard
> -- incorporate in the revision developments since RFC 6126
> -- resolve technical issues found
> -- include in the base specification the extensibility work in RFC 755= 7
> -- support auto-configuration
> -- consider any important changes based on experience with Babel to da= te.
>
> - Address security needs for BABEL. This may include using the techniq= ues in
> RFC 7298, or other alternatives. Security may be included in the base = spec or
> the base spec may normatively reference a separate Proposed Standard > specification. This is required as part of moving Babel to Proposed St= andard.
>
> - Address manageability of Babel by producing an informational model f= or
> use by other network management such as the Broadband Forum TR-069, > and a YANG data module based on that information model. This YANG data=
> module to be consistent with the ongoing effort to use YANG data modul= es
> in the Routing Area. This work is required as part of moving Babel to<= br> > Proposed Standard.
>
> - As the Proposed Standard version of Babel is completed, an Applicabi= lity
> Statement should be finalized to guide those potentially interested in=
> deploying Babel. This Applicability Statement may include deployment a= dvice
> and will be published as an RFC.
>
> - Coordinate with other Working Groups, such as the HOMENET WG for lik= ely
> applicability, the RTGWG and V6OPS WG about Source-Specific Routing to=
> support IPv6 multihoming, the PIM WG for discussion around multicast, = and
> the MANET WG for considerations around wireless.
>
> - Liaise as necessary with the Broadband Forum to facilitate use of th= e Babel
> management Information Model for TR-069.
>
> - The Working Group should document its ongoing implementation
> experience with Babel, so that new WG participants can understand the<= br> > state that is driving this work and the experience driving changes. > This documentation may be on the Working Group's wiki, in an inter= net-draft
> that isn't expected to be published as an RFC, or a combination. >
> - As a secondary focus, the Working Group may work on multicast aspect= s of
> Babel.=C2=A0 This may include discussion of any potential issues for s= upporting
> Babel running with PIM-SM in an auto-configuration profile.=C2=A0 It m= ay include
> exploring Babel carrying separate metrics for multicast.=C2=A0 It may = even include
> discussion and consultation with the PIM WG about Babel providing the<= br> > ability to build multicast routing tables.=C2=A0 With AD and WG agreem= ent, once an
> approach is understood, then a milestone may be added for an associate= d
> document targeted as Proposed Standard.
>
> - As a secondary focus, the Working Group may work on documents defini= ng
> source specific routing extensions for Babel as a way of handling
> IPv6 multihoming.
>
> Thus, the Working Group will produce a Proposed Standard Babel
> specification, including or paired with a suitable Proposed Standard > specification covering the security mechanism(s) for BABEL. It will al= so
> produce a management information and data model for BABEL as a Propose= d
> Standard RFC. An applicability statement will be produced as an Inform= ational
> RFC.
>
> Proposed Milestones
>
> Date=C2=A0 Milestone
> Aug 2017=C2=A0 =C2=A0 =C2=A0 IESG Submission of Babel Applicability dr= aft
> Jul 2017=C2=A0 =C2=A0 =C2=A0 IESG Submission of Babel Management draft=
> Jul 2017=C2=A0 =C2=A0 =C2=A0 IESG Submission of RFC6126bis and potenti= ally companion
> security mechanisms draft
> Oct 2016=C2=A0 =C2=A0 =C2=A0 WG adoption of Babel Management (Info Mod= el & YANG
> Model) draft
> Jul 2016=C2=A0 =C2=A0 =C2=A0 WG adoption of RFC6126bis
> Jul 2016=C2=A0 =C2=A0 =C2=A0 WG adoption of Babel Applicability draft<= br> > draft-chroboczek-babel-applicability
> <https://d= atatracker.ietf.org/doc/draft-chroboczek-babel-applicability/>
> =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=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=3D=3D=3D
>
>
>
> On Thu, Jun 2, 2016 at 2:39 PM, Juliusz Chroboczek <jch@pps.univ-pa= ris-
> diderot.fr <mailto:jch@pps.univ-paris-diderot.fr> >
> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> - The working group is encouraged to ke= ep its wiki updated with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> implementation experience with Babel so= that new WG
> participants can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> understand the state that is driving th= is work and the experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> driving changes.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Do we really need to specify the technology = used for this
> information?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What about
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"to keep its wiki updated with i= mplementation experience" -> "to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0maintain up-to-date, publicly accessi= ble information about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation experience"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Then the WG can choose whether to do a wiki = page, an internet-
> draft, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0whatever else we find convenient.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0-- Juliusz
>
>



--001a113e27fa195d160534b34ac2-- From nobody Tue Jun 7 10:57:57 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 270CA12D108; Tue, 7 Jun 2016 10:57:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607175756.13708.76878.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 10:57:56 -0700 Archived-At: Cc: babel@ietf.org Subject: [babel] WG Review: Babel routing protocol (babel) 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, 07 Jun 2016 17:57:56 -0000 The Babel routing protocol (babel) WG in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-06-14. Babel routing protocol (babel) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Donald Eastlake Russ White Assigned Area Director: Alia Atlas Routing Area Directors: Alia Atlas Alvaro Retana Deborah Brungard Mailing list: Address: babel@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/babel Archive: https://mailarchive.ietf.org/arch/browse/babel/ Charter: https://datatracker.ietf.org/doc/charter-ietf-babel/ Babel is a loop-avoiding, distance vector routing protocol with good provisions for dynamically computed link metrics. It is robust even in the presence of link metric oscillations and the failure of transitivity. The core of the Babel protocol and security extensions are described in Experimental Independent Stream RFCs 6126, 7557, and 7298. These RFCs are the basis of three independent, open source implementations. There is some production deployment of these implementations, notably in hybrid networks (networks that include classical, wired parts with meshy radio bits) and in global overlay networks (networks built out of large numbers of tunnels spanning continents). The Working Group will focus on moving the Babel protocol to IETF Proposed Standard with IETF review. This includes clarifying RFC 6126 and integrating RFC 7557 and feedback provided by independent implementations, and resolving comments. It is not a requirement that the Babel protocol produced is backwards compatible with RFC 6126. It is a requirement that Babel support at least one profile that is auto-configuring. Other documents that are relevant to the above work can also be produced. Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security. Link metric measurement or link metric calculation procedures significantly more complex that those currently in Babel are out of scope. Work Items: - Produce a revision of RFC 6126 suitable for publication as a Proposed Standard -- incorporate in the revision developments since RFC 6126 -- resolve technical issues found -- include in the base specification the extensibility work in RFC 7557 -- support auto-configuration -- consider any important changes based on experience with Babel to date. - Address security needs for BABEL. This may include using the techniques in RFC 7298, or other alternatives. Security may be included in the base spec or the base spec may normatively reference a separate Proposed Standard specification. This is required as part of moving Babel to Proposed Standard. - Address manageability of Babel by producing an informational model for use by other network management such as the Broadband Forum TR-069, and a YANG data module based on that information model. The former supports the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) as is done today. The latter YANG model supports management of home gateway routers and is consistent with the ongoing effort to use YANG data modules in the Routing Area. This work is required as part of moving Babel to Proposed Standard. - As the Proposed Standard version of Babel is completed, an Applicability Statement should be finalized to guide those potentially interested in deploying Babel. This Applicability Statement may include deployment advice and will be published as an RFC. - Coordinate with other Working Groups, such as the HOMENET WG for likely applicability, the RTGWG and V6OPS WG about Source-Specific Routing to support IPv6 multihoming, the PIM WG for discussion around multicast, and the MANET WG for considerations around wireless. - Liaise as necessary with the Broadband Forum to facilitate use of the Babel management Information Model for TR-069. - The Working Group should document its ongoing implementation experience with Babel, so that new WG participants can understand the state that is driving this work and the experience driving changes. This documentation may be on the Working Group's wiki, in an internet-draft that isn't expected to be published as an RFC, or a combination. - As a secondary focus, the Working Group may work on multicast aspects of Babel. This may include discussion of any potential issues for supporting Babel running with PIM-SM in an auto-configuration profile. It may include exploring Babel carrying separate metrics for multicast. It may include discussion and consultation with the PIM WG about Babel providing the ability to build multicast routing tables. With AD and WG agreement, once an approach is understood, then a milestone may be added for an associated document targeted as Proposed Standard. - As a secondary focus, the Working Group may work on documents defining source specific routing extensions for Babel as a way of handling IPv6 multihoming. Thus, the Working Group will produce a Proposed Standard Babel specification, including or paired with a suitable Proposed Standard specification covering the security mechanism(s) for BABEL. It will also produce a management information and data model for BABEL as a Proposed Standard RFC. An applicability statement will be produced as an Informational RFC. Milestones: Jul 2016 - WG adoption of Babel Applicability draft Jul 2016 - WG adoption of RFC6126bis Oct 2016 - WG adoption of Babel Management (Info Model & YANG Model) draft Jul 2017 - IESG Submission of RFC6126bis and potentially companion security mechanisms draft Jul 2017 - IESG Submission of Babel Management draft Aug 2017 - IESG Submission of Babel Applicability draft From nobody Tue Jun 7 10:58:39 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 CFECE12D836; Tue, 7 Jun 2016 10:58:17 -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: <20160607175817.13792.32999.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 10:58:17 -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, 07 Jun 2016 17:58:24 -0000 State changed to External review. ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-babel/ From nobody Tue Jun 7 10:58:51 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 A6CCC12D82A; Tue, 7 Jun 2016 10:58:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , "The IESG" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607175831.13736.73185.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 10:58:31 -0700 From: IETF Secretariat Archived-At: Subject: [babel] Telechat 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, 07 Jun 2016 17:58:37 -0000 Telechat date has been changed to 2016-06-16 from 2016-06-02 ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-babel/ From nobody Tue Jun 7 11:11: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 A27D212D814 for ; Tue, 7 Jun 2016 11:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_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 yqAmdC4_Tiz3 for ; Tue, 7 Jun 2016 11:11:30 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 5C02712D5A2 for ; Tue, 7 Jun 2016 11:11:30 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id s187so10429833itd.0 for ; Tue, 07 Jun 2016 11:11:30 -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=ODeP7AOPOrPIDiHDBwcGdN0W09l1qAo+DkqDgOqFZAA=; b=p9a2J+SjIHr5Clz3It2YNV8gSurKZvkWZU/s3XTu3ma+kN58qe5+8MNaO6cNnvgU/6 P9ZckbzVZmWX0eDcjJgMu6n5ILylXpFHNZ/mrtzK8/0avyqjrwBp2mG+vYUpGCd4PyBt tx0sOLdpqDKasKSHnPD9UnPmfBckqFwrfB9an4KtoBpTYCD+CvmR4Hv7Gy6j82VIQUbQ QNtb14852EC7mVwV9wxiOK3doSqWQJdWm9cVhQ+eZG0awKsm3V0BIzxLyvHdLT7RShUN 0Bl7m1IrhVnnakPK//HpTRRMG4NA/UrmuTPKNRIdsNvzfyLzcL5Nb+usOFZXJl7WwONb j74w== 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=ODeP7AOPOrPIDiHDBwcGdN0W09l1qAo+DkqDgOqFZAA=; b=l6QJNJ8SY3hc08Hfooi6OswnqVTxmdcygBgCQluj12CBJCW/aWPqIVbb55QzV6ykp7 QlpfvEOCT7NBac19kSVcl7fxZPBO/4sav+pAU1ZogN360/kPChCVFL/5+HC9cfSrSq/t NJuQ+CrbyialCqb7Wm59/VxdnI083SxN9EY/ZuJcMn/F4YZt6LsEgQX9UCrAO/gSowD+ T87CL4wGnCt8Bo9bqeA4l7RvVSZkhj7KXBGIX2qncDRXGAg6FbDtnVnheLqDoXRGHAVx 8JL+YMMW6nljoZh0Ixsood5+SKu2mnegedeTJ581t5l1K2ZeQSFbCRcdFqiwJFUYM+Al R61g== X-Gm-Message-State: ALyK8tLwlcUC8TjdW3OFkUpyw/ja9WiaiLDdcYcNEd+I2I1c3mIVlB6ATwd040JLlYXszmi/IzLLudWHIVibCA== X-Received: by 10.107.39.149 with SMTP id n143mr1839089ion.50.1465323089432; Tue, 07 Jun 2016 11:11:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.28.81 with HTTP; Tue, 7 Jun 2016 11:10:50 -0700 (PDT) From: Tony Przygienda Date: Tue, 7 Jun 2016 11:10:50 -0700 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=001a1140271a3a29790534b41e0f Archived-At: Subject: [babel] Never thought I'd live to see the day ... 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, 07 Jun 2016 18:11:31 -0000 --001a1140271a3a29790534b41e0f Content-Type: text/plain; charset=UTF-8 The discussion on running routing over lightbulbs left me fairly breathless. I never thought I'd live to see the day ... And 9$ for a board, o tempura [auto-corrected ;-)] , o mores ... --- tony --001a1140271a3a29790534b41e0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The discussion on running routing over lightbulbs left me = fairly breathless. I never thought I'd live to see the day ...=C2=A0
And 9$ for a board, o tempura [auto-corrected ;-)] , o mor= es ...=C2=A0

--- tony

=

--001a1140271a3a29790534b41e0f-- From nobody Tue Jun 7 11:42: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 F41D712D83A for ; Tue, 7 Jun 2016 11:42:27 -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 W6zWR6rKKmX3 for ; Tue, 7 Jun 2016 11:42:25 -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 7149A12D853 for ; Tue, 7 Jun 2016 11:42:18 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id e72so291212071oib.1 for ; Tue, 07 Jun 2016 11:42: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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vMwUxEG0uK5gJ2iIRd/6nlDxRSlBSJAwnjmsB/b7IDU=; b=naoJ/fxpGiwzM5icsSEpGGTussBoQddtVQhEChqC8dnTA3KYO0VQk9fm5ZjJCewR2P gDPPiINx63YmxbyTKMLmbbNUVKZ59JTD/YfeECXBWIM07cPzHheEfYKjr7c4Y4Vx6gd3 7m2kI/a74RcZiAMfRXzptalRbyKMAT2maXPEXWLREi3xwVL09AI5nnueINbt3GK0EcqT UHQ8CXY717ZO+dISJv9jCllYaPZ3GRHeYkHes741PsjJgmEnis+3qkG0XmimrOlSGXQH 1tYZg+D2SFnIIZxDQwLqKtaFnXkF8h9DfFwpBjn32gOK+E7cDoW1MELktVjp8YKqy/zg 6e7A== 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:content-transfer-encoding; bh=vMwUxEG0uK5gJ2iIRd/6nlDxRSlBSJAwnjmsB/b7IDU=; b=P5ijuSX5pnFQUYvSXqMFcy0Y/rwXHac5etW2lybIL+XZZA0Riqu50g++44AZ1L2EQC HXJHkDUkFR5Uddil5bcyeE0a9hc3xq20c5DEvKAURjB+GYkKbnYWQhGfggMXm1+ewk6Q KPVaJHIzGgAfuZGxaQD4tinBLh1lCFDHw1m8aZA9j5HBI1ge6YTsX2uFZJx4dZ6NkSEB IlmVoStGqmQbYh7WNDEyQPBytxclBFq8bPPv+sqn+l3IbcSlEjQWdhwa4pUdVnUIjyqe m8Hc39p9UaEXRu55D14mvZ/pq55lMjeGiV11tunbgXH46mUZGj/HP9ljqk/K93Qmv4GX OYHA== X-Gm-Message-State: ALyK8tJ7t/MLGLEUBq2G5vy7CGGZWZRUsjK2dOUsg1r//KiTfEvZ6ocP1n+G6gkr5UFLMJYN5UA17nyJ0Oyb5w== X-Received: by 10.157.34.14 with SMTP id o14mr634381ota.63.1465324937788; Tue, 07 Jun 2016 11:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Tue, 7 Jun 2016 11:42:16 -0700 (PDT) In-Reply-To: References: From: Dave Taht Date: Tue, 7 Jun 2016 11:42:16 -0700 Message-ID: To: Tony Przygienda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Babel at IETF Subject: Re: [babel] Never thought I'd live to see the day ... 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, 07 Jun 2016 18:42:28 -0000 On Tue, Jun 7, 2016 at 11:10 AM, Tony Przygienda wrot= e: > The discussion on running routing over lightbulbs left me fairly breathle= ss. > I never thought I'd live to see the day ... I thought I'd live to see the day. routing is trivial with various technologies. Even required, in the case of multiple meshy radio systems. There's also "LiFi" and related IP over LED technologies emerging. How about bongos? http://web.archive.org/web/20130126160401/http://eagle.auc.ca/~dreid/ ... The question is no longer about what devices can route, but what devices sh= ould. the act of routing itself is trivial compared to the problems of access to the devices themselves. Most of my internal routers, for example, do not have a public ipv6 address, just fe80s. My canonical example as to why you might not want to also grant full access to lightbulbs from the internet, at the moment is here: https://mjg59.dreamwidth.org/40397.html (and in addition to the security flaws exposed in that article, the gateway box DOES get an ipv6 address, and takes telnet over port 22 to the well known password. I got a couple merely because the flaws were so well documented that I figured I could make them do some nifty things outside of the box, but so far don't have a compiler working) They make great christmas gifts! For people you don't like very much! http://www.amazon.com/iSuper-iRainbow001-Lighting-Automation-Android/dp/B00= GTCF436?ie=3DUTF8&keywords=3Dirainbow&qid=3D1465324580&ref_=3Dsr_1_1&sr=3D8= -1 > > And 9$ for a board, o tempura [auto-corrected ;-)] , o mores ... That's *this year*. Project anything on a cost/capability curve forward a few years... > > --- tony > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Tue Jun 7 16:42: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 271D612D8EC for ; Tue, 7 Jun 2016 16:41:53 -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 aie9I5Nxcia6 for ; Tue, 7 Jun 2016 16:41:49 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 5266A12D8E7 for ; Tue, 7 Jun 2016 16:41:48 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m62so3354270iof.0 for ; Tue, 07 Jun 2016 16:41:48 -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=kRk3xtUhdrFgi96sPtKWEe8zI5eLBfB8wL8Weuv2da0=; b=JN0VaDaRqIL8JMCxudiKddFhbEWhP2FsRPc7thU+ry+u+b7my+Dv8aITThjTM5F6Bs wv0EjCAYWnHVm91LJFmnLP1RyZDpujZbetrNYiHUCe5yRi23OtQC+avb0xiGCqpswohW 3G5zBsLWzSto4jvbGZcWPePmXflVZVeUBa3VaxeyJybWGRl5lENHFyfuP/++kmverkag sj+HpK8ggC0MOkmjOtXbkF9APqiZI9DLlr8rF5Gvjk8PveWT7krqQnebPP/pH2EhnKJ8 P1QsrEvLM0lBAmng5jxfNxJ/Cu88gnUatg954IZg8lybVQLn/+Twf1PKfMvY4GR7aP0J CAAA== 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=kRk3xtUhdrFgi96sPtKWEe8zI5eLBfB8wL8Weuv2da0=; b=VdgKBH0hn3oKSLFoJxM0oCIX2PXjbq0KMFKEJ0PW/eidmJX/jdRszdRI2h3FCyKoU6 JqQNJ5CHUwIufGYU6hCW8OnLkYPgqUYPUHzReYJ1YI1PJdzE6OZtzynDZlm/waVxw2hn Im1e7aM1mWWyiMQHa3yVY3DDw2iNotPNeWAZEuErcvGLyVRsO8/ZRflEN4kbf632D6qQ GEmhnkLuhk4D0kQ2FwPj963U/ovMOFVIMlByH+jkQtgOBV2/HmHAFhy2fdZl/kTTkSmM Biw7mPe8zxn9+KSNQ9QahoZwk+tSoc7Dq6VaMPV50H3nlhjrtNXiorhfY722aAgDnPux FJJQ== X-Gm-Message-State: ALyK8tI7Vxaq1JuI2U/jYw+4ijgE8hFBANfQhd6a/AsY7LYqNKYi9EmyRfB0XIE+/h77gXM0I26nl/XPI0JK8w== X-Received: by 10.107.27.18 with SMTP id b18mr3562232iob.163.1465342907548; Tue, 07 Jun 2016 16:41:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.28.81 with HTTP; Tue, 7 Jun 2016 16:41:08 -0700 (PDT) In-Reply-To: References: From: Tony Przygienda Date: Tue, 7 Jun 2016 16:41:08 -0700 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=001a1140a2a07a8e370534b8bb7c Archived-At: Cc: Babel at IETF Subject: Re: [babel] Never thought I'd live to see the day ... 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, 07 Jun 2016 23:41:53 -0000 --001a1140a2a07a8e370534b8bb7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Writing _a_ routing protocol and switching it on is trivial ... Getting routing done correctly on a larger scale (i.e. more than a couple light-bulbs together) is a really interesting problem that with lots of effort achieves a stable local optimum initially for short times, these days for reasonably long times ... I look forward to the first on/off/on/off storm of my lightbulbs on IP routing loop ;-) The Industrial BUS in my house is almost indestructible in terms of looping multiple lines but by some smart misconfiguration I managed that couple times in last 10 years or so. The effects were mesmerizing but the rest of my family completely and utterly failed to appreciate the effect ... Speaking of which, I'm skeptical we'll have e'thing running iP inside the home (unless it's some very, very simplified version) for couple reasons albeit those price-points are shocking ... Most problematic is power consumption and galvanic interface decoupling which tends to be expensiv'ish. as always, the future, being the future, is hard to predict ... -- tony On Tue, Jun 7, 2016 at 11:42 AM, Dave Taht wrote: > On Tue, Jun 7, 2016 at 11:10 AM, Tony Przygienda > wrote: > > The discussion on running routing over lightbulbs left me fairly > breathless. > > I never thought I'd live to see the day ... > > I thought I'd live to see the day. > > routing is trivial with various technologies. Even required, in the > case of multiple meshy radio systems. There's also "LiFi" and related > IP over LED technologies emerging. > > How about bongos? > http://web.archive.org/web/20130126160401/http://eagle.auc.ca/~dreid/ > > ... > > The question is no longer about what devices can route, but what devices > should. > > the act of routing itself is trivial compared to the problems of > access to the devices themselves. Most of my internal routers, for > example, do not have a public ipv6 address, just fe80s. > > My canonical example as to why you might not want to also grant full > access to lightbulbs from the internet, at the moment is here: > > https://mjg59.dreamwidth.org/40397.html > > (and in addition to the security flaws exposed in that article, the > gateway box DOES get an ipv6 address, and takes telnet over port 22 to > the well known password. I got a couple merely because the flaws were > so well documented that I figured I could make them do some nifty > things outside of the box, but so far don't have a compiler working) > > They make great christmas gifts! For people you don't like very much! > > > http://www.amazon.com/iSuper-iRainbow001-Lighting-Automation-Android/dp/B= 00GTCF436?ie=3DUTF8&keywords=3Dirainbow&qid=3D1465324580&ref_=3Dsr_1_1&sr= =3D8-1 > > > > > And 9$ for a board, o tempura [auto-corrected ;-)] , o mores ... > > That's *this year*. Project anything on a cost/capability curve > forward a few years... > > > > > --- tony > > > > > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > > > > > -- > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a1140a2a07a8e370534b8bb7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Writing _a_ routing protocol and switching it on is trivia= l ...=C2=A0

Getting routing done correctly on a larger s= cale (i.e. more than a couple light-bulbs together) is a really interesting= problem that with lots of effort achieves a stable local optimum initially= for short times, these days for reasonably long times ...=C2=A0
=
I look forward to the first on/off/on/off storm of my lightb= ulbs on IP routing loop ;-) =C2=A0The Industrial BUS in my house is almost = indestructible in terms of looping multiple lines but by some smart misconf= iguration I managed that couple times in last 10 years or so. The effects w= ere mesmerizing =C2=A0but the rest of my family completely and utterly fail= ed to appreciate the effect ...=C2=A0

Speaking of = which, I'm skeptical we'll have e'thing running iP inside the h= ome (unless it's some very, very simplified version) for couple reasons= albeit those price-points are shocking ... Most problematic is power consu= mption and galvanic interface decoupling which tends to be expensiv'ish= .=C2=A0

as always, =C2=A0the future, being the fut= ure, is hard to predict ...=C2=A0

-- tony=C2=A0

On Tue, = Jun 7, 2016 at 11:42 AM, Dave Taht <dave.taht@gmail.com> w= rote:
On Tue, Jun 7, 201= 6 at 11:10 AM, Tony Przygienda <t= onysietf@gmail.com> wrote:
> The discussion on running routing over lightbulbs left me fairly breat= hless.
> I never thought I'd live to see the day ...

I thought I'd live to see the day.

routing is trivial with various technologies. Even required, in the
case of multiple meshy radio systems. There's also "LiFi" and= related
IP over LED technologies emerging.

How about bongos?
http://web.archive.org/web/2013= 0126160401/http://eagle.auc.ca/~dreid/

...

The question is no longer about what devices can route, but what devices sh= ould.

the act of routing itself is trivial compared to the problems of
access to the devices themselves. Most of my internal routers, for
example, do not have a public ipv6 address, just fe80s.

My canonical example as to why you might not want to also grant full
access to lightbulbs from the internet, at the moment is here:

https://mjg59.dreamwidth.org/40397.html

(and in addition to the security flaws exposed in that article, the
gateway box DOES get an ipv6 address, and takes telnet over port 22 to
the well known password. I got a couple merely because the flaws were
so well documented that I figured I could make them do some nifty
things outside of the box, but so far don't have a compiler working)
They make great christmas gifts! For people you don't like very much!
http://= www.amazon.com/iSuper-iRainbow001-Lighting-Automation-Android/dp/B00GTCF436= ?ie=3DUTF8&keywords=3Dirainbow&qid=3D1465324580&ref_=3Dsr_1_1&a= mp;sr=3D8-1

>
> And 9$ for a board, o tempura [auto-corrected ;-)] , o mores ...

That's *this year*. Project anything on a cost/capability curve<= br> forward a few years...

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



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



--
We=E2=80=99ve heard that a million monkeys at a million k= eyboards could produce the complete works of Shakespeare; now, thanks to th= e Internet, we know that is not true.
=E2=80=94Robert Wilensky
--001a1140a2a07a8e370534b8bb7c-- From nobody Thu Jun 9 08:55: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 0992B12D7DE for ; Thu, 9 Jun 2016 08:55:10 -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 JA5b4rf8ouzq for ; Thu, 9 Jun 2016 08:55: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 A61FC12D84C for ; Thu, 9 Jun 2016 08:55:08 -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 u59Ft7KE011025; Thu, 9 Jun 2016 17:55:07 +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 0234861F9D; Thu, 9 Jun 2016 17:55:07 +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 VKx8DgHFh1Vf; Thu, 9 Jun 2016 17:55:05 +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 DE53261FA1; Thu, 9 Jun 2016 17:55:04 +0200 (CEST) Date: Thu, 09 Jun 2016 17:55:04 +0200 Message-ID: <871t46tl0n.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: babel-users@lists.alioth.debian.org 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, 09 Jun 2016 17:55:07 +0200 (CEST) X-Miltered: at korolev with ID 5759915B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5759915B.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 : 5759915B.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: [babel] Redefining the encoding of source-specific updates 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, 09 Jun 2016 15:55:10 -0000 Dear all, Matthieu and I are considering changing the encoding of source-specific updates in an incompatible manner. We haven't decided anything yet, here's a summary of our thinking. The current encoding of source-specific updates is described in https://tools.ietf.org/html/draft-boutier-babel-source-specific-01 In short, a source-specific update is carried by a new TLV type, which is silently ignored by non-source-specific implementations. There are two other new TLV types, for requests for source-specific routes. Note that source-specific updates cannot be encoded as an ordinary update with a sub-TLV for the source, since Babel lacks a mandatory bit: the sub-TLV would be discarded by non-source-specific routers, and the update would be mis-interpreted, leading to routing pathologies. Now Babel uses a single Update TLV for both IPv4 and IPv6; IPv4 is distinguished from IPv6 by the AE, which is a one-octet field with values 1 for IPv4 and 2 for IPv6. See Section 4.1.3 of RFC 6126. Unknown TLVs are silently discarded according to RFC 6126 (although Matthieu has noted a bug in the implementation with this). The idea would be to encode source-specific updates using the existing Update TLV, with two new AE values for v4 source-specific and v6 source-specific. This avoids the need for three new TLVs, and significantly simplifies the packet parser. There are some minor complications; the structure of the Update TLV changes, but only for the new AEs (so compatibility is preserved). Additionally, there are some complications with address compression (do we organise a leak of information between different AEs, or do we make compression completely independent? the latter is simpler and cleaner, so I tend to favour it, while the former gives slightly better compression). Opinions? -- Juliusz From nobody Thu Jun 9 10:30: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 AAC6B12D796 for ; Thu, 9 Jun 2016 10:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 jcPXXXDGYQNt for ; Thu, 9 Jun 2016 10:30:13 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7FE12D8D9 for ; Thu, 9 Jun 2016 10:30:02 -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 56E14E9D05F13196; Thu, 9 Jun 2016 20:29:46 +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: <871t46tl0n.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 9 Jun 2016 20:29:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <56561E16-A803-45E7-9FF8-864B5A269181@iki.fi> References: <871t46tl0n.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3124) Archived-At: Cc: babel-users@lists.alioth.debian.org, babel@ietf.org Subject: Re: [babel] Redefining the encoding of source-specific updates 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, 09 Jun 2016 17:30:15 -0000 On 9.6.2016, at 18.55, Juliusz Chroboczek = wrote: > Matthieu and I are considering changing the encoding of = source-specific > updates in an incompatible manner. We haven't decided anything yet, > here's a summary of our thinking. >=20 > The current encoding of source-specific updates is described in >=20 > https://tools.ietf.org/html/draft-boutier-babel-source-specific-01 >=20 > In short, a source-specific update is carried by a new TLV type, which = is > silently ignored by non-source-specific implementations. There are = two > other new TLV types, for requests for source-specific routes. Disclaimer: You know I am not big fan of the current encoding :) > Note that source-specific updates cannot be encoded as an ordinary = update > with a sub-TLV for the source, since Babel lacks a mandatory bit: the > sub-TLV would be discarded by non-source-specific routers, and the = update > would be mis-interpreted, leading to routing pathologies. >=20 > Now Babel uses a single Update TLV for both IPv4 and IPv6; IPv4 is > distinguished from IPv6 by the AE, which is a one-octet field with = values > 1 for IPv4 and 2 for IPv6. See Section 4.1.3 of RFC 6126. Unknown = TLVs > are silently discarded according to RFC 6126 (although Matthieu has = noted > a bug in the implementation with this). >=20 > The idea would be to encode source-specific updates using the existing > Update TLV, with two new AE values for v4 source-specific and v6 > source-specific. This avoids the need for three new TLVs, and > significantly simplifies the packet parser. I like this. > There are some minor complications; the structure of the Update TLV > changes, but only for the new AEs (so compatibility is preserved). > Additionally, there are some complications with address compression = (do we > organise a leak of information between different AEs, or do we make > compression completely independent? the latter is simpler and = cleaner, so > I tend to favour it, while the former gives slightly better = compression). I prefer the latter as well. I suspect compression rates are not deal = breaker and defining leakage so that it works also in presence of future = AEs is bit iffy. e.g. can you do it only in AEs increasing order or..? = :-p (if you assume people implement AEs in definition order) Cheers, -Markus= From nobody Thu Jun 9 13:36: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 373AA12D9E4 for ; Thu, 9 Jun 2016 13:36:22 -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 X-PeRwZzY_dG for ; Thu, 9 Jun 2016 13:36:20 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 0F93012D9EA for ; Thu, 9 Jun 2016 13:36:20 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id e72so82219175oib.1 for ; Thu, 09 Jun 2016 13:36: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:content-transfer-encoding; bh=vINhewhKVvGLbrvkNyy5+aBafIca5LoC0AcPa6Js1Qg=; b=g75Zqom+EUdK4XLSk85DidgwpcpCfVQOYbd35q/c1565lv94PAgP1toGpXvh8La8MT lmTSnmFHBqVnHCq47rtL8UVm+z9zorxUxKwDqJdmeg+VQh6MDSqt9+oCSp1tiep+QrId hIsCXK/QzK+00o7+iyzywpojr8/QfLsOQZcSk4e1PZoR7D3mvRm+rAaaYuYCszNM+R3H 71SeqO0asCoTXuz+D/IFZhYR4J4B8i1GQQoqoyGYkl6Qw+lkrY/2qo3T75jnb8n0uAck PTHOfIjPbpVLFqzSVaV0ebnSI3afw02ipKB7Mf5epv2JPBqvf7iZTYaSivBezbQlrLex gpbg== 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:content-transfer-encoding; bh=vINhewhKVvGLbrvkNyy5+aBafIca5LoC0AcPa6Js1Qg=; b=l4tpExBh1BozU7EacDIuCkgyLO8/8Y8qKh6L3DfHIvQ1BgQ3tsaM3Uzj9vTQ0eH6s/ 8WQA16irh8oyixA2U1wW+bdEYPYy4Z/Ep6bqD7yCfEFFvwD/68ktcLGGPUjTFt4Wvd17 WGOBp/r9/ea0QpRaFMEqFq54mz2VbuubrhDDZsh3W3fJuPht732B6z+61MFKMEnXwyWx pYLeOJ8m7Ig1G1QLwq0vMACKNsnCwDkwAy4++JsMFbm60qEfksq3hSGZiUpCZkPvnUIT bftGiSqUaxn1xzPX1GsUXdvfgOS2Vzw+lCucNtch+7kannKpnp+cbJgSEFGbB77zJ1Hq VrOQ== X-Gm-Message-State: ALyK8tK4MbJ26K+2s1nugl9JggNVl12iB4GE3wU+xoRpy68NXAR6ZPYhW3oAGIlVuKYjBR35d2GoHaBPLgwF+g== X-Received: by 10.157.34.14 with SMTP id o14mr7638103ota.63.1465504579319; Thu, 09 Jun 2016 13:36:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.229.210 with HTTP; Thu, 9 Jun 2016 13:36:18 -0700 (PDT) In-Reply-To: <56561E16-A803-45E7-9FF8-864B5A269181@iki.fi> References: <871t46tl0n.wl-jch@pps.univ-paris-diderot.fr> <56561E16-A803-45E7-9FF8-864B5A269181@iki.fi> From: Dave Taht Date: Thu, 9 Jun 2016 13:36:18 -0700 Message-ID: To: Markus Stenberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "babel-users@lists.alioth.debian.org" , Babel at IETF , Juliusz Chroboczek Subject: Re: [babel] Redefining the encoding of source-specific updates 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, 09 Jun 2016 20:36:22 -0000 I am sufficiently lazy to ask (rather than try to calculate) what the difference in compression ratio is and if there are other changes in encoding that would make it better under various use cases. (I was impressed by the bmx7 encodings) If I have 3 source specific gateways, what happens? If I am using source specific to let me advertise clients deep in the network that have 3 SS/64s (or /128s) attached, what happens?[1] (Do I always have to announce all IPs a given device has or can they be propagated once, refreshed (perhaps based on their assigned lifetime), or retracted periodically, and merely update reachability info for that router_id) Say, you wanted to do SS to a small city, with 1000 SS exit nodes and a secondary meshy backbone, what happens? [1] These are my actual use cases for a deployed network that I am really loathe to make updates to. On Thu, Jun 9, 2016 at 10:29 AM, Markus Stenberg w= rote: > On 9.6.2016, at 18.55, Juliusz Chroboczek = wrote: >> Matthieu and I are considering changing the encoding of source-specific >> updates in an incompatible manner. We haven't decided anything yet, >> here's a summary of our thinking. >> >> The current encoding of source-specific updates is described in >> >> https://tools.ietf.org/html/draft-boutier-babel-source-specific-01 >> >> In short, a source-specific update is carried by a new TLV type, which i= s >> silently ignored by non-source-specific implementations. There are two >> other new TLV types, for requests for source-specific routes. > > Disclaimer: You know I am not big fan of the current encoding :) > >> Note that source-specific updates cannot be encoded as an ordinary updat= e >> with a sub-TLV for the source, since Babel lacks a mandatory bit: the >> sub-TLV would be discarded by non-source-specific routers, and the updat= e >> would be mis-interpreted, leading to routing pathologies. >> >> Now Babel uses a single Update TLV for both IPv4 and IPv6; IPv4 is >> distinguished from IPv6 by the AE, which is a one-octet field with value= s >> 1 for IPv4 and 2 for IPv6. See Section 4.1.3 of RFC 6126. Unknown TLVs >> are silently discarded according to RFC 6126 (although Matthieu has note= d >> a bug in the implementation with this). >> >> The idea would be to encode source-specific updates using the existing >> Update TLV, with two new AE values for v4 source-specific and v6 >> source-specific. This avoids the need for three new TLVs, and >> significantly simplifies the packet parser. > > I like this. > >> There are some minor complications; the structure of the Update TLV >> changes, but only for the new AEs (so compatibility is preserved). >> Additionally, there are some complications with address compression (do = we >> organise a leak of information between different AEs, or do we make >> compression completely independent? the latter is simpler and cleaner, = so >> I tend to favour it, while the former gives slightly better compression)= . > > I prefer the latter as well. I suspect compression rates are not deal bre= aker and defining leakage so that it works also in presence of future AEs i= s bit iffy. e.g. can you do it only in AEs increasing order or..? :-p (if y= ou assume people implement AEs in definition order) > > Cheers, > > -Markus > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Thu Jun 9 14:47: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 00F4D12D1CA for ; Thu, 9 Jun 2016 14:47: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 nhtKCoSHBEB8 for ; Thu, 9 Jun 2016 14:47:00 -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 D9B3212B00B for ; Thu, 9 Jun 2016 14:46:59 -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 u59Lkumb005180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jun 2016 23:46:56 +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 u59LkteG030247; Thu, 9 Jun 2016 23:46: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 C2CCB61FA1; Thu, 9 Jun 2016 23:46:55 +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 bL1yf6FsTm9z; Thu, 9 Jun 2016 23:46:54 +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 4FABA61F9D; Thu, 9 Jun 2016 23:46:53 +0200 (CEST) Date: Thu, 09 Jun 2016 23:46:52 +0200 Message-ID: <878tyeujar.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht In-Reply-To: References: <871t46tl0n.wl-jch@pps.univ-paris-diderot.fr> <56561E16-A803-45E7-9FF8-864B5A269181@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=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, 09 Jun 2016 23:46: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, 09 Jun 2016 23:46:56 +0200 (CEST) X-Miltered: at korolev with ID 5759E3D0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5759E3CF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5759E3D0.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5759E3CF.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 : 5759E3D0.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5759E3CF.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-users@lists.alioth.debian.org" , Babel at IETF Subject: Re: [babel] Redefining the encoding of source-specific updates 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, 09 Jun 2016 21:47:02 -0000 > I am sufficiently lazy to ask (rather than try to calculate) what the > difference in compression ratio is and if there are other changes in > encoding that would make it better under various use cases. It depends very much on the nature of the network. > (I was impressed by the bmx7 encodings) Yes, Alex has done a good job. However, he's using inter-packet state, which gives rise to a whole set of tradeoffs. In Babel, we only keep parser state within a single packet, and that's not likely to change. With the current encoding, only the destination address gets compressed, and source-specific contributes no compression state, which avoids confusing non-source-specific abwabel: So if you're announcing 2001:db8:1234:5678::/64 2001:db8:1234:5678:dead:beef:f00:ba4/128 2001:db8:1234:5678::/64 src 2001:db8:1234::/48 2001:db8:1234:5678::/64 src 2001:db8:5678::/48 ::/0 src 2001:db8:5678::/48 you only encode 2001:db8:1234:5678::/64 (compressed):dead:beef:f00:ba4/128 (compressed)::/64 src 2001:db8:5678::/48 (compressed)::/64 src 2001:db8:5678::/48 ::/0 src 2001:db8:5678::/48 Note how destination prefixes get compressed away, but there's no compression for the source prefixes. What Markus and I have in mind is an encoding in which there are separate compression states for non-specific and source-specific AEs. So the above will compress as 2001:db8:1234:5678::/64 (compressed):dead:beef:f00:ba4/128 2001:db8:1234:5678::/64 src 2001:db8:1234::/48 (compressed)::/64 src (compressed):5678::/48 ::/0 src (compressed)::/48 Note how both destination and source prefixes get compressed, but the compression state needs to be reestablished for the first source-specific update (2001:db8:1234:5678 is explicitly encoded twice, once for non-source-specific and once for source-specific). The alternative would be to have some unidirectional leaking between non-source-specific and source-specific, so as to get 2001:db8:1234:5678::/64 (compressed):dead:beef:f00:ba4/128 (compressed)::/64 src 2001:db8:1234::/48 (compressed)::/64 src (compressed):5678::/48 ::/0 src (compressed)::/48 This is likely to gain up to 8 octets for each non-default source-specific route, but at the cost of a much more complex implementation and specification, and bad compositionality with further extensions (TOS-specific is likely to happen). Note that if all source-specific routes are default routes, the gain is nil. -- Juliusz From nobody Tue Jun 14 23:31:29 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 DB83212B01C; Tue, 14 Jun 2016 23:31:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615063126.31805.9816.idtracker@ietfa.amsl.com> Date: Tue, 14 Jun 2016 23:31:26 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Suresh Krishnan's Yes on charter-ietf-babel-00-06: (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, 15 Jun 2016 06:31:27 -0000 Suresh Krishnan has entered the following ballot position for charter-ietf-babel-00-06: Yes 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: ---------------------------------------------------------------------- Thanks for addressing my comments from the previous version of the charter. It looks good now. As a minor nit, the charter has two bullet points that mention "As a secondary focus...". I suggest removing the phrase "As a secondary focus," from the second occurrence. From nobody Wed Jun 15 05:58:33 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 7B47112D5C9; Wed, 15 Jun 2016 05:58:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615125829.20236.95462.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 05:58:29 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-06: (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, 15 Jun 2016 12:58:29 -0000 Benoit Claise has entered the following ballot position for charter-ietf-babel-00-06: 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: ---------------------------------------------------------------------- 1. Editorial Justification: - TR69 is a management protocol, not "network management" - I tried to explain that data models are derived from the information model OLD: - Address manageability of Babel by producing an informational model for use by other network management such as the Broadband Forum TR-069, and a YANG data module based on that information model. The former supports the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) as is done today. The latter YANG model supports management of home gateway routers and is consistent with the ongoing effort to use YANG data modules in the Routing Area. This work is required as part of moving Babel to Proposed Standard. NEW: - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model to support management of home gateway routers is required as part of moving Babel to Proposed Standard. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. 2. I don't believe we need this text: Thus, the Working Group will produce a Proposed Standard Babel specification, including or paired with a suitable Proposed Standard specification covering the security mechanism(s) for BABEL. It will also produce a management information and data model for BABEL as a Proposed Standard RFC. An applicability statement will be produced as an Informational RFC. However, as discussed during the retreat, the deliverables should clearly mention the expected status: informational, proposed standard From nobody Wed Jun 15 13:46: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 6333912D9A4; Wed, 15 Jun 2016 13:46:50 -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 MKniXeMKlNgs; Wed, 15 Jun 2016 13:46:48 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 5769012D953; Wed, 15 Jun 2016 13:46:48 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id s186so35640031qkc.1; Wed, 15 Jun 2016 13:46:48 -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=C44Kl0czZCHbpmkAiTZANxf1yefZD7FXvzzZkMpNWfw=; b=XAShn+/Q6A6oFU9kbCZwox3fFW5fLcEblkOitOdqp+EFNg0HobyCpqY5p/Z9M1ADHB Rsmd58hIVBDNe8wsk/PsFZ53MC6J4eNYVKOELH6xJzztuw55Ksyma6ajZcJdJkOvlbB5 mOCNrozXdGlrFBwh51QgG5fjVmsby9NGpTdAiKPPXW6fdHhYMGocT1sopQphSc03lgAU qqE12Grtc8En8G5EO5MH/2Maf3oHQlRteGGL10/sfj7PasQKe76nxyAPXVLEGELX97B+ OUhBE15oDLVqiIETHvj/yQGEHugTTFejUijXoh6tcfF6A1BegrpLZrGpaTCaEFzsahEA ilAg== 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=C44Kl0czZCHbpmkAiTZANxf1yefZD7FXvzzZkMpNWfw=; b=kjE5L/N93s/AQXHV/nEYFeTA/fr028xC5zLDwuIycAk1CI7Ia2T06JzCmzj1bCkzev PSOB4Y5inP86UL32lv2Nm++SeTRsLPebK1ixImX3L75yINCY91kaTlTpPcWFqHArfM9X FhUWXXDKikQ+9p9R4myUzKW+ZnR8OEWPf6Fma1hWld8ZB7bXWx5lwJgPu2EkbidM7pGz OacKYXAXXXH5tJ3rpbTFHxhDaAbpuRl43i//SRPg3r1temjuCOAJVZQwVHlDemEe5i6z h5VR5g2wFmeGJ2ImzbY3fUHJbHQgHgtLL0MX4Q6EL8qq2n3RQyOTpcYunomjWrMxtlkT XiRw== X-Gm-Message-State: ALyK8tKPuXEaqdXqGxHzVf6G8o+qjyqvc4K7kSJ95LPhnR2fdc0HaWNMNqsLOmKG+wENwHb5me0UNv8tmr8vBA== X-Received: by 10.55.160.132 with SMTP id j126mr785067qke.108.1466023607465; Wed, 15 Jun 2016 13:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.81 with HTTP; Wed, 15 Jun 2016 13:46:46 -0700 (PDT) In-Reply-To: <20160615125829.20236.95462.idtracker@ietfa.amsl.com> References: <20160615125829.20236.95462.idtracker@ietfa.amsl.com> From: Alia Atlas Date: Wed, 15 Jun 2016 16:46:46 -0400 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a114fca4a5b01a50535573808 Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [babel] Benoit Claise's No Objection on charter-ietf-babel-00-06: (with COMMENT) 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, 15 Jun 2016 20:46:50 -0000 --001a114fca4a5b01a50535573808 Content-Type: text/plain; charset=UTF-8 Hi Benoit, Thanks for your suggested text. I've updated the charter ( https://datatracker.ietf.org/doc/charter-ietf-babel/ so we're at version 7) and milestones based on your suggestions as well as Alvaro's and Suresh's. Regards, Alia On Wed, Jun 15, 2016 at 8:58 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-babel-00-06: 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: > ---------------------------------------------------------------------- > > 1. Editorial > > Justification: > - TR69 is a management protocol, not "network management" > - I tried to explain that data models are derived from the information > model > > OLD: > - Address manageability of Babel by producing an informational model > for use by other network management such as the Broadband Forum > TR-069, and a YANG data module based on that information model. The > former supports the case where the Customer-Premise Equipment (CPE) > is managed by the Service Provider (SP) as is done today. The latter > YANG > model supports management of home gateway routers and is consistent > with the ongoing effort to use YANG data modules in the Routing Area. > This work is required as part of moving Babel to Proposed Standard. > > NEW: > - Address manageability of Babel by producing a Babel informational > model > to help provide guidance and derive the data models. To be consistent > with > the ongoing effort to use YANG data modules in the Routing Area, a Babel > > YANG data model to support management of home gateway routers is required > > as part of moving Babel to Proposed Standard. This information model is > useful as a common source of information for the case where the > Customer-Premise Equipment (CPE) is managed by the Service > Provider (SP) with the Broadband Forum TR-069 protocol and its associated > > data model. > > 2. > I don't believe we need this text: > Thus, the Working Group will produce a Proposed Standard Babel > specification, including or paired with a suitable Proposed Standard > specification covering the security mechanism(s) for BABEL. It will > also produce a management information and data model for BABEL as a > Proposed Standard RFC. An applicability statement will be produced as > an Informational RFC. > > However, as discussed during the retreat, the deliverables should clearly > mention > the expected status: informational, proposed standard > > > --001a114fca4a5b01a50535573808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

Thanks for your suggested te= xt.=C2=A0 I've updated the charter (https://datatracker.ietf.org/doc/charter-ietf= -babel/ so we're
at version 7) and milestones based on yo= ur suggestions as well as Alvaro's and Suresh's.

Regards,
Alia

On Wed, Jun 15, 2016 at 8:58 AM, Benoit Claise <b= claise@cisco.com> wrote:
Be= noit Claise has entered the following ballot position for
charter-ietf-babel-00-06: 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-ba= bel/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Editorial

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

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

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

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

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



--001a114fca4a5b01a50535573808-- From nobody Wed Jun 15 14:18:20 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 2F39112D96B; Wed, 15 Jun 2016 14:18:18 -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.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615211818.26205.66087.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 14:18:18 -0700 Archived-At: Cc: babel-chairs@ietf.org, babel@ietf.org Subject: [babel] Spencer Dawkins' Yes on charter-ietf-babel-00-07: (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, 15 Jun 2016 21:18:18 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-babel-00-07: Yes 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 a couple of suggestions, but this looks fine. We all know that applicability statements are standards-track, but perhaps it's worth spelling that out for people who haven't read RFC 2026 lately, since we don't produce many applicability statements. Perhaps "As the Proposed Standard version of Babel is completed, an Applicability Statement should be finalized to guide those potentially interested in deploying Babel. This Applicability Statement may include deployment advice and will be published as a standards-track RFC." I wasn't sure what you meant by "state" in "The Working Group should document its ongoing implementation experience with Babel, so that new WG participants can understand the state that is driving this work and the experience driving changes." I can guess, but I was guessing. From nobody Wed Jun 15 14:33: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 99ACB12D614; Wed, 15 Jun 2016 14:33:50 -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 E59nniALVjNt; Wed, 15 Jun 2016 14:33:48 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d: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 8668512D176; Wed, 15 Jun 2016 14:33:48 -0700 (PDT) Received: by mail-qg0-x22a.google.com with SMTP id v76so19453399qgv.3; Wed, 15 Jun 2016 14:33:48 -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=ejTIwF/MkJm4h3kJln+/zafEKIJgxsMwzvjb+aEQySA=; b=aP6gQJVRV/Td0SW700MJs4T+CouCR4jvx4Kpxff72TSyD/KCoQC3wGTyc/SXdYk6N/ nIIDwTlsDX7aIhf8xPVj4Zh2W+pEoMzrepQjyk3vDPV/fplACIPhTgghwbtHRODAi71x Y+BnAlhn/HFrS3HYMUHRyVJmzYP4SXrDTwUzZQGRnRz4k0IRhiBMDpktgzbWgX7H2Tzn S/riPBJbcwUqQUBWIu+R5QIO/MJXxkV1EDk6t58n6QsaWJrK2lUQwUNaIgujbJ+xj2T6 o3JnmBGYuk/4Jpjbbik8ftKwIam7WdbW1W0VVMks6b0O4U4kDSnFYxUVNNdXuOWradOq EM0g== 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=ejTIwF/MkJm4h3kJln+/zafEKIJgxsMwzvjb+aEQySA=; b=MxbDvUmjsKvcIHnypogYovt66vnBeZUDBnMCKtRS6KkYEBntdO7HAawRb01u+SgT1Q od8G8zChBkjH6pLPoqcmEGOe/KTTeWY4ibHfvRdj1S4QhyWr98v1PSwhvJA3m9R9EyVq nZzpumfZa3eXK0RnC5IKuggKOhoHE2uxLOvRe+HhsBt7STK/WAw9AlB29o5pZ7ZZ8HFP DlcX+cVWmOHN/w4X32QZByAYgVeh0HCjMc/s8KS8O3ipPynJEzv94IcHeSg7CSwgiL56 RlldD8DCtwGvUk3bXN54Ou1nq4Z3q7+/Bdi/Sgi8mavOwtXc/V/k8SyQaCSpaG4uMWpI d0pA== X-Gm-Message-State: ALyK8tLqxb25qpnWF8L/LbVKPefAFnHsFQUsihk/vqNoFe9chUBRL5ghvrRp41JhO1aTzuHu4NWmQ1Ieeu3A+Q== X-Received: by 10.140.105.71 with SMTP id b65mr971117qgf.66.1466026427698; Wed, 15 Jun 2016 14:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.81 with HTTP; Wed, 15 Jun 2016 14:33:47 -0700 (PDT) In-Reply-To: <20160615211818.26205.66087.idtracker@ietfa.amsl.com> References: <20160615211818.26205.66087.idtracker@ietfa.amsl.com> From: Alia Atlas Date: Wed, 15 Jun 2016 17:33:47 -0400 Message-ID: To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a11393e9074558a053557e0f9 Archived-At: Cc: babel-chairs@ietf.org, The IESG , Babel at IETF Subject: Re: [babel] Spencer Dawkins' Yes on charter-ietf-babel-00-07: (with COMMENT) 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, 15 Jun 2016 21:33:50 -0000 --001a11393e9074558a053557e0f9 Content-Type: text/plain; charset=UTF-8 Hi Spencer, On Wed, Jun 15, 2016 at 5:18 PM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > charter-ietf-babel-00-07: Yes > > 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 a couple of suggestions, but this looks fine. > > We all know that applicability statements are standards-track, but > perhaps it's worth spelling that out for people who haven't read RFC 2026 > lately, since we don't produce many applicability statements. Perhaps "As > the Proposed Standard version of Babel is completed, an Applicability > Statement should be finalized to guide those potentially interested in > deploying Babel. This Applicability Statement may include deployment > advice and will be published as a standards-track RFC." > Thanks - I captured the intended state in the milestones, in response to Benoit's suggestion. I wasn't sure what you meant by "state" in "The Working Group should > document its ongoing implementation experience with Babel, so that new WG > participants can understand the state that is driving this work and the > experience driving changes." I can guess, but I was guessing. > Hmm, I don't have a better term for it - but basically the experience and current state of implementation and deployment. Regards, Alia > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --001a11393e9074558a053557e0f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Spencer,

On Wed, Jun 15, 2016 at 5:18 PM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
Spencer Dawkins has entered the following ballot position for
charter-ietf-babel-00-07: Yes

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-ba= bel/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I had a couple of suggestions, but this looks fine.

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

Thanks - I captured the intended state in the milesto= nes, in response to Benoit's
suggestion.
=C2=A0

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

Hmm, I don't have a better term for it - bu= t basically the experience and current
state of implementation an= d deployment.

Regards,
Alia=C2=A0
<= div>
=C2=A0

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

--001a11393e9074558a053557e0f9-- From nobody Wed Jun 15 14:52:19 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 20B1A12DC0D; Wed, 15 Jun 2016 14:52:18 -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.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160615215218.26165.73152.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2016 14:52:18 -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: Wed, 15 Jun 2016 21:52:18 -0000 State changed to IESG review. ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-babel/ From nobody Fri Jun 17 09:19:29 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 9535812D845; Fri, 17 Jun 2016 09:19:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160617161927.9755.7110.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 09:19:27 -0700 Archived-At: Cc: babel-chairs@ietf.org, The IESG , babel@ietf.org Subject: [babel] WG Action: Formed Babel routing protocol (babel) 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: Fri, 17 Jun 2016 16:19:27 -0000 A new IETF WG has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Babel routing protocol (babel) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Donald Eastlake Russ White Assigned Area Director: Alia Atlas Routing Area Directors: Alia Atlas Alvaro Retana Deborah Brungard Mailing list: Address: babel@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/babel Archive: https://mailarchive.ietf.org/arch/browse/babel/ Charter: https://datatracker.ietf.org/doc/charter-ietf-babel/ Babel is a loop-avoiding, distance vector routing protocol with good provisions for dynamically computed link metrics. The core of the Babel protocol and security extensions are described in Experimental Independent Stream RFCs 6126, 7557, and 7298. These RFCs are the basis of three independent, open source implementations. There is some production deployment of these implementations, notably in hybrid networks (networks that include classical, wired parts with meshy radio bits) and in global overlay networks (networks built out of large numbers of tunnels spanning continents). The Working Group will focus on moving the Babel protocol to IETF Proposed Standard with IETF review. This includes clarifying RFC 6126 and integrating RFC 7557 and feedback provided by independent implementations, and resolving comments. It is not a requirement that the Babel protocol produced is backwards compatible with RFC 6126. It is a requirement that Babel support at least one profile that is auto-configuring. Other documents that are relevant to the above work can also be produced. Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security. Link metric measurement or link metric calculation procedures significantly more complex that those currently in Babel are out of scope. The Babel WG should coordinate with other Working Groups, such as the HOMENET WG for likely applicability, the RTGWG and V6OPS WG about Source-Specific Routing to support IPv6 multihoming, the PIM WG for discussion around multicast, and the MANET WG for considerations around wireless. The Babel WG should liaise as necessary with the Broadband Forum to facilitate use of the Babel Information Model for TR-069. Work Items: - Produce a revision of RFC 6126 suitable for publication as a Proposed Standard -- incorporate in the revision developments since RFC 6126 -- resolve technical issues found -- include in the base specification the extensibility work in RFC 7557 -- support auto-configuration -- consider any important changes based on experience with Babel to date. - Address security needs for BABEL. This may include using the techniques in RFC 7298, or other alternatives. Security may be included in the base spec or the base spec may normatively reference a separate Proposed Standard specification. This is required as part of moving Babel to Proposed Standard. - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model to support management of home gateway routers is required as part of moving Babel to Proposed Standard. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. - 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. - The Working Group should document its ongoing implementation experience with Babel, so that new WG participants can understand the state that is driving this work and the experience driving changes. This documentation may be on the Working Group's wiki, in an internet-draft that isn't expected to be published as an RFC, or a combination. - As a non-primary focus, the Working Group may work on multicast aspects of Babel. This may include discussion of any potential issues for supporting Babel running with PIM-SM in an auto-configuration profile. It may include exploring Babel carrying separate metrics for multicast. It may include discussion and consultation with the PIM WG about Babel providing the ability to build multicast routing tables. With AD and WG agreement, once an approach is understood, then a milestone may be added for an associated document targeted as Proposed Standard. - As a non-primary focus, the Working Group may work on documents defining source specific routing extensions for Babel as a way of handling IPv6 multihoming. Milestones: Jul 2016 - WG adoption of Babel Applicability draft Jul 2016 - WG adoption of RFC6126bis Oct 2016 - WG adoption of Babel Management (Info Model & YANG Model) draft Jul 2017 - IESG Submission of RFC6126bis and potentially companion security mechanisms draft (Proposed Standard) Jul 2017 - IESG Submission of Babel Management draft (Proposed Standard) Aug 2017 - IESG Submission of Babel Applicability draft (Informational) From nobody Fri Jun 17 13:05: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 AAA7612D112 for ; Fri, 17 Jun 2016 13:04:59 -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 UG4gCioBCxva for ; Fri, 17 Jun 2016 13:04:58 -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 D2F4312DA61 for ; Fri, 17 Jun 2016 13:04:57 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id u201so132663922oie.0 for ; Fri, 17 Jun 2016 13:04:57 -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=Mnz4FgpWx4NvC51O/QFXfLCBymSD2kg3Qci8nM8dRCA=; b=gwuVslQjbkK1bMbE+Ugc1nvQfEDCTqZQahEiVkqLObHt4/9eFsqxy4+jLRU8R0xSVJ wPRUfcm2SILOrpbT1t8+2juK4VaNKHYM0HVi210aVwLOUEJcj91l3os3tpTF8PnvtPKl z4xyfD8SNNo5M/KQe/+7/uEywAd8+JYWeuM92LcV6Hzup1dZgWk0zZ/u28vDAHbfErAL WCWvKAX/OWIfX1++R2nC+uPUEjimIkj7hh9Jdt9PFGa8Jfv77TYtPVc4azHYO/+nebad I8zX0YXp9Eynw1zLL5WV6TlhGZMEN47LmYJ+ahgoRXz+oey+nSIvi+KJZWu3onS8hzas QBFg== 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=Mnz4FgpWx4NvC51O/QFXfLCBymSD2kg3Qci8nM8dRCA=; b=kxkXMogDW6WV94/ANB90/TweSSHhhOIZq3+zONNeR0AMaKtjRh9HNbInJIoNuGXYV4 l6MN8rWIKdjijzVbQ6xW6Kpg7lYL+ua4TAUVfLUPkhg4E43NFyXrsFW58KddmN6JpcLu zBk7WJ1MuDZSk5HGGIAUN3BWfh4kkn6z69hRn/DzncJCMfsHd6oOktN/fzqG9Je8tXV5 vkF3bNR7f5uTnAegSBtuxbYG6Cp1smZakXwvmWYTm35HqPbjuxjaxgRu80D+B1kdbfm1 Gi4ofvS9shoEUFvB35OxpKzAKj8SA+CTT7IjH4Kkn7RIqmLAlit2ZPhIW4vvWmh81rYO ql/Q== X-Gm-Message-State: ALyK8tK6k0CF7A8Lf0WbbsMLZq6JMwPOtW3PoTz9XTpbcpCww3g9tmPyu0uXHpksn0ZZI3Nvo7TghO5xwfnjgA== X-Received: by 10.202.91.198 with SMTP id p189mr2516040oib.114.1466193896593; Fri, 17 Jun 2016 13:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.242 with HTTP; Fri, 17 Jun 2016 13:04:42 -0700 (PDT) From: Donald Eastlake Date: Fri, 17 Jun 2016 16:04:42 -0400 Message-ID: To: Babel at IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [babel] Babel WG meeting tentatively scheduled for IETF-96 in Berlin 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, 17 Jun 2016 20:05:00 -0000 Hi, A meeting of the BABEL WG has been tentatively scheduled for 16:20 to 18:20 Thursday afternoon at the upcoming IETF meeting in Berlin. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Sun Jun 19 04:18: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 9864212D0F5 for ; Sun, 19 Jun 2016 04:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 qYw-Fkn3KOOk for ; Sun, 19 Jun 2016 04:18: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 27EAC12B02B for ; Sun, 19 Jun 2016 04:18:01 -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 u5JBHxOS001194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Jun 2016 13:17:59 +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 u5JBHxpd014734; Sun, 19 Jun 2016 13:17: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 F2F8361FA1; Sun, 19 Jun 2016 13:17:58 +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 Ru3jYwBfTGIj; Sun, 19 Jun 2016 13:17:57 +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 504A861F9D; Sun, 19 Jun 2016 13:17:57 +0200 (CEST) Date: Sun, 19 Jun 2016 13:17:59 +0200 Message-ID: <87r3btpguw.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <20160617161927.9755.7110.idtracker@ietfa.amsl.com> References: <20160617161927.9755.7110.idtracker@ietfa.amsl.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]); Sun, 19 Jun 2016 13:17:59 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 19 Jun 2016 13:17:59 +0200 (CEST) X-Miltered: at korolev with ID 57667F67.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57667F67.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57667F67.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57667F67.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 : 57667F67.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57667F67.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-users@lists.alioth.debian.org Subject: Re: [babel] WG Action: Formed Babel routing protocol (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: Sun, 19 Jun 2016 11:18:04 -0000 The IESG says: > A new IETF WG has been formed in the Routing Area. > Charter: https://datatracker.ietf.org/doc/charter-ietf-babel/ Hourra! Many thanks to everyone who helped with making this happen. (Too many people to fit in the margin of this mail, so I'll just single out the fine-tuning work that Alia did in the final phases.) Pro memoria, IETF 96 is from 17 to 22 July in Berlin, Germany (from Warsaw, just follow the A2 highway westwards for 550km, or take the train at central station; from Paris, hop into the first night train at Gare de l'Est -- no need to suffer through airport security). The inscription fees are high, but there are very reasonable student rates, and Berlin is full of cheap hotels, many of them close to the Hilton. (And if you've never been to Berlin -- it's worth visiting.) I'll send a reminder to both lists just before the meeting, with pointers to the online participation URLs. Hope to see you all there, -- Juliusz From nobody Sun Jun 19 06:26: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 AB29612B030 for ; Sun, 19 Jun 2016 06:26: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 QhYdGlOIGH5j for ; Sun, 19 Jun 2016 06:26:17 -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 9139E12B057 for ; Sun, 19 Jun 2016 06:26: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 u5JDQFTI016056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Jun 2016 15:26: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 u5JDQEuC019475; Sun, 19 Jun 2016 15:26: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 8BDC361FA2; Sun, 19 Jun 2016 15:26: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 s5XBrC5LoXXx; Sun, 19 Jun 2016 15:26: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 3B86061F9D; Sun, 19 Jun 2016 15:26:13 +0200 (CEST) Date: Sun, 19 Jun 2016 15:26:15 +0200 Message-ID: <87d1ndpax4.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <87r3btpguw.wl-jch@pps.univ-paris-diderot.fr> References: <20160617161927.9755.7110.idtracker@ietfa.amsl.com> <87r3btpguw.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]); Sun, 19 Jun 2016 15:26:15 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 19 Jun 2016 15:26:15 +0200 (CEST) X-Miltered: at korolev with ID 57669D77.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 57669D76.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 57669D77.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 57669D76.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 : 57669D77.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 57669D76.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: babel-users@lists.alioth.debian.org Subject: Re: [babel] WG Action: Formed Babel routing protocol (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: Sun, 19 Jun 2016 13:26:18 -0000 > The inscription fees are high, but there are very reasonable student > rates, and Berlin is full of cheap hotels, many of them close to the > Hilton. People are telling me it's not at the Hilton. Apologies. I'm not saying where it is, please check the web pages rather than listening to me ;-) -- Juliusz From nobody Sun Jun 19 15:20: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 AE69012D758 for ; Sun, 19 Jun 2016 15:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ZZDxVTtmetyz for ; Sun, 19 Jun 2016 15:20:01 -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 946FC12D74F for ; Sun, 19 Jun 2016 15:20:00 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1466374799439880.7842602616371; Sun, 19 Jun 2016 15:19:59 -0700 (PDT) Date: Sun, 19 Jun 2016 23:19:59 +0100 From: Denis Ovsienko To: Message-ID: <1556abfc01f.b9c261e935402.5258754638272355649@ovsienko.info> In-Reply-To: <20160617161927.9755.7110.idtracker@ietfa.amsl.com> References: <20160617161927.9755.7110.idtracker@ietfa.amsl.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] WG Action: Formed Babel routing protocol (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: Sun, 19 Jun 2016 22:20:03 -0000 ---- On Fri, 17 Jun 2016 17:19:27 +0100 The IESG wrote ---- >A new IETF WG has been formed in the Routing Area. For additional >information, please contact the Area Directors or the WG Chairs. Hello list. It is very pleasing to see the working group formed, congratulations and thank you to everyone who has been spending their effort to make this happen! Are there any specific work items I could help with in the next couple weeks? -- Denis Ovsienko From nobody Fri Jun 24 09:02:42 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 8A03112DC64; Fri, 24 Jun 2016 09:00:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160041.10933.50993.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:41 -0700 Archived-At: Cc: babel@ietf.org, akatlas@gmail.com Subject: [babel] babel - Requested session has been scheduled for IETF 96 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: Fri, 24 Jun 2016 16:00:41 -0000 Dear Donald Eastlake, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. babel Session 1 (2:00:00) Thursday, Afternoon Session II 1620-1820 Room Name: Potsdam II size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: manet ospf homenet trill saag lpwan isis idr rtgwg 6man dnssd v6ops i2rs netmod netconf Second Priority: dnsop Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 18:10:12 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 B78B312D511 for ; Fri, 24 Jun 2016 18:10:10 -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 UDSSMAbnVSoo for ; Fri, 24 Jun 2016 18:10:09 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 61FDD12D59D for ; Fri, 24 Jun 2016 18:10:09 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id b72so114568788ywa.3 for ; Fri, 24 Jun 2016 18:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=DUInT0udHsYO9S81uHxzDlNW9r/jBG678pPazDi/2Fc=; b=LkCwD8psMoL3duS43O6yCUJSYhBFw1nYG/YzJ0jC4cOcJhsDK2V5b8Bj/Y0P29S15f EAzgJYt+EsaAGgHP21vyQUtRqWgdF859mtP3lAi1WTqOs5uYHu8nI86ZnIgi8Gm8+EJg OlXZtvKv1R7Q+Au/1+mWMRFLl8s55N+saVUYDi3CCkdhvfS5/H3a0u4ev44zQNMoQcQR AlPX2CFIV0AIYyuWN59sSiyfkVtl2IDQKcx3QaEEukuZ6P2YcZMIkDZZfjr8PDw/UlaG 34jnT4MJ9X0D+rpCwgS2awyTUjfssAkmp3At7qI5emNiidisH31l6Syc6cHJKc8Og2oi QkEQ== 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:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=DUInT0udHsYO9S81uHxzDlNW9r/jBG678pPazDi/2Fc=; b=T8vLm6D6WmFdJxc907H/gQOV1uDG52EeYnnwP/0lFWhLa6ra6F7wcQAyYlER9KPqVV i/Q0HjNFm+3soB9HapzVnVHLla0PPDoSwEJbQYv8Kzvroz9ZoLRkm6eV5Gn1iOygZLzT C60rX5j6/WKG3rJk/vo6LKMkjG0aDQknGUn56EIvajjJ/HtgxeQDPyR1CfIEh8igspen g4kWFschD7qdwaxRQd/OoKn2Uz25DkhG49BPNqt86FeKuEn/oqKya7oU2A4eGpz3ENGm t1tPLjvrRz3w+1jt9hpeSyDGq/0Gb4ghxLbv/UpiyXjgep9LYTFqZ+I1wrz/vOQscZop asXw== X-Gm-Message-State: ALyK8tJSYfaJUPSllsK0k1hBg1ul0PlVzZWH1otHdX62IA0LdxMTDcafof2F6Tcz6eL/Aw== X-Received: by 10.129.165.70 with SMTP id c67mr4861220ywh.67.1466817008538; Fri, 24 Jun 2016 18:10:08 -0700 (PDT) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id k5sm4188866ywd.50.2016.06.24.18.10.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jun 2016 18:10:08 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: Date: Fri, 24 Jun 2016 21:10:06 -0400 Message-ID: <029c01d1ce7e$4fedf110$efc9d330$@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: AdHOfiqy9ZhOIgKySPOmGXsmaNTVwQ== Content-Language: en-us Archived-At: Cc: 'Donald Eastlake' Subject: [babel] Pool for presentations at Berlin IETF 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, 25 Jun 2016 01:10:11 -0000 Y'all -- The BABEL working group has a two hour slot at the IETF in Berlin -- are there folks who would like to present current drafts, or potentially other interesting work? Donald & Russ From nobody Fri Jun 24 20:23: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 A7C9712D7FD for ; Fri, 24 Jun 2016 20:23:52 -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 Ttb8ku3BfE-M for ; Fri, 24 Jun 2016 20:23:50 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 CED5612D549 for ; Fri, 24 Jun 2016 20:23:50 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id s66so139308811oif.1 for ; Fri, 24 Jun 2016 20:23:50 -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=8qZzk02ZhNC/YHiQ21r9kPSkK3bjHDa2i9cpuV4me0A=; b=JPcSmW+DOCGJqjPQd0usnctN+2OFsvd19mnWcK7+paWNZ1RAvFir+DscxwL0T8vrmB B+dzE15+qYLWXmaZhmJuA25kyRJOD+OHpk1Glk5SAiaRekFFLB9gmrtvAOEhuL0d6FsV w06cAGYI6trvcc3/CEyryfDFi600ov/OD8wZj7o0qsGJvtMY1bLHZ0zoY+U8ZFa4ads4 3/q9HVAxaTjT1IBqRWVgS7RevOZeDHhNtTXweZHPpn3yO7CYrahpxeYkoZeIr/106ZbV HC5zUwZU3HecVrr8VKQIu2QExYNrn1fZCUANwiFVURaggBjt76jmRSDounTcdr40L8iu Hipw== 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=8qZzk02ZhNC/YHiQ21r9kPSkK3bjHDa2i9cpuV4me0A=; b=mXyFWrD1imNckoDcBW3OB0YPn+XQKqYvTL/RJ/4iyKAwIbTRMijatZLzDE/bX1saX9 e50xqKEkcsv0ltOKz+iUvmXPVAWDx8jc8UL9hWiAwlttQqIJtXwGwuYK98dIC6uvR8DF e2zpgvQKvVzafwU/cxHQACMMfhzuhPxvQdrXWcjFqLFboO6XXSSBmN7wUF7ZGrUjEzTB FsKx41xkPnoh6S7/4HX+8QlbwWGp5Etlnm+r8tKNn9bc7ydDuW3I9uM2bh7NCUYugLv/ Zy6kkoCp7wLtrVFFO16aO0ez/pFwWhXjwojNSFMOet+/P267+vz22ftdFhoSn3HmNOnc O6jg== X-Gm-Message-State: ALyK8tKUJjwQXV2C8XUjuZMwKQO3h/7u2+70ekxmK6yjOg0nPSQA7Z9ZNe0pE+kiskXGRs1wr7BIORlYBSC0XA== X-Received: by 10.202.242.139 with SMTP id q133mr4981245oih.126.1466825030047; Fri, 24 Jun 2016 20:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.242 with HTTP; Fri, 24 Jun 2016 20:23:35 -0700 (PDT) From: Donald Eastlake Date: Fri, 24 Jun 2016 23:23:35 -0400 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=94eb2c092822dd2077053611d0ce Archived-At: Subject: [babel] Poll for Working Group adoption of draft-chroboczek-babel-applicability (6/24-7/8) 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, 25 Jun 2016 03:23:53 -0000 --94eb2c092822dd2077053611d0ce Content-Type: text/plain; charset=UTF-8 Hi, This starts a two-week poll on adopting https://datatracker.ietf.org/doc/draft-chroboczek-babel-applicability/ as a BABEL WG document, Please indicate if you think this sort or should not be adopted as a starting point. Comments on the draft are also welcome. Thanks, Donald & Russ =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --94eb2c092822dd2077053611d0ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This starts a two-week poll on adop= ting
as a BABEL WG document, Please indicat= e if you think this sort or should not be adopted as a starting point. Comm= ents on the draft are also welcome.

Thanks,
Dona= ld & Russ
=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
--94eb2c092822dd2077053611d0ce-- From nobody Fri Jun 24 20:26: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 6745312D800 for ; Fri, 24 Jun 2016 20:26:35 -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 4bjotNWbNO2k for ; Fri, 24 Jun 2016 20:26:33 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 E7A5612D7FD for ; Fri, 24 Jun 2016 20:26:32 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id f6so126313964lfg.0 for ; Fri, 24 Jun 2016 20:26:32 -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=31dIwyaE1Wno2F7gx0le9qvtLt5LOEx9YwaLVfCWGxU=; b=lZNEMiASeMMlujT48yAr76p6z2BVJqsu3d69+yvMzAMJuLUuev7p6ojHfD91+ATOaH MNYXnR3qTfAzDbGwJWS7P9945gE/JqnWgyrpmbjOTA+u1ZCpflFjALtu+dNYFeXsz0Bd 5nsV5b70vBkrFQ419dsJRBWJueyEoNX4lO2dADp10CKb4io70hdx0BEgVBOcTkrguwXk vYQSG4h4VBJezYWx9KVnY5lbxwl/2E9JNPWkTmiDn5VysV6vRvgjrkIhV0QFms2jwn0l +356CQV+VjhJ704LdqmFty4sAkWlEi1mccDVRLccxe5x8BEcsbDdyk0s5jmg5Jgfuy3Y tdGQ== 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=31dIwyaE1Wno2F7gx0le9qvtLt5LOEx9YwaLVfCWGxU=; b=kt6r6P+COf60aY4gsj2JLr1n9YS3en6CmDgFpuvGds+VPDzzVPmSMt/VTDeBi+S4ps yvCBwylkhAJbdE3rjKzLPb2SUn8XjDrnHjZGOXTWdwadh3f7h2/7sbRQE6+aupzUlZK5 a85c6kcBIMEDClS0Turr+PnbMiBUFaeFYm0toL5O2YbYYfWZBbIgUyH88rJoP3ZJ2xHy hn8bN5OHQkreB/NqPcyLwMoPXjBBnveyULGHdFHi0mB0cqwsORe5dtVAPMGdPO8kkKSc X5p9cngS6sum7tCNtwK0qGFmNeVM4OEz++Wa1B1Wceht1iSKxneug0ekmVDky90FLfiV Z9Bw== X-Gm-Message-State: ALyK8tKL6qdv+dzZN7DbhOa0pXvZPKY1WuzU0+PbLTe+ySRKwF6HiumRagQ/zSq1xk64gDLUO1JHP8L3r8O5Bw== X-Received: by 10.25.85.200 with SMTP id j191mr1878141lfb.39.1466825191078; Fri, 24 Jun 2016 20:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.219 with HTTP; Fri, 24 Jun 2016 20:25:51 -0700 (PDT) In-Reply-To: References: From: Ted Lemon Date: Fri, 24 Jun 2016 23:25:51 -0400 Message-ID: To: Donald Eastlake Content-Type: multipart/alternative; boundary=001a11424d0c76508b053611daff Archived-At: Cc: Babel at IETF Subject: Re: [babel] Poll for Working Group adoption of draft-chroboczek-babel-applicability (6/24-7/8) 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, 25 Jun 2016 03:26:35 -0000 --001a11424d0c76508b053611daff Content-Type: text/plain; charset=UTF-8 I've read the document. It looks like a reasonable place to start. I support adoption. On Fri, Jun 24, 2016 at 11:23 PM, Donald Eastlake wrote: > Hi, > > This starts a two-week poll on adopting > https://datatracker.ietf.org/doc/draft-chroboczek-babel-applicability/ > as a BABEL WG document, Please indicate if you think this sort or should > not be adopted as a starting point. Comments on the draft are also welcome. > > Thanks, > Donald & Russ > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > --001a11424d0c76508b053611daff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've read the document. =C2=A0 It looks like a reasona= ble place to start. =C2=A0 I support adoption.

On Fri, Jun 24, 2016 at 11:23 PM, Donald= Eastlake <d3e3e3@gmail.com> wrote:
Hi,

This starts a two-week po= ll on adopting
as a BABEL= WG document, Please indicate if you think this sort or should not be adopt= ed as a starting point. Comments on the draft are also welcome.
<= br clear=3D"all">
Thanks,
Do= nald & Russ
=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 0175= 7 USA
=C2=A0d3e3e3= @gmail.com

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


--001a11424d0c76508b053611daff-- From nobody Sat Jun 25 00:29: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 5FDD712D862 for ; Sat, 25 Jun 2016 00:29:08 -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 9Wr9GWT7HumT for ; Sat, 25 Jun 2016 00:29:06 -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 1BCFA12D5F6 for ; Sat, 25 Jun 2016 00:29:06 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r201so50568313wme.1 for ; Sat, 25 Jun 2016 00:29:06 -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=R+tbpb9WRilHAEPo0DVu7iwjDYbJhrqr87o3HiK9d/Y=; b=WH8GHPnYijCsHPDCTdYfLRjzopm5HU55Gl9ihIiVQNiw80A5+vI3IbRv6S0flLkjYX NAI2TlgHrpTtpoIEuMCCgx4xwYSv/VpD2FfLxcyE5BYXy+8Ew04G31rXX68dmgJkFkoa oHRIOU4lG23BXmwNFTNpCUzx/P8stGdCAUtCT1YtHVBeXqMlaYjQFnnc7UrzxJeUpvI/ wlQF9AUw4us5t7OuwD/kxkYJOqYG524ioSZOGaNfnOsEsVK3F/6Dnt5QSfZ7uiYQdgB6 T+qL7SghlNkhYtgNbyH3ulyYzv+KsqOh/AoIKzT9/SpmanGRzoih0Hae+6hWp/YGHbI9 bSuQ== 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=R+tbpb9WRilHAEPo0DVu7iwjDYbJhrqr87o3HiK9d/Y=; b=lgs21ewwtpevvLr0vgnrj+mPhzQZVTSGRmPs4NMsBOXHy/cBQRpcGzXY7rWQMJBfSv vp9W6Iz5/Nh9ek+QVZDWbiBuRBsj4tIWW0saYWBV69iUwnBZ4Pu3TEYGhUVmROov3eoK aYx8vEOVHn9rS+1vqAMnjJbwZhFamztwf/j+g3hbPjO9r3VEealTx3lL93Ig0kzuFpNi HzXPj/XoC3CzJg2zynHPrP8PLM0nZTTMDjXlsoMlDPVxm+0YMauyn80QIqHhShFO9kYp kR47FTwAZmGjnHQn1ZI3Wt1n5eoYl70MxL4b8e2RaZTFY9ksVhI+M6ZYw6lWdWmxSHdM NIdQ== X-Gm-Message-State: ALyK8tIsebdxwcbEUA84QRYgFmmK4agCtYwUkszhdGWzZQ+F/a3ZRjbhltiBSuzI2EoPfWBl7D/9wbO8SWKHpS8X X-Received: by 10.28.137.67 with SMTP id l64mr1576384wmd.51.1466839742205; Sat, 25 Jun 2016 00:29:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.151.97 with HTTP; Sat, 25 Jun 2016 00:28:22 -0700 (PDT) In-Reply-To: References: From: Gabriel Kerneis Date: Sat, 25 Jun 2016 09:28:22 +0200 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a114432fec8e7cc0536153d1e Archived-At: Cc: Donald Eastlake , Babel at IETF Subject: Re: [babel] Poll for Working Group adoption of draft-chroboczek-babel-applicability (6/24-7/8) 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, 25 Jun 2016 07:29:08 -0000 --001a114432fec8e7cc0536153d1e Content-Type: text/plain; charset=UTF-8 On Sat, Jun 25, 2016 at 5:25 AM, Ted Lemon wrote: > I've read the document. It looks like a reasonable place to start. I > support adoption. > I support adoption as well. I note that the draft does not mention Homenet at all, but I guess this can be fixed if deemed necessary after adopting it. Gabriel --001a114432fec8e7cc0536153d1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jun 25, 2016 at 5:25 AM, Ted Lemon <mellon@fugue.com> wro= te:
I've read the do= cument. =C2=A0 It looks like a reasonable place to start. =C2=A0 I support = adoption.

I support adoption as well.= I note that the draft does not mention Homenet at all, but I guess this ca= n be fixed if deemed necessary after adopting it.

= Gabriel

--001a114432fec8e7cc0536153d1e-- From nobody Sat Jun 25 00:34: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 927E612D669 for ; Sat, 25 Jun 2016 00:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 U3f2V3_wtZpw for ; Sat, 25 Jun 2016 00:34:07 -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 EFC6C12D5F6 for ; Sat, 25 Jun 2016 00:34:06 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l125so117127517ywb.2 for ; Sat, 25 Jun 2016 00:34:06 -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=CEIFUAXVUj5+xv6wy3kwbuxOR/lE/BWIlYef40IK7C4=; b=i5kpQNaqw6xm5plbW+bz5KspbexTjaLyVm+Gg5tOtPxd7OByhUYdeBIpbHiOZ6p+KO ZkLeAPJj2aqTrrSktPmyRTCOG4Gm8bom0zefXbZPwivOTSyx27kYQQk9pb9zjgHu5xKw xhDrIo77FkbW1yIH1yYjS7yOWJwJg8Q1oEP/ww9YXl0t7r2EnkChkHvrOr9rOJbk75K0 moYOGzXPpVKwZjTa+gcKYfVA7RWEZTNyyJfOfgWL0KnB8DPR26MhWklwvKFz1FU+m/cg R/DU2RRc2dJhxQZyOi/wUL5HZouO9bZmv2/hcGheyt0/dfyi3m19uQyuR+I+kl/sh712 GLzQ== 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=CEIFUAXVUj5+xv6wy3kwbuxOR/lE/BWIlYef40IK7C4=; b=JfOQl8dI3EAm7I7KsTYxocXE13Qd07E5Fxk4OVEXtIfHJrWtDxWvo49o12817GNjaN Hnicx2NWra1234H4+KyU/6Dm3Ki98AzHonNGStitkDHBnHhK98dq/adEHjjZaJSEvarX lVsg/TQBBSDZszUtI5hEUXkKCu60se4s1wtM83HNAAqQqJ3GZ/G9MuTJC+12e0Janyso 3hSlL0dRiYxZISErgbTP31EigAi+QLfjpYR+Zp19EGSVl/6HTdMKItiiiVSyBPvwZQ+g 2YUJaOQJEqMm2LedvRGcj+EAS8tPjp7pVnQwfhJOMQOiJfA/6+NjSWCCNHJPtLm2TDMb mw8g== X-Gm-Message-State: ALyK8tLTtO/ydOB4aUGV9sze0ey0PfHMGj1MgK1HboyjtnHu5AlSK6qIxkYe061cOmsGoA== X-Received: by 10.37.217.203 with SMTP id q194mr5388908ybg.141.1466840046179; Sat, 25 Jun 2016 00:34:06 -0700 (PDT) Received: from [10.248.44.145] ([166.170.55.191]) by smtp.gmail.com with ESMTPSA id g4sm1826429ywa.48.2016.06.25.00.34.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Jun 2016 00:34:05 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-DC470A79-2E13-4AE8-8978-19FE06FDC77D Mime-Version: 1.0 (1.0) From: Tim Wicinski X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Sat, 25 Jun 2016 09:34:03 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9C390E14-258F-42B7-8DC1-A1613C8697E9@gmail.com> References: To: Donald Eastlake Archived-At: Cc: Babel at IETF Subject: Re: [babel] Poll for Working Group adoption of draft-chroboczek-babel-applicability (6/24-7/8) 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, 25 Jun 2016 07:34:08 -0000 --Apple-Mail-DC470A79-2E13-4AE8-8978-19FE06FDC77D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I've read the document and I support adoption.=20 Tim =46rom my high tech gadget > On Jun 25, 2016, at 05:23, Donald Eastlake wrote: >=20 > Hi, >=20 > This starts a two-week poll on adopting > https://datatracker.ietf.org/doc/draft-chroboczek-babel-applicability/ > as a BABEL WG document, Please indicate if you think this sort or should n= ot be adopted as a starting point. Comments on the draft are also welcome. >=20 > Thanks, > Donald & Russ > =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 > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail-DC470A79-2E13-4AE8-8978-19FE06FDC77D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I've read the document and I support a= doption. 

Tim

=46rom my high tech gadget

On Jun 2= 5, 2016, at 05:23, Donald Eastlake <d= 3e3e3@gmail.com> wrote:

<= div dir=3D"ltr">Hi,

This starts a two-week poll on adopti= ng
as a BABEL WG document, Please indicate if y= ou think this sort or should not be adopted as a starting point. Comments on= the draft are also welcome.

Thanks,
Donald & R= uss
=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
 Donald E. Eastlake 3rd   +1-508-333-2= 270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com
____________________= ___________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mai= lman/listinfo/babel
= --Apple-Mail-DC470A79-2E13-4AE8-8978-19FE06FDC77D-- From nobody Sat Jun 25 09:38: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 362D012D15A for ; Sat, 25 Jun 2016 09:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=joelhalpern.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 e2k3gLz_krjt for ; Sat, 25 Jun 2016 09:38:44 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 98CB812D149 for ; Sat, 25 Jun 2016 09:38:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 813A12407EC; Sat, 25 Jun 2016 09:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1466872724; bh=dQw1zsLpFcI+ZA1Akq1kRxzzHkS4tU59w2438EDvC2k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GNCP4hC+5TSJ62bm28c6XHzqwHBtJPwxpM8yaA2A/CvlKGt5hBCQ2kAXNuERTODRS 1TWd4HIIRniC4eibvd4Y8GGspqGWRkWAntQUomNNclvkAZElFJ5kOQ0PfRdbDkWvXt uDaHIptoGG6OCL4MiGrwNlALZKy4HQZ4cEhUPhlo= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 095412404FA; Sat, 25 Jun 2016 09:38:43 -0700 (PDT) To: Donald Eastlake , Babel at IETF References: From: "Joel M. Halpern" Message-ID: <1b8cae82-e71d-1b8d-03de-ea7feb5178aa@joelhalpern.com> Date: Sat, 25 Jun 2016 12:38:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 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] Poll for Working Group adoption of draft-chroboczek-babel-applicability (6/24-7/8) 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, 25 Jun 2016 16:38:46 -0000 I believe this document is a good basis for addressing this WG need. I support adoption. Yours, Joel On 6/24/16 11:23 PM, Donald Eastlake wrote: > Hi, > > This starts a two-week poll on adopting > https://datatracker.ietf.org/doc/draft-chroboczek-babel-applicability/ > as a BABEL WG document, Please indicate if you think this sort or should > not be adopted as a starting point. Comments on the draft are also welcome. > > Thanks, > Donald & Russ > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Mon Jun 27 03:01: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 2D5B012B071; Mon, 27 Jun 2016 03:01:00 -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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] 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 4ZgxXhqo9W-j; Mon, 27 Jun 2016 03:00:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB5C12D0B5; Mon, 27 Jun 2016 03:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1727; q=dns/txt; s=iport; t=1467021651; x=1468231251; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NzgB05ndXFvAal4UowvSzWYZjNI3QBf7owvP0AcMbaM=; b=Br5zmsbyN8XZOEJ11NH+TueqAk6HVT/S2CL6hFFFVAdSW2AtBYRPpiMK eVc8t3lqA62cS9t1lQI2Za5R6eTktAX0Wez4XoMxGrxkV+fF4vLpOXC6Y xLY1Hgjt2cPyCfvtI45bijl4/6BtH2BpHI85mCsuq6Dq51H09TM5qpBEz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlBwB7+HBX/4cNJK1bgz5WfQa5K4JxF?= =?us-ascii?q?wuFF18CgSw7EQEBAQEBAQFlJ4RNAQEEAQEBNzQbAgEINhAnCxsBBgMCBAESFIg?= =?us-ascii?q?cDr4iAQEBAQEBAQEBAQEBAQEBAQEBAQEdhiiETYE5iGIFmQEBhgeIL4I3jG2Pf?= =?us-ascii?q?gE0IIIVgVtuAYh3fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,536,1459814400"; d="scan'208";a="119373810" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jun 2016 10:00:49 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5RA0ndA027946 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 10:00:49 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 05:00:49 -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.1210.000; Mon, 27 Jun 2016 05:00:49 -0500 From: "Alvaro Retana (aretana)" To: "manet@ietf.org" , "babel@ietf.org" Thread-Topic: [gaia] GAIA RG Meeting Agenda - July 21, 2016 (IETF 96) Thread-Index: AQHR0FSREAYA3HsqykGckTlF86lSF5/9JaWA Date: Mon, 27 Jun 2016 10:00:49 +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: text/plain; charset="us-ascii" Content-ID: <9368B80CDB590E449A48487FD32C45F8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [babel] FW: [gaia] GAIA RG Meeting Agenda - July 21, 2016 (IETF 96) 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, 27 Jun 2016 10:01:00 -0000 FYI.. On 6/27/16, 5:15 AM, "gaia on behalf of Matthew Ford" wrote: >Folks, > >This is the draft agenda for our meeting which will take place during >IETF 96 in Berlin next month. I have included links to the remote >participation tools. I hope to see some of you there, both physically and >virtually. > >Regards, >Mat > >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Preliminary Agenda >GAIARG Meeting @ IETF-96 >Berlin, Germany >Thursday, July 21, 2016 (CEST) >14:00-16:00 Thursday Afternoon session I >Location: Schoeneberg >Audio: http://ietf96streaming.dnsalias.net/ietf/ietf968.m3u >Video: http://www.meetecho.com/ietf96/gaia >Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-gaia >Jabber: gaia@jabber.ietf.org > >Welcome, Agenda Bashing, Minutes taker, Blue sheets, Status > Chairs > 10 mins > >Refugee Hotspot - providing Internet connectivity to Refugees and Migrants > Niels ten Oever & Shane Kerr > 20 mins > >The dual role of community networks: Internet access vs. local services > Panayotis Antoniadis > 30 mins > >FreeSurf: Application-Centric Wireless Access > Zhen Cao > 20 mins > >Sustainability in guifi.net: Initial results of cost sharing > Roger Baig > 20 mins=20 > >Wi-5: Advanced Features for Low-cost Wi-Fi APs > Jose Saldana, University of Zaragoza. > 5 mins + Q&A > >Open discussion of next steps for GAIARG > Chairs > 15 mins > >_______________________________________________ >gaia mailing list >gaia@irtf.org >https://www.irtf.org/mailman/listinfo/gaia From nobody Mon Jun 27 06:54: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 A164112D0B7 for ; Mon, 27 Jun 2016 06:54:09 -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 dyVFfLH4T0Ne for ; Mon, 27 Jun 2016 06:54:05 -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 F2DA512D1EA for ; Mon, 27 Jun 2016 06:54:01 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467035634260398.87966244709; Mon, 27 Jun 2016 06:53:54 -0700 (PDT) Date: Mon, 27 Jun 2016 14:53:54 +0100 From: Denis Ovsienko To: , "babel-users " Message-ID: <1559223496a.d17793824725.7727429011413914222@ovsienko.info> 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: axel@ac.upc.edu Subject: [babel] SEMTOR mesh security mechanism 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, 27 Jun 2016 13:54:09 -0000 Hello all. Regarding the paper titled "Securely-Entrusted Multi-Topology Routing for Community Networks" by Axel Neumann (CC'd) et al., I failed to find which of the mailing lists the PDF link was posted to originally (and by whom), but now I have looked through my hard copy of the paper and would like to note a couple things of interest. My current understanding of SEMTOR mechanism is that it uses an explicit pre-agreed list of node IDs that belong to a trusted sub-graph. This list would then be provisioned into each node, which would then filter non-trusted nodes out when routing a specific set of network prefixes of concern. I have thought about it and it seems to me as the size of the trusted graph grows, the total combined size of the deployed configuration will grow faster (n*n). This makes it much more difficult to add the 100th node to a 99-node graph than it is to add 10th node to 9-node graph. Also as far as I understand it, the pre-agreed list of the trusted nodes cannot be amended online without losing the association with the peer nodes because the set is represented by the hash value of its contents and as soon as one has changed it in one place, the old [different] hash will be filtered out. In other words, compared to a pre-shared key method I see operational disadvantages and don't see a gain. If anyone can point me in a better direction to understand, that would be nice. Another thing, as the paper explains, is the same old link spoofing attack and the same attacks things a rogue node can do on the transit payload. For this SEMTOR doesn't itself claim to be a solution and doesn't refer to some other ultimate solution but does include a discussion of possible detection by means of monitoring. So the good news is problem statement is consistently understood by different people. That said, the solution is still unknown. I would be glad to hear if anyone has to add to this. -- Denis Ovsienko From nobody Mon Jun 27 09:33: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 6891E12D746 for ; Mon, 27 Jun 2016 09:33:56 -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 Dyj-GkpF9x12 for ; Mon, 27 Jun 2016 09:33:54 -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 BC11E12D1B1 for ; Mon, 27 Jun 2016 09:33:54 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467045233295899.2230795372966; Mon, 27 Jun 2016 09:33:53 -0700 (PDT) Date: Mon, 27 Jun 2016 17:33:52 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <15592b5c161.c0bf369e12208.3681860808858283691@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: Subject: Re: [babel] Poll for Working Group adoption of draft-chroboczek-babel-applicability (6/24-7/8) 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, 27 Jun 2016 16:33:56 -0000 ---- On Sat, 25 Jun 2016 04:23:35 +0100 Donald Eastlake wrote ---- > Hi, > > This starts a two-week poll on adopting > > https://datatracker.ietf.org/doc/draft-chroboczek-babel-applicability/ > as a BABEL WG document, Please indicate if you think this sort or should not be adopted as a starting point. Comments on the draft are also welcome. To me the I-D seems to be a fine starting point. These considerations needs to be made somewhere, either in a standalone document or in a section of the main document. Another point I am not sure where it belongs to, but would it make sense to spell Babel behaviour in IPv4-only, IPv4+IPv6 and IPv6-only networks? -- Denis Ovsienko From nobody Mon Jun 27 09:54:14 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 192BF12D661 for ; Mon, 27 Jun 2016 09:54:13 -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 e5sHuSSKHiYP for ; Mon, 27 Jun 2016 09:54:11 -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 6E31B12D0C8 for ; Mon, 27 Jun 2016 09:54:11 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467046450394915.7300911541097; Mon, 27 Jun 2016 09:54:10 -0700 (PDT) Date: Mon, 27 Jun 2016 17:54:09 +0100 From: Denis Ovsienko To: Message-ID: <15592c852dd.d37fe80b13048.2927765307740444705@ovsienko.info> In-Reply-To: <029c01d1ce7e$4fedf110$efc9d330$@gmail.com> References: <029c01d1ce7e$4fedf110$efc9d330$@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] Pool for presentations at Berlin IETF 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, 27 Jun 2016 16:54:13 -0000 ---- On Sat, 25 Jun 2016 02:10:06 +0100 Russ White<7riw77@gmail.com> wrote ---- > Y'all -- > > The BABEL working group has a two hour slot at the IETF in Berlin -- are > there folks who would like to present current drafts, or potentially other > interesting work? Dear working group chairs and members, I would like to attend this time too, but to get things done I have to skip the meeting in person and try remote participation. At the moment I am progressing through my reading list of relevant documents and looking to rig a testbed up. I do read the mailing list. -- Denis Ovsienko From nobody Mon Jun 27 10:12: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 7528112D874 for ; Mon, 27 Jun 2016 10:12:18 -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 QuWpuSiT_-22 for ; Mon, 27 Jun 2016 10:12:16 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 7B3FA12D873 for ; Mon, 27 Jun 2016 10:12:16 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id s66so209238819oif.1 for ; Mon, 27 Jun 2016 10:12: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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lYpvHr7XCukHh5gGv7I8zpGpSZ+K9qjNH8yX/BV+vUY=; b=bDGzbBVohjoPsdWIjx3LwLnXpoJzy3AQzsGHVKLig0+xWS8Xo1YW+lnt/LI7l9fsYg 9eqmkPf7JfwqBZEicPB6QyhJzw/9fCSsq9Lar+x3hsBeNYbWW5p9/lc8O6UJ0xYDCaVx ct9LBdFt7zIMdrR58PywM/pQ19JjPWIQMFZfojPU/qmhm++JG8WkOE5eX5JgN3Qdxrjn 4zXskFQ6TwjaqdMewN/TEjebtVWpnw8BywW5n7UuqZP7MJnL8/SBggI0q6yGSFOOUbzu qRC4pLbnl8Krr85+b1sr3+UKgRPNH4cEH2AQe5O1EEiRGuOLc5ZFoGsfalmMvbq+pFnk vN+A== 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:content-transfer-encoding; bh=lYpvHr7XCukHh5gGv7I8zpGpSZ+K9qjNH8yX/BV+vUY=; b=b7RNkBGGMZeaJ9ulTxaqx/QnNUF3uBt8nLStlBDOk6r9SwnHVqI08GOwLWcT6St75k IJ2MTODMU9zPqCwX0rwHVeNv291bwSokGVASYX1Be/Uftf0EqObQNIEisI3chLdBngSj c5vXxSE/MasN+Mio/6dI3htvVCxGy3AmEk6JI487aHWsRtQikHrh1h4FlcpH2PBKfPQ9 gM0R/AmXIc50Og3ZuodLHz6ubFuPJBt0I2dRgW0S7bfUA7sY0FHbTflbnpSARfNN0cAL I/obcmlXn9IzdjboyqahLOCBXRJmNBK77+8jn7WUt3dhc7LQL/mBA/LS+1AmKomKGS6a FIqQ== X-Gm-Message-State: ALyK8tLZ8PsHqksV4Of5TkOB6cB0IVioNJlfMGnt8rH5f0rpaqm2wEJWv9NTNmus7Utme5COD6RxrZ40s3qIKA== X-Received: by 10.157.56.101 with SMTP id r34mr1493842otd.154.1467047535853; Mon, 27 Jun 2016 10:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.130 with HTTP; Mon, 27 Jun 2016 10:12:15 -0700 (PDT) In-Reply-To: <029c01d1ce7e$4fedf110$efc9d330$@gmail.com> References: <029c01d1ce7e$4fedf110$efc9d330$@gmail.com> From: Dave Taht Date: Mon, 27 Jun 2016 10:12:15 -0700 Message-ID: To: Russ White <7riw77@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Donald Eastlake , Babel at IETF Subject: Re: [babel] Pool for presentations at Berlin IETF 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, 27 Jun 2016 17:12:18 -0000 1) I had a short, fun, preso detailing some of my work on 'homenet for hackerboards', leveraging usbnet + wifi - that has no slot in homenet at this time. 2) I have a bunch of pent up half-written stuff elsewhere that requires more research and coding - after fq_codel for mac8011 finishes landing - and I felt, after this wg had a firm foundation. So... my hope is that the 2 hour babel slot fills up with needed work, rather than my $RANDOM. On Fri, Jun 24, 2016 at 6:10 PM, Russ White <7riw77@gmail.com> wrote: > Y'all -- > > The BABEL working group has a two hour slot at the IETF in Berlin -- are > there folks who would like to present current drafts, or potentially othe= r > interesting work? > > Donald & Russ > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Mon Jun 27 10:39: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 3FF1712D689 for ; Mon, 27 Jun 2016 10:39: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, RCVD_IN_DNSWL_LOW=-0.7] 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 4IzvGXYHQ4fO for ; Mon, 27 Jun 2016 10:39:43 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 3CBF512D63E for ; Mon, 27 Jun 2016 10:39:41 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5RHYrYV011991; Mon, 27 Jun 2016 13:39:40 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 23u8em9rj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jun 2016 13:39:40 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u5RHdc6r001432; Mon, 27 Jun 2016 13:39:39 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u5RHdWA7001298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jun 2016 13:39:33 -0400 Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 27 Jun 2016 17:39:25 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.212]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0294.000; Mon, 27 Jun 2016 13:39:24 -0400 From: "STARK, BARBARA H" To: Russ White <7riw77@gmail.com>, "babel@ietf.org" Thread-Topic: [babel] Pool for presentations at Berlin IETF Thread-Index: AdHOfiqy9ZhOIgKySPOmGXsmaNTVwQCG/Z1g Date: Mon, 27 Jun 2016 17:39:24 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611426B4E0E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <029c01d1ce7e$4fedf110$efc9d330$@gmail.com> In-Reply-To: <029c01d1ce7e$4fedf110$efc9d330$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.216.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-27_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606270180 Archived-At: Cc: 'Donald Eastlake' Subject: Re: [babel] Pool for presentations at Berlin IETF 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, 27 Jun 2016 17:39:53 -0000 It's my hope to get a start on an information model. Maybe if I commit to a= ctually doing it by the contribution deadline of July 7, I'll get it done..= . I'm also trying to get some meaningful testing done (and provide a report i= f there's anything interesting). But I've been having trouble getting my ha= nds on OpenWRT routers that have good instructions for loading OpenWRT, HNC= P, and Babel; newer versions of some formerly good models have proven too c= hallenging. Does any of that sound useful? If it does, I'll make it more of a priority. Barbara > -----Original Message----- > From: babel [mailto:babel-bounces@ietf.org] On Behalf Of Russ White > Sent: Friday, June 24, 2016 9:10 PM > To: babel@ietf.org > Cc: 'Donald Eastlake' > Subject: [babel] Pool for presentations at Berlin IETF >=20 > Y'all -- >=20 > The BABEL working group has a two hour slot at the IETF in Berlin -- are = there > folks who would like to present current drafts, or potentially other > interesting work? >=20 > Donald & Russ >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Jun 27 23:29:43 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 946C312D624 for ; Mon, 27 Jun 2016 23:29:41 -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 m1nuAaGqrDx9 for ; Mon, 27 Jun 2016 23:29:39 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF7612B015 for ; Mon, 27 Jun 2016 23:29:39 -0700 (PDT) Received: from [46.227.151.81] (port=55830 helo=rays-mbp-3.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1bHmWf-0003Dl-7I (Exim 4.72) for babel@ietf.org (return-path ); Tue, 28 Jun 2016 07:29:37 +0100 To: babel@ietf.org References: <029c01d1ce7e$4fedf110$efc9d330$@gmail.com> From: Ray Bellis Message-ID: Date: Tue, 28 Jun 2016 07:29:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [babel] Pool for presentations at Berlin IETF 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, 28 Jun 2016 06:29:41 -0000 On 27/06/2016 18:12, Dave Taht wrote: > 1) I had a short, fun, preso detailing some of my work on 'homenet for > hackerboards', leveraging usbnet + wifi - that has no slot in homenet > at this time. Has no *confirmed* slot, we do hope to fit it in, subject to progress being made on WG items. Ray From nobody Tue Jun 28 02:36: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 D2BB612DC1C for ; Tue, 28 Jun 2016 02:36:18 -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 1vUwxZVlPd7B for ; Tue, 28 Jun 2016 02:36:17 -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 771A612DC1D for ; Tue, 28 Jun 2016 02:35:31 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1467106524651179.3528516782544; Tue, 28 Jun 2016 02:35:24 -0700 (PDT) Date: Tue, 28 Jun 2016 10:35:24 +0100 From: Denis Ovsienko To: Message-ID: <155965cfdac.cbdb555c4322.6526672062053797991@ovsienko.info> In-Reply-To: <1559223496a.d17793824725.7727429011413914222@ovsienko.info> References: <1559223496a.d17793824725.7727429011413914222@ovsienko.info> 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: babel-users , axel@ac.upc.edu Subject: Re: [babel] SEMTOR mesh security mechanism 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, 28 Jun 2016 09:36:19 -0000 ---- On Mon, 27 Jun 2016 14:53:54 +0100 Denis Ovsienko wrote ---- >Hello all. > >Regarding the paper titled "Securely-Entrusted Multi-Topology Routing for Community Networks" by Axel Neumann (CC'd) et al., I failed to find which of the mailing lists the PDF link was posted to originally (and by whom), but now I have looked through my hard copy of the paper and would like to note a couple things of interest. > Found the link to the PDF: http://bmx6.net/news/22 Originally suggested by Dave: https://www.ietf.org/mail-archive/web/babel/current/msg00312.html >My current understanding of SEMTOR mechanism is that it uses an explicit pre-agreed list of node IDs that belong to a trusted sub-graph. This list would then be provisioned into each node, which would then filter non-trusted nodes out when routing a specific set of network prefixes of concern. > >I have thought about it and it seems to me as the size of the trusted graph grows, the total combined size of the deployed configuration will grow faster (n*n). This makes it much more difficult to add the 100th node to a 99-node graph than it is to add 10th node to 9-node graph. Also as far as I understand it, the pre-agreed list of the trusted nodes cannot be amended online without losing the association with the peer nodes because the set is represented by the hash value of its contents and as soon as one has changed it in one place, the old [different] hash will be filtered out. In other words, compared to a pre-shared key method I see operational disadvantages and don't see a gain. If anyone can point me in a better direction to understand, that would be nice. > Well, obvious things sometimes take time to be understood. In SEMTOR the advantage is each trusted sub-graph only protects its own prefixes of interest. After some thinking this interesting property does not seem to be exclusive to SEMTOR, however. In particular, the RFC7298 authentication mechanism could pass to the main protocol instance the details of successful check together with each accepted Babel packet. Then the main protocol instance could keep a note of which neighbours have successfully worked which security associations and make this information available to the route filtering layer, which then would provide the operator with means to shape the trusted sub-graph using the terms similar to SEMTOR: * accept prefix P1 or longer if worked SA 123 * accept prefix P2 or longer if worked SA 123 * reject prefix P1 or longer * reject prefix P2 or longer The description is not technically accurate but the idea should be clear. I am not sure how much practically useful it can be, but anyway. >Another thing, as the paper explains, is the same old link spoofing attack and the same attacks things a rogue node can do on the transit payload. For this SEMTOR doesn't itself claim to be a solution and doesn't refer to some other ultimate solution but does include a discussion of possible detection by means of monitoring. So the good news is problem statement is consistently understood by different people. That said, the solution is still unknown. I would be glad to hear if anyone has to add to this. > -- Denis Ovsienko From nobody Tue Jun 28 09:07:41 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 3093812D5A0 for ; Tue, 28 Jun 2016 09:07:39 -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 QOkruu3hs3ZC for ; Tue, 28 Jun 2016 09:07:37 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 6C67F12D59D for ; Tue, 28 Jun 2016 09:07:37 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id f189so29392290oig.3 for ; Tue, 28 Jun 2016 09:07:37 -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:content-transfer-encoding; bh=KnndM5wzYHfOHEC33cOmz9uLno8F7Pf5vVk6rSJvTXA=; b=JYdBLQuBaZ7IDSiSb4q6bVYF9i9bFVXQb/2X0rTVjvjnfJ/xri3yYuP4cSS6BkIY+/ s+v2xjtokZZh3iewzP2bf2lm0mKMl0gYhv1NfqsfsPkVTKp5IQHlXggteJdk5ejXvZs4 tzYjHmSWY5TrNEN43lr8w5advpM0F2hOiEgzxV+QgNQluWTVW7F9GA0iXGlhoFzdMoDK uHSUS2ZzRqWr02d1ZaHM0RChZj874fq8FLBlGeT6FgtacDLENLTSj8HZdDTzRm/cZvMJ EHbUwq5EnVPWuWnT2zHs1yq0E8kjovBSPFWas0s69VyOBLvxklOQ/rnzSFVV9Mxlq99B EI2g== 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:content-transfer-encoding; bh=KnndM5wzYHfOHEC33cOmz9uLno8F7Pf5vVk6rSJvTXA=; b=PEEwPAqbqivOE0ECr+8D8Lc/h11dtFbJ/FjsFKcuAqMOpwfxa83O7w0fvaBRxa2VSO 1EFAwXGs+tS9CpWqhA+IxG6GeqQChB+ceylm/d2nxNnITMbS9A10y39B6lLqQ02+O3kF tXzl1qZAXGLqb2+HjZiS+gPnJW8/JS/tPJEDJe5VN7BWPm2j/GB/xqB7Y0jN7gk+WHb6 9sRdi//me6Swt+LDViTn5ai2mUk9xqOD32O0PkNxKzlTlWNudjFYl3uipRUepRw5pZRt CFxajVfH5IvF3t8qs6uf3CCxtlTSiTvaGr4AKbP5/5XMembGMnuSXYpR4H35knt/ivbf 4OHg== X-Gm-Message-State: ALyK8tLbkxi4i93o87tMF0V4XxM9jkIriC41MVYC7vxptOGQG/pAB6Br6kGnRIDAA1rhTOP0d2sbDlpu/lE1Zw== X-Received: by 10.157.39.75 with SMTP id r69mr2382961ota.181.1467130056648; Tue, 28 Jun 2016 09:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.52.242 with HTTP; Tue, 28 Jun 2016 09:07:22 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611426B4E0E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <029c01d1ce7e$4fedf110$efc9d330$@gmail.com> <2D09D61DDFA73D4C884805CC7865E611426B4E0E@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Donald Eastlake Date: Tue, 28 Jun 2016 12:07:22 -0400 Message-ID: To: "STARK, BARBARA H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "babel@ietf.org" , Russ White <7riw77@gmail.com> Subject: Re: [babel] Pool for presentations at Berlin IETF 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, 28 Jun 2016 16:07:39 -0000 Barbara: I think it would be useful to have an initial information model. All: My personal opinion is that we have a relatively generous amount of time available and should be able to accommodate the presentations suggested so far... 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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jun 27, 2016 at 1:39 PM, STARK, BARBARA H wrote: > It's my hope to get a start on an information model. Maybe if I commit to= actually doing it by the contribution deadline of July 7, I'll get it done= ... > I'm also trying to get some meaningful testing done (and provide a report= if there's anything interesting). But I've been having trouble getting my = hands on OpenWRT routers that have good instructions for loading OpenWRT, H= NCP, and Babel; newer versions of some formerly good models have proven too= challenging. > Does any of that sound useful? If it does, I'll make it more of a priorit= y. > Barbara > >> -----Original Message----- >> From: babel [mailto:babel-bounces@ietf.org] On Behalf Of Russ White >> Sent: Friday, June 24, 2016 9:10 PM >> To: babel@ietf.org >> Cc: 'Donald Eastlake' >> Subject: [babel] Pool for presentations at Berlin IETF >> >> Y'all -- >> >> The BABEL working group has a two hour slot at the IETF in Berlin -- are= there >> folks who would like to present current drafts, or potentially other >> interesting work? >> >> Donald & Russ
DateMilesto= ne
Aug 2017IESG Submission of Babel Applicability draft
Jul 2017IESG Submission of Babel Management draft
Jul 2017IESG Submissio= n of RFC6126bis and potentially companion security mechanisms draft
Oct 2016WG adoption of Babel Management (Info Model & Y= ANG Model) draft
WG adoption of RFC6126bis
Jul 201= 6W= G adoption of Babel Applicability draft=C2=A0
draft-chroboczek-babel-applicability