From nobody Wed Apr 1 18:43:52 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CE11AD1DB; Wed, 1 Apr 2015 18:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 H0e6u_OqOaqc; Wed, 1 Apr 2015 18:43:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 1D0841A8A96; Wed, 1 Apr 2015 18:43:49 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:a03d:ff9:7f8:ed99]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t321hMom020240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 01:43:22 GMT (envelope-from joelja@bogus.com) To: Margaret Wasserman , "Joel M. Halpern" references: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> x-enigmail-draft-status: N1110 From: joel jaeggli message-id: <551C9EB9.6040200@bogus.com> Date: Wed, 1 Apr 2015 18:43:21 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Thunderbird/37.0 mime-version: 1.0 in-reply-to: <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wjawlv0QOfqF1INU9ARaX4FmVEn2Ow0O2" Archived-At: Cc: "int-ads@ietf.org" , "rtg-ads@ietf.org" , Dave Taht , Ray Bellis , "homenet@ietf.org" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 01:43:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wjawlv0QOfqF1INU9ARaX4FmVEn2Ow0O2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/31/15 9:25 AM, Margaret Wasserman wrote: >=20 > Hi Joel, >=20 > As I understand it, the downref policy is intended to allow references > to Informational or Experimental documents in specific cases. The page= > you referenced says: "Exceptions to this rule are sometimes needed as > the IETF uses informational RFCs to describe non-IETF standards or > IETF-specific modes of use of such standards." >=20 > I don't think it is intended to allow a downref to a protocol defined i= n > a non-IETF RFC. Babel was published as an Independent Submission > Experimental RFC. We have already been told by at least one AD that > they wouldn't approve that sort of downref, but that may not represent = a > final decision of the IESG. The concern about labels is offputting, the downref policy is about exception handling, and the mechanics of reviewing and approving it has a lot to do with the necessity of making the normative reference, since it's already been established that the status is a problem. > If this is something the Homenet WG may want to do (even though we > didn't have consensus to do this during the meeting), would it be > possible for us to get an answer from the IESG about whether they would= > approve this, as part of our selection process? my own .02 is that I don't think we're really forging new ground here. if you can refer to rfc 3174 which is pretty foundational then this has already been considered... > Margaret >=20 >=20 > On Mar 31, 2015, at 12:02 PM, "Joel M. Halpern" > wrote: >=20 >> Actually Ray, IETF process, as described by the IESG, happily allows >> for Downref with suitable approval and notice to the community. So, >> as far as I can tell, homenet could indeed reference and mandate Babel= >> in a Proposed Standard RFC. I would agree that homenet choosing to do= >> that would be a strong impetus for moving the document to Standards >> track. But that does not have to be gating. >> >> https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry >> >> Yours, >> Joel >> >> On 3/31/15 11:54 AM, Ray Bellis wrote: >>> >>>> On 31 Mar 2015, at 16:35, Dave Taht wrote: >>>> >>>> I don't see any point in starting up a new working group[1] whatsoev= er >>>> based on the events of the last ietf homenet meeting, particularly >>>> with the arrival of a new written from-spec version of babel in unde= r >>>> 15 hours, (which I am still chortling about. I am tempted to write o= ne >>>> in rust). >>> >>> Whilst full standardisation of Babel may end up happening in a WG >>> anyway, some of this design team's job will be to establish whether >>> it's more expedient to bring Babel up to "proposed standard" levels >>> of specification than to add Homenet-related features (per your list >>> below) to existing IETF endorsed standards. >>> >>>> It is just punting the question and more delay when stuff that is mo= re >>>> than sufficiently stable is done, already, and shipping, with a 5 ye= ar >>>> long productization pipeline left to fill. >>> >>> For better or worse, IETF process dictates that we cannot use what is= >>> officially an _experimental_ protocol in a standards track document. >>> Markus' work was very impressive, but not sufficient to overcome >>> that hurdle. >>> >>> However this _should_ be a very short-lived punt - less than one IETF= >>> cycle. The WG was unable to reach consensus over three full IETF >>> cycles, and this structured design team approach _should_ clear this >>> log jam. >>> >>>> (If it helps any (which I doubt) I have never thought that homenet >>>> must settle on one routing protocol, and certainly the from the ISP >>>> part of the link is underspecified) >>>> >>>> At least one routing protocol must be available, however to turn bac= k >>>> the tide of the current situation where none are commonly available = in >>>> most consumer routing gear. More than one IS available. >>> >>> We are arguing on the choice of one _mandatory to implement_ >>> protocol. For interoperability's sake, this will be the one that >>> "must be available". >>> >>> Nothing can (nor will) prevent additional protocols from being >>> implemented, and perhaps even operate simultaneously. >>> >>>> Aside from that my major two requirements have only been >>>> >>>> 0) Must support source specific routing >>>> 1) A homenet capable routing protocol MUST work well over wifi and >>>> wireless links in addition to conventional ethernet and other mac >>>> layers >>>> >>>> My minor requirements were: >>>> >>>> 0) Binary and memory sizes must be small enough to fit into teeny >>>> routers >>>> 1) should be wildly available in every off the shelf OS that might b= e >>>> used for routing >>>> 2) should be extensively tested in environments ranging from homes, = to >>>> battlemesh, to small business campus networks >>>> 3) Should have a good spec, must have at least one open sourced and >>>> liberally licensed implementation >>> >>> These requirements are all very well understood. >>> >>>> So to me, y'all are wasting time that could be better spent into A) >>>> pouring resources into making hnetd less the monster than it became,= >>> >>> please elaborate (in a separate thread, please!) >>> >>>> B) dogfooding what exists and C) developing better tests and D) >>>> developing better metrics >>>> >>>> PS However. >>>> >>>> [1] I would not mind a working group that took the outputs of the >>>> battlemesh folk (babel, olsr-ETX, batman, bmx) and stacked them up >>>> against the outputs of the ietf working groups (like RPL, olsrv2, an= d >>>> others from manet and elsewhere) - and the IEEE (like all the layer = 2 >>>> isis stuff) and that wg BOTH tackled them in the working group AND i= n >>>> the real world - and worked to sort out the mess of academic code an= d >>>> real world requirements in the hope, that one day, maybe before I di= e >>>> of old age and/or apoplexy, the one true routing protocol and metric= s >>>> emerged from the chaos. >>> >>> If enough people backed that and a suitable charter was agreed that >>> could happen. >>> >>> kind regards, >>> >>> Ray >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 --Wjawlv0QOfqF1INU9ARaX4FmVEn2Ow0O2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUcnrkACgkQ8AA1q7Z/VrJK3ACeKPiyKm2hovSWKG19swvIP7sp 0C0An11QD0CrO1AQPCaFUcheyS7wb6dU =j9YT -----END PGP SIGNATURE----- --Wjawlv0QOfqF1INU9ARaX4FmVEn2Ow0O2-- From nobody Wed Apr 1 20:34:18 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABCC1B2A0C; Wed, 1 Apr 2015 20:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 0aNaFWrUuuRR; Wed, 1 Apr 2015 20:34:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AB71B2A0E; Wed, 1 Apr 2015 20:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1375; q=dns/txt; s=iport; t=1427945653; x=1429155253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XM+Lvy2eYFScbFFIMXYMR1VH66EvXJh9j/v1MOi+rKo=; b=Vl1s1XBvI872fyllkuYSUbIoBa4o50oAcNRd9f4prqAQbqwUkllEwyqI Ribg/5oK13p/ZiOdU30eFZljEdGnz0l+6L3B8qrO7kJeL55DOexDv1Rc9 YA6HhPlChOHjcxXpGMi3j8iIJX6l2280IuW+++Ffrhfu/BA5bwsAH5CAc I=; X-Files: signature.asc : 487 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BABQCEuBxV/4kNJK1cgwiBM8tQAoFKTAEBAQEBAX6EHwEBBHkQAgEIRjIlAgQOE4ghzRkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiymEeQeDF4EWAQSQZIFsgTKGWAGUQCKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,507,1422921600"; d="asc'?scan'208";a="408534393" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 02 Apr 2015 03:34:12 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t323YBNJ023354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 03:34:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.67]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 22:34:11 -0500 From: "Fred Baker (fred)" To: joel jaeggli Thread-Topic: [homenet] Selecting a routing protocol for HOMENET Thread-Index: AQHQbPXhz4tgC7GxP0WYXXsYLIRpIA== Date: Thu, 2 Apr 2015 03:34:10 +0000 Message-ID: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551C9EB9.6040200@bogus.com> In-Reply-To: <551C9EB9.6040200@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_3BA5DD24-F132-414D-9797-C8EF3EA6383C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "int-ads@ietf.org" , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:34:16 -0000 --Apple-Mail=_3BA5DD24-F132-414D-9797-C8EF3EA6383C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 My understanding, which could be wrong, is that the IESG has a = long-standing policy that a routing protocol needs to have two = interoperable implementations, written from the specification. It=92s = not about the SDO or the specification (IS-IS anyone?), it=92s about = having proof that the specification is in fact correct and implementable = from, by having two or more parties do it. --Apple-Mail=_3BA5DD24-F132-414D-9797-C8EF3EA6383C 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 - http://gpgtools.org iQEVAwUBVRyyVJ9ieig10VPpAQKGZAf/aH9SbUlNJhWZjsD7ECBBVcDDaKieU4Bd EGHeBcWOKERjKFjTWx/joO9wspyJz7ZgVuaXmx/BZ9YeES1fDTlxLzbMk1lWCCtX qzu6pdz55ZorTYOESJAKPXjG4pZD7MQo8VS+P/Nx/LccaRxmIruw9m4suju5hm4Y 3njvfePVxoKOUzzxg2VGurEX/ZoYARPbp1LfmlLWK2EU+MDYCmFATuYPbY8mKVYE daVxWKD7EAd7yX4B5UJLZ5minZYhpsq5s/3k9YxkJp8fxN1/XsaT+0ony4+6dr48 GLPz2BGUQSNLoXELbAtctduf35RzbWfBVATIO1SzIIRdythQUMjDRA== =1ZwQ -----END PGP SIGNATURE----- --Apple-Mail=_3BA5DD24-F132-414D-9797-C8EF3EA6383C-- From nobody Wed Apr 1 20:49:46 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67251B2A61; Wed, 1 Apr 2015 20:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 QEyhyYP_IscG; Wed, 1 Apr 2015 20:49:43 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::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 B3CAA1B2A60; Wed, 1 Apr 2015 20:49:43 -0700 (PDT) Received: by pdrw1 with SMTP id w1so67689542pdr.0; Wed, 01 Apr 2015 20:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZmJSt8RHWvT3IGMgikQPm3AVJikrSr7sdG5hE8M8NEU=; b=fm+dmjmH6HOIf7KxgVrtEBbwiiaGKkJqg7L3pZzTXe0h+abjZVq5nMa+vAb57Oymgr kttS2Mts67MXZ2YKMoD+na585GCxnNQ2hg/5cWC+9ZOdbIeivWInBvqzGeU4HMH6k7HI TqkpA0LSds+DtISBzT2Zq4cNQD0jPfJ2hRfOZMGbFITkopAtaQfd46FWn5PtEQbA6CVq sdKbx0YGCuAt/o9WVc886LU1ErQyw8s9VNGa2h//AKF+uB/JIO7x9Qv0xZJo+6JWvDp3 jQO6P1rDIxB02JfZmfkcXXof/lQ2pAR1GUWj7lABuznGvMo821IiRXIEspqllxkEp3C0 k16g== X-Received: by 10.66.66.166 with SMTP id g6mr41939949pat.88.1427946583425; Wed, 01 Apr 2015 20:49:43 -0700 (PDT) Received: from ?IPv6:2406:e007:77ed:1:28cc:dc4c:9703:6781? ([2406:e007:77ed:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id ks6sm3568219pbc.68.2015.04.01.20.49.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 20:49:42 -0700 (PDT) Message-ID: <551CBC57.7090702@gmail.com> Date: Thu, 02 Apr 2015 16:49:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , joel jaeggli References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551C9EB9.6040200@bogus.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "int-ads@ietf.org" , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 03:49:45 -0000 On 02/04/2015 16:34, Fred Baker (fred) wrote: > My understanding, which could be wrong, is that the IESG has a long-sta= nding policy that a routing protocol needs to have two interoperable impl= ementations, written from the specification. It=E2=80=99s not about the S= DO or the specification (IS-IS anyone?), it=E2=80=99s about having proof = that the specification is in fact correct and implementable from, by havi= ng two or more parties do it. Formally, it's less rigid since RFC 4794, but the ADs have a lot of discr= etion. Brian From nobody Thu Apr 2 08:04:18 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF0B1B2CEA; Thu, 2 Apr 2015 08:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 NFHH1I5fHtVv; Thu, 2 Apr 2015 08:04:15 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 CA5B01B2CE4; Thu, 2 Apr 2015 08:04:11 -0700 (PDT) Received: by obbec2 with SMTP id ec2so132103422obb.3; Thu, 02 Apr 2015 08:04: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:date:message-id:subject:from:to :cc:content-type; bh=HqFHZkG5VRA2EeHFAX52Ho0yDw7v8ojf2Onc+U2sL0U=; b=IG75Ryp5Njjvr1YXXwC6B/Jahdvac74V2jr1zTg/38lstnRoXeeHpNEVyfAkcTnLnN 2HkHcaOfIzP4dJ6wwK2CRiG4vByyb0wXCGiPKNJdnxftuo/xHw17bHoPPQC0lHCwvN7u 3OzslIVD27OtPzT1BgyXi2FCy+vZHAPSv0jj/cXbs3YUeXUNW8ecrrepo3xy7TSYHN3s vPvvijSa6V0FHS00W9FAME9piMp/l6hslqs3g7qyPfFFusVEPukpGs82oqqNrT/uDjHJ oCx1tGqhsAPXESQrozoq3GAa8E2CilpzyAVwh5Eo2A3Z6VVAGI1/HyEMktXtLxL7fMe0 FJnQ== MIME-Version: 1.0 X-Received: by 10.182.255.231 with SMTP id at7mr31020134obd.20.1427987047307; Thu, 02 Apr 2015 08:04:07 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Thu, 2 Apr 2015 08:04:07 -0700 (PDT) In-Reply-To: <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 2 Apr 2015 11:04:07 -0400 Message-ID: From: Alia Atlas To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=001a1134aaaeb2dfd80512bf24cd Archived-At: Cc: "int-ads@ietf.org" , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:04:17 -0000 --001a1134aaaeb2dfd80512bf24cd Content-Type: text/plain; charset=UTF-8 Juliusz, On Tue, Mar 31, 2015 at 6:08 PM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > > As I said in the meeting, my concern is not because of the process > > requirements - but because of the experience and improvements found > during > > the standardization and interoperability process. > > This makes sense, and I'm quite open to discussing that in Prague. > > However, I'd like to attract your attention on one set of data: > > - OSPFv2 is 244 pages, OSPFv3 adds 92 pages; > - OLSRv2 is 144+60+14 = 218 pages (including dependencies); > - RPL is 157 pages, and it's badly underspecified (grep for > "implementation" and try not to cry). > > On the other hand > > - Babel 45+10 = 55 pages (including the extension mechanism). > Perhaps you are familiar with the old joke "I'm sorry this is so long. I didn't have time to make it shorter." ? > The current version of Babel is version 2. It has been much simplified > since versions 0 and 1 -- there's almost nothing left to remove from this > protocol. With one minor exception, all of the mechanisms in RFC 6126 are > used by the implementation, and are necessary for correctness. > > In the light of the above figures -- can I trust an IETF working group to > understand that a huge amount of effort has been put into removing > mechanisms from this protocol, and to respect that work? Yes, I think that the requirement for minimal mechanisms and a simple easy to implement and troubleshoot protocol can be clearly expressed. How well the WG handles this depends in part on the WG chairs and how strongly the participants are reminded of that requirement and how stringently the need for truly active consensus is focused on. Regards, Alia > -- Juliusz > --001a1134aaaeb2dfd80512bf24cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juliusz,

On Tue, Mar 31, 2015 at 6:08 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
> As I said in the meeting, my concern = is not because of the process
> requirements - but because of the experience and improvements found du= ring
> the standardization and interoperability process.

This makes sense, and I'm quite open to discussing that in Pragu= e.

However, I'd like to attract your attention on one set of data:

=C2=A0 - OSPFv2 is 244 pages, OSPFv3 adds 92 pages;
=C2=A0 - OLSRv2 is 144+60+14 =3D 218 pages (including dependencies);
=C2=A0 - RPL is 157 pages, and it's badly underspecified (grep for
=C2=A0 =C2=A0 "implementation" and try not to cry).

On the other hand

=C2=A0 - Babel 45+10 =3D 55 pages (including the extension mechanism).
<= /blockquote>

Perhaps you are familiar with the old joke = "I'm sorry this is so long.=C2=A0 I didn't have time to make
it shorter." ? =C2=A0
=C2=A0
The current version of Babel is version 2.=C2=A0 It has been much simplifie= d
since versions 0 and 1 -- there's almost nothing left to remove from th= is
protocol.=C2=A0 With one minor exception, all of the mechanisms in RFC 6126= are
used by the implementation, and are necessary for correctness.

In the light of the above figures -- can I trust an IETF working group to understand that a huge amount of effort has been put into removing
mechanisms from this protocol, and to respect that work?
<= br>
Yes, I think that the requirement for minimal mechanisms and = a simple
easy to implement and troubleshoot protocol can be clear= ly expressed.=C2=A0 How
well the WG handles this depends in part = on the WG chairs and how strongly
the participants are reminded o= f that requirement and how stringently the need
for truly active = consensus is focused on.=C2=A0

Regards,
= Alia

=C2=A0
-- Juliusz

--001a1134aaaeb2dfd80512bf24cd-- From nobody Thu Apr 2 10:38:02 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD341A01E7; Thu, 2 Apr 2015 10:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 t08j-7xqyxII; Thu, 2 Apr 2015 10:37:58 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3281B2D64; Thu, 2 Apr 2015 10:37:57 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,512,1422939600"; d="scan'208,217";a="848694861" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 02 Apr 2015 13:24:08 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 2 Apr 2015 13:37:56 -0400 From: "George, Wes" To: Juliusz Chroboczek , "homenet@ietf.org" Date: Thu, 2 Apr 2015 13:37:55 -0400 Thread-Topic: [homenet] Selecting a routing protocol for HOMENET Thread-Index: AdBta8C03x52ARfeRFW515O8wXGNDw== Message-ID: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D142EA094BE82wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "int-ads@ietf.org" Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 17:38:00 -0000 --_000_D142EA094BE82wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdt YWlsLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgQXByaWwgMiwgMjAxNSBhdCAxMTowNCBBTQ0KVG86 IEp1bGl1c3ogQ2hyb2JvY3playA8amNoQHBwcy51bml2LXBhcmlzLWRpZGVyb3QuZnI8bWFpbHRv OmpjaEBwcHMudW5pdi1wYXJpcy1kaWRlcm90LmZyPj4NCkNjOiAiaW50LWFkc0BpZXRmLm9yZzxt YWlsdG86aW50LWFkc0BpZXRmLm9yZz4iIDxpbnQtYWRzQGlldGYub3JnPG1haWx0bzppbnQtYWRz QGlldGYub3JnPj4sICJydGctYWRzQGlldGYub3JnPG1haWx0bzpydGctYWRzQGlldGYub3JnPiIg PHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+PiwgTWFyZ2FyZXQgV2Fz c2VybWFuIDxtYXJnYXJldHc0MkBnbWFpbC5jb208bWFpbHRvOm1hcmdhcmV0dzQyQGdtYWlsLmNv bT4+LCBEYXZlIFRhaHQgPGRhdmUudGFodEBnbWFpbC5jb208bWFpbHRvOmRhdmUudGFodEBnbWFp bC5jb20+PiwgUmF5IEJlbGxpcyA8UmF5LkJlbGxpc0Bub21pbmV0Lm9yZy51azxtYWlsdG86UmF5 LkJlbGxpc0Bub21pbmV0Lm9yZy51az4+LCAiaG9tZW5ldEBpZXRmLm9yZzxtYWlsdG86aG9tZW5l dEBpZXRmLm9yZz4iIDxob21lbmV0QGlldGYub3JnPG1haWx0bzpob21lbmV0QGlldGYub3JnPj4s ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tPj4sIFRlcnJ5IE1hbmRlcnNvbiA8dGVycnkubWFuZGVyc29uQGljYW5uLm9yZzxt YWlsdG86dGVycnkubWFuZGVyc29uQGljYW5uLm9yZz4+DQpTdWJqZWN0OiBSZTogW2hvbWVuZXRd IFNlbGVjdGluZyBhIHJvdXRpbmcgcHJvdG9jb2wgZm9yIEhPTUVORVQNCg0KIC0tIHRoZXJlJ3Mg YWxtb3N0IG5vdGhpbmcgbGVmdCB0byByZW1vdmUgZnJvbSB0aGlzDQpwcm90b2NvbC4gIFdpdGgg b25lIG1pbm9yIGV4Y2VwdGlvbiwgYWxsIG9mIHRoZSBtZWNoYW5pc21zIGluIFJGQyA2MTI2IGFy ZQ0KdXNlZCBieSB0aGUgaW1wbGVtZW50YXRpb24sIGFuZCBhcmUgbmVjZXNzYXJ5IGZvciBjb3Jy ZWN0bmVzcy4NCg0KSW4gdGhlIGxpZ2h0IG9mIHRoZSBhYm92ZSBmaWd1cmVzIC0tIGNhbiBJIHRy dXN0IGFuIElFVEYgd29ya2luZyBncm91cCB0bw0KdW5kZXJzdGFuZCB0aGF0IGEgaHVnZSBhbW91 bnQgb2YgZWZmb3J0IGhhcyBiZWVuIHB1dCBpbnRvIHJlbW92aW5nDQptZWNoYW5pc21zIGZyb20g dGhpcyBwcm90b2NvbCwgYW5kIHRvIHJlc3BlY3QgdGhhdCB3b3JrPw0KDQpZZXMsIEkgdGhpbmsg dGhhdCB0aGUgcmVxdWlyZW1lbnQgZm9yIG1pbmltYWwgbWVjaGFuaXNtcyBhbmQgYSBzaW1wbGUN CmVhc3kgdG8gaW1wbGVtZW50IGFuZCB0cm91Ymxlc2hvb3QgcHJvdG9jb2wgY2FuIGJlIGNsZWFy bHkgZXhwcmVzc2VkLiAgSG93DQp3ZWxsIHRoZSBXRyBoYW5kbGVzIHRoaXMgZGVwZW5kcyBpbiBw YXJ0IG9uIHRoZSBXRyBjaGFpcnMgYW5kIGhvdyBzdHJvbmdseQ0KdGhlIHBhcnRpY2lwYW50cyBh cmUgcmVtaW5kZWQgb2YgdGhhdCByZXF1aXJlbWVudCBhbmQgaG93IHN0cmluZ2VudGx5IHRoZSBu ZWVkDQpmb3IgdHJ1bHkgYWN0aXZlIGNvbnNlbnN1cyBpcyBmb2N1c2VkIG9uLg0KDQpXR10gQWxz byB3b3J0aCBub3RpbmcgdGhhdCB0aG9zZSBvZiB1cyBzdWdnZXN0aW5nIHRoYXQgQmFiZWwgbW92 ZSBmcm9tIGV4cGVyaW1lbnRhbC9pbmRpdmlkdWFsIHRvIElFVEYgY29uc2Vuc3VzIHN0YW5kYXJk IGFyZSBub3Qgc3VnZ2VzdGluZyB0aGlzIGJlY2F1c2Ugd2UgYmVsaWV2ZSB0aGF0IHRoZSBkZXNp Z24gaXMgZmxhd2VkIGFuZCBuZWVkcyBJRVRGIHRvIGZpeCBpdC4gUmF0aGVyLCB3ZSdyZSBzdWdn ZXN0aW5nIHRoYXQgaXQncyBnb29kIHRvIGhhdmUgYWRkaXRpb25hbCBzY3J1dGlueSBhbmQgY29u c2Vuc3VzIGJlaGluZCB5b3VyIGRlc2lnbiBjaG9pY2VzIG9uIGEgbWFuZGF0b3J5LXRvLWltcGxl bWVudCBwcm90b2NvbCB0aGF0IHdpbGwgbGl2ZSBvbiBkZXZpY2VzIHRoYXQgYXJlIG5vdG9yaW91 cyBmb3Igbm90IGdldHRpbmcgY29uc2lzdGVudCBzb2Z0d2FyZSB1cGRhdGVzLiBJIHZpZXcgYSBX RyB0aGF0IG1ha2VzIGNoYW5nZXMgdG8gYW4gZXhpc3RpbmcgcHJvdG9jb2wgZm9yIHRoZSBzYWtl IG9mIGNoYW5nZXMgb3IgdG8gIm1hcmsgdGhlaXIgdGVycml0b3J5IiBhcyBkb2luZyBpdCB3cm9u ZywgYW5kIEkgdGhpbmsgbW9zdCBXRyBjaGFpcnMgYXJlIGdvb2QgYXQgbWFraW5nIHN1cmUgdGhh dCBjaGFuZ2VzIGFyZSBqdXN0aWZpZWQuIFlvdeKAmXZlIG9idmlvdXNseSBzcGVudCBhIGxvdCBv ZiB0aW1lIHRoaW5raW5nIGFib3V0IHlvdXIgZGVzaWduIGNob2ljZXMgYW5kIHJlZmluaW5nIHRo ZSBkZXNpZ24uIEFzIHRvIHRoZSBxdWVzdGlvbiBvZiB0aGUgV0cgcmVzcGVjdGluZyB0aGF0IHdv cmssIHRoYXQncyB1bmxpa2VseSB0byBoYXBwZW4gb24gYXNzZXJ0aW9uIGFsb25lLiBJZiB0aGUg cmF0aW9uYWxlIGlzbid0IGluIHRoZSBSRkMsIHlvdSBzaG91bGQgYmUgcHJlcGFyZWQgdG8gaGF2 ZSB0aG9zZSBjaG9pY2VzIHF1ZXN0aW9uZWQgYnkgd2VsbC1tZWFuaW5nIGZvbGtzIGluIHRoZSBJ RVRGLCBidXQgaXQgc2hvdWxkbid0IGJlIGhhcmQgdG8gZGVmZW5kIHRoZW0gaWYgdGhleSBhcmUg aW5kZWVkIHRoZSBiZXN0IGNob2ljZSBmb3IgdGhlIGdvYWxzIG9mIHRoZSBwcm90b2NvbCwgZXNw ZWNpYWxseSB3aXRoIHRoZSB3ZWlnaHQgb2YgcnVubmluZyBjb2RlIGJlaGluZCB0aGVtLiBKdXN0 IGRvbid0IHRha2UgdGhvc2Ugc29ydHMgb2YgcXVlc3Rpb25zIHBlcnNvbmFsbHksIG9yIHRoaXMg d2lsbCBiZSBhIGxvdCBsZXNzIHBsZWFzYW50IGZvciBldmVyeW9uZS4NCg0KVGhhbmtzLA0KDQpX ZXMgR2VvcmdlDQoNCkFueXRoaW5nIGJlbG93IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBt eSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSSBoYXZlIG5vIGNvbnRyb2wgb3ZlciBpdC4NCi0t LS0tLS0tLS0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJs ZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50 aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2Fi bGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9y IGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1l bnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxh d2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== --_000_D142EA094BE82wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgQXByaWwg MiwgMjAxNSBhdCAxMTowNCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPkp1bGl1c3ogQ2hyb2JvY3playAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpjaEBwcHMu dW5pdi1wYXJpcy1kaWRlcm90LmZyIj5qY2hAcHBzLnVuaXYtcGFyaXMtZGlkZXJvdC5mcjwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmludC1hZHNAaWV0Zi5vcmciPmludC1hZHNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aW50LWFkc0BpZXRmLm9yZyI+aW50LWFkc0BpZXRmLm9y ZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFk c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGctYWRzQGlldGYub3Jn Ij5ydGctYWRzQGlldGYub3JnPC9hPiZndDssDQogTWFyZ2FyZXQgV2Fzc2VybWFuICZsdDs8YSBo cmVmPSJtYWlsdG86bWFyZ2FyZXR3NDJAZ21haWwuY29tIj5tYXJnYXJldHc0MkBnbWFpbC5jb208 L2E+Jmd0OywgRGF2ZSBUYWh0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2ZS50YWh0QGdtYWlsLmNv bSI+ZGF2ZS50YWh0QGdtYWlsLmNvbTwvYT4mZ3Q7LCBSYXkgQmVsbGlzICZsdDs8YSBocmVmPSJt YWlsdG86UmF5LkJlbGxpc0Bub21pbmV0Lm9yZy51ayI+UmF5LkJlbGxpc0Bub21pbmV0Lm9yZy51 azwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aG9tZW5ldEBpZXRmLm9yZyI+aG9tZW5l dEBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvbWVuZXRAaWV0Zi5v cmciPmhvbWVuZXRAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJu LmNvbTwvYT4mZ3Q7LCBUZXJyeSBNYW5kZXJzb24gJmx0OzxhIGhyZWY9Im1haWx0bzp0ZXJyeS5t YW5kZXJzb25AaWNhbm4ub3JnIj50ZXJyeS5tYW5kZXJzb25AaWNhbm4ub3JnPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbaG9t ZW5ldF0gU2VsZWN0aW5nIGEgcm91dGluZyBwcm90b2NvbCBmb3IgSE9NRU5FVDxicj4NCjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxf ZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQombmJzcDstLSB0aGVyZSdzIGFsbW9zdCBub3RoaW5n IGxlZnQgdG8gcmVtb3ZlIGZyb20gdGhpczxicj4NCnByb3RvY29sLiZuYnNwOyBXaXRoIG9uZSBt aW5vciBleGNlcHRpb24sIGFsbCBvZiB0aGUgbWVjaGFuaXNtcyBpbiBSRkMgNjEyNiBhcmU8YnI+ DQp1c2VkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbiwgYW5kIGFyZSBuZWNlc3NhcnkgZm9yIGNvcnJl Y3RuZXNzLjxicj4NCjxicj4NCkluIHRoZSBsaWdodCBvZiB0aGUgYWJvdmUgZmlndXJlcyAtLSBj YW4gSSB0cnVzdCBhbiBJRVRGIHdvcmtpbmcgZ3JvdXAgdG88YnI+DQp1bmRlcnN0YW5kIHRoYXQg YSBodWdlIGFtb3VudCBvZiBlZmZvcnQgaGFzIGJlZW4gcHV0IGludG8gcmVtb3Zpbmc8YnI+DQpt ZWNoYW5pc21zIGZyb20gdGhpcyBwcm90b2NvbCwgYW5kIHRvIHJlc3BlY3QgdGhhdCB3b3JrPzwv YmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlllcywgSSB0aGluayB0aGF0IHRo ZSByZXF1aXJlbWVudCBmb3IgbWluaW1hbCBtZWNoYW5pc21zIGFuZCBhIHNpbXBsZTwvZGl2Pg0K PGRpdj5lYXN5IHRvIGltcGxlbWVudCBhbmQgdHJvdWJsZXNob290IHByb3RvY29sIGNhbiBiZSBj bGVhcmx5IGV4cHJlc3NlZC4mbmJzcDsgSG93PC9kaXY+DQo8ZGl2PndlbGwgdGhlIFdHIGhhbmRs ZXMgdGhpcyBkZXBlbmRzIGluIHBhcnQgb24gdGhlIFdHIGNoYWlycyBhbmQgaG93IHN0cm9uZ2x5 PC9kaXY+DQo8ZGl2PnRoZSBwYXJ0aWNpcGFudHMgYXJlIHJlbWluZGVkIG9mIHRoYXQgcmVxdWly ZW1lbnQgYW5kIGhvdyBzdHJpbmdlbnRseSB0aGUgbmVlZDwvZGl2Pg0KPGRpdj5mb3IgdHJ1bHkg YWN0aXZlIGNvbnNlbnN1cyBpcyBmb2N1c2VkIG9uLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+V0ddIEFsc28gd29ydGggbm90aW5nIHRoYXQgdGhvc2Ugb2YgdXMgc3VnZ2Vz dGluZyB0aGF0IEJhYmVsIG1vdmUgZnJvbSBleHBlcmltZW50YWwvaW5kaXZpZHVhbCB0byBJRVRG IGNvbnNlbnN1cyBzdGFuZGFyZCBhcmUgbm90IHN1Z2dlc3RpbmcgdGhpcyBiZWNhdXNlIHdlIGJl bGlldmUgdGhhdCB0aGUgZGVzaWduIGlzIGZsYXdlZCBhbmQgbmVlZHMgSUVURiB0byBmaXggaXQu IFJhdGhlciwgd2UncmUgc3VnZ2VzdGluZyB0aGF0IGl0J3MNCiBnb29kIHRvIGhhdmUgYWRkaXRp b25hbCBzY3J1dGlueSBhbmQgY29uc2Vuc3VzIGJlaGluZCB5b3VyIGRlc2lnbiBjaG9pY2VzIG9u IGEgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBwcm90b2NvbCB0aGF0IHdpbGwgbGl2ZSBvbiBkZXZp Y2VzIHRoYXQgYXJlIG5vdG9yaW91cyBmb3Igbm90IGdldHRpbmcgY29uc2lzdGVudCBzb2Z0d2Fy ZSB1cGRhdGVzLiBJIHZpZXcgYSBXRyB0aGF0IG1ha2VzIGNoYW5nZXMgdG8gYW4gZXhpc3Rpbmcg cHJvdG9jb2wNCiBmb3IgdGhlIHNha2Ugb2YgY2hhbmdlcyBvciB0byAmcXVvdDttYXJrIHRoZWly IHRlcnJpdG9yeSZxdW90OyBhcyBkb2luZyBpdCB3cm9uZywgYW5kIEkgdGhpbmsgbW9zdCBXRyBj aGFpcnMgYXJlIGdvb2QgYXQgbWFraW5nIHN1cmUgdGhhdCBjaGFuZ2VzIGFyZSBqdXN0aWZpZWQu IFlvdeKAmXZlIG9idmlvdXNseSBzcGVudCBhIGxvdCBvZiB0aW1lIHRoaW5raW5nIGFib3V0IHlv dXIgZGVzaWduIGNob2ljZXMgYW5kIHJlZmluaW5nIHRoZSBkZXNpZ24uIEFzIHRvIHRoZQ0KIHF1 ZXN0aW9uIG9mIHRoZSBXRyByZXNwZWN0aW5nIHRoYXQgd29yaywgdGhhdCdzIHVubGlrZWx5IHRv IGhhcHBlbiBvbiBhc3NlcnRpb24gYWxvbmUuIElmIHRoZSByYXRpb25hbGUgaXNuJ3QgaW4gdGhl IFJGQywgeW91IHNob3VsZCBiZSBwcmVwYXJlZCB0byBoYXZlIHRob3NlIGNob2ljZXMgcXVlc3Rp b25lZCBieSB3ZWxsLW1lYW5pbmcgZm9sa3MgaW4gdGhlIElFVEYsIGJ1dCBpdCBzaG91bGRuJ3Qg YmUgaGFyZCB0byBkZWZlbmQgdGhlbSBpZg0KIHRoZXkgYXJlIGluZGVlZCB0aGUgYmVzdCBjaG9p Y2UgZm9yIHRoZSBnb2FscyBvZiB0aGUgcHJvdG9jb2wsIGVzcGVjaWFsbHkgd2l0aCB0aGUgd2Vp Z2h0IG9mIHJ1bm5pbmcgY29kZSBiZWhpbmQgdGhlbS4gSnVzdCBkb24ndCB0YWtlIHRob3NlIHNv cnRzIG9mIHF1ZXN0aW9ucyBwZXJzb25hbGx5LCBvciB0aGlzIHdpbGwgYmUgYSBsb3QgbGVzcyBw bGVhc2FudCBmb3IgZXZlcnlvbmUuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+V2VzIEdlb3JnZTxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7Ij4m bmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PGJyPg0KPC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTI3LCAxMjcsIDEyNyk7Ij5Bbnl0aGluZyBiZWxv dyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIs IEkgaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTI3LCAxMjcsIDEyNyk7Ij4tLS0tLS0t LS0tLTwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBj b2xvcj0iR3JheSIgc2l6ZT0iMSI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24s IHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZCBzb2xlbHkNCiBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvDQogdGhpcyBFLW1haWwgaXMg c3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBv ZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_D142EA094BE82wesleygeorgetwcablecom_-- From nobody Thu Apr 2 15:20:06 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092FE1A872C; Thu, 2 Apr 2015 15:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, SPF_PASS=-0.001] autolearn=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 pEq3R6GX27I8; Thu, 2 Apr 2015 15:20:03 -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 4AC401A8729; Thu, 2 Apr 2015 15:20:03 -0700 (PDT) Received: by qgdy78 with SMTP id y78so19753682qgd.0; Thu, 02 Apr 2015 15:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=f8IF5XDe8X07C0mWOpYteVVoxUkMJnhGriHtKbMbIUI=; b=kSeI4FG2l9IBfXqyWxQWFc59PK+6+SnnipJwRRRG4TyVLALpZnu0JNY7N9CdunxuBr nsGM5JAfhMQZEqHklYpoyVrWwtyL0MmkuRNTls0+VMlQ5EypKOj+VGCEaVbgRsw1dSxb 99a7MDxVcSQXzJLhhMBZhaxsKyc505Zvl+hAuQyUmUBucyiszEwGMRppqqeqoniG+Rmy lC2A0UME2WcIVB/zuCjVufN7FFUba45j1fLjliSqKKNHqFq2eC+v4og4B+Vr1PbiYXH9 Wcr9BC3LwapcbXCJ0zFXLyyrXxERtgzn+ACwJ2KbCIwU2atO1s82XQ60R/DMMZzAepeh VTEw== X-Received: by 10.140.17.50 with SMTP id 47mr60705689qgc.55.1428013202592; Thu, 02 Apr 2015 15:20:02 -0700 (PDT) Received: from ?IPv6:2601:6:3440:a00:d8d:382a:ffb3:54a3? ([2601:6:3440:a00:d8d:382a:ffb3:54a3]) by mx.google.com with ESMTPSA id g64sm4402718qkh.18.2015.04.02.15.20.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 15:20:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA493911-4D4D-4063-9968-2C9BC4FAB81F" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Margaret Wasserman In-Reply-To: Date: Thu, 2 Apr 2015 18:20:03 -0400 Message-Id: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> To: Alia Atlas X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 22:20:05 -0000 --Apple-Mail=_EA493911-4D4D-4063-9968-2C9BC4FAB81F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think we could come closer to this by forming a Babel-specific WG that = is chartered to take the current Babel documents as a starting point and = only change them by consensus of the WG to meet IETF standards-track = requirements and fix any technical holes, than we will if we form a more = generic WG. if we start a generic DVRP WG, then we are likely to have = multiple candidate specs, and people will be looking to combine specs by = compromising and merging the features of different specifications into a = single document, so that there will be one document with enough = followers to gain consensus. I suspect that what emerges from that sort = of process might not be recognizably Babel. Margaret On Apr 2, 2015, at 11:04 AM, Alia Atlas wrote: > Juliusz, >=20 > On Tue, Mar 31, 2015 at 6:08 PM, Juliusz Chroboczek = wrote: > > As I said in the meeting, my concern is not because of the process > > requirements - but because of the experience and improvements found = during > > the standardization and interoperability process. >=20 > This makes sense, and I'm quite open to discussing that in Prague. >=20 > However, I'd like to attract your attention on one set of data: >=20 > - OSPFv2 is 244 pages, OSPFv3 adds 92 pages; > - OLSRv2 is 144+60+14 =3D 218 pages (including dependencies); > - RPL is 157 pages, and it's badly underspecified (grep for > "implementation" and try not to cry). >=20 > On the other hand >=20 > - Babel 45+10 =3D 55 pages (including the extension mechanism). >=20 > Perhaps you are familiar with the old joke "I'm sorry this is so long. = I didn't have time to make > it shorter." ? =20 > =20 > The current version of Babel is version 2. It has been much = simplified > since versions 0 and 1 -- there's almost nothing left to remove from = this > protocol. With one minor exception, all of the mechanisms in RFC 6126 = are > used by the implementation, and are necessary for correctness. >=20 > In the light of the above figures -- can I trust an IETF working group = to > understand that a huge amount of effort has been put into removing > mechanisms from this protocol, and to respect that work? >=20 > Yes, I think that the requirement for minimal mechanisms and a simple > easy to implement and troubleshoot protocol can be clearly expressed. = How > well the WG handles this depends in part on the WG chairs and how = strongly > the participants are reminded of that requirement and how stringently = the need > for truly active consensus is focused on.=20 >=20 > Regards, > Alia >=20 > =20 > -- Juliusz >=20 --Apple-Mail=_EA493911-4D4D-4063-9968-2C9BC4FAB81F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii akatlas@gmail.com> = wrote:

Juliusz,

On Tue, Mar 31, = 2015 at 6:08 PM, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> = wrote:
> = As I said in the meeting, my concern is not because of the process
> requirements - but because of the experience and improvements found = during
> the standardization and interoperability process.

This makes sense, and I'm quite open to discussing that in = Prague.

However, I'd like to attract your attention on one set of data:

  - OSPFv2 is 244 pages, OSPFv3 adds 92 pages;
  - OLSRv2 is 144+60+14 =3D 218 pages (including dependencies);
  - RPL is 157 pages, and it's badly underspecified (grep for
    "implementation" and try not to cry).

On the other hand

  - Babel 45+10 =3D 55 pages (including the extension = mechanism).

Perhaps you are familiar = with the old joke "I'm sorry this is so long.  I didn't have time = to make
it shorter." ? =  
 
The current version of Babel is version 2.  It has been much = simplified
since versions 0 and 1 -- there's almost nothing left to remove from = this
protocol.  With one minor exception, all of the mechanisms in RFC = 6126 are
used by the implementation, and are necessary for correctness.

In the light of the above figures -- can I trust an IETF working group = to
understand that a huge amount of effort has been put into removing
mechanisms from this protocol, and to respect that = work?

Yes, I think that the requirement = for minimal mechanisms and a simple
easy to implement and = troubleshoot protocol can be clearly expressed.  How
well = the WG handles this depends in part on the WG chairs and how = strongly
the participants are reminded of that requirement and = how stringently the need
for truly active consensus is focused = on. 

Regards,
Alia

<= /div>
 
-- Juliusz


= --Apple-Mail=_EA493911-4D4D-4063-9968-2C9BC4FAB81F-- From nobody Thu Apr 2 23:04:36 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BBC1A90D7; Thu, 2 Apr 2015 23:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 IdFms2uC243R; Thu, 2 Apr 2015 23:04:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722031A90CF; Thu, 2 Apr 2015 23:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10113; q=dns/txt; s=iport; t=1428041074; x=1429250674; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2I6ozs2CfiyCurTpxEnpk+UW3GggcrYx8iMoSuZhJnw=; b=JvG4tyq0Mje4kBf2TgaP/Ral9FsAHituTXvTnXSWH28+2H9qkG1rQS91 Ix2JMW/M88VIDCtvOvCa6Huessl+WmohgHIJRnpsAuJrVv6txudWCwOR2 TjMb5Vx7GvyrO91TlmVqqmrSbBnFTtZPvPsQVlEmuEEWFjGvrRKE6w3X4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B7CACELB5V/5FdJa1cgwtSXIUdvheCNgEJhS9OAoE4TAEBAQEBAX6EHgEBAQMBAQEBaQIIAwULAgEIGCcHIQYLFBECBA4FFIgHAwkIDcc4DYUyAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLKYJHgi4EB4MXgRYFhFeGGoNZgiCHfzSBTYEdhmyGE4Jng0gigVsoHIFQb4JDAQEB X-IronPort-AV: E=Sophos;i="5.11,516,1422921600"; d="scan'208,217";a="405786199" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 03 Apr 2015 06:04:33 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3364VTL029825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Apr 2015 06:04:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 3 Apr 2015 01:04:31 -0500 From: "Pascal Thubert (pthubert)" To: Margaret Wasserman Thread-Topic: [homenet] Selecting a routing protocol for HOMENET Thread-Index: AQHQbZMq3x52ARfeRFW515O8wXGND506zPI6 Date: Fri, 3 Apr 2015 06:04:30 +0000 Message-ID: <238BA46B-2D45-4D01-9283-A98B182BBF6D@cisco.com> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_238BA46B2D454D019283A98B182BBF6Dciscocom_" MIME-Version: 1.0 Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 06:04:35 -0000 --_000_238BA46B2D454D019283A98B182BBF6Dciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Certainly, Margaret... ... but then you have to differentiate the capability of any new proposed p= rotocol from what current IETF protocols already do to get that work charte= red. We are having an interesting chat on MANET and ROLL where the differences = (and core similarities) between BABEL and RPL are elaborated. For all I 've seen so far both protocols employ the same basic methods, and= yield the same capabilities though RPL is a lot more versatile - and a lot= less understood by the general community- outside LLNs. Though the discussion is still ongoing and we didn't reach any conclusion y= et, we are now at the gory details and the fundamentals are clearly the sam= e. I 'll note that RPL already addresses the problems the Margaret listed in D= allas, in with a proposed standard doc. The shortest time to Homenet is pro= bably to explain how to use RPL at home, and that probably requires only a = guideline informational document... Cheers, Pascal Le 3 avr. 2015 =E0 00:20, Margaret Wasserman > a =E9crit : I think we could come closer to this by forming a Babel-specific WG that is= chartered to take the current Babel documents as a starting point and only= change them by consensus of the WG to meet IETF standards-track requiremen= ts and fix any technical holes, than we will if we form a more generic WG. = if we start a generic DVRP WG, then we are likely to have multiple candid= ate specs, and people will be looking to combine specs by compromising and = merging the features of different specifications into a single document, so= that there will be one document with enough followers to gain consensus. = I suspect that what emerges from that sort of process might not be recogniz= ably Babel. Margaret On Apr 2, 2015, at 11:04 AM, Alia Atlas > wrote: Juliusz, On Tue, Mar 31, 2015 at 6:08 PM, Juliusz Chroboczek > wrote: > As I said in the meeting, my concern is not because of the process > requirements - but because of the experience and improvements found durin= g > the standardization and interoperability process. This makes sense, and I'm quite open to discussing that in Prague. However, I'd like to attract your attention on one set of data: - OSPFv2 is 244 pages, OSPFv3 adds 92 pages; - OLSRv2 is 144+60+14 =3D 218 pages (including dependencies); - RPL is 157 pages, and it's badly underspecified (grep for "implementation" and try not to cry). On the other hand - Babel 45+10 =3D 55 pages (including the extension mechanism). Perhaps you are familiar with the old joke "I'm sorry this is so long. I d= idn't have time to make it shorter." ? The current version of Babel is version 2. It has been much simplified since versions 0 and 1 -- there's almost nothing left to remove from this protocol. With one minor exception, all of the mechanisms in RFC 6126 are used by the implementation, and are necessary for correctness. In the light of the above figures -- can I trust an IETF working group to understand that a huge amount of effort has been put into removing mechanisms from this protocol, and to respect that work? Yes, I think that the requirement for minimal mechanisms and a simple easy to implement and troubleshoot protocol can be clearly expressed. How well the WG handles this depends in part on the WG chairs and how strongly the participants are reminded of that requirement and how stringently the n= eed for truly active consensus is focused on. Regards, Alia -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --_000_238BA46B2D454D019283A98B182BBF6Dciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Certainly, Margaret...

... but then you have to differentiate the capability of any new propo= sed protocol from what current IETF protocols already do to get that work c= hartered.

We are having an interesting chat on MANET and ROLL where the differen= ces  (and core similarities) between BABEL and RPL are elaborated.

For all I 've seen so far both protocols employ the same basic methods= , and yield the same capabilities though RPL is a lot more versatile - and = a lot less understood by the general community- outside LLNs.

Though the discussion is still ongoing and we didn't reach any conclus= ion yet, we are now at the gory details and the fundamentals are clearly th= e same. 

I 'll note that RPL already addresses the problems the Margaret listed= in Dallas, in with a proposed standard doc. The shortest time to Homenet i= s probably to explain how to use RPL at home, and that probably requires on= ly a guideline informational document...

Cheers,
Pascal

Le 3 avr. 2015 =E0 00:20, Margaret Wasserman <margaretw42@gmail.com> a =E9crit :


I think we could come closer to this by forming a Babel-specific WG that is= chartered to take the current Babel documents as a starting point and only= change them by consensus of the WG to meet IETF standards-track requiremen= ts and fix any technical holes, than we will if we form a more generic WG.   if we start a generic DV= RP WG, then we are likely to have multiple candidate specs, and people will= be looking to combine specs by compromising and merging the features of di= fferent specifications into a single document, so that there will be one document with enough followers to gain= consensus.  I suspect that what emerges from that sort of process mig= ht not be recognizably Babel.

Margaret

On Apr 2, 2015, at 11:04 AM, Alia Atlas <akatlas@gmail.com> wrote:

Juliusz,

On Tue, Mar 31, 2015 at 6:08 PM, Juliusz Chroboc= zek <jch@= pps.univ-paris-diderot.fr> wrote:
> As I said in the meeting, my concern is not because o= f the process
> requirements - but because of the experience and improvements found du= ring
> the standardization and interoperability process.

This makes sense, and I'm quite open to discussing that in Prague.
However, I'd like to attract your attention on one set of data:

  - OSPFv2 is 244 pages, OSPFv3 adds 92 pages;
  - OLSRv2 is 144+60+14 =3D 218 pages (including dependencies)= ;
  - RPL is 157 pages, and it's badly underspecified (grep for
    "implementation" and try not to cry).

On the other hand

  - Babel 45+10 =3D 55 pages (including the extension mechanism).<= br>

Perhaps you are familiar with the old joke "I'm sorry this is so = long.  I didn't have time to make
it shorter." ?  
 
The current version of Babel is version 2.  It has been much simplifie= d
since versions 0 and 1 -- there's almost nothing left to remove from this protocol.  With one minor exception, all of the mechanisms in RFC 6126= are
used by the implementation, and are necessary for correctness.

In the light of the above figures -- can I trust an IETF working group to understand that a huge amount of effort has been put into removing
mechanisms from this protocol, and to respect that work?

Yes, I think that the requirement for minimal mechanisms and a simple<= /div>
easy to implement and troubleshoot protocol can be clearly expressed.&= nbsp; How
well the WG handles this depends in part on the WG chairs and how stro= ngly
the participants are reminded of that requirement and how stringently = the need
for truly active consensus is focused on. 

Regards,
Alia

 
-- Juliusz


_______________________________________________
homenet mailing list
homenet@ietf.org
https://www= .ietf.org/mailman/listinfo/homenet
--_000_238BA46B2D454D019283A98B182BBF6Dciscocom_-- From nobody Thu Apr 2 23:20:47 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9911A90F4 for ; Thu, 2 Apr 2015 23:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 BvwjYMOyx9WY for ; Thu, 2 Apr 2015 23:20:44 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 736471A90EE for ; Thu, 2 Apr 2015 23:20:44 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so78332678ieb.0 for ; Thu, 02 Apr 2015 23:20:44 -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:content-type; bh=w0DACBxKasMBLoe3KLBx+g+1VfXnh7jiOPUxCcFryQ4=; b=cPV+fgWScCo+bFao/PxLigHMjqFZErMRSEwre7Ta/QFCJH780DStlA1TPyiR/3kowV leJqNxY17G/UDde0L9rEL1YPI1QgZl/uA54TdDotf09gUbm8v+O6SzVAbIF3Ch2RuMj+ R01nB6TDI2Nl2+vd5AC0/20kkf8xw83SGHOZz0jUCvLuhbEqG0qE7lzr6DjiU95e7Cq1 tHh7senSv80UThIV1xqeUE38NsXJi+TQf5GS9J9C+kJVWDkU6UkTADU/ZXpp7DcrMzN9 3ekb7I4MWlLn87eef4e+3T9pqxu0ieEu9FbvNyDj32QtWLNJnXeWUtN7dbByQp5Gmtbk WMRg== 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-type; bh=w0DACBxKasMBLoe3KLBx+g+1VfXnh7jiOPUxCcFryQ4=; b=J87vLeM39ID3LNiJum7ZnckxRRSnij3wA58sdBKmSL5cm28zPBvl2TjZgzqGkzNCgH 1fi/Eut7cDWw44VZXezgXnlrvAXrKnS1/XSMgW5yRHer0F/+mkl8QEjSTcPHVca8CdAr zOWdsLrqcD4z0goU6aVOrU5m8x4HV5ObEpgc+zhJ3KborvhSS/fCbnhquKEoXjKsjkH8 EzTUuUABpc3wy0Cs3FytAWDJr/rkYW2K3vBXw+Eb4q8H/dnAJNJG8scrXDCPk6ClnsSW V/iGEUfL8lRdgOfQC/Hd/a8FOizip+1WbDBt9BqFnlRWdoZhYJKOTnIaQl/TiVIhX1c7 SCHQ== X-Gm-Message-State: ALoCoQnelElbeqnKF79TWTRKLiw6GvJaqT9BemTNFbxTvYUfudOUAN/h/xN+n1/yfI8Rx2+cDG56 X-Received: by 10.50.39.65 with SMTP id n1mr25767149igk.37.1428042043882; Thu, 02 Apr 2015 23:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Thu, 2 Apr 2015 23:20:23 -0700 (PDT) In-Reply-To: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Fri, 3 Apr 2015 15:20:23 +0900 Message-ID: To: Margaret Wasserman Content-Type: multipart/alternative; boundary=047d7bdc1438c023cb0512cbf244 Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 06:20:45 -0000 --047d7bdc1438c023cb0512cbf244 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 7:20 AM, Margaret Wasserman wrote: > I think we could come closer to this by forming a Babel-specific WG that > is chartered to take the current Babel documents as a starting point and > only change them by consensus of the WG to meet IETF standards-track > requirements and fix any technical holes, than we will if we form a more > generic WG. > Absolutely. > if we start a generic DVRP WG, then we are likely to have multiple > candidate specs, and people will be looking to combine specs by > compromising and merging the features of different specifications into a > single document, so that there will be one document with enough followers > to gain consensus. I suspect that what emerges from that sort of process > might not be recognizably Babel. > More to the point, that sort of process will likely result in nothing emerging at all. There are two discussions happening at the moment. One is what routing protocol should be chosen for homenet, and the proposed deadline for concluding that discussion is "before Prague". The other is around standardizing babel. That can proceed in parallel. We should not block either discussion on considering yet more routing protocols. --047d7bdc1438c023cb0512cbf244 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 7:20 AM, Margaret Wasserman <margaretw42@gmail.com<= /a>> wrote:
I think we could come closer to this by forming a Bab= el-specific WG that is chartered to take the current Babel documents as a s= tarting point and only change them by consensus of the WG to meet IETF stan= dards-track requirements and fix any technical holes, than we will if we fo= rm a more generic WG.

Absolutel= y.
=C2=A0
=C2=A0 if we start a generic DVRP WG, then we are li= kely to have multiple candidate specs, and people will be looking to combin= e specs by compromising and merging the features of different specification= s into a single document, so that there will be one document with enough fo= llowers to gain consensus.=C2=A0 I suspect that what emerges from that sort= of process might not be recognizably Babel.
<= br>
More to the point, that sort of process will likely result in= nothing emerging at all. There are two discussions happening at the moment= . One is what routing protocol should be chosen for homenet, and the propos= ed deadline for concluding that discussion is "before Prague". Th= e other is around standardizing babel. That can proceed in parallel.
<= div>
--047d7bdc1438c023cb0512cbf244-- From nobody Fri Apr 3 00:28:36 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32111A9162 for ; Fri, 3 Apr 2015 00:28: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8ZPd94CZs8aE for ; Fri, 3 Apr 2015 00:28:32 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (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 28CD71A9145 for ; Fri, 3 Apr 2015 00:28:31 -0700 (PDT) Received: by widjs5 with SMTP id js5so22317109wid.1 for ; Fri, 03 Apr 2015 00:28:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=lHYKKCxXuxZ7Gy83vKsl722V2nWR1hkW9D6BQxUgdKM=; b=jmNoDMeoXjLKT2un0mXKVxQ1FodmmeI9UcMwHsXe3IcDesLV20I2Pl5+xPAVNL1qD6 yWtRn3nnffi2/drrofQXAYs8WfASmuRJHXP2s7QgXEWdruQaD3HJ6RsJ1hzL37vLHXSC PjSrtFANiSU52XcUB3haMi6Rwm0TSNf/bq4kdHkpieDqHyXKQBSGqkuZ4TxfwKGArmVl onqD9Gh4s4KAgLMwalTCZlc/2dodDIb6m8vrJtads6DeWtsr/bsxWJiNT7EPb6+x9pPu yjLZ5VcKNaEEhdiw+fDZWuu1B7edswz89BwtP505/SVxZsbIEDLP2wIpYJNXy4hRljSC 5lbQ== X-Gm-Message-State: ALoCoQnRmbMA+E1+nwCi98Gmci0yNwTPfdpBnxEgO42t4fyVHk30OCxWR+z3t80tfS4oxLwuoPZG X-Received: by 10.180.88.169 with SMTP id bh9mr18860715wib.6.1428046110495; Fri, 03 Apr 2015 00:28:30 -0700 (PDT) Received: from [192.168.178.24] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPSA id ka1sm10370604wjc.2.2015.04.03.00.28.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 00:28:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Teco Boot In-Reply-To: Date: Fri, 3 Apr 2015 09:28:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AEC5D75-05CC-47A5-9BD0-2625528BBABE@inf-net.nl> References: To: Terry Manderson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtg-ads@ietf.org" , "homenet@ietf.org" , "int-ads@ietf.org" Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 07:28:35 -0000 Please let me repeat myself, by asking the DT that WiFi clients with=20 IEEE802.11r (fast BSS transition) are supported in the homenet. The=20 requirement is in RFC 7368. The DT could say: we have RFC 5415/5416 and someone shall bring=20 in a WLC, or, add an SDN layer in the homenet. This might not happen. The alternative would be MAC layer routing (a.k. bridging). This is brought up several times, by several people. People which IMO understand home WiFi problems and know how to fix them. I do not say I prefer ISIS/TRILL or ISIS/RFC6329/IEEE802.1aq=20 over Babel. What I say is that selection based on number of pages=20 of an RFC, number of lines of code will result in nothing. It is=20 about problems to fix with a good engineering effort. =20 I know this SPB technology seems to be overkill and is less an IP layer routing beast. But a well performing homenet with multiple WiFi APs cannot without.=20 BTW: 802.11r without central controller needs a config distribution=20 protocol. We could provide that. May I ask for having 802.11 experts in the DT? =20 Teco > Op 31 mrt. 2015, om 17:12 heeft Terry Manderson = het volgende geschreven: >=20 > WG, >=20 > I have reviewed all of the emails on this topic. >=20 > My assessment is that no-one spoke specifically against (nor for!) the > design team to select the mandatory to implement routing protocol for > homenet. There was, however, some constructive discussion about the = design > team charter, along with some advice for the design team to consider. >=20 > I have the sense that folks were waiting for charter word-smithing to = be > completed prior to accepting/supporting the design team and ultimately = its > determination. There simply wasn't enough positive nor negative = responses > to gauge consensus. >=20 >=20 > I have updated the charter as follows which folds in the substantive > comments from Lorenzo and Brian. >=20 > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > Homenet's architecture (RFC 7368) articulates the general features > required. The working group has agreed that a single routing protocol > must be identified as mandatory to implement. The final purpose of > this design team is to select and present a single routing protocol > with a summary of the necessary extensions and work to be the one that > is mandatory to implement. Once the design team has made its > recommendation, the working group will consider any substantial > technical objections (see RFC 7282) as part of gaining consensus. >=20 > For the design team to make this determination, it shall first > understand the use-cases for homenet and derive routing requirements > from those. Then it shall compare these routing requirements to > candidate routing protocols and examine the gaps in each. For each > highly plausible candidate routing protocol, the design team will > estimate the work and actions needed, the resources at hand > or reasonably available, and the associated timeline to get > an acceptable, full, standardized solution using each protocol. > Based upon this information and the perceived market timing > needs of the technology, the design team will make its selection. > The requirements, gaps, and reasoning will be documented. >=20 > This document should be delivered by the July 2015 IETF. >=20 > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > So with no more emails on the thread, I'm marking the above as the = final > design team charter and I now ask the WG to comment by midnight Friday = the > 3rd April (UTC) of either accepting the design team, or not. I will = judge > consensus at that point, remembering that silence doesn't help. >=20 >=20 > Pending consensus, and at the appropriate time I will direct the = design > team to read the advice from Steven, Alexandru, and James posted here = for > their consideration. >=20 >=20 > Cheers > Terry > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Apr 3 01:08:03 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61241A0140; Fri, 3 Apr 2015 01:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 l6LnZMYVJQPs; Fri, 3 Apr 2015 01:08:00 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [82.96.72.7]) by ietfa.amsl.com (Postfix) with ESMTP id EDDC91A0137; Fri, 3 Apr 2015 01:07:59 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1Ydwdt-0007A6-Ou with ESMTPSA (TLSv1.2:DHE-RSA-AES256-SHA:256) for ; Fri, 03 Apr 2015 10:07:54 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <238BA46B-2D45-4D01-9283-A98B182BBF6D@cisco.com> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> , <238BA46B-2D45-4D01-9283-A98B182BBF6D@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Steven Barth Date: Fri, 03 Apr 2015 10:07:51 +0200 To: "Pascal Thubert (pthubert)" , Margaret Wasserman Message-ID: <402DB602-10CF-4F91-A562-6B5B94899AF8@openwrt.org> Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 08:08:02 -0000 >I 'll note that RPL already addresses the problems the Margaret listed >in Dallas, in with a proposed standard doc. The shortest time to >Homenet is probably to explain how to use RPL at home, and that >probably requires only a guideline informational document... Interesting. Does RPL fulfill the requirements for a homenet RP already: supporting source-dest-routes and being autoconfiguring? Also is there any good linux-compatible C implementation to play with? Cheers, Steven From nobody Fri Apr 3 02:05:28 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6901A1B00; Fri, 3 Apr 2015 02:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7bAP9LbbdfkS; Fri, 3 Apr 2015 02:05:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03541A1B30; Fri, 3 Apr 2015 02:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1822; q=dns/txt; s=iport; t=1428051925; x=1429261525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6RrTZhHVIEIKmqgKf9zJYO4Fjwjhimxz8kH047uPgF8=; b=BGxmaZDiLf1YVbeM97mmiHrn+s4GwsVajsfTDSkPJ+pTxtAYC0fS2I5n jfKymltTt2jhDm0+jrsBGJDyg8VnMNxr0Qg6wY19dS3ISDEzfP4ruSLzW Uiq2DG2pUKgfNuCEzdAcL2BfdfDNfPtOEbMUUaXiNhCUebZR36andJyxE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BvCAAcVx5V/4MNJK1cgwuBLsMwiD0CgStMAQEBAQEBfoQfAQEDAXkFCwIBCA44MiUCBA4FiCcIzFEBAQEBAQEBAQEBAQEBAQEBAQEBARiLKYQqHDMHgxeBFgEEinGDaoIPigCUSyKDb2+CQwEBAQ X-IronPort-AV: E=Sophos;i="5.11,516,1422921600"; d="scan'208";a="409276965" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP; 03 Apr 2015 09:05:24 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3395Nuk021837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Apr 2015 09:05:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 3 Apr 2015 04:05:23 -0500 From: "Pascal Thubert (pthubert)" To: Steven Barth Thread-Topic: [homenet] Selecting a routing protocol for HOMENET Thread-Index: AQHQbZMq3x52ARfeRFW515O8wXGND506zPI6gAB2SID//7xB5g== Date: Fri, 3 Apr 2015 09:05:22 +0000 Message-ID: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> , <238BA46B-2D45-4D01-9283-A98B182BBF6D@cisco.com>, <402DB602-10CF-4F91-A562-6B5B94899AF8@openwrt.org> In-Reply-To: <402DB602-10CF-4F91-A562-6B5B94899AF8@openwrt.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 09:05:26 -0000 Yes to both. RPL had to address multiple IOT GWs from the start, say one for the power u= tility, one for cloud access, etc...=20 to address this is that it creates multiple instances which are as many log= ical topologies. By selecting the instance applied to a packet, the source = or the first RPL router will force which GW is used. RPL extends the hop count to include more information, including that insta= nce ID. This is done by a HbH option though arguably the flow label would s= uffice to carry it should 6MAN allow that usage. For a good Linux implementation, you may start with Unstrung on OpenWRT. Mo= re discussion on ROLL at this very moment. There is also a discussion on relating BABEL and RPL operations on ROLL an= d MANET. For the record, we have RPL running on some of the smallest router= s on this planet. But we also have it running of the some of the biggest ir= on we have at Cisco. This is how versatile RPL can be. This is because RPL = is a generic DV operation, designed to be instantiated by the selection of = an objective function that will deal with link types, metrics and policies, Cheers, Cheers, Pascal > Le 3 avr. 2015 =E0 10:08, Steven Barth a =E9crit : >=20 >=20 >=20 >=20 >> I 'll note that RPL already addresses the problems the Margaret listed >> in Dallas, in with a proposed standard doc. The shortest time to >> Homenet is probably to explain how to use RPL at home, and that >> probably requires only a guideline informational document... >=20 > Interesting. Does RPL fulfill the requirements for a homenet RP already: = supporting source-dest-routes and being autoconfiguring? >=20 > Also is there any good linux-compatible C implementation to play with? >=20 >=20 > Cheers, >=20 > Steven >=20 From nobody Fri Apr 3 02:53:40 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080521A6F2F; Fri, 3 Apr 2015 02:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 UiWvpUlJ6qzx; Fri, 3 Apr 2015 02:53:37 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161421A6F2A; Fri, 3 Apr 2015 02:53:36 -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/56100) with ESMTP id t339r9TU009658; Fri, 3 Apr 2015 11:53:09 +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 A6C5A2A0C49; Fri, 3 Apr 2015 11:53:09 +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 G87X6muZQA-c; Fri, 3 Apr 2015 11:53:07 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 700422A0C02; Fri, 3 Apr 2015 11:53:06 +0200 (CEST) Date: Fri, 03 Apr 2015 11:53:21 +0200 Message-ID: <87h9sxzgfi.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: <238BA46B-2D45-4D01-9283-A98B182BBF6D@cisco.com> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 03 Apr 2015 11:53:10 +0200 (CEST) X-Miltered: at korolev with ID 551E6305.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551E6305.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 : 551E6305.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: "int-ads@ietf.org" , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 09:53:39 -0000 > We are having an interesting chat on MANET and ROLL where the differences > (and core similarities) between BABEL and RPL are elaborated. There are, however, a number of issues with RPL that make it difficult to use in the Homenet or the MANET space. Note that what I say below applies to RFCs 6550 and 6552, which is not necessarily what any particular RPL vendor ships. - the RPL spec is incomplete and relies on vendor magic (for example, there's no link sensing or bidirectional reachability detection in the spec); - RPL is a large protocol, with many options, and two implementations of RPL from different vendors will not necessarily interoperate (for example, RPL includes support for no less than three distinct forwarding mechanisms -- and perhaps a fourth one, I'm not sure); - notwithstanding the omissions above, the RPL spec is a 157 page long monster (compare this to the 45 pages of Babel, of which only 20 are normative). I'm supposed to be good at reading this sort of stuff, and I'm finding it extremely difficult to work out what is the structure of RFC 6552 -- after two days of work on it, I'm still grepping. I am also not entirely convinced that the mechanisms in RFC 6552 are correct (I think I see a number of race conditions), but I don't understand the answers that I'm getting from the RPL specialists. In addition to RFC 6552 and the thread that's being crossposted between MANET and ROLL, you may want to look at: https://hal.inria.fr/inria-00597036/document Figure 3 on page 14 is my new favourite. -- Juliusz From nobody Fri Apr 3 03:13:13 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EC91A8035; Fri, 3 Apr 2015 03:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 c96D-nXW8ktY; Fri, 3 Apr 2015 03:13:10 -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 8E9071A6FCF; Fri, 3 Apr 2015 03:13:10 -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/56100) with ESMTP id t33ACjiD028972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 12:12:45 +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 t33ACjQa013495; Fri, 3 Apr 2015 12:12:45 +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 ECFB52A0C02; Fri, 3 Apr 2015 12:12:44 +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 CToxRq3gPMHm; Fri, 3 Apr 2015 12:12:43 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2AF3E2A0C6C; Fri, 3 Apr 2015 12:12:42 +0200 (CEST) Date: Fri, 03 Apr 2015 12:12:57 +0200 Message-ID: <878ue9zfiu.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.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]); Fri, 03 Apr 2015 12:12:45 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 03 Apr 2015 12:12:45 +0200 (CEST) X-Miltered: at korolev with ID 551E679D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551E679D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551E679D.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551E679D.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 : 551E679D.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551E679D.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: "int-ads@ietf.org" , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , Steven Barth , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 10:13:11 -0000 > RPL had to address multiple IOT GWs from the start, say one for the > power utility, one for cloud access, etc... to address this is that it > creates multiple instances which are as many logical topologies. By > selecting the instance applied to a packet, the source or the first RPL > router will force which GW is used. Multiple instances of RPL are supported, but I don't see any explicit support for source-specific routing. In concrete terms, there's no way to associate a given source address to an instance ID, so you need to do that by means outside the protocol. (That's a little like saying that BGP has support for source-specific routing because you can use communities to encode source-specific routes.) > RPL extends the hop count to include more information, including that > instance ID. This is done by a HbH option Modifying the data plane so that it supports new IPv6 options is certainly something that's reasonable in a sensor network. -- Juliusz From nobody Fri Apr 3 03:15:57 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E061A8784; Fri, 3 Apr 2015 03:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 YDhFvJpQjikn; Fri, 3 Apr 2015 03:15: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 263AD1A871B; Fri, 3 Apr 2015 03:15:43 -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/56100) with ESMTP id t33AFJOP030302; Fri, 3 Apr 2015 12:15:19 +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 04B6D2A0C60; Fri, 3 Apr 2015 12:15:19 +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 DD9phH0iSlCC; Fri, 3 Apr 2015 12:15:17 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 42D872A0C02; Fri, 3 Apr 2015 12:15:17 +0200 (CEST) Date: Fri, 03 Apr 2015 12:15:31 +0200 Message-ID: <877fttzfek.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: <87h9sxzgfi.wl-jch@pps.univ-paris-diderot.fr> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <238BA46B-2D45-4D01-9283-A98B182BBF6D@cisco.com> <87h9sxzgfi.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 03 Apr 2015 12:15:19 +0200 (CEST) X-Miltered: at korolev with ID 551E6837.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551E6837.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 : 551E6837.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: "int-ads@ietf.org" , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 10:15:55 -0000 > I'm finding it extremely difficult to work out what is the structure of > RFC 6552 -- after two days of work on it, I'm still grepping. [...] > I am also not entirely convinced that the mechanisms in RFC 6552 are correct Sorry, that was meant to be 6550 in both cases. -- Juliusz From nobody Fri Apr 3 10:46:57 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4932D1ACE5C for ; Fri, 3 Apr 2015 10:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 rtQ4VUeT9kus for ; Fri, 3 Apr 2015 10:46:53 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::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 9440B1ACE5B for ; Fri, 3 Apr 2015 10:46:53 -0700 (PDT) Received: by obvd1 with SMTP id d1so179807328obv.0 for ; Fri, 03 Apr 2015 10:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=L3ox1G8f/THgXq8jQ3bGXCDkJtGnX2Wf6IXapZO3xUU=; b=UGAzVxRrM9n7TlRzsZXDQjG2LzGO/gfzm3272VjQtpFNvbaXv3ak97V11tBkQhjx0g woh3rjVuZqaH21e/RVdAeg4pMi57ez0CCs2dNriv41si42l/j75z9C9U3Rpa2BqzPOD0 vW6lRut54iiDOjxwQlBI1yB/iDBoj2g2m88Ks9PamZhphTWjR4hphNohm0DUSyLE75jQ BjndoaXeG8mshkdbGaPQPJGBT50XmGthfB1TtuuH9s4mHsfDi8ku+am9hH/dNctdsWeZ DRZSMua9Ox1PNgBlGgZW0OGXV5zq5Q23IH/tu6R4pIYscNxmbTvxKTNVzZMcvK65fSfQ CeZA== MIME-Version: 1.0 X-Received: by 10.60.103.234 with SMTP id fz10mr4184214oeb.11.1428083213066; Fri, 03 Apr 2015 10:46:53 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Fri, 3 Apr 2015 10:46:52 -0700 (PDT) Date: Fri, 3 Apr 2015 10:46:52 -0700 Message-ID: From: Dave Taht To: "babel-users@lists.alioth.debian.org" , HOMENET Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [homenet] stupid babel tricks: routing ipv6 while keeping nat X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 17:46:55 -0000 I really need a better place than g+ to write this stuff down, and I am curious how you would do this with other daemons and routing protocols. Sometimes I am unwilling to take the time to unnat an internal router. So all I do is add two lines to /etc/babeld.conf to not distribute ipv4 addresses, and let me do ipv6 routed, only. That=C2=B4s easy. To kill the ipv4 routing... out if eth0 ip 0.0.0.0/0 deny in if eth0 ip 0.0.0.0/0 deny Then I can arbitrarily give myself a real /128 ipv6 address from some range elsewhere on my source specific routed network - not even adding an ipv6 address to the router in question... and it automagically transits the network in that direction, even the hops that have no or a ula-only ipv6 address. The only thing this bugs is traceroute, it is transparent to other applications. root@nuc-client:~/public_html/archer_c7_O2# traceroute6 -n $_ traceroute to shipka.bufferbloat.net (2001:4f8:3:36::52) from 2601:a:4e10:4cc7::99, 30 hops max, 24 byte packets 1 fd75:d7b6:a0c6::1 0.29 ms 0.232 ms 0.238 ms 2 * * * 3 * * * 4 * * * 5 2601:9:4e00:4cb0::1 2.313 ms 1.928 ms 1.777 ms 6 * * * 7 2001:558:82:2623::1 15.664 ms 16.341 ms 11.83 ms 8 2001:558:80:17::1 22.258 ms 15.526 ms 11.844 ms 9 * * * 10 2001:558:0:f587::2 15.589 ms 13.895 ms 14.733 ms 11 2001:559::14e 17.713 ms 18.346 ms 13.916 ms 12 2001:4f8:0:1::4:1 14.851 ms 16.484 ms 14.67 ms 13 2001:4f8:1b:1::8:2 18.905 ms 19.527 ms 18.625 ms 14 2001:4f8:3:36::52 17.228 ms 14.048 ms 14.109 ms=EF=BB=BF Current openwrt uses a default deny policy on the wan gateway, so you also have to open up the firewall for babel packets. config rule option name 'Allow-Babel' option family 'ipv6' option src 'wan' option dest_port '6696' option proto 'udp' option target 'ACCEPT' at least on the babels version of the uci scripts in chaos calmer, it is having trouble finding the br-lan option to give to babel in the first place, for some reason. --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From nobody Fri Apr 3 12:46:56 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F01A037C for ; Fri, 3 Apr 2015 12:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.481 X-Spam-Level: **** X-Spam-Status: No, score=4.481 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 675gWLZ6z7py for ; Fri, 3 Apr 2015 12:46:52 -0700 (PDT) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 61AC71A0369 for ; Fri, 3 Apr 2015 12:46:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0869640339; Fri, 3 Apr 2015 21:46:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF6Tg5vhruDp; Fri, 3 Apr 2015 21:46:49 +0200 (CEST) Received: from Rays-iMac.local (092-111-140-211.static.chello.nl [92.111.140.211]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id E8B1B40332; Fri, 3 Apr 2015 21:46:48 +0200 (CEST) Message-ID: <551EEE28.3080809@globis.net> Date: Fri, 03 Apr 2015 21:46:48 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Daniel Migault References: <20150217193324.25368.88002.idtracker@ietfa.amsl.com> <54F6F93F.8030602@globis.net> <5504CCDE.709@gmail.com> <550800B2.1090208@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040400040801020803090204" Archived-At: Cc: "homenet@ietf.org" Subject: Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 19:46:54 -0000 This is a multi-part message in MIME format. --------------040400040801020803090204 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Apologies for the very late reply: change weekends. > Daniel Migault > 20 March 2015 20:55 > Hi Ray, > > Please see my comments in text. > > I think the description of the requirements and overall chain of > events is excellent. Thanks for that. > > However I'm not particularly convinced by the security and > authentication mechanisms, as the proposed text just seems to punt > these to another transport protocol. > > Thank you for raising this point, but this is not the case. I need to > make the text clearer. When a renumbering occurs, the Hidden Master > changes its IP address, and has to provide the new IP address to the > slave. This can be done with DNS extensions or other layers. I will > update the section 9.1.2 to clarify this. Cool. Thanks. > > > I also don't see the recovery mechanism/ how to distinguish > between a break before make event, and a make before break where > the ISP's DNS servers may not be reachable at the moment of > renumbering, or that a Homenet is simply not reachable for some > time, and comes up "unnumbered" with no old IP, or that the > Homenet never comes back at all. It seems to me that you could > also end up hosting lots of cruft in the ISP servers, and there's > a need for some garbage collection. > > I am not sure I correctly get the use case: > a) It seems to me you consider also the case where the slave is > being renumbered. I did not considered this point and assume these > servers will hardly renumbered. To be honest this should be a corner case. But it would be nice if the slave was also discovered via a DNS records rather, than a literal, or cached IPv6 address. > b) It also seems to me you consider a Homenet work that is removed > or not in used, and you wonder what happen to the zone? My > understanding is that it is similar a service you subscribed and you > do not use. Do you mean that we should state that after some time, the > slave may remove its zone? > Correct. It would be cruft removal. > Can you please elaborate on the use cases you think we should comment? > Is sounds to me these considerations may not be related to > renumbering, but instead to general operations. They are indeed more general cases of changes. > > I also expect we need some more limitations on when/why a slave > would poll an unknown hidden master, otherwise it seems to me that > we have a nice DoS vector/ amplification attack. A number of > attack machines could spoof notification messages pointing to > various ISP slave systems, all pointing to a common target victim > "new" hidden master. > > > This is mentioned in the NOTIFY RFC1996 in the security consideration. > A forged NOTIFY results makes the slave trigger a SOA query. These are > small paquets, thus the amplification factor is very small. RFC1996 > qualify it as a begnin DoS attack. But I agree I will comment on that. > Actually I though of writing a specific section on it. That will be > done in the next version anyway. > If we are not specifying the mechanism more precisely, then there should be some warning that the slave should only try once to reach the new hidden master for every incoming notify request. Ant retries should be triggered from the hidden master sending a new NOTIFY request, not the slave retrying independently. Otherwise you really are creating an amplification attack. > > > It feels to me like > 1) we need a more reliable update mechanism between the hidden > master and the slaves (to cover longer-term unreachability events, > or a Homenet hidden master going off air permanently) > 2) we need a more effective authentication mechanism for > triggering updates, that is source IP address agnostic. > > This is the case, as authentication is based only cryptographic keys. > The IP address is only used for reach-ability and is never used > otherwise. > > > -- > Regards, > RayH > > > > > -- > Daniel Migault > Ericsson > > > -- > Daniel Migault > Ericsson --------------040400040801020803090204 Content-Type: multipart/related; boundary="------------050400010201070004070703" --------------050400010201070004070703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Apologies for the very late reply: change weekends.
20 March 2015 20:55
Hi Ray,

Please see my comments in text.

I think the description of the requirements and overall chain of events is excellent. Thanks for that.

However I'm not particularly convinced by the security and authentication mechanisms, as the proposed text just seems to punt these to another transport protocol.
 
Thank you for raising this point, but this is not the case. I need to make the text clearer. When a renumbering occurs, the Hidden Master changes its IP address, and has to provide the new IP address to the slave. This can be done with DNS extensions or other layers. I will update the section 9.1.2 to clarify this.
Cool. Thanks.


I also don't see the recovery mechanism/ how to distinguish between a break before make event, and a make before break where the ISP's DNS servers may not be reachable at the moment of renumbering, or that a Homenet is simply not reachable for some time, and comes up "unnumbered" with no old IP, or that the Homenet never comes back at all. It seems to me that you could also end up hosting lots of cruft in the ISP servers, and there's a need for some garbage collection.

I am not sure I correctly get the use case:
    a) It seems to me you consider also the case where the slave is being renumbered. I did not considered this point and assume these servers will hardly renumbered.
To be honest this should be a corner case.

But it would be nice if the slave was also discovered via a DNS records rather, than a literal, or cached IPv6 address.
    b) It also seems to me you consider a Homenet work that is removed or not in used, and you wonder what happen to the zone? My understanding is that it is similar a service you subscribed and you do not use. Do you mean that we should state that after some time, the slave may remove its zone?

Correct. It would be cruft removal.
Can you please elaborate on the use cases you think we should comment? Is sounds to me these considerations may not be related to renumbering, but instead to general operations.
They are indeed more general cases of changes.
 
I also expect we need some more limitations on when/why a slave would poll an unknown hidden master, otherwise it seems to me that we have a nice DoS vector/ amplification attack. A number of attack machines could spoof notification messages pointing to various ISP slave systems, all pointing to a common target victim "new" hidden master.

This is mentioned in the NOTIFY RFC1996 in the security consideration. A forged NOTIFY results makes the slave trigger a SOA query. These are small paquets, thus the amplification factor is very small. RFC1996 qualify it as a begnin DoS attack. But I agree I will comment on that. Actually I though of writing a specific section on it. That will be done in the next version anyway.
  
If we are not specifying the mechanism more precisely, then there should be some warning that the slave should only try once to reach the new hidden master for every incoming notify request. Ant retries should be triggered from the hidden master sending a new NOTIFY request, not the slave retrying independently.  Otherwise you really are creating an amplification attack.

It feels to me like
1) we need a more reliable update mechanism between the hidden master and the slaves (to cover longer-term unreachability events, or a Homenet hidden master going off air permanently)
2) we need a more effective authentication mechanism for triggering updates, that is source IP address agnostic.
This is the case, as authentication is based only cryptographic keys. The IP address is only used for reach-ability and is never used otherwise.

--
Regards,
RayH




--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson
--------------050400010201070004070703 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="compose-unknown-contact.jpg" /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEC AQEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAAR CAAZABkDAREAAhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUK BwAAAAAAAAACAQMEBQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAA AAAAAAAAAAADAAEEAv/EACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oA DAMBAAIRAxEAPwDuEt+gW/ULet6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJ VIl7eXLCaZIGwBl3TY8epPx2+jy2ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4 v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJEw/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx +a69/JSf9alIlste0VzaNpeFrcT9KKymotyiaZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mR UfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRDnu5azS8miKqjOTVkKqS/psG37fo1Fbab eg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GAcpOwBeN+U8/IkGbsiS8b7ryogmbz hbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH4hPOI0DkjZtaJtFxuVEbIUUi yeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJnYn9dnAQWl722p4ot37y zqnlfp6FrqbwawG8/9k= --------------050400010201070004070703-- --------------040400040801020803090204-- From nobody Fri Apr 3 18:53:38 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1F91A7030 for ; Fri, 3 Apr 2015 18:53:36 -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, SPF_PASS=-0.001] autolearn=ham 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 CHRCQ1mSLujQ for ; Fri, 3 Apr 2015 18:53:34 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 C23CF1A1B81 for ; Fri, 3 Apr 2015 18:53:33 -0700 (PDT) Received: by wgdm6 with SMTP id m6so122350469wgd.2 for ; Fri, 03 Apr 2015 18:53:32 -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-type; bh=lizvehqJiM9Pea1Hm/bjSjfaixNwFgo60RbiE+zKvzA=; b=SwPKO6IweivRT+/zOYPY853WLzetTv6RlJ+oOVBIHas+zPcpXvPt+7YG7su0I/3FMx YO1rnaWDxup3xA8Kl/TN7jK9+A+pEKthbJmGjgh4BFnmavyIZZSze0Hg0qV0/irt3OSn DCz6aTmvCiopb+VhSbOWHaW6XngcrCvdt3ByoAIyPBF15cCyCv/a2fxtg+yX8Yyxelfc EaGGcvrGyf14sR38lRxAc2b4p+m3BB4n7kDiWLue4QNATZuURVwcjUDRSQ4xbaaE4mKs ViAuI7FMUy7WjRsauR/VpE7kAFIxf3P1XLzHwaLMnIoOUbYiF4ZHChxnlwF1916r/AjN yslQ== MIME-Version: 1.0 X-Received: by 10.180.211.102 with SMTP id nb6mr10233871wic.32.1428112412572; Fri, 03 Apr 2015 18:53:32 -0700 (PDT) Received: by 10.194.5.97 with HTTP; Fri, 3 Apr 2015 18:53:32 -0700 (PDT) In-Reply-To: <551EEE28.3080809@globis.net> References: <20150217193324.25368.88002.idtracker@ietfa.amsl.com> <54F6F93F.8030602@globis.net> <5504CCDE.709@gmail.com> <550800B2.1090208@globis.net> <551EEE28.3080809@globis.net> Date: Fri, 3 Apr 2015 21:53:32 -0400 Message-ID: From: Daniel Migault To: Ray Hunter Content-Type: multipart/related; boundary=001a11c38ab20d1d480512dc5500 Archived-At: Cc: "homenet@ietf.org" Subject: Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 01:53:36 -0000 --001a11c38ab20d1d480512dc5500 Content-Type: multipart/alternative; boundary=001a11c38ab20d1d450512dc55ff --001a11c38ab20d1d450512dc55ff Content-Type: text/plain; charset=UTF-8 Hi, Thanks for the comments. We have also discussed this issue during the meeting in Dallas, I will provide a version soon. BR, Daniel On Fri, Apr 3, 2015 at 3:46 PM, Ray Hunter wrote: > Apologies for the very late reply: change weekends. > > Daniel Migault > 20 March 2015 20:55 > Hi Ray, > > Please see my comments in text. > > I think the description of the requirements and overall chain of events is >> excellent. Thanks for that. >> >> However I'm not particularly convinced by the security and authentication >> mechanisms, as the proposed text just seems to punt these to another >> transport protocol. >> > > Thank you for raising this point, but this is not the case. I need to make > the text clearer. When a renumbering occurs, the Hidden Master changes its > IP address, and has to provide the new IP address to the slave. This can be > done with DNS extensions or other layers. I will update the section 9.1.2 > to clarify this. > > Cool. Thanks. > > > >> I also don't see the recovery mechanism/ how to distinguish between a >> break before make event, and a make before break where the ISP's DNS >> servers may not be reachable at the moment of renumbering, or that a >> Homenet is simply not reachable for some time, and comes up "unnumbered" >> with no old IP, or that the Homenet never comes back at all. It seems to me >> that you could also end up hosting lots of cruft in the ISP servers, and >> there's a need for some garbage collection. >> >> I am not sure I correctly get the use case: > a) It seems to me you consider also the case where the slave is being > renumbered. I did not considered this point and assume these servers will > hardly renumbered. > > To be honest this should be a corner case. > > But it would be nice if the slave was also discovered via a DNS records > rather, than a literal, or cached IPv6 address. > Exactly, if the primary designates the secondaries with FQDNs it makes synchronization resilient to secondary renumbering. This has been suggested by Mark, and I have this on my local copy. > b) It also seems to me you consider a Homenet work that is removed > or not in used, and you wonder what happen to the zone? My understanding is > that it is similar a service you subscribed and you do not use. Do you mean > that we should state that after some time, the slave may remove its zone? > > Correct. It would be cruft removal. > > Can you please elaborate on the use cases you think we should comment? > Is sounds to me these considerations may not be related to renumbering, but > instead to general operations. > > They are indeed more general cases of changes. > > > >> I also expect we need some more limitations on when/why a slave would >> poll an unknown hidden master, otherwise it seems to me that we have a nice >> DoS vector/ amplification attack. A number of attack machines could spoof >> notification messages pointing to various ISP slave systems, all pointing >> to a common target victim "new" hidden master. >> > > This is mentioned in the NOTIFY RFC1996 in the security consideration. A > forged NOTIFY results makes the slave trigger a SOA query. These are small > paquets, thus the amplification factor is very small. RFC1996 qualify it as > a begnin DoS attack. But I agree I will comment on that. Actually I though > of writing a specific section on it. That will be done in the next version > anyway. > > > If we are not specifying the mechanism more precisely, then there should > be some warning that the slave should only try once to reach the new hidden > master for every incoming notify request. Ant retries should be triggered > from the hidden master sending a new NOTIFY request, not the slave retrying > independently. Otherwise you really are creating an amplification attack. > Well, in our case, the NOTIFY payload is authenticated. Eventually, the NOTIFY may be replayed multiple time during the valid time of the RRSIG. The slave is expected to have protections against replay attacks, especially given that NOTIFY are not expected to be sent in burst and multiple renumbering are expected o happen rarely. I think we consider this case then, and I will try to make it clear. > It feels to me like >> 1) we need a more reliable update mechanism between the hidden master and >> the slaves (to cover longer-term unreachability events, or a Homenet hidden >> master going off air permanently) >> 2) we need a more effective authentication mechanism for triggering >> updates, that is source IP address agnostic. >> > This is the case, as authentication is based only cryptographic keys. The > IP address is only used for reach-ability and is never used otherwise. > >> >> -- >> Regards, >> RayH >> >> > > > -- > Daniel Migault > Ericsson > > > -- > Daniel Migault > Ericsson > > -- Daniel Migault Ericsson --001a11c38ab20d1d450512dc55ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the comments. = We have also discussed this issue during the meeting in Dallas, I will prov= ide a version soon.

BR,

Daniel

=

On Fri, Apr 3, 20= 15 at 3:46 PM, Ray Hunter <v6ops@globis.net> wrote:
Apologies for the very=20 late reply: change weekends.

=20 20 March 2015=20 20:55
=
Hi Ray,

Please see my comments in text.=

I think the description of the requirements and overall chain of events=20 is excellent. Thanks for that.

However I'm not particularly convinced by the security and=20 authentication mechanisms, as the proposed text just seems to punt these to another transport protocol.
=C2=A0
Thank= =20 you for raising this point, but this is not the case. I need to make the text clearer. When a renumbering occurs, the Hidden Master changes its=20 IP address, and has to provide the new IP address to the slave. This can be done with DNS extensions or other layers. I will update the section=20 9.1.2 to clarify this.
Cool. Thanks.


I also don't see the recovery mechanism/ how to distinguish between a= =20 break before make event, and a make before break where the ISP's DNS=20 servers may not be reachable at the moment of renumbering, or that a=20 Homenet is simply not reachable for some time, and comes up "unnumbere= d" with no old IP, or that the Homenet never comes back at all. It seems=20 to me that you could also end up hosting lots of cruft in the ISP=20 servers, and there's a need for some garbage collection.

I am not sure I correctly get the use case:
=
=C2=A0=C2=A0=C2=A0 a) It seems to me you consider also the case where the slave is being=20 renumbered. I did not considered this point and assume these servers=20 will hardly renumbered.
To be honest this should be a corner case.

But it would be nice if the slave was also discovered via a DNS records=20 rather, than a literal, or cached IPv6 address.
=

Exactly, if the primary designates t= he secondaries with FQDNs it makes synchronization resilient to secondary r= enumbering. This has been suggested by Mark, and I have this on my local co= py.=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 b) It also s= eems to me you consider a Homenet work that is removed or not in used, and you wonder=20 what happen to the zone? My understanding is that it is similar a=20 service you subscribed and you do not use. Do you mean that we should=20 state that after some time, the slave may remove its zone?

Correct. It would be cruft removal.

=C2=A0
Can you please elaborate on the use cases you think we should comment? Is sounds to me these considerations may not be related to renumbering, but instead to general operations.
=
They are indeed more general cases of changes.
=C2=A0
I also expect we need some more limitations on when/why a slave would=20 poll an unknown hidden master, otherwise it seems to me that we have a=20 nice DoS vector/ amplification attack. A number of attack machines could spoof notification messages pointing to various ISP slave systems, all=20 pointing to a common target victim "new" hidden master.

This is mentioned in the NOTIFY RFC1996 in the security consideration. A=20 forged NOTIFY results makes the slave trigger a SOA query. These are=20 small paquets, thus the amplification factor is very small. RFC1996=20 qualify it as a begnin DoS attack. But I agree I will comment on that.=20 Actually I though of writing a specific section on it. That will be done in the next version anyway.
=C2=A0=C2=A0
If we are not specifying the mechanism more precisely, then there should be some warning that the slave should only try once to reach the new=20 hidden master for every incoming notify request. Ant retries should be=20 triggered from the hidden master sending a new NOTIFY request, not the=20 slave retrying independently.=C2=A0 Otherwise you really are creating an=20 amplification attack.

Well, in ou= r case, the NOTIFY payload is authenticated. Eventually, the NOTIFY may be = replayed multiple time during the valid time of the RRSIG. The slave is exp= ected to have protections against replay attacks, especially given that NOT= IFY are not expected to be sent in burst and multiple renumbering are expec= ted o happen rarely.

I think we consider this case then, = and I will try to make it clear.
It feels to me like
1) we need a more reliable update mechanism between the hidden master=20 and the slaves (to cover longer-term unreachability events, or a Homenet hidden master going off air permanently)
2) we need a more effective authentication mechanism for triggering=20 updates, that is source IP address agnostic.
This is the case, as authentication is based only cryptographic keys. The IP address is only used for=20 reach-ability and is never used otherwise.

--
Regards,
RayH




--
Daniel M= igault
Ericsson


--
<= div>Daniel Migault
Ericsson



--
Daniel Migault
Ericsson
--001a11c38ab20d1d450512dc55ff-- --001a11c38ab20d1d480512dc5500 Content-Type: image/jpeg; x-apple-mail-type=stationery; name="compose-unknown-contact.jpg" Content-Disposition: inline; filename="compose-unknown-contact.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 7afad9f3fee041b3_0.1.1 /9j/4AAQSkZJRgABAQEARwBHAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAQEB AQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/2wBDAQEBAQEBAQICAgICAgICAgICAgIC AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL/wAARCAAZABkDAREA AhEBAxEB/8QAGAAAAwEBAAAAAAAAAAAAAAAABgcICQr/xAA0EAABAwMCAgUKBwAAAAAAAAACAQME BQYRABITIQcUMUF2CBUXIjI2N0JRtVRWkZOV0dL/xAAYAQEAAwEAAAAAAAAAAAAAAAADAAEEAv/E ACQRAAICAAQGAwAAAAAAAAAAAAABAhEDMrHREyExM0FxgfDx/9oADAMBAAIRAxEAPwDuEt+gW/UL et6oVC3rfqNQqFv0OfPn1GhUqfOmzZtKZlS5UqZMaNwzNwiJVIl7eXLCaZIGwBl3TY8epPx2+jy2 ZNPjvkwc9uhW8j7nCPhvOsQliYIeS7cvCpp8o50qwrC4v3lsNSDbdmTEhvs2tahxpfV3WnmbbozJ Ew/gwdadbYExVRXKEKoSdvJcaOSqxE7/AAiX0gXx+a69/JSf9alIlste0VzaNpeFrcT9KKymotyi aZ0KRCnzacoE7Kjzn4gi2KqUh3jqDHDHv4mRUfruTWlMzlVUKIVNp9GguEJnAh0+IZjyAiisgyRD nu5azS8miKqjOTVkKqS/psG37fo1Fbabeg25b8eZPeFJBBJSjMG5HjMeyihnaauZwe4OGiju13GA cpOwBeN+U8/IkGbsiS8b7ryogmbzhbyc9REROfZhERO5ETShjPtvpGqTUyLErytS4siSwx5x2tRH 4hPOI0DkjZtaJtFxuVEbIUUiyeNujlBUJGbJN6nM/Cyf2Hf60YgjvKA+NPSP4gT7axpcPtr51YWJ nYn9dnAQWl722p4ot37yzqnlfp6FrqbwawG8/9k= --001a11c38ab20d1d480512dc5500-- From nobody Fri Apr 3 19:44:50 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353461A88EB for ; Fri, 3 Apr 2015 19:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 rmBoYL5RDVRu for ; Fri, 3 Apr 2015 19:44:48 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::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 0EE561A88F0 for ; Fri, 3 Apr 2015 19:44:47 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so16030624ieb.3 for ; Fri, 03 Apr 2015 19:44:46 -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:content-type; bh=qCEn77vpf2UDgeDh4RNokU0sY79N1v4F8IgEbzo9W7U=; b=Gef2xO2kAGAIYjo7pHcHmwjOZ2iTk1dPlu8F7MCqMn6JqmSNxgllRtilj/UIJu0dER gquJYxZyv/LYgIIAUEaAKQq5tKb9kAVfpPBw0MXguZhnCNp/9CET9dPeypXo7Pw5k/BK E0bFrTa1ROPDwtAHP3VbjWIHZt9CkLUO9xAfa8a1vc6cvVoUmZ6iJl3SsuLbP37meWC+ DRUGaaqBsO35T4RXz6l8Y8AtXkzNeqAoLrVd5+O4o17nOdVinXdlutwGaXHj6QwH8r5E dk4rNC6AEdruv87pXdbHumBeDR+x7cTrkY8KD1oHdlbqEnndbGW4qtQxmKazGssQxBYD 99pA== 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-type; bh=qCEn77vpf2UDgeDh4RNokU0sY79N1v4F8IgEbzo9W7U=; b=OxjA/R6Rdt5NHex/x0lqEJv+zQ2nwy2jYl0gGSDaY0J4zhMU5zeOiEJbLKDMbsN4b0 t5VTSrsqdS50RUyKiVvjvwsNx5S036LCLX9RphRytH3draYf8JRn65O4KAG9g0gpAwis yAHu7p8O/DSZDSjuH2pRYKUWc7Ve3WA5Ke5RGbkNGaOg10Q2Jnk4x3UyjSAmAOkv+yJY Oc/0EqcTLZscJ4HutfjJFQ2olQSM0947TkMPttmofliiGlvsHzX8dZShSnPkY51ctS4Q 54LFTkBxqo/Ls4In3q5yCpmqGXD9f8WI95kb7w4HAm/m3I/vH2F3cLbuJG5f3OW5Fg3B 6pRw== X-Gm-Message-State: ALoCoQmHpRKMUVNpOZlvw1/AWyH1rmhUhKUsvW5oBcn9cz1fJJdLinqnXjO8R5ZCN03r1T/ofwEX X-Received: by 10.50.122.5 with SMTP id lo5mr8643003igb.37.1428115486473; Fri, 03 Apr 2015 19:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Fri, 3 Apr 2015 19:44:25 -0700 (PDT) In-Reply-To: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Sat, 4 Apr 2015 11:44:25 +0900 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=089e015388b64536f20512dd0c94 Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 02:44:49 -0000 --089e015388b64536f20512dd0c94 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 3, 2015 at 12:04 AM, Alia Atlas wrote: > In the light of the above figures -- can I trust an IETF working group to >> understand that a huge amount of effort has been put into removing >> mechanisms from this protocol, and to respect that work? > > > Yes, I think that the requirement for minimal mechanisms and a simple > easy to implement and troubleshoot protocol can be clearly expressed. How > well the WG handles this depends in part on the WG chairs and how strongly > the participants are reminded of that requirement and how stringently the > need > for truly active consensus is focused on. > Alia - can we put something to that effect in the charter? There is a real risk that any WG working on standardizing babel will start proposing lots of changes to the protocol (due to NIH syndrome, general bikeshedding, etc.), alienating its author and leading to lost time and the usual failures of design-by-committee. To avoid this, can we see to it that the charter of any group chartered to take babel to proposed standard status be chartered to do so without making substantial changes to the protocol mechanics? That way, if the protocol works well as is, we'll get a standard soon. If it doesn't, the WG can always throw up its hands and fail fast. --089e015388b64536f20512dd0c94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 3, 2015 at 12:04 AM, Alia Atlas <akatlas@gmail.com> = wrote:
In the light of the above figures -- can I trust an IETF working = group to
understand that a huge amount of effort has been put into removing
mechanisms from this protocol, and to respect that work?
<= br>
Yes, I think that the requirement for minimal mechanis= ms and a simple
easy to implement and troubleshoot protocol can b= e clearly expressed.=C2=A0 How
well the WG handles this depends i= n part on the WG chairs and how strongly
the participants are rem= inded of that requirement and how stringently the need
for truly = active consensus is focused on.=C2=A0
<= div>
Alia - can we put something to that effect in the charte= r?

There is a real risk that any WG working on sta= ndardizing babel will start proposing lots of changes to the protocol (due = to NIH syndrome, general bikeshedding, etc.), alienating its author and lea= ding to lost time and the usual failures of design-by-committee.
=
To avoid this, can we see to it that the charter of any grou= p chartered to take babel to proposed standard status be chartered to do so= without making substantial changes to the protocol mechanics?
That way, if the protocol works well as is, we'll get a st= andard soon. If it doesn't, the WG can always throw up its hands and fa= il fast.
--089e015388b64536f20512dd0c94-- From nobody Fri Apr 3 20:43:25 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8D1A8949; Fri, 3 Apr 2015 20:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 5y2usGm7QAnS; Fri, 3 Apr 2015 20:43:22 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::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 35CA01A8947; Fri, 3 Apr 2015 20:43:22 -0700 (PDT) Received: by qcgx3 with SMTP id x3so100096445qcg.3; Fri, 03 Apr 2015 20:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YgKhwr/hVmkp75vv6HpjXiYHGlUqSxPWpITr4u4JbFI=; b=eJdQ3Q11YNLwVp+AnDsTkXxk3ZIN+lAe+ciYhYQ5Q1uyJdBRXPnJhw+WmDcnPHQ1ta JkWw0yx0yqLq/N/zuPJI+uS7pxhUZahxPr0RSDRWxsMnlxHObn+RFFyxmBNvsMdPcVDh WKSKfSJ5VpJ+fCHC0dFomeEGcFTNop1OEaVxNVwayaAOHXbFwA544gOQvG3n+gqpkrB2 B/exj+BI0D96UOHsPc5BMOdhHqBbOK+mUHC4LHpH+Ag8IXH8W8Vj6wEOPvALN9U1gnbv EyX96kVsG2tBf/uObov8LMUu/XPVvzGBazRXujHEgaSY4D8Bnlr2YntnLHe4hfq8dgki h3IA== X-Received: by 10.55.27.42 with SMTP id b42mr9628994qkb.53.1428119001554; Fri, 03 Apr 2015 20:43:21 -0700 (PDT) Received: from [33.150.179.56] ([172.56.22.81]) by mx.google.com with ESMTPSA id h3sm708892qkh.34.2015.04.03.20.43.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Apr 2015 20:43:20 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-22AC8C12-AA55-4642-8BD0-F9AFB2BBE6A6 Mime-Version: 1.0 (1.0) From: Margaret Wasserman X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Fri, 3 Apr 2015 23:43:16 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> To: Lorenzo Colitti Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 03:43:24 -0000 --Apple-Mail-22AC8C12-AA55-4642-8BD0-F9AFB2BBE6A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You can definitely charter a WG to use a specific set of documents as a star= ting point for their work -- that's a solution space WG, and they used to be= more common than they are now. That sort of group will typically formally a= dopt the documents named in their charter right away, and only change them i= f they have consensus to do so. I think that is about as far in that direct= ion as you can go, though. I don't think you can have a WG that the isn't allowed to make changes to a W= G document if they _do_ have consensus to make those changes. If an AD wants to publish a document as a standards-track document close to a= s-is and thinks the IETF would have consensus to do that, he or she can just= sponsor it for publication without a WG at all. If I understand correctly,= that wouldn't work well in this case, because people active in the Routing A= rea would not feel comfortable publishing a routing protocol without more re= view and visibility than that. Margaret Sent from my iPhone > On Apr 3, 2015, at 10:44 PM, Lorenzo Colitti wrote: >=20 > On Fri, Apr 3, 2015 at 12:04 AM, Alia Atlas wrote: >>> In the light of the above figures -- can I trust an IETF working group t= o >>> understand that a huge amount of effort has been put into removing >>> mechanisms from this protocol, and to respect that work? >>=20 >> Yes, I think that the requirement for minimal mechanisms and a simple >> easy to implement and troubleshoot protocol can be clearly expressed. Ho= w >> well the WG handles this depends in part on the WG chairs and how strongl= y >> the participants are reminded of that requirement and how stringently the= need >> for truly active consensus is focused on.=20 >=20 > Alia - can we put something to that effect in the charter? >=20 > There is a real risk that any WG working on standardizing babel will start= proposing lots of changes to the protocol (due to NIH syndrome, general bik= eshedding, etc.), alienating its author and leading to lost time and the usu= al failures of design-by-committee. >=20 > To avoid this, can we see to it that the charter of any group chartered to= take babel to proposed standard status be chartered to do so without making= substantial changes to the protocol mechanics? >=20 > That way, if the protocol works well as is, we'll get a standard soon. If i= t doesn't, the WG can always throw up its hands and fail fast. --Apple-Mail-22AC8C12-AA55-4642-8BD0-F9AFB2BBE6A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You can definitely charter a WG to use= a specific set of documents as a starting point for their work -- that's a s= olution space WG, and they used to be more common than they are now.  T= hat sort of group will typically formally adopt the documents named in their= charter right away, and only change them if they have consensus to do so. &= nbsp;I think that is about as far in that direction as you can go, though.

I don't think you can have a WG that the isn't allow= ed to make changes to a WG document if they _do_ have consensus to make thos= e changes.

If an AD wants to publish a document as a= standards-track document close to as-is and thinks the IETF would have cons= ensus to do that, he or she can just sponsor it for publication without a WG= at all.  If I understand correctly, that wouldn't work well in this ca= se, because people active in the Routing Area would not feel comfortable pub= lishing a routing protocol without more review and visibility than that.

Margaret

Sent from my iPhone

On A= pr 3, 2015, at 10:44 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

On Fri, Apr 3, 2015 at 12:04 AM, Alia Atlas <akatlas@gmail.com> wrote:
In the light of the above figures -- can I trust an IETF working g= roup to
understand that a huge amount of effort has been put into removing
mechanisms from this protocol, and to respect that work?
Yes, I think that the requirement for minimal mechanisms= and a simple
easy to implement and troubleshoot protocol can be c= learly expressed.  How
well the WG handles this depends in pa= rt on the WG chairs and how strongly
the participants are reminded= of that requirement and how stringently the need
for truly active= consensus is focused on. 
Alia - can we put something to that effect in the charter?
=

There is a real risk that any WG working on standardizin= g babel will start proposing lots of changes to the protocol (due to NIH syn= drome, general bikeshedding, etc.), alienating its author and leading to los= t time and the usual failures of design-by-committee.

To avoid this, can we see to it that the charter of any group chartered t= o take babel to proposed standard status be chartered to do so without makin= g substantial changes to the protocol mechanics?

Th= at way, if the protocol works well as is, we'll get a standard soon. If it d= oesn't, the WG can always throw up its hands and fail fast.
= --Apple-Mail-22AC8C12-AA55-4642-8BD0-F9AFB2BBE6A6-- From nobody Fri Apr 3 21:25:50 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94461A8996; Fri, 3 Apr 2015 21:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 01-2vcnoB1gU; Fri, 3 Apr 2015 21:25:47 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 E54751A8983; Fri, 3 Apr 2015 21:25:46 -0700 (PDT) Received: by obbec2 with SMTP id ec2so190987272obb.3; Fri, 03 Apr 2015 21:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dOS6kAng+xbsqHlXV9wNCUP5PDu5P7/vXlevYBBRZgk=; b=ec/dnhM2meKbhRdwnKYqamAehyzJKjhNDmpuIJtiCnQKdHQL6qVqyW7R1sgK2OfO1C 9YUIRpljnww5cCIdavj4pFCVdCJ+Ty+8WixwQQbDRbKWGhPH/aOvbBdm1KgEoUVcqw1q ezoEwXlEDsPMwg3/NSIfGOru6y43OVzrumYdOur7Pgbv6pqVsvpMPtOTw3m7oWDLEK5E 7A0/TORx/uwqxfe/Usqa/MMverudq/9n43zEmLuvL6J/GPUEFEV8VpYtaXLOaoeE7HSi Y6wtxdxq77ihYilYAYaCQ0oSAzMIoZ4LQQfUiA6w4qrtrrFV5rtOC5fa2Ksmo4+cxeDE 3Bjw== MIME-Version: 1.0 X-Received: by 10.60.161.36 with SMTP id xp4mr6541867oeb.61.1428121546346; Fri, 03 Apr 2015 21:25:46 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Fri, 3 Apr 2015 21:25:46 -0700 (PDT) In-Reply-To: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> Date: Sat, 4 Apr 2015 00:25:46 -0400 Message-ID: From: Alia Atlas To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=089e011600267755530512de75ab Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 04:25:49 -0000 --089e011600267755530512de75ab Content-Type: text/plain; charset=UTF-8 Lorenzo, On Fri, Apr 3, 2015 at 10:44 PM, Lorenzo Colitti wrote: > On Fri, Apr 3, 2015 at 12:04 AM, Alia Atlas wrote: > >> In the light of the above figures -- can I trust an IETF working group to >>> understand that a huge amount of effort has been put into removing >>> mechanisms from this protocol, and to respect that work? >> >> >> Yes, I think that the requirement for minimal mechanisms and a simple >> easy to implement and troubleshoot protocol can be clearly expressed. How >> well the WG handles this depends in part on the WG chairs and how strongly >> the participants are reminded of that requirement and how stringently the >> need >> for truly active consensus is focused on. >> > > Alia - can we put something to that effect in the charter? > That is part of the scoping & chartering discussion. It is a possible outcome. I'm still gathering data (finally next week getting a bit more time to focus) and listening to opinions and concerns. Figuring out the charter scope is part of asking for what are the requirements and applicability driving the obvious and deployed interest in Babel? > There is a real risk that any WG working on standardizing babel will start > proposing lots of changes to the protocol (due to NIH syndrome, general > bikeshedding, etc.), alienating its author and leading to lost time and the > usual failures of design-by-committee. > Usually, people are suggesting a change or feature because they need it for a deployment or customer. Sometimes, there are just "interesting ideas" - but requiring implementations and solid discussion usually make it clear what the case is and how much applicability/scope creep there is. Regards, Alia To avoid this, can we see to it that the charter of any group chartered to > take babel to proposed standard status be chartered to do so without making > substantial changes to the protocol mechanics? > > That way, if the protocol works well as is, we'll get a standard soon. If > it doesn't, the WG can always throw up its hands and fail fast. > --089e011600267755530512de75ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lorenzo,

On Fri, Apr 3, 2015 at 10:44 PM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On= Fri, Apr 3, 2015 at 12:04 AM, Alia Atlas <akatlas@gmail.com> wrote:
In the light of the above figures -- can I trust an IETF working group to<= br> understand that a huge amount of effort has been put into removing
mechanisms from this protocol, and to respect that work?
<= br>
Yes, I think that the requirement for minimal mechanis= ms and a simple
easy to implement and troubleshoot protocol can b= e clearly expressed.=C2=A0 How
well the WG handles this depends i= n part on the WG chairs and how strongly
the participants are rem= inded of that requirement and how stringently the need
for truly = active consensus is focused on.=C2=A0
<= div>
Alia - can we put something to that effect in the= charter?

That is p= art of the scoping & chartering discussion.=C2=A0 It is a possible outc= ome.=C2=A0 I'm
still gathering data (finally next week gettin= g a bit more time to focus) and listening
to opinions and concern= s.
Figuring out the charter scope is part of asking for what are = the requirements and=C2=A0
applicability driving the obvious and = deployed interest in Babel?
=C2=A0
There is a real risk that any WG working on standardizing= babel will start proposing lots of changes to the protocol (due to NIH syn= drome, general bikeshedding, etc.), alienating its author and leading to lo= st time and the usual failures of design-by-committee.

Usually, people are suggesting a change= or feature because they need it for a deployment or customer.=C2=A0 Someti= mes,=C2=A0
there are just "interesting ideas" - but req= uiring implementations and solid discussion usually make it clear what the= =C2=A0
case is and how much applicability/scope creep there is.= =C2=A0
=C2=A0
Regards,
Alia

To avoid this, can we see to = it that the charter of any group chartered to take babel to proposed standa= rd status be chartered to do so without making substantial changes to the p= rotocol mechanics?

That way, if the protocol works= well as is, we'll get a standard soon. If it doesn't, the WG can a= lways throw up its hands and fail fast.

--089e011600267755530512de75ab-- From nobody Sat Apr 4 14:52:43 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CD51A037B for ; Sat, 4 Apr 2015 14:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35] autolearn=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 7ey4SuYAgWoq for ; Sat, 4 Apr 2015 14:52: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 AE8A31A036D for ; Sat, 4 Apr 2015 14:52: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/56100) with ESMTP id t34LqbbC029077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Apr 2015 23:52:37 +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 t34LqbTL015059; Sat, 4 Apr 2015 23:52: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 4E9792A0C61; Sat, 4 Apr 2015 23:52: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 adh6GIpho5zB; Sat, 4 Apr 2015 23:52:35 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 573A72A0C09; Sat, 4 Apr 2015 23:52:35 +0200 (CEST) Date: Sat, 04 Apr 2015 23:52:51 +0200 Message-ID: <87fv8f4l3g.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas 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 Apr 2015 23:52:37 +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 Apr 2015 23:52:37 +0200 (CEST) X-Miltered: at korolev with ID 55205D25.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 55205D25.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55205D25.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 55205D25.003 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 : 55205D25.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 55205D25.003 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: homenet@ietf.org, babel-users@lists.alioth.debian.org Subject: [homenet] draft-chroboczek-babel-doesnt-care-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 21:52:41 -0000 Dear Alia, [Homenet and babel-users in copy of this mail.] In a previous conversation, you suggested I write down an applicability statement for Babel. However, I got bored in the middle, and ended up writing this: Babel doesn't care. https://tools.ietf.org/html/draft-chroboczek-babel-doesnt-care-00 Please don't let the somewhat flippant title put you off -- somewhere within the verbiage, you will find an applicability statement (in Section 1.1). For people who are not familiar with Babel, I've done my best to give a protocol outline in Section 2 that might be easier to digest than RFC 6126. To my knowledge, there is nothing outright incorrect in this document, and I've removed almost all the jokes before submitting. -- Juliusz From tgg22@hermes.cam.ac.uk Sun Apr 5 06:48:06 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643921A8983 for ; Sun, 5 Apr 2015 06:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zNvVUsF6e1bB for ; Sun, 5 Apr 2015 06:48:04 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 9DE431A1B11 for ; Sun, 5 Apr 2015 06:48:03 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:55551) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:tgg22) id 1Yeku8-00054C-gg (Exim 4.82_3-c0e5623) (return-path ); Sun, 05 Apr 2015 14:48:00 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:tgg22) id 1Yeku8-00031q-5y (Exim 4.72) (return-path ); Sun, 05 Apr 2015 14:48:00 +0100 Received: from [81.158.112.171] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 05 Apr 2015 14:48:00 +0100 Date: 05 Apr 2015 14:48:00 +0100 From: "Timothy G. Griffin" To: Juliusz Chroboczek Message-ID: In-Reply-To: <87fv8f4l3g.wl-jch@pps.univ-paris-diderot.fr> References: <87fv8f4l3g.wl-jch@pps.univ-paris-diderot.fr> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: "T.G. Griffin" Archived-At: Cc: homenet@ietf.org, babel-users@lists.alioth.debian.org, Alia Atlas Subject: Re: [homenet] [Babel-users] draft-chroboczek-babel-doesnt-care-00 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 13:50:15 -0000 Juliusz, Your nice draft inspired me to decompose some lyrics for Babel. ---tim http://www.cl.cam.ac.uk/~tgg22/ =============== To the tune of "Yellow Submarine" by the Beatles. "Babel Doesn't Care" In the town where I do route Lived a man who surfed the net And he told us of his life with Metric Agnosticity So we booted up all the nodes Till we saw the screens of green And we lived with packet loss Because Babel does not care! We all know that Babel doesn't care Babel doesn't care, Babel doesn't care We all know that Babel doesn't care Babel doesn't care, Babel doesn't care And our friends are all on board Many more of them live next door And the band begins to play We all know that Babel doesn't care Babel doesn't care, Babel doesn't care We all know that Babel doesn't care Babel doesn't care, Babel doesn't care As we live a life of ease (A life of ease) Everyone of us (Everyone of us) has all we need (Has all we need) Lossy net (Lossy net) mobility (Mobility) Because Babel (Because Babel) doesn't care (Doesn't care, ha, ha) We all know that Babel doesn't care Babel doesn't care, Babel doesn't care We all know that Babel doesn't care Babel doesn't care, Babel doesn't care .... On Apr 4 2015, Juliusz Chroboczek wrote: >Dear Alia, > >[Homenet and babel-users in copy of this mail.] > >In a previous conversation, you suggested I write down an applicability >statement for Babel. However, I got bored in the middle, and ended up >writing this: > > Babel doesn't care. > https://tools.ietf.org/html/draft-chroboczek-babel-doesnt-care-00 > >Please don't let the somewhat flippant title put you off -- somewhere >within the verbiage, you will find an applicability statement (in Section >1.1). > >For people who are not familiar with Babel, I've done my best to give >a protocol outline in Section 2 that might be easier to digest than RFC >6126. To my knowledge, there is nothing outright incorrect in this >document, and I've removed almost all the jokes before submitting. > >-- Juliusz > >_______________________________________________ >Babel-users mailing list >Babel-users@lists.alioth.debian.org >http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users > From nobody Sun Apr 5 06:56:21 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19C1A8998; Sun, 5 Apr 2015 06:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35] autolearn=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 V3dQ1lL2k-2P; Sun, 5 Apr 2015 06:56:19 -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 B00C71A0011; Sun, 5 Apr 2015 06:56:18 -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/56100) with ESMTP id t35DtrVl029160; Sun, 5 Apr 2015 15:55:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 77FA42A0C7C; Sun, 5 Apr 2015 15:55:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id cOpWK2x_2dhD; Sun, 5 Apr 2015 15:55:51 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 109342A0C4C; Sun, 5 Apr 2015 15:55:50 +0200 (CEST) Date: Sun, 05 Apr 2015 15:56:06 +0200 Message-ID: <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.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]); Sun, 05 Apr 2015 15:55:54 +0200 (CEST) X-Miltered: at korolev with ID 55213EE9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55213EE9.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 : 55213EE9.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: "int-ads@ietf.org" , Terry Manderson , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Lorenzo Colitti Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 13:56:20 -0000 Sorry for the delay, I needed to think this over. >> In the light of the above figures -- can I trust an IETF working group >> to understand that a huge amount of effort has been put into removing >> mechanisms from this protocol, and to respect that work? > Yes, I think that the requirement for minimal mechanisms and a simple > easy to implement and troubleshoot protocol can be clearly expressed. Here's some initial and incomplete input. I'm just thinking aloud, and perhaps taking my God-given right to say something stupid. I'd like the charter to clearly state that no mechanism will be added unless there is experimental data to show that it is necessary in realistic situations. For example, should people believe that an additional congestion control mechanism is needed, they will need to show experimental data that prove their point. I'd like the charter to clearly state that security considerations are outside the scope of the base spec. The base spec says "This is a completely insecure protocol" and I much prefer this frank admission of failure to a half-baked solution, which would then prevent better security mechanisms from being developed. (I am not a security specialist, and while I'm really glad about RFC 7298 (HMAC auth for Babel), I am not competent to judge whether it is the only solution.) I'd like the suggested metrics to remain informative appendices, contrary to Ted's opinion. Babel's main claim to fame is that it's an extremely flexible protocol, and putting the suggested metrics in the body of the document is contrary with the main goal. I'd also like the other metrics (as well as source-specific routing) to remain separate documents, since they require extensions to the packet format. There is only one mechanism in the base spec that is not currently used by implementations -- it's the reliable transport building block defined in Section 3.3. It has very low cost (20 lines of code or so in the C version), so it's a MUST, since it is only useful if implemented by all nodes. I have no strong feelings about whether it should stay. It is not clear to me whether the extension mechanism should be merged into the base spec. I think the answer is yes, but in the meantime this should not delay the publication of draft-chroboczek-babel-extension-mechanism-04 as an Experimental RFC. Sorry for the underfull hbox. The packet format is a little messy, but extremely compact, which is useful in meshy places. I believe that Joel Halpern dislikes it, I'm not so sure I like it myself. I hold no opinion whether it should be replaced by a cleaner but more costly format -- it's a difficult choice. -- Juliusz From nobody Sun Apr 5 07:11:48 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44A81A89EF; Sun, 5 Apr 2015 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 F5mKf8SBNrEj; Sun, 5 Apr 2015 07:11:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51C61A89D3; Sun, 5 Apr 2015 07:11:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5E4F9BE8F; Sun, 5 Apr 2015 15:11:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXESbQziM1lG; Sun, 5 Apr 2015 15:11:43 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3BAD4BE87; Sun, 5 Apr 2015 15:11:27 +0100 (IST) Message-ID: <5521428A.1070306@cs.tcd.ie> Date: Sun, 05 Apr 2015 15:11:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Juliusz Chroboczek , Alia Atlas References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "int-ads@ietf.org" , Lorenzo Colitti , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:11:47 -0000 Hiya, Just on one topic... On 05/04/15 14:56, Juliusz Chroboczek wrote: > I'd like the charter to clearly state that security considerations are > outside the scope of the base spec. FWIW, and wearing my security AD hat, I can guarantee that would generate pushback. We have BCPs that say we don't do that, e.g. BCP61 and others. And the effort to get RPL to consider this properly added quite a bit of delay for that WG partly because they wanted to take the approach of doing security later which isn't really a good plan IMO. And of course results tend to be mediocre as well when folks take the "graft on security later" approach. You may have an argument that that approach has already been taken, but how we handle that is IMO one of the differences between the ISE stream and IETF stream, esp. standards track. Security in environments like this is tricky though I agree, esp when one considers the impacts of the various security mechanisms at the various layers. But that just does not mean that it's ok to ignore those issues. S. PS: The above does not mean that I think it's a problem if a WG want to produce a base spec and some other RFC that has the security analysis and defines useful security mechanisms. IMO so long as those are done at the same time, and so long as the security mechanisms have the the 2119 keywords associated that are justified by the security analysis, then that's just fine. From nobody Sun Apr 5 07:24:24 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F91A1A8A5F; Sun, 5 Apr 2015 07:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 34BsJNjY5WRZ; Sun, 5 Apr 2015 07:24:22 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3451A8A4A; Sun, 5 Apr 2015 07:24:21 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t35ENpxD002763; Sun, 5 Apr 2015 16:23:51 +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 8FF4E2A0C7C; Sun, 5 Apr 2015 16:23:51 +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 SAdPiz54_nQR; Sun, 5 Apr 2015 16:23:50 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A1AF72A0C4C; Sun, 5 Apr 2015 16:23:49 +0200 (CEST) Date: Sun, 05 Apr 2015 16:24:06 +0200 Message-ID: <877ftqvek9.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Stephen Farrell In-Reply-To: <5521428A.1070306@cs.tcd.ie> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> <5521428A.1070306@cs.tcd.ie> 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 Apr 2015 16:23:51 +0200 (CEST) X-Miltered: at korolev with ID 55214577.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55214577.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 : 55214577.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: "int-ads@ietf.org" , Terry Manderson , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Lorenzo Colitti Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:24:23 -0000 >> I'd like the charter to clearly state that security considerations are >> outside the scope of the base spec. > PS: The above does not mean that I think it's a problem if a > WG want to produce a base spec and some other RFC that has the > security analysis and defines useful security mechanisms. I don't think we're disagreeing. I was careful to say "outside the scope of the base spec", as opposed to the scope of the WG. (The base spec is 45 pages long, and can be explained in less than one hour. I will fight to keep it that way.) I'll have a look at the BCP you refer to. Thanks for your input, -- Juliusz From nobody Sun Apr 5 07:32:58 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2861A8A78; Sun, 5 Apr 2015 07:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gsTcJgaDJake; Sun, 5 Apr 2015 07:32:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1F51A8A73; Sun, 5 Apr 2015 07:32:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9AAE9BE8E; Sun, 5 Apr 2015 15:32:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLGcK6jowYJM; Sun, 5 Apr 2015 15:32:53 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EAEA5BE87; Sun, 5 Apr 2015 15:32:52 +0100 (IST) Message-ID: <55214794.90208@cs.tcd.ie> Date: Sun, 05 Apr 2015 15:32:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> <5521428A.1070306@cs.tcd.ie> <877ftqvek9.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <877ftqvek9.wl-jch@pps.univ-paris-diderot.fr> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "int-ads@ietf.org" , Lorenzo Colitti , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:32:57 -0000 On 05/04/15 15:24, Juliusz Chroboczek wrote: >>> I'd like the charter to clearly state that security considerations are >>> outside the scope of the base spec. > >> PS: The above does not mean that I think it's a problem if a >> WG want to produce a base spec and some other RFC that has the >> security analysis and defines useful security mechanisms. > > I don't think we're disagreeing. I was careful to say "outside the scope > of the base spec", as opposed to the scope of the WG. You were indeed. And I'm being careful to say that a plan of the form "produce base spec RCC and only then start to think about security" will get pushback from me. And that said, I'm not entirely sure if we're agreeing or not, but we'd know pretty soon if this gets going, so we're fine for now:-) S. > > (The base spec is 45 pages long, and can be explained in less than one > hour. I will fight to keep it that way.) > > I'll have a look at the BCP you refer to. > > Thanks for your input, > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > From nobody Sun Apr 5 07:37:59 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086771A8A9A; Sun, 5 Apr 2015 07:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 NxaxuqaMZCk4; Sun, 5 Apr 2015 07:37:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C931A8A99; Sun, 5 Apr 2015 07:37:57 -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/56100) with ESMTP id t35EbXqb005812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Apr 2015 16:37:33 +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 t35EbXXl026378; Sun, 5 Apr 2015 16:37:33 +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 8EFC32A0C7C; Sun, 5 Apr 2015 16:37:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Cd4hvbV1jrwO; Sun, 5 Apr 2015 16:37:32 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D601A2A0C4C; Sun, 5 Apr 2015 16:37:29 +0200 (CEST) Date: Sun, 05 Apr 2015 16:37:46 +0200 Message-ID: <874mouvdxh.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Stephen Farrell In-Reply-To: <55214794.90208@cs.tcd.ie> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> <5521428A.1070306@cs.tcd.ie> <877ftqvek9.wl-jch@pps.univ-paris-diderot.fr> <55214794.90208@cs.tcd.ie> 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, 05 Apr 2015 16:37:33 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 05 Apr 2015 16:37:33 +0200 (CEST) X-Miltered: at korolev with ID 552148AD.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 552148AD.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 552148AD.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 552148AD.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 : 552148AD.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 552148AD.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: "int-ads@ietf.org" , Lorenzo Colitti , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:37:59 -0000 > a plan of the form "produce base spec RCC and only then start to think > about security" will get pushback from me. Why? (If the answer is "read BCP 61", I'll do that, but not right now.) -- Juliusz From nobody Sun Apr 5 07:48:43 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385511A8AE0; Sun, 5 Apr 2015 07:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 6jQlxmlI5Ymv; Sun, 5 Apr 2015 07:48:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CA61A8ADE; Sun, 5 Apr 2015 07:48:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A540FBE8E; Sun, 5 Apr 2015 15:48:39 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03Z2-PtDhB1q; Sun, 5 Apr 2015 15:48:38 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2D79ABE8A; Sun, 5 Apr 2015 15:48:38 +0100 (IST) Message-ID: <55214B45.3000703@cs.tcd.ie> Date: Sun, 05 Apr 2015 15:48:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> <5521428A.1070306@cs.tcd.ie> <877ftqvek9.wl-jch@pps.univ-paris-diderot.fr> <55214794.90208@cs.tcd.ie> <874mouvdxh.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <874mouvdxh.wl-jch@pps.univ-paris-diderot.fr> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "int-ads@ietf.org" , Terry Manderson , "rtg-ads@ietf.org" , Margaret Wasserman , Dave Taht , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Lorenzo Colitti Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 14:48:42 -0000 On 05/04/15 15:37, Juliusz Chroboczek wrote: >> a plan of the form "produce base spec RCC and only then start to think >> about security" will get pushback from me. > > Why? > > (If the answer is "read BCP 61", I'll do that, but not right now.) Partly that and partly the horrible experience with years of delay with RPL. I inherited a DISCUSS on the base RPL spec in March 2011 from the previous security AD. I can't remember how much that delayed the base RPL spec, maybe a year or so until we worked out a plan that was going to not result in security being ignored. And their security analysis RFC (7416) was only published in Jan 2015. And there was loads and loads of gnashing of teeth in between for everyone involved. And I also think the final result would have been better had the security work been done up front whilst they had more energy and motivation. S. > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > From nobody Sun Apr 5 08:17:08 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92301A9141 for ; Sun, 5 Apr 2015 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 X0foMSsMFv4X for ; Sun, 5 Apr 2015 08:17:05 -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 2E9151A912F for ; Sun, 5 Apr 2015 08:17:04 -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/56100) with ESMTP id t35FH0Mp016381; Sun, 5 Apr 2015 17:17:00 +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 75C042A0C0D; Sun, 5 Apr 2015 17:17:00 +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 MQgIRtu4eG0L; Sun, 5 Apr 2015 17:16:58 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 270B12A0C0B; Sun, 5 Apr 2015 17:16:54 +0200 (CEST) Date: Sun, 05 Apr 2015 17:17:11 +0200 Message-ID: <871tjyvc3s.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Markus Stenberg In-Reply-To: <6E582E90-B871-41F1-8E95-26CACAACFC35@iki.fi> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> <6E582E90-B871-41F1-8E95-26CACAACFC35@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 05 Apr 2015 17:17:00 +0200 (CEST) X-Miltered: at korolev with ID 552151EC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 552151EC.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 : 552151EC.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: "homenet@ietf.org" , Stephen Farrell , babel-users@lists.alioth.debian.org, Alia Atlas Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 15:17:06 -0000 > (Argh, kilometer long cc list, sorry guys in advance..) Dropping everyone and his brother too, leaving Homenet and Alia, adding babel-users and Stephen. > Sadly enough the more flexible/less code footprint _given system-wide > IPsec_ approach of OSPFv3 turned out not to be popular. It allowed us to > secure Babel with just few lines of changes to one script in the hnetd > implementation, which was neat, but.. :-) Hmm, if you're using static keying, you're vulnerable to replay. Does that mean I should port the replay protection bits from RFC 7298 to the reference implementation? They don't frighten me as much as the crypto bits. > I am not very fond of making any MUST metric functions either. However, > what I _would_ like to see is some guidance on metrics ranges that > should be used and how the combination should approximately work best > (remember ‘pybabel’s metric=1 + combination using + favors it too much’ > email). Perhaps this could be also just in an appendix. Point taken. >> There is only one mechanism in the base spec that is not currently used by >> implementations -- it's the reliable transport building block defined in >> Section 3.3. It has very low cost (20 lines of code or so in the >> C version), > I am not very fond of it, as I do not see much of a justification for it > given the goal of minimality. See the discussion in Section 3.7.2 of RFC 6126. I've been planning to implement that, to see how much it improves behaviour in sparse wireless meshes. > E.g. on point-to-point link (or one with few routers), you could send > stuff very rarely and just use that ack feature to make sure the other > end is aware of the current state Hmm... have you noticed the (optional) receiver-driven scheme described in Section 3.8.2.3? But yes, you're right, although fine-tuning the details of your scheme might not be quite obvious. > I only wonder about the padding TLVs/sub-TLVs I don't expect anyone to use padding for alignment. But I'm fond of PAD1 and PADN TLVs, since they don't cost much and often turn out to be useful for various reasons. For example, the Babel-RTT extension puts a PADN sub-TLV at the place where a timestamp will go; then it applies jitter to the outgoing packet, and patches it with a timestamp at the very last moment. If the timestamping fails for some reason, the packet can still go out -- the PADN will be ignored by the receiver. Look, Ma, no complex error handling and no packet drops. (Credit to Baptiste Jonglez.) Similarly, suppose you wanted to do MTU probing a la OSPF (or is it IS-IS?), or wanted to evaluate packet loss for full-size frames only. In either case, PADN your Hellos to full MTU, and you're done. > Especially given multicast-using (default) nature of the protocol, I am > fond of _a_ solution that fits as much as possible in one MTU packet per > interval; therefore, more costly format would essentially behave worse > for networks above certain size (in terms of # of total routes mostly). I agree. Still, it might be worthwile to have an expert pore over the packet format, and see how much he shakes his head. -- Juliusz From nobody Sun Apr 5 08:19:01 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3509A1A912F; Sun, 5 Apr 2015 08:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 5ftbTh019krN; Sun, 5 Apr 2015 08:18:58 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 045741A914D; Sun, 5 Apr 2015 08:18:58 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so14045218obb.1; Sun, 05 Apr 2015 08:18: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:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+xIeCHi0KvT9DqSHxvLkIVIjV84izl2UeEObtTKif70=; b=eVDfAfIKIb2eEBmvQsuTxZgi05k9KcrZ/0Fex79aQMwITPXPTatMt/cGrz0CJcR8t0 okhyZREoaHn4wNVmsENPEeyZQE6twzmXfgD14562Fhr4vI69BK6IJKhyTQ+o35BppK+w jK5VNUmd47I0MKLatY7gsy+fq8QDl9WP/2n2wX5AVSaM7LscrYRepRbBCkqzqnwILsRW 0B61DWVK7yWmH0jxDKestZ/sgAaSd+F1JpkSpolPZ0hgQxOQTO9JUGCjk0rO6ZBoNTD/ 3AzMSOhgXtVqZ0eeLhc75YuBRUfbjHy5hYIUiG1HYrbHY9GNbzrdb+NvvLR86HcJ/Or+ CKxA== MIME-Version: 1.0 X-Received: by 10.60.103.234 with SMTP id fz10mr13574088oeb.11.1428247137473; Sun, 05 Apr 2015 08:18:57 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Sun, 5 Apr 2015 08:18:57 -0700 (PDT) In-Reply-To: <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> Date: Sun, 5 Apr 2015 08:18:57 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "int-ads@ietf.org" , Terry Manderson , "rtg-ads@ietf.org" , Margaret Wasserman , Alia Atlas , Ray Bellis , "homenet@ietf.org" , "Joel M. Halpern" , Lorenzo Colitti Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 15:19:00 -0000 On Sun, Apr 5, 2015 at 6:56 AM, Juliusz Chroboczek wrote: > Sorry for the delay, I needed to think this over. > >>> In the light of the above figures -- can I trust an IETF working group >>> to understand that a huge amount of effort has been put into removing >>> mechanisms from this protocol, and to respect that work? > >> Yes, I think that the requirement for minimal mechanisms and a simple >> easy to implement and troubleshoot protocol can be clearly expressed. > > Here's some initial and incomplete input. I'm just thinking aloud, and > perhaps taking my God-given right to say something stupid. My vote is for juliusz as benevolent dictator for life. Can that go in an R= FC? > I'd like the charter to clearly state that no mechanism will be added > unless there is experimental data to show that it is necessary in > realistic situations. For example, should people believe that an > additional congestion control mechanism is needed, they will need to show > experimental data that prove their point. I think in larger lans ECN would be nice as a means of distinguishing between connectivity loss and congestive loss... but am totally willing to produce experimental data in favor for or against, and to wait til I get around to it as part of the upcoming short-RTT work. > I'd like the charter to clearly state that security considerations are > outside the scope of the base spec. The base spec says "This is > a completely insecure protocol" and I much prefer this frank admission of > failure to a half-baked solution, which would then prevent better securit= y > mechanisms from being developed. (I am not a security specialist, and > while I'm really glad about RFC 7298 (HMAC auth for Babel), I am not > competent to judge whether it is the only solution.) Agree. Security has two meanings here, one of which is not useful, one that may be. The "lets encrypt and authenticate everything" part is not terribly useful (particularly in a world that still has arp and ra). I see no reason for e2e encryption here, do see so a small one for authentication= , but am not sure it needs to be e2e. A part that *usefully* allowed a network to allow a mixture of authenticate= d nodes (injecting default routes), while retaining un-authenticated routing for other nodes would be nice. I only briefly deployed the HMAC auth, but as the quagga version fell too far behind the mainline, did not gain enough operational experience with it to have a feel for it. I look forward to seeing it in babeld-1.7. ... somewhat related ... I have a smallish bcp38-ish like document for some best current practices (like filtering out local announcements of non-rfc1918 addresses, filtering out route announcements for the hip 1.0.0.0/24, 2001:10::/28, and advice to not announce local-only vpn routes) which I could maybe finish by Prague. (On the other hand I think it is easier read if on a wik= i.) ... But it is the prospect of someone with a laptop announcing the lowest metric possible default route is through them and out via 3G that is the biggest hole in the "security" of not just babel, but all non-authentic= ated routing protocols (targeted at the home. at least. So far as I know there are a lot of insecured routing protocol *deployments* in general. Someone feel free to correct me). > I'd like the suggested metrics to remain informative appendices, contrary > to Ted's opinion. Babel's main claim to fame is that it's an extremely > flexible protocol, and putting the suggested metrics in the body of the > document is contrary with the main goal. All routing metrics to date have had various degrees of suckage. Agree. > I'd also like the other metrics > (as well as source-specific routing) to remain separate documents, since > they require extensions to the packet format. I am not sure if I share the word "metric" here for source specific routing= . I would support a rollup rfc6126.bis after several more years of deployment experience. > There is only one mechanism in the base spec that is not currently used b= y > implementations -- it's the reliable transport building block defined in > Section 3.3. It has very low cost (20 lines of code or so in the > C version), so it's a MUST, since it is only useful if implemented by all > nodes. I have no strong feelings about whether it should stay. > > It is not clear to me whether the extension mechanism should be merged > into the base spec. I think the answer is yes, but in the meantime this > should not delay the publication of > draft-chroboczek-babel-extension-mechanism-04 as an Experimental RFC. > Sorry for the underfull hbox. Can live. > The packet format is a little messy, but extremely compact, which is > useful in meshy places. I believe that Joel Halpern dislikes it, I'm not > so sure I like it myself. I hold no opinion whether it should be replace= d > by a cleaner but more costly format -- it's a difficult choice. I have no desire to further mess with the wire format at the moment. I like very much that it carries both ipv4 and ipv6 in the same packet. > -- Juliusz --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From nobody Sun Apr 5 09:18:22 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903661A88F5; Sun, 5 Apr 2015 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zz9t9sk6rMSw; Sun, 5 Apr 2015 09:18:19 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 D877C1A88C9; Sun, 5 Apr 2015 09:18:18 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so14921858obb.2; Sun, 05 Apr 2015 09:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wsZqYPOYD2pQGR5PghQBBgpmniuniFHEl3pa30oIF6w=; b=aBX9AFmJSHfQv/iZ0qXPBKIkkDDPERUEKKem3abc+PY3S77lcF1RLOmvgzZnfOfVMg X/jXNiK60ZAqrTzyPJ9VWVks11g0redCCxwvkwIVS+4gru3rfs10ZpA/mqYogAAfXICq EJrGYct26MUpFBKQYrdEkSWNMLV4cWe42CfG7ok0UdO8uJqh1UWNAIhnusv6cQkaS52c FYaz0MpAjBpFE9PFx2Ef7SSNEObMvBV2cS/3RnXeJj/nGCGrUTYtaJVwIV4rH6vaStuP rQKrlwmq35tIEZ1iTp36pq7IGn5rD4ggS6q6wATsSzSzi/QQntzKDfvduutJfs1cDLNf TmSg== MIME-Version: 1.0 X-Received: by 10.60.223.228 with SMTP id qx4mr1635688oec.24.1428250698341; Sun, 05 Apr 2015 09:18:18 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Sun, 5 Apr 2015 09:18:18 -0700 (PDT) In-Reply-To: <87zj6mtxc3.wl-jch@pps.univ-paris-diderot.fr> References: <551AC4FE.3090106@joelhalpern.com> <57AFB8D5-2F79-49DF-B251-49423506F31E@gmail.com> <551AD21B.2070400@joelhalpern.com> <87bnj8bz12.wl-jch@pps.univ-paris-diderot.fr> <87d23ivfux.wl-jch@pps.univ-paris-diderot.fr> <5521428A.1070306@cs.tcd.ie> <877ftqvek9.wl-jch@pps.univ-paris-diderot.fr> <55214794.90208@cs.tcd.ie> <874mouvdxh.wl-jch@pps.univ-paris-diderot.fr> <55214B45.3000703@cs.tcd.ie> <87zj6mtxc3.wl-jch@pps.univ-paris-diderot.fr> Date: Sun, 5 Apr 2015 09:18:18 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtg-ads@ietf.org" , "homenet@ietf.org" , "Joel M. Halpern" , Denis Ovsienko , "int-ads@ietf.org" Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 16:18:20 -0000 On Sun, Apr 5, 2015 at 8:21 AM, Juliusz Chroboczek wrote: >>>> a plan of the form "produce base spec RCC and only then start to think >>>> about security" will get pushback from me. > >>> Why? >>> >>> (If the answer is "read BCP 61", I'll do that, but not right now.) > >> Partly that and partly the horrible experience with years of delay [...] >> until we worked out a plan that was going to not result in security >> being ignored. > > Stephen, everyone, > > I would appreciate an expert opinion on RFC 7298 (HMAC for Babel), perhap= s > by private mail. Trimming the CC. I found RFC7298 to be a very good read, but me being me, found reading the code - which is much shorter - only about 1000 lines, exclusive of the actual implementations of sha1,etc, much more illuminating= . https://github.com/Quagga-RE/quagga-RE/blob/RE-stable-0.99/babeld/babel_aut= h.c > -- Juliusz --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb From nobody Sun Apr 5 19:10:45 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8351AD0C0 for ; Sun, 5 Apr 2015 19:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 9bxKj-Rw1Kgg for ; Sun, 5 Apr 2015 19:10:43 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 99A4F1AD0BF for ; Sun, 5 Apr 2015 19:10:43 -0700 (PDT) Received: by igblo3 with SMTP id lo3so12289494igb.1 for ; Sun, 05 Apr 2015 19:10:42 -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:content-type; bh=Ja48PCBqeblC0ZmuOwIpzIFnVArcR+rkp7QQoBnPU/o=; b=G1eeouVdGrItOQNXzgN6dHaxmWQRlQjcYKMNs25eO4JgiuigBaIHJWLeUuxEku3C8r Fa2PHXmhv/Md/P2S2gPeoi96V92AHwadRH5ln8DpaeAKppwlvL2DM4U6As26J8pTgZnF WvjJyOldY0ssf3ax78aJKvfCxtMUblCzMjKhOM7SAImDnLOaaeBbRt7hdWQz+7aeYhtm WfPO5ReIh8y6/S9pPQNO2wFGdY2z7PQdpXGGKXLwqZnhRbuTEAS3V/W4VyU7nyNN2s2z RSgLCXnq30yxf4DCA6sPy/PLOmEUGohnmMgQDgK4bCQR7yqoJAdE+88ZQjVpjCrpXXTn aLUA== 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-type; bh=Ja48PCBqeblC0ZmuOwIpzIFnVArcR+rkp7QQoBnPU/o=; b=HvI7MR2QNHGJfPaqjhFEinC3C6Nw2N9mcrvh7ttcgOIJYbPN9v8HdhFgFTsStJQYGX 2zG1w9lkuBXpts3UmVN8iHdBvVshhWQtcqzVu2Eqt2F9YhAb+rtlwI0Vm7g6EvRwE35x Dgvy09eX7zBf+wkKYTKH8KE27T6ibO3ZpQi1nKotgpDZjdto8UxU8ocMMUhmjQ/NHFYp GvWFJUSfd66w2Sp0y/laLavtUptID4iKpzxvFLlG2riS13pOW196MG6MynQBReHWInwm NEMES1HIflSEvEEu1sXc9iVyXILQG8ih0hfXBKnbCL/kL7We8Sx6xbAjnqPsDaxCeXFh MbYg== X-Gm-Message-State: ALoCoQkq31uDM7wEVlD4pt1uBG+TFdEdD/viF/Kfp76eU+HTEQkAzNnPlTYLY9WsSWvJD4g+PWSq X-Received: by 10.43.72.138 with SMTP id yo10mr16872228icb.69.1428286242861; Sun, 05 Apr 2015 19:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Sun, 5 Apr 2015 19:10:22 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 6 Apr 2015 11:10:22 +0900 Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=001a11c204fe24dce7051304ce50 Archived-At: Cc: HOMENET , "babel-users@lists.alioth.debian.org" Subject: Re: [homenet] stupid babel tricks: routing ipv6 while keeping nat X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 02:10:45 -0000 --001a11c204fe24dce7051304ce50 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 4, 2015 at 2:46 AM, Dave Taht wrote: > Then I can arbitrarily give myself a real /128 ipv6 address from some > range elsewhere on my source specific routed network - not even adding > an ipv6 address to the router in question... > > and it automagically transits the network in that direction, even the > hops that have no or a ula-only ipv6 address. The only thing this > bugs is traceroute, it is transparent to other applications. > Why would you want to use a /128? Don't you have enough address space for a /64 per link? --001a11c204fe24dce7051304ce50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 4, 2015 at 2:46 AM, Dave Taht <dave.taht@gmail.com> wrote:
Then I can arbitrarily give myse= lf a real /128 ipv6 address from some
range elsewhere on my source specific routed network - not even adding
an ipv6 address to the router in question...

and it automagically transits the network in that direction, even the
hops that have no or a ula-only ipv6 address.=C2=A0 The only thing this
bugs is traceroute, it is transparent to other applications.

Why would you want to use a /128? Don't you have = enough address space for a /64 per link?
--001a11c204fe24dce7051304ce50-- From nobody Mon Apr 6 01:54:33 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5011A1EF2 for ; Mon, 6 Apr 2015 01:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 weUnuWxciaxd for ; Mon, 6 Apr 2015 01:54:30 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 801551A1EEA for ; Mon, 6 Apr 2015 01:54:30 -0700 (PDT) Received: by obvd1 with SMTP id d1so32208184obv.0 for ; Mon, 06 Apr 2015 01:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rgYrH8ln553sGvEZFbGftm5lMazD3X+tQ7+7F9vVnIw=; b=H70x7CB145vyGgdukVDcMcijAs2m6f/QidWU28pCEsqxC/lja6LVWy/W3AyPIWiLN/ JxkdM3OCzGwy3QlipmCun7vLuiGDLFYAMXG7iPC5AIIvEfaHL+rH+ZIkPf8iwkb0Xf2n JN/Q2K35KCMZmz3e8H2Y9KpOpJu3QZT98fsRmdH5XqhLI7rvUpdq9JKT1Mn84weDaup2 6URhkFX0Ga38s5FfDzbyRwhEZ5Eb+sPvpVVC2CASZv9U9CelTauVCwtRVYAQ0ZY8iNnY Cad86MEm0K+TVjQkgNsB2PfAbjmrOJMlpIrtkmF8NVMBcZXbsVEHKslVVn0H5VLjNbzj yiIQ== X-Received: by 10.182.87.8 with SMTP id t8mr17418242obz.35.1428310469967; Mon, 06 Apr 2015 01:54:29 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.40.102 with HTTP; Mon, 6 Apr 2015 01:54:09 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Mon, 6 Apr 2015 10:54:09 +0200 X-Google-Sender-Auth: wslaPEDDvP0YG_gyT7jmSr4UIJY Message-ID: To: HOMENET Content-Type: multipart/alternative; boundary=089e013c705431052505130a72e8 Archived-At: Cc: "babel-users@lists.alioth.debian.org" Subject: Re: [homenet] stupid babel tricks: routing ipv6 while keeping nat X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 08:54:32 -0000 --089e013c705431052505130a72e8 Content-Type: text/plain; charset=UTF-8 Hi Lorenzo, I'm not sure I fully grasp all the details of the debate about Babel here, but here is an RFC recommending /128 are the way to go on similar "links". https://tools.ietf.org/html/rfc5889 And if you want to read more about why these recommendations came about, read this: http://www.ietf.org/id/draft-baccelli-intarea-adhoc-wireless-com-00.txt Best, Emmanuel On Mon, Apr 6, 2015 at 4:10 AM, Lorenzo Colitti wrote: > On Sat, Apr 4, 2015 at 2:46 AM, Dave Taht wrote: > >> Then I can arbitrarily give myself a real /128 ipv6 address from some >> range elsewhere on my source specific routed network - not even adding >> an ipv6 address to the router in question... >> >> and it automagically transits the network in that direction, even the >> hops that have no or a ula-only ipv6 address. The only thing this >> bugs is traceroute, it is transparent to other applications. >> > > Why would you want to use a /128? Don't you have enough address space for > a /64 per link? > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > --089e013c705431052505130a72e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lorenzo,
I'm not sure I fully grasp all the det= ails of the debate about Babel here, but here is an RFC recommending /128 a= re the way to go on similar "links".
https://tools.ietf.org/html/rfc5889
And if you want to read more about why these recommendations came = about, read this:=C2=A0http://www.ietf.org/id/dra= ft-baccelli-intarea-adhoc-wireless-com-00.txt
Best,
Emmanuel

On Mon, Apr 6, 2015 at 4:10 AM, Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com" target=3D"_blank">lorenzo@google.com> wrote:
On Sat,= Apr 4, 2015 at 2:46 AM, Dave Taht <dave.taht@gmail.com> w= rote:
Then I can arbitrarily give myself = a real /128 ipv6 address from some
range elsewhere on my source specific routed network - not even adding
an ipv6 address to the router in question...

and it automagically transits the network in that direction, even the
hops that have no or a ula-only ipv6 address.=C2=A0 The only thing this
bugs is traceroute, it is transparent to other applications.

Why would you want to use a /128? Don't yo= u have enough address space for a /64 per link?

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


--089e013c705431052505130a72e8-- From nobody Mon Apr 6 19:39:27 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985971AD0A9; Mon, 6 Apr 2015 19:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VDMBNsBTpkdb; Mon, 6 Apr 2015 19:39:23 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615B41AD0A5; Mon, 6 Apr 2015 19:39:23 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 6 Apr 2015 19:39:21 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Mon, 6 Apr 2015 19:39:21 -0700 From: Terry Manderson To: "homenet@ietf.org" Thread-Topic: [homenet] Selecting a routing protocol for HOMENET Thread-Index: AQHQZ9+CkO2MczRTM02qGhfBQR2ymp0vcEmAgADABgD//4R8gIAAHxwAgAgDboCACi33AA== Date: Tue, 7 Apr 2015 02:39:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3511255152_20397328" MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "int-ads@ietf.org" Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 02:39:25 -0000 --B_3511255152_20397328 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit WG, In reviewing the posts on this thread over the last several days, I note that no-one spoke strenuously against the Design Team (DT) as chartered. There were several emails that implied support of the DT, and many others seeking conditions that the DT take on board comments for their review. The DT will be chartered as below. I will advise the DT to review this thread and to take on board the comments that are germane to their work of selecting the mandatory to implement HOMENET routing protocol. Thank you for all your comments! I urge the WG to now focus on the work ahead, and wait patiently for the DT response in Prague. Cheers Terry On 1/04/2015 1:12 am, "Terry Manderson" wrote: > >=-=-=-=-=-=-=-=- > >Homenet's architecture (RFC 7368) articulates the general features >required. The working group has agreed that a single routing protocol >must be identified as mandatory to implement. The final purpose of >this design team is to select and present a single routing protocol >with a summary of the necessary extensions and work to be the one that >is mandatory to implement. Once the design team has made its >recommendation, the working group will consider any substantial >technical objections (see RFC 7282) as part of gaining consensus. > >For the design team to make this determination, it shall first >understand the use-cases for homenet and derive routing requirements >from those. Then it shall compare these routing requirements to >candidate routing protocols and examine the gaps in each. For each >highly plausible candidate routing protocol, the design team will >estimate the work and actions needed, the resources at hand >or reasonably available, and the associated timeline to get >an acceptable, full, standardized solution using each protocol. >Based upon this information and the perceived market timing >needs of the technology, the design team will make its selection. >The requirements, gaps, and reasoning will be documented. > >This document should be delivered by the July 2015 IETF. > >=-=-=-=-=-=-=-=- > >So with no more emails on the thread, I'm marking the above as the final >design team charter and I now ask the WG to comment by midnight Friday the >3rd April (UTC) of either accepting the design team, or not. I will judge >consensus at that point, remembering that silence doesn't help. > > >Pending consensus, and at the appropriate time I will direct the design >team to read the advice from Steven, Alexandru, and James posted here for >their consideration. --B_3511255152_20397328 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFKwa j8z8JXW1pz3iF8s0QolTD6X6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDQwNzAyMzkxMlowDQYJKoZIhvcNAQEBBQAEggEASALA58BN1KQBG/HHZ4Rh 3DRr6ZmGGU29xlbh9jrbG+KNyPuLJjqodcbVTi94FR4PBHB/o1RQ9if9QpJ1m8hEfsOwFvIT 4GA4cEz93yuUIVJkE+uWMwiZiS+ouQCO5xYChDPqSvhTpMIF7DED98qefGT8LZY2xrTPTzg/ 48BAXdGG1xBuye4iUR7Waq66JC0fF6uUqvzLeojWSB/R38CUOJUlRHzmi4FFgHNipT9V91Aw k9Wtrl7E2bkemiD1jW8bWThoRtyte0JQ0b71qRjv14bSC9YsOlpW0s+kZj3HOcZOvSRRoNzd T7UrfbZHsmaDQoWaMNkTni9UN/L1ZuO5AA== --B_3511255152_20397328-- From nobody Tue Apr 7 03:48:23 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709A11B3413; Tue, 7 Apr 2015 03:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 M6dNjgtQkmqb; Tue, 7 Apr 2015 03:48:20 -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 CFD191A1EF9; Tue, 7 Apr 2015 03:48:19 -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/56100) with ESMTP id t37AltYE027392; Tue, 7 Apr 2015 12:47:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D0BD62A0C46; Tue, 7 Apr 2015 12:47: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 A5Y8X4l6XvBy; Tue, 7 Apr 2015 12:47:54 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6332C2A0C0A; Tue, 7 Apr 2015 12:47:53 +0200 (CEST) Date: Tue, 07 Apr 2015 12:47:53 +0200 Message-ID: <87zj6k6wpy.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Terry Manderson In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 07 Apr 2015 12:47:56 +0200 (CEST) X-Miltered: at korolev with ID 5523B5DB.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5523B5DB.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 : 5523B5DB.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: "rtg-ads@ietf.org" , "homenet@ietf.org" , "int-ads@ietf.org" Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 10:48:21 -0000 > The DT will be chartered as below. I find the lack of the words "working code", "implementation experience" or "experimental data" somewhat disquieting. With frustrated regards, -- Juliusz Chroboczek From nobody Tue Apr 7 05:35:24 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764CB1A87A7; Tue, 7 Apr 2015 05:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 21PkAs4OxwiF; Tue, 7 Apr 2015 05:35:22 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083221A87A3; Tue, 7 Apr 2015 05:35:22 -0700 (PDT) Received: by qkx62 with SMTP id 62so49806879qkx.0; Tue, 07 Apr 2015 05:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GON/rBj4HgtO6wK/50FmhxId979EuFsj1yeeYAPvCX8=; b=FojOW+icSKn8wngFDxmf2EWApMRJm/jOK7JW4rQSZIXphFGR5+prQo9j7Mwdate8ty aMtycSIcI/9VogXsOL0ILgoeyhtlN9n2ESrq84xdkaPJNlxVJvZL5T4cu9H9fnefYlGq 7YIs6HJlnvsoIG6t9sU6pKrx/QFPv9CVeTTA1IGvcAbgsvR2Z4IRupJ+a9x/K7ZjeJ67 jpiGQvhJogNBkbJn0HW+q+TB0BhrBkUG7ouDaUITxFUhpbYb7X+4pWY1JWR+F71YmgpW Bt3idFgeG5J/svT6IEuvPUMOLVp7bwho4XAd78/w5InZgMvcmNy7aB8qjMQmFGK/ooMd 81NA== X-Received: by 10.55.23.16 with SMTP id i16mr12141168qkh.14.1428410121237; Tue, 07 Apr 2015 05:35:21 -0700 (PDT) Received: from [172.20.10.2] (mobile-107-107-60-2.mycingular.net. [107.107.60.2]) by mx.google.com with ESMTPSA id f33sm5235916qkh.23.2015.04.07.05.34.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Apr 2015 05:35:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <87zj6k6wpy.wl-jch@pps.univ-paris-diderot.fr> Date: Tue, 7 Apr 2015 08:32:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <651BFE39-4CC8-4017-9C76-BA6E76129C89@gmail.com> References: <87zj6k6wpy.wl-jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek , Terry Manderson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtg-ads@ietf.org" , "homenet@ietf.org" , "int-ads@ietf.org" Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 12:35:23 -0000 > On Apr 7, 2015, at 6:47 AM 4/7/15, Juliusz Chroboczek = wrote: >=20 >> The DT will be chartered as below. >=20 > I find the lack of the words "working code", "implementation = experience" > or "experimental data" somewhat disquieting. I think the umbrella direction for requirements could be considered to = cover those specifics: >> For the design team to make this determination, it shall first >> understand the use-cases for homenet and derive routing requirements >> from those. Terry - you might consider adding a pointer to RFC 7368 as an explicit = source of input for the requirements. - Ralph >=20 > With frustrated regards, >=20 > -- Juliusz Chroboczek >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Tue Apr 7 18:57:15 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8A1B2B0C for ; Tue, 7 Apr 2015 18:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 SQ95b1EUOvG2 for ; Tue, 7 Apr 2015 18:57:09 -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 7E55E1B2AFD for ; Tue, 7 Apr 2015 18:56:53 -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/56100) with ESMTP id t381unjl026609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2015 03:56:49 +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 t381unQB005914; Wed, 8 Apr 2015 03:56:49 +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 F421861F9D; Wed, 8 Apr 2015 03:56: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 lkwIywusD7ze; Wed, 8 Apr 2015 03:56:46 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 137E861F9A; Wed, 8 Apr 2015 03:56:45 +0200 (CEST) Date: Wed, 08 Apr 2015 03:56:46 +0200 Message-ID: <87a8yje61t.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Stephen Farrell User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 08 Apr 2015 03:56:50 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 08 Apr 2015 03:56:49 +0200 (CEST) X-Miltered: at korolev with ID 55248AE1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 55248AE1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55248AE1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 55248AE1.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 : 55248AE1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 55248AE1.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: homenet@ietf.org Subject: [homenet] Security considerations for the Babel routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 01:57:11 -0000 Dear Stephen, Following your request of 5 April 2015, I have published the following Internet-Draft: Security considerations for the Babel routing protocol draft-chroboczek-babel-security-considerations-00 I also attract your attention to the following RFC: RFC 7298: Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication I hope that these documents alleviate your concerns about the Babel community not thinking about security hard enough. Should you have any further inquiries, please do not hesitate to contact me, and I'll do my best, time permitting, to update the security considerations document. With respectful regards, -- Juliusz Chroboczek From nobody Wed Apr 8 00:24:09 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1081A032D; Wed, 8 Apr 2015 00:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 rq59Sn4E3hnG; Wed, 8 Apr 2015 00:24:07 -0700 (PDT) Received: from globis01.globis.net (092-111-140-212.static.chello.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1658A1A02BE; Wed, 8 Apr 2015 00:24:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D7FF640332; Wed, 8 Apr 2015 09:24:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GINgadICibaj; Wed, 8 Apr 2015 09:24:02 +0200 (CEST) Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:418c:b8ab:ae4f:3091]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id B446040182; Wed, 8 Apr 2015 09:24:01 +0200 (CEST) Message-ID: <5524D78F.3070809@globis.net> Date: Wed, 08 Apr 2015 09:23:59 +0200 From: Ray Hunter User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Ralph Droms References: <87zj6k6wpy.wl-jch@pps.univ-paris-diderot.fr> <651BFE39-4CC8-4017-9C76-BA6E76129C89@gmail.com> In-Reply-To: <651BFE39-4CC8-4017-9C76-BA6E76129C89@gmail.com> Content-Type: multipart/alternative; boundary="------------010802020305060600050606" Archived-At: Cc: "rtg-ads@ietf.org" , "homenet@ietf.org" , Terry Manderson , "int-ads@ietf.org" , Juliusz Chroboczek Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 07:24:08 -0000 This is a multi-part message in MIME format. --------------010802020305060600050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ralph Droms wrote: >> On Apr 7, 2015, at 6:47 AM 4/7/15, Juliusz Chroboczek wrote: >> >>> The DT will be chartered as below. >> I find the lack of the words "working code", "implementation experience" >> or "experimental data" somewhat disquieting. +1 I'd like to see a DT with hands on experience of running Homenet code before IETF 93 in Prague, and that they give this appropriate weight in any considerations. > I think the umbrella direction for requirements could be considered to cover those specifics: > >>> For the design team to make this determination, it shall first >>> understand the use-cases for homenet and derive routing requirements >>> from those. > > Terry - you might consider adding a pointer to RFC 7368 as an explicit source of input for the requirements. +1 The WG achieved rough consensus on Section 3.5 of RFC 7368. That should be the baseline for any beauty contest of routing protocols for Homenet. > - Ralph > >> With frustrated regards, >> >> -- Juliusz Chroboczek >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > --------------010802020305060600050606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Ralph Droms wrote: 
On Apr 7, 2015, at 6:47 AM 4/7/15, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:


The DT will be chartered as below.

I find the lack of the words "working code", "implementation experience"
or "experimental data" somewhat disquieting.
+1 I'd like to see a DT with hands on experience of running Homenet code before IETF 93 in Prague, and that they give this appropriate weight in any considerations.
I think the umbrella direction for requirements could be considered to cover those specifics:


For the design team to make this determination, it shall first
understand the use-cases for homenet and derive routing requirements
from those.


Terry - you might consider adding a pointer to RFC 7368 as an explicit source of input for the requirements.
+1 The WG achieved rough consensus on Section 3.5 of RFC 7368. That should be the baseline for any beauty contest of routing protocols for Homenet.

- Ralph


With frustrated regards,

-- Juliusz Chroboczek

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--------------010802020305060600050606-- From nobody Wed Apr 8 03:35:12 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40F1B2F37 for ; Wed, 8 Apr 2015 03:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PlH7cDEl6bYa for ; Wed, 8 Apr 2015 03:35:08 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 859211B2F3A for ; Wed, 8 Apr 2015 03:35:04 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=NgcNGih0eiWeCw3SjAJ56ssHmBn3XLO2hYvqlCJdgCVYwYgLVSfmkz+a fFF3ppP/LXZn9hbhENzytBGNMIN90Xi+MC3W8V+jnZ8ev6t5lfd7z0FiT MZU1ap8Jl5+eosSF5tr3f/+aDdWhNR0x6PejxQFiO3aJDc5kUDJnQzg9a a/Kp8Bx4/KRei8NEcTA6gLjWdb2FfY4hSyuzQQzi3MkonRYQ3SSNfrXUK FBOC+u7Fb9Vet8MhHHRvS9z+k4t16; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1428489305; x=1460025305; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=L/X+kshMAW8GuS7ZnnW0ZXsnz9dKNtM0j/xitCvdpRQ=; b=yRbWJ1q2+vri5ygTllfAKhTqiZJZ7S/qLLfNhUrMkL9Ma9kP8DAagvRo YGAg4bCUOhpqUNOC8gF2w3PSqGCuPBTt93VpbmFLv8h6uztHowFRhFojh gCeiv2UwBgav9Wx+7fCIzvEzU1AcAVm+O1vdwJqlWab0a4lQnigKchEPp 5TtUxpp68ILHZdo7LRoHPjBlOgaUTVoeyQokcWFW8CJGJhCjXfZ/UNvh5 s/lq/LLFBzDnytMyKYZY9FhSVErYc; X-IronPort-AV: E=Sophos;i="5.11,543,1422921600"; d="scan'208";a="18093745" X-IPAS-Result: A2DaBQDlAiVV/5HF+NVcgmYiUkQdthkBjxkPhy07EQEBAQEBAQF9hCZTOAGBACcEiD4DCaUdpjYLAQEBAQEYBJNFgRYFinaRIoM3kAcig2+CM38BAQE Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 08 Apr 2015 11:35:03 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0224.002; Wed, 8 Apr 2015 11:35:03 +0100 From: Ray Bellis To: HOMENET Thread-Topic: IETF92 WG session draft minutes upload Thread-Index: AQHQceerQ7Wk+qRuzEWjuEN1JetaIA== Date: Wed, 8 Apr 2015 10:35:01 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5DD83791FE3E9B44AB718975E3BBC756@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [homenet] IETF92 WG session draft minutes upload X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 10:35:10 -0000 The notes from the Dallas WG session (thanks =D8le!) are now available at: https://www.ietf.org/proceedings/92/minutes/minutes-92-homenet Please let me know if you have any corrections not later than April 24th. thanks, Ray From nobody Wed Apr 8 03:50:19 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD8D1B2F5D for ; Wed, 8 Apr 2015 03:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 laIYrgsNCmTK for ; Wed, 8 Apr 2015 03:50:17 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9521B2F5B for ; Wed, 8 Apr 2015 03:50:17 -0700 (PDT) Received: by igbqf9 with SMTP id qf9so34778177igb.1 for ; Wed, 08 Apr 2015 03:50:17 -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:content-type; bh=xjoD/pLO3NR51yGApvOyj7PTOzIfi2o0N02BkoopU5o=; b=kYUi+7RpfWLsU2wkPTAaO+6Oyo4fQTgqApRxqqSaZkXX43kqfGrXiSr+QbwSsC4CPr JtkWfB/Traui4/58Di6mCRG52wo7R9HlewCJqs1u9W8jm3HZ+Q4wuRm2F5OM/uRjWCaE 5xHyXWl1nejWa+bma2j9y2HFtmXVXMWxl5pOYgPso4pj2saE3MRqWMqYud22CMZYNDJL Frktc62COYjza8aaUOYj00ghyaoGmLxw7ES4TUf4W9MzvZHkfocaYuCv7zOzVencZhCf aAsTbwB57sgh1P8/Hrka/t/VA+kLhE3kVdWsw94L0UcscE2E/oh/9z7BLTYpq+ueWHa3 RnYg== 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-type; bh=xjoD/pLO3NR51yGApvOyj7PTOzIfi2o0N02BkoopU5o=; b=g1GidyB13X/Cg73pcSBXDJn35kV+TSL1U94kx4hsofJxSByS7DUKdv9FLGk05kBxN0 robGMTfeaIKq3Epknkcz2K/xtvWH7xxxb2Qh+68Arfgp9QyGkRzWraf1+E0vRmaAo0J4 f3t7ZPKLDQ+O8yLtpyk+aHFobQrIhjuN4Z4/4cvI5mu/Qpg5D3fM8kXS7eOQhhYBviMl V0S5m8gmNRY6PUDibbVUqOhe2eslgR+zMfCFcV3Pkk7bvNQ1QMXOv/1eM+eFqyshQO0z iYf3PBjmcnoJcRj/0Bi+/XLD6bn32Nq4lXxc0UdoZ+sr8ndd+YEnv8dFaIU9zR8aiWY+ +Agg== X-Gm-Message-State: ALoCoQlixXq4IZOKlGS+CbqUNan+A4hgvzHd8LMaoq8jCg8u9tidCHFwoONAsKSJjwZKylKEnIJX X-Received: by 10.50.221.98 with SMTP id qd2mr10806468igc.37.1428490216984; Wed, 08 Apr 2015 03:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Wed, 8 Apr 2015 03:49:56 -0700 (PDT) In-Reply-To: <5524D78F.3070809@globis.net> References: <87zj6k6wpy.wl-jch@pps.univ-paris-diderot.fr> <651BFE39-4CC8-4017-9C76-BA6E76129C89@gmail.com> <5524D78F.3070809@globis.net> From: Lorenzo Colitti Date: Wed, 8 Apr 2015 19:49:56 +0900 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=001a11347f20f30bbc0513344beb Archived-At: Cc: "int-ads@ietf.org" , Juliusz Chroboczek , "rtg-ads@ietf.org" , Ralph Droms , "homenet@ietf.org" , Terry Manderson Subject: Re: [homenet] Selecting a routing protocol for HOMENET X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 10:50:18 -0000 --001a11347f20f30bbc0513344beb Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 4:23 PM, Ray Hunter wrote: > Terry - you might consider adding a pointer to RFC 7368 as an explicit source of input for the requirements. > > +1 The WG achieved rough consensus on Section 3.5 of RFC 7368. That > should be the baseline for any beauty contest of routing protocols for > Homenet. > +1, although one would hope that it goes without saying that a routing protocol that does not meet the requirements in RFC 7368 cannot be chosen. --001a11347f20f30bbc0513344beb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 8, 2015 at 4:23 PM, Ray Hunter <v6ops@globis.net> wro= te:
Terry - you might consider adding a pointer to RFC 7368 as a=
n explicit source of input for the requirements.
+1 The WG achieved rough consensus on Section 3.5 of RFC 7368. That=20 should be the baseline for any beauty contest of routing protocols for=20 Homenet.

+1, although one would hope = that it goes without saying that a routing protocol that does not meet the = requirements in RFC 7368 cannot be chosen.
--001a11347f20f30bbc0513344beb-- From nobody Wed Apr 8 06:33:20 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A271A86F0; Wed, 8 Apr 2015 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 qlYY6yA5JmJl; Wed, 8 Apr 2015 06:33:18 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 DE8AC1A86E9; Wed, 8 Apr 2015 06:33:17 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so63105065obb.3; Wed, 08 Apr 2015 06:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pLRe94BtDstXH0D5AyyBIr5IqltgkzBURO3JcpDFXXM=; b=Mge2lwypgi3U6bVDcH3vuYqcl+sWDHxZz0KpV10DyyGtzEucgLTFLktR0QzfScoIVA ZJnLPDh7qshDJuOypuuA7kUvYmOnbNj6KixEjzkSwZVtBlXeFZrTHhH4wDyaUFFrJ6rD rMNoJQkB/Fd9mjYApAhyhuTijNeGDgOJNsgiRiURMvDNRChzuiA5hCBjdH4X/cXNrPTV SGpYEBjXP64ivFp7533AFffPTP69AJfmGQJbGj+CTz5oNjFOi39FddzNtIDz58858Tes A3XVlY4Y5Zlml+Z9+Drxo8yZPgsNeXmKFaGPf8O58otVyFouXHcVKpAT7Pdoz3IOkDYW F3Cw== MIME-Version: 1.0 X-Received: by 10.182.91.5 with SMTP id ca5mr31251921obb.54.1428499987296; Wed, 08 Apr 2015 06:33:07 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Wed, 8 Apr 2015 06:33:07 -0700 (PDT) Date: Wed, 8 Apr 2015 09:33:07 -0400 Message-ID: From: Alia Atlas To: HOMENET Content-Type: multipart/alternative; boundary=e89a8fb1ee244df8240513369244 Archived-At: Cc: "int-ads@ietf.org" Subject: [homenet] Homenet Design Team for Routing Protocol Selection X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 13:33:19 -0000 --e89a8fb1ee244df8240513369244 Content-Type: text/plain; charset=UTF-8 Terry's email on April 6 confirmed that Homenet will use the approach of having a Design Team to select the one mandatory-to-implement routing protocol. The charter for the design team, as sent in his email, is below. I am happy to also announce the membership of the design team with many thanks to them for taking on this time-consuming and critical job. Russ White (lead) Margaret (Wasserman) Cullen Ralph Droms Philippe Klein Wes George Ross Callon The design team has a private mailing list homenet-dt-routing@ietf.org for their internal communication. The design team members are the only ones on that mailing list. Charter: "Homenet's architecture (RFC 7368) articulates the general features required. The working group has agreed that a single routing protocol must be identified as mandatory to implement. The final purpose of this design team is to select and present a single routing protocol with a summary of the necessary extensions and work to be the one that is mandatory to implement. Once the design team has made its recommendation, the working group will consider any substantial technical objections (see RFC 7282) as part of gaining consensus. For the design team to make this determination, it shall first understand the use-cases for homenet and derive routing requirements from those. Then it shall compare these routing requirements to candidate routing protocols and examine the gaps in each. For each highly plausible candidate routing protocol, the design team will estimate the work and actions needed, the resources at hand or reasonably available, and the associated timeline to get an acceptable, full, standardized solution using each protocol. Based upon this information and the perceived market timing needs of the technology, the design team will make its selection. The requirements, gaps, and reasoning will be documented. This document should be delivered by the July 2015 IETF." Regards, Alia --e89a8fb1ee244df8240513369244 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Terry's email on April 6 confirmed that Homenet w= ill use the approach
of having a Design Team to select the one ma= ndatory-to-implement
routing protocol. =C2=A0 The charter for the= design team, as sent in his email,
is below. =C2=A0
I am happy to also announce the membership of the design team = with
many thanks to them for taking on this time-consuming and cr= itical job.

Russ White (lead)
Margaret (= Wasserman) Cullen
Ralph Droms
Philippe Klein
= Wes George
Ross Callon

The design team h= as a private mailing list ho= menet-dt-routing@ietf.org
for their internal communication. = =C2=A0 The design team members are the
only ones on that mailing = list.

Charter:

"Homenet&#= 39;s architecture (RFC 7368) articulates the general features
required.= =C2=A0 The working group has agreed that a single routing protocol
must = be identified as mandatory to implement.=C2=A0 The final purpose of
this= design team is to select and present a single routing protocol
with a s= ummary of the necessary extensions and work to be the one that
is mandat= ory to implement.=C2=A0 Once the design team has made its
recommendation= , the working group will consider any substantial
technical objections (= see RFC 7282) as part of gaining consensus.

For the design team to m= ake this determination, it shall first
understand the use-cases for home= net and derive routing requirements
from those.=C2=A0 Then it shall comp= are these routing requirements to
candidate routing protocols and examin= e the gaps in each.=C2=A0 For each
highly plausible candidate routing pr= otocol, the design team will
estimate the work and actions needed, the r= esources at hand
or reasonably available, and the associated timeline to= get
an acceptable, full, standardized solution using each protocol.
= Based upon this information and the perceived market timing
needs of the= technology, the design team will make its selection.
The requirements, = gaps, and reasoning will be documented.

This document should be deli= vered by the July 2015 IETF."

Regards,
Alia
--e89a8fb1ee244df8240513369244-- From nobody Wed Apr 8 06:49:01 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149B21A876B for ; Wed, 8 Apr 2015 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fuIOeMLaFSJZ for ; Wed, 8 Apr 2015 06:48:59 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 24FA81A876A for ; Wed, 8 Apr 2015 06:48:59 -0700 (PDT) Received: from [10.0.20.174] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 692BA2380CAC for ; Wed, 8 Apr 2015 09:48:58 -0400 (EDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9C103660-A36F-4AA9-A2C2-BADF89401341@fugue.com> Date: Wed, 8 Apr 2015 09:48:56 -0400 To: HOMENET Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [homenet] How is prefix delegation handled on OpenWRT/CeroWRT in a homenet configuration? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 13:49:01 -0000 Sorry to delve into an operational question when we're having so much = fun discussing layer 9 stuff, but are any of the OpenWRT folks around = who could tell me what OpenWRT is doing to get its delegation from the = ISP? ISC DHCP? dhcpcd? dnsmasq? I ask because I want to replicate a homenet environment at home, but my = edge router is a server running Ubuntu, and I don't want to put a Wifi = router between it and the internet. Clues appreciated. From nobody Wed Apr 8 06:55:21 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116351A8792 for ; Wed, 8 Apr 2015 06:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ahl_XqCxwL7u for ; Wed, 8 Apr 2015 06:55:18 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001: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 02C521A879F for ; Wed, 8 Apr 2015 06:55:17 -0700 (PDT) Received: by igblo3 with SMTP id lo3so38644388igb.0 for ; Wed, 08 Apr 2015 06:55:16 -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:content-type; bh=yRjwYG05uRAzqpgCVqQfpcdnOAd0cWGrJ4hXcP2shfc=; b=LJHYknnwGR1EBRrpnUorbptEgWdEE1hvopyjlnT/tLlYwXz93LVlbeQdJXWukC9pFs 4zhjFZpbznqXxAVKJVILvRP+L+80CvBoF/r9Fb9QwHSMlLIbvseVm8P+AXxfsbs+eUBH kzlbcQ4bCNqEKk0OO/moFyI3GJUPVMkIlEcNDuocPUWiscaTVR+0D6dSgRR3629FYc5k vuVvLsYB3kuicVOU6voSOLOpfcvejIIuIWHya3lIPPHzBFdAaLjEJLEqOwJEq49x+4zQ eVQHV7F9pMMdpwDmvThvGQhizvASg6bck4GmbsF/Qe88fxjPu+EjVKRVBSnEbXtsYv1m Ym/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yRjwYG05uRAzqpgCVqQfpcdnOAd0cWGrJ4hXcP2shfc=; b=VduGbCD0glCEMeA7Adhjyuv3MOotTI4T4/AD/zt7sEHJO4PvuQNrDcBtLq7Tfc6FPY e2p0PTaoiwaK6jtT4rsBZ/w9K5jXN+hlm7T2UEW0pS29H5zRSVIGQsQSUZ2Ud5vVoNqv xAe/d0Uy8aebcSs1IJ7kLb9GDatnEWIoSNe0nlSb+cW0rMCiqYRFRxMSquerGTm2Dhog cDpNqyqLOFbuEZMr0N57aR3ziQfPfOE52fECndInGd5FmWb/qJSHZRQO4wJac1qwfZyH SnnjvU3KZLGwID6Aqh62sEOUpXlGv4sJdl7CbqnfCjyT8gfAPtzblN7OkOzU+pKrCG2E Ah9g== X-Gm-Message-State: ALoCoQlt2Ia1jiwKHHxYkC/SMguNQizu3cEQGT1kkxvguoAKBfcSyGklx3QcSoQjPPNX9LxSDC9d X-Received: by 10.107.34.210 with SMTP id i201mr39053550ioi.1.1428501316523; Wed, 08 Apr 2015 06:55:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Wed, 8 Apr 2015 06:54:56 -0700 (PDT) In-Reply-To: <9C103660-A36F-4AA9-A2C2-BADF89401341@fugue.com> References: <9C103660-A36F-4AA9-A2C2-BADF89401341@fugue.com> From: Lorenzo Colitti Date: Wed, 8 Apr 2015 22:54:56 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a114031a0888b54051336e11f Archived-At: Cc: HOMENET Subject: Re: [homenet] How is prefix delegation handled on OpenWRT/CeroWRT in a homenet configuration? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 13:55:20 -0000 --001a114031a0888b54051336e11f Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 10:48 PM, Ted Lemon wrote: > Sorry to delve into an operational question when we're having so much fun > discussing layer 9 stuff, but are any of the OpenWRT folks around who could > tell me what OpenWRT is doing to get its delegation from the ISP? ISC > DHCP? dhcpcd? dnsmasq? > https://github.com/sbyx/odhcpd I ask because I want to replicate a homenet environment at home, but my > edge router is a server running Ubuntu, and I don't want to put a Wifi > router between it and the internet. Clues appreciated. > Run a DHCPv6 server on the ubuntu box? --001a114031a0888b54051336e11f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 8, 2015 at 10:48 PM, Ted Lemon <mellon@fugue.com> wro= te:
Sorry to delve into an operational question when we= 're having so much fun discussing layer 9 stuff, but are any of the Ope= nWRT folks around who could tell me what OpenWRT is doing to get its delega= tion from the ISP?=C2=A0 =C2=A0ISC DHCP?=C2=A0 =C2=A0dhcpcd?=C2=A0 dnsmasq?=


I ask because I want to replicate a homenet environment at home, but my e= dge router is a server running Ubuntu, and I don't want to put a Wifi r= outer between it and the internet.=C2=A0 =C2=A0Clues appreciated.

Run a DHCPv6 server on the ubuntu box?
--001a114031a0888b54051336e11f-- From nobody Wed Apr 8 06:57:23 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FC81A8820 for ; Wed, 8 Apr 2015 06:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 br8rlcImJneQ for ; Wed, 8 Apr 2015 06:57:21 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 A88431A87EB for ; Wed, 8 Apr 2015 06:57:21 -0700 (PDT) Received: by igblo3 with SMTP id lo3so39794912igb.1 for ; Wed, 08 Apr 2015 06:57:21 -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:content-type; bh=b0XKsdCCSI8YuhXrjaYORBMnUn07nkOksAbjDqzbWxA=; b=a30TS57xTwUN2j5Dyk5EqNZjYUZF5UW8HZ6OmVwv63X3AolGqrJPzMt5wPY+7iScQS YJI0mfuXUXZ5vueSI4vAm2Cdw/bcuEe5P6QvTiddXPAeqUR2LcX0H3PmW8l9INhCihTl BTMav7mq10ARCL4v5NkWmvpmtsCvQdQ3TW6GbCPh9bPvDC18t8TklU0nFgEYK7NbCKs3 h4qrj8kf1DN2sNoQl9bV2L6J0fj/fXsbotCIoww3nd5b/wAECmux3QhU4bNmZETCEKCt 4oBmK4jml2iZnZoZPD2P8vMzBGZiBIEJc44i6uLyWeMERvutF7ed3xZRjr7lPiVIsfEH 5LTA== 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-type; bh=b0XKsdCCSI8YuhXrjaYORBMnUn07nkOksAbjDqzbWxA=; b=gCvAVuylw402D5pgb8OGHRfGG4PdphBb1Op8DEsWH2qyP3qCIbHkwLiyIHMPThYIaY 7H7B/T6O8zKtmcFeS+zvXe4/lwiTZm2WxyqrMTFpuGslGpW8iT6ultohSRQJEQG3ER/F LFC5mxIFmpBlGvH2UOhNODD3Yht4qkCst/GpeuPXlX6/gLT8kurP4cf74FSKZ2c+YdXv pwjut35YdUN+KMkdtyvYI0vGEIVnmIke9UInwWXp5A8TbuzViun+QdfPu3DNmUL8p7Yo DQcqo1MOZ3r7PzAjvEI3WX0feqBDHudSwQkoDhaAVviAT7Xfq3XoZDUG98ghekEOoL3c nPGw== X-Gm-Message-State: ALoCoQmB4m3pobbJbnD8dvUOjyRL/VjD6K8fR4BlbXcs+Dtvk2+Xob/mAlUgASQ5XczTfcYbTxOt X-Received: by 10.50.50.209 with SMTP id e17mr12038500igo.37.1428501441157; Wed, 08 Apr 2015 06:57:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Wed, 8 Apr 2015 06:57:00 -0700 (PDT) In-Reply-To: References: <9C103660-A36F-4AA9-A2C2-BADF89401341@fugue.com> From: Lorenzo Colitti Date: Wed, 8 Apr 2015 22:57:00 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bdca97cf64ca3051336e851 Archived-At: Cc: HOMENET Subject: Re: [homenet] How is prefix delegation handled on OpenWRT/CeroWRT in a homenet configuration? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 13:57:23 -0000 --047d7bdca97cf64ca3051336e851 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 10:54 PM, Lorenzo Colitti wrote: > Sorry to delve into an operational question when we're having so much fun >> discussing layer 9 stuff, but are any of the OpenWRT folks around who could >> tell me what OpenWRT is doing to get its delegation from the ISP? ISC >> DHCP? dhcpcd? dnsmasq? >> > > https://github.com/sbyx/odhcpd > Actually, that's the server. I think the client is https://github.com/sbyx/odhcp6c . --047d7bdca97cf64ca3051336e851 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 8, 2015 at 10:54 PM, Lorenzo Colitti <lorenzo@google.com>= wrote:
Sorry to d= elve into an operational question when we're having so much fun discuss= ing layer 9 stuff, but are any of the OpenWRT folks around who could tell m= e what OpenWRT is doing to get its delegation from the ISP?=C2=A0 =C2=A0ISC= DHCP?=C2=A0 =C2=A0dhcpcd?=C2=A0 dnsmasq?

Actually, that's the server. I think the client is=C2=A0https://github.com/sbyx/odhcp6c .
--047d7bdca97cf64ca3051336e851-- From nobody Wed Apr 8 07:06:10 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F2C1AC3A1 for ; Wed, 8 Apr 2015 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 otRjSp4t09id for ; Wed, 8 Apr 2015 07:06:08 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::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 28E711AC3B5 for ; Wed, 8 Apr 2015 07:06:07 -0700 (PDT) Received: by iebmp1 with SMTP id mp1so74654451ieb.0 for ; Wed, 08 Apr 2015 07:06: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:content-type; bh=uAgMgrrTJrEKxaDqNeHVwCUBOtZ828zqiLmwfyoYdW4=; b=ZmcyFUmbYQabSWHUZUmmx0L2eHBUeHh4gQUTaucXUAEs/BVdla7ZaZdbnKZWAQUgOA v50TwQSlBmM7Wm+/s9I8huTg/38Qw0kaUTdSE8EvU7zPoRQSzKczasrdHHoy/rEZ8dR2 jr8wZC4DYyWYGAqTLvDv+6plmOz+UJwflDcWohXhhEw2bGsRA/eq7x+q9zN3j9Nc7nbD ko+6zoETjknDMg80EbmLZxDZLpDgY8B4cKgjGDO897mvBMyp/MNrBAVVGX5GdqphH2La LX4qABfzUJoybX1PV0cG7O3Ma3+TsrsgrYY2JYwTeLOh5jv8ZRHo+tYeRPlZAkEM4qFL XThQ== 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-type; bh=uAgMgrrTJrEKxaDqNeHVwCUBOtZ828zqiLmwfyoYdW4=; b=FnEQyMerLgJJUKI5SJcyzoNnIKM/8g3GDRL7aXz8uoqN1yUKU8u/s4euzsV1UZ22AR X08lxpSkjNX9tKeyfuI+w4B0U22pqbChAQlnjhJS3sfuWId1gOXSSvFs4h1fTc18PXP1 bTuAXe/h5qivvNervIdnJhB35KfHvYXTIEm5SpI+ruqMBdHNuGuyNdxdGt0Q2mbmkqyK ldUkEE+NKvGZ5DCeN4cOGGNBGV9UwtQgXcEmeKheFty9HSh+Jg5FEN4bBe5XFO1bad9/ YfosGNAOAEPfWaFQ0aIgz/hoaic6lGDtB0b1DTOPV+JTSHK+grf6I623iCU6y2D7rJh4 oduA== X-Gm-Message-State: ALoCoQmL9ooA8PzqALppIHkLJ3+OpE/dU8QRwh90XFlbBPvbEuAgkDenb3OGtDqFVyfjRFRwIEQP X-Received: by 10.107.46.155 with SMTP id u27mr37834884iou.87.1428501966678; Wed, 08 Apr 2015 07:06:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.195.75 with HTTP; Wed, 8 Apr 2015 07:05:46 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 8 Apr 2015 23:05:46 +0900 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113ac5b649050705133708ab Archived-At: Cc: HOMENET , "int-ads@ietf.org" Subject: Re: [homenet] Homenet Design Team for Routing Protocol Selection X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 14:06:09 -0000 --001a113ac5b649050705133708ab Content-Type: text/plain; charset=UTF-8 Alia, Russ White (lead) > Margaret (Wasserman) Cullen > Ralph Droms > Philippe Klein > Wes George > Ross Callon > Nowhere on that list do I see names that I recognize as being involved in current homenet implementations - or at least, in the implementations that seem most likely for selection. Is there a reason that none of those implementers were made part of the team? Was it done intentionally, out of concern that if they had been on the team, they would be partial to their own designs? If not, then... well, how can the team make a useful decision if it has not been involved with the work so far? Regards, Lorenzo --001a113ac5b649050705133708ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alia= ,

Russ White (lead)
Margaret= (Wasserman) Cullen
Ralph Droms
Philippe Klein
Wes George
Ross Callon

<= div>Nowhere on that list do I see names that I recognize as being involved = in current homenet implementations - or at least, in the implementations th= at seem most likely for selection.

Is there a= reason that none of those implementers were made part of the team? Was it = done intentionally, out of concern that if they had been on the team, they = would be partial to their own designs?

If no= t, then... well, how can the team make a useful decision if it has not been= involved with the work so far?

Regards,
Lorenzo
--001a113ac5b649050705133708ab-- From nobody Wed Apr 8 07:24:53 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC401B3112; Wed, 8 Apr 2015 07:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 UDVQh1uZg3MZ; Wed, 8 Apr 2015 07:24:51 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 687D31B3111; Wed, 8 Apr 2015 07:24:43 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so140109360obb.2; Wed, 08 Apr 2015 07:24:43 -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-type; bh=IZzsLqVoRDE5l+dgdJSHIeKAtrhqyXYDswizIdTS1tc=; b=MOWYM/LFIOEIOBdw77088iQAW7xHy/YlCJsOSn/2bb2xXAGZOX3Nla3L1Vn2Eh9DPn OgoctthSwBHpaHBqIvl7p9pNsWW6oyLbjP04oQ0Z2EHgDQ7Jpx/8BbpQIO1u0nv5N+qH rinQ6KXIpA35X0R86bOBJZ0XsOlOCcZ8mvAesARqaG/6+E/nMwtQl91bsYbpzyarFkhJ FqIthCiX/sHHCebip9DdL8DhaqkpoKMiHWjzIv5fcMtT07V1hSY/DRPxzl1ligHH8rRr uwwiO9wC1Ju1hhk87gdVjTNVMTOLOZR0+7WYxY+EUGYQ/AFFgL5gdwymi/wLO30Vf7H4 lBSQ== MIME-Version: 1.0 X-Received: by 10.182.255.195 with SMTP id as3mr32437296obd.56.1428503068122; Wed, 08 Apr 2015 07:24:28 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Wed, 8 Apr 2015 07:24:28 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Apr 2015 10:24:28 -0400 Message-ID: From: Alia Atlas To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=001a1134a616efcc3005133749b3 Archived-At: Cc: HOMENET , "int-ads@ietf.org" Subject: Re: [homenet] Homenet Design Team for Routing Protocol Selection X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 14:24:52 -0000 --001a1134a616efcc3005133749b3 Content-Type: text/plain; charset=UTF-8 Lorenzo, On Wed, Apr 8, 2015 at 10:05 AM, Lorenzo Colitti wrote: > Alia, > > Russ White (lead) >> Margaret (Wasserman) Cullen >> Ralph Droms >> Philippe Klein >> Wes George >> Ross Callon >> > > Nowhere on that list do I see names that I recognize as being involved in > current homenet implementations - or at least, in the implementations that > seem most likely for selection. > > Is there a reason that none of those implementers were made part of the > team? Was it done intentionally, out of concern that if they had been on > the team, they would be partial to their own designs? > Yes - we want the design team to be impartial and make an informed technical decision. There were many others that were considered but impartiality was a very important criteria. It does no good for the design team to recreate the extremely polarized conversation that have happened in Homenet. We did include Philippe as someone who is familiar with constrained environments as well layer 2 considerations. If not, then... well, how can the team make a useful decision if it has not > been involved with the work so far? > It was done intentionally. I believe that this design team has the background and knowledge to assess requirements and compare against candidate routing protocols. The design team is most able to reach out to others for questions and advice. Regards, Alia --001a1134a616efcc3005133749b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lorenzo,

On Wed, Apr 8, 2015 at 10:05 AM, Lorenzo Colitti <lore= nzo@google.com> wrote:
Alia,

Russ White (lead)
Margar= et (Wasserman) Cullen
Ralph Droms
Philippe Klein
<= div>Wes George
Ross Callon

Nowhere on that list do I see names that I recognize as being = involved in current homenet implementations - or at least, in the implement= ations that seem most likely for selection.

I= s there a reason that none of those implementers were made part of the team= ? Was it done intentionally, out of concern that if they had been on the te= am, they would be partial to their own designs?

Yes - we want the design team to be impa= rtial and make an informed technical decision.=C2=A0 There were many others=
that were considered but impartiality was a very important crite= ria.=C2=A0 It does no good for the design team to recreate the extremely po= larized conversation that have happened in Homenet.=C2=A0

We did include Philippe as someone who is familiar with constrained= environments as well layer 2 considerations.

If not, then... well, how can the team ma= ke a useful decision if it has not been involved with the work so far?

It was done intentional= ly.=C2=A0 I believe that this design team has the background and knowledge = to assess requirements and compare against candidate routing protocols.=C2= =A0 The design team is most able to reach out to others for questions and a= dvice.

Regards,
Alia
--001a1134a616efcc3005133749b3-- From nobody Wed Apr 8 08:18:34 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600761B325F; Wed, 8 Apr 2015 08:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 51Gnbk3_8zVA; Wed, 8 Apr 2015 08:18:24 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A731B323C; Wed, 8 Apr 2015 08:18:17 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t38FIEYn005616; Wed, 8 Apr 2015 17:18:14 +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 9C6F461FBD; Wed, 8 Apr 2015 17:18: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 1sBt_dW-4SAp; Wed, 8 Apr 2015 17:18:13 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E9C3461FBA; Wed, 8 Apr 2015 17:18:11 +0200 (CEST) Date: Wed, 08 Apr 2015 17:18:13 +0200 Message-ID: <87vbh6wswa.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 08 Apr 2015 17:18:14 +0200 (CEST) X-Miltered: at korolev with ID 552546B6.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 552546B6.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 : 552546B6.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: HOMENET , "int-ads@ietf.org" Subject: Re: [homenet] Homenet Design Team for Routing Protocol Selection X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:18:26 -0000 >> Russ White (lead) >> Margaret (Wasserman) Cullen >> Ralph Droms >> Philippe Klein >> Wes George >> Ross Callon > we want the design team to be impartial I think only Margaret has a passing familiarity with Babel. Since the team is impartial, I assume there's also at most one person familiar with IS-IS? -- Juliusz From nobody Wed Apr 8 08:25:35 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435801B3277; Wed, 8 Apr 2015 08:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 4A5cZ7p9SPUq; Wed, 8 Apr 2015 08:25:30 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 718261B3270; Wed, 8 Apr 2015 08:25:30 -0700 (PDT) Received: by obbfy7 with SMTP id fy7so143053570obb.2; Wed, 08 Apr 2015 08:25: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:date:message-id:subject:from:to :cc:content-type; bh=t2dYnRYhnZrGe3QZoilHoAyxzI8SdJVk2J9Ia8MV7HQ=; b=r5NNoLHl+txn19h7CyaaMlSBCWvIQlj9+0N6X79b5pg9VrBJsR2xquB1KxrHpgdFTI 1AVz8o66HNdgmTo49HlbupTXAaGUJY0SL8PsU1gmJC/OgsibVokuOcOQpMANUE2cg0Pf aI4HHfjX2nGonPfDfi/ls0eWEIp2H0VZlud6T7pfxpUVS0jLTdSt47dtDWIV6PVAKSip RWG5IOpieIOjThqlOYJohCFQzboYIluyTKY+UodORqlguWYiSig+Pwixl2p3gg/syZQK hMRMuAf8x7ow031uk9zX/g/2bDEUmaIg59ZCDTxKgSCeyaB9sGstoUgs4fvRZKsvorYE zgCA== MIME-Version: 1.0 X-Received: by 10.182.87.8 with SMTP id t8mr33076177obz.35.1428506717375; Wed, 08 Apr 2015 08:25:17 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Wed, 8 Apr 2015 08:25:17 -0700 (PDT) In-Reply-To: <87vbh6wswa.wl-jch@pps.univ-paris-diderot.fr> References: <87vbh6wswa.wl-jch@pps.univ-paris-diderot.fr> Date: Wed, 8 Apr 2015 11:25:17 -0400 Message-ID: From: Alia Atlas To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=089e013c705472d61305133823e4 Archived-At: Cc: HOMENET , "int-ads@ietf.org" Subject: Re: [homenet] Homenet Design Team for Routing Protocol Selection X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:25:32 -0000 --089e013c705472d61305133823e4 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 8, 2015 at 11:18 AM, Juliusz Chroboczek < jch@pps.univ-paris-diderot.fr> wrote: > >> Russ White (lead) > >> Margaret (Wasserman) Cullen > >> Ralph Droms > >> Philippe Klein > >> Wes George > >> Ross Callon > > > we want the design team to be impartial > > I think only Margaret has a passing familiarity with Babel. Since the > team is impartial, I assume there's also at most one person familiar with > IS-IS? In this, you would be incorrect. Russ White is also familiar with Babel. That is also - sorry - a false presentation of fairness which assumes that those on the design team will be biased and that it is reasonable and necessary to find equal numbers of people familiar with one of the most widely deployed IGPs and with an interesting protocol that has a niche deployment. There is knowledge of multiple IGPs in the team - and as critically, an impartiality and willingness to listen and consider the requirements and how the candidates compare. What I think we needed on the design team is both impartiality, understanding of homenet use cases for deriving use-cases, understanding of different IGPs, and understanding how to select a routing protocol based upon requirements. Regards, Alia > -- Juliusz > --089e013c705472d61305133823e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 8, 2015 at 11:18 AM, Juliusz Chroboczek <jch@pps.univ-= paris-diderot.fr> wrote:
>> Russ White (lead)
>> Margaret (Wasserman) Cullen
>> Ralph Droms
>> Philippe Klein
>> Wes George
>> Ross Callon

> we want the design team to be impartial

I think only Margaret has a passing familiarity with Babel.=C2=A0 Si= nce the
team is impartial, I assume there's also at most one person familiar wi= th
IS-IS?

In this, you would be incorrect.=C2= =A0 Russ White is also familiar with Babel.=C2=A0 That is
also - = sorry - a false presentation of fairness which assumes that those on the
design team will be biased and that it is reasonable and necessary = to find equal numbers of
people familiar with one of the most wid= ely deployed IGPs and with an interesting
protocol that has a nic= he deployment.

There is knowledge of multiple IGPs= in the team - and as critically, an impartiality
and willingness= to listen and consider the requirements and how the candidates compare.
What I think we needed on the design team is both impartiality, und= erstanding of homenet
use cases for deriving use-cases, understan= ding of different IGPs, and understanding
how to select a routing= protocol based upon requirements.

Regards,
<= div>Alia

=C2=A0
-- Juliusz

--089e013c705472d61305133823e4-- From nobody Wed Apr 8 08:38:15 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C621B32D8 for ; Wed, 8 Apr 2015 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 neOxj1lr2qJ4 for ; Wed, 8 Apr 2015 08:38:13 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 D60BD1B32C0 for ; Wed, 8 Apr 2015 08:36:58 -0700 (PDT) Received: by oblw8 with SMTP id w8so93028815obl.0 for ; Wed, 08 Apr 2015 08:36:58 -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-type:content-transfer-encoding; bh=4Hh4UniCa3UK/notht11adSqRBLmnFO1HZeEKXqYflY=; b=eKtj14zwB4r+0TAXwIlVYMDHopSmEOgz9aTB6gDa5xdGCXAUwU3Bjk7gzEeTh4P5lk /c567EsoauyCFYY1AJf4HOrEBTB/8g+W7rnEWXbUMV3xyAi88Wj1JQHwoBaDHx8LCUsh qsrVAdQwvybH427McBnst3vALADmeicd3TZQ1UVv/loO0SnFvdoe+/vRIvJZ9CicvZM/ +MgdCy5GsJEc/9ZW51ypHNofsUANwPppItpm95s4qDFgexX8wzYf07wNHpKb6X+bGNE4 P9PbC4g1kC6gvPUi4fc8qc/Gje8O8ZT+HngiyoQcH5jhVMh3iJP07AZbmVNBsLg4NnXP snzQ== MIME-Version: 1.0 X-Received: by 10.182.91.35 with SMTP id cb3mr32850355obb.87.1428507404061; Wed, 08 Apr 2015 08:36:44 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Wed, 8 Apr 2015 08:36:43 -0700 (PDT) In-Reply-To: <9C103660-A36F-4AA9-A2C2-BADF89401341@fugue.com> References: <9C103660-A36F-4AA9-A2C2-BADF89401341@fugue.com> Date: Wed, 8 Apr 2015 08:36:43 -0700 Message-ID: From: Dave Taht To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: HOMENET Subject: Re: [homenet] How is prefix delegation handled on OpenWRT/CeroWRT in a homenet configuration? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:38:15 -0000 I note that I was unsuccessful in getting PD to work properly on ubuntu. dhclient would assign /68s, dibbler (as currently released) would crash, and dibbler rc2 also had issues, all this compounded by switching between these daemons - causing the dhcp server on the cable modem I was using - to reject more PD requests and then run wild sending not in the spec error messages - which then drove the dhcp clients wild... https://github.com/sbyx/odhcp6c/issues/27 When you get it working let us know. That was a little too much dogfood in that weekend for me. On Wed, Apr 8, 2015 at 6:48 AM, Ted Lemon wrote: > Sorry to delve into an operational question when we're having so much fun= discussing layer 9 stuff, but are any of the OpenWRT folks around who coul= d tell me what OpenWRT is doing to get its delegation from the ISP? ISC D= HCP? dhcpcd? dnsmasq? > > I ask because I want to replicate a homenet environment at home, but my e= dge router is a server running Ubuntu, and I don't want to put a Wifi route= r between it and the internet. Clues appreciated. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=C3=A4ht We CAN make better hardware, ourselves, beat bufferbloat, and take back control of the edge of the internet! If we work together, on making it: https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hard= ware-for-networking From nobody Wed Apr 8 08:40:50 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1CC1B324C; Wed, 8 Apr 2015 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 UTQ3FZqr06nN; Wed, 8 Apr 2015 08:40:48 -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 DDBA91B3270; Wed, 8 Apr 2015 08:40:47 -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/56100) with ESMTP id t38FejqJ017124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Apr 2015 17:40:46 +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 t38FejLY030420; Wed, 8 Apr 2015 17:40:45 +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 DC56361FBA; Wed, 8 Apr 2015 17:40:45 +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 vgElK4cjRdeu; Wed, 8 Apr 2015 17:40:44 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AED3C61FA0; Wed, 8 Apr 2015 17:40:44 +0200 (CEST) Date: Wed, 08 Apr 2015 17:40:46 +0200 Message-ID: <87twwqwrup.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Alia Atlas In-Reply-To: References: <87vbh6wswa.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]); Wed, 08 Apr 2015 17:40:46 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 08 Apr 2015 17:40:45 +0200 (CEST) X-Miltered: at korolev with ID 55254BFD.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 55254BFD.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 55254BFD.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 55254BFD.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 : 55254BFD.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 55254BFD.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: HOMENET , "int-ads@ietf.org" Subject: Re: [homenet] Homenet Design Team for Routing Protocol Selection X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:40:49 -0000 >> I think only Margaret has a passing familiarity with Babel. > > Russ White is also familiar with Babel. Correct. Apologies to Russ. This doesn't change the fact that the right way to choose an impartial team is to select people who can correct each other's biases. I am fairly positive this is not the case in this particular group of experts. -- Juliusz From nobody Wed Apr 8 10:43:13 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364B21A877F; Wed, 8 Apr 2015 10:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OLorsW88j0GV; Wed, 8 Apr 2015 10:43:09 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 189D51A87AA; Wed, 8 Apr 2015 10:43:09 -0700 (PDT) Received: by obbgh1 with SMTP id gh1so141255161obb.1; Wed, 08 Apr 2015 10:43: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:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3ejjzLsPfl1UJIjmh6Qy4KS9c5ak0eXNrgJ6ydz87HQ=; b=vfPR9PG7GMDXUSWGgdRKXhHeHP7b7ghPlMmqgnPAFp5o7dwuZ9PpzyJmR3eYifnP0c RLUJ3N+iM0STbQElssr5C/izWynXQPo0rgFUknWSGvu/UUjpIq99tXYWvoo9KhT2c1Ec 16tkp35VBTqmHTfaUCoH3fg8Fh7g64g6xyRTAKt2zOwauH14m8DZFaaL2NcYwHB+b9vZ uc/O/Mp/Uxj0yzQz6MwkhFipXkorAiwdk6i3E9xjeoi+TAZglXNlI3Scv2daQue3E4n7 v7FuWcYUJzVI2oHoebC9mMH2EtTXGRRLSd0CdLq+YLhiHLUx+mfBweZ91CiTV5642ZXr MmmQ== MIME-Version: 1.0 X-Received: by 10.182.255.195 with SMTP id as3mr33655029obd.56.1428514986726; Wed, 08 Apr 2015 10:43:06 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Wed, 8 Apr 2015 10:43:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Apr 2015 10:43:06 -0700 Message-ID: From: Dave Taht To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: HOMENET , "int-ads@ietf.org" Subject: Re: [homenet] Homenet Design Team for Routing Protocol Selection X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:43:11 -0000 On Wed, Apr 8, 2015 at 6:33 AM, Alia Atlas wrote: > Terry's email on April 6 confirmed that Homenet will use the approach > of having a Design Team to select the one mandatory-to-implement > routing protocol. The charter for the design team, as sent in his email= , > is below. > > I am happy to also announce the membership of the design team with > many thanks to them for taking on this time-consuming and critical job. > > Russ White (lead) > Margaret (Wasserman) Cullen > Ralph Droms > Philippe Klein > Wes George > Ross Callon > > The design team has a private mailing list homenet-dt-routing@ietf.org > for their internal communication. The design team members are the > only ones on that mailing list. Had the proposal for the design team had been for a "private design team" I think you would have raise more ruckus here. That said, the ruckus and email burden was enough to make me nearly quit this list to focus on more important matters like making wifi scale to the next 10 billion users over the next 5 years. I am glad that there is 802.14 expertise on this design team, I think that wireless standard is very important to interoperate with, and for too long this wg has fought over wired vs wireless concepts without feedback from the IoT folk. I am glad there appears to be some source code over here worth looking at: https://twatteyne.wordpress.com/projects/openwsn/ In my case, since the burden of actually participating in a new group before july is now gone, I plan to focus on my primary missions in fq and aqm technologies and moving them into more hardware, as well as stablizing the openwrt chaos calmer code base for release this summer. IF there is any other source code worth incorporating into my testbeds, please let me know soon. I already ship batman, bmx6, olsr, hnetd, babel, and everything in quagga. It is off topic for this thread, but if there is anyone out there that would like to see some faster/better home cpe built with modern fq/aqm/shaping algorithms, maybe with support for loop avoiding bellman ford in gates... see my .sig. Only 24 hours left to run on the darn kickstarter. > Charter: > > "Homenet's architecture (RFC 7368) articulates the general features > required. The working group has agreed that a single routing protocol > must be identified as mandatory to implement. The final purpose of > this design team is to select and present a single routing protocol > with a summary of the necessary extensions and work to be the one that > is mandatory to implement. Once the design team has made its > recommendation, the working group will consider any substantial > technical objections (see RFC 7282) as part of gaining consensus. > > For the design team to make this determination, it shall first > understand the use-cases for homenet and derive routing requirements > from those. Then it shall compare these routing requirements to > candidate routing protocols and examine the gaps in each. For each > highly plausible candidate routing protocol, the design team will > estimate the work and actions needed, the resources at hand > or reasonably available, and the associated timeline to get > an acceptable, full, standardized solution using each protocol. I look forward also to estimates as to making it widely available as source code. > Based upon this information and the perceived market timing > needs of the technology, the design team will make its selection. > The requirements, gaps, and reasoning will be documented. > > This document should be delivered by the July 2015 IETF." > > Regards, > Alia > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=C3=A4ht We CAN make better hardware, ourselves, beat bufferbloat, and take back control of the edge of the internet! If we work together, on making it: https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hard= ware-for-networking From nobody Thu Apr 9 00:28:14 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7DB1A1B64; Thu, 9 Apr 2015 00:28: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] autolearn=ham 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 zMydtjlPoLFM; Thu, 9 Apr 2015 00:28:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA741A1B6A; Thu, 9 Apr 2015 00:28:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409072808.21672.86233.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 00:28:08 -0700 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-05.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 07:28:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Distributed Prefix Assignment Algorithm Authors : Pierre Pfister Benjamin Paterson Jari Arkko Filename : draft-ietf-homenet-prefix-assignment-05.txt Pages : 18 Date : 2015-04-09 Abstract: This document specifies a distributed algorithm for automatic prefix assignment. Given a set of delegated prefixes, it ensures that at most one prefix is assigned from each delegated prefix to each link. Nodes may assign available prefixes to the links they are directly connected to, or for other private purposes. The algorithm eventually converges and ensures that all assigned prefixes do not overlap. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-prefix-assignment-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 10 01:19:44 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9675A1B2ABF for ; Fri, 10 Apr 2015 01:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mtUEfiugLCb0 for ; Fri, 10 Apr 2015 01:19:41 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id CE5A51B2ABE for ; Fri, 10 Apr 2015 01:19:40 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=jfJb4dYt+VZZ78Nah9xRvVzJBoVSjKQzjfvWjAEBU3B0PyivchsvAGQQ 8RsD3qJVqGKRxnqGgsi/jPWUoujt/j1jKanpkFGgbGYQle3zLVnnp45Oh 8MebJ25v7rFyqP8RP0/I5WRKkr/R+r9DHPW64tiqtnIEwba6bAWdgC1ya c/FuEM6BgUU5gwZZFIc5i/1ZMl6Fa4dEV8gVemYUG3/q2vjJCsKOXqkuD F5YfoJ6AsiZG+YVxZKGKUXeyJ8G7o; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1428653981; x=1460189981; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Nn0eH0KHTIZwEeXg+vhQ1Y+VPSqXLKCEfHCqj0VfxKo=; b=hmLu1jOkLV8x+t27XMKQFxBA6baoWFXr3iPe4WmsS3lgx82l1CxsZ0Uj R7renIm6dOlkdsrCOd5S+xY5yjAdEh/+cLqzs5HnY2ud/Bd1QA9o9Bz4U ZrdwHFYVIj11rN6T0Y9GPsXaOzHJ9G1QLfOE0uUm064X9LtkryWcN/n5E kJTr+NmTLjvIZDRfNTlQJwsRbLJW6ayM12f+ETP/1/mt0AYA9YjIqvKUP y67mk07WuzwyhpEPO0fxvpZQ89kpP; X-IronPort-AV: E=Sophos;i="5.11,555,1422921600"; d="scan'208";a="18132983" X-IPAS-Result: A2AcBQBKhydV/5HF+NVcgmYmgS4FzDACAgKBPDwQAQEBAQEBAX2EHwEBAQECAToZKwsCAQgYHhAyJQIEE4giCQPOSgEBCAEBAQEBAQEbiyuBMwoBgws6gxeBFgWcLIM3kBEighCBX2+BRH8BAQE Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 10 Apr 2015 09:19:11 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0224.002; Fri, 10 Apr 2015 09:19:11 +0100 From: Ray Bellis To: HOMENET Thread-Topic: [homenet] WG Secretary - request for volunteers Thread-Index: AQHQaBqNq3E+J+FTqkaNHC5Qga6lOp1F7RCA Date: Fri, 10 Apr 2015 08:19:09 +0000 Message-ID: <5965C7A1-D1A9-4722-A390-A942A109D9CF@nominet.org.uk> References: <9A4BF912-F744-4D7C-9403-01C9C1BF346E@nominet.org.uk> In-Reply-To: <9A4BF912-F744-4D7C-9403-01C9C1BF346E@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <647607E601300643A8799CF23AEC894E@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [homenet] WG Secretary - request for volunteers X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 08:19:42 -0000 > On 26 Mar 2015, at 23:14, Ray Bellis wrote: >=20 > It has been strongly recommended to the Chairs that we appoint a WG Secre= tary to assist us in the administration of the Working Group. >=20 > Details on the role and responsibilities of a WG Secretary can be found i= n RFC 2418 and draft-secretaries-good-practices-07 (work in progress). >=20 > If you would like to volunteer, or perhaps nominate someone else (who wou= ld of course have the right to refuse the nomination) please let me know. I've only had one response so far. If there are others who wish to be considered too please let me know soon! = The Chairs expect to make the appointment at the start of the Prague meeti= ng once we've actually had a chance to meet the candidates. thanks, Ray From nobody Fri Apr 10 04:46:17 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9951F1B2CB1 for ; Fri, 10 Apr 2015 04:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ymyla8fqhzkU for ; Fri, 10 Apr 2015 04:46:10 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 37B121B2CB2 for ; Fri, 10 Apr 2015 04:46:10 -0700 (PDT) Received: from [10.0.20.187] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id BD7442381504; Fri, 10 Apr 2015 07:46:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5527ABE3.9040300@globis.net> Date: Fri, 10 Apr 2015 07:46:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D8F937B-35A5-4613-807C-EDC3FF9201ED@fugue.com> References: <9C103660-A36F-4AA9-A2C2-BADF89401341@fugue.com> <5527ABE3.9040300@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: HOMENET Subject: Re: [homenet] How is prefix delegation handled on OpenWRT/CeroWRT in a homenet configuration? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 11:46:16 -0000 Thanks, Ray! I'm actually trying to get my ubuntu machine to be the = homenet edge router rather than simulating an ISP edge router, but in = fact in the process of doing this I've concluded that for testing = purposes a setup like the one you've described would be very useful! = :) From nobody Sun Apr 12 07:55:26 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1681ACEF6 for ; Sun, 12 Apr 2015 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kfY3IqesfYrs for ; Sun, 12 Apr 2015 07:55:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C964A1ACEF4 for ; Sun, 12 Apr 2015 07:55:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DFBCBEF1; Sun, 12 Apr 2015 15:55:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzeq8Q5qF7qG; Sun, 12 Apr 2015 15:55:21 +0100 (IST) Received: from [10.87.48.73] (unknown [86.41.51.113]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82898BEE2; Sun, 12 Apr 2015 15:55:20 +0100 (IST) Message-ID: <552A8756.7000607@cs.tcd.ie> Date: Sun, 12 Apr 2015 15:55:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <87a8yje61t.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87a8yje61t.wl-jch@pps.univ-paris-diderot.fr> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] Security considerations for the Babel routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 14:55:24 -0000 On 08/04/15 02:56, Juliusz Chroboczek wrote: > Dear Stephen, > > Following your request of 5 April 2015, Well, I didn't quite request exactly that, but fair play. It's good to see the analysis begun, though I utterly disagree with your main so-called conclusion. I'll send a more detailed response off-list, as I don't think it'd be right if the homenet list were dominated by this (which could happen). S. > I have published the following > Internet-Draft: > > Security considerations for the Babel routing protocol > draft-chroboczek-babel-security-considerations-00 > > I also attract your attention to the following RFC: > > RFC 7298: Babel Hashed Message Authentication Code (HMAC) > Cryptographic Authentication > > I hope that these documents alleviate your concerns about the Babel > community not thinking about security hard enough. Should you have any > further inquiries, please do not hesitate to contact me, and I'll do my > best, time permitting, to update the security considerations document. > > With respectful regards, > > -- Juliusz Chroboczek > > From nobody Sun Apr 12 18:23:51 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B401A8028 for ; Sun, 12 Apr 2015 18:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35] autolearn=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 FOLggqHXmzv4 for ; Sun, 12 Apr 2015 18:23:48 -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 266351A70FD for ; Sun, 12 Apr 2015 18:23:47 -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/56100) with ESMTP id t3D1Njwt028288; Mon, 13 Apr 2015 03:23:45 +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 B2ABC61FB8; Mon, 13 Apr 2015 03:23:45 +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 oUxHGdX-WNwj; Mon, 13 Apr 2015 03:23:44 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 84D1961F9D; Mon, 13 Apr 2015 03:23:43 +0200 (CEST) Date: Mon, 13 Apr 2015 03:23:48 +0200 Message-ID: <877ftges7v.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Stephen Farrell In-Reply-To: <552A8756.7000607@cs.tcd.ie> References: <87a8yje61t.wl-jch@pps.univ-paris-diderot.fr> <552A8756.7000607@cs.tcd.ie> 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, 13 Apr 2015 03:23:45 +0200 (CEST) X-Miltered: at korolev with ID 552B1AA1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 552B1AA1.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 : 552B1AA1.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: homenet@ietf.org Subject: Re: [homenet] Security considerations for the Babel routing protocol X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 01:23:49 -0000 > I utterly disagree with your main so-called conclusion. [...] > I'll send a more detailed response off-list Respectful disagreement expressed by private mail, as Stephen requested. -- Juliusz From nobody Tue Apr 14 05:22:01 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8F1A8AA6 for ; Tue, 14 Apr 2015 05:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35] autolearn=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 gSVOpuu8P4Ui for ; Tue, 14 Apr 2015 05:21:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E1F1A8A76 for ; Tue, 14 Apr 2015 05:21:57 -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/56100) with ESMTP id t3ECLu1R030218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Apr 2015 14:21: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 t3ECLuJY005044 for ; Tue, 14 Apr 2015 14:21:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1213C61FBA for ; Tue, 14 Apr 2015 14:21:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id rm4vJygkQMtq for ; Tue, 14 Apr 2015 14:21:54 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 59F3F61FBD for ; Tue, 14 Apr 2015 14:21:51 +0200 (CEST) Date: Tue, 14 Apr 2015 14:21:57 +0200 Message-ID: <87oamqew7u.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: homenet@ietf.org References: <87pp76ew8l.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: message/rfc822 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, 14 Apr 2015 14:21:56 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 14 Apr 2015 14:21:56 +0200 (CEST) X-Miltered: at korolev with ID 552D0664.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 552D0664.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 552D0664.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 552D0664.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 : 552D0664.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 552D0664.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: [homenet] Fwd: ANNOUNCE: babeld-1.6.0 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 12:22:00 -0000 Date: Tue, 14 Apr 2015 14:21:30 +0200 Message-ID: <87pp76ew8l.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: babel-users@lists.alioth.debian.org Subject: ANNOUNCE: babeld-1.6.0 User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Tue_Apr_14_14:21:29_2015-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --pgp-sign-Multipart_Tue_Apr_14_14:21:29_2015-1 Content-Type: text/plain; charset=US-ASCII Dear all, I am happy to announce that babeld-1.6.0 is available from http://www.pps.univ-paris-diderot.fr/~jch/software/files/babeld-1.6.0.tar.gz http://www.pps.univ-paris-diderot.fr/~jch/software/files/babeld-1.6.0.tar.gz.asc For more information about babeld and the Babel routing protocol, please see http://www.pps.univ-paris-diderot.fr/~jch/software/babel/ The main news in this version is that source-specific routing is part of the stock babeld daemon. This is a large change, and is due to Matthieu Boutier. For more information about source-specific routing, please see Matthieu Boutier and Juliusz Chroboczek. Source-specific routing. To appear in Proc. IFIP Networking 2015. http://arxiv.org/pdf/1403.0445 Enjoy, -- Juliusz Chroboczek --pgp-sign-Multipart_Tue_Apr_14_14:21:29_2015-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJVLQZJAAoJECZSyIHq21UmePwIALawCkW2K2QrHXpOpwwk53AN bynlJ1gjhd7+E702A5WqSMajSpu5BkI+23E34zSlhop34/vBqnpC95Immu2gdxx6 X1661A6bVcHLByYcrq73NIRikgedpKSLNC6k6DyyyzF41h7zL0v30zaJJu5olpFO /JUh1zpNwcGUffATPHA0AguvsfoBV1sRL4ptz2xlJ2/4wGI+tpwEd04Xj5kV6iJV N7MvmYpWBxZwxfFdTm6gfskPxZHmMlkbGSwDHjewM84BHbHDcqpWM3HxdJMduRKH n+d+eFMve9nUWPrIezpAXsEl1jB80nNnB44PM2BuB/B/aN4nVFjDO6LQ7yjZnyA= =5EKf -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Apr_14_14:21:29_2015-1-- From nobody Wed Apr 15 07:07:23 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5161B33FF for ; Wed, 15 Apr 2015 07:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7jysQ5WaaZN9 for ; Wed, 15 Apr 2015 07:07:20 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A9D1A904A for ; Wed, 15 Apr 2015 07:07:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C0D2A1; Wed, 15 Apr 2015 16:07:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1429106838; bh=gSuQ+SoApPmQVpI0YJ6mhMCi82fgjs/nDIBVFt7Vc1k=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=E0xC5QBMYjrLuGPKG5AI6EHl02+EbFvpOSAkvq8BHCNZKz+VRyIdSoAgeILsjWfkw j9uw8xNoh+x/4fiQ6TKPHumVISqbr3+WX4hNvmIXuh1x+hD70JmsEPYYv2GiceyfOp GpcCyZdhUKYNE6FMAcup4pwphutAlY8z/Llf2Brc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 482C79F; Wed, 15 Apr 2015 16:07:18 +0200 (CEST) Date: Wed, 15 Apr 2015 16:07:18 +0200 (CEST) From: Mikael Abrahamsson To: Juliusz Chroboczek In-Reply-To: <87oamqew7u.wl-jch@pps.univ-paris-diderot.fr> Message-ID: References: <87pp76ew8l.wl-jch@pps.univ-paris-diderot.fr> <87oamqew7u.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-132096908-1429106838=:16871" Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] Fwd: ANNOUNCE: babeld-1.6.0 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:07:22 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-132096908-1429106838=:16871 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Tue, 14 Apr 2015, Juliusz Chroboczek wrote: Hi, could you please elaborate on one sentence in the abstract from http://arxiv.org/pdf/1403.0445.pdf: "to our knowledge, the first complete implementation of a sourcespecific dynamic routing protocol —" What do you mean by "complete"? What is it that you have done, that wasn't done in the OSPF and ISIS implementations that have been shown so far in the homenet context over the past few years? "While we enjoy working with distance-vector protocols, much of the networking community appears to have converged on using the OSPF protocol for internal routing." Coming from the ISP side, I also question OSPF being mentioned as IGP while totally excluding ISIS. I dare to say that a majority of the larger ISP networks of today are running ISIS as their IGP. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-132096908-1429106838=:16871-- From nobody Wed Apr 15 07:10:08 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E981B3548 for ; Wed, 15 Apr 2015 07:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 IOZ6QhhHUp0e for ; Wed, 15 Apr 2015 07:10:07 -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 1DDC61B3552 for ; Wed, 15 Apr 2015 07:10:00 -0700 (PDT) Received: by oift201 with SMTP id t201so23930483oif.3 for ; Wed, 15 Apr 2015 07:09:59 -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:content-type; bh=sV1ukgdSlXYNZKyRsxuGuYwilRDJ62mIwEWs7jpGZYA=; b=FoRa6tIeMmMUdpHh6qAEa0ljMEhv5eAmRMu9VJ66oqukAJBX5GNHattnr46jCt+bui E7b4N7zZD0yb5YKy0AcIpCiecsUL3AzfziCYvtvaA9owvv4LTeYsyVTPP9vDlsDkGO30 0A3sfKl0aM5OuUqpMVcKnMTxP1BIl6hnfk40w5IK6DG8WIRs1irUa8OfkUw8U0t9Ly4O +g0V+A/jQTSeE5p6h19vTL/Av6kqnpu2lexecjp5f/x/k/DRbG34DKrHEGR2jUD2hhGo qBJIHGUX4ooV1diufiSpdqdOQs8btBCl6za4uk4G2j0+VtWR3HvARODuSfFpr64YT9g0 Pjyg== 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-type; bh=sV1ukgdSlXYNZKyRsxuGuYwilRDJ62mIwEWs7jpGZYA=; b=ftnraGIPI6jsOo4cvijwstwGW3ELu3unPhhmimfy+9JC57rBSBspHClUL2xktDHP/s i4sfNDgxgHBzdInK2XVNbEFpqXyGxFJtobODibzAwI1n5fae2g4k/dNTRW6orZESBva9 Tl95cXhFq+euS8YzlmusrPr8UO6C2AubWtknYAsFvq8Zfm2EWILZyjMtki+rHUlvjrD4 2g2TKVsL/5+fVtoXwSxEVFGBx3Q+b2qHCkUFxuKo+NWhco+BUmqP3zhVwg5ESNFvDno6 NYIqONTYaVvuU3rLG7hDl4cgL09EBVgNO1lROrv36xY9aDHDzqufMCACp5RnrxWg10ve bK/Q== X-Gm-Message-State: ALoCoQn/ugJl2AYeayZLrpWKAdSQPrm+fELy6E7AchcLCAPdWzYpCLWaJZOQNX9ribA3m5YTODUf X-Received: by 10.42.207.206 with SMTP id fz14mr31825202icb.34.1429106979045; Wed, 15 Apr 2015 07:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.73.2 with HTTP; Wed, 15 Apr 2015 07:09:18 -0700 (PDT) In-Reply-To: References: <87pp76ew8l.wl-jch@pps.univ-paris-diderot.fr> <87oamqew7u.wl-jch@pps.univ-paris-diderot.fr> From: Lorenzo Colitti Date: Wed, 15 Apr 2015 23:09:18 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=20cf30426df6d5305b0513c3e568 Archived-At: Cc: "homenet@ietf.org" , Juliusz Chroboczek Subject: Re: [homenet] Fwd: ANNOUNCE: babeld-1.6.0 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:10:08 -0000 --20cf30426df6d5305b0513c3e568 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 15, 2015 at 11:07 PM, Mikael Abrahamsson wrote: > Coming from the ISP side, I also question OSPF being mentioned as IGP > while totally excluding ISIS. I dare to say that a majority of the larger > ISP networks of today are running ISIS as their IGP. What does that have to do with it? Unless your statement is "because big backbones with big iron hardware and big support teams are running ISIS, that means home networks with constrained hardware and no support should run ISIS as well"... --20cf30426df6d5305b0513c3e568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 15, 2015 at 11:07 PM, Mikael Abrahamsson <swmike@swm.pp.se><= /span> wrote:
Coming from the ISP side, I= also question OSPF being mentioned as IGP while totally excluding ISIS. I = dare to say that a majority of the larger ISP networks of today are running= ISIS as their IGP.

What does that have to = do with it? Unless your statement is "because big backbones with big i= ron hardware and big support teams are running ISIS, that means home networ= ks with constrained hardware and no support should run ISIS as well"..= .
--20cf30426df6d5305b0513c3e568-- From nobody Wed Apr 15 07:14:03 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8C71A9245 for ; Wed, 15 Apr 2015 07:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 G4O5junJGbi8 for ; Wed, 15 Apr 2015 07:14:01 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2571A6F27 for ; Wed, 15 Apr 2015 07:14:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E3CD0A1; Wed, 15 Apr 2015 16:13:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1429107238; bh=LIsEkrkjPQ8ktS6B3FcMqKXYRgWwYDg8adNRMGL4aSk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3CIRYeb8g62DqdT6tegL+Sy50mdN628+BI8ApxY7b9nybP4iyPwaYqzD056XxLf+1 vNancwnsT+IJqF1c8wujrDSGCsFiUyEPoNr3IXiE0Bdogn2CF8aMijHATngm0hBxrI M27CcKZ+mtNy/6SxFdhWNBi4hWYdaGzqsDPPADQA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DC56C9F; Wed, 15 Apr 2015 16:13:58 +0200 (CEST) Date: Wed, 15 Apr 2015 16:13:58 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <87pp76ew8l.wl-jch@pps.univ-paris-diderot.fr> <87oamqew7u.wl-jch@pps.univ-paris-diderot.fr> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "homenet@ietf.org" , Juliusz Chroboczek Subject: Re: [homenet] Fwd: ANNOUNCE: babeld-1.6.0 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:14:01 -0000 On Wed, 15 Apr 2015, Lorenzo Colitti wrote: > On Wed, Apr 15, 2015 at 11:07 PM, Mikael Abrahamsson > wrote: > >> Coming from the ISP side, I also question OSPF being mentioned as IGP >> while totally excluding ISIS. I dare to say that a majority of the larger >> ISP networks of today are running ISIS as their IGP. > > What does that have to do with it? Unless your statement is "because big > backbones with big iron hardware and big support teams are running ISIS, > that means home networks with constrained hardware and no support should > run ISIS as well"... This was outside the homenet context. Julius et al are making statements in that paper that I don't agree with and I'm making my objection known. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Apr 15 07:18:17 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C759C1B355F for ; Wed, 15 Apr 2015 07:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9nKkvOntV-bM for ; Wed, 15 Apr 2015 07:18:14 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4871B3575 for ; Wed, 15 Apr 2015 07:18:09 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=Hnb6gGsZF3vGJE5wqJ6k/rn3Bq82NpbWKq97oj04JkQ1IdM5tgV6ZmLr 4bj5i4nyjvMrFKNHPZpsJewAMP26PPA0XmMcTbjqxW+vxREOLZGpxTEVA +xm0iXqz2NHCpZ8/qLRbsA7eSXqrJ3SQUTUCuLPzEpP6mjTgolSMtd+EH hWGm/7x0xd7O90h2Q19aGptKaAQ52tTVO79hbhBRu5p+G0ORx1iQ4tpxY gP2uLp7QdVXnBdDc+b/e1X1boFDmT; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1429107489; x=1460643489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+W8GXy9u4nPkP7wlrbwFw7f8F6W1m7rrSwqLpPul/Y4=; b=AushRmZcq9x0LN/y6Xn3f/ZS1JMW8REhZSpiCbvqQd6C+hR1ZHtVXI6k 7fkk/WOULM5QloUzOG8kz74Cs9Ie96hfVNfTNmb/85mmFCLxkg3j8KuDz hYeF/rf1YMYXpxGDUF1CrGOsem7lj90FxLjiZmm8xlTjKQiC7pLMULlhw HxwJ6tEyjYSja0RbxB9nDB3W48Wwv6av4Oz9VI8UazzZKUe7r/dUqX/2F mdbbwBDPMrHE8lPV3UZPfcsGEJnQn; X-IronPort-AV: E=Sophos;i="5.11,582,1422921600"; d="scan'208";a="18257970" X-IPAS-Result: A2BLBQA5ci5V/5HF+NVcgmYmgS4FzS4KAoE6OxEBAQEBAQEBfYQgAQEBAQIBOhkmBQsCAQgOCh4QMiUCBA4FiCIJA8UQAQEBAQEFAQEBAQEBAQEaiyuEfAeDF4EWBZw8gzeQGyKDb2+BRH8BAQE Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 15 Apr 2015 15:18:08 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0224.002; Wed, 15 Apr 2015 15:18:08 +0100 From: Ray Bellis To: Mikael Abrahamsson Thread-Topic: [homenet] ANNOUNCE: babeld-1.6.0 Thread-Index: AQHQd4b+nWqQ9esD00+QNNrLnLqI8w== Date: Wed, 15 Apr 2015 14:18:07 +0000 Message-ID: <77849B39-47CE-42AC-B7C8-FCF4A8110EB8@nominet.org.uk> References: <87pp76ew8l.wl-jch@pps.univ-paris-diderot.fr> <87oamqew7u.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "homenet@ietf.org" , Juliusz Chroboczek , Lorenzo Colitti Subject: Re: [homenet] ANNOUNCE: babeld-1.6.0 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:18:16 -0000 > On 15 Apr 2015, at 15:13, Mikael Abrahamsson wrote: >=20 > This was outside the homenet context. Let's please keep this outside the Homenet list, then. thanks, Ray From nobody Thu Apr 16 04:38:38 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BB1A1B91 for ; Thu, 16 Apr 2015 04:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35] autolearn=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 z_MPWHiVSA1K for ; Thu, 16 Apr 2015 04:38:35 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEAB1A1B8A for ; Thu, 16 Apr 2015 04:38:35 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t3GBcXO7003422; Thu, 16 Apr 2015 13:38:33 +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 654F261FA0; Thu, 16 Apr 2015 13:38:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id RL7ggvfQTFKy; Thu, 16 Apr 2015 13:38:32 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6CCF361F9D; Thu, 16 Apr 2015 13:38:28 +0200 (CEST) Date: Thu, 16 Apr 2015 13:39:53 +0200 Message-ID: <874moggv3q.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Mikael Abrahamsson In-Reply-To: References: <87pp76ew8l.wl-jch@pps.univ-paris-diderot.fr> <87oamqew7u.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, 16 Apr 2015 13:38:33 +0200 (CEST) X-Miltered: at korolev with ID 552F9F39.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 552F9F39.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 : 552F9F39.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] Fwd: ANNOUNCE: babeld-1.6.0 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 11:38:37 -0000 > could you please elaborate on one sentence in the abstract from Answered by private mail, as requested by Ray. -- Juliusz From nobody Wed Apr 22 02:58:42 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC85D1B339D; Wed, 22 Apr 2015 02:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 IQriQx9MzgJk; Wed, 22 Apr 2015 02:58:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AB21B339F; Wed, 22 Apr 2015 02:58:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 02:58:37 -0700 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 09:58:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Distributed Node Consensus Protocol Authors : Markus Stenberg Steven Barth Filename : draft-ietf-homenet-dncp-02.txt Pages : 27 Date : 2015-04-22 Abstract: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP is transport agnostic and leaves some of the details to be specified in profiles, which define actual implementable DNCP based protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-dncp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 22 03:00:55 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33CB1B3152 for ; Wed, 22 Apr 2015 03:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 hBavbqAnC51B for ; Wed, 22 Apr 2015 03:00:47 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [82.96.72.7]) by ietfa.amsl.com (Postfix) with ESMTP id 06DA91B313F for ; Wed, 22 Apr 2015 03:00:41 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1YkrSP-0004nt-JB with ESMTPSA (TLSv1.2:DHE-RSA-AES128-SHA:128) for ; Wed, 22 Apr 2015 12:00:37 +0200 Message-ID: <5537713E.8070107@openwrt.org> Date: Wed, 22 Apr 2015 12:00:30 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Ray Bellis , HOMENET , Mark Townsley References: <20150305123318.3794.66093.idtracker@ietfa.amsl.com> <058278B2-0D66-44CF-80E0-35E394139AD5@nominet.org.uk> In-Reply-To: <058278B2-0D66-44CF-80E0-35E394139AD5@nominet.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] WG Actions X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 10:00:50 -0000 Hello everyone, we have just pushed dncp-02 which addresses the remaining open issues we had identified and that were brought forward to us. We - the authors - believe the draft to be complete now. Changelog: 1. Changed DNCP "messages" into series of TLV streams, allowing optimized round-trip saving synchronization. 2. Added fragmentation extension for bigger node data and for chunking in absence of reliable L2 and L3 fragmentation. 3. Various minor cleanups and clarifications On 05.03.2015 15:25, Ray Bellis wrote: > Please provide further reviews for the recently updated draft-ietf-homenet-dncp and draft-ietf-homenet-hncp-04. We believe these are very close to ready for WGLC. > We would kindly request doing a last call for DNCP since no further issues were brought up in Dallas nor in a subsequent call to the list ( https://www.ietf.org/mail-archive/web/homenet/current/msg05128.html ) Latest Draft: https://tools.ietf.org/html/draft-ietf-homenet-dncp-02 Cheers, Steven and Markus From nobody Wed Apr 22 16:37:25 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EE61B2B84 for ; Wed, 22 Apr 2015 16:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 WjoxuHBJVh2C for ; Wed, 22 Apr 2015 16:37:22 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 A12731B2B80 for ; Wed, 22 Apr 2015 16:37:22 -0700 (PDT) Received: by paboj16 with SMTP id oj16so1831853pab.0 for ; Wed, 22 Apr 2015 16:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6+/4zdaLG49mlykkBt1YrTXD+5qZe7CCbqLOZA8yjlA=; b=ifYP3wPTybEfmqBG50haeoNeJF7UIeA/eBhpJdBTUPYCSEUZ85zPoKPQpm1XVueon+ DgHOTm5KkDDsTifVQNboJO4+8Pw8zM026HOM+ilnJ3hNyKXmcbaGVwl16ofgpeltyNtG gFCfRF+MVo7w5brKgPI7nXUKjcQg7YL33CCe0o/nuqPXjFIcD//Pa/iOgbQXJKl/SdYt KdY8yOphaFE9VLSZ9LgYFvO02s8Sk+CnjtB1Tv8jo4x8WnRMWiu38qBILVooQHOSDRPP ANsivGD2IV9GqVLolFLyfMn0tcsu9fEa+SeBmH+gT5zSIEqpu+0G/Ly+YzdimYrQ1Z0y 4IoQ== X-Received: by 10.70.125.129 with SMTP id mq1mr45448pdb.19.1429745842394; Wed, 22 Apr 2015 16:37:22 -0700 (PDT) Received: from ?IPv6:2406:e007:55fb:1:28cc:dc4c:9703:6781? ([2406:e007:55fb:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id tz4sm6211506pac.46.2015.04.22.16.37.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Apr 2015 16:37:21 -0700 (PDT) Message-ID: <553830B7.8070100@gmail.com> Date: Thu, 23 Apr 2015 11:37:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: homenet@ietf.org References: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> In-Reply-To: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 23:37:24 -0000 Hi, > 1. Changed DNCP "messages" into series of TLV streams, allowing optimized round-trip saving synchronization. So, I have a couple of questions about the new text: A DNCP message in and of itself is just an abstraction; when using reliable stream transport, the whole stream of TLVs can be considered a single message, with new TLVs becoming gradually available once they have been fully received. On datagram transport, each individual datagram is a separate message. In order to facilitate fast comparing of local state with that in a received update, TLVs in every container TLV MUST be placed in ascending order based on the binary comparison of both TLV header and value. Firstly how do I know when I have received the end of "the whole stream of TLVs"? It's presumably not infinite, but with no clear notion of a "message" how do I know when to stop processing? Secondly, please define the phrase "container TLV". It's quite unclear to me whether your model is simply a sequence of separate TLVs or whether TLVs are encapsulated, i.e. does the length field of the first TLV include the size of some embedded TLVs? Of course I could go and read the code to find out what you really mean, but this should really be specified at the beginning of section 7 "Type-Length-Value Objects". > 2. Added fragmentation extension for bigger node data and for chunking in absence of reliable L2 and L3 fragmentation. Hmm. For GDNP we are thinking of simply saying "use a conservative MTU and TLS" to avoid fragmentation. Regards Brian Carpenter From nobody Wed Apr 22 23:47:09 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5E21ACE81 for ; Wed, 22 Apr 2015 23:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 ZTQNuH7FK0TQ for ; Wed, 22 Apr 2015 23:47:06 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id 578191B2A0F for ; Wed, 22 Apr 2015 23:46:39 -0700 (PDT) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 552B87C9013B4EBB; Thu, 23 Apr 2015 09:46:37 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Markus Stenberg In-Reply-To: <553830B7.8070100@gmail.com> Date: Thu, 23 Apr 2015 09:46:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> <553830B7.8070100@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2098) Archived-At: Cc: homenet@ietf.org, Markus Stenberg Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 06:47:08 -0000 On 23.4.2015, at 2.37, Brian E Carpenter = wrote: >> 1. Changed DNCP "messages" into series of TLV streams, allowing = optimized round-trip saving synchronization.=20 >=20 > So, I have a couple of questions about the new text: >=20 > A DNCP message in and of itself is just an abstraction; when using > reliable stream transport, the whole stream of TLVs can be = considered > a single message, with new TLVs becoming gradually available once > they have been fully received. On datagram transport, each > individual datagram is a separate message. In order to facilitate > fast comparing of local state with that in a received update, TLVs = in > every container TLV MUST be placed in ascending order based on the > binary comparison of both TLV header and value. >=20 > Firstly how do I know when I have received the end of "the whole = stream > of TLVs"? It's presumably not infinite, but with no clear notion of a > =E2=80=9Cmessage" how do I know when to stop processing? You can process TLVs invididually (the length is in second byte = received), or in small chunks. TLV processing definition has only one = dependency on other TLVs (node data has to have respective node state = =E2=80=99nearby=E2=80=99, for undefined nearby) in the stream, and the = node connection TLV must be remembered per message (=3Dwhole TCP stream = or single UDP datagram) if encountered. Any suggestions on how to rephrase that to be more clear? > Secondly, please define the phrase "container TLV". It's quite unclear > to me whether your model is simply a sequence of separate TLVs or > whether TLVs are encapsulated, i.e. does the length field of the first > TLV include the size of some embedded TLVs? Of course I could go and > read the code to find out what you really mean, but this should really > be specified at the beginning of section 7 =E2=80=9CType-Length-Value = Objects". The later. I guess some sort of update is needed here. Node Data TLV is the only container TLV in the base spec (but it only = says nested TLVs). The base spec has no other container TLVs.=20 I noticed also that the Node Data TLV is missing a description. I guess = it only alludes to how it is encoded with the variable length, but that = could also just refer to the node identifier which is variable length in = base spec so clearly more detail is needed here. >> 2. Added fragmentation extension for bigger node data and for = chunking in absence of reliable L2 and L3 fragmentation. > Hmm. For GDNP we are thinking of simply saying "use a conservative MTU > and TLS=E2=80=9D to avoid fragmentation. With TCP (=3DTLS) fragmentation isn=E2=80=99t a problem anyway for most = part. Of course, as our single node=E2=80=99s data is encoded (by = default) in a single Node Data TLV, that sets 2^16 size limit to it; = that can be worked around using the fragmentation scheme as well. Thanks for the comments ;) Cheers, -Markus= From nobody Thu Apr 23 21:46:40 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853581B2C5C for ; Thu, 23 Apr 2015 21:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zixvefQkgkNn for ; Thu, 23 Apr 2015 21:46:37 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::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 EAE5E1B2C5B for ; Thu, 23 Apr 2015 21:46:18 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so37975066pdb.1 for ; Thu, 23 Apr 2015 21:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FbQkNJ3L6AKYXZj3JZs+wVRiafqEh2FF3All9WCzpZU=; b=FMrtxMgGaYtM5wo8J6PZrnlXipWVR4qiVb1NGcVKqGLWApy4TC1BG/YemvBYtlWihh rCQiKLBVcymzK928K48ex3efHG++xjwkwe9BwRBhaesIaPsxhr89sbqgFdQgnLZ+zGrM fmFOW5zWAseMyKla/PVQs0pYPtmBCI8azL63CtVpAvEcGtO+VhfZ+Eth+FkZW8yqQFW7 m5PwSbS4zLDPGgqWgrd3IxAlWXAsGN1dsFug94vtsBRF0Y4BoMFpKNxN9Rvz1x6oNlqt EFXxuEAHZ9TKgnkeiA1tHQLEzxJ/5sjrP4KX5op2lQcA+XB0wd2aPsbQPhCglJRv10S1 shQA== X-Received: by 10.67.4.138 with SMTP id ce10mr11498637pad.102.1429850778616; Thu, 23 Apr 2015 21:46:18 -0700 (PDT) Received: from ?IPv6:2406:e007:6a88:1:28cc:dc4c:9703:6781? ([2406:e007:6a88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id p1sm9655563pdl.60.2015.04.23.21.46.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 21:46:17 -0700 (PDT) Message-ID: <5539CAA1.8000401@gmail.com> Date: Fri, 24 Apr 2015 16:46:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Markus Stenberg References: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> <553830B7.8070100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 04:46:39 -0000 Hi Markus, On 23/04/2015 18:46, Markus Stenberg wrote: > On 23.4.2015, at 2.37, Brian E Carpenter = wrote: >>> 1. Changed DNCP "messages" into series of TLV streams, allowing optim= ized round-trip saving synchronization.=20 >> >> So, I have a couple of questions about the new text: >> >> A DNCP message in and of itself is just an abstraction; when using >> reliable stream transport, the whole stream of TLVs can be considere= d >> a single message, with new TLVs becoming gradually available once >> they have been fully received. On datagram transport, each >> individual datagram is a separate message. In order to facilitate >> fast comparing of local state with that in a received update, TLVs i= n >> every container TLV MUST be placed in ascending order based on the >> binary comparison of both TLV header and value. >> >> Firstly how do I know when I have received the end of "the whole strea= m >> of TLVs"? It's presumably not infinite, but with no clear notion of a >> =E2=80=9Cmessage" how do I know when to stop processing? >=20 > You can process TLVs invididually (the length is in second byte receive= d), or in small chunks. TLV processing definition has only one dependency= on other TLVs (node data has to have respective node state =E2=80=99near= by=E2=80=99, for undefined nearby) in the stream, and the node connection= TLV must be remembered per message (=3Dwhole TCP stream or single UDP da= tagram) if encountered. OK, so the process will just keep running until the TCP session closes, as I understand it. Which incidentally means that you tie up the listen p= ort, doesn't it? In GDNP we think of more transactional messages, which is why= I wasn't understanding DNCP properly. >=20 > Any suggestions on how to rephrase that to be more clear? Maybe you need an outline description of the DNCP state machine. >=20 >> Secondly, please define the phrase "container TLV". It's quite unclear= >> to me whether your model is simply a sequence of separate TLVs or >> whether TLVs are encapsulated, i.e. does the length field of the first= >> TLV include the size of some embedded TLVs? Of course I could go and >> read the code to find out what you really mean, but this should really= >> be specified at the beginning of section 7 =E2=80=9CType-Length-Value = Objects". >=20 > The later. I guess some sort of update is needed here. Yes, it's not quite clear. >=20 > Node Data TLV is the only container TLV in the base spec (but it only s= ays nested TLVs). The base spec has no other container TLVs. OK. >=20 > I noticed also that the Node Data TLV is missing a description. I guess= it only alludes to how it is encoded with the variable length, but that = could also just refer to the node identifier which is variable length in = base spec so clearly more detail is needed here. >=20 >>> 2. Added fragmentation extension for bigger node data and for chunkin= g in absence of reliable L2 and L3 fragmentation. >> Hmm. For GDNP we are thinking of simply saying "use a conservative MTU= >> and TLS=E2=80=9D to avoid fragmentation. >=20 > With TCP (=3DTLS) fragmentation isn=E2=80=99t a problem anyway for most= part. Of course, as our single node=E2=80=99s data is encoded (by defaul= t) in a single Node Data TLV, that sets 2^16 size limit to it; that can b= e worked around using the fragmentation scheme as well. OK, that's clear now, thanks. Brian >=20 > Thanks for the comments ;) >=20 > Cheers, >=20 > -Markus >=20 From nobody Fri Apr 24 00:52:02 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCFF1B352B for ; Fri, 24 Apr 2015 00:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 hXkMjLFHTEga for ; Fri, 24 Apr 2015 00:51:59 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id 454D91AC438 for ; Fri, 24 Apr 2015 00:51:33 -0700 (PDT) Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5511FF6403B5E69B; Fri, 24 Apr 2015 10:51:30 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Markus Stenberg In-Reply-To: <5539CAA1.8000401@gmail.com> Date: Fri, 24 Apr 2015 10:51:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1741C705-0A3E-43EC-9ECD-DEB95B197143@iki.fi> References: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> <553830B7.8070100@gmail.com> <5539CAA1.8000401@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2098) Archived-At: Cc: homenet@ietf.org, Markus Stenberg Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 07:52:01 -0000 On 24.4.2015, at 7.46, Brian E Carpenter = wrote: >> You can process TLVs invididually (the length is in second byte = received), or in small chunks. TLV processing definition has only one = dependency on other TLVs (node data has to have respective node state = =E2=80=99nearby=E2=80=99, for undefined nearby) in the stream, and the = node connection TLV must be remembered per message (=3Dwhole TCP stream = or single UDP datagram) if encountered. > OK, so the process will just keep running until the TCP session = closes, > as I understand it. Which incidentally means that you tie up the = listen port, > doesn't it? In GDNP we think of more transactional messages, which is = why > I wasn=E2=80=99t understanding DNCP properly. I am not sure what do you mean with listen port; the TCP connection is = (proto, ip1, p1, ip2, p2) tuple, and one listen port can obviously = produce as many TCP connections as there are connecting clients (as long = as you do not run out of the tuples). However, the duration of the TCP connection is intentionally not = specified in the core protocol; a DNCP profile _may_ tie e.g. peer state = to it=E2=80=99s lifetime (in which case longer durations are = preferable), but it also may not. >> Any suggestions on how to rephrase that to be more clear? > Maybe you need an outline description of the DNCP state machine. Well, that is intentionally omitted. The mandatory =E2=80=99state = machine=E2=80=99 should be simply Trickle caused network state messages, = and then processing triggered by them (the MUSTs in the processing of = received TLVs). This is so that =E2=80=99simple=E2=80=99 implementation is indeed simple = (in -03 we will probably send today, we are removing the # of TLVs that = need to be handled from 6 to 5 by removing the node data altogether, as = it had implicit dependency on node state anyway to be useful), Given the per-TLV semantics, optimizations such as more proactive = spreading of state _will_ be supported by simple clients, although they = are not even specified in the DNCP base spec yet, we have just some = ideas for implementation purposes.=20 Anyway, sending updated -03 probably later today or early next week, it = should hopefully make the per-TLV nature bit more clear (and also = address some other things). Cheers, -Markus= From nobody Fri Apr 24 02:52:17 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1471A1A3B for ; Fri, 24 Apr 2015 02:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JMbx8hSXNlc1 for ; Fri, 24 Apr 2015 02:52:14 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 67B921A1A12 for ; Fri, 24 Apr 2015 02:52:13 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=kR7PURSptieg/7RyHcHnEx/STDLA2LHSW8NgqNRPKULFiV1UCM2CANOo OrZslva4oA+434Xc/Rj/eaqOyifJFXC1xdi/PoPMax/j04+FQFUCMMIjr epcO4fZE9z8+oOWchWFhR/uwOcxbBvsOYgxa7luPhe12Jf89wkXufrvKR Pkllbb9An/gdtPUmtx2Ld9HlEZkxHPcZMVlIPSSZIEK1T/Uph5hAIJpHK IJkZjPr1tNbjsuAVrBmHSYxfCNSDd; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1429869134; x=1461405134; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=RB487RKuv9qWd/jR9CZwOa9crSW5SIl4FzaBFvP11OY=; b=DDLjoOKq6R2OnPoj7wPLvA3zZ3pf11tRZpZCsqCNlnu1ly+BKUpib9xv 98Y+w9SkOmHBzolQ1LQOtHMslyQCXGCD9IWaLcmYDiv0dqD4fvvorJDaN TfEt/ZVj+LBkORUjPmsDU5hHWVQKCsgAwU7Ma/Pc+CWXa5G0c0Levkfld mgWthXgqDtfo5qIh+OSPD8xX1GS2Lq/ADxp5T/MWZd7vtssoyfnQHMwH+ cvyWHEWkOc1nMrucrRkLmzC8+SAaq; X-IronPort-AV: E=Sophos;i="5.11,638,1422921600"; d="scan'208";a="17397022" X-IPAS-Result: A2CVBgAbEjpVdJHF+NVbgmaBVAW4WAGPJIdPPBABAQEBAQEBEQEMbIQnOhk4AT5CJwQTiCwDpySkWQEfj1gRAYNvgRYFsUqEF2+BCzmBAAEBAQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 24 Apr 2015 10:52:03 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0224.002; Fri, 24 Apr 2015 10:52:03 +0100 From: Ray Bellis To: HOMENET Thread-Topic: Change of affiliation and email address Thread-Index: AQHQfnRQHzVwcfjd7UOV732BlXBAZQ== Date: Fri, 24 Apr 2015 09:52:01 +0000 Message-ID: <381E80EA-6E2D-4055-9222-897E8CCBE6EB@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [homenet] Change of affiliation and email address X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 09:52:16 -0000 I'm leaving Nominet today to join ISC, so my old email address will stop wo= rking. My new email address for IETF-related stuff is ray+ietf@bellis.me.uk. Mark and I can also be reached via the WG alias of homenet-chairs@tools.iet= f.org Ray From nobody Fri Apr 24 03:56:45 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FDA1A88E4; Fri, 24 Apr 2015 03:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 AfkmbLIy2lOn; Fri, 24 Apr 2015 03:56:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC221A19F0; Fri, 24 Apr 2015 03:56:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150424105642.12256.59303.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 03:56:42 -0700 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-dncp-03.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 10:56:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Distributed Node Consensus Protocol Authors : Markus Stenberg Steven Barth Filename : draft-ietf-homenet-dncp-03.txt Pages : 27 Date : 2015-04-24 Abstract: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP is transport agnostic and leaves some of the details to be specified in profiles, which define actual implementable DNCP based protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-dncp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 24 04:17:02 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767301A8A6B for ; Fri, 24 Apr 2015 04:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 n1JOVVatCydE for ; Fri, 24 Apr 2015 04:16:58 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [82.96.72.7]) by ietfa.amsl.com (Postfix) with ESMTP id 27D151A8A56 for ; Fri, 24 Apr 2015 04:16:58 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1YlbbM-00031u-4a with ESMTPSA (TLSv1.2:DHE-RSA-AES128-SHA:128) for homenet@ietf.org; Fri, 24 Apr 2015 13:16:56 +0200 Message-ID: <553A2621.4090400@openwrt.org> Date: Fri, 24 Apr 2015 13:16:49 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: homenet@ietf.org References: <20150424105642.12256.59303.idtracker@ietfa.amsl.com> In-Reply-To: <20150424105642.12256.59303.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dncp-03.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 11:17:00 -0000 Just a quick update, based on the feedback we got here and on private channels. This is mostly a cleanup to remove the partly ambiguous use of the terms "connection" and "message" and one backwards-incompatible change to TLVs to simplify the state machines and get rid of an unnecessary TLV-to-TLV dependency as well as an accompanyingTLV-renumbering. Draft: https://tools.ietf.org/html/draft-ietf-homenet-dncp-03 Cheers, Steven On 24.04.2015 12:56, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Home Networking Working Group of the IETF. > > Title : Distributed Node Consensus Protocol > Authors : Markus Stenberg > Steven Barth > Filename : draft-ietf-homenet-dncp-03.txt > Pages : 27 > Date : 2015-04-24 > > Abstract: > This document describes the Distributed Node Consensus Protocol > (DNCP), a generic state synchronization protocol which uses Trickle > and Merkle trees. DNCP is transport agnostic and leaves some of the > details to be specified in profiles, which define actual > implementable DNCP based protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-homenet-dncp-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From nobody Fri Apr 24 13:25:15 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2841A6FCF for ; Fri, 24 Apr 2015 13:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 nEMWhgE3BgVm for ; Fri, 24 Apr 2015 13:25:12 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 916821A6F3F for ; Fri, 24 Apr 2015 13:25:12 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so35773386pac.0 for ; Fri, 24 Apr 2015 13:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mTs+LCdUeT5yDf4+5FbV+bwHg1Y/e5sNKHqtaC+6ge4=; b=B/sVDP1qRHuh1SKE2y/2+l5LFygt4nVYhDkfcyQWMZcEDlGlBlswgYf9J8vO9JUF02 zG40ScqUoKOQ6384LXlLflqH9Mi9iiHdndJLd7e33fxQDMxRz4ANeLrF2KfMmTpOwdN0 yNEH1aFqQFGuCbdmhQdA4EN0GJjZ+7MU1511X9R1kwfDpXEIGdSnI7XWuOSWPZTX1p3o QaStddifXXpBHpy27diQdi3uf3QESq5/W7Q66WmoOg/uCrKX35YhG5xzYU5jHHs5R+bQ zFgwTVa8MygsusYzr5ZdueceENiFdJtVBu/l7nihpwIriOi77gDwPVoRHIfef4CFlPYW vZEg== X-Received: by 10.66.162.74 with SMTP id xy10mr256770pab.55.1429907112325; Fri, 24 Apr 2015 13:25:12 -0700 (PDT) Received: from ?IPv6:2406:e007:419a:1:28cc:dc4c:9703:6781? ([2406:e007:419a:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id w1sm11956771pdp.25.2015.04.24.13.25.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2015 13:25:11 -0700 (PDT) Message-ID: <553AA6B1.1050009@gmail.com> Date: Sat, 25 Apr 2015 08:25:21 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Markus Stenberg References: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> <553830B7.8070100@gmail.com> <5539CAA1.8000401@gmail.com> <1741C705-0A3E-43EC-9ECD-DEB95B197143@iki.fi> In-Reply-To: <1741C705-0A3E-43EC-9ECD-DEB95B197143@iki.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 20:25:14 -0000 On 24/04/2015 19:51, Markus Stenberg wrote: > On 24.4.2015, at 7.46, Brian E Carpenter = wrote: >>> You can process TLVs invididually (the length is in second byte recei= ved), or in small chunks. TLV processing definition has only one dependen= cy on other TLVs (node data has to have respective node state =E2=80=99ne= arby=E2=80=99, for undefined nearby) in the stream, and the node connecti= on TLV must be remembered per message (=3Dwhole TCP stream or single UDP = datagram) if encountered. >> OK, so the process will just keep running until the TCP session closes= , >> as I understand it. Which incidentally means that you tie up the liste= n port, >> doesn't it? In GDNP we think of more transactional messages, which is = why >> I wasn=E2=80=99t understanding DNCP properly. >=20 > I am not sure what do you mean with listen port; the TCP connection is = (proto, ip1, p1, ip2, p2) tuple, and one listen port can obviously produc= e as many TCP connections as there are connecting clients (as long as you= do not run out of the tuples). Yes, but that means that DNCP can only be used for one thing at a time; i= f you want to synchronize two different datasets you would need two ports. That's fine,= it's just different from our goals with GDNP, which is why I wanted to underst= and it. >=20 > However, the duration of the TCP connection is intentionally not specif= ied in the core protocol; a DNCP profile _may_ tie e.g. peer state to it=E2= =80=99s lifetime (in which case longer durations are preferable), but it = also may not. >=20 >>> Any suggestions on how to rephrase that to be more clear? >> Maybe you need an outline description of the DNCP state machine. >=20 > Well, that is intentionally omitted. The mandatory =E2=80=99state machi= ne=E2=80=99 should be simply Trickle caused network state messages, and t= hen processing triggered by them (the MUSTs in the processing of received= TLVs). Fair enough, but not quite obvious until you stated it. Thanks Brian >=20 > This is so that =E2=80=99simple=E2=80=99 implementation is indeed simpl= e (in -03 we will probably send today, we are removing the # of TLVs that= need to be handled from 6 to 5 by removing the node data altogether, as = it had implicit dependency on node state anyway to be useful), >=20 > Given the per-TLV semantics, optimizations such as more proactive sprea= ding of state _will_ be supported by simple clients, although they are no= t even specified in the DNCP base spec yet, we have just some ideas for i= mplementation purposes.=20 >=20 > Anyway, sending updated -03 probably later today or early next week, it= should hopefully make the per-TLV nature bit more clear (and also addres= s some other things). >=20 > Cheers, >=20 > -Markus >=20 From nobody Fri Apr 24 14:25:21 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263DD1AC417 for ; Fri, 24 Apr 2015 14:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 KqQKSGdXRAoT for ; Fri, 24 Apr 2015 14:25:18 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out1.inet.fi [62.71.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id E17BF1AC419 for ; Fri, 24 Apr 2015 14:25:15 -0700 (PDT) Received: from poro.lan (80.220.64.126) by kirsi2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5511FF6A003BB456; Sat, 25 Apr 2015 00:25:12 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Markus Stenberg In-Reply-To: <553AA6B1.1050009@gmail.com> Date: Sat, 25 Apr 2015 00:25:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <23B9BA3F-BCDD-4191-9BDC-2CE84809F7BC@iki.fi> References: <20150422095837.6049.29336.idtracker@ietfa.amsl.com> <553830B7.8070100@gmail.com> <5539CAA1.8000401@gmail.com> <1741C705-0A3E-43EC-9ECD-DEB95B197143@iki.fi> <553AA6B1.1050009@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.2098) Archived-At: Cc: homenet@ietf.org, Markus Stenberg Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:25:20 -0000 On 24.4.2015, at 23.25, Brian E Carpenter = wrote: > On 24/04/2015 19:51, Markus Stenberg wrote: >> On 24.4.2015, at 7.46, Brian E Carpenter = wrote: >>>> You can process TLVs invididually (the length is in second byte = received), or in small chunks. TLV processing definition has only one = dependency on other TLVs (node data has to have respective node state = =E2=80=99nearby=E2=80=99, for undefined nearby) in the stream, and the = node connection TLV must be remembered per message (=3Dwhole TCP stream = or single UDP datagram) if encountered. >>> OK, so the process will just keep running until the TCP session = closes, >>> as I understand it. Which incidentally means that you tie up the = listen port, >>> doesn't it? In GDNP we think of more transactional messages, which = is why >>> I wasn=E2=80=99t understanding DNCP properly. >>=20 >> I am not sure what do you mean with listen port; the TCP connection = is (proto, ip1, p1, ip2, p2) tuple, and one listen port can obviously = produce as many TCP connections as there are connecting clients (as long = as you do not run out of the tuples). > Yes, but that means that DNCP can only be used for one thing at a = time; if you want to > synchronize two different datasets you would need two ports. That's = fine, it's > just different from our goals with GDNP, which is why I wanted to = understand it. Yes. But you can run multiple instances of DNCP on a single transport = stream easily enough (by inserting e.g. 1 byte instance id at front of = each TLV, or by defining some container TLV semantics) in a profile if = you want to. I guess there are other schemes for that as well. However, = the core protocol intends to stay simple so I am not sticking them (or = areas) there :-) (You could probably even share keepalives across instances, therefore = keeping it still efficient.) Cheers, -Markus= From nobody Mon Apr 27 11:01:52 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D6F1A904A for ; Mon, 27 Apr 2015 11:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2mMVPaStvDAd for ; Mon, 27 Apr 2015 11:01:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39171A0211 for ; Mon, 27 Apr 2015 11:01:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9950A203BB for ; Mon, 27 Apr 2015 14:13:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2A91263B86; Mon, 27 Apr 2015 14:01:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 143F463731 for ; Mon, 27 Apr 2015 14:01:48 -0400 (EDT) From: Michael Richardson To: homenet@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: [homenet] homenet requirements on ISPs -- should write them down? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 18:01:52 -0000 --=-=-= Content-Type: text/plain This WG has been chartered to address networking issues in the home. In the process of doing this we have made various assumptions about what ISPs might (or might not) provide. These have mostly been aligned with what other groups (particularly ops area groups) have said. In many cases, we have taken the approach about what ISPs might/sometimes do, or things that we think all ISPs will do. For instance, BCP38 (ingress filtering of source addresses) puts a significant constraint on how we build our homenets. We have also said decided that we won't deal with the case where an ISP provides enough IPv6 space to number the homenet, (other than to say that we hope to fail gracefully). QUESTION: I wonder if we should collect these things into an ISP requirements document. Well... "requirements" might be too strong a word here. Maybe "wishlist" is more appropriate; my purpose is not to argue the precise term here, but rather to condense the list more clearly. BACKGROUND to why this email today: I say this with a hat I wear a few days/month as the maintainer of a PPPoE appliance/access concentrator that has widespread deployment, and has been shipping IPv6 (rfc6204/7084) support since last fall. I think that it will grow support for additional things we might specify in homenet. For instance delegation of reverse DNS zones. (In creating my work plan, in the end I had to reverse engineer the Broadband Forum TR-187 to decide what services I needed to provide. RFC6204 wasn't enough) I am updating the NTP software in this appliance, and I'm looking at a question, should I enable 5906 by default. rfc5906 is, to save you a trip to your browser: Network Time Protocol Version 4: Autokey Specification This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions. ... In smaller, understaffed ISPs, anything the edge concentrator can do out of the box without additional configuration is a boon, so being the NTP server for the connected homes is a good thing.... should I think about turning on 5906? well, the question becomes: will anyone need it? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVT55i4CLcPvd0N1lAQL1UAf/R8yyZHaTKR8O9K/guTIhMvFG7orWtKJ1 J9Qf5+Gy33DzVPRrgWR/dX2vRxfh3gn1saxq89DVXcqE4sJPaJbKIyc2BSH+owrk wtZdV5EDbo5gYCemCJ0FhrOIgxPBben99zQZARHSIlJtTKuN8EtcsGB2mv68EyoR GJa4OSG0nwxocUYD+0LMz5tgWoMGBeb16t+fOyQim19oz4xqSRIcPwBAscsOgXSW pKSmtRfQLcLcQu8MJYEdCVmwBjVdVrlFHYdh/nKERkyvqqh4ZbhZbinVrOdxAeTW xRJuNi1rGwkGWiGGjRTxZO7ufr+GrqIv2filIyzB4At5WnEs4ZQhgg== =aoEZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 28 02:03:39 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB591A1BA9 for ; Tue, 28 Apr 2015 02:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 DDclQ-4pQ234 for ; Tue, 28 Apr 2015 02:03:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208811A1B8C for ; Tue, 28 Apr 2015 02:03:35 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t3S93T1W027905; Tue, 28 Apr 2015 10:03:29 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t3S93T1W027905 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1430211810; bh=zlWb5sjhT7oZgMKqkrH/R5r2SFc=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=MUedSnl265aFGgVScrTxKBUaaLsWgJefwFc8sKrkkRZ1LEOwtgDRaKYsCPTKR90kR j9nh9qVUigZKgH9viPXj+UXy0qVay7wacG0PvmDd1fGHh8cz2NbScr90pwxyVvZC4B 4nUH0/4TmLl+Lgx8wt81D+6ROksjX9KWr7gM/lmM= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r3RA3Y288410235586 ret-id none; Tue, 28 Apr 2015 10:03:30 +0100 Received: from [10.1.11.13] ([194.82.140.195]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t3S928bO015203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 10:02:08 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0B510A9F-AED4-435A-BA4F-6A324B620C49"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Tim Chown In-Reply-To: <23802.1430157708@sandelman.ca> Date: Tue, 28 Apr 2015 10:02:11 +0100 Message-ID: References: <23802.1430157708@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2098) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r3RA3Y288410235500; tid=r3RA3Y288410235586; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t3S93T1W027905 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] homenet requirements on ISPs -- should write them down? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 09:03:38 -0000 --Apple-Mail=_0B510A9F-AED4-435A-BA4F-6A324B620C49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 27 Apr 2015, at 19:01, Michael Richardson = wrote: >=20 >=20 > This WG has been chartered to address networking issues in the home. > In the process of doing this we have made various assumptions about = what ISPs > might (or might not) provide. These have mostly been aligned with = what other > groups (particularly ops area groups) have said. >=20 > In many cases, we have taken the approach about what ISPs = might/sometimes do, > or things that we think all ISPs will do. For instance, BCP38 = (ingress > filtering of source addresses) puts a significant constraint on how we = build > our homenets. We have also said decided that we won't deal with the = case > where an ISP provides enough IPv6 space to number the homenet, (other = than to > say that we hope to fail gracefully). >=20 > QUESTION: > I wonder if we should collect these things into an ISP = requirements document. > Well... "requirements" might be too strong a word here. Maybe = "wishlist" is > more appropriate; my purpose is not to argue the precise term = here, but > rather to condense the list more clearly. I agree. I think there are a number of things that could/should be teased out of = the work done to date and made more explicit (and expanded) in separate documents. = These might include, as rough working titles : - Recommendations for ISPs providing residential IPv6 - Management and monitoring of IPv6 home networks (something Joel asked = for as we wrapped up RFC7368) - Security architecture for IPv6 home networks - Graceful(!) renumbering of IPv6 home networks (drawing on 6renum and = its gaps document) The ISP document would also help more knowledgable customers understand = the expectations they might have of their ISP. Something for the chairs to consider. None of the above should prevent = existing work continuing, but it may be useful to document common understanding of = what we=E2=80=99re trying to achieve. Tim > BACKGROUND to why this email today: >=20 > I say this with a hat I wear a few days/month as the maintainer of a = PPPoE > appliance/access concentrator that has widespread deployment, and has = been > shipping IPv6 (rfc6204/7084) support since last fall. > I think that it will grow support for additional things we might = specify in > homenet. For instance delegation of reverse DNS zones. >=20 > (In creating my work plan, in the end I had to reverse engineer the = Broadband > Forum TR-187 to decide what services I needed to provide. RFC6204 = wasn't enough) >=20 > I am updating the NTP software in this appliance, and I'm looking at a > question, should I enable 5906 by default. rfc5906 is, to save you a = trip to > your browser: > Network Time Protocol Version 4: Autokey Specification > This memo describes the Autokey security model for authenticating > servers to clients using the Network Time Protocol (NTP) and public > key cryptography. Its design is based on the premise that IPsec > schemes cannot be adopted intact, since that would preclude > stateless servers and severely compromise timekeeping accuracy. In = addition, > Public Key Infrastructure (PKI) schemes presume authenticated > time values are always available to enforce certificate lifetimes; > however, cryptographically verified timestamps require interaction > between the timekeeping and authentication functions. >=20 > ... > In smaller, understaffed ISPs, anything the edge concentrator can do = out > of the box without additional configuration is a boon, so being the = NTP > server for the connected homes is a good thing.... should I think = about > turning on 5906? well, the question becomes: will anyone need it? >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | network = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_0B510A9F-AED4-435A-BA4F-6A324B620C49 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 iQEcBAEBCgAGBQJVP0yUAAoJEFoq8u2Gfpfes54IAIcWFa76C+iGRlUTbGBnwuVe Qe3+7bBVvC5r63vOQ14x/bWIUJ5JoMDalD2hJsPliJyhiEiJLkvBVHE08PvS+fVE 5WlED8wa90pprmcuERtApxaPYojyh/lclwf2SyhQZKEzZ1vNgBZAnNNdJOscb+uQ eavgJg6B/fjKliNIZORbXaYi8y/nw3mRaCbyafPb130mA1mRMnxMy/B7SB2BXGKo lybitLmgbnkO6ILl5Co5d2Q5wgyJ/nJlatL0WYK9Oy2OnKfGi2bO2IGEm/rJ1Abj OQvH/KfkgFR8hnraa1fQ0G/vXhFe5JVrcA3M8YWzWclNfiEr5YKgLlbJc6i8vSk= =punh -----END PGP SIGNATURE----- --Apple-Mail=_0B510A9F-AED4-435A-BA4F-6A324B620C49-- From nobody Tue Apr 28 10:19:47 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4C61B2AF9 for ; Tue, 28 Apr 2015 10:18: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 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 dTQQ4Tt07OnK for ; Tue, 28 Apr 2015 10:18:41 -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 5FB051B2AF3 for ; Tue, 28 Apr 2015 10:18:37 -0700 (PDT) Received: from dhcp-wifi-245.sql1.isc.org ([149.20.50.245]:52516) 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 1Yn99U-0002Zw-Rm (Exim 4.72) for homenet@ietf.org (return-path ); Tue, 28 Apr 2015 18:18:33 +0100 Message-ID: <553FC0E8.5080309@bellis.me.uk> Date: Tue, 28 Apr 2015 10:18:32 -0700 From: Ray Bellis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: homenet@ietf.org References: <23802.1430157708@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 28 Apr 2015 10:19:46 -0700 Subject: Re: [homenet] homenet requirements on ISPs -- should write them down? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 17:18:46 -0000 On 28/04/2015 02:02, Tim Chown wrote: > Something for the chairs to consider. None of the above should > prevent existing work continuing, but it may be useful to document > common understanding of what we’re trying to achieve. It sounds like a fine idea to me, but I shall need to discuss with my co-chair and AD when I get back to the UK next week, not least to confirm whether it's in charter (and if not, whether the charter could be updated to accommodate this). Ray From nobody Wed Apr 29 19:31:46 2015 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9811A90C4 for ; Wed, 29 Apr 2015 19:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eOp7-qzeMXnN for ; Wed, 29 Apr 2015 19:31:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AA51A90B8 for ; Wed, 29 Apr 2015 19:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3665; q=dns/txt; s=iport; t=1430361103; x=1431570703; h=date:from:to:cc:subject:message-id:reply-to:mime-version; bh=b2utyfaCiIWrqbrGD1C4/Wap30sNW++1EOQtomemFvc=; b=LSYfqTCHqukFdx063nri9jE5caj5eYd1pq/q7Fzrk26hLst6fgEkG+Si +KsN84JZgGsFlI0XhB51daXDjYPIeHwJLfEq38dW7/M8/jkMd1YYz0Oq9 /w9zffXTytBsRwUp1GwBZ8XQxfZKI+nWT6+yFXfD4w8j1XJprZEcIS92u 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBQBmk0FV/4cNJK1cgwxTXAHHX4YCgUVMAQEBAQEBgQuEIgEhHTQLMwk0BTmITQENq16OWY0KAQEBAQEBBAEBAQEBARyLOIE9AYJvWIMegRYFi2uKCIY+AYEjPYMMiWCGX00jYIEFIg0PgXFQgQIBHgaBHQEBAQ X-IronPort-AV: E=Sophos;i="5.11,674,1422921600"; d="scan'208";a="415976818" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 30 Apr 2015 02:31:42 +0000 Received: from cisco.com (irp-view14.cisco.com [171.70.123.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3U2Vfk9016348; Thu, 30 Apr 2015 02:31:41 GMT Received: (from eckert@localhost) by cisco.com (8.13.7/8.13.7) id t3U2Ve4S014685; Wed, 29 Apr 2015 19:31:40 -0700 (PDT) Date: Wed, 29 Apr 2015 19:31:40 -0700 From: Toerless Eckert To: homenet@ietf.org Message-ID: <20150430023140.GA14360@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Archived-At: Cc: "Liubing \(Leo\)" , "anima-chairs@tools.ietf.org" Subject: [homenet] FWD/FYI: Re: Call for Volunteer - ANIMA signaling design team X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: anima@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 02:31:45 -0000 Just wanted to forward. Not meant for discussion on the homenet mailing list On Mon, Apr 27, 2015 at 10:02:13AM +0000, Sheng Jiang wrote: > Hi, all, > > We are calling for volunteers to form a design time for ANIMA signaling design team. The chairs has assigned two editors (Brian Carpenter and Bing Liu), we are expecting up to 4 main contributors. The charter, initial goal and target date for the signaling design team is introduced below. It also available in the design team wiki page. > > http://trac.tools.ietf.org/wg/anima/trac/wiki/Signaling > > Because of the intended design team work, we expect that the design team members would need to spend at least half a day per week on this project for maybe 4..6 month, but it should become less afterwards. We would like to limit the design team to one year (or shorter if the goals are reached faster of course). > > As WG chairs we will participate and help of course in the design team primarily for logistics. In principle, the design team discussions should be open for all ANIMA participators. People who is interested, but do not have enough time to commit, could also be able to participate and make contributions or comments. > > This call is last for one week. It ends May 3rd, Sunday. Please reply before it if you are interested in the commitment. > > Charter for the signaling design team > > The Anima WG charter states a requirement for discovery and negotiation mechanisms to enable closed-loop interaction between autonomic nodes. It also states the goal of developing one or more protocol specifications (or extensions to existing protocols) to achieve these goals. There is an existing draft requirements analysis, whose main points include > > - support for any type of network objective parameter; > - discovery must support any topology and bootstrap scenario; > - synchronize parameters with other nodes individually or by flooding; > - negotiate parameters with other nodes; > - always secure. > > A simple TLV format is proposed for the protocol design. Binary or name-based discovery are proposed as alternative discovery approaches. > > The purpose of the design team is to analyze these issues and recommend a combined approach to the working group, preferably in the form of one draft or a small set of coordinated drafts. The proposed approach should be suitable for use by the Autonomic Control Plane, and for other use cases including those listed in the Anima WG charter. > > In preparing the recommendation, the design team will verify and update the existing requirements and understand the relevant use cases. However, documenting and solving use cases is out of scope for the design team. The design team is encouraged to develop protocol walkthroughs and an abstract API as aids to understanding. The design team is not itself expected to produce code, but ease of implementation is an important consideration. > > The draft(s) should be delivered by the July 2015 IETF (2015-07-06 cutoff date). > > Initial Goals > > - Validate and update the existing list of requirements (?http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-2) against bootstrap and ACP drafts (and optionally against other use case validation drafts). Target date: end May. > - Recommend how the other milestone components of ANIMA (bootstrap, ACP, validation drafts) should use the signaling protocol(s). As a side-effect, critique the proposal on the table (?https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol#section-3). > > Target date: mid June. > > Best regards, > > Toerless + Sheng