From nobody Wed Jan 1 17:11:37 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC0F1200F6 for ; Wed, 1 Jan 2020 17:11:35 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXQrQ1v6DRLZ for ; Wed, 1 Jan 2020 17:11:34 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 488121200DF for ; Wed, 1 Jan 2020 17:11:34 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id b15so33030161iln.3 for ; Wed, 01 Jan 2020 17:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/jHmNZ4Kvsb5tFUIvqNVDRGNO8I5px+xxTK2R+oUUqE=; b=CnGPAHM8n7c6Chbuw1sbJ/ggGs0Agz+zoQXiP5ot4gbuLkbGyC7IP6kO5LxMn3Eovd P+pCb4XqUQwA8ARObQq2lRlv7vVLvRsZNqrL9SskrpwCrLcN3HNtFiGUtCMbNU6c/2vL boLzThYwI3s3HZyNDJt16J8xloQv5vyWbKX8De9eRUr0xnn08dhcbLgYZxiPNMjdV91A zeWbp2BuucefiAf6kSyx8EKNAUiB6yARl2Io5hpoOWF2FIxrfltYFCCSoTpLCmqfKeLh Hrh5i1wDk2YZmRboTK1rGM9H+fkQs8wT4RJ+uyWA5IWNgnOnas22k6YL+Z/ZsJUFPtoS 4ldA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/jHmNZ4Kvsb5tFUIvqNVDRGNO8I5px+xxTK2R+oUUqE=; b=DHuCouipITkzUD9IL5bQF5yC0gLWVje02JN4rtja2vOnDKvADQRzO0PU7xFjUpLDvi 6A7j9E22VFTKpP6XWqf3hQYIXa0RCjIIpAQrVjSzRa+yxzbA7roUeHlLdqOhH0chZw+E h/gcLIpdL9BsjhVUah8oi3Mp8mxS3zcgBbhilEyzoF7ILvL/oCMnj6485HSDggaFYlg0 ZUmXy53UI6+5KqQk/zUvwYZpOTKNd7hi5pm0MO3gxvuDQZwWoN0xTVAH8t5qha/1/2j2 jxVMxV8B0R7Nyo0keFaPEHvm310xkLfNweJLBTc4S+VjuKifOFqFRWtaxEOyrvxwzLC/ RDfg== X-Gm-Message-State: APjAAAVYH/mAPnt91EGeK8zGndVHfNlUT3JKuTcQavrmPBJHsGBqJanG hTct+CjzYXuOCEbt1sIsxKnshA6jXbqrrUa/B/zN8LPG X-Google-Smtp-Source: APXvYqwBpOncTTokz83+yRRnDfbCfvE290lZbJfNoaQYOQKbHt/ijKWeU1kp0ZWLs9aGJpi4KyF4PGSIV8ZAczxye2Y= X-Received: by 2002:a92:cd52:: with SMTP id v18mr71129438ilq.83.1577927493402; Wed, 01 Jan 2020 17:11:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Wed, 1 Jan 2020 20:11:22 -0500 Message-ID: To: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Cc: Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel-MAC: key size and digest size X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 01:11:36 -0000 Hi Antonin, Thanks for your comments. They look plausible to me although it is common to use truncated MACs. However, I'm thinking that at this stage, it would be best to get draft-ietf-babel-rfc6126bis, and the draft that are being held up by it through the process, and then start an update to or a revision of the Babel HMAC draft. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Sat, Dec 28, 2019 at 1:15 PM Antonin D=C3=A9cimo wrote: > > Hello again, > > I'm keeping in mind that (=C2=A77): > > Every implementation MUST implement HMAC-SHA256 as defined in > > [RFC6234] and Section 2 of [RFC2104] , SHOULD implement keyed > > BLAKE2s [RFC7693] , and MAY implement other MAC algorithms. > > > 1. Key length > > This is the change I'm proposing in =C2=A77: > > Keys must be chosen in a manner that makes them difficult to guess. > -Ideally, they should have a length of 32 octets (both for HMAC-SHA256 > -and Blake2s), and be chosen randomly. > +Ideally, they should be chosen randomly, and have the maximum key > +length supported by the MAC algorithm (32 octets for keyed BLAKE2S) > +or no less than the block size of the MAC algorithm (64 octets for > +HMAC-SHA256). > > > 2. Digest length > > After a bit of sleep, I realised that reading the length of the MAC > TLV in order to compute a MAC of this length is not compliant with the > protocol (=C2=A74.3) since MACs are computed without looking into the > packet. > > > Then, for each key configured on the receiving interface, the > > receiver computes the MAC of the packet. It then compares every > > generated MAC against every MAC included in the packet; > > Still, it was an error I was almost going to make. I propose the > following change to ensure that we're always using the maximum digest > length of the MAC algorithm. > > This is the change I'm proposing in =C2=A74.1: > > implementation MUST implement HMAC-SHA256 as defined in > and Section 2 of , > SHOULD implement keyed BLAKE2s , and MAY imple= ment > other MAC algorithms. > +The length of the MAC MUST be the maximum MAC length computable by > +the MAC algorithm (32 octets for both HMAC-SHA256 and keyed > +BLAKE2S). > > > 3. Lazy computation > > With the idea that computing a MAC is more costly than comparing MACs, > and that there's a very limited amount of MACs to check, I propose we > lazily compute MACs. Instead of computing the MAC for every key on > packet reception, we compute the MAC with the first key, then check it > against the MACs carried by the packet. If there's a match, the packet > is immediately accepted. If there's no match, we the proceed to the > next key until all keys are exhausted, and the packet is rejected. > > This is the change I'm proposing in =C2=A74.3: > > -Then, for each key configured on the receiving interface, the > -receiver computes the MAC of the packet. It then compares every > -generated MAC against every MAC included in the packet; if there is > -at least one match, the packet passes the MAC test; if there is none, > -the packet MUST be silently dropped and processing stops at this > -point. > +Then, for each key configured on the receiving interface, the > +receiver computes the MAC of the packet and compares it against every > +MAC included in the packet; if there is at least one match, the > +packet passes the MAC test; if there is none, the receiver proceeds > +with the next key. If none of the MAC matched, the packet MUST be > +silently dropped and processing stops at this point. > > > Cheers! > > -- Antonin > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Thu Jan 2 20:27:28 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD27D1200C1 for ; Thu, 2 Jan 2020 20:27:26 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKpvCUFEi07p for ; Thu, 2 Jan 2020 20:27:25 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 AEB3A1200B4 for ; Thu, 2 Jan 2020 20:27:25 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id z12so35676466iln.11 for ; Thu, 02 Jan 2020 20:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=j8pei6ac26pQlNAVIDRWjDVEgoa1MsI800BYJo7L6EU=; b=h5o3B7aklB/VRNw/93f4cNswOHsGZX8wT+ztVztBifBRNEO9pM4kiaPIyLHBRFsBqm qroqukjwqBVxU4ve8/X6pzGkR/WV2S0dZ6TbExYxcf9HlquwWjwbprwmXMIWVCUIMpZO I7AyauV2PnktBRUxmKU90lnIY04gvOxewNrt0j5KXd2VQLkcRoEt935nzRS3HiCKF/Wa CqKH/la2ejyvw3k5GMrS6O9s5iVogGu/IQjAqsMcN2aoZhi5Fy4kfM1rC2bUdpjRWc5z kbx+7Z15rIeVpNENHAt23+aDUnt7wAWBruyFSLtJzobgyZKUjtjYLZibNdksWh0oyFE+ rVPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=j8pei6ac26pQlNAVIDRWjDVEgoa1MsI800BYJo7L6EU=; b=htVoaKr1cWVCCKvg7ztOYH+XmTyXxX8yc0UDXy1sM//K/0cpdjwr7szFTYSZlkwSBn etQUIaeoTVJ24Lh+EqQBSviWuBzJIDDJhTWVXRIpoY4/fltxVK/UgfrXVsKzXMrFsMWN QBuZDTdU9lehaaN9i8D1v9QDR0kj63/EBQSQPIjFJGiuViYk20aOhVgA3VoEQYIsYV2L fvwkfQcCebPQGGei3vRQhcaBz+iz2cSGAyydkF+DLxdmUNpQrj1Sp8xLIl0ug1DtqCJv mQTq8FpVxZ6HrZwPeomU8R4q77gaiCZqLiZknTZSIFOXFxphcjeDlwhkrA/WEvB3Xebi LT5Q== X-Gm-Message-State: APjAAAXgo1aqCXMHfInKbiEELXdyYzlCCrvc9qVBgnDu8VdeWKzO5s1R 6hu1RtjR4Qx3xy8WIDKORCtYhEuxd8h7n4D/HOU= X-Google-Smtp-Source: APXvYqwYfPqKr9YMt31gBQmTLYuFCr0KIwpGz2Z3e15tcugRrgy50bYD8qUWg28ft+0IvQoNVcErtKWgx32MgwmkQjQ= X-Received: by 2002:a92:cd52:: with SMTP id v18mr76718887ilq.83.1578025645024; Thu, 02 Jan 2020 20:27:25 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Thu, 2 Jan 2020 23:27:14 -0500 Message-ID: To: Mahesh Jethanandani Cc: Babel at IETF Content-Type: multipart/alternative; boundary="00000000000004aa45059b34ba10" Archived-At: Subject: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 04:27:27 -0000 --00000000000004aa45059b34ba10 Content-Type: text/plain; charset="UTF-8" Hi Mahesh, Happy New Year! There seems to be a minor format problem in this draft, in particular four lines, all identical, that are 76 characters long. Lines over 72 characters are not allowed in Internet Drafts. On page 34, page 35, page 36, and page 38 the following line occurs: xmlns:babel="urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel Is it possible to fold this into something like xmlns:babel= "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel or just reduce the indent of those lines? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --00000000000004aa45059b34ba10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

Happy New Year!

There seems to be= a minor format problem in this draft, in particular four lines, all identi= cal, that are 76 characters long. Lines over 72 characters are not allowed = in Internet Drafts.

On page 34, page 35, page 36, and page 38 the fo= llowing line occurs:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ie= tf-babel">babel:babel
Is it possible to fold this into so= mething like
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:babel=3D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "urn:ietf:par= ams:xml:ns:yang:ietf-babel">babel:babel
or just reduce the inden= t of those lines?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2= =A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panor= amic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com
--00000000000004aa45059b34ba10-- From nobody Thu Jan 2 23:21:25 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECDE120072 for ; Thu, 2 Jan 2020 23:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmYD7MnL0Y0z for ; Thu, 2 Jan 2020 23:21:21 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 8DC60120043 for ; Thu, 2 Jan 2020 23:21:21 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id 2so23154802pfg.12 for ; Thu, 02 Jan 2020 23:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gd74xofnmBMrTycF5pjIqXAq5c2n7v2KZqVrfzUiEUg=; b=gWecRUPu9YuLbF8BWZtbd1bzE8xZzTHlbPKKbmefyCHE1sH+AWVaaH3sC+ZoNGqnPM rNslAXf1hvx/gJd+1EzY1tjnXDqCwMMCvqMyfkeBtDy67v7zfgTA4eQoHIVFnFVhMpjI /tz8g7CTl+Ma/oLaJe3KJNBv2NgBdXlXMnPHktPUJ7aLKuHwPR9glgVoUlI1ToZNFHA4 C84gucr+htwCsOlOd44s3wUcmWVbTRV1lcPaHMZiClU4IIHX7a/m3uWZoBSiIOvyGtrF i9pIZQs4A1hvaz5aPKZqSA1Eg/l+MCuQ8WlTuw62kBgHZsvRHIygucyCAydLz4xEvtla tbwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gd74xofnmBMrTycF5pjIqXAq5c2n7v2KZqVrfzUiEUg=; b=c3IBfD/gSq1iITAoooAZUSZh6SEZ4nXQ4YOzpLYhOBIukJTsgv+wIMqEwa5mfaXDxw 8FOPl3EjHQXhgLMrT7Xww9FsUsObv1oYoqTubDm+yK9pnYZ2y5zYCpPKKAWXe5AoOloZ 4Wrao6NicIi/FPt3jv8sZZQmDMNbNZucvm2RwbVTnKiDRNNs5RaqaEtwvd3b3Ayj5CBl s3V/FHOJFm5SLLkFUWR7so0tPj90UJvgYE1EGXqUMUKHvo3Yn5vuxmMmjqjXYDM/iPO9 aFBIaGgNw5LO+NgshZz3qpCu33CXcP12TVQtX2iLkBSjwQTybdMnq4O6l9uSnXWM4X+g /Ppg== X-Gm-Message-State: APjAAAUl4bi+/mIbiFIFwMDC5vXH0rmLPT+3LDhKfm5Ow+d3soKgipsZ 9sq/II+QGMPM4tRceC8CW01TrhbJ X-Google-Smtp-Source: APXvYqwolLPqGFeHildjVUo24aIqodwepqTXyztAsyoVccDrv3uMhq5YWqlYUbsOL2MmJB06nJ8L2g== X-Received: by 2002:a63:289:: with SMTP id 131mr95768735pgc.149.1578036080757; Thu, 02 Jan 2020 23:21:20 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:8169:a975:e1cf:abf8? ([2601:647:5600:5020:8169:a975:e1cf:abf8]) by smtp.gmail.com with ESMTPSA id p28sm62990620pgb.93.2020.01.02.23.21.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jan 2020 23:21:20 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E1BFE63B-F406-431C-AE75-382FD43843E0 Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani X-Mailer: iPad Mail (16A404) In-Reply-To: Date: Thu, 2 Jan 2020 23:21:19 -0800 Cc: Babel at IETF Content-Transfer-Encoding: 7bit Message-Id: References: To: Donald Eastlake Archived-At: Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 07:21:22 -0000 --Apple-Mail-E1BFE63B-F406-431C-AE75-382FD43843E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Donald, Yes, that should be ok. And thanks for catching it. Cheers. Mahesh Jethanandani mjethanandani@gmail.com > On Jan 2, 2020, at 8:27 PM, Donald Eastlake wrote: >=20 > Hi Mahesh, >=20 > Happy New Year! >=20 > There seems to be a minor format problem in this draft, in particular four= lines, all identical, that are 76 characters long. Lines over 72 characters= are not allowed in Internet Drafts. >=20 > On page 34, page 35, page 36, and page 38 the following line occurs: > xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:b= abel > Is it possible to fold this into something like > xmlns:babel=3D > "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel > or just reduce the indent of those lines? >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com --Apple-Mail-E1BFE63B-F406-431C-AE75-382FD43843E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Donald,

Yes, that sho= uld be ok. And thanks for catching it.

Cheers.
<= br>
Mahesh Jethanandani
=

On Jan 2, 2020, at 8:27 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:

Hi Mahesh,

= Happy New Year!

There seems to be a minor format problem in this draf= t, in particular four lines, all identical, that are 76 characters long. Lin= es over 72 characters are not allowed in Internet Drafts.

On page 34,= page 35, page 36, and page 38 the following line occurs:
            xmlns:babel=3D"u= rn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
Is it possib= le to fold this into something like
          &n= bsp; xmlns:babel=3D
              &nbs= p; "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
or just reduce= the indent of those lines?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Pan= oramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
= --Apple-Mail-E1BFE63B-F406-431C-AE75-382FD43843E0-- From nobody Fri Jan 3 10:33:10 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8B12002F for ; Fri, 3 Jan 2020 10:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwnkgMH1TdRJ for ; Fri, 3 Jan 2020 10:33:06 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 CF876120013 for ; Fri, 3 Jan 2020 10:33:06 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id z12so801415iln.11 for ; Fri, 03 Jan 2020 10:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m+RP2S7spgSiYKvD6XwYf25lzwGIReiFVnTBxf6L78w=; b=BxMmyCT+muZKM65PDt0y9gGupZJadozGaaDpvAEltXod0LutPQiSR8+9beNwqGNQ4L O+Cue1zkYA913fo5hmQHr5OHNHhfJ3GUPGy+e7daO8WeJ5tWsLkR/XEkfcEjMZQOYXHs yLE1GrNdIs+GSr9EmBuTpjVkejTDWZ/EIBdW21yk8IZjVn0VKkIjk6zKijydL0+OPdSs +qqoO8F7luatTV9CP1QX+eScH4ugRCElnjUGCjwpj5MHdrMd2tjL8EZEsKIZIM9fD6FC La33JqazSCDWP7L3AQ8IBVLBcKy60728DCP1Rn+T6JT+LwcHxM30ttvsjRge6se0Dmjx +wEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m+RP2S7spgSiYKvD6XwYf25lzwGIReiFVnTBxf6L78w=; b=RYdWbQSkxSJ4ImTmrcfm8AsHzz5BxI+1XjZTQPsbPjagPaxUfM8i26U9DeNyjpmUc/ ksz2iITG9UOCdm+cMw7aVikRh3qIJSRn/yijvoCritImLepLt2J2Cyu/6c0iwTp1xFXh TVGupvYCugs3ZKd/BepOGPhXshN53HyiDPXDkmrSaz7AFNfM/a/iBu+VvEim+PvtI5ZF bLdkBe9FaeW1M8wdvZeetV4F/e3HLzMPwh1NY0WXZoPLD8Fel41latPlKOEeshlmc8Nl LzD2LVH2kWUCX4mtuzqaJMBEcyckUTX5XXNIyTbmDKoSloA28h9A2ZycUoUn6LCltJ6q IJrQ== X-Gm-Message-State: APjAAAU15Jq8i9t7IuQseCWOrAlaRUQnsMabt/CBE6y5vcH3Uw/1tiBB x8Eo09gOB8O0OokozQxQ/PqaaBxZH3aft5zuGrc= X-Google-Smtp-Source: APXvYqyU6p6/9UsPCOivLROigWiebCKZCumrxWy65zgBzDYomQZL6UjWeTJSxcueC34ucZNq6NTWXY/jw1rJC3dUPkM= X-Received: by 2002:a92:8712:: with SMTP id m18mr72499155ild.40.1578076386149; Fri, 03 Jan 2020 10:33:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Fri, 3 Jan 2020 13:32:55 -0500 Message-ID: To: Mahesh Jethanandani Cc: Babel at IETF Content-Type: multipart/alternative; boundary="0000000000006ccdf4059b408a48" Archived-At: Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 18:33:08 -0000 --0000000000006ccdf4059b408a48 Content-Type: text/plain; charset="UTF-8" Hi Mahesh, You're welcome. My apologies for not noticing it earlier. Can you go ahead and post a revision with this trivial change? Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani wrote: > Hi Donald, > > Yes, that should be ok. And thanks for catching it. > > Cheers. > > Mahesh Jethanandani > mjethanandani@gmail.com > > On Jan 2, 2020, at 8:27 PM, Donald Eastlake wrote: > > Hi Mahesh, > > Happy New Year! > > There seems to be a minor format problem in this draft, in particular four > lines, all identical, that are 76 characters long. Lines over 72 characters > are not allowed in Internet Drafts. > > On page 34, page 35, page 36, and page 38 the following line occurs: > > xmlns:babel="urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel > Is it possible to fold this into something like > xmlns:babel= > "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel > or just reduce the indent of those lines? > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > --0000000000006ccdf4059b408a48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

You're welcome. My apolo= gies for not noticing it earlier. Can you go ahead and post a revision with= this trivial change?

Thanks,
Donald=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-= 2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0<= a href=3D"mailto:d3e3e3@gmail.com" target=3D"_blank">d3e3e3@gmail.com


On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani <= mjethanandani@gmail.com> = wrote:
Hi Donald,

Yes, that should be ok. And thanks = for catching it.

Cheers.

Mahesh Jethanandani

On Jan 2, 2020, at 8:27 PM, D= onald Eastlake <d3= e3e3@gmail.com> wrote:

Hi Mahesh,

Happy New Year!

There = seems to be a minor format problem in this draft, in particular four lines,= all identical, that are 76 characters long. Lines over 72 characters are n= ot allowed in Internet Drafts.

On page 34, page 35, page 36, and pag= e 38 the following line occurs:
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:babel=3D"urn:ietf:params:xml:= ns:yang:ietf-babel">babel:babel
Is it possible to fold th= is into something like
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:b= abel=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ur= n:ietf:params:xml:ns:yang:ietf-babel">babel:babel
or just reduce= the indent of those lines?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0238= 6 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com
--0000000000006ccdf4059b408a48-- From nobody Fri Jan 3 13:21:49 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2542120045 for ; Fri, 3 Jan 2020 13:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP35ivACcLAF for ; Fri, 3 Jan 2020 13:21:46 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 4F706120026 for ; Fri, 3 Jan 2020 13:21:46 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id bg7so5172702pjb.5 for ; Fri, 03 Jan 2020 13:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NL+mQogA4YGF7S5nXkZjrDX0YUmQZwvMC11Zi+/E+7M=; b=HkNctMqjsQUckUzV+0I8j3lWlDfVz8g1IDhagxUuqJbXzxmcRf4fTmm/gLhOJjoD4q Kjhb/uY+tQA0kMUFvfNgfH1C9S5rpjJEW1U7QWywiOE44pjcv5jJey8yw4/zENKckLL4 aB/WUONyDV/UngA1br8RJclcUFZa2iUumwRULbg9PCXX1iOpxr01CcEmrRGLCHoe0T2P bqFMuYk1a2IOkn5H6dPf2NKeNM267evX0IPdLBfhIewd0mNwRBopzH4V2VAb6YPj6PrT fmvp5icUvlCm+OLknDFlwZ2/zgoIi0h/rZuJZmQRlKs6pMqzpXfAZLRrlwcJueDFwzYl 9iZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NL+mQogA4YGF7S5nXkZjrDX0YUmQZwvMC11Zi+/E+7M=; b=rBnmGg4Ij75PIUBMPBb/7paHIxVQmDbtHh0Hfbj+ZNPp7T1Q/B5QdbF3O6cGqgTPaj fDeRoPlFr2YA8yGIooe3Hu7toclFB3WXT0ltDOygyK+YTFWYb4qyzxrRffLe54YvrX54 p/ZHaYBIUnTuMpH1a3J5FCHhHK7SiwTofI9Zypu1ku8bdKC1VDzL7F3wYM1dIjzvdCoT ly/AJ3OPe70gveRLjsnaFm1LgdOwCt8ios1ccawb7Zi6fM3kMl4uDeI/WjD6ifj2d0F2 7Izfk4ZiA/bg0mRDOtWiep+Jqd2I2elGsSlJG/39UX2gXU5yHADyzucSQGeoSvOhh4lm /3hA== X-Gm-Message-State: APjAAAUq2m5s7xCxpmoQKg9Z9a+gvY8DfD7w9HCqAMONdTTbnblfniDQ j6ffHoNmtyPqkp/otmsRQRk= X-Google-Smtp-Source: APXvYqzVd0RZnZ8tEgpY0TgHpXDY0jwR1jgIfpHHp0nmU4JdAUJrgsT+Zuhh8K7o2RHiecqovwdlhQ== X-Received: by 2002:a17:902:32b:: with SMTP id 40mr37860539pld.22.1578086505728; Fri, 03 Jan 2020 13:21:45 -0800 (PST) Received: from [192.168.1.122] (c-73-93-49-153.hsd1.ca.comcast.net. [73.93.49.153]) by smtp.gmail.com with ESMTPSA id n188sm64936458pga.84.2020.01.03.13.21.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jan 2020 13:21:44 -0800 (PST) From: Mahesh Jethanandani Message-Id: <98799C32-6591-475E-B9F3-B6E31D828154@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA9B2188-0F28-4CFE-9DA9-5BE637A96067" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 3 Jan 2020 13:21:43 -0800 In-Reply-To: Cc: Babel at IETF To: Donald Eastlake References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 21:21:48 -0000 --Apple-Mail=_EA9B2188-0F28-4CFE-9DA9-5BE637A96067 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Donald, In trying to make the changes you requested, I came across another = change that needs to be pushed. The information model suggests that babel-information-obj should = maintain a list of metric-comp-algorithm that are supported by an = implementation. The problem with just keeping a list in YANG is that = there is no way to enforce that the implementation uses only those = algorithms. To address the issue we had introduced the concept of = features in -04 version of the draft. Using the feature statement, the implementation can declare which of the = metric-comp-algorithms it supports, which was the intention of having a = list of those algorithms in the first place. As such, we do not need the = global list anymore, and needs to be removed. I will be adding that = change in the -05 version of the draft. If you feel that it requires a short LC to be issued, please feel free = to do so after I post the draft. Thanks. > On Jan 3, 2020, at 10:32 AM, Donald Eastlake wrote: >=20 > Hi Mahesh, >=20 > You're welcome. My apologies for not noticing it earlier. Can you go = ahead and post a revision with this trivial change? >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com >=20 > On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani = > wrote: > Hi Donald, >=20 > Yes, that should be ok. And thanks for catching it. >=20 > Cheers. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 > On Jan 2, 2020, at 8:27 PM, Donald Eastlake > wrote: >=20 >> Hi Mahesh, >>=20 >> Happy New Year! >>=20 >> There seems to be a minor format problem in this draft, in particular = four lines, all identical, that are 76 characters long. Lines over 72 = characters are not allowed in Internet Drafts. >>=20 >> On page 34, page 35, page 36, and page 38 the following line occurs: >> = xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel >> Is it possible to fold this into something like >> xmlns:babel=3D >> "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel >> or just reduce the indent of those lines? >>=20 >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> d3e3e3@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_EA9B2188-0F28-4CFE-9DA9-5BE637A96067 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Donald,

In trying to = make the changes you requested, I came across another change that needs = to be pushed.

The information model suggests that babel-information-obj = should maintain a list of metric-comp-algorithm that are supported by an = implementation. The problem with just keeping a list in YANG is that = there is no way to enforce that the implementation uses only those = algorithms. To address the issue we had introduced the concept of = features in -04 version of the draft.

Using the feature statement, the = implementation can declare which of the metric-comp-algorithms it = supports, which was the intention of having a list of those = algorithms in the first place. As such, we do not need the global list = anymore, and needs to be removed. I will be adding that change in the = -05 version of the draft.

If you feel that it requires a short LC to be issued, please = feel free to do so after I post the draft.

Thanks.

On Jan 3, 2020, at 10:32 AM, Donald Eastlake <d3e3e3@gmail.com> = wrote:

Hi Mahesh,

You're welcome. My apologies for not noticing it earlier. = Can you go ahead and post a revision with this trivial change?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani = <mjethanandani@gmail.com> wrote:
Hi = Donald,

Yes, that = should be ok. And thanks for catching it.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com

On Jan 2, 2020, at 8:27 PM, Donald Eastlake = <d3e3e3@gmail.com> wrote:

Hi Mahesh,

Happy New Year!

There seems to = be a minor format problem in this draft, in particular four lines, all = identical, that are 76 characters long. Lines over 72 characters are not = allowed in Internet Drafts.

On page 34, = page 35, page 36, and page 38 the following line occurs:
    =         = xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
Is it possible to fold this into something like
            xmlns:babel=3D
                = "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
or = just reduce the indent of those lines?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake = 3rd   +1-508-333-2270 (cell)
 2386 Panoramic = Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_EA9B2188-0F28-4CFE-9DA9-5BE637A96067-- From nobody Mon Jan 6 06:09:25 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BD4120818; Mon, 6 Jan 2020 06:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuyVBLvbYHei; Mon, 6 Jan 2020 06:09:21 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 74480120815; Mon, 6 Jan 2020 06:09:21 -0800 (PST) Received: from 200116b8243550004499ccf78e5880e6.dip.versatel-1u1.de ([2001:16b8:2435:5000:4499:ccf7:8e58:80e6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ioT4I-00068q-Tv; Mon, 06 Jan 2020 15:09:18 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87r212n59b.wl-jch@irif.fr> Date: Mon, 6 Jan 2020 15:09:18 +0100 Cc: David Schinazi , draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs , Babel at IETF , Alvaro Retana , The IESG , Donald Eastlake , Martin Vigoureux Content-Transfer-Encoding: quoted-printable Message-Id: <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578319761;99821748; X-HE-SMSGID: 1ioT4I-00068q-Tv Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 14:09:23 -0000 Hi Juliusz, I didn=E2=80=99t talk about pacing in that mail but only about defining = default values for the interval parameters you already have defined in = the draft. If all deployed scenarios use the first set of values and these value = are well applicable for all different scenarios that are defined in the = use case doc, such as =E2=80=9Csmall unmanaged network" as well as in a = "large overlay network=E2=80=9D, why don=E2=80=99t you just specify = these values as normatively default value in the spec? Mirja > On 17. Dec 2019, at 20:04, Juliusz Chroboczek wrote: >=20 >>> If that is the case, then I request that you state explicitly why = you >>> think that Babel must be held to a much higher standard than OSPFv3. = If >>> that is not the case, then please clear your discuss. >=20 >> In OSPFv3 as far as I can see (and I am really not an expert here) = all >> values that define intervals are in seconds which leads to a minimum >> value of 1 seconds. This is not the case for babel and therefore we = need >> to be more carful here. >=20 > After a change of topology, OSPF executes the procedure described in > Section 4.5.2 of RFC 5340 (Section 13.3 of RFC 2328). At this point, > a potentially unbounded number of LSAs are flooded out every active > interface (point 5 in Section 13.3 of RFC 2328). This flooding is not > regulated by any timer -- all that the protocol says is that the LSAs = must > go out through a certain subset of the router's interfaces. >=20 > I could be wrong, but I am fairly confident that nothing in RFCs 5340 = and > 2328 specifies congestion control, flow control or packet pacing for = this > flooding procedure. My interpretation is that since OSPF is designed = to > be deployed on local links, congestion caused by OSPF is not likely to > endanger the Global Internet, and therefore packet pacing (if = required) is > left to the implementation. >=20 > I also don't recall any discussion of flow control in Moy's and = Gredler's > books, but they have a lot of pages (especially Gredler's), so, again, > I could be wrong. >=20 > Where you are right, Mirja, is that packet pacing is a very difficult > problem in OSPF, where incorrectly delaying flooding could lead to > microloops; since Babel has a loop-avoidance mechanism built-in, it = can > safely perform packet pacing should the need to do so be demonstrated = in > a particular topology. >=20 > In summary, while I agree that packet pacing for Babel would be an > interesting research project, I maintain that by requiring packet = pacing > as a condition for publication as PS, you are requiring an = unreasonably > high standard, certainly a standard that neither OSPF nor IS-IS are = held to. >=20 >>> Appendix B gives values that are suggested for implementations. >=20 >> Yes but it doesn=E2=80=99t discuss for with _deployment_ scenarios = these values >> are suitable. >=20 > As far as I am aware, all current production deployments use the first = set > of constants. The one exception is an experimental testbed used for > mobility research, that uses the (more aggressive) second set of = constants. >=20 >> Did you deploy the same parameters in all of the discussed scenarios. >=20 > Yes. >=20 >> Does it actually makes sense to use the same parameters in a "small >> unmanaged network" as well as in a "large overlay network"? >=20 > Yes. >=20 >> Is that network connected to the Internet or not? >=20 > Yes, but that's irrelevant -- the Babel traffic is link-local, and = does > not go outside the local routing domain. >=20 > -- Juliusz >=20 From nobody Mon Jan 6 06:39:57 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4969D120864 for ; Mon, 6 Jan 2020 06:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Squs0radhxCY for ; Mon, 6 Jan 2020 06:39:48 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DB7120823 for ; Mon, 6 Jan 2020 06:39:47 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 006EZMCp036556; Mon, 6 Jan 2020 09:39:46 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2xb9475vme-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 06 Jan 2020 09:39:46 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 006EdiH4029979; Mon, 6 Jan 2020 09:39:44 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 006EddvY029885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Jan 2020 09:39:39 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 8E7614009E7C; Mon, 6 Jan 2020 14:39:39 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30485.vci.att.com (Service) with ESMTPS id 7791E4009E75; Mon, 6 Jan 2020 14:39:39 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0468.000; Mon, 6 Jan 2020 09:39:38 -0500 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" , "'Donald Eastlake'" CC: "'Babel at IETF'" Thread-Topic: [babel] Minor format problem in draft-ietf-babel-yang-model-04 Thread-Index: AQHVwe4golIkjFFv90qm56f1AaCpn6fY3L6AgAC7pYCAAC8pgIAD8IEA Date: Mon, 6 Jan 2020 14:39:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153729C3E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <98799C32-6591-475E-B9F3-B6E31D828154@gmail.com> In-Reply-To: <98799C32-6591-475E-B9F3-B6E31D828154@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.105.209] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61153729C3EGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-06_04:2020-01-06,2020-01-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 clxscore=1011 adultscore=0 phishscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001060134 Archived-At: Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 14:39:57 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61153729C3EGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mahesh, In looking over this change, I'm trying to understand how indicating suppor= ted metric computation algorithms (expressed through feature + identity sta= tements, but no leaf-list) differs from indicating supported security mecha= nisms, MAC algorithms, and certificate types (expressed through identity st= atements + leaf-list). Why would we not use the same approach for all 4 of these? Barbara From: babel On Behalf Of Mahesh Jethanandani Sent: Friday, January 03, 2020 4:22 PM To: Donald Eastlake Cc: Babel at IETF Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 Hi Donald, In trying to make the changes you requested, I came across another change t= hat needs to be pushed. The information model suggests that babel-information-obj should maintain a= list of metric-comp-algorithm that are supported by an implementation. The= problem with just keeping a list in YANG is that there is no way to enforc= e that the implementation uses only those algorithms. To address the issue = we had introduced the concept of features in -04 version of the draft. Using the feature statement, the implementation can declare which of the me= tric-comp-algorithms it supports, which was the intention of having a list = of those algorithms in the first place. As such, we do not need the global = list anymore, and needs to be removed. I will be adding that change in the = -05 version of the draft. If you feel that it requires a short LC to be issued, please feel free to d= o so after I post the draft. Thanks. On Jan 3, 2020, at 10:32 AM, Donald Eastlake > wrote: Hi Mahesh, You're welcome. My apologies for not noticing it earlier. Can you go ahead = and post a revision with this trivial change? Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani > wrote: Hi Donald, Yes, that should be ok. And thanks for catching it. Cheers. Mahesh Jethanandani mjethanandani@gmail.com On Jan 2, 2020, at 8:27 PM, Donald Eastlake > wrote: Hi Mahesh, Happy New Year! There seems to be a minor format problem in this draft, in particular four = lines, all identical, that are 76 characters long. Lines over 72 characters= are not allowed in Internet Drafts. On page 34, page 35, page 36, and page 38 the following line occurs: xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:ba= bel Is it possible to fold this into something like xmlns:babel=3D "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel or just reduce the indent of those lines? Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --_000_2D09D61DDFA73D4C884805CC7865E61153729C3EGAALPA1MSGUSRBF_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

In looking over this change, I’m trying to und= erstand how indicating supported metric computation algorithms (expressed t= hrough feature + identity statements, but no leaf-list) differs from in= dicating supported security mechanisms, MAC algorithms, and certificate types (expressed through identity statements &= #43; leaf-list).

 

Why would we not use the same approach for all 4 of = these?

Barbara

 

From: babel <babel-bounces@ietf.org> On Behalf Of Mahesh Jethanandani
Sent: Friday, January 03, 2020 4:22 PM
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: Babel at IETF <babel@ietf.org>
Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-m= odel-04

 

Hi Donald,

 

In trying to make the changes you requested, I came = across another change that needs to be pushed.

 

The information model suggests that babel-informatio= n-obj should maintain a list of metric-comp-algorithm that are supported by= an implementation. The problem with just keeping a list in YANG is that th= ere is no way to enforce that the implementation uses only those algorithms. To address the issue we had int= roduced the concept of features in -04 version of the draft.

 

Using the feature statement, the implementation can = declare which of the metric-comp-algorithms it supports, which was the = ;intention of having a list of those algorithms in the first place. As such= , we do not need the global list anymore, and needs to be removed. I will be adding that change in the -05 version o= f the draft.

 

If you feel that it requires a short LC to be issued= , please feel free to do so after I post the draft.

 

Thanks.



On Jan 3, 2020, at 10:32 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:=

 

Hi Mahesh,

 

You're welcome. My apologies for not noticing it ear= lier. Can you go ahead and post a revision with this trivial change?


Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.co= m

 

 

On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani &= lt;mjethanandani@gmail.com&g= t; wrote:

Hi Donald,

 

Yes, that should be ok. And thanks for catching it.<= o:p>

 

Cheers.

Mahesh Jethanandani


On Jan 2, 2020, at 8:27 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:

Hi Mahesh,

Happy New Year!

There seems to be a minor format problem in this draft, in particular four = lines, all identical, that are 76 characters long. Lines over 72 characters= are not allowed in Internet Drafts.

On page 34, page 35, page 36, and page 38 the following line occurs:
    &nbs= p;       xmlns:babel=3D"urn:ietf:params:xml:ns:yang:iet= f-babel">babel:babel
Is it possible to fold this into something like
            xmlns:babel=3D
                "urn:ietf:para= ms:xml:ns:yang:ietf-babel">babel:babel
or just reduce the indent of those lines?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.co= m

 

Mahesh Jethanandani

 

 

 

--_000_2D09D61DDFA73D4C884805CC7865E61153729C3EGAALPA1MSGUSRBF_-- From nobody Mon Jan 6 07:53:05 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7159120864; Mon, 6 Jan 2020 07:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jbYRnO0oM3H; Mon, 6 Jan 2020 07:53:00 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9188E120861; Mon, 6 Jan 2020 07:53:00 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 006FkHlL033480; Mon, 6 Jan 2020 10:52:59 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2xb9477n8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 06 Jan 2020 10:52:59 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 006Fqvgr016143; Mon, 6 Jan 2020 10:52:58 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 006FqolT015997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Jan 2020 10:52:50 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 7B2FF401466C; Mon, 6 Jan 2020 15:52:50 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30483.vci.att.com (Service) with ESMTPS id 604174014669; Mon, 6 Jan 2020 15:52:50 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0468.000; Mon, 6 Jan 2020 10:52:50 -0500 From: "STARK, BARBARA H" To: "'Mirja Kuehlewind'" , "'Juliusz Chroboczek'" CC: "'draft-ietf-babel-rfc6126bis@ietf.org'" , "'Babel at IETF'" , "'Alvaro Retana'" , "'The IESG'" , "'Martin Vigoureux'" Thread-Topic: =?utf-8?B?W2JhYmVsXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1iYWJlbC1yZmM2MTI2YmlzLTEyOiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHVTt06AK6dfyPlI0OMGh0boC4LDab7CkOAgAAcDoCADGkOgIBZvQyAgEsuF4CACGjKPYABOL2AgAmMUoCAAAhngIAAHtAAgB8cSgD//75AEA== Date: Mon, 6 Jan 2020 15:52:49 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> In-Reply-To: <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.105.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-06_04:2020-01-06,2020-01-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=977 clxscore=1011 adultscore=0 phishscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001060142 Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 15:53:03 -0000 PiBGcm9tOiBNaXJqYSBLdWVobGV3aW5kDQo+IA0KPiBIaSBKdWxpdXN6LA0KPiANCj4gSSBkaWRu 4oCZdCB0YWxrIGFib3V0IHBhY2luZyBpbiB0aGF0IG1haWwgYnV0IG9ubHkgYWJvdXQgZGVmaW5p bmcgZGVmYXVsdCB2YWx1ZXMNCj4gZm9yIHRoZSBpbnRlcnZhbCBwYXJhbWV0ZXJzIHlvdSBhbHJl YWR5IGhhdmUgZGVmaW5lZCBpbiB0aGUgZHJhZnQuDQo+IA0KPiBJZiBhbGwgZGVwbG95ZWQgc2Nl bmFyaW9zIHVzZSB0aGUgZmlyc3Qgc2V0IG9mIHZhbHVlcyBhbmQgdGhlc2UgdmFsdWUgYXJlIHdl bGwNCj4gYXBwbGljYWJsZSBmb3IgYWxsIGRpZmZlcmVudCBzY2VuYXJpb3MgdGhhdCBhcmUgZGVm aW5lZCBpbiB0aGUgdXNlIGNhc2UgZG9jLA0KPiBzdWNoIGFzIOKAnHNtYWxsIHVubWFuYWdlZCBu ZXR3b3JrIiBhcyB3ZWxsIGFzIGluIGEgImxhcmdlIG92ZXJsYXkgbmV0d29ya+KAnSwNCj4gd2h5 IGRvbuKAmXQgeW91IGp1c3Qgc3BlY2lmeSB0aGVzZSB2YWx1ZXMgYXMgbm9ybWF0aXZlbHkgZGVm YXVsdCB2YWx1ZSBpbiB0aGUNCj4gc3BlYz8NCj4gDQo+IE1pcmphDQoNCkhpIE1pcmphLA0KSSd2 ZSBiZWVuIHN0YXlpbmcgb3V0IG9mIHRoaXMgZGlzY3Vzc2lvbiwgYmVjYXVzZSBJIHdhc24ndCBl dmVuIGNsb3NlIHRvIHVuZGVyc3RhbmRpbmcgd2hhdCB0aGUgcmVxdWVzdGVkIGNoYW5nZSB3YXMu IEJ1dCB0aGlzIGVtYWlsIGlzIHByb3ZpZGluZyBtZSB3aXRoIG1vcmUgKGJ1dCBzdGlsbCBpbmNv bXBsZXRlKSBjbGFyaXR5Lg0KQXMgYW4gYXV0aG9yIG9mIGRyYWZ0LWlldGYtYmFiZWwtaW5mb3Jt YXRpb24tbW9kZWwsIEkgbmVlZCB0byBhc2sgbW9yZSBkZXRhaWxlZCBxdWVzdGlvbnMsIGJlY2F1 c2UgdGhpcyByZXF1ZXN0ZWQgY2hhbmdlIGNhbiBpbXBhY3QgdGhhdCBkcmFmdCAoYW5kIHRoZSBh c3NvY2lhdGVkIFlBTkcgZGF0YSBtb2RlbCkuIFdoZW5ldmVyIGEgcHJvdG9jb2wgc3BlYyBkZWZp bmVzIGEgInBhcmFtZXRlciIgd2l0aCBhICJkZWZhdWx0IiwgaXQncyBpbXBvcnRhbnQgZm9yIGFu IGluZm9ybWF0aW9uL2RhdGEgbW9kZWwgdG8gYWxsb3cgZm9yIGNvbmZpZ3VyYXRpb24gb2YgdGhh dCBwYXJhbWV0ZXIgKGFuZCBpbmRpY2F0ZSBhbnkgZGVmYXVsdCB2YWx1ZXMpLg0KDQpJbiB0aGUg aW5mb3JtYXRpb24gbW9kZWwsIHdlIGN1cnJlbnRseSBoYXZlIHRoZSBmb2xsb3dpbmcgZGVmaW5l ZCBpbnRlcnZhbHMgKGN1cnJlbnRseSBiZWluZyBzZW50IGJ5IHRoZSBpbXBsZW1lbnRhdGlvbik6 IA0KIC0gbXVsdGljYXN0IEhlbGxvIGludGVydmFsIChkZWZpbmVkIHBlciBpbnRlcmZhY2UpDQog LSB1cGRhdGUgaW50ZXJ2YWwgKGRlZmluZWQgcGVyIGludGVyZmFjZSwgdXNlZCBmb3IgbXVsdGlj YXN0IGFuZCB1bmljYXN0KQ0KIC0gdW5pY2FzdCBIZWxsbyBpbnRlcnZhbCAoZGVmaW5lZCBwZXIg bmVpZ2hib3IpDQoNCkFyZSB5b3UgcmVmZXJyaW5nIHRvIGFueSBvciBhbGwgb2YgdGhlc2UgaW50 ZXJ2YWxzPyBBcmUgdGhlcmUgb3RoZXIgaW50ZXJ2YWxzIHlvdSdyZSBjb25jZXJuZWQgYWJvdXQ/ IEZvciBleGFtcGxlLCBhcmUgeW91IHJlZmVycmluZyB0byBpbXBsZW1lbnRhdGlvbi1zcGVjaWZp YyB2YWx1ZXMgdXNlZCB0byBkZXJpdmUgdGhlc2UgaW50ZXJ2YWxzPyANClRoZXNlIGFyZSB0aGUg aW50ZXJ2YWxzIHRoZSBXRyBjb25zaWRlcmVkIG1vc3QgaW1wb3J0YW50IGZvciBkZXBsb3llcnMg dG8gaGF2ZSBwb3RlbnRpYWwga25vd2xlZGdlIG9mLiBIb3dldmVyLCB0aGUgV0cgYWxzbyBkZXRl cm1pbmVkIHRoYXQgYWxsb3dpbmcgZm9yIGNvbmZpZ3VyYXRpb24gb2YgdGhlc2UgaW50ZXJ2YWxz IHdhc24ndCBuZWVkZWQgYW5kIHdhc24ndCBldmVuIGEgZ29vZCBpZGVhLiBTbyB0aGV5J3JlIHJl YWQtb25seS4gSW1wbGVtZW50YXRpb25zIGFyZSBleHBlY3RlZCB0byBhbGdvcml0aG1pY2FsbHkg ZGV0ZXJtaW5lIGFwcHJvcHJpYXRlIHZhbHVlcyBmb3IgdGhlc2UgaW50ZXJ2YWxzLiANCg0KVGhl IHJmYzYxMjZiaXMgZHJhZnQgZXhwb3VuZHMgb24gc29tZSBvZiB0aGUgcmVhc29uaW5nIGZvciB0 aGlzIHdpdGggc3RhdGVtZW50cyBsaWtlIA0KIiBGb3IgZXhhbXBsZSwgYSBtb2JpbGUgbm9kZQ0K ICAgdGhhdCBpcyBsb3cgb24gYmF0dGVyeSBtYXkgY2hvb3NlIHRvIHVzZSBsYXJnZXIgdGltZSBj b25zdGFudHMgKGhlbGxvDQogICBhbmQgdXBkYXRlIGludGVydmFscywgZXRjLikgdGhhbiBhIG5v ZGUgdGhhdCBoYXMgYWNjZXNzIHRvIHdhbGwNCiAgIHBvd2VyLiAgQ29udmVyc2VseSwgYSBub2Rl IHRoYXQgZGV0ZWN0cyBoaWdoIGxldmVscyBvZiBtb2JpbGl0eSBtYXkNCiAgIGNob29zZSB0byB1 c2Ugc21hbGxlciB0aW1lIGNvbnN0YW50cy4gIFRoZSBhYmlsaXR5IHRvIGJ1aWxkIHN1Y2gNCiAg IGhldGVyb2dlbmVvdXMgbmV0d29ya3MgbWFrZXMgQmFiZWwgcGFydGljdWxhcmx5IGFkYXB0ZWQg dG8gdGhlDQogICB1bm1hbmFnZWQgYW5kIHdpcmVsZXNzIGVudmlyb25tZW50LiINCg0KVGhpcyBz dWdnZXN0cyBhbiBpbXBsZW1lbnRhdGlvbiBtYXkgaGF2ZSBkaWZmZXJlbnQgZGVmYXVsdHMgYnVp bHQgaW4gb3IgYWxnb3JpdGhtaWNhbGx5IGNhbGN1bGF0ZWQsIGJhc2VkIG5vdCBvbmx5IG9uIGxp bmsgY2hhcmFjdGVyaXN0aWNzLCBidXQgYWxzbyBwb3dlciBzdXBwbHkgKGFuZCBwb3RlbnRpYWxs eSBvdGhlciBmYWN0b3JzKS4gSWRlbnRpZnlpbmcgYSBzaW5nbGUgbWFuZGF0b3J5IGRlZmF1bHQg d291bGQgbWFrZSBpdCBkaWZmaWN1bHQgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRvIGhhbmRsZSBz cGVjaWZpYyBlbnZpcm9ubWVudGFsIGZhY3RvcnMuIElkZW50aWZ5aW5nIG11bHRpcGxlIG1hbmRh dG9yeSBkZWZhdWx0cyBiYXNlZCBvbiBwZXJtdXRhdGlvbnMgb2YgZW52aXJvbm1lbnRhbCBmYWN0 b3JzIHdvdWxkIGJlIHZlcnkgY29tcGxleCwgYW5kIG1pZ2h0IG9taXQgc29tZSBpbXBvcnRhbnQg ZW52aXJvbm1lbnRhbCBmYWN0b3JzIChvciBwZXJtdXRhdGlvbnMgb2YgZmFjdG9ycykgdGhhdCBh biBpbXBsZW1lbnRvciBkZWNpZGVzIHRvIGJ1aWxkIGludG8gYSBwYXJ0aWN1bGFyIGltcGxlbWVu dGF0aW9uLiANCg0KSU1PLCB0aGUgV0cgbWFkZSB0aGUgcmlnaHQgZGVjaXNpb24gbm90IHRvIGFs bG93IGNvbmZpZ3VyYXRpb24gb2YgdGhlc2UgaW50ZXJ2YWxzIChvciB0cnkgdG8gaWRlbnRpZnkg cGFyYW1ldGVycyB0byBpbmZsdWVuY2UgY2FsY3VsYXRpb24gb2YgdGhlc2UgaW50ZXJ2YWwgdmFs dWVzKS4gU28gSSBoYXZlIHRvIGFncmVlIHdpdGggSnVsaXVzeiB0aGF0IChpZiB0aGVzZSBhcmUg dGhlIGludGVydmFscyB5b3UncmUgdGFsa2luZyBhYm91dCkgdGhlIHNwZWMgc2hvdWxkbid0IGlk ZW50aWZ5IGFueSBkZWZhdWx0IHZhbHVlcyBmb3IgdGhlbS4NCg0KSWYgSSdtIG1pc3VuZGVyc3Rh bmRpbmcgdGhlIHJlcXVlc3QsIHBsZWFzZSBsZXQgbWUga25vdzsgYmVjYXVzZSBJIHN0aWxsIHRo aW5rIGl0IHdpbGwgaW1wYWN0IHRoZSBpbmZvL2RhdGEgbW9kZWxzLg0KVGh4LA0KQmFyYmFyYQ0K DQo+IA0KPiANCj4gDQo+ID4gT24gMTcuIERlYyAyMDE5LCBhdCAyMDowNCwgSnVsaXVzeiBDaHJv Ym9jemVrIDxqY2hAaXJpZi5mcj4gd3JvdGU6DQo+ID4NCj4gPj4+IElmIHRoYXQgaXMgdGhlIGNh c2UsIHRoZW4gSSByZXF1ZXN0IHRoYXQgeW91IHN0YXRlIGV4cGxpY2l0bHkgd2h5DQo+ID4+PiB5 b3UgdGhpbmsgdGhhdCBCYWJlbCBtdXN0IGJlIGhlbGQgdG8gYSBtdWNoIGhpZ2hlciBzdGFuZGFy ZCB0aGFuDQo+ID4+PiBPU1BGdjMuICBJZiB0aGF0IGlzIG5vdCB0aGUgY2FzZSwgdGhlbiBwbGVh c2UgY2xlYXIgeW91ciBkaXNjdXNzLg0KPiA+DQo+ID4+IEluIE9TUEZ2MyBhcyBmYXIgYXMgSSBj YW4gc2VlIChhbmQgSSBhbSByZWFsbHkgbm90IGFuIGV4cGVydCBoZXJlKQ0KPiA+PiBhbGwgdmFs dWVzIHRoYXQgZGVmaW5lIGludGVydmFscyBhcmUgaW4gc2Vjb25kcyB3aGljaCBsZWFkcyB0byBh DQo+ID4+IG1pbmltdW0gdmFsdWUgb2YgMSBzZWNvbmRzLiBUaGlzIGlzIG5vdCB0aGUgY2FzZSBm b3IgYmFiZWwgYW5kDQo+ID4+IHRoZXJlZm9yZSB3ZSBuZWVkIHRvIGJlIG1vcmUgY2FyZnVsIGhl cmUuDQo+ID4NCj4gPiBBZnRlciBhIGNoYW5nZSBvZiB0b3BvbG9neSwgT1NQRiBleGVjdXRlcyB0 aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbg0KPiA+IFNlY3Rpb24gNC41LjIgb2YgUkZDIDUzNDAg KFNlY3Rpb24gMTMuMyBvZiBSRkMgMjMyOCkuICBBdCB0aGlzIHBvaW50LA0KPiA+IGEgcG90ZW50 aWFsbHkgdW5ib3VuZGVkIG51bWJlciBvZiBMU0FzIGFyZSBmbG9vZGVkIG91dCBldmVyeSBhY3Rp dmUNCj4gPiBpbnRlcmZhY2UgKHBvaW50IDUgaW4gU2VjdGlvbiAxMy4zIG9mIFJGQyAyMzI4KS4g IFRoaXMgZmxvb2RpbmcgaXMgbm90DQo+ID4gcmVndWxhdGVkIGJ5IGFueSB0aW1lciAtLSBhbGwg dGhhdCB0aGUgcHJvdG9jb2wgc2F5cyBpcyB0aGF0IHRoZSBMU0FzDQo+ID4gbXVzdCBnbyBvdXQg dGhyb3VnaCBhIGNlcnRhaW4gc3Vic2V0IG9mIHRoZSByb3V0ZXIncyBpbnRlcmZhY2VzLg0KPiA+ DQo+ID4gSSBjb3VsZCBiZSB3cm9uZywgYnV0IEkgYW0gZmFpcmx5IGNvbmZpZGVudCB0aGF0IG5v dGhpbmcgaW4gUkZDcyA1MzQwDQo+ID4gYW5kDQo+ID4gMjMyOCBzcGVjaWZpZXMgY29uZ2VzdGlv biBjb250cm9sLCBmbG93IGNvbnRyb2wgb3IgcGFja2V0IHBhY2luZyBmb3INCj4gPiB0aGlzIGZs b29kaW5nIHByb2NlZHVyZS4gIE15IGludGVycHJldGF0aW9uIGlzIHRoYXQgc2luY2UgT1NQRiBp cw0KPiA+IGRlc2lnbmVkIHRvIGJlIGRlcGxveWVkIG9uIGxvY2FsIGxpbmtzLCBjb25nZXN0aW9u IGNhdXNlZCBieSBPU1BGIGlzDQo+ID4gbm90IGxpa2VseSB0byBlbmRhbmdlciB0aGUgR2xvYmFs IEludGVybmV0LCBhbmQgdGhlcmVmb3JlIHBhY2tldA0KPiA+IHBhY2luZyAoaWYgcmVxdWlyZWQp IGlzIGxlZnQgdG8gdGhlIGltcGxlbWVudGF0aW9uLg0KPiA+DQo+ID4gSSBhbHNvIGRvbid0IHJl Y2FsbCBhbnkgZGlzY3Vzc2lvbiBvZiBmbG93IGNvbnRyb2wgaW4gTW95J3MgYW5kDQo+ID4gR3Jl ZGxlcidzIGJvb2tzLCBidXQgdGhleSBoYXZlIGEgbG90IG9mIHBhZ2VzIChlc3BlY2lhbGx5IEdy ZWRsZXIncyksDQo+ID4gc28sIGFnYWluLCBJIGNvdWxkIGJlIHdyb25nLg0KPiA+DQo+ID4gV2hl cmUgeW91IGFyZSByaWdodCwgTWlyamEsIGlzIHRoYXQgcGFja2V0IHBhY2luZyBpcyBhIHZlcnkg ZGlmZmljdWx0DQo+ID4gcHJvYmxlbSBpbiBPU1BGLCB3aGVyZSBpbmNvcnJlY3RseSBkZWxheWlu ZyBmbG9vZGluZyBjb3VsZCBsZWFkIHRvDQo+ID4gbWljcm9sb29wczsgc2luY2UgQmFiZWwgaGFz IGEgbG9vcC1hdm9pZGFuY2UgbWVjaGFuaXNtIGJ1aWx0LWluLCBpdA0KPiA+IGNhbiBzYWZlbHkg cGVyZm9ybSBwYWNrZXQgcGFjaW5nIHNob3VsZCB0aGUgbmVlZCB0byBkbyBzbyBiZQ0KPiA+IGRl bW9uc3RyYXRlZCBpbiBhIHBhcnRpY3VsYXIgdG9wb2xvZ3kuDQo+ID4NCj4gPiBJbiBzdW1tYXJ5 LCB3aGlsZSBJIGFncmVlIHRoYXQgcGFja2V0IHBhY2luZyBmb3IgQmFiZWwgd291bGQgYmUgYW4N Cj4gPiBpbnRlcmVzdGluZyByZXNlYXJjaCBwcm9qZWN0LCBJIG1haW50YWluIHRoYXQgYnkgcmVx dWlyaW5nIHBhY2tldA0KPiA+IHBhY2luZyBhcyBhIGNvbmRpdGlvbiBmb3IgcHVibGljYXRpb24g YXMgUFMsIHlvdSBhcmUgcmVxdWlyaW5nIGFuDQo+ID4gdW5yZWFzb25hYmx5IGhpZ2ggc3RhbmRh cmQsIGNlcnRhaW5seSBhIHN0YW5kYXJkIHRoYXQgbmVpdGhlciBPU1BGIG5vciBJUy0NCj4gSVMg YXJlIGhlbGQgdG8uDQo+ID4NCj4gPj4+IEFwcGVuZGl4IEIgZ2l2ZXMgdmFsdWVzIHRoYXQgYXJl IHN1Z2dlc3RlZCBmb3IgaW1wbGVtZW50YXRpb25zLg0KPiA+DQo+ID4+IFllcyBidXQgaXQgZG9l c27igJl0IGRpc2N1c3MgZm9yIHdpdGggX2RlcGxveW1lbnRfIHNjZW5hcmlvcyB0aGVzZQ0KPiA+ PiB2YWx1ZXMgYXJlIHN1aXRhYmxlLg0KPiA+DQo+ID4gQXMgZmFyIGFzIEkgYW0gYXdhcmUsIGFs bCBjdXJyZW50IHByb2R1Y3Rpb24gZGVwbG95bWVudHMgdXNlIHRoZSBmaXJzdA0KPiA+IHNldCBv ZiBjb25zdGFudHMuICBUaGUgb25lIGV4Y2VwdGlvbiBpcyBhbiBleHBlcmltZW50YWwgdGVzdGJl ZCB1c2VkDQo+ID4gZm9yIG1vYmlsaXR5IHJlc2VhcmNoLCB0aGF0IHVzZXMgdGhlIChtb3JlIGFn Z3Jlc3NpdmUpIHNlY29uZCBzZXQgb2YNCj4gY29uc3RhbnRzLg0KPiA+DQo+ID4+IERpZCB5b3Ug ZGVwbG95IHRoZSBzYW1lIHBhcmFtZXRlcnMgaW4gYWxsIG9mIHRoZSBkaXNjdXNzZWQgc2NlbmFy aW9zLg0KPiA+DQo+ID4gWWVzLg0KPiA+DQo+ID4+IERvZXMgaXQgYWN0dWFsbHkgbWFrZXMgc2Vu c2UgdG8gdXNlIHRoZSBzYW1lIHBhcmFtZXRlcnMgaW4gYSAic21hbGwNCj4gPj4gdW5tYW5hZ2Vk IG5ldHdvcmsiIGFzIHdlbGwgYXMgaW4gYSAibGFyZ2Ugb3ZlcmxheSBuZXR3b3JrIj8NCj4gPg0K PiA+IFllcy4NCj4gPg0KPiA+PiBJcyB0aGF0IG5ldHdvcmsgY29ubmVjdGVkIHRvIHRoZSBJbnRl cm5ldCBvciBub3Q/DQo+ID4NCj4gPiBZZXMsIGJ1dCB0aGF0J3MgaXJyZWxldmFudCAtLSB0aGUg QmFiZWwgdHJhZmZpYyBpcyBsaW5rLWxvY2FsLCBhbmQNCj4gPiBkb2VzIG5vdCBnbyBvdXRzaWRl IHRoZSBsb2NhbCByb3V0aW5nIGRvbWFpbi4NCj4gPg0KPiA+IC0tIEp1bGl1c3oNCj4gPg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gYmFi ZWwgbWFpbGluZyBsaXN0DQo+IGJhYmVsQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2JhYmVsJmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1M b0d6aEMtOHNjOFNZOFRxNHZyZm9nJm09bEFGdnNVMF9PUER5LQ0KPiBabEhJdjV1QlBkazR2ZkFO SURyQTk1MkFqa0ExMDgmcz1RdXJGdlc2eDUtDQo+IGNkNkpOWjY1Y3BjaFl1WHpLYjJiZlBmTVhP ZkllQ1Q1ZyZlPQ0K From nobody Mon Jan 6 09:02:59 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8D912083E; Mon, 6 Jan 2020 09:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ6Z9sfSZqdI; Mon, 6 Jan 2020 09:02:51 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 C96BD1208F4; Mon, 6 Jan 2020 09:02:50 -0800 (PST) Received: from 200116b8243550004499ccf78e5880e6.dip.versatel-1u1.de ([2001:16b8:2435:5000:4499:ccf7:8e58:80e6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ioVm8-0000lY-Ux; Mon, 06 Jan 2020 18:02:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Mon, 6 Jan 2020 18:02:44 +0100 Cc: Juliusz Chroboczek , "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux Content-Transfer-Encoding: quoted-printable Message-Id: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578330170;df5bc54c; X-HE-SMSGID: 1ioVm8-0000lY-Ux Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:02:54 -0000 Hi Barbara, To me the question of configuration is actually orthogonal.=20 I think this sentence you write is the core of the misunderstanding we = might have: > Identifying a single mandatory default would make it difficult for an=20= > implementation to handle specific environmental factors. The whole point of the word =E2=80=9Cdefault=E2=80=9D here is that of = course you can use another value (because otherwise it would not be a = parameter but a constant). What I=E2=80=99m talking about is the point = of time when the code is written and I as an implementator have to = decide which value to set (for my implementation). Having a normatively = defined default value doesn=E2=80=99t mean that all implementation have = to use this value, but if I write the code at a point of time where I = might not be aware of specific requirements, the default values should = give me some reasonable idea about something that will work =E2=80=9Cwell=E2= =80=9D in =E2=80=9Cmost=E2=80=9D scenarios (which it seems to be case = that this set actually exists for babel as people tell me that all = deployed implementation currently use the same value). I=E2=80=99d say = it=E2=80=99s common practice these kind of default values are specified = normatively (with MUSTs or SHOULDs) as part of the protocol spec as it = gives simply implementor (that don=E2=80=99t know any better) a high = incentive to use these values (more than some examples values in the = appendix). I guess for a default value it=E2=80=99s doesn=E2=80=99t make a real = difference to have a MUST or SHOULD because it=E2=80=99s only the = default which always implies that you may use another value if you know = better. However, thinking about configuration, I think a MUST default = value probably makes more sense when then value is configurable because = then there is another way to change it and a MUST might avoid surprises = if used unchanged. If the value is not configurable maybe SHOULD makes = more sense=E2=80=A6 again in practice there is no difference; none of = these mean that another value cannot be used but only provide guidance = about a safe default. Further you could also specify normative min and max values to give an = implementor or a user (that can configure these values) a better idea = about which range of values are safe to deploy. The values would be MUST = requirements if there is a known boundary that will cause the protocol = to not work anymore (as expected) or could also be SHOULDs just to give = a better idea of common or reasonable values (maybe together with a = discussion about bad thinks that can happen if a larger or smaller value = is chosen).=20 Mirja > On 6. Jan 2020, at 16:52, STARK, BARBARA H wrote: >=20 >> From: Mirja Kuehlewind >>=20 >> Hi Juliusz, >>=20 >> I didn=E2=80=99t talk about pacing in that mail but only about = defining default values >> for the interval parameters you already have defined in the draft. >>=20 >> If all deployed scenarios use the first set of values and these value = are well >> applicable for all different scenarios that are defined in the use = case doc, >> such as =E2=80=9Csmall unmanaged network" as well as in a "large = overlay network=E2=80=9D, >> why don=E2=80=99t you just specify these values as normatively = default value in the >> spec? >>=20 >> Mirja >=20 > Hi Mirja, > I've been staying out of this discussion, because I wasn't even close = to understanding what the requested change was. But this email is = providing me with more (but still incomplete) clarity. > As an author of draft-ietf-babel-information-model, I need to ask more = detailed questions, because this requested change can impact that draft = (and the associated YANG data model). Whenever a protocol spec defines a = "parameter" with a "default", it's important for an information/data = model to allow for configuration of that parameter (and indicate any = default values). >=20 > In the information model, we currently have the following defined = intervals (currently being sent by the implementation):=20 > - multicast Hello interval (defined per interface) > - update interval (defined per interface, used for multicast and = unicast) > - unicast Hello interval (defined per neighbor) >=20 > Are you referring to any or all of these intervals? Are there other = intervals you're concerned about? For example, are you referring to = implementation-specific values used to derive these intervals?=20 > These are the intervals the WG considered most important for deployers = to have potential knowledge of. However, the WG also determined that = allowing for configuration of these intervals wasn't needed and wasn't = even a good idea. So they're read-only. Implementations are expected to = algorithmically determine appropriate values for these intervals.=20 >=20 > The rfc6126bis draft expounds on some of the reasoning for this with = statements like=20 > " For example, a mobile node > that is low on battery may choose to use larger time constants = (hello > and update intervals, etc.) than a node that has access to wall > power. Conversely, a node that detects high levels of mobility may > choose to use smaller time constants. The ability to build such > heterogeneous networks makes Babel particularly adapted to the > unmanaged and wireless environment." >=20 > This suggests an implementation may have different defaults built in = or algorithmically calculated, based not only on link characteristics, = but also power supply (and potentially other factors). Identifying a = single mandatory default would make it difficult for an implementation = to handle specific environmental factors. Identifying multiple mandatory = defaults based on permutations of environmental factors would be very = complex, and might omit some important environmental factors (or = permutations of factors) that an implementor decides to build into a = particular implementation.=20 >=20 > IMO, the WG made the right decision not to allow configuration of = these intervals (or try to identify parameters to influence calculation = of these interval values). So I have to agree with Juliusz that (if = these are the intervals you're talking about) the spec shouldn't = identify any default values for them. >=20 > If I'm misunderstanding the request, please let me know; because I = still think it will impact the info/data models. > Thx, > Barbara >=20 >>=20 >>=20 >>=20 >>> On 17. Dec 2019, at 20:04, Juliusz Chroboczek wrote: >>>=20 >>>>> If that is the case, then I request that you state explicitly why >>>>> you think that Babel must be held to a much higher standard than >>>>> OSPFv3. If that is not the case, then please clear your discuss. >>>=20 >>>> In OSPFv3 as far as I can see (and I am really not an expert here) >>>> all values that define intervals are in seconds which leads to a >>>> minimum value of 1 seconds. This is not the case for babel and >>>> therefore we need to be more carful here. >>>=20 >>> After a change of topology, OSPF executes the procedure described in >>> Section 4.5.2 of RFC 5340 (Section 13.3 of RFC 2328). At this = point, >>> a potentially unbounded number of LSAs are flooded out every active >>> interface (point 5 in Section 13.3 of RFC 2328). This flooding is = not >>> regulated by any timer -- all that the protocol says is that the = LSAs >>> must go out through a certain subset of the router's interfaces. >>>=20 >>> I could be wrong, but I am fairly confident that nothing in RFCs = 5340 >>> and >>> 2328 specifies congestion control, flow control or packet pacing for >>> this flooding procedure. My interpretation is that since OSPF is >>> designed to be deployed on local links, congestion caused by OSPF is >>> not likely to endanger the Global Internet, and therefore packet >>> pacing (if required) is left to the implementation. >>>=20 >>> I also don't recall any discussion of flow control in Moy's and >>> Gredler's books, but they have a lot of pages (especially = Gredler's), >>> so, again, I could be wrong. >>>=20 >>> Where you are right, Mirja, is that packet pacing is a very = difficult >>> problem in OSPF, where incorrectly delaying flooding could lead to >>> microloops; since Babel has a loop-avoidance mechanism built-in, it >>> can safely perform packet pacing should the need to do so be >>> demonstrated in a particular topology. >>>=20 >>> In summary, while I agree that packet pacing for Babel would be an >>> interesting research project, I maintain that by requiring packet >>> pacing as a condition for publication as PS, you are requiring an >>> unreasonably high standard, certainly a standard that neither OSPF = nor IS- >> IS are held to. >>>=20 >>>>> Appendix B gives values that are suggested for implementations. >>>=20 >>>> Yes but it doesn=E2=80=99t discuss for with _deployment_ scenarios = these >>>> values are suitable. >>>=20 >>> As far as I am aware, all current production deployments use the = first >>> set of constants. The one exception is an experimental testbed used >>> for mobility research, that uses the (more aggressive) second set of >> constants. >>>=20 >>>> Did you deploy the same parameters in all of the discussed = scenarios. >>>=20 >>> Yes. >>>=20 >>>> Does it actually makes sense to use the same parameters in a "small >>>> unmanaged network" as well as in a "large overlay network"? >>>=20 >>> Yes. >>>=20 >>>> Is that network connected to the Internet or not? >>>=20 >>> Yes, but that's irrelevant -- the Babel traffic is link-local, and >>> does not go outside the local routing domain. >>>=20 >>> -- Juliusz >>>=20 >>=20 >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwIGaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DlAFvsU0_OPDy- >> ZlHIv5uBPdk4vfANIDrA952AjkA108&s=3DQurFvW6x5- >> cd6JNZ65cpchYuXzKb2bfPfMXOfIeCT5g&e=3D From nobody Mon Jan 6 11:07:16 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64E1200EB for ; Mon, 6 Jan 2020 11:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZLk8mykL_Jy for ; Mon, 6 Jan 2020 11:07:13 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 2F23B1200B3 for ; Mon, 6 Jan 2020 11:07:13 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id b9so27271128pgk.12 for ; Mon, 06 Jan 2020 11:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BngM3faf2c4H5Os+5rcH9IEVY472X1UaUIbQn+LPFUA=; b=FkXWhbokEwydB46ZXgKdL6KZ1+1uEkqP17Klylc6qnDH0y3/MvV38lEhdbOLuzhVHL NWv+7fJrMbK74ahNcL8ZJ2IUmAwMEky/gugUhZ38cKJxYrkqYHSOX1FXMhoZtFizkrLp kC7cJpyZZzHGworRr6yncM3h9qlkQQKF/AMnOtNVtvOhzhYqnTR/SgpyTXQy4Z0y0abL ApefmsVJh4q8QqWyPWqMbYLyjAN85TYjfAWtO6+QiuKEK+W6JkS40XkJ/Qkmxl6bIYhR dTQF/C+p5cRBVbazEeCnLabQc3ANud3SdLA3onog6jGkQSve/fBzKXu6aRK7qBDsbzNi qEcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BngM3faf2c4H5Os+5rcH9IEVY472X1UaUIbQn+LPFUA=; b=snyT61kkB4mbYEuTbv0gGXkzqFNUyaGSYFQJvuo+z5ozaqhX5Q2zVMUzzTRccxKoq1 9L2iSd3B29mC17m6x2wbb1ubjh8gQHPeqkctNp3mbEqF052JaTWnw6z51ZKjHmHlYPjH bpCwtivJ4zAanzSKKyH9uCUN1uMqbJJjNytgZHZfjCMoS3Fq6rcT6+x2JLajtV/XReAL oBr9XezjnlSYJk5wjoEKxWIL9r02u6sjdZQlVuy/MlQ/yBDYpHN0I2Pyvo/TCWAVMk68 TQB9ZoZu3UiigyzhIboCJcDTyEd2HtXkEMGifUkAVMfkrXB63KbqUvh2r9LpJ+RyPv5a gs+g== X-Gm-Message-State: APjAAAWGImWrqYFacpHbDxrN99cyYzny70EuUzhN510j/ChP+ccyfQBw R9hJILvXhTGw79BeMc2s9nw= X-Google-Smtp-Source: APXvYqx+sXuv9ZO1shwhQ1DgNPjGhtrGfEZLsvbwOAe00M48/1sG11lwQHbCL0/nzepeLBiw0TNxrQ== X-Received: by 2002:a63:b642:: with SMTP id v2mr110277310pgt.126.1578337632532; Mon, 06 Jan 2020 11:07:12 -0800 (PST) Received: from [10.33.123.65] ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id a9sm51282235pfn.38.2020.01.06.11.07.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jan 2020 11:07:12 -0800 (PST) From: Mahesh Jethanandani Message-Id: <1149EE36-765D-449B-BF23-A68DFB55E3B2@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3BA2C757-E924-47AE-B4EF-20926A113488" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 6 Jan 2020 11:07:11 -0800 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153729C3E@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Donald Eastlake , Babel at IETF To: "STARK, BARBARA H" References: <98799C32-6591-475E-B9F3-B6E31D828154@gmail.com> <2D09D61DDFA73D4C884805CC7865E61153729C3E@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 19:07:15 -0000 --Apple-Mail=_3BA2C757-E924-47AE-B4EF-20926A113488 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Barbara, You bring up a good point. Have added feature statements for security, MAC and certificate types, = and made the identity statements conditional on the features being = declared. Also beefed up the example to show how the system could be = configured for HMAC-SHA256 MAC algorithm. Thanks. > On Jan 6, 2020, at 6:39 AM, STARK, BARBARA H wrote: >=20 > Hi Mahesh, > In looking over this change, I=E2=80=99m trying to understand how = indicating supported metric computation algorithms (expressed through = feature + identity statements, but no leaf-list) differs from indicating = supported security mechanisms, MAC algorithms, and certificate types = (expressed through identity statements + leaf-list). > =20 > Why would we not use the same approach for all 4 of these? > Barbara > =20 > From: babel On Behalf Of Mahesh Jethanandani > Sent: Friday, January 03, 2020 4:22 PM > To: Donald Eastlake > Cc: Babel at IETF > Subject: Re: [babel] Minor format problem in = draft-ietf-babel-yang-model-04 > =20 > Hi Donald, > =20 > In trying to make the changes you requested, I came across another = change that needs to be pushed. > =20 > The information model suggests that babel-information-obj should = maintain a list of metric-comp-algorithm that are supported by an = implementation. The problem with just keeping a list in YANG is that = there is no way to enforce that the implementation uses only those = algorithms. To address the issue we had introduced the concept of = features in -04 version of the draft. > =20 > Using the feature statement, the implementation can declare which of = the metric-comp-algorithms it supports, which was the intention of = having a list of those algorithms in the first place. As such, we do not = need the global list anymore, and needs to be removed. I will be adding = that change in the -05 version of the draft. > =20 > If you feel that it requires a short LC to be issued, please feel free = to do so after I post the draft. > =20 > Thanks. >=20 >=20 > On Jan 3, 2020, at 10:32 AM, Donald Eastlake > wrote: > =20 > Hi Mahesh, > =20 > You're welcome. My apologies for not noticing it earlier. Can you go = ahead and post a revision with this trivial change? >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > =20 > =20 > On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani = > wrote: > Hi Donald, > =20 > Yes, that should be ok. And thanks for catching it. > =20 > Cheers. >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 > On Jan 2, 2020, at 8:27 PM, Donald Eastlake > wrote: >=20 > Hi Mahesh, >=20 > Happy New Year! >=20 > There seems to be a minor format problem in this draft, in particular = four lines, all identical, that are 76 characters long. Lines over 72 = characters are not allowed in Internet Drafts. >=20 > On page 34, page 35, page 36, and page 38 the following line occurs: > = xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel > Is it possible to fold this into something like > xmlns:babel=3D > "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel > or just reduce the indent of those lines? >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > =20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3BA2C757-E924-47AE-B4EF-20926A113488 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Barbara,

You bring = up a good point.

Have added feature statements for security, MAC and = certificate types, and made the identity statements conditional on the = features being declared. Also beefed up the example to show how the = system could be configured for HMAC-SHA256 MAC algorithm.

Thanks.

On Jan 6, 2020, at 6:39 AM, STARK, BARBARA H <bs7652@att.com> = wrote:

Hi = Mahesh,
In looking over this change, I=E2=80=99m trying to understand = how indicating supported metric computation algorithms (expressed = through feature + identity statements, but no leaf-list) differs from = indicating supported security mechanisms, MAC algorithms, and = certificate types (expressed through identity statements + = leaf-list).
 
Why would we not use the same approach for all 4 of = these?
Barbara
 
From: babel <babel-bounces@ietf.org> On Behalf = Of Mahesh = Jethanandani
Sent: Friday, January 03, 2020 = 4:22 PM
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: Babel at IETF <babel@ietf.org>
Subject: Re: [babel] Minor format = problem in draft-ietf-babel-yang-model-04
 
Hi Donald,
 
In trying to make the changes you requested, I came across = another change that needs to be pushed.
 
The information model suggests that = babel-information-obj should maintain a list of metric-comp-algorithm = that are supported by an implementation. The problem with just keeping a = list in YANG is that there is no way to enforce that the implementation = uses only those algorithms. To address the issue we had introduced the = concept of features in -04 version of the draft.
 
Using the feature statement, the = implementation can declare which of the metric-comp-algorithms it = supports, which was the intention of having a list of those = algorithms in the first place. As such, we do not need the global list = anymore, and needs to be removed. I will be adding that change in the = -05 version of the draft.
 
If you feel that it requires a short LC to be issued, please = feel free to do so after I post the draft.
 
Thanks.


On Jan 3, 2020, at 10:32 = AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
 
Hi Mahesh,
 
You're welcome. My apologies for not = noticing it earlier. Can you go ahead and post a revision with this = trivial change?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake = 3rd   +1-508-333-2270 (cell)
 2386 Panoramic = Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
 
 
On Fri, = Jan 3, 2020 at 2:21 AM Mahesh Jethanandani <mjethanandani@gmail.com> = wrote:
Hi Donald,
 
Yes, that should be ok. And thanks for catching it.
 

Cheers.

Mahesh Jethanandani


On Jan 2, 2020, at 8:27 PM, Donald Eastlake = <d3e3e3@gmail.com> = wrote:

Hi Mahesh,

Happy New Year!

There seems to = be a minor format problem in this draft, in particular four lines, all = identical, that are 76 characters long. Lines over 72 characters are not = allowed in Internet Drafts.

On page 34, = page 35, page 36, and page 38 the following line occurs:
            = xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
Is it possible to fold this into something like
            xmlns:babel=3D
                = "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
or = just reduce the indent of those lines?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake = 3rd   +1-508-333-2270 (cell)
 2386 Panoramic = Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
<= /div>
 
Mahesh Jethanandani
=

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_3BA2C757-E924-47AE-B4EF-20926A113488-- From nobody Mon Jan 6 13:54:41 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651F12007A; Mon, 6 Jan 2020 13:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVV60eVIGOyz; Mon, 6 Jan 2020 13:54:30 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B1E120033; Mon, 6 Jan 2020 13:54:30 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 006LjHl6032420; Mon, 6 Jan 2020 16:54:29 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2xccbj9745-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 06 Jan 2020 16:54:28 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 006LsRAF032019; Mon, 6 Jan 2020 16:54:27 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 006LsMOY031912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 6 Jan 2020 16:54:22 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 20F0C4009E61; Mon, 6 Jan 2020 21:54:22 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30484.vci.att.com (Service) with ESMTPS id F3ECD40006FD; Mon, 6 Jan 2020 21:54:21 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.43]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Mon, 6 Jan 2020 16:54:21 -0500 From: "STARK, BARBARA H" To: "'Mirja Kuehlewind'" CC: "'Juliusz Chroboczek'" , "'draft-ietf-babel-rfc6126bis@ietf.org'" , "'Babel at IETF'" , "'Alvaro Retana'" , "'The IESG'" , "'Martin Vigoureux'" Thread-Topic: =?utf-8?B?W2JhYmVsXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1iYWJlbC1yZmM2MTI2YmlzLTEyOiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHVTt06AK6dfyPlI0OMGh0boC4LDab7CkOAgAAcDoCADGkOgIBZvQyAgEsuF4CACGjKPYABOL2AgAmMUoCAAAhngIAAHtAAgB8cSgD//75AEIAAcjQA///5tZA= Date: Mon, 6 Jan 2020 21:54:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6115372AF7D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.105.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-06_07:2020-01-06,2020-01-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 adultscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 bulkscore=0 mlxscore=0 clxscore=1015 spamscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001060182 Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 21:54:33 -0000 SGkgTWlyamEsDQpUaGFua3MgZm9yIHRoYXQuIE9LLCBzbyB5b3UgZG9uJ3QgbmVlZCB0aGVtIHRv IGJlIGNvbmZpZ3VyYWJsZSBvciBtYW5kYXRvcnkgKHdoaWNoIG1lYW5zIHRoZSBXRyBjb25zZW5z dXMgdGhhdCB0aGV5IG5vdCBiZSBjb25maWd1cmFibGUgaXMgYWNjZXB0YWJsZSkgYW5kIHlvdSB3 b3VsZCBiZSBzYXRpc2ZpZWQgd2l0aCAiU0hPVUxEIi4gTm9ybWF0aXZlIGxhbmd1YWdlIHRlcm1p bm9sb2d5IChSRkMgMjExOSkgYWxsb3dzIGZvciB1c2Ugb2YgIlJFQ09NTUVOREVEIiB0byBtZWFu IHRoZSBzYW1lIGFzICJTSE9VTEQiLCBhbmQgIkFwcGVuZGl4IEI6IFByb3RvY29sIHBhcmFtZXRl cnMiIGN1cnJlbnRseSBzYXlzIChpbiAyIHBsYWNlcykgIlRoZSBmb2xsb3dpbmcgdmFsdWVzIGFy ZSByZWNvbW1lbmRlZCAuLi4iIA0KSWYgdGhpcyB3ZXJlIGNoYW5nZWQgdG8gIiBUaGUgZm9sbG93 aW5nIHZhbHVlcyBhcmUgUkVDT01NRU5ERUQgLi4uIiwgd291bGQgdGhhdCBzYXRpc2Z5IHlvdXIg Y29tbWVudD8NCg0KSnVsaXVzeiwgd291bGQgdGhhdCBiZSBhY2NlcHRhYmxlIHRvIHlvdT8NCkJh cmJhcmENCg0KPiBIaSBCYXJiYXJhLA0KPiANCj4gVG8gbWUgdGhlIHF1ZXN0aW9uIG9mIGNvbmZp Z3VyYXRpb24gaXMgYWN0dWFsbHkgb3J0aG9nb25hbC4NCj4gDQo+IEkgdGhpbmsgdGhpcyBzZW50 ZW5jZSB5b3Ugd3JpdGUgaXMgdGhlIGNvcmUgb2YgdGhlIG1pc3VuZGVyc3RhbmRpbmcgd2UgbWln aHQNCj4gaGF2ZToNCj4gPiBJZGVudGlmeWluZyBhIHNpbmdsZSBtYW5kYXRvcnkgZGVmYXVsdCB3 b3VsZCBtYWtlIGl0IGRpZmZpY3VsdCBmb3IgYW4NCj4gPiBpbXBsZW1lbnRhdGlvbiB0byBoYW5k bGUgc3BlY2lmaWMgZW52aXJvbm1lbnRhbCBmYWN0b3JzLg0KPiANCj4gVGhlIHdob2xlIHBvaW50 IG9mIHRoZSB3b3JkIOKAnGRlZmF1bHTigJ0gaGVyZSBpcyB0aGF0IG9mIGNvdXJzZSB5b3UgY2Fu IHVzZQ0KPiBhbm90aGVyIHZhbHVlIChiZWNhdXNlIG90aGVyd2lzZSBpdCB3b3VsZCBub3QgYmUg YSBwYXJhbWV0ZXIgYnV0IGENCj4gY29uc3RhbnQpLiBXaGF0IEnigJltIHRhbGtpbmcgYWJvdXQg aXMgdGhlIHBvaW50IG9mIHRpbWUgd2hlbiB0aGUgY29kZSBpcw0KPiB3cml0dGVuIGFuZCBJIGFz IGFuIGltcGxlbWVudGF0b3IgaGF2ZSB0byBkZWNpZGUgd2hpY2ggdmFsdWUgdG8gc2V0IChmb3Ig bXkNCj4gaW1wbGVtZW50YXRpb24pLiBIYXZpbmcgYSBub3JtYXRpdmVseSBkZWZpbmVkIGRlZmF1 bHQgdmFsdWUgZG9lc27igJl0IG1lYW4NCj4gdGhhdCBhbGwgaW1wbGVtZW50YXRpb24gaGF2ZSB0 byB1c2UgdGhpcyB2YWx1ZSwgYnV0IGlmIEkgd3JpdGUgdGhlIGNvZGUgYXQgYQ0KPiBwb2ludCBv ZiB0aW1lIHdoZXJlIEkgbWlnaHQgbm90IGJlIGF3YXJlIG9mIHNwZWNpZmljIHJlcXVpcmVtZW50 cywgdGhlDQo+IGRlZmF1bHQgdmFsdWVzIHNob3VsZCBnaXZlIG1lIHNvbWUgcmVhc29uYWJsZSBp ZGVhIGFib3V0IHNvbWV0aGluZyB0aGF0DQo+IHdpbGwgd29yayDigJx3ZWxs4oCdIGluIOKAnG1v c3TigJ0gc2NlbmFyaW9zICh3aGljaCBpdCBzZWVtcyB0byBiZSBjYXNlIHRoYXQgdGhpcyBzZXQN Cj4gYWN0dWFsbHkgZXhpc3RzIGZvciBiYWJlbCBhcyBwZW9wbGUgdGVsbCBtZSB0aGF0IGFsbCBk ZXBsb3llZCBpbXBsZW1lbnRhdGlvbg0KPiBjdXJyZW50bHkgdXNlIHRoZSBzYW1lIHZhbHVlKS4g SeKAmWQgc2F5IGl04oCZcyBjb21tb24gcHJhY3RpY2UgdGhlc2Uga2luZCBvZg0KPiBkZWZhdWx0 IHZhbHVlcyBhcmUgc3BlY2lmaWVkIG5vcm1hdGl2ZWx5ICh3aXRoIE1VU1RzIG9yIFNIT1VMRHMp IGFzIHBhcnQgb2YNCj4gdGhlIHByb3RvY29sIHNwZWMgYXMgaXQgZ2l2ZXMgc2ltcGx5IGltcGxl bWVudG9yICh0aGF0IGRvbuKAmXQga25vdyBhbnkgYmV0dGVyKQ0KPiBhIGhpZ2ggaW5jZW50aXZl IHRvIHVzZSB0aGVzZSB2YWx1ZXMgKG1vcmUgdGhhbiBzb21lIGV4YW1wbGVzIHZhbHVlcyBpbiB0 aGUNCj4gYXBwZW5kaXgpLg0KPiANCj4gSSBndWVzcyBmb3IgYSBkZWZhdWx0IHZhbHVlIGl04oCZ cyBkb2VzbuKAmXQgbWFrZSBhIHJlYWwgZGlmZmVyZW5jZSB0byBoYXZlIGEgTVVTVA0KPiBvciBT SE9VTEQgYmVjYXVzZSBpdOKAmXMgb25seSB0aGUgZGVmYXVsdCB3aGljaCBhbHdheXMgaW1wbGll cyB0aGF0IHlvdSBtYXkNCj4gdXNlIGFub3RoZXIgdmFsdWUgaWYgeW91IGtub3cgYmV0dGVyLiBI b3dldmVyLCB0aGlua2luZyBhYm91dA0KPiBjb25maWd1cmF0aW9uLCBJIHRoaW5rIGEgTVVTVCBk ZWZhdWx0IHZhbHVlIHByb2JhYmx5IG1ha2VzIG1vcmUgc2Vuc2UNCj4gd2hlbiB0aGVuIHZhbHVl IGlzIGNvbmZpZ3VyYWJsZSBiZWNhdXNlIHRoZW4gdGhlcmUgaXMgYW5vdGhlciB3YXkgdG8NCj4g Y2hhbmdlIGl0IGFuZCBhIE1VU1QgbWlnaHQgYXZvaWQgc3VycHJpc2VzIGlmIHVzZWQgdW5jaGFu Z2VkLiBJZiB0aGUgdmFsdWUgaXMNCj4gbm90IGNvbmZpZ3VyYWJsZSBtYXliZSBTSE9VTEQgbWFr ZXMgbW9yZSBzZW5zZeKApiBhZ2FpbiBpbiBwcmFjdGljZSB0aGVyZQ0KPiBpcyBubyBkaWZmZXJl bmNlOyBub25lIG9mIHRoZXNlIG1lYW4gdGhhdCBhbm90aGVyIHZhbHVlIGNhbm5vdCBiZSB1c2Vk IGJ1dA0KPiBvbmx5IHByb3ZpZGUgZ3VpZGFuY2UgYWJvdXQgYSBzYWZlIGRlZmF1bHQuDQo+IA0K PiBGdXJ0aGVyIHlvdSBjb3VsZCBhbHNvIHNwZWNpZnkgbm9ybWF0aXZlIG1pbiBhbmQgbWF4IHZh bHVlcyB0byBnaXZlIGFuDQo+IGltcGxlbWVudG9yIG9yIGEgdXNlciAodGhhdCBjYW4gY29uZmln dXJlIHRoZXNlIHZhbHVlcykgYSBiZXR0ZXIgaWRlYSBhYm91dA0KPiB3aGljaCByYW5nZSBvZiB2 YWx1ZXMgYXJlIHNhZmUgdG8gZGVwbG95LiBUaGUgdmFsdWVzIHdvdWxkIGJlIE1VU1QNCj4gcmVx dWlyZW1lbnRzIGlmIHRoZXJlIGlzIGEga25vd24gYm91bmRhcnkgdGhhdCB3aWxsIGNhdXNlIHRo ZSBwcm90b2NvbCB0byBub3QNCj4gd29yayBhbnltb3JlIChhcyBleHBlY3RlZCkgb3IgY291bGQg YWxzbyBiZSBTSE9VTERzIGp1c3QgdG8gZ2l2ZSBhIGJldHRlcg0KPiBpZGVhIG9mIGNvbW1vbiBv ciByZWFzb25hYmxlIHZhbHVlcyAobWF5YmUgdG9nZXRoZXIgd2l0aCBhIGRpc2N1c3Npb24NCj4g YWJvdXQgYmFkIHRoaW5rcyB0aGF0IGNhbiBoYXBwZW4gaWYgYSBsYXJnZXIgb3Igc21hbGxlciB2 YWx1ZSBpcyBjaG9zZW4pLg0KPiANCj4gTWlyamENCj4gDQo+IA0KPiANCj4gPiBPbiA2LiBKYW4g MjAyMCwgYXQgMTY6NTIsIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPiB3cm90ZToN Cj4gPg0KPiA+PiBGcm9tOiBNaXJqYSBLdWVobGV3aW5kDQo+ID4+DQo+ID4+IEhpIEp1bGl1c3os DQo+ID4+DQo+ID4+IEkgZGlkbuKAmXQgdGFsayBhYm91dCBwYWNpbmcgaW4gdGhhdCBtYWlsIGJ1 dCBvbmx5IGFib3V0IGRlZmluaW5nDQo+ID4+IGRlZmF1bHQgdmFsdWVzIGZvciB0aGUgaW50ZXJ2 YWwgcGFyYW1ldGVycyB5b3UgYWxyZWFkeSBoYXZlIGRlZmluZWQgaW4gdGhlDQo+IGRyYWZ0Lg0K PiA+Pg0KPiA+PiBJZiBhbGwgZGVwbG95ZWQgc2NlbmFyaW9zIHVzZSB0aGUgZmlyc3Qgc2V0IG9m IHZhbHVlcyBhbmQgdGhlc2UgdmFsdWUNCj4gPj4gYXJlIHdlbGwgYXBwbGljYWJsZSBmb3IgYWxs IGRpZmZlcmVudCBzY2VuYXJpb3MgdGhhdCBhcmUgZGVmaW5lZCBpbg0KPiA+PiB0aGUgdXNlIGNh c2UgZG9jLCBzdWNoIGFzIOKAnHNtYWxsIHVubWFuYWdlZCBuZXR3b3JrIiBhcyB3ZWxsIGFzIGlu IGENCj4gPj4gImxhcmdlIG92ZXJsYXkgbmV0d29ya+KAnSwgd2h5IGRvbuKAmXQgeW91IGp1c3Qg c3BlY2lmeSB0aGVzZSB2YWx1ZXMgYXMNCj4gPj4gbm9ybWF0aXZlbHkgZGVmYXVsdCB2YWx1ZSBp biB0aGUgc3BlYz8NCj4gPj4NCj4gPj4gTWlyamENCj4gPg0KPiA+IEhpIE1pcmphLA0KPiA+IEkn dmUgYmVlbiBzdGF5aW5nIG91dCBvZiB0aGlzIGRpc2N1c3Npb24sIGJlY2F1c2UgSSB3YXNuJ3Qg ZXZlbiBjbG9zZSB0bw0KPiB1bmRlcnN0YW5kaW5nIHdoYXQgdGhlIHJlcXVlc3RlZCBjaGFuZ2Ug d2FzLiBCdXQgdGhpcyBlbWFpbCBpcyBwcm92aWRpbmcNCj4gbWUgd2l0aCBtb3JlIChidXQgc3Rp bGwgaW5jb21wbGV0ZSkgY2xhcml0eS4NCj4gPiBBcyBhbiBhdXRob3Igb2YgZHJhZnQtaWV0Zi1i YWJlbC1pbmZvcm1hdGlvbi1tb2RlbCwgSSBuZWVkIHRvIGFzayBtb3JlDQo+IGRldGFpbGVkIHF1 ZXN0aW9ucywgYmVjYXVzZSB0aGlzIHJlcXVlc3RlZCBjaGFuZ2UgY2FuIGltcGFjdCB0aGF0IGRy YWZ0IChhbmQNCj4gdGhlIGFzc29jaWF0ZWQgWUFORyBkYXRhIG1vZGVsKS4gV2hlbmV2ZXIgYSBw cm90b2NvbCBzcGVjIGRlZmluZXMgYQ0KPiAicGFyYW1ldGVyIiB3aXRoIGEgImRlZmF1bHQiLCBp dCdzIGltcG9ydGFudCBmb3IgYW4gaW5mb3JtYXRpb24vZGF0YSBtb2RlbCB0bw0KPiBhbGxvdyBm b3IgY29uZmlndXJhdGlvbiBvZiB0aGF0IHBhcmFtZXRlciAoYW5kIGluZGljYXRlIGFueSBkZWZh dWx0IHZhbHVlcykuDQo+ID4NCj4gPiBJbiB0aGUgaW5mb3JtYXRpb24gbW9kZWwsIHdlIGN1cnJl bnRseSBoYXZlIHRoZSBmb2xsb3dpbmcgZGVmaW5lZCBpbnRlcnZhbHMNCj4gKGN1cnJlbnRseSBi ZWluZyBzZW50IGJ5IHRoZSBpbXBsZW1lbnRhdGlvbik6DQo+ID4gLSBtdWx0aWNhc3QgSGVsbG8g aW50ZXJ2YWwgKGRlZmluZWQgcGVyIGludGVyZmFjZSkNCj4gPiAtIHVwZGF0ZSBpbnRlcnZhbCAo ZGVmaW5lZCBwZXIgaW50ZXJmYWNlLCB1c2VkIGZvciBtdWx0aWNhc3QgYW5kDQo+ID4gdW5pY2Fz dCkNCj4gPiAtIHVuaWNhc3QgSGVsbG8gaW50ZXJ2YWwgKGRlZmluZWQgcGVyIG5laWdoYm9yKQ0K PiA+DQo+ID4gQXJlIHlvdSByZWZlcnJpbmcgdG8gYW55IG9yIGFsbCBvZiB0aGVzZSBpbnRlcnZh bHM/IEFyZSB0aGVyZSBvdGhlciBpbnRlcnZhbHMNCj4geW91J3JlIGNvbmNlcm5lZCBhYm91dD8g Rm9yIGV4YW1wbGUsIGFyZSB5b3UgcmVmZXJyaW5nIHRvIGltcGxlbWVudGF0aW9uLQ0KPiBzcGVj aWZpYyB2YWx1ZXMgdXNlZCB0byBkZXJpdmUgdGhlc2UgaW50ZXJ2YWxzPw0KPiA+IFRoZXNlIGFy ZSB0aGUgaW50ZXJ2YWxzIHRoZSBXRyBjb25zaWRlcmVkIG1vc3QgaW1wb3J0YW50IGZvciBkZXBs b3llcnMgdG8NCj4gaGF2ZSBwb3RlbnRpYWwga25vd2xlZGdlIG9mLiBIb3dldmVyLCB0aGUgV0cg YWxzbyBkZXRlcm1pbmVkIHRoYXQNCj4gYWxsb3dpbmcgZm9yIGNvbmZpZ3VyYXRpb24gb2YgdGhl c2UgaW50ZXJ2YWxzIHdhc24ndCBuZWVkZWQgYW5kIHdhc24ndCBldmVuDQo+IGEgZ29vZCBpZGVh LiBTbyB0aGV5J3JlIHJlYWQtb25seS4gSW1wbGVtZW50YXRpb25zIGFyZSBleHBlY3RlZCB0bw0K PiBhbGdvcml0aG1pY2FsbHkgZGV0ZXJtaW5lIGFwcHJvcHJpYXRlIHZhbHVlcyBmb3IgdGhlc2Ug aW50ZXJ2YWxzLg0KPiA+DQo+ID4gVGhlIHJmYzYxMjZiaXMgZHJhZnQgZXhwb3VuZHMgb24gc29t ZSBvZiB0aGUgcmVhc29uaW5nIGZvciB0aGlzIHdpdGgNCj4gPiBzdGF0ZW1lbnRzIGxpa2UgIiBG b3IgZXhhbXBsZSwgYSBtb2JpbGUgbm9kZQ0KPiA+ICAgdGhhdCBpcyBsb3cgb24gYmF0dGVyeSBt YXkgY2hvb3NlIHRvIHVzZSBsYXJnZXIgdGltZSBjb25zdGFudHMgKGhlbGxvDQo+ID4gICBhbmQg dXBkYXRlIGludGVydmFscywgZXRjLikgdGhhbiBhIG5vZGUgdGhhdCBoYXMgYWNjZXNzIHRvIHdh bGwNCj4gPiAgIHBvd2VyLiAgQ29udmVyc2VseSwgYSBub2RlIHRoYXQgZGV0ZWN0cyBoaWdoIGxl dmVscyBvZiBtb2JpbGl0eSBtYXkNCj4gPiAgIGNob29zZSB0byB1c2Ugc21hbGxlciB0aW1lIGNv bnN0YW50cy4gIFRoZSBhYmlsaXR5IHRvIGJ1aWxkIHN1Y2gNCj4gPiAgIGhldGVyb2dlbmVvdXMg bmV0d29ya3MgbWFrZXMgQmFiZWwgcGFydGljdWxhcmx5IGFkYXB0ZWQgdG8gdGhlDQo+ID4gICB1 bm1hbmFnZWQgYW5kIHdpcmVsZXNzIGVudmlyb25tZW50LiINCj4gPg0KPiA+IFRoaXMgc3VnZ2Vz dHMgYW4gaW1wbGVtZW50YXRpb24gbWF5IGhhdmUgZGlmZmVyZW50IGRlZmF1bHRzIGJ1aWx0IGlu IG9yDQo+IGFsZ29yaXRobWljYWxseSBjYWxjdWxhdGVkLCBiYXNlZCBub3Qgb25seSBvbiBsaW5r IGNoYXJhY3RlcmlzdGljcywgYnV0IGFsc28NCj4gcG93ZXIgc3VwcGx5IChhbmQgcG90ZW50aWFs bHkgb3RoZXIgZmFjdG9ycykuIElkZW50aWZ5aW5nIGEgc2luZ2xlIG1hbmRhdG9yeQ0KPiBkZWZh dWx0IHdvdWxkIG1ha2UgaXQgZGlmZmljdWx0IGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0byBoYW5k bGUgc3BlY2lmaWMNCj4gZW52aXJvbm1lbnRhbCBmYWN0b3JzLiBJZGVudGlmeWluZyBtdWx0aXBs ZSBtYW5kYXRvcnkgZGVmYXVsdHMgYmFzZWQgb24NCj4gcGVybXV0YXRpb25zIG9mIGVudmlyb25t ZW50YWwgZmFjdG9ycyB3b3VsZCBiZSB2ZXJ5IGNvbXBsZXgsIGFuZCBtaWdodA0KPiBvbWl0IHNv bWUgaW1wb3J0YW50IGVudmlyb25tZW50YWwgZmFjdG9ycyAob3IgcGVybXV0YXRpb25zIG9mIGZh Y3RvcnMpIHRoYXQNCj4gYW4gaW1wbGVtZW50b3IgZGVjaWRlcyB0byBidWlsZCBpbnRvIGEgcGFy dGljdWxhciBpbXBsZW1lbnRhdGlvbi4NCj4gPg0KPiA+IElNTywgdGhlIFdHIG1hZGUgdGhlIHJp Z2h0IGRlY2lzaW9uIG5vdCB0byBhbGxvdyBjb25maWd1cmF0aW9uIG9mIHRoZXNlDQo+IGludGVy dmFscyAob3IgdHJ5IHRvIGlkZW50aWZ5IHBhcmFtZXRlcnMgdG8gaW5mbHVlbmNlIGNhbGN1bGF0 aW9uIG9mIHRoZXNlDQo+IGludGVydmFsIHZhbHVlcykuIFNvIEkgaGF2ZSB0byBhZ3JlZSB3aXRo IEp1bGl1c3ogdGhhdCAoaWYgdGhlc2UgYXJlIHRoZSBpbnRlcnZhbHMNCj4geW91J3JlIHRhbGtp bmcgYWJvdXQpIHRoZSBzcGVjIHNob3VsZG4ndCBpZGVudGlmeSBhbnkgZGVmYXVsdCB2YWx1ZXMg Zm9yIHRoZW0uDQo+ID4NCj4gPiBJZiBJJ20gbWlzdW5kZXJzdGFuZGluZyB0aGUgcmVxdWVzdCwg cGxlYXNlIGxldCBtZSBrbm93OyBiZWNhdXNlIEkgc3RpbGwNCj4gdGhpbmsgaXQgd2lsbCBpbXBh Y3QgdGhlIGluZm8vZGF0YSBtb2RlbHMuDQo+ID4gVGh4LA0KPiA+IEJhcmJhcmENCj4gPg0KPiA+ Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gT24gMTcuIERlYyAyMDE5LCBhdCAyMDowNCwgSnVsaXVzeiBD aHJvYm9jemVrIDxqY2hAaXJpZi5mcj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+PiBJZiB0aGF0IGlz IHRoZSBjYXNlLCB0aGVuIEkgcmVxdWVzdCB0aGF0IHlvdSBzdGF0ZSBleHBsaWNpdGx5IHdoeQ0K PiA+Pj4+PiB5b3UgdGhpbmsgdGhhdCBCYWJlbCBtdXN0IGJlIGhlbGQgdG8gYSBtdWNoIGhpZ2hl ciBzdGFuZGFyZCB0aGFuDQo+ID4+Pj4+IE9TUEZ2My4gIElmIHRoYXQgaXMgbm90IHRoZSBjYXNl LCB0aGVuIHBsZWFzZSBjbGVhciB5b3VyIGRpc2N1c3MuDQo+ID4+Pg0KPiA+Pj4+IEluIE9TUEZ2 MyBhcyBmYXIgYXMgSSBjYW4gc2VlIChhbmQgSSBhbSByZWFsbHkgbm90IGFuIGV4cGVydCBoZXJl KQ0KPiA+Pj4+IGFsbCB2YWx1ZXMgdGhhdCBkZWZpbmUgaW50ZXJ2YWxzIGFyZSBpbiBzZWNvbmRz IHdoaWNoIGxlYWRzIHRvIGENCj4gPj4+PiBtaW5pbXVtIHZhbHVlIG9mIDEgc2Vjb25kcy4gVGhp cyBpcyBub3QgdGhlIGNhc2UgZm9yIGJhYmVsIGFuZA0KPiA+Pj4+IHRoZXJlZm9yZSB3ZSBuZWVk IHRvIGJlIG1vcmUgY2FyZnVsIGhlcmUuDQo+ID4+Pg0KPiA+Pj4gQWZ0ZXIgYSBjaGFuZ2Ugb2Yg dG9wb2xvZ3ksIE9TUEYgZXhlY3V0ZXMgdGhlIHByb2NlZHVyZSBkZXNjcmliZWQgaW4NCj4gPj4+ IFNlY3Rpb24gNC41LjIgb2YgUkZDIDUzNDAgKFNlY3Rpb24gMTMuMyBvZiBSRkMgMjMyOCkuICBB dCB0aGlzDQo+ID4+PiBwb2ludCwgYSBwb3RlbnRpYWxseSB1bmJvdW5kZWQgbnVtYmVyIG9mIExT QXMgYXJlIGZsb29kZWQgb3V0IGV2ZXJ5DQo+ID4+PiBhY3RpdmUgaW50ZXJmYWNlIChwb2ludCA1 IGluIFNlY3Rpb24gMTMuMyBvZiBSRkMgMjMyOCkuICBUaGlzDQo+ID4+PiBmbG9vZGluZyBpcyBu b3QgcmVndWxhdGVkIGJ5IGFueSB0aW1lciAtLSBhbGwgdGhhdCB0aGUgcHJvdG9jb2wgc2F5cw0K PiA+Pj4gaXMgdGhhdCB0aGUgTFNBcyBtdXN0IGdvIG91dCB0aHJvdWdoIGEgY2VydGFpbiBzdWJz ZXQgb2YgdGhlIHJvdXRlcidzDQo+IGludGVyZmFjZXMuDQo+ID4+Pg0KPiA+Pj4gSSBjb3VsZCBi ZSB3cm9uZywgYnV0IEkgYW0gZmFpcmx5IGNvbmZpZGVudCB0aGF0IG5vdGhpbmcgaW4gUkZDcw0K PiA+Pj4gNTM0MCBhbmQNCj4gPj4+IDIzMjggc3BlY2lmaWVzIGNvbmdlc3Rpb24gY29udHJvbCwg ZmxvdyBjb250cm9sIG9yIHBhY2tldCBwYWNpbmcgZm9yDQo+ID4+PiB0aGlzIGZsb29kaW5nIHBy b2NlZHVyZS4gIE15IGludGVycHJldGF0aW9uIGlzIHRoYXQgc2luY2UgT1NQRiBpcw0KPiA+Pj4g ZGVzaWduZWQgdG8gYmUgZGVwbG95ZWQgb24gbG9jYWwgbGlua3MsIGNvbmdlc3Rpb24gY2F1c2Vk IGJ5IE9TUEYgaXMNCj4gPj4+IG5vdCBsaWtlbHkgdG8gZW5kYW5nZXIgdGhlIEdsb2JhbCBJbnRl cm5ldCwgYW5kIHRoZXJlZm9yZSBwYWNrZXQNCj4gPj4+IHBhY2luZyAoaWYgcmVxdWlyZWQpIGlz IGxlZnQgdG8gdGhlIGltcGxlbWVudGF0aW9uLg0KPiA+Pj4NCj4gPj4+IEkgYWxzbyBkb24ndCBy ZWNhbGwgYW55IGRpc2N1c3Npb24gb2YgZmxvdyBjb250cm9sIGluIE1veSdzIGFuZA0KPiA+Pj4g R3JlZGxlcidzIGJvb2tzLCBidXQgdGhleSBoYXZlIGEgbG90IG9mIHBhZ2VzIChlc3BlY2lhbGx5 DQo+ID4+PiBHcmVkbGVyJ3MpLCBzbywgYWdhaW4sIEkgY291bGQgYmUgd3JvbmcuDQo+ID4+Pg0K PiA+Pj4gV2hlcmUgeW91IGFyZSByaWdodCwgTWlyamEsIGlzIHRoYXQgcGFja2V0IHBhY2luZyBp cyBhIHZlcnkNCj4gPj4+IGRpZmZpY3VsdCBwcm9ibGVtIGluIE9TUEYsIHdoZXJlIGluY29ycmVj dGx5IGRlbGF5aW5nIGZsb29kaW5nIGNvdWxkDQo+ID4+PiBsZWFkIHRvIG1pY3JvbG9vcHM7IHNp bmNlIEJhYmVsIGhhcyBhIGxvb3AtYXZvaWRhbmNlIG1lY2hhbmlzbQ0KPiA+Pj4gYnVpbHQtaW4s IGl0IGNhbiBzYWZlbHkgcGVyZm9ybSBwYWNrZXQgcGFjaW5nIHNob3VsZCB0aGUgbmVlZCB0byBk bw0KPiA+Pj4gc28gYmUgZGVtb25zdHJhdGVkIGluIGEgcGFydGljdWxhciB0b3BvbG9neS4NCj4g Pj4+DQo+ID4+PiBJbiBzdW1tYXJ5LCB3aGlsZSBJIGFncmVlIHRoYXQgcGFja2V0IHBhY2luZyBm b3IgQmFiZWwgd291bGQgYmUgYW4NCj4gPj4+IGludGVyZXN0aW5nIHJlc2VhcmNoIHByb2plY3Qs IEkgbWFpbnRhaW4gdGhhdCBieSByZXF1aXJpbmcgcGFja2V0DQo+ID4+PiBwYWNpbmcgYXMgYSBj b25kaXRpb24gZm9yIHB1YmxpY2F0aW9uIGFzIFBTLCB5b3UgYXJlIHJlcXVpcmluZyBhbg0KPiA+ Pj4gdW5yZWFzb25hYmx5IGhpZ2ggc3RhbmRhcmQsIGNlcnRhaW5seSBhIHN0YW5kYXJkIHRoYXQg bmVpdGhlciBPU1BGDQo+ID4+PiBub3IgSVMtDQo+ID4+IElTIGFyZSBoZWxkIHRvLg0KPiA+Pj4N Cj4gPj4+Pj4gQXBwZW5kaXggQiBnaXZlcyB2YWx1ZXMgdGhhdCBhcmUgc3VnZ2VzdGVkIGZvciBp bXBsZW1lbnRhdGlvbnMuDQo+ID4+Pg0KPiA+Pj4+IFllcyBidXQgaXQgZG9lc27igJl0IGRpc2N1 c3MgZm9yIHdpdGggX2RlcGxveW1lbnRfIHNjZW5hcmlvcyB0aGVzZQ0KPiA+Pj4+IHZhbHVlcyBh cmUgc3VpdGFibGUuDQo+ID4+Pg0KPiA+Pj4gQXMgZmFyIGFzIEkgYW0gYXdhcmUsIGFsbCBjdXJy ZW50IHByb2R1Y3Rpb24gZGVwbG95bWVudHMgdXNlIHRoZQ0KPiA+Pj4gZmlyc3Qgc2V0IG9mIGNv bnN0YW50cy4gIFRoZSBvbmUgZXhjZXB0aW9uIGlzIGFuIGV4cGVyaW1lbnRhbA0KPiA+Pj4gdGVz dGJlZCB1c2VkIGZvciBtb2JpbGl0eSByZXNlYXJjaCwgdGhhdCB1c2VzIHRoZSAobW9yZSBhZ2dy ZXNzaXZlKQ0KPiA+Pj4gc2Vjb25kIHNldCBvZg0KPiA+PiBjb25zdGFudHMuDQo+ID4+Pg0KPiA+ Pj4+IERpZCB5b3UgZGVwbG95IHRoZSBzYW1lIHBhcmFtZXRlcnMgaW4gYWxsIG9mIHRoZSBkaXNj dXNzZWQgc2NlbmFyaW9zLg0KPiA+Pj4NCj4gPj4+IFllcy4NCj4gPj4+DQo+ID4+Pj4gRG9lcyBp dCBhY3R1YWxseSBtYWtlcyBzZW5zZSB0byB1c2UgdGhlIHNhbWUgcGFyYW1ldGVycyBpbiBhICJz bWFsbA0KPiA+Pj4+IHVubWFuYWdlZCBuZXR3b3JrIiBhcyB3ZWxsIGFzIGluIGEgImxhcmdlIG92 ZXJsYXkgbmV0d29yayI/DQo+ID4+Pg0KPiA+Pj4gWWVzLg0KPiA+Pj4NCj4gPj4+PiBJcyB0aGF0 IG5ldHdvcmsgY29ubmVjdGVkIHRvIHRoZSBJbnRlcm5ldCBvciBub3Q/DQo+ID4+Pg0KPiA+Pj4g WWVzLCBidXQgdGhhdCdzIGlycmVsZXZhbnQgLS0gdGhlIEJhYmVsIHRyYWZmaWMgaXMgbGluay1s b2NhbCwgYW5kDQo+ID4+PiBkb2VzIG5vdCBnbyBvdXRzaWRlIHRoZSBsb2NhbCByb3V0aW5nIGRv bWFpbi4NCj4gPj4+DQo+ID4+PiAtLSBKdWxpdXN6DQo+ID4+Pg0KPiA+Pg0KPiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBiYWJlbCBtYWls aW5nIGxpc3QNCj4gPj4gYmFiZWxAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+PiAzQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fYmFiZWwmZD1Ed0lHYVEmYz1MRllaLQ0KPiA+PiBvOV9IVU1lTVRTUWljdmpJ ZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT1sQUZ2c1UwX09QRHktDQo+ID4+IFpsSEl2NXVC UGRrNHZmQU5JRHJBOTUyQWprQTEwOCZzPVF1ckZ2VzZ4NS0NCj4gPj4gY2Q2Sk5aNjVjcGNoWXVY ektiMmJmUGZNWE9mSWVDVDVnJmU9DQoNCg== From nobody Mon Jan 6 16:41:10 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0CB1200CE; Mon, 6 Jan 2020 16:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKSbw-K9vYQa; Mon, 6 Jan 2020 16:40:58 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 1A8BB120041; Mon, 6 Jan 2020 16:40:58 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id 203so37565246lfa.12; Mon, 06 Jan 2020 16:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sx2XDlr13i41GCYAigFF1DEY/2JwMCKpmlCf/WcnMJc=; b=AT7khScvQvNaHLqijytufKtAt4dQ2ajER45PWx2MRzcodzPy4g2jAuzg/4IVpJd+y6 CIYb3/KJBm/69njzAhdDpD/GwEI7k1FLnWaQgn8JLdineYe7yIk/nvAJWkqpTkwCf/p9 R+AvQ9fqv8+Cm4yEC+xMiYqi2UZcsYJM0haegTJ1ct72xN10w5craFqhW03NmbIp3ZzT Svl4F+2qC4FFCY/7WzzbmrGk2q8iLDteH5a24rmve4vsGujFLVDXORFIzoJjXSRSf66g 0ah1xur36q+RyljbworDlo5URht74Pez8CBP2fgsSjWOVRM7RlCVW3lmn5Gx6FPLk5FZ 6vIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sx2XDlr13i41GCYAigFF1DEY/2JwMCKpmlCf/WcnMJc=; b=NoBkgxOHdpI9KYczf9WhBk3f2AtBY1jPCk5Q7t2fEb2bAS7CLap7oCeAriF2aUsDjt B61x0lhvYIsEgBiNql3zBHkreivNoR/8jgOBzHZIu4ITjFsSIHH1ghHwX/mU8UrByzcW 5IQjfBsBceXeU3tu5Fz78nq/XylMktO7C55uErBNWPy0XJjCNi6CDPEl36M7DBrLSTAz rtWftymi751El8XMGGGk5M6NHkWddGPUUCTod8fOCjtW/EEKqgKp6li74QK/P0Z8kBXN HD0eCJyD/9zL+wSJhlUw22AqaE88c3tMVhQ2nUcA37Dz98YHCElTwnoZjW4ldgxBssqM dLZw== X-Gm-Message-State: APjAAAUnlwvxSI//ymAjpnxkLq1u6GuQQUFXLm4C5OuLLKy+rkxZ2RRf 5mTslDmoFfjxYQAO8Yy1yBCcoxI9ERbqDjCuKmw= X-Google-Smtp-Source: APXvYqypHmQYtm+rI+z716wS7Q+0i9FmoakInC0+g8TGpE9CWzbPj1XS/LxoiAjjFC0lFCtGExIAgH26EXz/RPCfNlA= X-Received: by 2002:ac2:4834:: with SMTP id 20mr53064999lft.166.1578357656085; Mon, 06 Jan 2020 16:40:56 -0800 (PST) MIME-Version: 1.0 References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6115372AF7D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6115372AF7D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Mon, 6 Jan 2020 16:40:44 -0800 Message-ID: To: "STARK, BARBARA H" Cc: Mirja Kuehlewind , Juliusz Chroboczek , "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux Content-Type: multipart/alternative; boundary="0000000000006b696e059b82071a" Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 00:41:03 -0000 --0000000000006b696e059b82071a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Barbara, The text you mention containing "The following values are recommended" intentionally does not use RFC2119 language. The appendices of rfc6126bis do not contain any RFC2119 uppercase language as appendices are not meant to be normative. Hi Mirja, It sounds like you're asking us to move the informative values from the appendix to a normative statement in the core spec. That goes against the current design philosophies of the document, which is to specify normatively only what is needed for interoperability, and leave any advice to non-normative appendices. I'm not sure I understand what your proposed change would accomplish. As we have seen repeatedly, implementors of Babel have been happy to read the appendix and follow that implementation advice in the absence of better ideas. I would rather keep what we currently have, as it is a principled approach that has worked in practice for all known implementations of Babel. Thanks, David On Mon, Jan 6, 2020 at 1:54 PM STARK, BARBARA H wrote: > Hi Mirja, > Thanks for that. OK, so you don't need them to be configurable or > mandatory (which means the WG consensus that they not be configurable is > acceptable) and you would be satisfied with "SHOULD". Normative language > terminology (RFC 2119) allows for use of "RECOMMENDED" to mean the same a= s > "SHOULD", and "Appendix B: Protocol parameters" currently says (in 2 > places) "The following values are recommended ..." > If this were changed to " The following values are RECOMMENDED ...", woul= d > that satisfy your comment? > > Juliusz, would that be acceptable to you? > Barbara > > > Hi Barbara, > > > > To me the question of configuration is actually orthogonal. > > > > I think this sentence you write is the core of the misunderstanding we > might > > have: > > > Identifying a single mandatory default would make it difficult for an > > > implementation to handle specific environmental factors. > > > > The whole point of the word =E2=80=9Cdefault=E2=80=9D here is that of c= ourse you can use > > another value (because otherwise it would not be a parameter but a > > constant). What I=E2=80=99m talking about is the point of time when the= code is > > written and I as an implementator have to decide which value to set (fo= r > my > > implementation). Having a normatively defined default value doesn=E2=80= =99t mean > > that all implementation have to use this value, but if I write the code > at a > > point of time where I might not be aware of specific requirements, the > > default values should give me some reasonable idea about something that > > will work =E2=80=9Cwell=E2=80=9D in =E2=80=9Cmost=E2=80=9D scenarios (w= hich it seems to be case that > this set > > actually exists for babel as people tell me that all deployed > implementation > > currently use the same value). I=E2=80=99d say it=E2=80=99s common prac= tice these kind of > > default values are specified normatively (with MUSTs or SHOULDs) as par= t > of > > the protocol spec as it gives simply implementor (that don=E2=80=99t kn= ow any > better) > > a high incentive to use these values (more than some examples values in > the > > appendix). > > > > I guess for a default value it=E2=80=99s doesn=E2=80=99t make a real di= fference to have > a MUST > > or SHOULD because it=E2=80=99s only the default which always implies th= at you may > > use another value if you know better. However, thinking about > > configuration, I think a MUST default value probably makes more sense > > when then value is configurable because then there is another way to > > change it and a MUST might avoid surprises if used unchanged. If the > value is > > not configurable maybe SHOULD makes more sense=E2=80=A6 again in practi= ce there > > is no difference; none of these mean that another value cannot be used > but > > only provide guidance about a safe default. > > > > Further you could also specify normative min and max values to give an > > implementor or a user (that can configure these values) a better idea > about > > which range of values are safe to deploy. The values would be MUST > > requirements if there is a known boundary that will cause the protocol > to not > > work anymore (as expected) or could also be SHOULDs just to give a bett= er > > idea of common or reasonable values (maybe together with a discussion > > about bad thinks that can happen if a larger or smaller value is chosen= ). > > > > Mirja > > > > > > > > > On 6. Jan 2020, at 16:52, STARK, BARBARA H wrote: > > > > > >> From: Mirja Kuehlewind > > >> > > >> Hi Juliusz, > > >> > > >> I didn=E2=80=99t talk about pacing in that mail but only about defin= ing > > >> default values for the interval parameters you already have defined > in the > > draft. > > >> > > >> If all deployed scenarios use the first set of values and these valu= e > > >> are well applicable for all different scenarios that are defined in > > >> the use case doc, such as =E2=80=9Csmall unmanaged network" as well = as in a > > >> "large overlay network=E2=80=9D, why don=E2=80=99t you just specify = these values as > > >> normatively default value in the spec? > > >> > > >> Mirja > > > > > > Hi Mirja, > > > I've been staying out of this discussion, because I wasn't even close > to > > understanding what the requested change was. But this email is providin= g > > me with more (but still incomplete) clarity. > > > As an author of draft-ietf-babel-information-model, I need to ask mor= e > > detailed questions, because this requested change can impact that draft > (and > > the associated YANG data model). Whenever a protocol spec defines a > > "parameter" with a "default", it's important for an information/data > model to > > allow for configuration of that parameter (and indicate any default > values). > > > > > > In the information model, we currently have the following defined > intervals > > (currently being sent by the implementation): > > > - multicast Hello interval (defined per interface) > > > - update interval (defined per interface, used for multicast and > > > unicast) > > > - unicast Hello interval (defined per neighbor) > > > > > > Are you referring to any or all of these intervals? Are there other > intervals > > you're concerned about? For example, are you referring to implementatio= n- > > specific values used to derive these intervals? > > > These are the intervals the WG considered most important for deployer= s > to > > have potential knowledge of. However, the WG also determined that > > allowing for configuration of these intervals wasn't needed and wasn't > even > > a good idea. So they're read-only. Implementations are expected to > > algorithmically determine appropriate values for these intervals. > > > > > > The rfc6126bis draft expounds on some of the reasoning for this with > > > statements like " For example, a mobile node > > > that is low on battery may choose to use larger time constants (hel= lo > > > and update intervals, etc.) than a node that has access to wall > > > power. Conversely, a node that detects high levels of mobility may > > > choose to use smaller time constants. The ability to build such > > > heterogeneous networks makes Babel particularly adapted to the > > > unmanaged and wireless environment." > > > > > > This suggests an implementation may have different defaults built in = or > > algorithmically calculated, based not only on link characteristics, but > also > > power supply (and potentially other factors). Identifying a single > mandatory > > default would make it difficult for an implementation to handle specifi= c > > environmental factors. Identifying multiple mandatory defaults based on > > permutations of environmental factors would be very complex, and might > > omit some important environmental factors (or permutations of factors) > that > > an implementor decides to build into a particular implementation. > > > > > > IMO, the WG made the right decision not to allow configuration of the= se > > intervals (or try to identify parameters to influence calculation of > these > > interval values). So I have to agree with Juliusz that (if these are th= e > intervals > > you're talking about) the spec shouldn't identify any default values fo= r > them. > > > > > > If I'm misunderstanding the request, please let me know; because I > still > > think it will impact the info/data models. > > > Thx, > > > Barbara > > > > > >> > > >> > > >> > > >>> On 17. Dec 2019, at 20:04, Juliusz Chroboczek wrote: > > >>> > > >>>>> If that is the case, then I request that you state explicitly why > > >>>>> you think that Babel must be held to a much higher standard than > > >>>>> OSPFv3. If that is not the case, then please clear your discuss. > > >>> > > >>>> In OSPFv3 as far as I can see (and I am really not an expert here) > > >>>> all values that define intervals are in seconds which leads to a > > >>>> minimum value of 1 seconds. This is not the case for babel and > > >>>> therefore we need to be more carful here. > > >>> > > >>> After a change of topology, OSPF executes the procedure described i= n > > >>> Section 4.5.2 of RFC 5340 (Section 13.3 of RFC 2328). At this > > >>> point, a potentially unbounded number of LSAs are flooded out every > > >>> active interface (point 5 in Section 13.3 of RFC 2328). This > > >>> flooding is not regulated by any timer -- all that the protocol say= s > > >>> is that the LSAs must go out through a certain subset of the router= 's > > interfaces. > > >>> > > >>> I could be wrong, but I am fairly confident that nothing in RFCs > > >>> 5340 and > > >>> 2328 specifies congestion control, flow control or packet pacing fo= r > > >>> this flooding procedure. My interpretation is that since OSPF is > > >>> designed to be deployed on local links, congestion caused by OSPF i= s > > >>> not likely to endanger the Global Internet, and therefore packet > > >>> pacing (if required) is left to the implementation. > > >>> > > >>> I also don't recall any discussion of flow control in Moy's and > > >>> Gredler's books, but they have a lot of pages (especially > > >>> Gredler's), so, again, I could be wrong. > > >>> > > >>> Where you are right, Mirja, is that packet pacing is a very > > >>> difficult problem in OSPF, where incorrectly delaying flooding coul= d > > >>> lead to microloops; since Babel has a loop-avoidance mechanism > > >>> built-in, it can safely perform packet pacing should the need to do > > >>> so be demonstrated in a particular topology. > > >>> > > >>> In summary, while I agree that packet pacing for Babel would be an > > >>> interesting research project, I maintain that by requiring packet > > >>> pacing as a condition for publication as PS, you are requiring an > > >>> unreasonably high standard, certainly a standard that neither OSPF > > >>> nor IS- > > >> IS are held to. > > >>> > > >>>>> Appendix B gives values that are suggested for implementations. > > >>> > > >>>> Yes but it doesn=E2=80=99t discuss for with _deployment_ scenarios= these > > >>>> values are suitable. > > >>> > > >>> As far as I am aware, all current production deployments use the > > >>> first set of constants. The one exception is an experimental > > >>> testbed used for mobility research, that uses the (more aggressive) > > >>> second set of > > >> constants. > > >>> > > >>>> Did you deploy the same parameters in all of the discussed > scenarios. > > >>> > > >>> Yes. > > >>> > > >>>> Does it actually makes sense to use the same parameters in a "smal= l > > >>>> unmanaged network" as well as in a "large overlay network"? > > >>> > > >>> Yes. > > >>> > > >>>> Is that network connected to the Internet or not? > > >>> > > >>> Yes, but that's irrelevant -- the Babel traffic is link-local, and > > >>> does not go outside the local routing domain. > > >>> > > >>> -- Juliusz > > >>> > > >> > > >> _______________________________________________ > > >> babel mailing list > > >> babel@ietf.org > > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > >> 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwIGaQ&c=3DLFYZ- > > >> o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DlAFvsU0_OPDy- > > >> ZlHIv5uBPdk4vfANIDrA952AjkA108&s=3DQurFvW6x5- > > >> cd6JNZ65cpchYuXzKb2bfPfMXOfIeCT5g&e=3D > > --0000000000006b696e059b82071a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Barbara,

The text you mention contai= ning "The following values are recommended" intentionally does no= t use RFC2119 language. The appendices of rfc6126bis do not contain any RFC= 2119 uppercase language as appendices are not meant to be normative.
<= div>
Hi Mirja,

It sounds like you= 9;re asking us to move the informative values from the appendix to a normat= ive statement in the core spec. That goes against the current design philos= ophies of the document, which is to specify normatively only what is needed= for interoperability, and leave any advice to non-normative appendices. I&= #39;m not sure I understand what your proposed change would accomplish. As = we have seen repeatedly, implementors of Babel have been happy to read the = appendix and follow that implementation advice in the absence of better ide= as. I would rather keep what we currently have, as it is a principled appro= ach=C2=A0that has worked in=C2=A0practice for all known implementations of = Babel.

Thanks,
David

On Mon, Jan 6,= 2020 at 1:54 PM STARK, BARBARA H <bs7= 652@att.com> wrote:
Hi Mirja,
Thanks for that. OK, so you don't need them to be configurable or manda= tory (which means the WG consensus that they not be configurable is accepta= ble) and you would be satisfied with "SHOULD". Normative language= terminology (RFC 2119) allows for use of "RECOMMENDED" to mean t= he same as "SHOULD", and "Appendix B: Protocol parameters&qu= ot; currently says (in 2 places) "The following values are recommended= ..."
If this were changed to " The following values are RECOMMENDED ...&quo= t;, would that satisfy your comment?

Juliusz, would that be acceptable to you?
Barbara

> Hi Barbara,
>
> To me the question of configuration is actually orthogonal.
>
> I think this sentence you write is the core of the misunderstanding we= might
> have:
> > Identifying a single mandatory default would make it difficult fo= r an
> > implementation to handle specific environmental factors.
>
> The whole point of the word =E2=80=9Cdefault=E2=80=9D here is that of = course you can use
> another value (because otherwise it would not be a parameter but a
> constant). What I=E2=80=99m talking about is the point of time when th= e code is
> written and I as an implementator have to decide which value to set (f= or my
> implementation). Having a normatively defined default value doesn=E2= =80=99t mean
> that all implementation have to use this value, but if I write the cod= e at a
> point of time where I might not be aware of specific requirements, the=
> default values should give me some reasonable idea about something tha= t
> will work =E2=80=9Cwell=E2=80=9D in =E2=80=9Cmost=E2=80=9D scenarios (= which it seems to be case that this set
> actually exists for babel as people tell me that all deployed implemen= tation
> currently use the same value). I=E2=80=99d say it=E2=80=99s common pra= ctice these kind of
> default values are specified normatively (with MUSTs or SHOULDs) as pa= rt of
> the protocol spec as it gives simply implementor (that don=E2=80=99t k= now any better)
> a high incentive to use these values (more than some examples values i= n the
> appendix).
>
> I guess for a default value it=E2=80=99s doesn=E2=80=99t make a real d= ifference to have a MUST
> or SHOULD because it=E2=80=99s only the default which always implies t= hat you may
> use another value if you know better. However, thinking about
> configuration, I think a MUST default value probably makes more sense<= br> > when then value is configurable because then there is another way to > change it and a MUST might avoid surprises if used unchanged. If the v= alue is
> not configurable maybe SHOULD makes more sense=E2=80=A6 again in pract= ice there
> is no difference; none of these mean that another value cannot be used= but
> only provide guidance about a safe default.
>
> Further you could also specify normative min and max values to give an=
> implementor or a user (that can configure these values) a better idea = about
> which range of values are safe to deploy. The values would be MUST
> requirements if there is a known boundary that will cause the protocol= to not
> work anymore (as expected) or could also be SHOULDs just to give a bet= ter
> idea of common or reasonable values (maybe together with a discussion<= br> > about bad thinks that can happen if a larger or smaller value is chose= n).
>
> Mirja
>
>
>
> > On 6. Jan 2020, at 16:52, STARK, BARBARA H <bs7652@att.com> wrote:
> >
> >> From: Mirja Kuehlewind
> >>
> >> Hi Juliusz,
> >>
> >> I didn=E2=80=99t talk about pacing in that mail but only abou= t defining
> >> default values for the interval parameters you already have d= efined in the
> draft.
> >>
> >> If all deployed scenarios use the first set of values and the= se value
> >> are well applicable for all different scenarios that are defi= ned in
> >> the use case doc, such as =E2=80=9Csmall unmanaged network&qu= ot; as well as in a
> >> "large overlay network=E2=80=9D, why don=E2=80=99t you j= ust specify these values as
> >> normatively default value in the spec?
> >>
> >> Mirja
> >
> > Hi Mirja,
> > I've been staying out of this discussion, because I wasn'= t even close to
> understanding what the requested change was. But this email is providi= ng
> me with more (but still incomplete) clarity.
> > As an author of draft-ietf-babel-information-model, I need to ask= more
> detailed questions, because this requested change can impact that draf= t (and
> the associated YANG data model). Whenever a protocol spec defines a > "parameter" with a "default", it's important f= or an information/data model to
> allow for configuration of that parameter (and indicate any default va= lues).
> >
> > In the information model, we currently have the following defined= intervals
> (currently being sent by the implementation):
> > - multicast Hello interval (defined per interface)
> > - update interval (defined per interface, used for multicast and<= br> > > unicast)
> > - unicast Hello interval (defined per neighbor)
> >
> > Are you referring to any or all of these intervals? Are there oth= er intervals
> you're concerned about? For example, are you referring to implemen= tation-
> specific values used to derive these intervals?
> > These are the intervals the WG considered most important for depl= oyers to
> have potential knowledge of. However, the WG also determined that
> allowing for configuration of these intervals wasn't needed and wa= sn't even
> a good idea. So they're read-only. Implementations are expected to=
> algorithmically determine appropriate values for these intervals.
> >
> > The rfc6126bis draft expounds on some of the reasoning for this w= ith
> > statements like " For example, a mobile node
> >=C2=A0 =C2=A0that is low on battery may choose to use larger time = constants (hello
> >=C2=A0 =C2=A0and update intervals, etc.) than a node that has acce= ss to wall
> >=C2=A0 =C2=A0power.=C2=A0 Conversely, a node that detects high lev= els of mobility may
> >=C2=A0 =C2=A0choose to use smaller time constants.=C2=A0 The abili= ty to build such
> >=C2=A0 =C2=A0heterogeneous networks makes Babel particularly adapt= ed to the
> >=C2=A0 =C2=A0unmanaged and wireless environment."
> >
> > This suggests an implementation may have different defaults built= in or
> algorithmically calculated, based not only on link characteristics, bu= t also
> power supply (and potentially other factors). Identifying a single man= datory
> default would make it difficult for an implementation to handle specif= ic
> environmental factors. Identifying multiple mandatory defaults based o= n
> permutations of environmental factors would be very complex, and might=
> omit some important environmental factors (or permutations of factors)= that
> an implementor decides to build into a particular implementation.
> >
> > IMO, the WG made the right decision not to allow configuration of= these
> intervals (or try to identify parameters to influence calculation of t= hese
> interval values). So I have to agree with Juliusz that (if these are t= he intervals
> you're talking about) the spec shouldn't identify any default = values for them.
> >
> > If I'm misunderstanding the request, please let me know; beca= use I still
> think it will impact the info/data models.
> > Thx,
> > Barbara
> >
> >>
> >>
> >>
> >>> On 17. Dec 2019, at 20:04, Juliusz Chroboczek <jch@irif.fr> wrote:
> >>>
> >>>>> If that is the case, then I request that you stat= e explicitly why
> >>>>> you think that Babel must be held to a much highe= r standard than
> >>>>> OSPFv3.=C2=A0 If that is not the case, then pleas= e clear your discuss.
> >>>
> >>>> In OSPFv3 as far as I can see (and I am really not an= expert here)
> >>>> all values that define intervals are in seconds which= leads to a
> >>>> minimum value of 1 seconds. This is not the case for = babel and
> >>>> therefore we need to be more carful here.
> >>>
> >>> After a change of topology, OSPF executes the procedure d= escribed in
> >>> Section 4.5.2 of RFC 5340 (Section 13.3 of RFC 2328).=C2= =A0 At this
> >>> point, a potentially unbounded number of LSAs are flooded= out every
> >>> active interface (point 5 in Section 13.3 of RFC 2328).= =C2=A0 This
> >>> flooding is not regulated by any timer -- all that the pr= otocol says
> >>> is that the LSAs must go out through a certain subset of = the router's
> interfaces.
> >>>
> >>> I could be wrong, but I am fairly confident that nothing = in RFCs
> >>> 5340 and
> >>> 2328 specifies congestion control, flow control or packet= pacing for
> >>> this flooding procedure.=C2=A0 My interpretation is that = since OSPF is
> >>> designed to be deployed on local links, congestion caused= by OSPF is
> >>> not likely to endanger the Global Internet, and therefore= packet
> >>> pacing (if required) is left to the implementation.
> >>>
> >>> I also don't recall any discussion of flow control in= Moy's and
> >>> Gredler's books, but they have a lot of pages (especi= ally
> >>> Gredler's), so, again, I could be wrong.
> >>>
> >>> Where you are right, Mirja, is that packet pacing is a ve= ry
> >>> difficult problem in OSPF, where incorrectly delaying flo= oding could
> >>> lead to microloops; since Babel has a loop-avoidance mech= anism
> >>> built-in, it can safely perform packet pacing should the = need to do
> >>> so be demonstrated in a particular topology.
> >>>
> >>> In summary, while I agree that packet pacing for Babel wo= uld be an
> >>> interesting research project, I maintain that by requirin= g packet
> >>> pacing as a condition for publication as PS, you are requ= iring an
> >>> unreasonably high standard, certainly a standard that nei= ther OSPF
> >>> nor IS-
> >> IS are held to.
> >>>
> >>>>> Appendix B gives values that are suggested for im= plementations.
> >>>
> >>>> Yes but it doesn=E2=80=99t discuss for with _deployme= nt_ scenarios these
> >>>> values are suitable.
> >>>
> >>> As far as I am aware, all current production deployments = use the
> >>> first set of constants.=C2=A0 The one exception is an exp= erimental
> >>> testbed used for mobility research, that uses the (more a= ggressive)
> >>> second set of
> >> constants.
> >>>
> >>>> Did you deploy the same parameters in all of the disc= ussed scenarios.
> >>>
> >>> Yes.
> >>>
> >>>> Does it actually makes sense to use the same paramete= rs in a "small
> >>>> unmanaged network" as well as in a "large o= verlay network"?
> >>>
> >>> Yes.
> >>>
> >>>> Is that network connected to the Internet or not?
> >>>
> >>> Yes, but that's irrelevant -- the Babel traffic is li= nk-local, and
> >>> does not go outside the local routing domain.
> >>>
> >>> -- Juliusz
> >>>
> >>
> >> _______________________________________________
> >> babel mailing list
> >> babel@iet= f.org
> >> https://urldefense.proofpoint.com/v= 2/url?u=3Dhttps-
> >> 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwIGaQ&c= =3DLFYZ-
> >> o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DlAFv= sU0_OPDy-
> >> ZlHIv5uBPdk4vfANIDrA952AjkA108&s=3DQurFvW6x5-
> >> cd6JNZ65cpchYuXzKb2bfPfMXOfIeCT5g&e=3D

--0000000000006b696e059b82071a-- From nobody Tue Jan 7 03:50:10 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9A9120026; Tue, 7 Jan 2020 03:50:08 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLfc9o6zQero; Tue, 7 Jan 2020 03:50:06 -0800 (PST) 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 E482A120089; Tue, 7 Jan 2020 03:50:05 -0800 (PST) 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/82085) with ESMTP id 007BnwVZ020633; Tue, 7 Jan 2020 12:49:58 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B0052C51AA; Tue, 7 Jan 2020 12:50:00 +0100 (CET) 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 sDrGZD8bF0w6; Tue, 7 Jan 2020 12:49:59 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 23E99C51A5; Tue, 7 Jan 2020 12:49:59 +0100 (CET) Date: Tue, 07 Jan 2020 12:49:59 +0100 Message-ID: <87sgkrtriw.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: "STARK, BARBARA H" , "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux In-Reply-To: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 07 Jan 2020 12:49:58 +0100 (CET) X-Miltered: at korolev with ID 5E147066.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E147066.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 : 5E147066.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: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 11:50:08 -0000 Dear Mirja, You made the very same proposition on 22 August 2019 (almost half a year ago!). Here is what I replied at the time: I am sorry, but I disagree. The original document that I submitted for IETF review back in 2009 had the structure that you suggest, but the reviewer (Joel Halpern) convinced me to a adopt the following structure: - the body of the document describes the main algorithm, the parts that are required to enforce the strong guarantees that the protocol makes about lack of loops and forward progress; - the appendices describe algorithms that have been shown to be useful over some link layers but that might need to be tweaked when Babel is run over new, exciting link layers. Since Joel did a good job convincing me, it will take some work to convince me otherwise. -- Juliusz From nobody Tue Jan 7 04:38:37 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A6E1200C5; Tue, 7 Jan 2020 04:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86Gig4KO7Cv7; Tue, 7 Jan 2020 04:38:33 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 EB021120044; Tue, 7 Jan 2020 04:38:32 -0800 (PST) Received: from 200116b82c063500e5b05a6044f6d04d.dip.versatel-1u1.de ([2001:16b8:2c06:3500:e5b0:5a60:44f6:d04d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ioo7t-0002Fy-QZ; Tue, 07 Jan 2020 13:38:25 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87sgkrtriw.wl-jch@irif.fr> Date: Tue, 7 Jan 2020 13:38:25 +0100 Cc: "STARK, BARBARA H" , "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux Content-Transfer-Encoding: quoted-printable Message-Id: <89E87F97-51B6-4F46-B8A8-380B513F8B9A@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578400713;f32f571a; X-HE-SMSGID: 1ioo7t-0002Fy-QZ Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 12:38:36 -0000 Hi Juliusz, I did reply to this message a while ago. I think this is a fine approach for algorithms (as you say below) = however it is not useful for recommended parameters of an algorithm that = is the define in the body of of the spec. Also note that my point is not about interoperability but about safety. = Often these kind of requirements are not enforceable by the protocol = itself, so an implementator could diverge from the recommendation = without breaking the protocol, however, it is still important to give = the right recommendation in the spec. We all know that just writing a = MUST or SHOULD in an RFC that will not automatically mean that is always = done that way, however, that doesn=E2=80=99t mean that we don=E2=80=99t = have to write it down. Mirja > On 7. Jan 2020, at 12:49, Juliusz Chroboczek wrote: >=20 > Dear Mirja, >=20 > You made the very same proposition on 22 August 2019 (almost half a = year ago!). > Here is what I replied at the time: >=20 > I am sorry, but I disagree. The original document that I submitted = for > IETF review back in 2009 had the structure that you suggest, but = the > reviewer (Joel Halpern) convinced me to a adopt the following = structure: >=20 > - the body of the document describes the main algorithm, the = parts that > are required to enforce the strong guarantees that the protocol = makes > about lack of loops and forward progress; > - the appendices describe algorithms that have been shown to be = useful > over some link layers but that might need to be tweaked when = Babel is > run over new, exciting link layers. >=20 > Since Joel did a good job convincing me, it will take some work to > convince me otherwise. >=20 > -- Juliusz >=20 From nobody Tue Jan 7 10:13:48 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE65120862; Tue, 7 Jan 2020 10:13:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <157842081938.20980.13084913997319474604@ietfa.amsl.com> Date: Tue, 07 Jan 2020 10:13:39 -0800 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-yang-model-05.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 18:13:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : YANG Data Model for Babel Authors : Mahesh Jethanandani Barbara Stark Filename : draft-ietf-babel-yang-model-05.txt Pages : 38 Date : 2020-01-07 Abstract: This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-yang-model-05 https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-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 Tue Jan 7 11:17:10 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1561202DD; Tue, 7 Jan 2020 11:17:02 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRf941m86Jey; Tue, 7 Jan 2020 11:17:01 -0800 (PST) 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 D5AEB12025D; Tue, 7 Jan 2020 11:17:00 -0800 (PST) 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/82085) with ESMTP id 007JGqG4002774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Jan 2020 20:16:52 +0100 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/82085) with ESMTP id 007JGo71006504; Tue, 7 Jan 2020 20:16:50 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 504BCCD602; Tue, 7 Jan 2020 20:16:54 +0100 (CET) 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 zuJcAXIWVCmp; Tue, 7 Jan 2020 20:16:53 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E882FCD600; Tue, 7 Jan 2020 20:16:51 +0100 (CET) Date: Tue, 07 Jan 2020 20:16:51 +0100 Message-ID: <87o8vf2i1o.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: "STARK, BARBARA H" , "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux In-Reply-To: <89E87F97-51B6-4F46-B8A8-380B513F8B9A@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <89E87F97-51B6-4F46-B8A8-380B513F8B9A@kuehlewind.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 07 Jan 2020 20:16:53 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 07 Jan 2020 20:16:51 +0100 (CET) X-Miltered: at korolev with ID 5E14D924.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5E14D922.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E14D924.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5E14D922.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 : 5E14D924.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5E14D922.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: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:17:03 -0000 > Also note that my point is not about interoperability but about safety. I'm confused. Interoperability is about different implementations interoperating without endangering the integrity of the network. What definition of safety do you propose that is not covered by that? In short -- what technical problem do you want us to solve that you have witnessed with the three existing interoperable implementations of Babel, or that you foresee with a future implementation? -- Juliusz From nobody Tue Jan 7 11:55:10 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DCB120113 for ; Tue, 7 Jan 2020 11:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZETlorM8gfF for ; Tue, 7 Jan 2020 11:55:06 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 95D6C12010E for ; Tue, 7 Jan 2020 11:55:06 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id t2so899862wrr.1 for ; Tue, 07 Jan 2020 11:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r1cOypE+y6ISgleL+0tmcK6OFEJGVWXKe+zAiWAhyBE=; b=OcYfPghfH/LC8d2X7DvVsdDSgYGbP7HFZ7fzwyfJjNA4rIcncPdBdXQURc1fT2MqxG 0gE0mBrMTG/EQuOxDWJrGdHIQdLKLXJfquDQutba9qMSyi3j9BVPkvS5Jc/OfBFYlkj2 mfJKInL/b+raG9gps4eSnNUR2pJPgzCRqebFRbCCObhxG0SO2fDM9VSNhJn6/ya2/s6C 7yqEH4Sl0Sg19DFI31v6CYbkrrFxkYOoBMucdN411kwvbSKwMVif+CZFRL4bXdA3DI64 J8nntBkCdBSVOz0bU0EdZmbzjrmLNOlFU9wHaT+g46W6kwwS5th92kJAliRo5O2E78Tt UsUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r1cOypE+y6ISgleL+0tmcK6OFEJGVWXKe+zAiWAhyBE=; b=H6v8ZY3WMMEuGhS8OaRk2sM0GUYa1iGiJ+d772tXnhQjS0TE2uZGBerVhku+oMdizN tonrbhLJQGcnRJHTQF6WlOO4Qrw3E5cI0wiBkuh1wJJU5IjAx+X1awgoGAKlWjPOHHvZ BWcQ7zYSyqn8eQmiryG6lbDL3wins6ZIinv2fFxEO/IETSQdNh4HDTIKgs7mi8Q6hF5d VYvDxVCtjDwUXRY3xdgUMAb6juzI/jsXNzDkOIlfLV8AhzqN9xatJh70B407ypbktCgC FWnSWdlk0dRFwCLwe+cHucluNcHsBUaDQCVRGQbiV/LiIePRGsYaiVGQaq8Z2zEGJElU naYQ== X-Gm-Message-State: APjAAAVJzO0YBLbzymrfzKmIVea5F1R1jF1XCpR93rjKB4VwkmBOW8Ce TrUum9FW6EHh1FzrANBOi5mG/Q== X-Google-Smtp-Source: APXvYqzm/klhRwNoh/wqDbnyn/8Z7EGosf9uX5lazg1H7lYwi1Br3KbOSiXuy3PoHu+O9dNCGGSdlA== X-Received: by 2002:a5d:6441:: with SMTP id d1mr759975wrw.93.1578426904660; Tue, 07 Jan 2020 11:55:04 -0800 (PST) Received: from [192.168.178.19] (82-74-82-139.cable.dynamic.v4.ziggo.nl. [82.74.82.139]) by smtp.gmail.com with ESMTPSA id n8sm1163512wrx.42.2020.01.07.11.55.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 11:55:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Teco Boot In-Reply-To: <87sgkrtriw.wl-jch@irif.fr> Date: Tue, 7 Jan 2020 20:55:02 +0100 Cc: "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" Content-Transfer-Encoding: quoted-printable Message-Id: <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> To: Juliusz Chroboczek , Mirja Kuehlewind X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:55:10 -0000 Agreed. This is in line with for example the OSPF RFCs. But for unmanaged networks, good advice from an authority is almost = mandatory. For Homenets, this could be draft-ietf-homenet-babel-profile. Teco PS. I don=E2=80=99t take the IETF suggested timers for modern LANs that = serious... > Op 7 jan. 2020, om 12:49 heeft Juliusz Chroboczek het = volgende geschreven: >=20 > Dear Mirja, >=20 > You made the very same proposition on 22 August 2019 (almost half a = year ago!). > Here is what I replied at the time: >=20 > I am sorry, but I disagree. The original document that I submitted = for > IETF review back in 2009 had the structure that you suggest, but = the > reviewer (Joel Halpern) convinced me to a adopt the following = structure: >=20 > - the body of the document describes the main algorithm, the = parts that > are required to enforce the strong guarantees that the protocol = makes > about lack of loops and forward progress; > - the appendices describe algorithms that have been shown to be = useful > over some link layers but that might need to be tweaked when = Babel is > run over new, exciting link layers. >=20 > Since Joel did a good job convincing me, it will take some work to > convince me otherwise. >=20 > -- Juliusz >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Jan 7 12:34:11 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D77E1200D7; Tue, 7 Jan 2020 12:34:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, martin.vigoureux@nokia.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157842924731.20872.3087417505396296893.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 12:34:07 -0800 Archived-At: Subject: [babel] babel - New Meeting Session Request for IETF 107 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 20:34:08 -0000 A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 21 Conflicts to Avoid: Chair Conflict: bess idr rtgwg nvo3 Technology Overlap: homenet manet rtgarea lpwan Key Participant Conflict: netconf netmod People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jan 7 16:26:28 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2251120020; Tue, 7 Jan 2020 16:26:25 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDrQ50E9OtsC; Tue, 7 Jan 2020 16:26:24 -0800 (PST) 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 B0668120018; Tue, 7 Jan 2020 16:26:23 -0800 (PST) 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/82085) with ESMTP id 0080QEx6019849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Jan 2020 01:26:14 +0100 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/82085) with ESMTP id 0080QDpN001500; Wed, 8 Jan 2020 01:26:13 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 17AF4CF89C; Wed, 8 Jan 2020 01:26:17 +0100 (CET) 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 83frNfZMk-i2; Wed, 8 Jan 2020 01:26:15 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 55499CF89A; Wed, 8 Jan 2020 01:26:14 +0100 (CET) Date: Wed, 08 Jan 2020 01:26:14 +0100 Message-ID: <87tv56x07t.wl-jch@irif.fr> From: Juliusz Chroboczek To: Teco Boot Cc: Mirja Kuehlewind , "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" In-Reply-To: <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 08 Jan 2020 01:26:15 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 08 Jan 2020 01:26:13 +0100 (CET) X-Miltered: at korolev with ID 5E1521A6.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5E1521A5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E1521A6.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5E1521A5.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 : 5E1521A6.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5E1521A5.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: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:26:26 -0000 Hi Teco, > This is in line with for example the OSPF RFCs. > But for unmanaged networks, good advice from an authority is almost mandatory. The advice is already there, it's in Appendix B, and it's referenced at all the relevant points in the document. However, Babel is designed so that the exact values don't matter, so it's merely advice, not a recommendation. That the exact values don't matter is the whole point of Babel -- it's designed to interoperate in the presence of asymmetric configuration, which is why it's useful in community and unmanaged networks. If we start recommending a default set of values, we obfuscate this fact, at which point we're no longer communicating clearly why Babel might, in some deployments, be a good alternative to OSPF. I've repeatedly explained this back in August, but apparently wasn't clear enough. > For Homenets, this could be draft-ietf-homenet-babel-profile. Homenet-babel-profile goes further than that -- it defines the set of extensions required in order to implement Homenet routing (MUST IPv6, SHOULD IPv4, MUST source-specific routing), and it defines the interactions between HNCP and Babel. -- Juliusz From nobody Tue Jan 7 22:53:15 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1E212004A for ; Tue, 7 Jan 2020 22:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppo_TWblDQx0 for ; Tue, 7 Jan 2020 22:53:05 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 F0A82120043 for ; Tue, 7 Jan 2020 22:53:04 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id w1so2171596ljh.5 for ; Tue, 07 Jan 2020 22:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=43taIYBMlnT8gzfVGog+teb1kx1j3l362t6gvvF24MU=; b=Hd+vrtcbIlOmCCP0mfKrKV23UrZULygFy4zbPryN1LR2CBdjtvRPD95YGG8mKHtCu5 VpiuSBRumlReKZSnfCFCSzIRC/jAX+EzD8oMnMz6OJJRdvQ5oYLQy+ajGQ9UX/V/lrvk RJTSSGzzOhWs9WDP+c08ki1G0As6bI2NkRebqnqVIcFAd/Bl4ndQUPINRWt/VHPUP4U/ Iu0Aw6fzUZRgrrL4bqIHAeq5ZDAOj1dqnNpThl/z5gzFqwGyw9f3DBMaFXhavLkKpwGi tvXjrgeahY34AiCaJAbyqb+Pk5cONBMIMaGC37b1IIG2aDZwVb/6FLYuOWEtttc9YhPu UkWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=43taIYBMlnT8gzfVGog+teb1kx1j3l362t6gvvF24MU=; b=bhZwU/ScICEV+yVRgl/u+BU6GU/6nDb75RoimB8X8HtxCjJP5OuHCQys442dBhF0Ry Bd2wTcaQwa4vrOaYKfNcfKEJStnZJ/JA00nuzgR3xANBqiQLkZztevI+hWdSKkgD70ab oWCNLFBf9WaYiF2IaAr37gbLiaMk1r/GfK6jjiZ7/z/6ycuxSMdb7h98SEJtQqksgNKa ZnuV5HCRQVXLSZmS8E1kH4/E0+oEmgljDl1TGJwvvtlAMX9lJUf7mcAY5OsY3scw0fcl 4jWV3Ghxuna7ZHSt6cqIPwYh+NYP0d03j3kRryfJNrtfJEkWCSeIPZiJNsjhHjII6/mz Buyw== X-Gm-Message-State: APjAAAU/0Oj4r2C4YbX5IS5AsCLdfKzaZ5IPwDq8VKJ+LBEoh4zVo7aM vLSOvfvWjJzfADqgSW8pHbndQQ== X-Google-Smtp-Source: APXvYqweOKEiEOHKjCf2mSNTyOCzvZUQ9RLDmiuDeQSss/xlxeZHnA0aYTysb1Uz7Cj+MEM0/fwJGA== X-Received: by 2002:a2e:8651:: with SMTP id i17mr1928689ljj.121.1578466382755; Tue, 07 Jan 2020 22:53:02 -0800 (PST) Received: from [10.87.0.51] ([145.15.244.17]) by smtp.gmail.com with ESMTPSA id t1sm728538lji.98.2020.01.07.22.52.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 22:53:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Teco Boot In-Reply-To: <87tv56x07t.wl-jch@irif.fr> Date: Wed, 8 Jan 2020 07:52:54 +0100 Cc: Mirja Kuehlewind , "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" Content-Transfer-Encoding: quoted-printable Message-Id: <06AA3BD8-391A-4B38-A40A-1896DFC4D836@inf-net.nl> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> <87tv56x07t.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 06:53:08 -0000 > Op 8 jan. 2020, om 01:26 heeft Juliusz Chroboczek het = volgende geschreven: >=20 > Hi Teco, >=20 >> This is in line with for example the OSPF RFCs. >> But for unmanaged networks, good advice from an authority is almost = mandatory. >=20 > The advice is already there, it's in Appendix B, and it's referenced = at > all the relevant points in the document. However, Babel is designed = so > that the exact values don't matter, so it's merely advice, not a = recommendation. >=20 > That the exact values don't matter is the whole point of Babel -- it's > designed to interoperate in the presence of asymmetric configuration, > which is why it's useful in community and unmanaged networks. If we = start > recommending a default set of values, we obfuscate this fact, at which > point we're no longer communicating clearly why Babel might, in some > deployments, be a good alternative to OSPF. >=20 > I've repeatedly explained this back in August, but apparently wasn't = clear > enough. I know and I agree. So please try to finish this work. >> For Homenets, this could be draft-ietf-homenet-babel-profile. >=20 > Homenet-babel-profile goes further than that -- it defines the set of > extensions required in order to implement Homenet routing (MUST IPv6, > SHOULD IPv4, MUST source-specific routing), and it defines the > interactions between HNCP and Babel. There is nothing on timers. OK, the rfc6126bis suggested timers make = sense.=20 But how can a homenet device vendor know to select one of the use cases?=20= I also think the guidance for link costs for homenets has too much = freedom. IMHO, for Homenets, all of this needs strict rules. But this is out of topic here. I only wanted to suggest that there are other and better places to = define the protocol=20 parameters. This could help to close this discussion. =20 Teco > -- Juliusz From nobody Wed Jan 8 01:54:55 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1CD1200D5; Wed, 8 Jan 2020 01:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwFUIsV9Npgv; Wed, 8 Jan 2020 01:54:47 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 3995D12006D; Wed, 8 Jan 2020 01:54:47 -0800 (PST) Received: from 200116b82ce1a4005104981634920ee5.dip.versatel-1u1.de ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ip82x-0000Er-Ho; Wed, 08 Jan 2020 10:54:39 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <06AA3BD8-391A-4B38-A40A-1896DFC4D836@inf-net.nl> Date: Wed, 8 Jan 2020 10:54:38 +0100 Cc: "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" , Teco Boot Content-Transfer-Encoding: quoted-printable Message-Id: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> <87tv56x07t.wl-jch@irif.fr> <06AA3BD8-391A-4B38-A40A-1896DFC4D836@inf-net.nl> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578477287;26cb9eca; X-HE-SMSGID: 1ip82x-0000Er-Ho Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 09:54:49 -0000 Hi Juliusz, Just recommending default value doesn=E2=80=99t mean that anybody has to = use the same values and it still conserves the benefits that babel works = with a brought set of values. However, you already said that all = deployed implementation use the same set of values, so what=E2=80=99s = the point of not recommending these? You made several times the point that babel is based on implementation = and testing. Given all deployed implementations use the same values that = actually is the only set that is really tested and therefore the only = one that should be recommended. You said: "Interoperability is about different implementations interoperating = without endangering the integrity of the network.=E2=80=9D The smaller the time interval are that you use, the higher is the load = on the network. That means certain configuration would endanger the = integrity of the network if the network capacity is below the load that = is generated by the updates and hello.=20 This is not discussed in appendix B. Appendix B only talks about e.g. = "networks with little mobility, and where occasional outages of up to 14 = seconds are acceptable=E2=80=9D but it doesn=E2=80=99t say anything = about load. The effect of the chosen configuration on the network = load/integrity needs further discussion and it needs this discussion in = the body of the spec and not only in the appendix with relation to the = concrete parameter values or a certain range of values. Mirja > On 8. Jan 2020, at 07:52, Teco Boot wrote: >=20 >=20 >=20 >> Op 8 jan. 2020, om 01:26 heeft Juliusz Chroboczek het = volgende geschreven: >>=20 >> Hi Teco, >>=20 >>> This is in line with for example the OSPF RFCs. >>> But for unmanaged networks, good advice from an authority is almost = mandatory. >>=20 >> The advice is already there, it's in Appendix B, and it's referenced = at >> all the relevant points in the document. However, Babel is designed = so >> that the exact values don't matter, so it's merely advice, not a = recommendation. >>=20 >> That the exact values don't matter is the whole point of Babel -- = it's >> designed to interoperate in the presence of asymmetric configuration, >> which is why it's useful in community and unmanaged networks. If we = start >> recommending a default set of values, we obfuscate this fact, at = which >> point we're no longer communicating clearly why Babel might, in some >> deployments, be a good alternative to OSPF. >>=20 >> I've repeatedly explained this back in August, but apparently wasn't = clear >> enough. >=20 > I know and I agree. > So please try to finish this work. >=20 >=20 >>> For Homenets, this could be draft-ietf-homenet-babel-profile. >>=20 >> Homenet-babel-profile goes further than that -- it defines the set of >> extensions required in order to implement Homenet routing (MUST IPv6, >> SHOULD IPv4, MUST source-specific routing), and it defines the >> interactions between HNCP and Babel. >=20 > There is nothing on timers. OK, the rfc6126bis suggested timers make = sense.=20 > But how can a homenet device vendor know to select one of the use = cases?=20 > I also think the guidance for link costs for homenets has too much = freedom. > IMHO, for Homenets, all of this needs strict rules. > But this is out of topic here. >=20 > I only wanted to suggest that there are other and better places to = define the protocol=20 > parameters. This could help to close this discussion. >=20 >=20 > Teco >=20 >=20 >> -- Juliusz >=20 >=20 From nobody Wed Jan 8 07:15:46 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8A3120127; Wed, 8 Jan 2020 07:15:45 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT7vldaBxLLf; Wed, 8 Jan 2020 07:15:43 -0800 (PST) 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 5763D120120; Wed, 8 Jan 2020 07:15:42 -0800 (PST) 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/82085) with ESMTP id 008FFa5B007892; Wed, 8 Jan 2020 16:15:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D8F4AB9529; Wed, 8 Jan 2020 16:15:38 +0100 (CET) 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 1X8LdcDVpmoh; Wed, 8 Jan 2020 16:15:37 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 12220B9527; Wed, 8 Jan 2020 16:15:37 +0100 (CET) Date: Wed, 08 Jan 2020 16:15:36 +0100 Message-ID: <87v9pmx9lz.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: "draft-ietf-babel-rfc6126bis@ietf.org" , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" , Teco Boot In-Reply-To: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> <87tv56x07t.wl-jch@irif.fr> <06AA3BD8-391A-4B38-A40A-1896DFC4D836@inf-net.nl> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 08 Jan 2020 16:15:36 +0100 (CET) X-Miltered: at korolev with ID 5E15F218.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E15F218.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 : 5E15F218.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: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 15:15:45 -0000 > The smaller the time interval are that you use, the higher is the load > on the network. That means certain configuration would endanger the > integrity of the network if the network capacity is below the load that > is generated by the updates and hello. Mirja -- this is not a transport-layer protocol that is deployed over a heterogeneous Internet; it's a signalling protocol that is deployed over the local link. Since there are no intermediate routers to congest, congestion control issues are very different from what you are used to. The amount of signalling traffic that a Babel node generates is minuscule, on the order of a few hundred bytes per second, a few kB/s in large networks. Since there are no intermediate routers to congest, the only limiting factor is the speed of the local link. > This is not discussed in appendix B. Neither does RFC 5340. There is no concensus whether congestion control for link-local signalling protocols is a real issue. If you believe that it is an issue, then I encourage you to create a WG to deal with the issue in a general manner, one that applies to OSPF, IS-IS, Babel and even DHCPv6 and ND. (I know at least one person who thinks like you, and would probably be interested in participating; I, for one, would be interested in reviewing any documents you produce.) Requiring us to solve this (real or imagined) problem within the Babel WG is not reasonable, just as it would not be reasonable to request that it be solved within the OSPF WG. -- Juliusz From nobody Wed Jan 8 07:30:50 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373B412016E; Wed, 8 Jan 2020 07:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce17rK_aKdal; Wed, 8 Jan 2020 07:30:42 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 4071C12013D; Wed, 8 Jan 2020 07:30:42 -0800 (PST) Received: from 200116b82ce1a4005104981634920ee5.dip.versatel-1u1.de ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipDI5-0002Mq-3Z; Wed, 08 Jan 2020 16:30:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87v9pmx9lz.wl-jch@irif.fr> Date: Wed, 8 Jan 2020 16:30:36 +0100 Cc: "draft-ietf-babel-rfc6126bis@ietf.org" , Teco Boot , Babel at IETF , Alvaro Retana , The IESG , "STARK, BARBARA H" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> <87tv56x07t.wl-jch@irif.fr> <06AA3BD8-391A-4B38-A40A-1896DFC4D836@inf-net.nl> <87v9pmx9lz.wl-jch@irif.fr> To: Juliusz Chroboczek , Martin Vigoureux X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578497442;51cbe9e9; X-HE-SMSGID: 1ipDI5-0002Mq-3Z Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 15:30:45 -0000 Hi Juliusz, This is not about congestion control. Congestion control is something = that has a control loop and is based on feedback. This is not possible = and not required here. However, limiting the total load a protocol can = induce on a network is a common safety mechanism that I usually look for = in all protocols including routing protocols. As explained already e.g = OSPF has a limit because all interval values are in units of seconds, = however, this is not the case here. Even if the communication is link local, overloading that one link and = the respective endpoint (or actually all neighbours) can have an impact = on the network as a whole as this can also push away all other traffic. = Even if the traffic rate generated by the protocol is low, you still = have to make sure that it is lower than the local link capacity. That = seems straight forward to us maybe but still some good advise to give in = the spec. Further if misconfigured it is still possible that the babel traffic = does not stay local. So even for this unlikely error case we must insure = that babel can=E2=80=99t crash the network. I know this seem overly cautious because these are unlikely cases, = however, that=E2=80=99s still makes it important to discuss them in = proposed standard spec. I don=E2=80=99t really understand the whole discussion here to be honest = because I actually don=E2=80=99t ask for much. Why is it such a problem = to recommend the one value set that you have tested and works well for = all scenarios? Again, of course that doesn=E2=80=99t mean that all = implementations have to use this and that was never what I asked for. = And why do you think it is a problem to add more text in the spec that = explains better the network impact of choosing these value, e.g. like = calculating the load that is expected by the choice of certain value? I don=E2=80=99t think we will make any progress here, as I have the = feeling you are just unwilling to make any further changes to the = document, and would like to ask Martin as the responsible AD to = intervene and provide further guidance to both of us! Mirja > On 8. Jan 2020, at 16:15, Juliusz Chroboczek wrote: >=20 >> The smaller the time interval are that you use, the higher is the = load >> on the network. That means certain configuration would endanger the >> integrity of the network if the network capacity is below the load = that >> is generated by the updates and hello. >=20 > Mirja -- this is not a transport-layer protocol that is deployed over > a heterogeneous Internet; it's a signalling protocol that is deployed = over > the local link. Since there are no intermediate routers to congest, > congestion control issues are very different from what you are used = to. >=20 > The amount of signalling traffic that a Babel node generates is = minuscule, > on the order of a few hundred bytes per second, a few kB/s in large > networks. Since there are no intermediate routers to congest, the = only > limiting factor is the speed of the local link. >=20 >> This is not discussed in appendix B. >=20 > Neither does RFC 5340. >=20 > There is no concensus whether congestion control for link-local = signalling > protocols is a real issue. If you believe that it is an issue, then > I encourage you to create a WG to deal with the issue in a general = manner, > one that applies to OSPF, IS-IS, Babel and even DHCPv6 and ND. (I = know at > least one person who thinks like you, and would probably be interested = in > participating; I, for one, would be interested in reviewing any = documents > you produce.) >=20 > Requiring us to solve this (real or imagined) problem within the Babel = WG > is not reasonable, just as it would not be reasonable to request that = it > be solved within the OSPF WG. >=20 > -- Juliusz >=20 >=20 From nobody Wed Jan 8 09:08:19 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334AC12082F; Wed, 8 Jan 2020 09:08:13 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux1kyy5ehard; Wed, 8 Jan 2020 09:08:12 -0800 (PST) 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 CA84112022A; Wed, 8 Jan 2020 09:08:11 -0800 (PST) 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/82085) with ESMTP id 008H85C1005142; Wed, 8 Jan 2020 18:08:05 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D6630BAEB5; Wed, 8 Jan 2020 18:08:07 +0100 (CET) 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 Z04e2oDl5yVM; Wed, 8 Jan 2020 18:08:06 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 48F5BBAEB3; Wed, 8 Jan 2020 18:08:06 +0100 (CET) Date: Wed, 08 Jan 2020 18:08:06 +0100 Message-ID: <87k161yiyx.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: Martin Vigoureux , "draft-ietf-babel-rfc6126bis@ietf.org" , Teco Boot , Babel at IETF , Alvaro Retana , The IESG , "STARK, BARBARA H" In-Reply-To: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> <87tv56x07t.wl-jch@irif.fr> <06AA3BD8-391A-4B38-A40A-1896DFC4D836@inf-net.nl> <87v9pmx9lz.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 08 Jan 2020 18:08:05 +0100 (CET) X-Miltered: at korolev with ID 5E160C75.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E160C75.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 : 5E160C75.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: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 17:08:13 -0000 > As explained already e.g OSPF has a limit because all interval values > are in units of seconds, however, this is not the case here. I refer you to my mail of 17 December 2019 where I explain why this is not the case. > I have the feeling you are just unwilling to make any further changes to > the document, Over the last six months, Mirja, I have made dozens of changes, many of which I don't feel improve the text at all. What I'm unwilling to do is to break the structure of the document in order to adress a problem that is purely hypothetical, and with no commitment that you will actually clear your objection after I do that. -- Juliusz From nobody Wed Jan 8 09:13:15 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971E8120233; Wed, 8 Jan 2020 09:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9cJR06zwzAt; Wed, 8 Jan 2020 09:13:02 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 F1C941208A1; Wed, 8 Jan 2020 09:13:01 -0800 (PST) Received: from 200116b82ce1a4005104981634920ee5.dip.versatel-1u1.de ([2001:16b8:2ce1:a400:5104:9816:3492:ee5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipEt9-0007sS-7M; Wed, 08 Jan 2020 18:12:59 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87k161yiyx.wl-jch@irif.fr> Date: Wed, 8 Jan 2020 18:12:58 +0100 Cc: "draft-ietf-babel-rfc6126bis@ietf.org" , Teco Boot , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net> <89C41AAF-B019-4872-9AED-278D6FE7EE0E@kuehlewind.net> <87lfra9a2s.wl-jch@irif.fr> <35766A70-6E3D-4216-B559-811F6B3FB46F@kuehlewind.net> <87r212n59b.wl-jch@irif.fr> <63DE7522-7FFF-49F4-9126-A2C4B66596B4@kuehlewind.net> <2D09D61DDFA73D4C884805CC7865E6115372A0DD@GAALPA1MSGUSRBF.ITServices.sbc.com> <87sgkrtriw.wl-jch@irif.fr> <019A54A0-5414-4D3E-8DC3-294CE7F9E774@inf-net.nl> <87tv56x07t.wl-jch@irif.fr> <06AA3BD8-391A-4B38-A40A-1896DFC4D836@inf-net.nl> <87v9pmx9lz.wl-jch@irif.fr> <87k161yiyx.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578503582;99b46785; X-HE-SMSGID: 1ipEt9-0007sS-7M Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 17:13:09 -0000 Hi Juliusz, You didn=E2=80=99t make any concrete proposals for changes that I could = commit to. Mirja > On 8. Jan 2020, at 18:08, Juliusz Chroboczek wrote: >=20 >> As explained already e.g OSPF has a limit because all interval values >> are in units of seconds, however, this is not the case here. >=20 > I refer you to my mail of 17 December 2019 where I explain why this is = not > the case. >=20 >> I have the feeling you are just unwilling to make any further changes = to >> the document, >=20 > Over the last six months, Mirja, I have made dozens of changes, many = of > which I don't feel improve the text at all. >=20 > What I'm unwilling to do is to break the structure of the document in > order to adress a problem that is purely hypothetical, and with no > commitment that you will actually clear your objection after I do = that. >=20 > -- Juliusz >=20 >=20 From nobody Wed Jan 8 09:31:57 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F0120052; Wed, 8 Jan 2020 09:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBdU9puOBk7U; Wed, 8 Jan 2020 09:31:54 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 5151B1208A2; Wed, 8 Jan 2020 09:31:54 -0800 (PST) Received: from ip-109-42-1-106.web.vodafone.de ([109.42.1.106] helo=[100.95.76.202]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ipFBO-0007vC-5c; Wed, 08 Jan 2020 18:31:50 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= Mime-Version: 1.0 (1.0) Date: Wed, 8 Jan 2020 18:31:48 +0100 Message-Id: References: Cc: "draft-ietf-babel-rfc6126bis@ietf.org" , Teco Boot , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" In-Reply-To: To: Juliusz Chroboczek X-Mailer: iPhone Mail (17C54) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1578504714;848e5e04; X-HE-SMSGID: 1ipFBO-0007vC-5c Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 17:31:56 -0000 Hi again, Please also note that changes you already did are good (maybe with the excep= tion of adding the second set of example parameters which we are still discu= ssing here) and they address already part of my discuss.=20 Also note that Alvaro also still has a discuss on the document which is also= related to default parameters. Unfortunately I have the feeling we don=E2=80= =99t make any further progress about this point in the discussion right and w= ould therefore like to rely on Martin as the responsible AD for further advi= se. Mirja=20 > Am 08.01.2020 um 18:13 schrieb Mirja Kuehlewind : >=20 > =EF=BB=BFHi Juliusz, >=20 > You didn=E2=80=99t make any concrete proposals for changes that I could co= mmit to. >=20 > Mirja >=20 >=20 >=20 >>> On 8. Jan 2020, at 18:08, Juliusz Chroboczek wrote: >>>=20 >>> As explained already e.g OSPF has a limit because all interval values >>> are in units of seconds, however, this is not the case here. >>=20 >> I refer you to my mail of 17 December 2019 where I explain why this is no= t >> the case. >>=20 >>> I have the feeling you are just unwilling to make any further changes to= >>> the document, >>=20 >> Over the last six months, Mirja, I have made dozens of changes, many of >> which I don't feel improve the text at all. >>=20 >> What I'm unwilling to do is to break the structure of the document in >> order to adress a problem that is purely hypothetical, and with no >> commitment that you will actually clear your objection after I do that. >>=20 >> -- Juliusz >>=20 >>=20 >=20 >=20 From nobody Wed Jan 8 18:35:34 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF7A1207FD; Wed, 8 Jan 2020 18:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbFoPpMoFK1W; Wed, 8 Jan 2020 18:35:23 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 E66B81208BE; Wed, 8 Jan 2020 18:35:22 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id o13so5494204ljg.4; Wed, 08 Jan 2020 18:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZLS9NlxYjtqMNJRhpYicVOnq7iu0bm/60nr9ni1cX+g=; b=tkfRZEkO6O1q8nMCKSn7Xv38t78ECKuoio5Pvh6dgoQCDSBcP7hgvJt5tDbQJ2dgis DYeJulKFl1UJpsyGS/vjDQDPPonMfqASP/6GnkGBTI+ab8RW7Sl7KGhmgr7QbUPsu2wv 5FrP1fVq728+ULCQ4BvTaXtHvcphzXB9XGDX2Qi3WyCqiY04v2GQHatmsPWKtyAM1HZ5 DQ7KTuNuVlzc0j6uLEgiInPX7YPOr3BdWwR/FTgl81cSt8G+jt0XtLSSlOLVUuAd8IHc w6JorTKlIrYFaJ/ltYDB5fI2sO8oBy4uOtP8foqtFetVcwyPYGmemMioApADYS5wjaJh iVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZLS9NlxYjtqMNJRhpYicVOnq7iu0bm/60nr9ni1cX+g=; b=V/JpZPJngVqhAhZ2oxrA2JnVdB3lV3NzpkW7JX9I8wO6VUnjr61GjsDHpqaxkc22ga Izg//9wJrcy1JaWm/hm8aiAwAbSWnkeu9OnOTxCdOpZ6psWv6wdyxtvssou9H3W8OIXR SDLyvvgcFBCnAAirDMaRe7S5cZK9AnO58VyQd7a88q9vCJN5uSWTh3Ts65PDvdX02X4p PYj2OwjeXcD1bFb4InlcP4w6qrvlpt+ZonCAdDszDkemJxJisMoAl1xnRyxmxUenFDvW ciBPeIG9DvisojxLSoMNKXhQYJ5RlezzOCCVFzVk9x49CcTXkupTNnOQdEH3uPGU00hA o2qw== X-Gm-Message-State: APjAAAWmy6/XWfOGoNA8aLYmGn28YEAJN6xRESX7ijnkLIV0WcCxktb6 qqk2UTqz5P6hJI8v1sPZj5tMQZvL2aHTpU1gjDc= X-Google-Smtp-Source: APXvYqzSY/b+uoEJ46bxAJv3R5ngkvprb1k5fqEljlfdFwY9aq1VpclUUlVGk3XvhvQzJGx8DL/4Y5CliuPvVsS48e0= X-Received: by 2002:a2e:884c:: with SMTP id z12mr4657223ljj.55.1578537321221; Wed, 08 Jan 2020 18:35:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 8 Jan 2020 18:35:10 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= Cc: Juliusz Chroboczek , "draft-ietf-babel-rfc6126bis@ietf.org" , Teco Boot , Babel at IETF , Alvaro Retana , The IESG , Martin Vigoureux , "STARK, BARBARA H" Content-Type: multipart/alternative; boundary="0000000000004bd109059babdcd2" Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 02:35:33 -0000 --0000000000004bd109059babdcd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, Thanks for recognizing that we have addressed parts of your DISCUSS. I think that the document is better as a result. However, that doesn't mean that we will make further changes only because you would prefer the document to be a certain way. If the only remaining part of your DISCUSS is the absence of normative default values, then you have to consider whether delaying the document's approval is the best path forward. Juliusz and I are failing to understand what problem you're trying to solve. I agree that you're asking for something small, but we won't make changes to the document if we don't understand how they make the document better. As discussed earlier in this thread, the issues you describe appear to be unrelated to the routing protocol at hand. Feel free to clarify what singles Babel out for mandatory default values, but please consider that lifting your DISCUSS is also a viable option given that this is a minor point. Thank you, David On Wed, Jan 8, 2020 at 9:31 AM "Mirja K=C3=BChlewind (IETF)" wrote: > Hi again, > > Please also note that changes you already did are good (maybe with the > exception of adding the second set of example parameters which we are sti= ll > discussing here) and they address already part of my discuss. > > Also note that Alvaro also still has a discuss on the document which is > also related to default parameters. Unfortunately I have the feeling we > don=E2=80=99t make any further progress about this point in the discussio= n right > and would therefore like to rely on Martin as the responsible AD for > further advise. > > Mirja > > > > Am 08.01.2020 um 18:13 schrieb Mirja Kuehlewind : > > > > =EF=BB=BFHi Juliusz, > > > > You didn=E2=80=99t make any concrete proposals for changes that I could= commit > to. > > > > Mirja > > > > > > > >>> On 8. Jan 2020, at 18:08, Juliusz Chroboczek wrote: > >>> > >>> As explained already e.g OSPF has a limit because all interval values > >>> are in units of seconds, however, this is not the case here. > >> > >> I refer you to my mail of 17 December 2019 where I explain why this is > not > >> the case. > >> > >>> I have the feeling you are just unwilling to make any further changes > to > >>> the document, > >> > >> Over the last six months, Mirja, I have made dozens of changes, many o= f > >> which I don't feel improve the text at all. > >> > >> What I'm unwilling to do is to break the structure of the document in > >> order to adress a problem that is purely hypothetical, and with no > >> commitment that you will actually clear your objection after I do that= . > >> > >> -- Juliusz > >> > >> > > > > > > --0000000000004bd109059babdcd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Thanks for recognizing that w= e have addressed parts of your DISCUSS. I think that the document is better= as a result. However, that doesn't mean that we will make further chan= ges only because you would prefer the document to be a certain way.

If the only remaining part of your DISCUSS is the absence= of normative default values, then you have to consider whether delaying th= e document's approval is the best path forward.

Juliusz and I are failing to understand what problem you're trying to= solve. I agree that you're asking for something small, but we won'= t make changes to the document if we don't understand how they make the= document better. As discussed earlier in this thread, the issues you descr= ibe appear to be unrelated to the routing protocol at hand.

<= /div>
Feel free to clarify what singles Babel out for mandatory default= values, but please consider that lifting your DISCUSS is also a viable opt= ion given that this is a minor point.

Thank you,
David

On Wed, Jan 8, 2020 at 9:31 AM "Mirja K=C3=BChlewi= nd (IETF)" <ietf@kuehlewind.= net> wrote:
Hi again,

Please also note that changes you already did are good (maybe with the exce= ption of adding the second set of example parameters which we are still dis= cussing here) and they=C2=A0 address already part of my discuss.

Also note that Alvaro also still has a discuss on the document which is als= o related to default parameters. Unfortunately I have the feeling we don=E2= =80=99t make any further progress about this point in the discussion right = and would therefore like to rely on Martin as the responsible AD for furthe= r advise.

Mirja


> Am 08.01.2020 um 18:13 schrieb Mirja Kuehlewind <ietf@kuehlewind.net>:
>
> =EF=BB=BFHi Juliusz,
>
> You didn=E2=80=99t make any concrete proposals for changes that I coul= d commit to.
>
> Mirja
>
>
>
>>> On 8. Jan 2020, at 18:08, Juliusz Chroboczek <jch@irif.fr> wrote:
>>>
>>> As explained already e.g OSPF has a limit because all interval= values
>>> are in units of seconds, however, this is not the case here. >>
>> I refer you to my mail of 17 December 2019 where I explain why thi= s is not
>> the case.
>>
>>> I have the feeling you are just unwilling to make any further = changes to
>>> the document,
>>
>> Over the last six months, Mirja, I have made dozens of changes, ma= ny of
>> which I don't feel improve the text at all.
>>
>> What I'm unwilling to do is to break the structure of the docu= ment in
>> order to adress a problem that is purely hypothetical, and with no=
>> commitment that you will actually clear your objection after I do = that.
>>
>> -- Juliusz
>>
>>
>
>

--0000000000004bd109059babdcd2-- From nobody Wed Jan 15 18:39:08 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD9120882 for ; Wed, 15 Jan 2020 18:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxGNnT7WwQNQ for ; Wed, 15 Jan 2020 18:39:04 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C50E112002F for ; Wed, 15 Jan 2020 18:39:04 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id n11so20097659iom.9 for ; Wed, 15 Jan 2020 18:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Ai1FNpr3n0SHNdTPOSzru8ON0AdHlO7vLnpzvfDJzg=; b=m4auYZh4iwpRf5QdTQStiLMADMIe6wU0ZQDdYVF9aNwysbacU+sKeETYl+6YJS49Py GiiJ++eu64t/0tT50u5M37JtetbMQKFQldiFE0kAjaG2tB2O8NZxAYiMGQefXkY0R9u7 8a56uTNDL+xw5v3ZzRWbLlTqHj3p+tB7kQ39soIoXC8bzB5EEvFwdkok0A2VRjmNzMp7 ZWBBL8PdKrmW9+8qrNAoZTefllQwv4fjjfMZlyVFiyq+q1dJzsT3R8uLtw6M5Yjstfgf S7pyvmp5vNZ0NaWyeac9KnZPAG9Y78y3Jp/9LXCjVhM9L30X9BNqngzKcIjqyM6lox++ qNwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Ai1FNpr3n0SHNdTPOSzru8ON0AdHlO7vLnpzvfDJzg=; b=FNQHRDed5MGa1YznQu4QVATm+Du8q7KkhFF8+H9hXUqXShStshTwBOvHnsp46paGWH Un+z5TubtfH6jCNWpe3wHsRjPmB/Dy3UrWg69YsnNyUSKfS6PseNlfBBH0KV38g7qCbN +F3Uc/saYaY2ZuAvy9r6xgWG+32sveepivV0Djnlr18VDECYNd+6L+pMarCRD3LOdKuI MfOUrBAtKilmJdkuo9QGXiGYYOycOc2eg86xAmX1DcbVVh/2eCE9TEIVEZ5eWnoxw1vc eEGDjozL8HVngUHMTtpgrGmLeS3W1rlrzgo8POtoSA3inhXDiXBe0Wju7iG0GQ7919zv e+Pw== X-Gm-Message-State: APjAAAX2Gl+9lDjpd3TdSU2RBQRFo2iw7j7g4ZQIR5srl8H67tfNFmSc 6BvFyXAJBhhvRNE8ppyfrITouNnJjj6OJNiZbi0= X-Google-Smtp-Source: APXvYqx5+XaNIXhEcs72AuFHOhCKUhIntvEocx33q7tCmpyWTjMCqTLjIDZv7jVQTYhH4ft7JLDgo3CvfUrOJ1NIymw= X-Received: by 2002:a5d:9f05:: with SMTP id q5mr24698285iot.199.1579142344014; Wed, 15 Jan 2020 18:39:04 -0800 (PST) MIME-Version: 1.0 References: <98799C32-6591-475E-B9F3-B6E31D828154@gmail.com> <2D09D61DDFA73D4C884805CC7865E61153729C3E@GAALPA1MSGUSRBF.ITServices.sbc.com> <1149EE36-765D-449B-BF23-A68DFB55E3B2@gmail.com> In-Reply-To: <1149EE36-765D-449B-BF23-A68DFB55E3B2@gmail.com> From: Donald Eastlake Date: Wed, 15 Jan 2020 21:38:52 -0500 Message-ID: To: Mahesh Jethanandani Cc: "STARK, BARBARA H" , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000007701b3059c38ba7d" Archived-At: Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 02:39:06 -0000 --0000000000007701b3059c38ba7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Thanks for posting an update to the Babel YANG draft. Does this includes all the changes you currently think needed? If so, I think we could just do a brief WG Last Call and then proceed to request publication. For people's information, the diff against the previous version is https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-babel-yang-model-05.txt Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Jan 6, 2020 at 2:07 PM Mahesh Jethanandani wrote: > Hi Barbara, > > You bring up a good point. > > Have added feature statements for security, MAC and certificate types, an= d > made the identity statements conditional on the features being declared. > Also beefed up the example to show how the system could be configured for > HMAC-SHA256 MAC algorithm. > > Thanks. > > On Jan 6, 2020, at 6:39 AM, STARK, BARBARA H wrote: > > Hi Mahesh, > In looking over this change, I=E2=80=99m trying to understand how indicat= ing > supported metric computation algorithms (expressed through feature + > identity statements, but no leaf-list) differs from indicating supported > security mechanisms, MAC algorithms, and certificate types (expressed > through identity statements + leaf-list). > > Why would we not use the same approach for all 4 of these? > Barbara > > *From:* babel *On Behalf Of *Mahesh Jethanandani > *Sent:* Friday, January 03, 2020 4:22 PM > *To:* Donald Eastlake > *Cc:* Babel at IETF > *Subject:* Re: [babel] Minor format problem in > draft-ietf-babel-yang-model-04 > > Hi Donald, > > In trying to make the changes you requested, I came across another change > that needs to be pushed. > > The information model suggests that babel-information-obj should maintain > a list of metric-comp-algorithm that are supported by an implementation. > The problem with just keeping a list in YANG is that there is no way to > enforce that the implementation uses only those algorithms. To address th= e > issue we had introduced the concept of features in -04 version of the dra= ft. > > Using the feature statement, the implementation can declare which of the > metric-comp-algorithms it supports, which was the intention of having a > list of those algorithms in the first place. As such, we do not need the > global list anymore, and needs to be removed. I will be adding that chang= e > in the -05 version of the draft. > > If you feel that it requires a short LC to be issued, please feel free to > do so after I post the draft. > > Thanks. > > > On Jan 3, 2020, at 10:32 AM, Donald Eastlake wrote: > > Hi Mahesh, > > You're welcome. My apologies for not noticing it earlier. Can you go ahea= d > and post a revision with this trivial change? > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > Hi Donald, > > Yes, that should be ok. And thanks for catching it. > > > Cheers. > Mahesh Jethanandani > mjethanandani@gmail.com > > > On Jan 2, 2020, at 8:27 PM, Donald Eastlake wrote: > > Hi Mahesh, > > Happy New Year! > > There seems to be a minor format problem in this draft, in particular fou= r > lines, all identical, that are 76 characters long. Lines over 72 characte= rs > are not allowed in Internet Drafts. > > On page 34, page 35, page 36, and page 38 the following line occurs: > > xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel > Is it possible to fold this into something like > xmlns:babel=3D > "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel > or just reduce the indent of those lines? > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > --0000000000007701b3059c38ba7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

Thanks for posting an update= to the Babel YANG draft. Does this includes all the changes you currently = think needed? If so, I think we could just do a brief WG Last Call and then= proceed to request publication.

For people's = information, the diff against the previous version is

Thanks,
Donald
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0= 2386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com

<= /div>
O= n Mon, Jan 6, 2020 at 2:07 PM Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Hi Barbara,

You bring up a good point.
=

Have added feature statements for security, MAC and cer= tificate types, and made the identity statements conditional on the feature= s being declared. Also beefed up the example to show how the system could b= e configured for HMAC-SHA256 MAC algorithm.

Thanks= .

On Jan 6, 2020, at 6:39 AM, ST= ARK, BARBARA H <bs76= 52@att.com> wrote:

Hi M= ahesh,
In looking over this change, I=E2=80=99= m trying to understand how indicating supported metric computation algorith= ms (expressed through feature + identity statements, but no leaf-list) diff= ers from indicating supported security mechanisms, MAC algorithms, and cert= ificate types (expressed through identity statements + leaf-list).
=C2=A0
Why would we not u= se the same approach for all 4 of these?
Barba= ra
=C2=A0
From:=C2=A0babel <babel-bounces@ietf.org>= =C2=A0On Behalf Of=C2=A0Mahesh Jethanandani
<= b>Sent:=C2=A0Friday, January 03, 2020 4:22 PM
To:=C2=A0Donald Eastlake <d3e3e3@gmail.com>
Cc:=C2=A0Babel at IETF <babe= l@ietf.org>
Subject:=C2=A0Re: [babel] Minor f= ormat problem in draft-ietf-babel-yang-model-04
=C2=A0
Hi Donald,<= /div>
=C2=A0
In tryin= g to make the changes you requested, I came across another change that need= s to be pushed.
=C2=A0
The information model suggests that babel-infor= mation-obj should maintain a list of metric-comp-algorithm that are support= ed by an implementation. The problem with just keeping a list in YANG is th= at there is no way to enforce that the implementation uses only those algor= ithms. To address the issue we had introduced the concept of features in -0= 4 version of the draft.
=C2= =A0
Using the feature statement, the imple= mentation can declare which of the metric-comp-algorithms it supports, whic= h was the=C2=A0intention of having a list of those algorithms in the first = place. As such, we do not need the global list anymore, and needs to be rem= oved. I will be adding that change in the -05 version of the draft.<= u>
=C2=A0
If you feel that it requires a short LC to be issued, please feel free= to do so after I post the draft.
= =C2=A0
Thanks.
<= div>


On Jan 3, 2020, at 10:32 AM, Dona= ld Eastlake <d3e3e3@gmail.com> wrote:=
=C2=A0
Hi Mahesh,
=C2=A0
You're welcome. My apologies for not noticing i= t earlier. Can you go ahead and post a revision with this trivial change?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Do= nald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic = Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gm= ail.com
=C2=A0
=C2=A0
On = Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Hi Donald,
=C2=A0
Yes, that should be = ok. And thanks for catching it.
= =C2=A0

Cheers.=

Mahesh Jethanandani


On Jan 2, 2020, a= t 8:27 PM, Donald Eastlake <d3e3e3@gmail.com= > wrote:

Hi Mahesh,

Happy New Year!
There seems to be a minor format problem in this draft, in particular = four lines, all identical, that are 76 characters long. Lines over 72 chara= cters are not allowed in Internet Drafts.

On page 34, page 35, page = 36, and page 38 the following line occurs:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:babel=3D&qu= ot;urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
Is= it possible to fold this into something like
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 xmlns:babel=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 "urn:ietf:params:xml:ns:yang:ietf-babel">bab= el:babel
or just reduce the indent of those lines?

Thanks,
Don= ald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-3= 33-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2= =A0d3e3e3@gmail.com
=C2=A0
Mahesh Jethananda= ni

Mahesh Jethanandani



--0000000000007701b3059c38ba7d-- From nobody Thu Jan 16 09:09:11 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2B51200F9 for ; Thu, 16 Jan 2020 09:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2vaPF7fYiGB for ; Thu, 16 Jan 2020 09:09:04 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 76315120071 for ; Thu, 16 Jan 2020 09:09:04 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id s21so8582135plr.7 for ; Thu, 16 Jan 2020 09:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gxQ/nirg9iN7MfeWmoyHb45baQoLHgeZGsXhjiiP0mg=; b=oJgNToe6ll+URGB89J5xUgtdlfaF1BPoOhHI1DyqVBumyvz5TLjKoEWQWnhIkf7cJF A0Vz6JwS6B1Fiag05dj/R+zq79vlHHhiX/uCMkVhwC5YiVExLdXaLIqD35yg5KN0/Qhp Fj0rmRgAMUdezkD3FXOaWtv/XLp4mHwC14SsAksxwWrHPJ70vzmc8dq51ToGItrUoyYi lLeovYxKVwKMsQ2OFz3qfcKKkVWB/lNjh0qAEgKNw0geN62woNpw0rfWxHInF3himzfG c3ZRi58KPdSWpW2u8cWiq6ukQcgJ6Lb8LNQf4mLgQZ8XRVooMWU2Ix+Ny3DgjT8PEOVa leMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gxQ/nirg9iN7MfeWmoyHb45baQoLHgeZGsXhjiiP0mg=; b=dCjuYYPVddcuUHfb15WF8s0dpJI8HZNLgULSHGy5tdAr8yzFg20SsP+g/91BcGgvbP +uit4eJPvUD0X080aUJ2XPid8rnE1qa2rCZe+Kdev60V6gGFeY8KjUokfk2Yw159OYNn Gfkmhwq0+3c9lw7KHK17WeyhGD8mgYuNzeZjDny6Sq1zn8MxHBVGMAJzPQkQBRG9dLYR 3X+yawyAZs3cObqDeDjSUwJHIxei70HZU96XGbV09Phv3co/VXQlj1c9co4+tKI9RmuP 0ZIegRIehktw49hviFiP5sThSS3VVUILmsX5n1Hw4CC/8hOgVjxHhCB+B0H4621Hb6hn EUrA== X-Gm-Message-State: APjAAAXiUcioyp9edCeuIvmbp9Je9KwZ9qRTl/BaRK1rxDGaQVoAPxTV 6PvKfqxzlRSIsnkM6ov1fLw= X-Google-Smtp-Source: APXvYqwC4CthUZUtHQBwr/iBvgCn5UDN0a+voA4VHAhcgexCYI3jjNNL4sEr8AFDFU/MjKvdmu/khQ== X-Received: by 2002:a17:90a:a88d:: with SMTP id h13mr98397pjq.48.1579194543852; Thu, 16 Jan 2020 09:09:03 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:e0c6:5b71:3740:4743? ([2601:647:5600:5020:e0c6:5b71:3740:4743]) by smtp.gmail.com with ESMTPSA id r62sm27100265pfc.89.2020.01.16.09.09.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 09:09:02 -0800 (PST) From: Mahesh Jethanandani Message-Id: <4C66C87A-5BC7-49D3-9E88-7EA853483398@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7B027AF1-9426-4B66-82F7-8851A93F9FF1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 16 Jan 2020 09:09:01 -0800 In-Reply-To: Cc: "STARK, BARBARA H" , Babel at IETF To: Donald Eastlake References: <98799C32-6591-475E-B9F3-B6E31D828154@gmail.com> <2D09D61DDFA73D4C884805CC7865E61153729C3E@GAALPA1MSGUSRBF.ITServices.sbc.com> <1149EE36-765D-449B-BF23-A68DFB55E3B2@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Minor format problem in draft-ietf-babel-yang-model-04 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 17:09:09 -0000 --Apple-Mail=_7B027AF1-9426-4B66-82F7-8851A93F9FF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Donald, > On Jan 15, 2020, at 6:38 PM, Donald Eastlake wrote: >=20 > Hi Mahesh, >=20 > Thanks for posting an update to the Babel YANG draft. Does this = includes all the changes you currently think needed? Yes. > If so, I think we could just do a brief WG Last Call and then proceed = to request publication. Okay. Thanks. >=20 > For people's information, the diff against the previous version is > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-babel-yang-model-05.txt= = = >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com >=20 > On Mon, Jan 6, 2020 at 2:07 PM Mahesh Jethanandani = > wrote: > Hi Barbara, >=20 > You bring up a good point. >=20 > Have added feature statements for security, MAC and certificate types, = and made the identity statements conditional on the features being = declared. Also beefed up the example to show how the system could be = configured for HMAC-SHA256 MAC algorithm. >=20 > Thanks. >=20 >> On Jan 6, 2020, at 6:39 AM, STARK, BARBARA H > wrote: >>=20 >> Hi Mahesh, >> In looking over this change, I=E2=80=99m trying to understand how = indicating supported metric computation algorithms (expressed through = feature + identity statements, but no leaf-list) differs from indicating = supported security mechanisms, MAC algorithms, and certificate types = (expressed through identity statements + leaf-list). >> =20 >> Why would we not use the same approach for all 4 of these? >> Barbara >> =20 >> From: babel > = On Behalf Of Mahesh Jethanandani >> Sent: Friday, January 03, 2020 4:22 PM >> To: Donald Eastlake > >> Cc: Babel at IETF > >> Subject: Re: [babel] Minor format problem in = draft-ietf-babel-yang-model-04 >> =20 >> Hi Donald, >> =20 >> In trying to make the changes you requested, I came across another = change that needs to be pushed. >> =20 >> The information model suggests that babel-information-obj should = maintain a list of metric-comp-algorithm that are supported by an = implementation. The problem with just keeping a list in YANG is that = there is no way to enforce that the implementation uses only those = algorithms. To address the issue we had introduced the concept of = features in -04 version of the draft. >> =20 >> Using the feature statement, the implementation can declare which of = the metric-comp-algorithms it supports, which was the intention of = having a list of those algorithms in the first place. As such, we do not = need the global list anymore, and needs to be removed. I will be adding = that change in the -05 version of the draft. >> =20 >> If you feel that it requires a short LC to be issued, please feel = free to do so after I post the draft. >> =20 >> Thanks. >>=20 >>=20 >> On Jan 3, 2020, at 10:32 AM, Donald Eastlake > wrote: >> =20 >> Hi Mahesh, >> =20 >> You're welcome. My apologies for not noticing it earlier. Can you go = ahead and post a revision with this trivial change? >>=20 >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> d3e3e3@gmail.com >> =20 >> =20 >> On Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani = > wrote: >> Hi Donald, >> =20 >> Yes, that should be ok. And thanks for catching it. >> =20 >> Cheers. >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >> On Jan 2, 2020, at 8:27 PM, Donald Eastlake > wrote: >>=20 >> Hi Mahesh, >>=20 >> Happy New Year! >>=20 >> There seems to be a minor format problem in this draft, in particular = four lines, all identical, that are 76 characters long. Lines over 72 = characters are not allowed in Internet Drafts. >>=20 >> On page 34, page 35, page 36, and page 38 the following line occurs: >> = xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel >> Is it possible to fold this into something like >> xmlns:babel=3D >> "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel >> or just reduce the indent of those lines? >>=20 >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> d3e3e3@gmail.com >> =20 >> Mahesh Jethanandani >> mjethanandani@gmail.com > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 --Apple-Mail=_7B027AF1-9426-4B66-82F7-8851A93F9FF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Donald,

On Jan 15, 2020, at 6:38 PM, Donald Eastlake = <d3e3e3@gmail.com> wrote:

Hi Mahesh,

Thanks for posting an update to the Babel YANG draft. Does = this includes all the changes you currently think = needed?

Yes.

= If so, I think we could just do a brief WG Last Call and then proceed to = request publication.

Okay.

Thanks.


For people's = information, the diff against the previous version is
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-babel-yang-mod= el-05.txt

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake = 3rd   +1-508-333-2270 (cell)
 2386 Panoramic = Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


On Mon, Jan 6, 2020 at 2:07 PM Mahesh Jethanandani = <mjethanandani@gmail.com> wrote:
Hi Barbara,

You bring up a good point.

Have added feature = statements for security, MAC and certificate types, and made the = identity statements conditional on the features being declared. Also = beefed up the example to show how the system could be configured for = HMAC-SHA256 MAC algorithm.

Thanks.

On Jan = 6, 2020, at 6:39 AM, STARK, BARBARA H <bs7652@att.com> wrote:

Hi = Mahesh,
In = looking over this change, I=E2=80=99m trying to understand how = indicating supported metric computation algorithms (expressed through = feature + identity statements, but no leaf-list) differs from indicating = supported security mechanisms, MAC algorithms, and certificate types = (expressed through identity statements + leaf-list).
 
Why= would we not use the same approach for all 4 of these?
Barbara
 
From: babel <babel-bounces@ietf.org> On Behalf Of Mahesh = Jethanandani
Sent: Friday, January 03, 2020 4:22 PM
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: Babel at IETF <babel@ietf.org>
Subject: Re: [babel] Minor = format problem in draft-ietf-babel-yang-model-04
 
Hi = Donald,
 
In = trying to make the changes you requested, I came across another change = that needs to be pushed.
 
The = information model suggests that babel-information-obj should maintain a = list of metric-comp-algorithm that are supported by an implementation. = The problem with just keeping a list in YANG is that there is no way to = enforce that the implementation uses only those algorithms. To address = the issue we had introduced the concept of features in -04 version of = the draft.
 
Using = the feature statement, the implementation can declare which of the = metric-comp-algorithms it supports, which was the intention of = having a list of those algorithms in the first place. As such, we do not = need the global list anymore, and needs to be removed. I will be adding = that change in the -05 version of the draft.
 
If = you feel that it requires a short LC to be issued, please feel free to = do so after I post the draft.
 
Thanks.


On = Jan 3, 2020, at 10:32 AM, Donald Eastlake <d3e3e3@gmail.com> wrote:
 
Hi = Mahesh,
 
You're = welcome. My apologies for not noticing it earlier. Can you go ahead and = post a revision with this trivial change?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake = 3rd   +1-508-333-2270 (cell)
 2386 Panoramic = Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
 
 
On = Fri, Jan 3, 2020 at 2:21 AM Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Hi = Donald,
 
Yes, = that should be ok. And thanks for catching it.
 

Cheers.

Mahesh = Jethanandani
mjethanandani@gmail.com


On = Jan 2, 2020, at 8:27 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:

Hi = Mahesh,

Happy New Year!

There seems to be a minor format problem in this draft, in = particular four lines, all identical, that are 76 characters long. Lines = over 72 characters are not allowed in Internet Drafts.

On page 34, page 35, page 36, and page 38 the following line = occurs:
            = xmlns:babel=3D"urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
Is it possible to fold this into something like
            xmlns:babel=3D
                = "urn:ietf:params:xml:ns:yang:ietf-babel">babel:babel
or = just reduce the indent of those lines?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake = 3rd   +1-508-333-2270 (cell)
 2386 Panoramic = Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
 
Mahesh = Jethanandani
mjethanandani@gmail.com
=
Mahesh Jethanandani
mjethanandani@gmail.com




= --Apple-Mail=_7B027AF1-9426-4B66-82F7-8851A93F9FF1-- From nobody Thu Jan 16 09:35:33 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F6112087E; Thu, 16 Jan 2020 09:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29NkKTaSpD12; Thu, 16 Jan 2020 09:35:30 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 23199120071; Thu, 16 Jan 2020 09:35:30 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id n21so22803147ioo.10; Thu, 16 Jan 2020 09:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e/TpM25Z77+RBpVGWid6FdDJS/+gYnL6Bo/xXKDXns4=; b=lrdYR5GfNUa6lZjThv6+HNEXb9NsirN+S9t/LWkC00W6D4ZVxqtFU7ZzMG94lduoPL H7HRDSFWpVDiT1vULyM9ukzXFXdoNIyY/PCoOkGimXGljCcn1Wap7HmIoQXLSePBnRXc d0Zt3Q5+ILAzJsyzM25ymWX+KKv9RguV2f+js5kCJHsbq+2CYGcfTxMUWpQD8y+CNb5m 8scB2axd2Jf/iI/DrXEWux0T9mMLMB0/iQiYFxQSb/qXZuS5UuE9CQL6IRt3hUMI1FAU RVgCrX98RQdoL8sSAwpA9rC90pcT1to/4+3XuZlWI2ES2P38WyvQCc+EWw3+XwDDm3dT lhGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e/TpM25Z77+RBpVGWid6FdDJS/+gYnL6Bo/xXKDXns4=; b=rYmuZhCwayR5ggtT5JcA1zQg1w3Vb7uSpKt3zgbVR3nQ3YceC874z9ZQlZv+xGWJ7N BDSDlmyssZGQHJCbjnoQsyFSJmOBwOu9A7MM1P6l+gVNh42wxyNvgOIJaPCLhMhejIwB DvDVZRKY9yCTsb3aizmamSXDsYT5ss5tcQd/ao7M0s8IOeH6JUU4AamXlWv9QQ7LPLre I0uT4wL9EKqjieN06ZRBGzsZRsCr6/GTpXA8D+m2M8+sjQfaHM2snEbggXM6/9xC2IVv D/LzwwExevvdCQXbCp7gMXhQNAyKYzKLGHH5RS1fYSEM4pjbegqF+7UQY18MUYuKbtAB Cy1Q== X-Gm-Message-State: APjAAAU7V2WCL57Qx1MmtfQ3xNpY33Ku+MiQ3CUQ9mqETiiqXtyauC4Q XRLK5YrWcBclNVqMeB10PwbjnQy/3IrVYGbCovpiQA== X-Google-Smtp-Source: APXvYqzNMHCIdbTziukZGhilDVnfLxY1cHXxQyZWIbDXIWrd+So+KNvI224sP3asx8pCdpJNgePz9wMHY6xIN4RZd50= X-Received: by 2002:a02:aa10:: with SMTP id r16mr30545329jam.48.1579196128494; Thu, 16 Jan 2020 09:35:28 -0800 (PST) MIME-Version: 1.0 References: <157842081951.20980.11629259219646555334.idtracker@ietfa.amsl.com> In-Reply-To: <157842081951.20980.11629259219646555334.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Thu, 16 Jan 2020 12:35:16 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="0000000000004509f4059c4540f8" Archived-At: Subject: [babel] 2nd WG Last Call draft-ietf-babel-yang-model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 17:35:32 -0000 --0000000000004509f4059c4540f8 Content-Type: text/plain; charset="UTF-8" Hi, Due to some changes, I am doing a 2nd WG Last Call on the Babel YANG draft. An earlier version was approved by the WG and these changes are relatively minor (see forwarded message below) and were presented on the mailing list so this will just run for one week, through January 24th and the document will be considered approved unless there are objections. Thanks, Donald (co-chair) =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com ---------- Forwarded message --------- From: Date: Tue, Jan 7, 2020 at 1:13 PM Subject: New Version Notification - draft-ietf-babel-yang-model-05.txt To: Donald Eastlake A new version (-05) has been submitted for draft-ietf-babel-yang-model: https://www.ietf.org/internet-drafts/draft-ietf-babel-yang-model-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-05 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. --0000000000004509f4059c4540f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Due to some changes, I am doing a 2= nd WG Last Call on the Babel YANG draft.

An earlie= r version was approved by the WG and these changes are relatively minor (se= e forwarded message below) and were presented on the mailing list so this w= ill just run for one week, through January 24th and the document will be co= nsidered approved unless there are objections.

=
Thanks,
Donald (co-chair)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donal= d E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Cir= cle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


---------- Forwarded message --= -------
From: <internet-drafts@ietf.org>
Date: Tue, Jan 7, 2020 = at 1:13 PM
Subject: New Version Notification - draft-ietf-babel-yang-mod= el-05.txt
To: Donald Eastlake <d3= e3e3@gmail.com>



A new version (-05) has been submitted for draft-ietf-babel-yang-model:
https://www.ietf.org/internet= -drafts/draft-ietf-babel-yang-model-05.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-= ietf-babel-yang-model/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-babel-yang-model-05

Please note that it may take a couple of minutes from the time of submissio= n
until the diff is available at tools.ietf.org.

IETF Secretariat.

--0000000000004509f4059c4540f8-- From nobody Thu Jan 16 10:45:51 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957A12004A for ; Thu, 16 Jan 2020 10:45:50 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKJ6P1exPTnw for ; Thu, 16 Jan 2020 10:45:44 -0800 (PST) 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 0E7C4120026 for ; Thu, 16 Jan 2020 10:45:43 -0800 (PST) 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/82085) with ESMTP id 00GIjbvu015647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Jan 2020 19:45:37 +0100 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/82085) with ESMTP id 00GIjZXR014222; Thu, 16 Jan 2020 19:45:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8F561AF78D; Thu, 16 Jan 2020 19:45:39 +0100 (CET) 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 zlsYxPAaSCXs; Thu, 16 Jan 2020 19:45:37 +0100 (CET) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D1845AF78B; Thu, 16 Jan 2020 19:45:36 +0100 (CET) Date: Thu, 16 Jan 2020 19:45:36 +0100 Message-ID: <877e1r6y0f.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel-users@lists.alioth.debian.org CC: babel@ietf.org, Barbara Stark User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 16 Jan 2020 19:45:37 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 16 Jan 2020 19:45:36 +0100 (CET) X-Miltered: at korolev with ID 5E20AF51.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5E20AF4F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E20AF51.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5E20AF4F.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 : 5E20AF51.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5E20AF4F.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: Subject: [babel] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 18:45:50 -0000 Dear all, Antonin and I have spent the afternoon looking at his work on MAC rekeying in babeld. His code is available in branch hmac-rekeying of https://github.com/MisterDA/babeld Now... we've got an issue with the information model. Following the information model, Antonin adds the following attribute to keys: key-use sign|verify|both I'm a little puzzled by the purpose of this attribute. What usage scenarios is it useful in? In particular, it does not appear to subsume the sign-only interface attribute, which is useful in incremental deployment scenarios. Thanks, -- Juliusz From nobody Thu Jan 16 12:00:52 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609AC12093A; Thu, 16 Jan 2020 12:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lU2jui7MDU5; Thu, 16 Jan 2020 12:00:38 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 75F57120C4B; Thu, 16 Jan 2020 12:00:38 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id r19so23966499ljg.3; Thu, 16 Jan 2020 12:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Nvvh5CMusTdfdrGriMBl3TwJP9BDJakLMAZv+wz4uw=; b=clYUW8ua2SUExIuDVFcuuqZbl7PHhK0rBHn2WiYu/FblePvQyqpTYM4417Bx656txT XDShLnr0+Lndp2A6fcezBPX+UVLeDMtRdfJfCZf/l9uGUUqjjfkvQsMPQ1ocyKXNXMaD Edi5bmps3fb+iZxRzNeMguTRuHjL3gobGWqa7kcsS47pyPP92vhRYFJUx5cjrRhZOziZ 2ZwcEwk3y3C0KD0+AVVta3hJs41re4n+DSTuR12k4xTZ6RHmNTHAX9dv/x7Q5v9lrU8U j3cpt4itUn+ePt98oZgsfOgQPwPyZtzLVHR2vqJAllqGvFktyRsg72xtw50a0Z6IMhtC whxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Nvvh5CMusTdfdrGriMBl3TwJP9BDJakLMAZv+wz4uw=; b=Lh1BylNNX3cXKNbLDTj/lOFR4qS6kzy9elYAx6cURu7dcwl7IEkXcbYNA7/VKuecFk KwoCMPerOPx/MzQR22woWZkCGGElRBGfPp6ZVOdhQVHXO7I1Dh0qUHGGP7T6Zs+G/BNz /RDaQuorlf6q0M4R+CcAOTE0UwyGoWdfJ8ziYGxH2t3KWhT4i3ShSB8nbLDZid79JSNo 1t2ujgz6/GE1neNz33iQI2wQ5zLix6DHwdRVipO7y1kbIx0p36AXHJP1XC063X2Wor9L Slxqlv8VCPCWp9CNMqe1026PkzmMZ7I8pCR3lVC7E6lGMo8nLFdF8f7EUo8JHuXElRrh Sj9g== X-Gm-Message-State: APjAAAW1Izq6LGgrYLI/uxuOj7PypEzNNEZC1IuW72hkk1iflCA2bGbJ DXzM1waHVzyZjqf0L546/32IPTfpvVi9m5xPbAo= X-Google-Smtp-Source: APXvYqxIvTePs/v6VXqDP2i8P28g86WL1pf81yH51QNcajuQgScqq8Q6RSf17NNn+3I9qvkOx0PC7XReqn3V4cCNsxo= X-Received: by 2002:a2e:884d:: with SMTP id z13mr3516911ljj.116.1579204836767; Thu, 16 Jan 2020 12:00:36 -0800 (PST) MIME-Version: 1.0 References: <157842081951.20980.11629259219646555334.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Thu, 16 Jan 2020 12:00:25 -0800 Message-ID: To: Donald Eastlake Cc: Babel at IETF , babel-chairs Content-Type: multipart/alternative; boundary="00000000000052bb96059c474720" Archived-At: Subject: Re: [babel] 2nd WG Last Call draft-ietf-babel-yang-model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 20:00:51 -0000 --00000000000052bb96059c474720 Content-Type: text/plain; charset="UTF-8" I've reviewed the diff and it looks good to me. David On Thu, Jan 16, 2020 at 9:35 AM Donald Eastlake wrote: > Hi, > > Due to some changes, I am doing a 2nd WG Last Call on the Babel YANG draft. > > An earlier version was approved by the WG and these changes are relatively > minor (see forwarded message below) and were presented on the mailing list > so this will just run for one week, through January 24th and the document > will be considered approved unless there are objections. > > Thanks, > Donald (co-chair) > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > ---------- Forwarded message --------- > From: > Date: Tue, Jan 7, 2020 at 1:13 PM > Subject: New Version Notification - draft-ietf-babel-yang-model-05.txt > To: Donald Eastlake > > > > A new version (-05) has been submitted for draft-ietf-babel-yang-model: > https://www.ietf.org/internet-drafts/draft-ietf-babel-yang-model-05.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-05 > > Please note that it may take a couple of minutes from the time of > submission > until the diff is available at tools.ietf.org. > > IETF Secretariat. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --00000000000052bb96059c474720 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've reviewed the diff and it looks good to me.
David

On Thu, Jan 16, 2020 at 9:35 AM Donald Eastlake <= ;d3e3e3@gmail.com> wrote:
Hi,
Due to some changes, I am doing a 2nd WG Last Call on the= Babel YANG draft.

An earlier version was approved= by the WG and these changes are relatively minor (see forwarded message be= low) and were presented on the mailing list so this will just run for one w= eek, through January 24th and the document will be considered approved unle= ss there are objections.

= Thanks,
Donald (co-chair)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. East= lake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apop= ka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


---------- Forwarded message ---------From: <internet-drafts@ietf.org>
Date: Tue, Jan= 7, 2020 at 1:13 PM
Subject: New Version Notification - draft-ietf-babel= -yang-model-05.txt
To: Donald Eastlake <d3e3e3@gmail.com>



A new version (-05) has been submitted for draft-ietf-babel-yang-model:
https://www.ietf.org/internet= -drafts/draft-ietf-babel-yang-model-05.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-= ietf-babel-yang-model/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-babel-yang-model-05

Please note that it may take a couple of minutes from the time of submissio= n
until the diff is available at tools.ietf.org.

IETF Secretariat.

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--00000000000052bb96059c474720-- From nobody Fri Jan 17 03:27:18 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1412001E for ; Fri, 17 Jan 2020 03:27:17 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RsTQd-1xIH4 for ; Fri, 17 Jan 2020 03:27:12 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 F258C12001B for ; Fri, 17 Jan 2020 03:27:11 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1579260429; bh=0FBznWqTkmbH9n1+yN5YJhLieR3Nd0/IbFLNfSUOvJI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZtYaRn4/B4GAAgJhPlZQcCQiQORw1dfphQRLo+T1iVDZCmkdAMS3PgMWXdkLKcjGL V/x6uWAKoBz1XCzSxB8Dk8aJh7MIAGazM1oqMo2xjQsHnP/PBn88zKyrOMrW791mmh QlpRSDryXJjuUj/M6XZJdVZKHPDWeMXfgbCiD0qrPDw0dttfKrlfpcwPiNoWdyo2ei /9moBjxxVI0572xbdjC6Kr66jHcw4ZGojd4hTpN5B/5Gnnriq90j6Furz4dg+Jej9M MVjnPJF/3R+WmAgVMFBgzq8O+1BYYXRlzj9/NELdtEMKwc0HgssHXCT8rWbC55qplU PHlh28Poj9ItA== To: Juliusz Chroboczek , babel-users@lists.alioth.debian.org Cc: Barbara Stark , babel@ietf.org In-Reply-To: <877e1r6y0f.wl-jch@irif.fr> References: <877e1r6y0f.wl-jch@irif.fr> Date: Fri, 17 Jan 2020 12:27:08 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <875zhaqq5v.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 11:27:17 -0000 Juliusz Chroboczek writes: > Dear all, > > Antonin and I have spent the afternoon looking at his work on MAC rekeying > in babeld. His code is available in branch hmac-rekeying of > > https://github.com/MisterDA/babeld > > Now... we've got an issue with the information model. > > Following the information model, Antonin adds the following attribute to > keys: > > key-use sign|verify|both > > I'm a little puzzled by the purpose of this attribute. What usage > scenarios is it useful in? In particular, it does not appear to subsume > the sign-only interface attribute, which is useful in incremental > deployment scenarios. Hmm, I think this notion originally comes from Bird's password configuration support? https://bird.network.cz/?get_doc&v=20&f=bird-3.html - search for 'password'. I guess you could use it for a kind of asymmetrical verification procedure? I.e., a route server could have its own key that it signs with, that all peers with the route server will accept, but each peer has its own key it signs with, that the route server is set up to accept. That way the peers wouldn't peer with each other, but all go through the route server? This would not prevent malicious actors, of course (they could just start signing with the route server's key), but it could prevent accidental misconfiguration. Dunno exactly what the original intention with the Bird option is, though. I can ask on the Bird list? -Toke From nobody Fri Jan 17 06:51:43 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378C9120098 for ; Fri, 17 Jan 2020 06:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecu8wOxL1-XH for ; Fri, 17 Jan 2020 06:51:36 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC918120074 for ; Fri, 17 Jan 2020 06:51:36 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00HEjNLe006989; Fri, 17 Jan 2020 09:51:36 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2xk0skwajr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 09:51:36 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00HEpYW0005131; Fri, 17 Jan 2020 09:51:34 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00HEpU4q005048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jan 2020 09:51:31 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 0E06A4009E86; Fri, 17 Jan 2020 14:51:30 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30486.vci.att.com (Service) with ESMTPS id ECE004009E70; Fri, 17 Jan 2020 14:51:29 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Fri, 17 Jan 2020 09:51:29 -0500 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "'Juliusz Chroboczek'" , "'babel-users@lists.alioth.debian.org'" CC: "'babel@ietf.org'" Thread-Topic: [Babel-users] MAC rekeying in babeld and information model Thread-Index: AQHVzJ0q8jDHxzeyx0S6Gir5zXgjYKfvDLIA///hz8A= Date: Fri, 17 Jan 2020 14:51:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> In-Reply-To: <875zhaqq5v.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.107.145] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_03:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 adultscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 spamscore=0 mlxscore=0 clxscore=1011 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001170116 Archived-At: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 14:51:41 -0000 > -----Original Message----- > From: Toke H=F8iland-J=F8rgensen > Sent: Friday, January 17, 2020 6:27 AM > To: Juliusz Chroboczek ; babel-users@lists.alioth.debian.org > Cc: STARK, BARBARA H ; babel@ietf.org > Subject: Re: [Babel-users] MAC rekeying in babeld and information model >=20 > Juliusz Chroboczek writes: >=20 > > Dear all, > > > > Antonin and I have spent the afternoon looking at his work on MAC > > rekeying in babeld. His code is available in branch hmac-rekeying of > > > > > > > > Now... we've got an issue with the information model. > > > > Following the information model, Antonin adds the following attribute > > to > > keys: > > > > key-use sign|verify|both > > > > I'm a little puzzled by the purpose of this attribute. What usage > > scenarios is it useful in? In particular, it does not appear to > > subsume the sign-only interface attribute, which is useful in > > incremental deployment scenarios. >=20 > Hmm, I think this notion originally comes from Bird's password configurat= ion > support? > > search for 'password'. >=20 > I guess you could use it for a kind of asymmetrical verification procedur= e? > I.e., a route server could have its own key that it signs with, that all = peers > with the route server will accept, but each peer has its own key it signs= with, > that the route server is set up to accept. That way the peers wouldn't pe= er > with each other, but all go through the route server? This would not prev= ent > malicious actors, of course (they could just start signing with the route > server's key), but it could prevent accidental misconfiguration. >=20 > Dunno exactly what the original intention with the Bird option is, though= . I > can ask on the Bird list? >=20 > -Toke I don't remember precisely and would need to go looking for the emails. I t= hink it did come from Toke's comments. But if an implementation doesn't sup= port asymmetric signing, it can just hard-code the parameter to "both", not= allow configuration of the parameter, and be done with it. Barbara From nobody Fri Jan 17 07:14:07 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235C3120077 for ; Fri, 17 Jan 2020 07:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4DLgorhS9JP for ; Fri, 17 Jan 2020 07:14:04 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC85120018 for ; Fri, 17 Jan 2020 07:14:04 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00HF92Uu012454; Fri, 17 Jan 2020 10:14:04 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2xk0sn5w1g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 10:14:03 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00HFE2kn019840; Fri, 17 Jan 2020 10:14:02 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00HFDu2W019739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jan 2020 10:13:56 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 23C91400AE37; Fri, 17 Jan 2020 15:13:56 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30485.vci.att.com (Service) with ESMTPS id 0EF3C400AE36; Fri, 17 Jan 2020 15:13:56 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0468.000; Fri, 17 Jan 2020 10:13:55 -0500 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "'Juliusz Chroboczek'" , "'babel-users@lists.alioth.debian.org'" CC: "'babel@ietf.org'" Thread-Topic: [Babel-users] MAC rekeying in babeld and information model Thread-Index: AQHVzJ0q8jDHxzeyx0S6Gir5zXgjYKfvDLIA///hz8CAAAgi8A== Date: Fri, 17 Jan 2020 15:13:54 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.107.145] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_03:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 phishscore=0 impostorscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001170119 Archived-At: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 15:14:06 -0000 BTW, I just looked at the -10 revision of=20 https://tools.ietf.org/html/draft-ietf-babel-information-model-10 Since that revision has Boolean (true/false) parameters of babel-key-use-si= gn and babel-key-use-verify (but not key-use with values of sign/verify/bot= h), I did want to be sure we were talking about the right model revision. Barbara > From: STARK, BARBARA H >=20 > > From: Toke H=F8iland-J=F8rgensen > > > > Juliusz Chroboczek writes: > > > > > Dear all, > > > > > > Antonin and I have spent the afternoon looking at his work on MAC > > > rekeying in babeld. His code is available in branch hmac-rekeying > > > of > > > > > > > > > > > > Now... we've got an issue with the information model. > > > > > > Following the information model, Antonin adds the following > > > attribute to > > > keys: > > > > > > key-use sign|verify|both > > > > > > I'm a little puzzled by the purpose of this attribute. What usage > > > scenarios is it useful in? In particular, it does not appear to > > > subsume the sign-only interface attribute, which is useful in > > > incremental deployment scenarios. > > > > Hmm, I think this notion originally comes from Bird's password > > configuration support? > > > > search for 'password'. > > > > I guess you could use it for a kind of asymmetrical verification proced= ure? > > I.e., a route server could have its own key that it signs with, that > > all peers with the route server will accept, but each peer has its own > > key it signs with, that the route server is set up to accept. That way > > the peers wouldn't peer with each other, but all go through the route > > server? This would not prevent malicious actors, of course (they could > > just start signing with the route server's key), but it could prevent > accidental misconfiguration. > > > > Dunno exactly what the original intention with the Bird option is, > > though.. I can ask on the Bird list? > > > > -Toke >=20 > I don't remember precisely and would need to go looking for the emails. I > think it did come from Toke's comments. But if an implementation doesn't > support asymmetric signing, it can just hard-code the parameter to "both"= , > not allow configuration of the parameter, and be done with it. > Barbara From nobody Fri Jan 17 07:32:24 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1021200E3 for ; Fri, 17 Jan 2020 07:32:23 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plHV9JG9g-ie for ; Fri, 17 Jan 2020 07:32:16 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBF41200B5 for ; Fri, 17 Jan 2020 07:32:16 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00HFFQLL024855 for ; Fri, 17 Jan 2020 10:32:16 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2xk0skxd22-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 17 Jan 2020 10:32:16 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00HFWETD020517 for ; Fri, 17 Jan 2020 10:32:15 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00HFWDpj020488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 17 Jan 2020 10:32:13 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 00082400B574 for ; Fri, 17 Jan 2020 15:32:12 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30488.vci.att.com (Service) with ESMTPS id E1090400B573 for ; Fri, 17 Jan 2020 15:32:12 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0468.000; Fri, 17 Jan 2020 10:32:12 -0500 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: info and data models -- feedback requested Thread-Index: AdXNRgJByTVE3gjKRoepFUG1DhqqXA== Date: Fri, 17 Jan 2020 15:32:12 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.107.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_03:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 adultscore=0 malwarescore=0 phishscore=0 mlxlogscore=968 priorityscore=1501 lowpriorityscore=0 spamscore=0 mlxscore=0 clxscore=1015 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001170120 Archived-At: Subject: [babel] info and data models -- feedback requested X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 15:32:23 -0000 There are 2 items related to the info/data models that have been swirling a= round in my head over the past month.=20 1. Since the most recent drafts of rfc6126bis now have 2 examples of initia= l interval settings (for cases where fast convergence is desired, or where = slow convergence is acceptable and less chattiness is desired), I don't lik= e that we have no means for the user to express what their preference is ar= ound this (in case an implementation could support both cases). Should we h= ave something at the top level of the model like: boolean rw converge-fast; converge-fast: Indicates whether the user wants the network to converge= =20 quickly (which will cause Babel messages to be sent more frequently),= or prefers fewer Babel messages with slower time to convergence. Fast convergence is desired if "true". An implementation MAY choose to exp= ose this parameter as read-only ("ro"). 2. In BBF, I got a comment related to babel-stats-enable and babel-packet-l= og-enable. It's unspecified as to whether previous data is discarded when t= he stats or log are enabled, or the new log entries are appended / existing= counts incremented. I tend to agree that the lack of a statement will lead= to inconsistency, and would prefer consistent behavior. Mahesh and I had a= brief exchange where we disagreed on what the preferred behavior should be= -- which suggests there is definitely a strong likelihood of different imp= lementations choosing different behavior in the absence of guidance. I realize we're past last call. But I think these are important. Barbara From nobody Fri Jan 17 12:13:24 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C041D12087F for ; Fri, 17 Jan 2020 12:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9mNTRmpPL8E for ; Fri, 17 Jan 2020 12:13:18 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 EAB3E12010E for ; Fri, 17 Jan 2020 12:13:17 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id b137so12178278pga.6 for ; Fri, 17 Jan 2020 12:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ti9Co/djth4WCbJuataZpLRkNLcVqmiflkMKrHW+C8M=; b=PI3Yr7bhm/RWzu8CgJtbnXH5PMwheOtNA3NDAiOLYIAa/OaPCQ8d3B6FpqWdCyZC09 miOGlEcGJKIWgwzixr9weIa38HRVpYIBryCK3uy2qD49C+ulxdEUO/PoBd/A4Fm/7gZy kiSQkC1xvuMRSiDr0r1zRtcybWSMRD3jquZvR8jIiJVc+fUD5m5z17Op32pVAd89+dSE z3HQIr3jY0J+6fDEDiEmTu8GyRZ0WMquPJ/5rUufXa2PV77jQkq9bBFTwAU6vUkd2NDZ FqkoINRKW7Vj7wpFEwH/IAsR/BzZHJpjVvXVjRFF2rkrjE8XAPZHpthnp5392mWrg85K bzWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ti9Co/djth4WCbJuataZpLRkNLcVqmiflkMKrHW+C8M=; b=BgRHmbLt5m9n6u2deUAdu14MS0tAxHPo7jWcDGjblUkokaxOvmlT/qxaQ85czXE1JF TaYE2lT8RpgMg7r9CkWGwiaURM1vliOCrF02QdQc64HlSTaCUS89tRuwSgMEZgGBb/3k JnXlTH+e4hJp/jZRzxqNaLFYO627C7vnkLpyWYXgaDpvldMKeIoj8IN8InFi3I44yu5e YtCC65sZj7X0dHEeuE9A4sscsYxXBCwTFdrQveP3WgxiANRyxpdYsQsuF/PmKQp8FW/q lBLwjlsbDfuEqzsxEeQv9mNilWp9yfpjFs10jSSbq8KF09lNbnWp3kWvnlEGaHcd+Rex I/Fw== X-Gm-Message-State: APjAAAVMGZzDZ9zqok4xrRh7e9ECTgo7Y1HTP7a92HOrwIhjigmQU5is EiJhcxf3A50xH0/8scTaePI= X-Google-Smtp-Source: APXvYqyksDHfrSd5UK/QEZPnlNRpZ+uDSmaWqOSHEKEAul1d9uwDhugvrnGhJ9JirEbv7Yu/7y3Dkg== X-Received: by 2002:aa7:8299:: with SMTP id s25mr4511353pfm.261.1579291997372; Fri, 17 Jan 2020 12:13:17 -0800 (PST) Received: from [10.33.123.108] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id 133sm30256845pfy.14.2020.01.17.12.13.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jan 2020 12:13:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 17 Jan 2020 12:13:15 -0800 Cc: "babel@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] info and data models -- feedback requested X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 20:13:23 -0000 > On Jan 17, 2020, at 7:32 AM, STARK, BARBARA H wrote: >=20 > There are 2 items related to the info/data models that have been = swirling around in my head over the past month.=20 >=20 > 1. Since the most recent drafts of rfc6126bis now have 2 examples of = initial interval settings (for cases where fast convergence is desired, = or where slow convergence is acceptable and less chattiness is desired), = I don't like that we have no means for the user to express what their = preference is around this (in case an implementation could support both = cases). Should we have something at the top level of the model like: > boolean rw converge-fast; >=20 > converge-fast: Indicates whether the user wants the network to = converge=20 > quickly (which will cause Babel messages to be sent more = frequently), or > prefers fewer Babel messages with slower time to convergence. = Fast > convergence is desired if "true". An implementation MAY choose to = expose > this parameter as read-only ("ro"). >=20 > 2. In BBF, I got a comment related to babel-stats-enable and = babel-packet-log-enable. It's unspecified as to whether previous data is = discarded when the stats or log are enabled, or the new log entries are = appended / existing counts incremented. I tend to agree that the lack of = a statement will lead to inconsistency, and would prefer consistent = behavior. Mahesh and I had a brief exchange where we disagreed on what = the preferred behavior should be -- which suggests there is definitely a = strong likelihood of different implementations choosing different = behavior in the absence of guidance. And to clarify the disagreement between Barbara and I was =E2=80=A6 The Babel information and data models define a boolean flag that = enables/disables the collection of statistics. The Babel data model in = addition has an =E2=80=98action=E2=80=99 YANG statement defined to clear = the statistics being collected. Barbara=E2=80=99s assumption with = enabling the boolean flag was that it would implicitly clear all the = statistics. But the data model with a separate =E2=80=98action=E2=80=99 = statement requires it to be called explicitly to clear the statistics.=20= Unfortunately, there isn=E2=80=99t a way in YANG to invoke the calling = of an =E2=80=98action=E2=80=99 statement when a certain attribute value = toggles. Implementations can choose to make it implicit by including the = call to the =E2=80=98action=E2=80=99 statement as part of enabling = statistics. But it is not something YANG can enforce. So the question is - should the information model require that enabling = of statistics collection also clear the statistics (even if the YANG = model cannot enforce it) or leave it to implementations to = decide/enforce? Cheers. >=20 > I realize we're past last call. But I think these are important. >=20 > Barbara >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com From nobody Sat Jan 18 12:49:32 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5F4120019; Sat, 18 Jan 2020 12:49:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, martin.vigoureux@nokia.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157938057082.31646.1061058055552269878.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2020 12:49:30 -0800 Archived-At: Subject: [babel] babel - Update to a Meeting Session Request for IETF 107 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 20:49:31 -0000 An update to a meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 21 Conflicts to Avoid: Chair Conflict: bess idr rtgwg saag Technology Overlap: homenet manet rtgarea lpwan Key Participant Conflict: netconf netmod People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jan 18 13:09:44 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E800D120019 for ; Sat, 18 Jan 2020 13:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGZiHa7W4XB8 for ; Sat, 18 Jan 2020 13:09:41 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 43A8812008B for ; Sat, 18 Jan 2020 13:09:41 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id n21so29702292ioo.10 for ; Sat, 18 Jan 2020 13:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SWL3wld0qAWKOSFjSu5n6vxD5+u/iUPursshFxHvEWI=; b=siaft5ETBUpCCcDkFnWZ9+bqEhq7LiQrkp0UxG8auZkUXoAvt6+XsQFeNC73gqaP0g /M7626nVxTj6nWLEbhkOBkn89mwmrQBpyVBDpEL8psvkKjHJIKplJvnYHFkgDy5kxDmC JRHh0umSQ0QMmMrNJkvmdkr1DOQUj+Aea8+ZWL9SRgLkA0CDd9jGkx/e/4chEQcpMqGP nrDqZrcbB5aV4/1xGx/KrrCifIa3zCrDzK5NKkUbmrwnX94CiSGdLjoJwjqazf7klNhm BshQ+iZvAVK1gFUyzUa3+fU57Kk1Wf8gUW+q18cpRPu8iZZluDP+SqIXWVdkdBfSeI4U TT1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SWL3wld0qAWKOSFjSu5n6vxD5+u/iUPursshFxHvEWI=; b=GcD+TcLF8i3CCDXhaYjfI+8BeuAnTzqxCZzlpZ/OKbFYDu+hxdlOWksLLnRitsD/Ko x/OVhUg/Sma2Au4KBHVXJa5faRX9Rx4ZVmsU8Ma2W76rdHvgCzEW5pTeA4J8EPB8eRJ6 PNCAqmh8CABJWMxl6EshT3njlaiD4EOKCDGshHVDKEEZw/PxZ0qUOUKKv0MkB3Eoa0cg oYzBMWImV/a+6VAY25wmAoYjGi8IRGxm3vSic0tab/RR7jpROfxsvBU5E+sWzFFS/Fes 0sziJSw9F3rZTczMSYhX4c4SIeW9+DPQiPzLS1MbSpErrbJZZZoR6PZ6eb/4vjy5K2Zt TAfg== X-Gm-Message-State: APjAAAWoMU/01aKesmpgMvX1ifV2w1JA251phQU0YoDMRo6knejoa/W9 7BvbGq/pwMSztEHq4wjQlkHWnN7Yvcfv+a+xp0E= X-Google-Smtp-Source: APXvYqxN7wmgnnnttAoM8x4hDSYTuDpONIbMwAUyVs5bJpdTRAs+dmS0BUo4xVRyDsdgiWYqdQVMzGB+GZpVwpCakug= X-Received: by 2002:a02:778d:: with SMTP id g135mr39393195jac.115.1579381780591; Sat, 18 Jan 2020 13:09:40 -0800 (PST) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> In-Reply-To: <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> From: Donald Eastlake Date: Sat, 18 Jan 2020 16:09:29 -0500 Message-ID: To: Mahesh Jethanandani Cc: "STARK, BARBARA H" , "babel@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ff3730059c707930" Archived-At: Subject: Re: [babel] info and data models -- feedback requested X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 21:09:43 -0000 --000000000000ff3730059c707930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mahesh and Barbara, Speaking just as a WG member, it seems to me more flexible for the clearing of statistics and the enablement of statistics to be separate actions. You can always do both if that's wht you want. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Jan 17, 2020 at 3:13 PM Mahesh Jethanandani wrote: > > > > On Jan 17, 2020, at 7:32 AM, STARK, BARBARA H wrote: > > > > There are 2 items related to the info/data models that have been > swirling around in my head over the past month. > > > > 1. Since the most recent drafts of rfc6126bis now have 2 examples of > initial interval settings (for cases where fast convergence is desired, o= r > where slow convergence is acceptable and less chattiness is desired), I > don't like that we have no means for the user to express what their > preference is around this (in case an implementation could support both > cases). Should we have something at the top level of the model like: > > boolean rw converge-fast; > > > > converge-fast: Indicates whether the user wants the network to > converge > > quickly (which will cause Babel messages to be sent more > frequently), or > > prefers fewer Babel messages with slower time to convergence. Fas= t > > convergence is desired if "true". An implementation MAY choose to > expose > > this parameter as read-only ("ro"). > > > > 2. In BBF, I got a comment related to babel-stats-enable and > babel-packet-log-enable. It's unspecified as to whether previous data is > discarded when the stats or log are enabled, or the new log entries are > appended / existing counts incremented. I tend to agree that the lack of = a > statement will lead to inconsistency, and would prefer consistent behavio= r. > Mahesh and I had a brief exchange where we disagreed on what the preferre= d > behavior should be -- which suggests there is definitely a strong > likelihood of different implementations choosing different behavior in th= e > absence of guidance. > > And to clarify the disagreement between Barbara and I was =E2=80=A6 > > The Babel information and data models define a boolean flag that > enables/disables the collection of statistics. The Babel data model in > addition has an =E2=80=98action=E2=80=99 YANG statement defined to clear = the statistics > being collected. Barbara=E2=80=99s assumption with enabling the boolean f= lag was > that it would implicitly clear all the statistics. But the data model wit= h > a separate =E2=80=98action=E2=80=99 statement requires it to be called ex= plicitly to clear > the statistics. > > Unfortunately, there isn=E2=80=99t a way in YANG to invoke the calling of= an > =E2=80=98action=E2=80=99 statement when a certain attribute value toggles= . Implementations > can choose to make it implicit by including the call to the =E2=80=98acti= on=E2=80=99 > statement as part of enabling statistics. But it is not something YANG ca= n > enforce. > > So the question is - should the information model require that enabling o= f > statistics collection also clear the statistics (even if the YANG model > cannot enforce it) or leave it to implementations to decide/enforce? > > Cheers. > > > > > I realize we're past last call. But I think these are important. > > > > Barbara > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000ff3730059c707930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mahesh and Barbara,

Speaking just as= a WG member, it seems to me more flexible for the clearing of statistics a= nd the enablement of statistics to be separate actions. You can always do b= oth if that's wht you want.

Thank= s,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0= +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 US= A
=C2=A0d3e3e3@gma= il.com


On Fri, Jan 17, 2020 at 3:13 PM Mahesh Jeth= anandani <mjethanandani@gmail= .com> wrote:


> On Jan 17, 2020, at 7:32 AM, STARK, BARBARA H <bs7652@att.com> wrote:
>
> There are 2 items related to the info/data models that have been swirl= ing around in my head over the past month.
>
> 1. Since the most recent drafts of rfc6126bis now have 2 examples of i= nitial interval settings (for cases where fast convergence is desired, or w= here slow convergence is acceptable and less chattiness is desired), I don&= #39;t like that we have no means for the user to express what their prefere= nce is around this (in case an implementation could support both cases). Sh= ould we have something at the top level of the model like:
> boolean=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rw conv= erge-fast;
>
>=C2=A0 =C2=A0converge-fast:=C2=A0 Indicates whether the user wants the = network to converge
>=C2=A0 =C2=A0 =C2=A0 quickly (which will cause Babel messages to be sen= t more frequently), or
>=C2=A0 =C2=A0 =C2=A0 prefers fewer Babel messages with slower time to c= onvergence.=C2=A0 Fast
>=C2=A0 =C2=A0 =C2=A0 convergence is desired if "true". An imp= lementation MAY choose to expose
>=C2=A0 =C2=A0 =C2=A0 this parameter as read-only ("ro").
>
> 2. In BBF, I got a comment related to babel-stats-enable and babel-pac= ket-log-enable. It's unspecified as to whether previous data is discard= ed when the stats or log are enabled, or the new log entries are appended /= existing counts incremented. I tend to agree that the lack of a statement = will lead to inconsistency, and would prefer consistent behavior. Mahesh an= d I had a brief exchange where we disagreed on what the preferred behavior = should be -- which suggests there is definitely a strong likelihood of diff= erent implementations choosing different behavior in the absence of guidanc= e.

And to clarify the disagreement between Barbara and I was =E2=80=A6

The Babel information and data models define a boolean flag that enables/di= sables the collection of statistics. The Babel data model in addition has a= n =E2=80=98action=E2=80=99 YANG statement defined to clear the statistics b= eing collected. Barbara=E2=80=99s assumption with enabling the boolean flag= was that it would implicitly clear all the statistics. But the data model = with a separate =E2=80=98action=E2=80=99 statement requires it to be called= explicitly to clear the statistics.

Unfortunately, there isn=E2=80=99t a way in YANG to invoke the calling of a= n =E2=80=98action=E2=80=99 statement when a certain attribute value toggles= . Implementations can choose to make it implicit by including the call to t= he =E2=80=98action=E2=80=99 statement as part of enabling statistics. But i= t is not something YANG can enforce.

So the question is - should the information model require that enabling of = statistics collection also clear the statistics (even if the YANG model can= not enforce it) or leave it to implementations to decide/enforce?

Cheers.

>
> I realize we're past last call. But I think these are important. >
> Barbara
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@= gmail.com



_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000ff3730059c707930-- From nobody Sun Jan 19 05:14:44 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2481200B8 for ; Sun, 19 Jan 2020 05:14:42 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns8BvcTailtx for ; Sun, 19 Jan 2020 05:14:40 -0800 (PST) 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 5619C12007A for ; Sun, 19 Jan 2020 05:14:39 -0800 (PST) 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/82085) with ESMTP id 00JDEWSs010459; Sun, 19 Jan 2020 14:14:32 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id F1F32FE874; Sun, 19 Jan 2020 14:14:34 +0100 (CET) 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 ZIJ3Hfnukg1C; Sun, 19 Jan 2020 14:14:33 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2EFA4FE872; Sun, 19 Jan 2020 14:14:30 +0100 (CET) Date: Sun, 19 Jan 2020 14:14:29 +0100 Message-ID: <878sm3a8qy.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen=27?=" , "'babel-users@lists.alioth.debian.org'" , "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 19 Jan 2020 14:14:33 +0100 (CET) X-Miltered: at korolev with ID 5E245638.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E245638.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 : 5E245638.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: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 13:14:43 -0000 > Since that revision has Boolean (true/false) parameters of > babel-key-use-sign and babel-key-use-verify (but not key-use with values > of sign/verify/both), I did want to be sure we were talking about the > right model revision. The second part of my inquiry -- how does the information model enable incremental deployment? Section 5 of draft-ietf-babel-mac. Toke, it would be helpful if we could understand what key-use is intended for. My personal opinion right now is that we should: - remove key-use from the draft; - add a per-interface configuration "allow-unauthentified", which, if set, causes all packets received on that interface to be accepted, whether signed, unsigned, or incorrectly signed. Incremental deployment is an important feature, and I think that we need to make really sure that the information model allows it. -- Juliusz From nobody Mon Jan 20 08:24:13 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222671208B0 for ; Mon, 20 Jan 2020 08:24:12 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDLJV9pccz0B for ; Mon, 20 Jan 2020 08:24:05 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A981208BC for ; Mon, 20 Jan 2020 08:24:05 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00KGI9rN009354; Mon, 20 Jan 2020 11:24:05 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2xmge6tfdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jan 2020 11:24:04 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00KGO3xa010209; Mon, 20 Jan 2020 11:24:03 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00KGNwbk010090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jan 2020 11:23:58 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 1451B400AE37; Mon, 20 Jan 2020 16:23:58 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30485.vci.att.com (Service) with ESMTPS id F403C400AE36; Mon, 20 Jan 2020 16:23:57 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Mon, 20 Jan 2020 11:23:57 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "'babel-users@lists.alioth.debian.org'" , "'babel@ietf.org'" Thread-Topic: [Babel-users] MAC rekeying in babeld and information model Thread-Index: AQHVzJ0q8jDHxzeyx0S6Gir5zXgjYKfvDLIA///hz8CAAAgi8IADWLeAgAFttWA= Date: Mon, 20 Jan 2020 16:23:56 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> <878sm3a8qy.wl-jch@irif.fr> In-Reply-To: <878sm3a8qy.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.99.207] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-20_07:2020-01-20, 2020-01-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=543 malwarescore=0 impostorscore=0 priorityscore=1501 phishscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 suspectscore=0 adultscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001200136 Archived-At: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:24:12 -0000 > > Since that revision has Boolean (true/false) parameters of > > babel-key-use-sign and babel-key-use-verify (but not key-use with > > values of sign/verify/both), I did want to be sure we were talking > > about the right model revision. >=20 > The second part of my inquiry -- how does the information model enable > incremental deployment? Section 5 of draft-ietf-babel-mac. Incremental deployment is enabled through the interfaces object babel-mac-v= erify parameter. Set this parameter to false until all routers have key(s).= Then set to true. >=20 > Toke, it would be helpful if we could understand what key-use is intended > for. My personal opinion right now is that we should: >=20 > - remove key-use from the draft; >=20 > - add a per-interface configuration "allow-unauthentified", which, if s= et, > causes all packets received on that interface to be accepted, whether > signed, unsigned, or incorrectly signed. >=20 > Incremental deployment is an important feature, and I think that we need = to > make really sure that the information model allows it. The key-use-sign and key-use-verify are only peripherally involved in incre= mental deployment and key rotation -- you need to have at least one key wit= h key-use-verify=3Dtrue and key-use-sign=3Dtrue. The common case when incre= mentally deploying will be to provide a single key with valid and sign =3D = true and all interfaces' babel-mac-verify =3D false. Once all routers have = the key, set babel-mac-verify to true in all routers. When rotating, the co= mmon case will be to provide an additional key with valid and sign =3D true= . Once the new key is in all routers, delete old one. I don't think an additional per-interface parameter is needed. I think babe= l-mac-verify should be fine. If the group wants to remove the key-use param= eters and only support symmetrical keying, I have no objection. We could al= so make those parameters optional-to-implement (square brackets), with the = expectation that an implementation wouldn't implement them if it only suppo= rts symmetric keying. Barbara From nobody Mon Jan 20 08:25:34 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0912089B for ; Mon, 20 Jan 2020 08:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPldBD_yXyHR for ; Mon, 20 Jan 2020 08:25:27 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 159B51208C3 for ; Mon, 20 Jan 2020 08:25:27 -0800 (PST) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00KGI7nv027057; Mon, 20 Jan 2020 11:25:26 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2xkxbrsf6w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jan 2020 11:25:25 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00KGPNO4012623; Mon, 20 Jan 2020 11:25:25 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00KGPJck012435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jan 2020 11:25:19 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 64B0A401466F; Mon, 20 Jan 2020 16:25:19 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30483.vci.att.com (Service) with ESMTPS id 4C6C74014663; Mon, 20 Jan 2020 16:25:19 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0468.000; Mon, 20 Jan 2020 11:25:18 -0500 From: "STARK, BARBARA H" To: "'Donald Eastlake'" , "'Mahesh Jethanandani'" CC: "'babel@ietf.org'" Thread-Topic: [babel] info and data models -- feedback requested Thread-Index: AdXNRgJByTVE3gjKRoepFUG1DhqqXAAVnNqAADRBXoAAUCPK4A== Date: Mon, 20 Jan 2020 16:25:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153757B62@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.99.207] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61153757B62GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-20_07:2020-01-20, 2020-01-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 impostorscore=0 phishscore=0 malwarescore=0 suspectscore=0 adultscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 clxscore=1015 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001200136 Archived-At: Subject: Re: [babel] info and data models -- feedback requested X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:25:33 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61153757B62GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3b3VsZCBzdWdnZXN0IHdlIHNob3VsZCBhZGQgYSByZXNldCBhY3Rpb24gZm9yIHRoZSBw YWNrZXQgbG9nLiBXZSBkb27igJl0IGN1cnJlbnRseSBoYXZlIG9uZS4NCkJhcmJhcmENCg0KRnJv bTogRG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21haWwuY29tPg0KDQpIaSBNYWhlc2ggYW5kIEJh cmJhcmEsDQoNClNwZWFraW5nIGp1c3QgYXMgYSBXRyBtZW1iZXIsIGl0IHNlZW1zIHRvIG1lIG1v cmUgZmxleGlibGUgZm9yIHRoZSBjbGVhcmluZyBvZiBzdGF0aXN0aWNzIGFuZCB0aGUgZW5hYmxl bWVudCBvZiBzdGF0aXN0aWNzIHRvIGJlIHNlcGFyYXRlIGFjdGlvbnMuIFlvdSBjYW4gYWx3YXlz IGRvIGJvdGggaWYgdGhhdCdzIHdodCB5b3Ugd2FudC4NCg0KVGhhbmtzLA0KRG9uYWxkDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsx LTUwOC0zMzMtMjI3MCAoY2VsbCkNCiAyMzg2IFBhbm9yYW1pYyBDaXJjbGUsIEFwb3BrYSwgRkwg MzI3MDMgVVNBDQogZDNlM2UzQGdtYWlsLmNvbTxtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbT4NCg0K DQpPbiBGcmksIEphbiAxNywgMjAyMCBhdCAzOjEzIFBNIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdy b3RlOg0KDQoNCj4gT24gSmFuIDE3LCAyMDIwLCBhdCA3OjMyIEFNLCBTVEFSSywgQkFSQkFSQSBI IDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUyQGF0dC5jb20+PiB3cm90ZToNCj4NCj4gVGhl cmUgYXJlIDIgaXRlbXMgcmVsYXRlZCB0byB0aGUgaW5mby9kYXRhIG1vZGVscyB0aGF0IGhhdmUg YmVlbiBzd2lybGluZyBhcm91bmQgaW4gbXkgaGVhZCBvdmVyIHRoZSBwYXN0IG1vbnRoLg0KPg0K PiAxLiBTaW5jZSB0aGUgbW9zdCByZWNlbnQgZHJhZnRzIG9mIHJmYzYxMjZiaXMgbm93IGhhdmUg MiBleGFtcGxlcyBvZiBpbml0aWFsIGludGVydmFsIHNldHRpbmdzIChmb3IgY2FzZXMgd2hlcmUg ZmFzdCBjb252ZXJnZW5jZSBpcyBkZXNpcmVkLCBvciB3aGVyZSBzbG93IGNvbnZlcmdlbmNlIGlz IGFjY2VwdGFibGUgYW5kIGxlc3MgY2hhdHRpbmVzcyBpcyBkZXNpcmVkKSwgSSBkb24ndCBsaWtl IHRoYXQgd2UgaGF2ZSBubyBtZWFucyBmb3IgdGhlIHVzZXIgdG8gZXhwcmVzcyB3aGF0IHRoZWly IHByZWZlcmVuY2UgaXMgYXJvdW5kIHRoaXMgKGluIGNhc2UgYW4gaW1wbGVtZW50YXRpb24gY291 bGQgc3VwcG9ydCBib3RoIGNhc2VzKS4gU2hvdWxkIHdlIGhhdmUgc29tZXRoaW5nIGF0IHRoZSB0 b3AgbGV2ZWwgb2YgdGhlIG1vZGVsIGxpa2U6DQo+IGJvb2xlYW4gICAgICAgICAgICAgICAgcncg Y29udmVyZ2UtZmFzdDsNCj4NCj4gICBjb252ZXJnZS1mYXN0OiAgSW5kaWNhdGVzIHdoZXRoZXIg dGhlIHVzZXIgd2FudHMgdGhlIG5ldHdvcmsgdG8gY29udmVyZ2UNCj4gICAgICBxdWlja2x5ICh3 aGljaCB3aWxsIGNhdXNlIEJhYmVsIG1lc3NhZ2VzIHRvIGJlIHNlbnQgbW9yZSBmcmVxdWVudGx5 KSwgb3INCj4gICAgICBwcmVmZXJzIGZld2VyIEJhYmVsIG1lc3NhZ2VzIHdpdGggc2xvd2VyIHRp bWUgdG8gY29udmVyZ2VuY2UuICBGYXN0DQo+ICAgICAgY29udmVyZ2VuY2UgaXMgZGVzaXJlZCBp ZiAidHJ1ZSIuIEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UgdG8gZXhwb3NlDQo+ICAgICAg dGhpcyBwYXJhbWV0ZXIgYXMgcmVhZC1vbmx5ICgicm8iKS4NCj4NCj4gMi4gSW4gQkJGLCBJIGdv dCBhIGNvbW1lbnQgcmVsYXRlZCB0byBiYWJlbC1zdGF0cy1lbmFibGUgYW5kIGJhYmVsLXBhY2tl dC1sb2ctZW5hYmxlLiBJdCdzIHVuc3BlY2lmaWVkIGFzIHRvIHdoZXRoZXIgcHJldmlvdXMgZGF0 YSBpcyBkaXNjYXJkZWQgd2hlbiB0aGUgc3RhdHMgb3IgbG9nIGFyZSBlbmFibGVkLCBvciB0aGUg bmV3IGxvZyBlbnRyaWVzIGFyZSBhcHBlbmRlZCAvIGV4aXN0aW5nIGNvdW50cyBpbmNyZW1lbnRl ZC4gSSB0ZW5kIHRvIGFncmVlIHRoYXQgdGhlIGxhY2sgb2YgYSBzdGF0ZW1lbnQgd2lsbCBsZWFk IHRvIGluY29uc2lzdGVuY3ksIGFuZCB3b3VsZCBwcmVmZXIgY29uc2lzdGVudCBiZWhhdmlvci4g TWFoZXNoIGFuZCBJIGhhZCBhIGJyaWVmIGV4Y2hhbmdlIHdoZXJlIHdlIGRpc2FncmVlZCBvbiB3 aGF0IHRoZSBwcmVmZXJyZWQgYmVoYXZpb3Igc2hvdWxkIGJlIC0tIHdoaWNoIHN1Z2dlc3RzIHRo ZXJlIGlzIGRlZmluaXRlbHkgYSBzdHJvbmcgbGlrZWxpaG9vZCBvZiBkaWZmZXJlbnQgaW1wbGVt ZW50YXRpb25zIGNob29zaW5nIGRpZmZlcmVudCBiZWhhdmlvciBpbiB0aGUgYWJzZW5jZSBvZiBn dWlkYW5jZS4NCg0KQW5kIHRvIGNsYXJpZnkgdGhlIGRpc2FncmVlbWVudCBiZXR3ZWVuIEJhcmJh cmEgYW5kIEkgd2FzIOKApg0KDQpUaGUgQmFiZWwgaW5mb3JtYXRpb24gYW5kIGRhdGEgbW9kZWxz IGRlZmluZSBhIGJvb2xlYW4gZmxhZyB0aGF0IGVuYWJsZXMvZGlzYWJsZXMgdGhlIGNvbGxlY3Rp b24gb2Ygc3RhdGlzdGljcy4gVGhlIEJhYmVsIGRhdGEgbW9kZWwgaW4gYWRkaXRpb24gaGFzIGFu IOKAmGFjdGlvbuKAmSBZQU5HIHN0YXRlbWVudCBkZWZpbmVkIHRvIGNsZWFyIHRoZSBzdGF0aXN0 aWNzIGJlaW5nIGNvbGxlY3RlZC4gQmFyYmFyYeKAmXMgYXNzdW1wdGlvbiB3aXRoIGVuYWJsaW5n IHRoZSBib29sZWFuIGZsYWcgd2FzIHRoYXQgaXQgd291bGQgaW1wbGljaXRseSBjbGVhciBhbGwg dGhlIHN0YXRpc3RpY3MuIEJ1dCB0aGUgZGF0YSBtb2RlbCB3aXRoIGEgc2VwYXJhdGUg4oCYYWN0 aW9u4oCZIHN0YXRlbWVudCByZXF1aXJlcyBpdCB0byBiZSBjYWxsZWQgZXhwbGljaXRseSB0byBj bGVhciB0aGUgc3RhdGlzdGljcy4NCg0KVW5mb3J0dW5hdGVseSwgdGhlcmUgaXNu4oCZdCBhIHdh eSBpbiBZQU5HIHRvIGludm9rZSB0aGUgY2FsbGluZyBvZiBhbiDigJhhY3Rpb27igJkgc3RhdGVt ZW50IHdoZW4gYSBjZXJ0YWluIGF0dHJpYnV0ZSB2YWx1ZSB0b2dnbGVzLiBJbXBsZW1lbnRhdGlv bnMgY2FuIGNob29zZSB0byBtYWtlIGl0IGltcGxpY2l0IGJ5IGluY2x1ZGluZyB0aGUgY2FsbCB0 byB0aGUg4oCYYWN0aW9u4oCZIHN0YXRlbWVudCBhcyBwYXJ0IG9mIGVuYWJsaW5nIHN0YXRpc3Rp Y3MuIEJ1dCBpdCBpcyBub3Qgc29tZXRoaW5nIFlBTkcgY2FuIGVuZm9yY2UuDQoNClNvIHRoZSBx dWVzdGlvbiBpcyAtIHNob3VsZCB0aGUgaW5mb3JtYXRpb24gbW9kZWwgcmVxdWlyZSB0aGF0IGVu YWJsaW5nIG9mIHN0YXRpc3RpY3MgY29sbGVjdGlvbiBhbHNvIGNsZWFyIHRoZSBzdGF0aXN0aWNz IChldmVuIGlmIHRoZSBZQU5HIG1vZGVsIGNhbm5vdCBlbmZvcmNlIGl0KSBvciBsZWF2ZSBpdCB0 byBpbXBsZW1lbnRhdGlvbnMgdG8gZGVjaWRlL2VuZm9yY2U/DQoNCkNoZWVycy4NCg0KPg0KPiBJ IHJlYWxpemUgd2UncmUgcGFzdCBsYXN0IGNhbGwuIEJ1dCBJIHRoaW5rIHRoZXNlIGFyZSBpbXBv cnRhbnQuDQo+DQo+IEJhcmJhcmENCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gYmFiZWwgbWFpbGluZyBsaXN0DQo+IGJhYmVsQGlldGYub3Jn PG1haWx0bzpiYWJlbEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9iYWJlbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmQ9RHdNRmFRJmM9 TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT1FcnZhcjZZ VlBuQ2V3VFdwTUdVUWR2cldEbC0tVVRSSUtWeU1tLVNFdkY0JnM9RGhqWU5ESE5SUExzQmhDUFBq ZTZlNjUzd0w5SV9WQ3ZncGpFR3lrYzBhQSZlPT4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpl dGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmJhYmVs IG1haWxpbmcgbGlzdA0KYmFiZWxAaWV0Zi5vcmc8bWFpbHRvOmJhYmVsQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDxodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2JhYmVsJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3po Qy04c2M4U1k4VHE0dnJmb2cmbT1FcnZhcjZZVlBuQ2V3VFdwTUdVUWR2cldEbC0tVVRSSUtWeU1t LVNFdkY0JnM9RGhqWU5ESE5SUExzQmhDUFBqZTZlNjUzd0w5SV9WQ3ZncGpFR3lrYzBhQSZlPT4N Cg== --_000_2D09D61DDFA73D4C884805CC7865E61153757B62GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGF0IHdvdWxkIHN1Z2dlc3Qgd2Ugc2hvdWxkIGFkZCBhIHJlc2V0IGFjdGlvbiBmb3IgdGhlIHBh Y2tldCBsb2cuIFdlIGRvbuKAmXQgY3VycmVudGx5IGhhdmUgb25lLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IERvbmFsZCBFYXN0bGFrZSAmbHQ7ZDNl M2UzQGdtYWlsLmNvbSZndDsgPGJyPg0KPGJyPg0KPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIE1haGVzaCBhbmQgQmFyYmFyYSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFraW5nIGp1c3QgYXMgYSBXRyBtZW1iZXIsIGl0IHNlZW1z IHRvIG1lIG1vcmUgZmxleGlibGUgZm9yIHRoZSBjbGVhcmluZyBvZiBzdGF0aXN0aWNzIGFuZCB0 aGUgZW5hYmxlbWVudCBvZiBzdGF0aXN0aWNzIHRvIGJlIHNlcGFyYXRlIGFjdGlvbnMuIFlvdSBj YW4gYWx3YXlzIGRvIGJvdGggaWYgdGhhdCdzIHdodCB5b3Ugd2FudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Ms PGJyPg0KRG9uYWxkPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZu YnNwO0RvbmFsZCBFLiBFYXN0bGFrZSAzcmQgJm5ic3A7ICYjNDM7MS01MDgtMzMzLTIyNzAgKGNl bGwpPGJyPg0KJm5ic3A7MjM4NiBQYW5vcmFtaWMgQ2lyY2xlLCBBcG9wa2EsIEZMIDMyNzAzIFVT QTxicj4NCiZuYnNwOzxhIGhyZWY9Im1haWx0bzpkM2UzZTNAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZDNlM2UzQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTcsIDIwMjAgYXQgMzoxMyBQ TSBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBn bWFpbC5jb20iPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQomZ3Q7IE9uIEphbiAxNywgMjAyMCwgYXQgNzozMiBBTSwgU1RBUkssIEJBUkJBUkEgSCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJzNzY1MkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnM3NjUy QGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUgYXJlIDIg aXRlbXMgcmVsYXRlZCB0byB0aGUgaW5mby9kYXRhIG1vZGVscyB0aGF0IGhhdmUgYmVlbiBzd2ly bGluZyBhcm91bmQgaW4gbXkgaGVhZCBvdmVyIHRoZSBwYXN0IG1vbnRoLg0KPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDEuIFNpbmNlIHRoZSBtb3N0IHJlY2VudCBkcmFmdHMgb2YgcmZjNjEyNmJpcyBu b3cgaGF2ZSAyIGV4YW1wbGVzIG9mIGluaXRpYWwgaW50ZXJ2YWwgc2V0dGluZ3MgKGZvciBjYXNl cyB3aGVyZSBmYXN0IGNvbnZlcmdlbmNlIGlzIGRlc2lyZWQsIG9yIHdoZXJlIHNsb3cgY29udmVy Z2VuY2UgaXMgYWNjZXB0YWJsZSBhbmQgbGVzcyBjaGF0dGluZXNzIGlzIGRlc2lyZWQpLCBJIGRv bid0IGxpa2UgdGhhdCB3ZSBoYXZlIG5vIG1lYW5zIGZvciB0aGUNCiB1c2VyIHRvIGV4cHJlc3Mg d2hhdCB0aGVpciBwcmVmZXJlbmNlIGlzIGFyb3VuZCB0aGlzIChpbiBjYXNlIGFuIGltcGxlbWVu dGF0aW9uIGNvdWxkIHN1cHBvcnQgYm90aCBjYXNlcykuIFNob3VsZCB3ZSBoYXZlIHNvbWV0aGlu ZyBhdCB0aGUgdG9wIGxldmVsIG9mIHRoZSBtb2RlbCBsaWtlOjxicj4NCiZndDsgYm9vbGVhbiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcncg Y29udmVyZ2UtZmFzdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7Y29udmVyZ2Ut ZmFzdDombmJzcDsgSW5kaWNhdGVzIHdoZXRoZXIgdGhlIHVzZXIgd2FudHMgdGhlIG5ldHdvcmsg dG8gY29udmVyZ2UgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHF1aWNrbHkgKHdoaWNo IHdpbGwgY2F1c2UgQmFiZWwgbWVzc2FnZXMgdG8gYmUgc2VudCBtb3JlIGZyZXF1ZW50bHkpLCBv cjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcmVmZXJzIGZld2VyIEJhYmVsIG1lc3Nh Z2VzIHdpdGggc2xvd2VyIHRpbWUgdG8gY29udmVyZ2VuY2UuJm5ic3A7IEZhc3Q8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY29udmVyZ2VuY2UgaXMgZGVzaXJlZCBpZiAmcXVvdDt0cnVl JnF1b3Q7LiBBbiBpbXBsZW1lbnRhdGlvbiBNQVkgY2hvb3NlIHRvIGV4cG9zZTxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyB0aGlzIHBhcmFtZXRlciBhcyByZWFkLW9ubHkgKCZxdW90O3Jv JnF1b3Q7KS48YnI+DQomZ3Q7IDxicj4NCiZndDsgMi4gSW4gQkJGLCBJIGdvdCBhIGNvbW1lbnQg cmVsYXRlZCB0byBiYWJlbC1zdGF0cy1lbmFibGUgYW5kIGJhYmVsLXBhY2tldC1sb2ctZW5hYmxl LiBJdCdzIHVuc3BlY2lmaWVkIGFzIHRvIHdoZXRoZXIgcHJldmlvdXMgZGF0YSBpcyBkaXNjYXJk ZWQgd2hlbiB0aGUgc3RhdHMgb3IgbG9nIGFyZSBlbmFibGVkLCBvciB0aGUgbmV3IGxvZyBlbnRy aWVzIGFyZSBhcHBlbmRlZCAvIGV4aXN0aW5nIGNvdW50cyBpbmNyZW1lbnRlZC4gSSB0ZW5kIHRv DQogYWdyZWUgdGhhdCB0aGUgbGFjayBvZiBhIHN0YXRlbWVudCB3aWxsIGxlYWQgdG8gaW5jb25z aXN0ZW5jeSwgYW5kIHdvdWxkIHByZWZlciBjb25zaXN0ZW50IGJlaGF2aW9yLiBNYWhlc2ggYW5k IEkgaGFkIGEgYnJpZWYgZXhjaGFuZ2Ugd2hlcmUgd2UgZGlzYWdyZWVkIG9uIHdoYXQgdGhlIHBy ZWZlcnJlZCBiZWhhdmlvciBzaG91bGQgYmUgLS0gd2hpY2ggc3VnZ2VzdHMgdGhlcmUgaXMgZGVm aW5pdGVseSBhIHN0cm9uZyBsaWtlbGlob29kIG9mDQogZGlmZmVyZW50IGltcGxlbWVudGF0aW9u cyBjaG9vc2luZyBkaWZmZXJlbnQgYmVoYXZpb3IgaW4gdGhlIGFic2VuY2Ugb2YgZ3VpZGFuY2Uu PGJyPg0KPGJyPg0KQW5kIHRvIGNsYXJpZnkgdGhlIGRpc2FncmVlbWVudCBiZXR3ZWVuIEJhcmJh cmEgYW5kIEkgd2FzIOKApjxicj4NCjxicj4NClRoZSBCYWJlbCBpbmZvcm1hdGlvbiBhbmQgZGF0 YSBtb2RlbHMgZGVmaW5lIGEgYm9vbGVhbiBmbGFnIHRoYXQgZW5hYmxlcy9kaXNhYmxlcyB0aGUg Y29sbGVjdGlvbiBvZiBzdGF0aXN0aWNzLiBUaGUgQmFiZWwgZGF0YSBtb2RlbCBpbiBhZGRpdGlv biBoYXMgYW4g4oCYYWN0aW9u4oCZIFlBTkcgc3RhdGVtZW50IGRlZmluZWQgdG8gY2xlYXIgdGhl IHN0YXRpc3RpY3MgYmVpbmcgY29sbGVjdGVkLiBCYXJiYXJh4oCZcyBhc3N1bXB0aW9uIHdpdGgg ZW5hYmxpbmcNCiB0aGUgYm9vbGVhbiBmbGFnIHdhcyB0aGF0IGl0IHdvdWxkIGltcGxpY2l0bHkg Y2xlYXIgYWxsIHRoZSBzdGF0aXN0aWNzLiBCdXQgdGhlIGRhdGEgbW9kZWwgd2l0aCBhIHNlcGFy YXRlIOKAmGFjdGlvbuKAmSBzdGF0ZW1lbnQgcmVxdWlyZXMgaXQgdG8gYmUgY2FsbGVkIGV4cGxp Y2l0bHkgdG8gY2xlYXIgdGhlIHN0YXRpc3RpY3MuDQo8YnI+DQo8YnI+DQpVbmZvcnR1bmF0ZWx5 LCB0aGVyZSBpc27igJl0IGEgd2F5IGluIFlBTkcgdG8gaW52b2tlIHRoZSBjYWxsaW5nIG9mIGFu IOKAmGFjdGlvbuKAmSBzdGF0ZW1lbnQgd2hlbiBhIGNlcnRhaW4gYXR0cmlidXRlIHZhbHVlIHRv Z2dsZXMuIEltcGxlbWVudGF0aW9ucyBjYW4gY2hvb3NlIHRvIG1ha2UgaXQgaW1wbGljaXQgYnkg aW5jbHVkaW5nIHRoZSBjYWxsIHRvIHRoZSDigJhhY3Rpb27igJkgc3RhdGVtZW50IGFzIHBhcnQg b2YgZW5hYmxpbmcgc3RhdGlzdGljcy4gQnV0DQogaXQgaXMgbm90IHNvbWV0aGluZyBZQU5HIGNh biBlbmZvcmNlLjxicj4NCjxicj4NClNvIHRoZSBxdWVzdGlvbiBpcyAtIHNob3VsZCB0aGUgaW5m b3JtYXRpb24gbW9kZWwgcmVxdWlyZSB0aGF0IGVuYWJsaW5nIG9mIHN0YXRpc3RpY3MgY29sbGVj dGlvbiBhbHNvIGNsZWFyIHRoZSBzdGF0aXN0aWNzIChldmVuIGlmIHRoZSBZQU5HIG1vZGVsIGNh bm5vdCBlbmZvcmNlIGl0KSBvciBsZWF2ZSBpdCB0byBpbXBsZW1lbnRhdGlvbnMgdG8gZGVjaWRl L2VuZm9yY2U/PGJyPg0KPGJyPg0KQ2hlZXJzLjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBJ IHJlYWxpemUgd2UncmUgcGFzdCBsYXN0IGNhbGwuIEJ1dCBJIHRoaW5rIHRoZXNlIGFyZSBpbXBv cnRhbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJhcmJhcmE8YnI+DQomZ3Q7IDxicj4NCiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 IGJhYmVsIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmJhYmVsQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+YmFiZWxAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRlla LW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmYW1wO209RXJ2 YXI2WVZQbkNld1RXcE1HVVFkdnJXRGwtLVVUUklLVnlNbS1TRXZGNCZhbXA7cz1EaGpZTkRITlJQ THNCaENQUGplNmU2NTN3TDlJX1ZDdmdwakVHeWtjMGFBJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDwvYT48YnI+DQo8 YnI+DQpNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+ PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpiYWJlbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86YmFiZWxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iYWJlbEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmFtcDtkPUR3TUZhUSZh bXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cm YW1wO209RXJ2YXI2WVZQbkNld1RXcE1HVVFkdnJXRGwtLVVUUklLVnlNbS1TRXZGNCZhbXA7cz1E aGpZTkRITlJQTHNCaENQUGplNmU2NTN3TDlJX1ZDdmdwakVHeWtjMGFBJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmFiZWw8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E61153757B62GAALPA1MSGUSRBF_-- From nobody Mon Jan 20 08:27:48 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2892C1208ED for ; Mon, 20 Jan 2020 08:27:42 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejkVgJqgyVxp for ; Mon, 20 Jan 2020 08:27:37 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 AB5101208E3 for ; Mon, 20 Jan 2020 08:27:37 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1579537655; bh=ZPN7yxbMOj5lx4NqaxQMxHiAava9QIByhw4cz1VAuFY=; h=From:To:Cc:Subject:Date:From; b=sq86LxisbLjEzy4P/rslxBLgvDZ4EpOoXUz6iNNUFxxc31/7NlRmbljDijeJ0q4BG E1ntPj3zoe4gVCC/Fg239vMKaVLbwhovVjH5QKZrxHKlYr5Hv+6ghhmNFWU8Q+hILe V6UbQpxXmd83Zo4MNhQxwoaUM830cQWrYROCQk5j0bBPagQen/wJmvXAhT2r3eTspx +kig1gLQmK7Pzjgqi6ikSqIeSPxJb8uBljYM+EAeTp+JHZcEP2cC+FFIJJCeIBr/ik DAPM8oHPpqkXIqOJks0+rzUSYQaJRkhcsy7UGSG45lpJ+5ZWIxLwZ1PzYF50bKHF5K UfIL+IMG+x1Mw== To: bird-users@network.cz Cc: babel@ietf.org Date: Mon, 20 Jan 2020 17:27:34 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lfq2nle1.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] Purpose of 'generate from/to' and 'accept from/to' for passwords? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:27:42 -0000 Hi Bird people When specifying passwords for protocol authentication in the Bird config, it is possible to specify time windows in which the password will be used to sign messages (the 'generate from/to' configuration options), and a separate time window in which that password will be accepted to authenticate a packet (the 'accept from/to' options). My question is this: What is the purpose of having these two time intervals be separate? I.e., in what deployment scenario is it useful to have a password be accepted to authenticate a message, without also using that password to sign outgoing messages? This question came out of a discussion around whether we should standardise a similar feature in the Babel RFCs. As you can see I'm struggling a little to come up with a definite use case: https://mailarchive.ietf.org/arch/msg/babel/XOahz4fuXXs-nHO4NMGdBwU8AZo -Toke From nobody Mon Jan 20 08:28:41 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5F21208F4 for ; Mon, 20 Jan 2020 08:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.541 X-Spam-Level: X-Spam-Status: No, score=-0.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Outkf6sP49k for ; Mon, 20 Jan 2020 08:28:39 -0800 (PST) Received: from mail.toke.dk (unknown [85.204.121.218]) (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 70B1D1208DD for ; Mon, 20 Jan 2020 08:28:39 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1579537714; bh=FPKEDfiuq4rwnvEVV3PwzKQ/GoXEYf/f+4yve01lxRA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rc79OPSiFeYrvp47SjaOnpbzP/ddJ9PfhHR/gevksTy96hF/2ES6tDkkBNuPyBhiY 4QrMwkl0UqQaJj1X6ofe6DTlOlJSmE2hXe5dJKS9owU4/XUk02x36X90+/WBmFr+IA eosBJer/swodRgPJcCgh5GGV4QFWicnYAa8VY7lF30kLbTJ1vow3zEbOPmCkal0Gay mI1QijPZWPbC2L9s6eUFemZec64rLVToLsc1GamqaPlq0gefZtMuCNcVrHtA1ChYmJ bHmLE5DAz2yoLaNLIjyi/BTmaeP3L/9tZdvw8ODFrlCqHhpyhc3i2sGAuwVlt2lGYn q7bJdijvdlt0w== To: Juliusz Chroboczek , "STARK\, BARBARA H" Cc: "'babel-users\@lists.alioth.debian.org'" , "'babel\@ietf.org'" In-Reply-To: <878sm3a8qy.wl-jch@irif.fr> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> <878sm3a8qy.wl-jch@irif.fr> Date: Mon, 20 Jan 2020 17:28:34 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87iml6nlcd.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 16:28:40 -0000 Juliusz Chroboczek writes: >> Since that revision has Boolean (true/false) parameters of >> babel-key-use-sign and babel-key-use-verify (but not key-use with values >> of sign/verify/both), I did want to be sure we were talking about the >> right model revision. > > The second part of my inquiry -- how does the information model enable > incremental deployment? Section 5 of draft-ietf-babel-mac. > > Toke, it would be helpful if we could understand what key-use is intended > for. I've asked on the Bird list (cc'ed to babel@ietf). -Toke From nobody Mon Jan 20 11:01:55 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50DF120019 for ; Mon, 20 Jan 2020 11:01:53 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQeTj-QQ-aEO for ; Mon, 20 Jan 2020 11:01:46 -0800 (PST) Received: from mail.crfreenet.org (varda.crfreenet.org [81.92.145.160]) by ietfa.amsl.com (Postfix) with ESMTP id 43E7D12001B for ; Mon, 20 Jan 2020 11:01:45 -0800 (PST) Received: from feanor (feanor-poda.crfreenet.org [164.215.121.182]) by mail.crfreenet.org (Postfix) with ESMTP id DBF825FB80; Mon, 20 Jan 2020 20:01:42 +0100 (CET) Date: Mon, 20 Jan 2020 20:01:42 +0100 From: Ondrej Zajicek To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: bird-users@network.cz, babel@ietf.org Message-ID: <20200120190142.GV2475@feanor.crfreenet.org> References: <87lfq2nle1.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <87lfq2nle1.fsf@toke.dk> X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] Purpose of 'generate from/to' and 'accept from/to' for passwords? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 19:01:54 -0000 On Mon, Jan 20, 2020 at 05:27:34PM +0100, Toke H=F8iland-J=F8rgensen wrote: > Hi Bird people >=20 > When specifying passwords for protocol authentication in the Bird > config, it is possible to specify time windows in which the password > will be used to sign messages (the 'generate from/to' configuration > options), and a separate time window in which that password will be > accepted to authenticate a packet (the 'accept from/to' options). >=20 > My question is this: What is the purpose of having these two time > intervals be separate? I.e., in what deployment scenario is it useful to > have a password be accepted to authenticate a message, without also > using that password to sign outgoing messages? Hi Well, it is requirement of OSPF spec (RFC 2328). I could assume it could help for smoother key transitions when clocks are not perfectly synchronize= d. Personally, if i had to do key rotation, i would only use 'generate =66rom'. As 'generate to' is implicit by presence of newer valid key and 'accept from/to' could be unlimited during transition, while key would be removed later after transition. For systems with dynamic key selections (in contrast to BIRD, where keys are in config file), it would perhaps make sense to merge 'accept to' with automatic removal of key from keylist. --=20 Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From nobody Mon Jan 20 11:54:50 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B38120803 for ; Mon, 20 Jan 2020 11:54:49 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEkupXKPYBdq for ; Mon, 20 Jan 2020 11:54:47 -0800 (PST) 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 B5F78120274 for ; Mon, 20 Jan 2020 11:54:46 -0800 (PST) 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/82085) with ESMTP id 00KJseuU005042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Jan 2020 20:54:40 +0100 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/82085) with ESMTP id 00KJsdqI018602; Mon, 20 Jan 2020 20:54:39 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BD56DB14EB; Mon, 20 Jan 2020 20:54:42 +0100 (CET) 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 D8SqHKk1MQ5F; Mon, 20 Jan 2020 20:54:41 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 416EEB14E9; Mon, 20 Jan 2020 20:54:41 +0100 (CET) Date: Mon, 20 Jan 2020 20:54:41 +0100 Message-ID: <87lfq1nbsu.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen=27?=" , "'babel-users@lists.alioth.debian.org'" , "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> <878sm3a8qy.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 20 Jan 2020 20:54:40 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 20 Jan 2020 20:54:39 +0100 (CET) X-Miltered: at korolev with ID 5E260580.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5E26057F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E260580.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5E26057F.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 : 5E260580.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5E26057F.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: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 19:54:49 -0000 >> The second part of my inquiry -- how does the information model enable >> incremental deployment? Section 5 of draft-ietf-babel-mac. > Incremental deployment is enabled through the interfaces object > babel-mac-verify parameter. Set this parameter to false until all > routers have key(s). Then set to true. Ah, ok. That's fine, then, sorry for missing it. > I don't think an additional per-interface parameter is needed. I think > babel-mac-verify should be fine. Agreed. > If the group wants to remove the key-use parameters and only support > symmetrical keying, I have no objection. We could also make those > parameters optional-to-implement (square brackets), with the expectation > that an implementation wouldn't implement them if it only supports > symmetric keying. Shall we wait for Toke to express an opinion? -- Juliusz From nobody Mon Jan 20 12:26:47 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC11120828 for ; Mon, 20 Jan 2020 12:26:45 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmJTRggwtgAN for ; Mon, 20 Jan 2020 12:26:43 -0800 (PST) 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 3AEDC120827 for ; Mon, 20 Jan 2020 12:26:43 -0800 (PST) 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/82085) with ESMTP id 00KKQcBW013558; Mon, 20 Jan 2020 21:26:38 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0BCB4B1845; Mon, 20 Jan 2020 21:26:41 +0100 (CET) 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 JsSZwy2XUWAU; Mon, 20 Jan 2020 21:26:39 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 98C00B1842; Mon, 20 Jan 2020 21:26:39 +0100 (CET) Date: Mon, 20 Jan 2020 21:26:39 +0100 Message-ID: <87iml5nabk.wl-jch@irif.fr> From: Juliusz Chroboczek To: Ondrej Zajicek Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , bird-users@network.cz, babel@ietf.org In-Reply-To: <20200120190142.GV2475@feanor.crfreenet.org> References: <87lfq2nle1.fsf@toke.dk> <20200120190142.GV2475@feanor.crfreenet.org> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 20 Jan 2020 21:26:38 +0100 (CET) X-Miltered: at korolev with ID 5E260CFE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E260CFE.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 : 5E260CFE.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: Subject: Re: [babel] Purpose of 'generate from/to' and 'accept from/to' for passwords? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 20:26:46 -0000 Thanks, Ondrej. > Well, it is requirement of OSPF spec (RFC 2328). I could assume it could > help for smoother key transitions when clocks are not perfectly synchronized. Ah, I see. OSPF only allows one key in the trailer, so it needs the ability to send one key but accept many. Babel-MAC allows multiple keys in the trailer, and that ability is therefore not required. Or am I missing something? I have no objection to keeping the ability, since it's pretty trivial to implement. No objection to making it optional, since it's not particularly useful in Babel-MAC. No objection to removing it altogether, since it's good to avoid unnecessary features. -- Juliusz From nobody Mon Jan 20 20:24:05 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF37120045 for ; Mon, 20 Jan 2020 20:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzOPgcRAhiCZ for ; Mon, 20 Jan 2020 20:24:02 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 EAB83120026 for ; Mon, 20 Jan 2020 20:24:01 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id m13so808331pjb.2 for ; Mon, 20 Jan 2020 20:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=T1JW/arXuIT8x0hfxCvUNwWBuYVIZGzPFvss/BMVVkQ=; b=SIYd2rL2Hztkl/ufLEe0Zud7uC8AsSBU8VB5EpNy1jO+FJk38DNs59ur66R5N7N67b SAO1aCQQctP6H8t4ExraT1SWAokei8N7RbdNlBSV1SbvWg/D+5Y3rrmnTgXEqUOKuygT EJhcBuIt+l3gYK07ETn/hPAt4HRmKYQlbx5QGXEOORp1Cto69XdwDsDh94M2dXvZr6Qh ysMwWak/kimrvWXrsRVC4LNwVcvGn0afkH56aKV6C3WckXYMOx5dRorkZfLEtJGwuQkX AzvtrdNWDqpkXY+framraTfRWbc8WnV1JoEQgGdae2XnCaTPZmRzdcDWSd+mZkKJVRCo W6eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=T1JW/arXuIT8x0hfxCvUNwWBuYVIZGzPFvss/BMVVkQ=; b=ZaxdTtc6qtMvpQEJwJsemldf6bu/l3wEOjPdOIvegXAHk/pUr6Sryj3RP4yzYLdH1z QOYW3Xe1CuNoM5AfQnOKsk+bMp5hQwfHo5lxcQ6gMoNn8GZMWITjKLDUzwP159XThs46 G0thh4xA/Ch08zdl7Ei820fllQMZvdoa0MNQNFWGXMEjHAH7rq9L0G481J/WTmKSz/Aq yVLEuEHMbZVFWVAgIPXZmNuXaJcQNDEhCCDXnC/36flzcdhVRxx3y/rET4M+2G2ztKsj YNrxptX8P66NJO+UPdlvrpQ0MSdnr1frgDWFwglMGD9FN3nzIhczujNGIMLuJd4QFuW7 i2Xg== X-Gm-Message-State: APjAAAX93inuQmSXRJRl7J5QiGg7AGBstT7HE9n0QnmWf5adlrsrZib/ LRxXofFgUadtQK+BaxL/n20= X-Google-Smtp-Source: APXvYqzuchVhiQq46/0hHGH628z/B6c68VarNAnyUQKXC+PsXU87h4eOi3etk+nWbX8QlC0HXBQ2Yw== X-Received: by 2002:a17:90a:20c4:: with SMTP id f62mr3162974pjg.70.1579580641310; Mon, 20 Jan 2020 20:24:01 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:84a0:9bd5:34a7:f9eb? ([2601:647:5600:5020:84a0:9bd5:34a7:f9eb]) by smtp.gmail.com with ESMTPSA id v5sm40329784pfn.122.2020.01.20.20.23.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 20:24:00 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_702EE1AA-B6C9-4749-976C-2E57B15ADCA7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Jan 2020 20:23:58 -0800 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61153757B62@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Donald Eastlake , "babel@ietf.org" To: "STARK, BARBARA H" References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> <2D09D61DDFA73D4C884805CC7865E61153757B62@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] info and data models -- feedback requested X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 04:24:03 -0000 --Apple-Mail=_702EE1AA-B6C9-4749-976C-2E57B15ADCA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Barbara, Good point. What would you expect the reset action on packet log to do? The difference between packet log and statistics from a data model is = that, statistics are maintained by the data model. As such a reset = causes the values in the data model to be cleared. For the packet log, = all that the model does is maintain a pointer to a URL/file where the = log is maintained. It does not maintain the contents of that log. A = reset action on an object that is external to the model cannot be = enforced by the model. All the model can do is clear the pointer, but I = gather that is not what you are looking for it to do. Cheers. > On Jan 20, 2020, at 8:25 AM, STARK, BARBARA H wrote: >=20 > That would suggest we should add a reset action for the packet log. We = don=E2=80=99t currently have one. > Barbara > =20 > From: Donald Eastlake =20 >=20 > Hi Mahesh and Barbara, > =20 > Speaking just as a WG member, it seems to me more flexible for the = clearing of statistics and the enablement of statistics to be separate = actions. You can always do both if that's wht you want. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > =20 > =20 > On Fri, Jan 17, 2020 at 3:13 PM Mahesh Jethanandani = > wrote: >=20 >=20 > > On Jan 17, 2020, at 7:32 AM, STARK, BARBARA H > wrote: > >=20 > > There are 2 items related to the info/data models that have been = swirling around in my head over the past month.=20 > >=20 > > 1. Since the most recent drafts of rfc6126bis now have 2 examples of = initial interval settings (for cases where fast convergence is desired, = or where slow convergence is acceptable and less chattiness is desired), = I don't like that we have no means for the user to express what their = preference is around this (in case an implementation could support both = cases). Should we have something at the top level of the model like: > > boolean rw converge-fast; > >=20 > > converge-fast: Indicates whether the user wants the network to = converge=20 > > quickly (which will cause Babel messages to be sent more = frequently), or > > prefers fewer Babel messages with slower time to convergence. = Fast > > convergence is desired if "true". An implementation MAY choose = to expose > > this parameter as read-only ("ro"). > >=20 > > 2. In BBF, I got a comment related to babel-stats-enable and = babel-packet-log-enable. It's unspecified as to whether previous data is = discarded when the stats or log are enabled, or the new log entries are = appended / existing counts incremented. I tend to agree that the lack of = a statement will lead to inconsistency, and would prefer consistent = behavior. Mahesh and I had a brief exchange where we disagreed on what = the preferred behavior should be -- which suggests there is definitely a = strong likelihood of different implementations choosing different = behavior in the absence of guidance. >=20 > And to clarify the disagreement between Barbara and I was =E2=80=A6 >=20 > The Babel information and data models define a boolean flag that = enables/disables the collection of statistics. The Babel data model in = addition has an =E2=80=98action=E2=80=99 YANG statement defined to clear = the statistics being collected. Barbara=E2=80=99s assumption with = enabling the boolean flag was that it would implicitly clear all the = statistics. But the data model with a separate =E2=80=98action=E2=80=99 = statement requires it to be called explicitly to clear the statistics.=20= >=20 > Unfortunately, there isn=E2=80=99t a way in YANG to invoke the calling = of an =E2=80=98action=E2=80=99 statement when a certain attribute value = toggles. Implementations can choose to make it implicit by including the = call to the =E2=80=98action=E2=80=99 statement as part of enabling = statistics. But it is not something YANG can enforce. >=20 > So the question is - should the information model require that = enabling of statistics collection also clear the statistics (even if the = YANG model cannot enforce it) or leave it to implementations to = decide/enforce? >=20 > Cheers. >=20 > >=20 > > I realize we're past last call. But I think these are important. > >=20 > > Barbara > >=20 > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel = >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel = --Apple-Mail=_702EE1AA-B6C9-4749-976C-2E57B15ADCA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Barbara,

Good point. = What would you expect the reset action on packet log to do?

The difference between = packet log and statistics from a data model is that, statistics are = maintained by the data model. As such a reset causes the values in the = data model to be cleared. For the packet log, all that the model does is = maintain a pointer to a URL/file where the log is maintained. It does = not maintain the contents of that log. A reset action on an object that = is external to the model cannot be enforced by the model. All the model = can do is clear the pointer, but I gather that is not what you are = looking for it to do.

Cheers.

On Jan 20, 2020, at 8:25 AM, = STARK, BARBARA H <bs7652@att.com> wrote:

That = would suggest we should add a reset action for the packet log. We = don=E2=80=99t currently have one.
Barbara
 
From: Donald Eastlake <d3e3e3@gmail.com> 

Hi Mahesh = and Barbara,
 
Speaking just as a WG member, it seems to me more flexible = for the clearing of statistics and the enablement of statistics to be = separate actions. You can always do both if that's wht you want.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
 
 
On Fri, = Jan 17, 2020 at 3:13 PM Mahesh Jethanandani <mjethanandani@gmail.com> = wrote:


> On Jan 17, 2020, at 7:32 AM, STARK, = BARBARA H <bs7652@att.com> wrote:
> 
> There = are 2 items related to the info/data models that have been swirling = around in my head over the past month. 
> 
> 1. = Since the most recent drafts of rfc6126bis now have 2 examples of = initial interval settings (for cases where fast convergence is desired, = or where slow convergence is acceptable and less chattiness is desired), = I don't like that we have no means for the user to express what their = preference is around this (in case an implementation could support both = cases). Should we have something at the top level of the model like:
> boolean              =   rw converge-fast;
> 
>  =  converge-fast:  Indicates whether the user wants the network = to converge 
>      quickly (which will cause Babel = messages to be sent more frequently), or
>    =   prefers fewer Babel messages with slower time to = convergence.  Fast
>      = convergence is desired if "true". An implementation MAY choose to = expose
>      this parameter as = read-only ("ro").
> 
> 2. In = BBF, I got a comment related to babel-stats-enable and = babel-packet-log-enable. It's unspecified as to whether previous data is = discarded when the stats or log are enabled, or the new log entries are = appended / existing counts incremented. I tend to agree that the lack of = a statement will lead to inconsistency, and would prefer consistent = behavior. Mahesh and I had a brief exchange where we disagreed on what = the preferred behavior should be -- which suggests there is definitely a = strong likelihood of different implementations choosing different = behavior in the absence of guidance.

And to = clarify the disagreement between Barbara and I was =E2=80=A6

The Babel information and data models define a = boolean flag that enables/disables the collection of statistics. The = Babel data model in addition has an =E2=80=98action=E2=80=99 YANG = statement defined to clear the statistics being collected. Barbara=E2=80=99= s assumption with enabling the boolean flag was that it would implicitly = clear all the statistics. But the data model with a separate = =E2=80=98action=E2=80=99 statement requires it to be called explicitly = to clear the statistics. 

Unfortunately, there isn=E2=80=99t a way in YANG to invoke = the calling of an =E2=80=98action=E2=80=99 statement when a certain = attribute value toggles. Implementations can choose to make it implicit = by including the call to the =E2=80=98action=E2=80=99 statement as part = of enabling statistics. But it is not something YANG can enforce.

So the question is - should the information = model require that enabling of statistics collection also clear the = statistics (even if the YANG model cannot enforce it) or leave it to = implementations to decide/enforce?

Cheers.
> 
> I = realize we're past last call. But I think these are important.
> 
> Barbara
> 
> = _______________________________________________
> babel = mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@gmail.com



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

= --Apple-Mail=_702EE1AA-B6C9-4749-976C-2E57B15ADCA7-- From nobody Tue Jan 21 05:37:46 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E57A1200CD for ; Tue, 21 Jan 2020 05:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41H-wQ9ydUVK for ; Tue, 21 Jan 2020 05:37:39 -0800 (PST) Received: from mail.toke.dk (unknown [85.204.121.218]) (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 BE38C1200F7 for ; Tue, 21 Jan 2020 05:37:39 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1579613856; bh=TfR0C2PZoqRYw4ob93olnCrGox8fcTfNkQihFT6nh8k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=C7T1WvA8E16qD45o4V0FXZfFmRaGS+F5iwkhdSFzTE+mMZEKUES0o2Xsg1YigelSX qbp6cLjvHJdOACjgYGeM8ZkQp5zkBMqq+pY7H2nriwnHvA3zMl86Ni7HXKYanLM+k2 sIgZ1LjZplCdOXkr5GJXy1ZQQdGk18HMGgw1l1fQYYXxFGnZXEqK0IL3vM2zAu9gVQ +r9ufpYtHFAAHzUS9or/H2BPe8941IMjjuhjvLbSiHotSl2htdQA8QUCfhYDg+dli1 4WoAr3MlFO8Oe8Yp8ycvD5YnqQ+5nCL3xCLiWpYlBHXpdjVugDk7iK1PVBJYdqG1aH bDhTnK1gHj8cQ== To: Juliusz Chroboczek , Ondrej Zajicek Cc: bird-users@network.cz, babel@ietf.org In-Reply-To: <87iml5nabk.wl-jch@irif.fr> References: <87lfq2nle1.fsf@toke.dk> <20200120190142.GV2475@feanor.crfreenet.org> <87iml5nabk.wl-jch@irif.fr> Date: Tue, 21 Jan 2020 14:37:35 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y2u1lylc.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Purpose of 'generate from/to' and 'accept from/to' for passwords? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 13:37:44 -0000 Juliusz Chroboczek writes: > Thanks, Ondrej. > >> Well, it is requirement of OSPF spec (RFC 2328). I could assume it could >> help for smoother key transitions when clocks are not perfectly synchronized. > > Ah, I see. > > OSPF only allows one key in the trailer, so it needs the ability to send > one key but accept many. Babel-MAC allows multiple keys in the trailer, > and that ability is therefore not required. > > Or am I missing something? No, I think you're right. > I have no objection to keeping the ability, since it's pretty trivial to > implement. No objection to making it optional, since it's not > particularly useful in Babel-MAC. No objection to removing it altogether, > since it's good to avoid unnecessary features. Well, the Bird implementation (which I really should get around to finishing) is going to re-use the existing config syntax, so that is going to implement it in any case. I don't have any strong opinions as to what the spec should say, as long as it doesn't forbid such an option :) -Toke From nobody Tue Jan 21 05:39:09 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE6D1200CD for ; Tue, 21 Jan 2020 05:39:06 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFjCgL8DJrRp for ; Tue, 21 Jan 2020 05:39:05 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 344EF1200E5 for ; Tue, 21 Jan 2020 05:39:05 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1579613943; bh=03zDlH1HPnDcjlAxq6P8KJ4KHPJdH1tpkyJLeYs0GGI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DbmCBAMpxOEB/dC7NCe1fVFpx5MkL7G2zUTEVYVO9nSF33d+YPOTvWYaWR52UE92C NzNbCi0qSI/AZ2C/KYTCRUlnwA421xOmPCgqxatcSzMv84RdLk3haCJlkiYXjroqef LyB1YuZBYraumMES2CAewwpo2k81w8zyXPYDJbiwWWWW9s8y7BzbZCSlWtYc7/YQ1r JGlUehDtQmofdMYK57w4F7vUvncDrO4NqkpM9ABJasonjE8xw31JNZsys1Bl36jTrv GqQJrHL4sJtLUsf95DWQ85drV4qhLKiJPxOPO0Qre55ntOspDM3ywlSeL21MX2nxxP RqSTS+11ZsNCw== To: Juliusz Chroboczek , "STARK\, BARBARA H" Cc: "'babel-users\@lists.alioth.debian.org'" , "'babel\@ietf.org'" In-Reply-To: <87lfq1nbsu.wl-jch@irif.fr> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> <878sm3a8qy.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfq1nbsu.wl-jch@irif.fr> Date: Tue, 21 Jan 2020 14:39:03 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87v9p5lyiw.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 13:39:07 -0000 Juliusz Chroboczek writes: >>> The second part of my inquiry -- how does the information model enable >>> incremental deployment? Section 5 of draft-ietf-babel-mac. > >> Incremental deployment is enabled through the interfaces object >> babel-mac-verify parameter. Set this parameter to false until all >> routers have key(s). Then set to true. > > Ah, ok. That's fine, then, sorry for missing it. > >> I don't think an additional per-interface parameter is needed. I think >> babel-mac-verify should be fine. > > Agreed. > >> If the group wants to remove the key-use parameters and only support >> symmetrical keying, I have no objection. We could also make those >> parameters optional-to-implement (square brackets), with the expectation >> that an implementation wouldn't implement them if it only supports >> symmetric keying. > > Shall we wait for Toke to express an opinion? As I just replied in the other thread: The Bird implementation is going to have this facility no matter what we specify in the spec, but I'm fine with having it optional, or omitting it from the spec entirely, as long as we don't forbid having a key-use parameter :) -Toke From nobody Tue Jan 21 05:46:00 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1B41200CD for ; Tue, 21 Jan 2020 05:45:57 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bma04qIw4cNu for ; Tue, 21 Jan 2020 05:45:51 -0800 (PST) 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 8C3FE1200E5 for ; Tue, 21 Jan 2020 05:45:51 -0800 (PST) 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/82085) with ESMTP id 00LDjTfL008695; Tue, 21 Jan 2020 14:45:30 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3DA8DBB733; Tue, 21 Jan 2020 14:45:32 +0100 (CET) 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 Hpo9sEyeStQX; Tue, 21 Jan 2020 14:45:30 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9F61DBB730; Tue, 21 Jan 2020 14:45:30 +0100 (CET) Date: Tue, 21 Jan 2020 14:45:30 +0100 Message-ID: <8736c8ylc5.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: "STARK, BARBARA H" , "'babel-users@lists.alioth.debian.org'" , "'babel@ietf.org'" In-Reply-To: <87v9p5lyiw.fsf@toke.dk> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> <878sm3a8qy.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfq1nbsu.wl-jch@irif.fr> <87v9p5lyiw.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 21 Jan 2020 14:45:30 +0100 (CET) X-Miltered: at korolev with ID 5E270079.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5E270079.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 : 5E270079.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: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 13:45:58 -0000 > As I just replied in the other thread: The Bird implementation is going > to have this facility no matter what we specify in the spec, but I'm > fine with having it optional, or omitting it from the spec entirely, as > long as we don't forbid having a key-use parameter :) It is my understanding that it's already effectively optional -- it can be exported as read-only (paragraph 3.9 of the draft). I suggest we let Barbara decide whether she wants to explicitly mark it as optional. -- Juliusz From nobody Tue Jan 21 09:29:48 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C78712006B for ; Tue, 21 Jan 2020 09:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaOn3MFTiqJw for ; Tue, 21 Jan 2020 09:29:41 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 83F0A120899 for ; Tue, 21 Jan 2020 09:29:41 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00LHFgCS021276; Tue, 21 Jan 2020 12:29:40 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2xp4s2hq90-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 12:29:39 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00LHTchT027793; Tue, 21 Jan 2020 12:29:39 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00LHTUjo027610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2020 12:29:30 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id BDE774009E78; Tue, 21 Jan 2020 17:29:30 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30486.vci.att.com (Service) with ESMTPS id A12F54009E77; Tue, 21 Jan 2020 17:29:30 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0468.000; Tue, 21 Jan 2020 12:29:30 -0500 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" CC: "'Donald Eastlake'" , "'babel@ietf.org'" Thread-Topic: [babel] info and data models -- feedback requested Thread-Index: AdXNRgJByTVE3gjKRoepFUG1DhqqXAAVnNqAADRBXoAAUCPK4AAjngEAAAlY3TA= Date: Tue, 21 Jan 2020 17:29:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611537590F3@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61153754370@GAALPA1MSGUSRBF.ITServices.sbc.com> <53327E10-4D4F-4F2D-9F9C-DC30EC3C1FA1@gmail.com> <2D09D61DDFA73D4C884805CC7865E61153757B62@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.112.151] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611537590F3GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.634 definitions=2020-01-21_05:2020-01-21, 2020-01-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 phishscore=0 bulkscore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001210134 Archived-At: Subject: Re: [babel] info and data models -- feedback requested X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 17:29:46 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611537590F3GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIGxvZ3MsIEkgY2FuIHNlZSBzZXZlcmFsIGhvbGlzdGljIChub3QgZm9jdXNpbmcgb24gcmVz dWx0IG9mIGEgc2luZ2xlIGFjdGlvbikgc2V0cyBvZiBiZWhhdmlvcnMgYSB1c2VyIG1heSB3YW50 IHRvIGFjY29tcGxpc2ggYXQgdGhlIHRpbWUgdGhleeKAmXJlIGVuYWJsaW5nIGxvZ2dpbmcgKEni gJltIHdvcmRpbmcgdGhpcyBzcGVjaWZpY2FsbHkgdG8gYmUgdmFndWUgYWJvdXQgaG93IG1hbnkg Y29tbWFuZHMgdGhlIHVzZXIgbWlnaHQgbmVlZCB0byBpc3N1ZSk6DQoNCiAgMS4gIE9sZCBmaWxl IGlzIGRlbGV0ZWQgb3Igb2xkIG1lbW9yeSBzdG9yZSBpcyBjbGVhcmVkL3JlbGVhc2VkLCBuZXcg ZmlsZSBpcyBzdGFydGVkIG9yIG1lbW9yeSBzcGFjZSBjcmVhdGVkIHdpdGggbmV3IHJlZmVyZW5j ZS4NCiAgMi4gIE9sZCBmaWxlIC8gbWVtb3J5IHN0b3JlIHN0YXlzLCBuZXcgZmlsZSAvIG1lbW9y eSBzdG9yZSBpcyBzdGFydGVkIHdpdGggbmV3IHJlZmVyZW5jZS4gLy8gdGhlcmUgaXMgbm8gbG9u Z2VyIGEgcmVmZXJlbmNlIHNwZWNpZmllZCBpbiB0aGUgQmFiZWwgaW5mbyBtb2RlbCB0aGF0IHdv dWxkIHBvaW50IHRvIHRoZSBvbGQgZmlsZSBvciBtZW1vcnk7IHNvbWUgRE0gc2NoZW1lcywgbGlr ZSBUUi0xODEsIHdvdWxkIHN0aWxsIGFsbG93IGFjY2VzcyB0byB0aGUgbG9nICh0aGUgQmFiZWwg cGFja2V0IGxvZyBpcyBhIHJlZmVyZW5jZSB0byBhbiBlbnRyeSBpbiBhIGxvZyBvYmplY3QpOyB3 aGVyZSB0aGUgbG9nIGNhbWUgZnJvbSwgdGhvdWdoLCB3b3VsZCBiZSBsb3N0IHVubGVzcyBpdCB3 YXMgaW5jb3Jwb3JhdGVkIGluIHRoZSBmaWxlbmFtZSBieSB0aGUgaW1wbGVtZW50YXRpb24gb3Ig b3RoZXJ3aXNlIGNvbnRhaW5lZCBpbiBsb2cgbWV0YWRhdGE7IG1heSBuZWVkIHRvIGNvbnNpZGVy IGlmIHNvbWV0aGluZyBuZWVkcyB0byBiZSBzYWlkIGFib3V0IHBlcnNpc3RlbmNlIGFjcm9zcyBy ZWJvb3RzDQogIDMuICBFeGlzdGluZyByZWZlcmVuY2VkIGZpbGUgLyBtZW1vcnkgc3RvcmUgaXMg YXBwZW5kZWQuDQogIDQuICBFeGlzdGluZyByZWZlcmVuY2VkIGZpbGUgLyBtZW1vcnkgc3RvcmUg aXMgY2xlYXJlZCBhbmQgdGhlbiBhcHBlbmRlZC4NCg0KMSBhbmQgNCBhcmUgdmVyeSBzaW1pbGFy IGluIGVmZmVjdC4NCg0KTm90ZSB0aGF0IHRoZXJlIGFyZSBiZWhhdmlvcnMgdGhhdCBjYW4gYmUg ZW5mb3JjZWQgYnkgdGhlIG1vZGVsLCBhbmQgYmVoYXZpb3JzIHRoYXQgYXJlIGltcG9zZWQgb24g Y29tcGxpYW50IGltcGxlbWVudGF0aW9ucyAoZS5nLiwgbWFuZGF0b3J5IHRvIGltcGxlbWVudCku IEnigJltIG5vdCBjb25jZXJuZWQgd2l0aCB3aGV0aGVyIG9yIG5vdCBhIGRlc2lyZWQgYmVoYXZp b3IgaXMgZW5mb3JjZWQgYnkgYSBtb2RlbC4gSeKAmW0gcGVyZmVjdGx5IHNhdGlzZmllZCBmb3Ig ZGVzaXJlZCBiZWhhdmlvcnMgdG8gYmUgaW1wb3NlZCB0aHJvdWdoIGltcGxlbWVudGF0aW9uIGNv bXBsaWFuY2UuIFRoZSBxdWVzdGlvbiBmb3IgbWUgaXMgd2hhdCB0aGUgZGVzaXJlZCBiZWhhdmlv ciBpcywgYW5kIG5vdCB3aGV0aGVyIG9yIG5vdCBhbnkgcGFydGljdWxhciBETSBzY2hlbWUgaGFz IHRoZSBhYmlsaXR5IHRvIGVuZm9yY2UuDQoNCknigJltIHRoaW5raW5nIChiYXNlZCBvbiBvcGlu aW9ucyBleHByZXNzZWQgdG8gZGF0ZSkgdGhhdCBpbiB0aGUgYWJzZW5jZSBvZiBhIGxvZyDigJxy ZXNldOKAnSwgYmVoYXZpb3IgMyAoYXBwZW5kaW5nKSBtaWdodCBiZSBleHBlY3RlZCB0byBvY2N1 ciAobm90ZSB0aGUgaW5mbyBtb2RlbCBzYXlzIG5vdGhpbmcgYWJvdXQgbGltaXRpbmcgZmlsZXNp emUg4oCTIGl04oCZcyB1cCB0byB0aGUgRE0gb3IgaW1wbGVtZW50YXRpb24gdG8gZG8gb3Igc2F5 IHNvbWV0aGluZyB3cnQgbWF4IGZpbGVzaXplIGFuZCB3aGF0IHRvIGRvIHdoZW4gbWF4IGlzIHJl YWNoZWQpLiBJZiB3ZSB3ZXJlIHRvIGhhdmUgYSBsb2cgcmVzZXQsIEkgdGhpbmsgZWl0aGVyIGJl aGF2aW9yIDEgb3IgNCB3b3VsZCBiZSBmaW5lLCBhbmQgZG9u4oCZdCB0aGluayB3ZeKAmWQgbmVl ZCB0byBkaWN0YXRlIG9uZSBvciB0aGUgb3RoZXIgaW4gdGhlIGluZm8gbW9kZWwuIEnigJlkIHBy ZWZlciB0byBhdm9pZCAyLCBiZWNhdXNlIEkgdGhpbmsgaXQgcG9zZXMgYSBkYW5nZXIgb2YgbWVt b3J5IGxlYWtzLiBJdCBtYXkgYWxzbyBiZSB1c2VmdWwgdG8gaW5jbHVkZSBhIHN0YXRlbWVudCB0 aGF0IHRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIGZvciBsb2dzIHRvIHBlcnNpc3QgYWNyb3NzIHJl Ym9vdHMuDQoNCkJhcmJhcmENCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFu ZGFuaUBnbWFpbC5jb20+DQoNCkhpIEJhcmJhcmEsDQoNCkdvb2QgcG9pbnQuIFdoYXQgd291bGQg eW91IGV4cGVjdCB0aGUgcmVzZXQgYWN0aW9uIG9uIHBhY2tldCBsb2cgdG8gZG8/DQoNClRoZSBk aWZmZXJlbmNlIGJldHdlZW4gcGFja2V0IGxvZyBhbmQgc3RhdGlzdGljcyBmcm9tIGEgZGF0YSBt b2RlbCBpcyB0aGF0LCBzdGF0aXN0aWNzIGFyZSBtYWludGFpbmVkIGJ5IHRoZSBkYXRhIG1vZGVs LiBBcyBzdWNoIGEgcmVzZXQgY2F1c2VzIHRoZSB2YWx1ZXMgaW4gdGhlIGRhdGEgbW9kZWwgdG8g YmUgY2xlYXJlZC4gRm9yIHRoZSBwYWNrZXQgbG9nLCBhbGwgdGhhdCB0aGUgbW9kZWwgZG9lcyBp cyBtYWludGFpbiBhIHBvaW50ZXIgdG8gYSBVUkwvZmlsZSB3aGVyZSB0aGUgbG9nIGlzIG1haW50 YWluZWQuIEl0IGRvZXMgbm90IG1haW50YWluIHRoZSBjb250ZW50cyBvZiB0aGF0IGxvZy4gQSBy ZXNldCBhY3Rpb24gb24gYW4gb2JqZWN0IHRoYXQgaXMgZXh0ZXJuYWwgdG8gdGhlIG1vZGVsIGNh bm5vdCBiZSBlbmZvcmNlZCBieSB0aGUgbW9kZWwuIEFsbCB0aGUgbW9kZWwgY2FuIGRvIGlzIGNs ZWFyIHRoZSBwb2ludGVyLCBidXQgSSBnYXRoZXIgdGhhdCBpcyBub3Qgd2hhdCB5b3UgYXJlIGxv b2tpbmcgZm9yIGl0IHRvIGRvLg0KDQpDaGVlcnMuDQoNCg0KT24gSmFuIDIwLCAyMDIwLCBhdCA4 OjI1IEFNLCBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUyQGF0 dC5jb20+PiB3cm90ZToNCg0KVGhhdCB3b3VsZCBzdWdnZXN0IHdlIHNob3VsZCBhZGQgYSByZXNl dCBhY3Rpb24gZm9yIHRoZSBwYWNrZXQgbG9nLiBXZSBkb27igJl0IGN1cnJlbnRseSBoYXZlIG9u ZS4NCkJhcmJhcmENCg0KRnJvbTogRG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21haWwuY29tPG1h aWx0bzpkM2UzZTNAZ21haWwuY29tPj4NCkhpIE1haGVzaCBhbmQgQmFyYmFyYSwNCg0KU3BlYWtp bmcganVzdCBhcyBhIFdHIG1lbWJlciwgaXQgc2VlbXMgdG8gbWUgbW9yZSBmbGV4aWJsZSBmb3Ig dGhlIGNsZWFyaW5nIG9mIHN0YXRpc3RpY3MgYW5kIHRoZSBlbmFibGVtZW50IG9mIHN0YXRpc3Rp Y3MgdG8gYmUgc2VwYXJhdGUgYWN0aW9ucy4gWW91IGNhbiBhbHdheXMgZG8gYm90aCBpZiB0aGF0 J3Mgd2h0IHlvdSB3YW50Lg0KDQpUaGFua3MsDQpEb25hbGQNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCiBEb25hbGQgRS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcwIChj ZWxsKQ0KIDIzODYgUGFub3JhbWljIENpcmNsZSwgQXBvcGthLCBGTCAzMjcwMyBVU0ENCiBkM2Uz ZTNAZ21haWwuY29tPG1haWx0bzpkM2UzZTNAZ21haWwuY29tPg0KDQoNCk9uIEZyaSwgSmFuIDE3 LCAyMDIwIGF0IDM6MTMgUE0gTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFp bC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KPiBPbiBK YW4gMTcsIDIwMjAsIGF0IDc6MzIgQU0sIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29t PG1haWx0bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KPg0KPiBUaGVyZSBhcmUgMiBpdGVtcyBy ZWxhdGVkIHRvIHRoZSBpbmZvL2RhdGEgbW9kZWxzIHRoYXQgaGF2ZSBiZWVuIHN3aXJsaW5nIGFy b3VuZCBpbiBteSBoZWFkIG92ZXIgdGhlIHBhc3QgbW9udGguDQo+DQo+IDEuIFNpbmNlIHRoZSBt b3N0IHJlY2VudCBkcmFmdHMgb2YgcmZjNjEyNmJpcyBub3cgaGF2ZSAyIGV4YW1wbGVzIG9mIGlu aXRpYWwgaW50ZXJ2YWwgc2V0dGluZ3MgKGZvciBjYXNlcyB3aGVyZSBmYXN0IGNvbnZlcmdlbmNl IGlzIGRlc2lyZWQsIG9yIHdoZXJlIHNsb3cgY29udmVyZ2VuY2UgaXMgYWNjZXB0YWJsZSBhbmQg bGVzcyBjaGF0dGluZXNzIGlzIGRlc2lyZWQpLCBJIGRvbid0IGxpa2UgdGhhdCB3ZSBoYXZlIG5v IG1lYW5zIGZvciB0aGUgdXNlciB0byBleHByZXNzIHdoYXQgdGhlaXIgcHJlZmVyZW5jZSBpcyBh cm91bmQgdGhpcyAoaW4gY2FzZSBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBzdXBwb3J0IGJvdGgg Y2FzZXMpLiBTaG91bGQgd2UgaGF2ZSBzb21ldGhpbmcgYXQgdGhlIHRvcCBsZXZlbCBvZiB0aGUg bW9kZWwgbGlrZToNCj4gYm9vbGVhbiAgICAgICAgICAgICAgICBydyBjb252ZXJnZS1mYXN0Ow0K Pg0KPiAgIGNvbnZlcmdlLWZhc3Q6ICBJbmRpY2F0ZXMgd2hldGhlciB0aGUgdXNlciB3YW50cyB0 aGUgbmV0d29yayB0byBjb252ZXJnZQ0KPiAgICAgIHF1aWNrbHkgKHdoaWNoIHdpbGwgY2F1c2Ug QmFiZWwgbWVzc2FnZXMgdG8gYmUgc2VudCBtb3JlIGZyZXF1ZW50bHkpLCBvcg0KPiAgICAgIHBy ZWZlcnMgZmV3ZXIgQmFiZWwgbWVzc2FnZXMgd2l0aCBzbG93ZXIgdGltZSB0byBjb252ZXJnZW5j ZS4gIEZhc3QNCj4gICAgICBjb252ZXJnZW5jZSBpcyBkZXNpcmVkIGlmICJ0cnVlIi4gQW4gaW1w bGVtZW50YXRpb24gTUFZIGNob29zZSB0byBleHBvc2UNCj4gICAgICB0aGlzIHBhcmFtZXRlciBh cyByZWFkLW9ubHkgKCJybyIpLg0KPg0KPiAyLiBJbiBCQkYsIEkgZ290IGEgY29tbWVudCByZWxh dGVkIHRvIGJhYmVsLXN0YXRzLWVuYWJsZSBhbmQgYmFiZWwtcGFja2V0LWxvZy1lbmFibGUuIEl0 J3MgdW5zcGVjaWZpZWQgYXMgdG8gd2hldGhlciBwcmV2aW91cyBkYXRhIGlzIGRpc2NhcmRlZCB3 aGVuIHRoZSBzdGF0cyBvciBsb2cgYXJlIGVuYWJsZWQsIG9yIHRoZSBuZXcgbG9nIGVudHJpZXMg YXJlIGFwcGVuZGVkIC8gZXhpc3RpbmcgY291bnRzIGluY3JlbWVudGVkLiBJIHRlbmQgdG8gYWdy ZWUgdGhhdCB0aGUgbGFjayBvZiBhIHN0YXRlbWVudCB3aWxsIGxlYWQgdG8gaW5jb25zaXN0ZW5j eSwgYW5kIHdvdWxkIHByZWZlciBjb25zaXN0ZW50IGJlaGF2aW9yLiBNYWhlc2ggYW5kIEkgaGFk IGEgYnJpZWYgZXhjaGFuZ2Ugd2hlcmUgd2UgZGlzYWdyZWVkIG9uIHdoYXQgdGhlIHByZWZlcnJl ZCBiZWhhdmlvciBzaG91bGQgYmUgLS0gd2hpY2ggc3VnZ2VzdHMgdGhlcmUgaXMgZGVmaW5pdGVs eSBhIHN0cm9uZyBsaWtlbGlob29kIG9mIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgY2hvb3Np bmcgZGlmZmVyZW50IGJlaGF2aW9yIGluIHRoZSBhYnNlbmNlIG9mIGd1aWRhbmNlLg0KDQpBbmQg dG8gY2xhcmlmeSB0aGUgZGlzYWdyZWVtZW50IGJldHdlZW4gQmFyYmFyYSBhbmQgSSB3YXMg4oCm DQoNClRoZSBCYWJlbCBpbmZvcm1hdGlvbiBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lIGEgYm9vbGVh biBmbGFnIHRoYXQgZW5hYmxlcy9kaXNhYmxlcyB0aGUgY29sbGVjdGlvbiBvZiBzdGF0aXN0aWNz LiBUaGUgQmFiZWwgZGF0YSBtb2RlbCBpbiBhZGRpdGlvbiBoYXMgYW4g4oCYYWN0aW9u4oCZIFlB Tkcgc3RhdGVtZW50IGRlZmluZWQgdG8gY2xlYXIgdGhlIHN0YXRpc3RpY3MgYmVpbmcgY29sbGVj dGVkLiBCYXJiYXJh4oCZcyBhc3N1bXB0aW9uIHdpdGggZW5hYmxpbmcgdGhlIGJvb2xlYW4gZmxh ZyB3YXMgdGhhdCBpdCB3b3VsZCBpbXBsaWNpdGx5IGNsZWFyIGFsbCB0aGUgc3RhdGlzdGljcy4g QnV0IHRoZSBkYXRhIG1vZGVsIHdpdGggYSBzZXBhcmF0ZSDigJhhY3Rpb27igJkgc3RhdGVtZW50 IHJlcXVpcmVzIGl0IHRvIGJlIGNhbGxlZCBleHBsaWNpdGx5IHRvIGNsZWFyIHRoZSBzdGF0aXN0 aWNzLg0KDQpVbmZvcnR1bmF0ZWx5LCB0aGVyZSBpc27igJl0IGEgd2F5IGluIFlBTkcgdG8gaW52 b2tlIHRoZSBjYWxsaW5nIG9mIGFuIOKAmGFjdGlvbuKAmSBzdGF0ZW1lbnQgd2hlbiBhIGNlcnRh aW4gYXR0cmlidXRlIHZhbHVlIHRvZ2dsZXMuIEltcGxlbWVudGF0aW9ucyBjYW4gY2hvb3NlIHRv IG1ha2UgaXQgaW1wbGljaXQgYnkgaW5jbHVkaW5nIHRoZSBjYWxsIHRvIHRoZSDigJhhY3Rpb27i gJkgc3RhdGVtZW50IGFzIHBhcnQgb2YgZW5hYmxpbmcgc3RhdGlzdGljcy4gQnV0IGl0IGlzIG5v dCBzb21ldGhpbmcgWUFORyBjYW4gZW5mb3JjZS4NCg0KU28gdGhlIHF1ZXN0aW9uIGlzIC0gc2hv dWxkIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCByZXF1aXJlIHRoYXQgZW5hYmxpbmcgb2Ygc3RhdGlz dGljcyBjb2xsZWN0aW9uIGFsc28gY2xlYXIgdGhlIHN0YXRpc3RpY3MgKGV2ZW4gaWYgdGhlIFlB TkcgbW9kZWwgY2Fubm90IGVuZm9yY2UgaXQpIG9yIGxlYXZlIGl0IHRvIGltcGxlbWVudGF0aW9u cyB0byBkZWNpZGUvZW5mb3JjZT8NCg0KQ2hlZXJzLg0KDQo+DQo+IEkgcmVhbGl6ZSB3ZSdyZSBw YXN0IGxhc3QgY2FsbC4gQnV0IEkgdGhpbmsgdGhlc2UgYXJlIGltcG9ydGFudC4NCj4NCj4gQmFy YmFyYQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBiYWJlbCBtYWlsaW5nIGxpc3QNCj4gYmFiZWxAaWV0Zi5vcmc8bWFpbHRvOmJhYmVsQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fYmFiZWwmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNR aWN2aklnJnI9TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPUVydmFyNllWUG5DZXdUV3BNR1VRZHZy V0RsLS1VVFJJS1Z5TW0tU0V2RjQmcz1EaGpZTkRITlJQTHNCaENQUGplNmU2NTN3TDlJX1ZDdmdw akVHeWtjMGFBJmU9Pg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWls LmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYmFiZWwgbWFpbGluZyBsaXN0DQpi YWJlbEBpZXRmLm9yZzxtYWlsdG86YmFiZWxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYmFiZWwm ZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLThzYzhTWThUcTR2cmZv ZyZtPUVydmFyNllWUG5DZXdUV3BNR1VRZHZyV0RsLS1VVFJJS1Z5TW0tU0V2RjQmcz1EaGpZTkRI TlJQTHNCaENQUGplNmU2NTN3TDlJX1ZDdmdwakVHeWtjMGFBJmU9Pg0KDQo= --_000_2D09D61DDFA73D4C884805CC7865E611537590F3GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo4NjczMzM4NTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjM4MjIyNDc3MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Rm9yIGxvZ3MsIEkgY2FuIHNlZSBzZXZlcmFsIGhvbGlzdGljIChub3QgZm9jdXNpbmcgb24g cmVzdWx0IG9mIGEgc2luZ2xlIGFjdGlvbikgc2V0cyBvZiBiZWhhdmlvcnMgYSB1c2VyIG1heSB3 YW50IHRvIGFjY29tcGxpc2ggYXQgdGhlIHRpbWUgdGhleeKAmXJlIGVuYWJsaW5nIGxvZ2dpbmcg KEnigJltIHdvcmRpbmcgdGhpcyBzcGVjaWZpY2FsbHkgdG8gYmUgdmFndWUgYWJvdXQgaG93IG1h bnkgY29tbWFuZHMgdGhlDQogdXNlciBtaWdodCBuZWVkIHRvIGlzc3VlKTo8bzpwPjwvbzpwPjwv cD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+T2xkIGZpbGUgaXMgZGVsZXRlZCBvciBvbGQgbWVtb3J5IHN0b3JlIGlz IGNsZWFyZWQvcmVsZWFzZWQsIG5ldyBmaWxlIGlzIHN0YXJ0ZWQgb3IgbWVtb3J5IHNwYWNlIGNy ZWF0ZWQgd2l0aCBuZXcgcmVmZXJlbmNlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPk9sZCBmaWxlIC8gbWVtb3J5IHN0b3JlIHN0YXlzLCBuZXcgZmlsZSAvIG1lbW9yeSBzdG9y ZSBpcyBzdGFydGVkIHdpdGggbmV3IHJlZmVyZW5jZS4gLy8gdGhlcmUgaXMgbm8gbG9uZ2VyIGEg cmVmZXJlbmNlIHNwZWNpZmllZCBpbiB0aGUgQmFiZWwgaW5mbyBtb2RlbCB0aGF0IHdvdWxkIHBv aW50IHRvIHRoZSBvbGQNCiBmaWxlIG9yIG1lbW9yeTsgc29tZSBETSBzY2hlbWVzLCBsaWtlIFRS LTE4MSwgd291bGQgc3RpbGwgYWxsb3cgYWNjZXNzIHRvIHRoZSBsb2cgKHRoZSBCYWJlbCBwYWNr ZXQgbG9nIGlzIGEgcmVmZXJlbmNlIHRvIGFuIGVudHJ5IGluIGEgbG9nIG9iamVjdCk7IHdoZXJl IHRoZSBsb2cgY2FtZSBmcm9tLCB0aG91Z2gsIHdvdWxkIGJlIGxvc3QgdW5sZXNzIGl0IHdhcyBp bmNvcnBvcmF0ZWQgaW4gdGhlIGZpbGVuYW1lIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbg0KIG9yIG90 aGVyd2lzZSBjb250YWluZWQgaW4gbG9nIG1ldGFkYXRhOyBtYXkgbmVlZCB0byBjb25zaWRlciBp ZiBzb21ldGhpbmcgbmVlZHMgdG8gYmUgc2FpZCBhYm91dCBwZXJzaXN0ZW5jZSBhY3Jvc3MgcmVi b290cw0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+RXhpc3RpbmcgcmVmZXJl bmNlZCBmaWxlIC8gbWVtb3J5IHN0b3JlIGlzIGFwcGVuZGVkLjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPkV4aXN0aW5nIHJlZmVyZW5jZWQgZmlsZSAvIG1lbW9yeSBzdG9yZSBp cyBjbGVhcmVkIGFuZCB0aGVuIGFwcGVuZGVkLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xIGFuZCA0IGFyZSB2ZXJ5IHNpbWlsYXIgaW4gZWZmZWN0LiA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Tm90ZSB0aGF0IHRoZXJlIGFyZSBiZWhhdmlvcnMgdGhhdCBjYW4gYmUgZW5mb3JjZWQg YnkgdGhlIG1vZGVsLCBhbmQgYmVoYXZpb3JzIHRoYXQgYXJlIGltcG9zZWQgb24gY29tcGxpYW50 IGltcGxlbWVudGF0aW9ucyAoZS5nLiwgbWFuZGF0b3J5IHRvIGltcGxlbWVudCkuIEnigJltIG5v dCBjb25jZXJuZWQgd2l0aCB3aGV0aGVyIG9yIG5vdCBhIGRlc2lyZWQgYmVoYXZpb3IgaXMgZW5m b3JjZWQgYnkgYSBtb2RlbC4NCiBJ4oCZbSBwZXJmZWN0bHkgc2F0aXNmaWVkIGZvciBkZXNpcmVk IGJlaGF2aW9ycyB0byBiZSBpbXBvc2VkIHRocm91Z2ggaW1wbGVtZW50YXRpb24gY29tcGxpYW5j ZS4gVGhlIHF1ZXN0aW9uIGZvciBtZSBpcyB3aGF0IHRoZSBkZXNpcmVkIGJlaGF2aW9yIGlzLCBh bmQgbm90IHdoZXRoZXIgb3Igbm90IGFueSBwYXJ0aWN1bGFyIERNIHNjaGVtZSBoYXMgdGhlIGFi aWxpdHkgdG8gZW5mb3JjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gdGhpbmtpbmcg KGJhc2VkIG9uIG9waW5pb25zIGV4cHJlc3NlZCB0byBkYXRlKSB0aGF0IGluIHRoZSBhYnNlbmNl IG9mIGEgbG9nIOKAnHJlc2V04oCdLCBiZWhhdmlvciAzIChhcHBlbmRpbmcpIG1pZ2h0IGJlIGV4 cGVjdGVkIHRvIG9jY3VyIChub3RlIHRoZSBpbmZvIG1vZGVsIHNheXMgbm90aGluZyBhYm91dCBs aW1pdGluZyBmaWxlc2l6ZSDigJMgaXTigJlzIHVwIHRvIHRoZSBETSBvciBpbXBsZW1lbnRhdGlv biB0bw0KIGRvIG9yIHNheSBzb21ldGhpbmcgd3J0IG1heCBmaWxlc2l6ZSBhbmQgd2hhdCB0byBk byB3aGVuIG1heCBpcyByZWFjaGVkKS4gSWYgd2Ugd2VyZSB0byBoYXZlIGEgbG9nIHJlc2V0LCBJ IHRoaW5rIGVpdGhlciBiZWhhdmlvciAxIG9yIDQgd291bGQgYmUgZmluZSwgYW5kIGRvbuKAmXQg dGhpbmsgd2XigJlkIG5lZWQgdG8gZGljdGF0ZSBvbmUgb3IgdGhlIG90aGVyIGluIHRoZSBpbmZv IG1vZGVsLiBJ4oCZZCBwcmVmZXIgdG8gYXZvaWQgMiwgYmVjYXVzZQ0KIEkgdGhpbmsgaXQgcG9z ZXMgYSBkYW5nZXIgb2YgbWVtb3J5IGxlYWtzLiBJdCBtYXkgYWxzbyBiZSB1c2VmdWwgdG8gaW5j bHVkZSBhIHN0YXRlbWVudCB0aGF0IHRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIGZvciBsb2dzIHRv IHBlcnNpc3QgYWNyb3NzIHJlYm9vdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhcmJhcmE8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBNYWhlc2ggSmV0aGFuYW5kYW5pICZsdDttamV0aGFuYW5kYW5pQGdtYWlsLmNvbSZndDsg PGJyPg0KPGJyPg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQmFyYmFyYSw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvb2QgcG9pbnQuIFdoYXQg d291bGQgeW91IGV4cGVjdCB0aGUgcmVzZXQgYWN0aW9uIG9uIHBhY2tldCBsb2cgdG8gZG8/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBk aWZmZXJlbmNlIGJldHdlZW4gcGFja2V0IGxvZyBhbmQgc3RhdGlzdGljcyBmcm9tIGEgZGF0YSBt b2RlbCBpcyB0aGF0LCBzdGF0aXN0aWNzIGFyZSBtYWludGFpbmVkIGJ5IHRoZSBkYXRhIG1vZGVs LiBBcyBzdWNoIGEgcmVzZXQgY2F1c2VzIHRoZSB2YWx1ZXMgaW4gdGhlIGRhdGEgbW9kZWwgdG8g YmUgY2xlYXJlZC4gRm9yIHRoZSBwYWNrZXQgbG9nLCBhbGwgdGhhdCB0aGUgbW9kZWwgZG9lcyBp cyBtYWludGFpbg0KIGEgcG9pbnRlciB0byBhIFVSTC9maWxlIHdoZXJlIHRoZSBsb2cgaXMgbWFp bnRhaW5lZC4gSXQgZG9lcyBub3QgbWFpbnRhaW4gdGhlIGNvbnRlbnRzIG9mIHRoYXQgbG9nLiBB IHJlc2V0IGFjdGlvbiBvbiBhbiBvYmplY3QgdGhhdCBpcyBleHRlcm5hbCB0byB0aGUgbW9kZWwg Y2Fubm90IGJlIGVuZm9yY2VkIGJ5IHRoZSBtb2RlbC4gQWxsIHRoZSBtb2RlbCBjYW4gZG8gaXMg Y2xlYXIgdGhlIHBvaW50ZXIsIGJ1dCBJIGdhdGhlciB0aGF0IGlzIG5vdA0KIHdoYXQgeW91IGFy ZSBsb29raW5nIGZvciBpdCB0byBkby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDIwLCAyMDIwLCBhdCA4OjI1IEFNLCBTVEFSSywgQkFS QkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iPmJzNzY1MkBhdHQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0IHdvdWxkIHN1Z2dlc3Qgd2Ugc2hvdWxkIGFkZCBhIHJlc2V0IGFjdGlvbiBmb3Ig dGhlIHBhY2tldCBsb2cuIFdlIGRvbuKAmXQgY3VycmVudGx5IGhhdmUgb25lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj5Gcm9tOjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RG9uYWxkIEVh c3RsYWtlICZsdDs8YSBocmVmPSJtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbSI+ZDNlM2UzQGdtYWls LmNvbTwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIE1haGVzaCBhbmQgQmFyYmFyYSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFraW5n IGp1c3QgYXMgYSBXRyBtZW1iZXIsIGl0IHNlZW1zIHRvIG1lIG1vcmUgZmxleGlibGUgZm9yIHRo ZSBjbGVhcmluZyBvZiBzdGF0aXN0aWNzIGFuZCB0aGUgZW5hYmxlbWVudCBvZiBzdGF0aXN0aWNz IHRvIGJlIHNlcGFyYXRlIGFjdGlvbnMuIFlvdSBjYW4gYWx3YXlzIGRvIGJvdGggaWYgdGhhdCdz IHdodCB5b3Ugd2FudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MsPGJyPg0KRG9uYWxkPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4N CiZuYnNwO0RvbmFsZCBFLiBFYXN0bGFrZSAzcmQgJm5ic3A7ICYjNDM7MS01MDgtMzMzLTIyNzAg KGNlbGwpPGJyPg0KJm5ic3A7MjM4NiBQYW5vcmFtaWMgQ2lyY2xlLCBBcG9wa2EsIEZMIDMyNzAz IFVTQTxicj4NCiZuYnNwOzxhIGhyZWY9Im1haWx0bzpkM2UzZTNAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZDNlM2UzQGdtYWlsLmNvbTwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy aSwgSmFuIDE3LCAyMDIwIGF0IDM6MTMgUE0gTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQomZ3Q7IE9uIEphbiAxNywgMjAyMCwgYXQgNzozMiBBTSwgU1RBUkssIEJBUkJBUkEgSCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJzNzY1MkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+YnM3NjUyQGF0dC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PGJy Pg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQomZ3Q7IFRoZXJlIGFyZSAyIGl0ZW1zIHJlbGF0ZWQgdG8gdGhlIGluZm8vZGF0YSBtb2Rl bHMgdGhhdCBoYXZlIGJlZW4gc3dpcmxpbmcgYXJvdW5kIGluIG15IGhlYWQgb3ZlciB0aGUgcGFz dCBtb250aC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQomZ3Q7IDEuIFNpbmNlIHRoZSBtb3N0IHJlY2VudCBkcmFmdHMgb2YgcmZjNjEyNmJp cyBub3cgaGF2ZSAyIGV4YW1wbGVzIG9mIGluaXRpYWwgaW50ZXJ2YWwgc2V0dGluZ3MgKGZvciBj YXNlcyB3aGVyZSBmYXN0IGNvbnZlcmdlbmNlIGlzIGRlc2lyZWQsIG9yIHdoZXJlIHNsb3cgY29u dmVyZ2VuY2UgaXMgYWNjZXB0YWJsZSBhbmQgbGVzcyBjaGF0dGluZXNzIGlzIGRlc2lyZWQpLCBJ IGRvbid0IGxpa2UgdGhhdCB3ZSBoYXZlIG5vIG1lYW5zIGZvciB0aGUNCiB1c2VyIHRvIGV4cHJl c3Mgd2hhdCB0aGVpciBwcmVmZXJlbmNlIGlzIGFyb3VuZCB0aGlzIChpbiBjYXNlIGFuIGltcGxl bWVudGF0aW9uIGNvdWxkIHN1cHBvcnQgYm90aCBjYXNlcykuIFNob3VsZCB3ZSBoYXZlIHNvbWV0 aGluZyBhdCB0aGUgdG9wIGxldmVsIG9mIHRoZSBtb2RlbCBsaWtlOjxicj4NCiZndDsgYm9vbGVh biZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg cncgY29udmVyZ2UtZmFzdDs8YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsmbmJzcDsgJm5ic3A7Y29udmVyZ2UtZmFzdDom bmJzcDsgSW5kaWNhdGVzIHdoZXRoZXIgdGhlIHVzZXIgd2FudHMgdGhlIG5ldHdvcmsgdG8gY29u dmVyZ2U8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHF1aWNrbHkgKHdoaWNoIHdpbGwgY2F1c2UgQmFi ZWwgbWVzc2FnZXMgdG8gYmUgc2VudCBtb3JlIGZyZXF1ZW50bHkpLCBvcjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyBwcmVmZXJzIGZld2VyIEJhYmVsIG1lc3NhZ2VzIHdpdGggc2xvd2Vy IHRpbWUgdG8gY29udmVyZ2VuY2UuJm5ic3A7IEZhc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgY29udmVyZ2VuY2UgaXMgZGVzaXJlZCBpZiAmcXVvdDt0cnVlJnF1b3Q7LiBBbiBpbXBs ZW1lbnRhdGlvbiBNQVkgY2hvb3NlIHRvIGV4cG9zZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyB0aGlzIHBhcmFtZXRlciBhcyByZWFkLW9ubHkgKCZxdW90O3JvJnF1b3Q7KS48YnI+DQom Z3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CiZndDsgMi4gSW4gQkJGLCBJIGdvdCBhIGNvbW1lbnQgcmVsYXRlZCB0byBiYWJlbC1zdGF0cy1l bmFibGUgYW5kIGJhYmVsLXBhY2tldC1sb2ctZW5hYmxlLiBJdCdzIHVuc3BlY2lmaWVkIGFzIHRv IHdoZXRoZXIgcHJldmlvdXMgZGF0YSBpcyBkaXNjYXJkZWQgd2hlbiB0aGUgc3RhdHMgb3IgbG9n IGFyZSBlbmFibGVkLCBvciB0aGUgbmV3IGxvZyBlbnRyaWVzIGFyZSBhcHBlbmRlZCAvIGV4aXN0 aW5nIGNvdW50cyBpbmNyZW1lbnRlZC4gSSB0ZW5kIHRvDQogYWdyZWUgdGhhdCB0aGUgbGFjayBv ZiBhIHN0YXRlbWVudCB3aWxsIGxlYWQgdG8gaW5jb25zaXN0ZW5jeSwgYW5kIHdvdWxkIHByZWZl ciBjb25zaXN0ZW50IGJlaGF2aW9yLiBNYWhlc2ggYW5kIEkgaGFkIGEgYnJpZWYgZXhjaGFuZ2Ug d2hlcmUgd2UgZGlzYWdyZWVkIG9uIHdoYXQgdGhlIHByZWZlcnJlZCBiZWhhdmlvciBzaG91bGQg YmUgLS0gd2hpY2ggc3VnZ2VzdHMgdGhlcmUgaXMgZGVmaW5pdGVseSBhIHN0cm9uZyBsaWtlbGlo b29kIG9mDQogZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBjaG9vc2luZyBkaWZmZXJlbnQgYmVo YXZpb3IgaW4gdGhlIGFic2VuY2Ugb2YgZ3VpZGFuY2UuPGJyPg0KPGJyPg0KQW5kIHRvIGNsYXJp ZnkgdGhlIGRpc2FncmVlbWVudCBiZXR3ZWVuIEJhcmJhcmEgYW5kIEkgd2FzIOKApjxicj4NCjxi cj4NClRoZSBCYWJlbCBpbmZvcm1hdGlvbiBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lIGEgYm9vbGVh biBmbGFnIHRoYXQgZW5hYmxlcy9kaXNhYmxlcyB0aGUgY29sbGVjdGlvbiBvZiBzdGF0aXN0aWNz LiBUaGUgQmFiZWwgZGF0YSBtb2RlbCBpbiBhZGRpdGlvbiBoYXMgYW4g4oCYYWN0aW9u4oCZIFlB Tkcgc3RhdGVtZW50IGRlZmluZWQgdG8gY2xlYXIgdGhlIHN0YXRpc3RpY3MgYmVpbmcgY29sbGVj dGVkLiBCYXJiYXJh4oCZcyBhc3N1bXB0aW9uIHdpdGggZW5hYmxpbmcNCiB0aGUgYm9vbGVhbiBm bGFnIHdhcyB0aGF0IGl0IHdvdWxkIGltcGxpY2l0bHkgY2xlYXIgYWxsIHRoZSBzdGF0aXN0aWNz LiBCdXQgdGhlIGRhdGEgbW9kZWwgd2l0aCBhIHNlcGFyYXRlIOKAmGFjdGlvbuKAmSBzdGF0ZW1l bnQgcmVxdWlyZXMgaXQgdG8gYmUgY2FsbGVkIGV4cGxpY2l0bHkgdG8gY2xlYXIgdGhlIHN0YXRp c3RpY3MuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCjxicj4NClVuZm9ydHVuYXRlbHksIHRoZXJlIGlzbuKAmXQgYSB3YXkgaW4gWUFORyB0byBp bnZva2UgdGhlIGNhbGxpbmcgb2YgYW4g4oCYYWN0aW9u4oCZIHN0YXRlbWVudCB3aGVuIGEgY2Vy dGFpbiBhdHRyaWJ1dGUgdmFsdWUgdG9nZ2xlcy4gSW1wbGVtZW50YXRpb25zIGNhbiBjaG9vc2Ug dG8gbWFrZSBpdCBpbXBsaWNpdCBieSBpbmNsdWRpbmcgdGhlIGNhbGwgdG8gdGhlIOKAmGFjdGlv buKAmSBzdGF0ZW1lbnQgYXMgcGFydCBvZiBlbmFibGluZyBzdGF0aXN0aWNzLiBCdXQNCiBpdCBp cyBub3Qgc29tZXRoaW5nIFlBTkcgY2FuIGVuZm9yY2UuPGJyPg0KPGJyPg0KU28gdGhlIHF1ZXN0 aW9uIGlzIC0gc2hvdWxkIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCByZXF1aXJlIHRoYXQgZW5hYmxp bmcgb2Ygc3RhdGlzdGljcyBjb2xsZWN0aW9uIGFsc28gY2xlYXIgdGhlIHN0YXRpc3RpY3MgKGV2 ZW4gaWYgdGhlIFlBTkcgbW9kZWwgY2Fubm90IGVuZm9yY2UgaXQpIG9yIGxlYXZlIGl0IHRvIGlt cGxlbWVudGF0aW9ucyB0byBkZWNpZGUvZW5mb3JjZT88YnI+DQo8YnI+DQpDaGVlcnMuPGJyPg0K PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQomZ3Q7IEkgcmVhbGl6ZSB3ZSdyZSBwYXN0IGxhc3QgY2FsbC4gQnV0IEkgdGhpbmsg dGhlc2UgYXJlIGltcG9ydGFudC48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCiZndDsgQmFyYmFyYTxicj4NCiZndDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgYmFi ZWwgbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86YmFiZWxAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5iYWJlbEBpZXRmLm9yZzwvc3Bhbj48 L2E+PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmFtcDtkPUR3TUZh USZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJm b2cmYW1wO209RXJ2YXI2WVZQbkNld1RXcE1HVVFkdnJXRGwtLVVUUklLVnlNbS1TRXZGNCZhbXA7 cz1EaGpZTkRITlJQTHNCaENQUGplNmU2NTN3TDlJX1ZDdmdwakVHeWtjMGFBJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmFiZWw8L3NwYW4+PC9hPjxicj4NCjxicj4NCk1haGVzaCBK ZXRoYW5hbmRhbmk8YnI+DQo8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tamV0aGFuYW5kYW5p QGdtYWlsLmNvbTwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpiYWJlbCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86YmFiZWxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5iYWJlbEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19iYWJlbCZhbXA7ZD1Ed01GYVEmYW1w O2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFt cDttPUVydmFyNllWUG5DZXdUV3BNR1VRZHZyV0RsLS1VVFJJS1Z5TW0tU0V2RjQmYW1wO3M9RGhq WU5ESE5SUExzQmhDUFBqZTZlNjUzd0w5SV9WQ3ZncGpFR3lrYzBhQSZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2JhYmVsPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E611537590F3GAALPA1MSGUSRBF_-- From nobody Tue Jan 21 10:00:16 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF01120922 for ; Tue, 21 Jan 2020 10:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-Q3LYbeQHNN for ; Tue, 21 Jan 2020 10:00:09 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7026120123 for ; Tue, 21 Jan 2020 10:00:09 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00LHx3X7020275; Tue, 21 Jan 2020 13:00:09 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2xp4v0ab8q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 13:00:09 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00LI07vg023041; Tue, 21 Jan 2020 13:00:08 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00LI03e8020281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2020 13:00:03 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 0DAFA4009E84; Tue, 21 Jan 2020 18:00:03 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30486.vci.att.com (Service) with ESMTPS id E71AE4009E77; Tue, 21 Jan 2020 18:00:02 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0468.000; Tue, 21 Jan 2020 13:00:00 -0500 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= CC: "'babel-users@lists.alioth.debian.org'" , "'babel@ietf.org'" Thread-Topic: [Babel-users] MAC rekeying in babeld and information model Thread-Index: AQHVzJ0q8jDHxzeyx0S6Gir5zXgjYKfvDLIA///hz8CAAAgi8IADWLeAgAFttWCAAJRwgIABKWGAgAABzgD//+/JUA== Date: Tue, 21 Jan 2020 18:00:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61153759233@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877e1r6y0f.wl-jch@irif.fr> <875zhaqq5v.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E61153754234@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611537542C9@GAALPA1MSGUSRBF.ITServices.sbc.com> <878sm3a8qy.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E61153757B47@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfq1nbsu.wl-jch@irif.fr> <87v9p5lyiw.fsf@toke.dk> <8736c8ylc5.wl-jch@irif.fr> In-Reply-To: <8736c8ylc5.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.112.151] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.634 definitions=2020-01-21_06:2020-01-21, 2020-01-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 adultscore=0 priorityscore=1501 spamscore=0 phishscore=0 mlxscore=0 impostorscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001210137 Archived-At: Subject: Re: [babel] [Babel-users] MAC rekeying in babeld and information model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 18:00:15 -0000 > From: Juliusz Chroboczek >=20 > > As I just replied in the other thread: The Bird implementation is > > going to have this facility no matter what we specify in the spec, but > > I'm fine with having it optional, or omitting it from the spec > > entirely, as long as we don't forbid having a key-use parameter :) >=20 > It is my understanding that it's already effectively optional -- it can b= e > exported as read-only (paragraph 3.9 of the draft). I suggest we let Bar= bara > decide whether she wants to explicitly mark it as optional. I find it confusing to have parameters an implementation has no use for. Th= e "MAY choose to expose as read-only" is actually a bit awkward in this cas= e, since ideally, users can add entries to the object (in which case it's w= eird to have read-only parameters set by the implementation). It's not disa= llowed -- just weird. I would like to mark them optional to implement. I do= n't think this would impact the YANG model (because the YANG model doesn't = deal with the mandatory/optional to implement aspects of the spec)? Barbara From nobody Tue Jan 21 11:49:27 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577E0120890 for ; Tue, 21 Jan 2020 11:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR-o27efyk3k for ; Tue, 21 Jan 2020 11:49:21 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 B633912084D for ; Tue, 21 Jan 2020 11:49:21 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id a15so4116089otf.1 for ; Tue, 21 Jan 2020 11:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3VkAExEKHP2IVAKxGthUPE5XndQN/SUrZ6CkXigmcUI=; b=M94jYA9XbTQgjP4llOSokhgp9BzX+LSlwyFY3JH5lj3OOtM1ofkNW1afXqCZNm/fyA 8wjXXEf6vEe7yAW1UQ0GifmDU1CqI6zq8VJiTThs+kjINBSgY95wW6RqWWjUYnvRogBV xaKWb5zLdmPifvcUbenP4gL4j9hn3ffhHMl8t1C8wSqRO+zYK0eDR6j0D8+XETBGS30R RZ/ldWZSyh81N4OptRz/7h8+ls4U+cBIWg+c/BYxEVZ7pVlnmL+J/3W+0IXYaRl3/DmD Dn+JWb/InsqrU83h4WL4rzpWQVwi+0HxZ/4NnSwus3LcOfn98IEBBI5KKFiZ9ENV9ANQ dAzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3VkAExEKHP2IVAKxGthUPE5XndQN/SUrZ6CkXigmcUI=; b=m2M2w/b7ojUgM+zlGyrBiE0rpsUZneGPitW2znKcdwXFKASeyTWAseDpAgPiodvZ38 Agc7tNrZkYKXgJQ/OET5I3a5kYu7iFoCOSb8k5UUp1hh5BH8NI3yWjDv23zKEUH5Glck Cr+BADqIkPsLi2wourZn3M1vcdpaO7hpA9aHmeRjyUtn+16zWy0Ca6F6OzS5VStWKS7L 9dqwwjwkTvqYDz34bHr+8ggWMtBHdYktMDW6yQflWIdclT2Hq1VD3dmmHbvUrhF21G/m i2ciRbQ6+z023KAaBRz4DNFw8x3Vv8Ljo4E7ghZel5GnfHQm9KbMwd4kl4JL6W4iuPC9 7dVQ== X-Gm-Message-State: APjAAAXCVOXk7RBGTZ91wLunG1BHTveYtFF3tYLHqey4ndY6jwFSEfPM wpmGTfrdMivzt93dSdg/PuHFR6OufvqD0wI4ny2WQAFK X-Google-Smtp-Source: APXvYqxbZw9oAKLubzTck5R/i1K2rdIZshTCHCORQev0M/e5yg/bXJnDkCGxEZ+KBYAwMokyqZy3zIRyLKoW+sdpeP0= X-Received: by 2002:a9d:3b09:: with SMTP id z9mr4845680otb.195.1579636160798; Tue, 21 Jan 2020 11:49:20 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Tue, 21 Jan 2020 20:49:40 +0100 Message-ID: To: "Barbara H. Stark" , Mahesh Jethanandani , "babel@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] [patch] Info model: fix little inconsistencies in naming, use singular for objects. X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 19:49:24 -0000 Hello Barbara, hello Mahesh, While reading carefully the Information Model with all the recent discussions, I've found some small inconsistencies in the naming of objects which I've fixed in the patch below. What bothered me more was that the name of object types was pluralized. I'm much more comfortable with singular, for instance I find it better to read "Definition of babel-route-obj" and then the composition of the object, rather than "Definition of babel-routes-obj": why was it pluralized? I also find it better to have the field (for instance) "babel-routes<0..*>;" be a set of objects of type "babel-route-obj". -- Antonin --- draft-ietf-babel-information-model.md | 56 +++++++++++++-------------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/draft-ietf-babel-information-model.md b/draft-ietf-babel-information-model.md index ad2a64a..9b66f2d 100644 --- a/draft-ietf-babel-information-model.md +++ b/draft-ietf-babel-information-model.md @@ -15,7 +15,7 @@ title: Babel Information Model area: Routing wg: Babel routing protocol kw: Babel -date: 2019 +date: 2020 author: - ins: B. H. Stark name: Barbara Stark @@ -332,10 +332,10 @@ model definitions in subsequent sections, the error is in this overview. [boolean rw babel-stats-enable;] [operation babel-stats-reset;] babel-constants-obj ro babel-constants; - babel-interfaces-obj ro babel-interfaces<0..*>; - babel-routes-obj ro babel-routes<0..*>; - [babel-mac-key-sets-obj rw babel-mac-key-sets<0..*>;] - [babel-dtls-cert-sets-obj rw babel-dtls-cert-sets<0..*>;] + babel-interface-obj ro babel-interfaces<0..*>; + babel-route-obj ro babel-routes<0..*>; + [babel-mac-key-set-obj rw babel-mac-key-sets<0..*>;] + [babel-dtls-cert-set-obj rw babel-dtls-cert-sets<0..*>;] } babel-information-obj; ~~~~ {: artwork-align="left"} @@ -407,14 +407,14 @@ babel-routes: node. babel-mac-key-sets: -: A babel-mac-key-sets-obj object. If this +: A set of babel-mac-key-set-obj objects. If this object is implemented, it provides access to parameters related to the MAC security mechanism. An implementation MAY choose to expose this object as read-only ("ro"). babel-dtls-cert-sets: -: A babel-dtls-cert-sets-obj object. If this +: A set of babel-dtls-cert-set-obj objects. If this object is implemented, it provides access to parameters related to the DTLS security mechanism. An implementation MAY choose @@ -446,7 +446,7 @@ babel-mcast-group: to expose this parameter as read-only ("ro"). -## Definition of babel-interfaces-obj +## Definition of babel-interface-obj ~~~~ @@ -468,8 +468,8 @@ babel-mcast-group: [boolean rw babel-packet-log-enable;] [reference ro babel-packet-log;] [babel-if-stats-obj ro babel-if-stats;] - babel-neighbors-obj ro babel-neighbors<0..*>; - } babel-interfaces-obj; + babel-neighbor-obj ro babel-neighbors<0..*>; + } babel-interface-obj; ~~~~ {: artwork-align="left"} @@ -594,7 +594,7 @@ babel-if-stats: : Statistics collection object for this interface. babel-neighbors: -: A set of babel-neighbors-obj objects. +: A set of babel-neighbor-obj objects. ## Definition of babel-if-stats-obj @@ -631,7 +631,7 @@ babel-received-packets: : A count of the number of Babel packets received on this interface. -## Definition of babel-neighbors-obj +## Definition of babel-neighbor-obj ~~~~ object { @@ -645,7 +645,7 @@ babel-received-packets: [uint ro babel-ucast-hello-interval;] [uint ro babel-rxcost;] [uint ro babel-cost;] - } babel-neighbors-obj; + } babel-neighbor-obj; ~~~~ {: artwork-align="left"} @@ -727,7 +727,7 @@ babel-cost: This is a 16-bit unsigned integer. -## Definition of babel-routes-obj +## Definition of babel-route-obj ~~~~ object { @@ -741,7 +741,7 @@ babel-cost: ip-address ro babel-route-next-hop; boolean ro babel-route-feasible; boolean ro babel-route-selected; - } babel-routes-obj; + } babel-route-obj; ~~~~ {: artwork-align="left"} @@ -808,13 +808,13 @@ babel-route-selected: is being advertised). -## Definition of babel-mac-key-sets-obj +## Definition of babel-mac-key-set-obj ~~~~ object { boolean rw babel-mac-default-apply; - babel-mac-keys-obj rw babel-mac-keys<0..*>; - } babel-mac-obj; + babel-mac-key-obj rw babel-mac-keys<0..*>; + } babel-mac-key-set-obj; ~~~~ {: artwork-align="left"} @@ -831,9 +831,9 @@ babel-mac-default-apply: to expose this parameter as read-only ("ro"). babel-mac-keys: -: A set of babel-mac-keys-obj objects. +: A set of babel-mac-key-obj objects. -## Definition of babel-mac-keys-obj +## Definition of babel-mac-key-obj ~~~~ object { @@ -843,7 +843,7 @@ babel-mac-keys: binary -- babel-mac-key-value; string rw babel-mac-key-algorithm; [operation babel-mac-key-test;] - } babel-mac-keys-obj; + } babel-mac-key-obj; ~~~~ {: artwork-align="left"} @@ -902,13 +902,13 @@ babel-mac-test: as a binary string. -## Definition of babel-dtls-cert-sets-obj +## Definition of babel-dtls-cert-set-obj ~~~~ object { boolean rw babel-dtls-default-apply; - babel-dtls-certs-obj rw babel-dtls-certs<0..*>; - } babel-dtls-obj; + babel-dtls-cert-obj rw babel-dtls-certs<0..*>; + } babel-dtls-cert-set-obj; ~~~~ {: artwork-align="left"} @@ -924,14 +924,14 @@ babel-dtls-default-apply: An implementation MAY choose to expose this parameter as read-only ("ro"). -babel-dtls-certs: -: A set of babel-dtls-keys-obj objects. This contains both certificates +babel-dtls-cert: +: A set of babel-dtls-cert-obj objects. This contains both certificates for this implementation to present for authentication, and to accept from others. Certificates with a non-empty babel-cert-private-key can be presented by this implementation for authentication. -## Definition of babel-dtls-certs-obj +## Definition of babel-dtls-cert-obj ~~~~ object { @@ -940,7 +940,7 @@ babel-dtls-certs: string rw babel-cert-type; binary -- babel-cert-private-key; [operation babel-cert-test;] - } babel-dtls-certs-obj; + } babel-dtls-cert-obj; ~~~~ {: artwork-align="left"} -- 2.25.0 From nobody Tue Jan 21 13:26:37 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF581208FA for ; Tue, 21 Jan 2020 13:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YWdl_jjD0aV for ; Tue, 21 Jan 2020 13:26:28 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 30FA01208AE for ; Tue, 21 Jan 2020 13:26:28 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 00LL6WBY007878; Tue, 21 Jan 2020 16:26:25 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2xp78xtvnx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 16:26:25 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00LLQO2O020390; Tue, 21 Jan 2020 16:26:25 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 00LLQIwH020224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2020 16:26:18 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 902D4400AE35; Tue, 21 Jan 2020 21:26:18 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30487.vci.att.com (Service) with ESMTPS id 74CFD400AE34; Tue, 21 Jan 2020 21:26:18 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.85]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Tue, 21 Jan 2020 16:26:18 -0500 From: "STARK, BARBARA H" To: =?utf-8?B?J0FudG9uaW4gRMOpY2ltbyc=?= , "'Mahesh Jethanandani'" , "'babel@ietf.org'" Thread-Topic: [babel] [patch] Info model: fix little inconsistencies in naming, use singular for objects. Thread-Index: AQHV0JPjhrwDJEDQaUmtIxXf5gS+96f1nYcA Date: Tue, 21 Jan 2020 21:26:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611537595E5@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.112.151] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_05:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 impostorscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 adultscore=0 phishscore=0 mlxscore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001210157 Archived-At: Subject: Re: [babel] [patch] Info model: fix little inconsistencies in naming, use singular for objects. X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 21:26:36 -0000 SGkgQW50b25pbiwNCkkgZG9uJ3QgcmVtZW1iZXIgd2h5IEkgbWFkZSB0aGVtIHBsdXJhbC4gSSdt IHN1cmUgaXQgd2FzIGJlY2F1c2UgSSBzYXcgaXQgZG9uZSB0aGF0IHdheSwgc29tZXdoZXJlLiBJ IHRyeSB0byBhdm9pZCBoYXZpbmcgb3JpZ2luYWwgdGhvdWdodHMuDQpCdXQgSSBhZ3JlZSB3aXRo IHlvdSBjb21wbGV0ZWx5LiBJbiBteSBCQkYgVFItMTgxIGRhdGEgbW9kZWwsIHRoZSBvYmplY3Qg bmFtZXMgYXJlIGFsbCBzaW5ndWxhciwgYmVjYXVzZSB0aGF0J3MgdGhlIEJCRiBjb252ZW50aW9u Lg0KU2luY2UgaXQgbG9va3MgbGlrZSB3ZSd2ZSBnb3Qgc29tZSBvdGhlciBsaXR0bGUgY2hhbmdl cyBjb21pbmcgaW4sIGl0IHdvdWxkbid0IGJvdGhlciBtZSB0byBtYWtlIHRoZSBvYmplY3QgbmFt ZXMgYWxsIHNpbmd1bGFyLiBCdXQgSSBkb24ndCBrbm93IGhvdyBNYWhlc2ggZmVlbHMgYWJvdXQg dGhpcy4gSSBrbm93IHRoZSBZQU5HIG1vZGVsIG1haW50YWlucyB0aGUgcGx1cmFsIGZvcm1zOyBi dXQgdGhlIGxpc3QgbmFtZXMgd291bGQgc3RpbGwgYmUgcGx1cmFsIChvbmx5IHRoZSAtb2JqIGRl ZmluaXRpb25zIHdvdWxkIGNoYW5nZSB0byBzaW5ndWxhcikgLS0gc28gdGhlIFlBTkcgbW9kZWwg d291bGRuJ3QgbmVlZCB0byBjaGFuZ2UuIA0KQmFyYmFyYQ0KIA0KPiBIZWxsbyBCYXJiYXJhLCBo ZWxsbyBNYWhlc2gsDQo+IA0KPiBXaGlsZSByZWFkaW5nIGNhcmVmdWxseSB0aGUgSW5mb3JtYXRp b24gTW9kZWwgd2l0aCBhbGwgdGhlIHJlY2VudCBkaXNjdXNzaW9ucywNCj4gSSd2ZSBmb3VuZCBz b21lIHNtYWxsIGluY29uc2lzdGVuY2llcyBpbiB0aGUgbmFtaW5nIG9mIG9iamVjdHMgd2hpY2gg SSd2ZQ0KPiBmaXhlZCBpbiB0aGUgcGF0Y2ggYmVsb3cuDQo+IA0KPiBXaGF0IGJvdGhlcmVkIG1l IG1vcmUgd2FzIHRoYXQgdGhlIG5hbWUgb2Ygb2JqZWN0IHR5cGVzIHdhcyBwbHVyYWxpemVkLg0K PiBJJ20gbXVjaCBtb3JlIGNvbWZvcnRhYmxlIHdpdGggc2luZ3VsYXIsIGZvciBpbnN0YW5jZSBJ IGZpbmQgaXQgYmV0dGVyIHRvIHJlYWQNCj4gIkRlZmluaXRpb24gb2YgYmFiZWwtcm91dGUtb2Jq IiBhbmQgdGhlbiB0aGUgY29tcG9zaXRpb24gb2YgdGhlIG9iamVjdCwNCj4gcmF0aGVyIHRoYW4g IkRlZmluaXRpb24gb2YNCj4gYmFiZWwtcm91dGVzLW9iaiI6IHdoeSB3YXMgaXQgcGx1cmFsaXpl ZD8NCj4gSSBhbHNvIGZpbmQgaXQgYmV0dGVyIHRvIGhhdmUgdGhlIGZpZWxkIChmb3IgaW5zdGFu Y2UpICJiYWJlbC1yb3V0ZXM8MC4uKj47IiBiZSBhDQo+IHNldCBvZiBvYmplY3RzIG9mIHR5cGUg ImJhYmVsLXJvdXRlLW9iaiIuDQo+IA0KPiAtLSBBbnRvbmluDQo+IA0KPiAtLS0NCj4gIGRyYWZ0 LWlldGYtYmFiZWwtaW5mb3JtYXRpb24tbW9kZWwubWQgfCA1NiArKysrKysrKysrKysrLS0tLS0t LS0tLS0tLS0NCj4gIDEgZmlsZSBjaGFuZ2VkLCAyOCBpbnNlcnRpb25zKCspLCAyOCBkZWxldGlv bnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9kcmFmdC1pZXRmLWJhYmVsLWluZm9ybWF0aW9uLW1v ZGVsLm1kDQo+IGIvZHJhZnQtaWV0Zi1iYWJlbC1pbmZvcm1hdGlvbi1tb2RlbC5tZA0KPiBpbmRl eCBhZDJhNjRhLi45YjY2ZjJkIDEwMDY0NA0KPiAtLS0gYS9kcmFmdC1pZXRmLWJhYmVsLWluZm9y bWF0aW9uLW1vZGVsLm1kDQo+ICsrKyBiL2RyYWZ0LWlldGYtYmFiZWwtaW5mb3JtYXRpb24tbW9k ZWwubWQNCj4gQEAgLTE1LDcgKzE1LDcgQEAgdGl0bGU6IEJhYmVsIEluZm9ybWF0aW9uIE1vZGVs DQo+ICBhcmVhOiBSb3V0aW5nDQo+ICB3ZzogQmFiZWwgcm91dGluZyBwcm90b2NvbA0KPiAga3c6 IEJhYmVsDQo+IC1kYXRlOiAyMDE5DQo+ICtkYXRlOiAyMDIwDQo+ICBhdXRob3I6DQo+ICAtIGlu czogQi4gSC4gU3RhcmsNCj4gICAgbmFtZTogQmFyYmFyYSBTdGFyaw0KPiBAQCAtMzMyLDEwICsz MzIsMTAgQEAgbW9kZWwgZGVmaW5pdGlvbnMgaW4gc3Vic2VxdWVudCBzZWN0aW9ucywgdGhlIGVy cm9yDQo+IGlzIGluIHRoaXMgb3ZlcnZpZXcuDQo+ICAgICAgICBbYm9vbGVhbiAgICAgICAgICAg ICAgICAgIHJ3IGJhYmVsLXN0YXRzLWVuYWJsZTtdDQo+ICAgICAgICBbb3BlcmF0aW9uICAgICAg ICAgICAgICAgICAgIGJhYmVsLXN0YXRzLXJlc2V0O10NCj4gICAgICAgICBiYWJlbC1jb25zdGFu dHMtb2JqICAgICAgcm8gYmFiZWwtY29uc3RhbnRzOw0KPiAtICAgICAgIGJhYmVsLWludGVyZmFj ZXMtb2JqICAgICBybyBiYWJlbC1pbnRlcmZhY2VzPDAuLio+Ow0KPiAtICAgICAgIGJhYmVsLXJv dXRlcy1vYmogICAgICAgICBybyBiYWJlbC1yb3V0ZXM8MC4uKj47DQo+IC0gICAgICBbYmFiZWwt bWFjLWtleS1zZXRzLW9iaiAgIHJ3IGJhYmVsLW1hYy1rZXktc2V0czwwLi4qPjtdDQo+IC0gICAg ICBbYmFiZWwtZHRscy1jZXJ0LXNldHMtb2JqIHJ3IGJhYmVsLWR0bHMtY2VydC1zZXRzPDAuLio+ O10NCj4gKyAgICAgICBiYWJlbC1pbnRlcmZhY2Utb2JqICAgICAgcm8gYmFiZWwtaW50ZXJmYWNl czwwLi4qPjsNCj4gKyAgICAgICBiYWJlbC1yb3V0ZS1vYmogICAgICAgICAgcm8gYmFiZWwtcm91 dGVzPDAuLio+Ow0KPiArICAgICAgW2JhYmVsLW1hYy1rZXktc2V0LW9iaiAgICBydyBiYWJlbC1t YWMta2V5LXNldHM8MC4uKj47XQ0KPiArICAgICAgW2JhYmVsLWR0bHMtY2VydC1zZXQtb2JqICBy dyBiYWJlbC1kdGxzLWNlcnQtc2V0czwwLi4qPjtdDQo+ICAgICB9IGJhYmVsLWluZm9ybWF0aW9u LW9iajsNCj4gIH5+fn4NCj4gIHs6IGFydHdvcmstYWxpZ249ImxlZnQifQ0KPiBAQCAtNDA3LDE0 ICs0MDcsMTQgQEAgYmFiZWwtcm91dGVzOg0KPiAgICBub2RlLg0KPiANCj4gIGJhYmVsLW1hYy1r ZXktc2V0czoNCj4gLTogQSBiYWJlbC1tYWMta2V5LXNldHMtb2JqIG9iamVjdC4gSWYgdGhpcw0K PiArOiBBIHNldCBvZiBiYWJlbC1tYWMta2V5LXNldC1vYmogb2JqZWN0cy4gSWYgdGhpcw0KPiAg ICBvYmplY3QgaXMgaW1wbGVtZW50ZWQsIGl0DQo+ICAgIHByb3ZpZGVzIGFjY2VzcyB0byBwYXJh bWV0ZXJzIHJlbGF0ZWQgdG8gdGhlIE1BQyBzZWN1cml0eSBtZWNoYW5pc20uDQo+ICAgIEFuIGlt cGxlbWVudGF0aW9uIE1BWSBjaG9vc2UNCj4gICAgdG8gZXhwb3NlIHRoaXMgb2JqZWN0IGFzIHJl YWQtb25seSAoInJvIikuDQo+IA0KPiAgYmFiZWwtZHRscy1jZXJ0LXNldHM6DQo+IC06IEEgYmFi ZWwtZHRscy1jZXJ0LXNldHMtb2JqIG9iamVjdC4gSWYgdGhpcw0KPiArOiBBIHNldCBvZiBiYWJl bC1kdGxzLWNlcnQtc2V0LW9iaiBvYmplY3RzLiBJZiB0aGlzDQo+ICAgIG9iamVjdCBpcyBpbXBs ZW1lbnRlZCwgaXQNCj4gICAgcHJvdmlkZXMgYWNjZXNzIHRvIHBhcmFtZXRlcnMgcmVsYXRlZCB0 byB0aGUgRFRMUyBzZWN1cml0eSBtZWNoYW5pc20uDQo+ICAgIEFuIGltcGxlbWVudGF0aW9uIE1B WSBjaG9vc2UNCj4gQEAgLTQ0Niw3ICs0NDYsNyBAQCBiYWJlbC1tY2FzdC1ncm91cDoNCj4gICAg dG8gZXhwb3NlIHRoaXMgcGFyYW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuDQo+IA0KPiANCj4g LSMjIERlZmluaXRpb24gb2YgYmFiZWwtaW50ZXJmYWNlcy1vYmoNCj4gKyMjIERlZmluaXRpb24g b2YgYmFiZWwtaW50ZXJmYWNlLW9iag0KPiANCj4gDQo+ICB+fn5+DQo+IEBAIC00NjgsOCArNDY4 LDggQEAgYmFiZWwtbWNhc3QtZ3JvdXA6DQo+ICAgICAgICBbYm9vbGVhbiAgICAgICAgICAgICAg cncgYmFiZWwtcGFja2V0LWxvZy1lbmFibGU7XQ0KPiAgICAgICAgW3JlZmVyZW5jZSAgICAgICAg ICAgIHJvIGJhYmVsLXBhY2tldC1sb2c7XQ0KPiAgICAgICAgW2JhYmVsLWlmLXN0YXRzLW9iaiAg IHJvIGJhYmVsLWlmLXN0YXRzO10NCj4gLSAgICAgICBiYWJlbC1uZWlnaGJvcnMtb2JqICBybyBi YWJlbC1uZWlnaGJvcnM8MC4uKj47DQo+IC0gICB9IGJhYmVsLWludGVyZmFjZXMtb2JqOw0KPiAr ICAgICAgIGJhYmVsLW5laWdoYm9yLW9iaiAgIHJvIGJhYmVsLW5laWdoYm9yczwwLi4qPjsNCj4g KyAgIH0gYmFiZWwtaW50ZXJmYWNlLW9iajsNCj4gIH5+fn4NCj4gIHs6IGFydHdvcmstYWxpZ249 ImxlZnQifQ0KPiANCj4gQEAgLTU5NCw3ICs1OTQsNyBAQCBiYWJlbC1pZi1zdGF0czoNCj4gIDog U3RhdGlzdGljcyBjb2xsZWN0aW9uIG9iamVjdCBmb3IgdGhpcyBpbnRlcmZhY2UuDQo+IA0KPiAg YmFiZWwtbmVpZ2hib3JzOg0KPiAtOiBBIHNldCBvZiBiYWJlbC1uZWlnaGJvcnMtb2JqIG9iamVj dHMuDQo+ICs6IEEgc2V0IG9mIGJhYmVsLW5laWdoYm9yLW9iaiBvYmplY3RzLg0KPiANCj4gDQo+ ICAjIyBEZWZpbml0aW9uIG9mIGJhYmVsLWlmLXN0YXRzLW9iag0KPiBAQCAtNjMxLDcgKzYzMSw3 IEBAIGJhYmVsLXJlY2VpdmVkLXBhY2tldHM6DQo+ICA6IEEgY291bnQgb2YgdGhlIG51bWJlciBv ZiBCYWJlbCBwYWNrZXRzIHJlY2VpdmVkIG9uIHRoaXMgaW50ZXJmYWNlLg0KPiANCj4gDQo+IC0j IyBEZWZpbml0aW9uIG9mIGJhYmVsLW5laWdoYm9ycy1vYmoNCj4gKyMjIERlZmluaXRpb24gb2Yg YmFiZWwtbmVpZ2hib3Itb2JqDQo+IA0KPiAgfn5+fg0KPiAgICBvYmplY3Qgew0KPiBAQCAtNjQ1 LDcgKzY0NSw3IEBAIGJhYmVsLXJlY2VpdmVkLXBhY2tldHM6DQo+ICAgICAgICBbdWludCAgICAg ICAgICAgICAgICBybyBiYWJlbC11Y2FzdC1oZWxsby1pbnRlcnZhbDtdDQo+ICAgICAgICBbdWlu dCAgICAgICAgICAgICAgICBybyBiYWJlbC1yeGNvc3Q7XQ0KPiAgICAgICAgW3VpbnQgICAgICAg ICAgICAgICAgcm8gYmFiZWwtY29zdDtdDQo+IC0gICB9IGJhYmVsLW5laWdoYm9ycy1vYmo7DQo+ ICsgICB9IGJhYmVsLW5laWdoYm9yLW9iajsNCj4gIH5+fn4NCj4gIHs6IGFydHdvcmstYWxpZ249 ImxlZnQifQ0KPiANCj4gQEAgLTcyNyw3ICs3MjcsNyBAQCBiYWJlbC1jb3N0Og0KPiAgICBUaGlz IGlzIGEgMTYtYml0IHVuc2lnbmVkIGludGVnZXIuDQo+IA0KPiANCj4gLSMjIERlZmluaXRpb24g b2YgYmFiZWwtcm91dGVzLW9iag0KPiArIyMgRGVmaW5pdGlvbiBvZiBiYWJlbC1yb3V0ZS1vYmoN Cj4gDQo+ICB+fn5+DQo+ICAgIG9iamVjdCB7DQo+IEBAIC03NDEsNyArNzQxLDcgQEAgYmFiZWwt Y29zdDoNCj4gICAgICAgICBpcC1hZGRyZXNzICAgICAgICAgICBybyBiYWJlbC1yb3V0ZS1uZXh0 LWhvcDsNCj4gICAgICAgICBib29sZWFuICAgICAgICAgICAgICBybyBiYWJlbC1yb3V0ZS1mZWFz aWJsZTsNCj4gICAgICAgICBib29sZWFuICAgICAgICAgICAgICBybyBiYWJlbC1yb3V0ZS1zZWxl Y3RlZDsNCj4gLSAgIH0gYmFiZWwtcm91dGVzLW9iajsNCj4gKyAgIH0gYmFiZWwtcm91dGUtb2Jq Ow0KPiAgfn5+fg0KPiAgezogYXJ0d29yay1hbGlnbj0ibGVmdCJ9DQo+IA0KPiBAQCAtODA4LDEz ICs4MDgsMTMgQEAgYmFiZWwtcm91dGUtc2VsZWN0ZWQ6DQo+ICAgIGlzIGJlaW5nIGFkdmVydGlz ZWQpLg0KPiANCj4gDQo+IC0jIyBEZWZpbml0aW9uIG9mIGJhYmVsLW1hYy1rZXktc2V0cy1vYmoN Cj4gKyMjIERlZmluaXRpb24gb2YgYmFiZWwtbWFjLWtleS1zZXQtb2JqDQo+IA0KPiAgfn5+fg0K PiAgICBvYmplY3Qgew0KPiAgICAgICAgIGJvb2xlYW4gICAgICAgICAgICAgICBydyBiYWJlbC1t YWMtZGVmYXVsdC1hcHBseTsNCj4gLSAgICAgICBiYWJlbC1tYWMta2V5cy1vYmogICAgcncgYmFi ZWwtbWFjLWtleXM8MC4uKj47DQo+IC0gICB9IGJhYmVsLW1hYy1vYmo7DQo+ICsgICAgICAgYmFi ZWwtbWFjLWtleS1vYmogICAgIHJ3IGJhYmVsLW1hYy1rZXlzPDAuLio+Ow0KPiArICAgfSBiYWJl bC1tYWMta2V5LXNldC1vYmo7DQo+ICB+fn5+DQo+ICB7OiBhcnR3b3JrLWFsaWduPSJsZWZ0In0N Cj4gDQo+IEBAIC04MzEsOSArODMxLDkgQEAgYmFiZWwtbWFjLWRlZmF1bHQtYXBwbHk6DQo+ICAg IHRvIGV4cG9zZSB0aGlzIHBhcmFtZXRlciBhcyByZWFkLW9ubHkgKCJybyIpLg0KPiANCj4gIGJh YmVsLW1hYy1rZXlzOg0KPiAtOiBBIHNldCBvZiBiYWJlbC1tYWMta2V5cy1vYmogb2JqZWN0cy4N Cj4gKzogQSBzZXQgb2YgYmFiZWwtbWFjLWtleS1vYmogb2JqZWN0cy4NCj4gDQo+IC0jIyBEZWZp bml0aW9uIG9mIGJhYmVsLW1hYy1rZXlzLW9iag0KPiArIyMgRGVmaW5pdGlvbiBvZiBiYWJlbC1t YWMta2V5LW9iag0KPiANCj4gIH5+fn4NCj4gICAgb2JqZWN0IHsNCj4gQEAgLTg0Myw3ICs4NDMs NyBAQCBiYWJlbC1tYWMta2V5czoNCj4gICAgICAgICBiaW5hcnkgICAgICAgICAgICAgICAgLS0g YmFiZWwtbWFjLWtleS12YWx1ZTsNCj4gICAgICAgICBzdHJpbmcgICAgICAgICAgICAgICAgcncg YmFiZWwtbWFjLWtleS1hbGdvcml0aG07DQo+ICAgICAgICBbb3BlcmF0aW9uICAgICAgICAgICAg ICAgIGJhYmVsLW1hYy1rZXktdGVzdDtdDQo+IC0gICB9IGJhYmVsLW1hYy1rZXlzLW9iajsNCj4g KyAgIH0gYmFiZWwtbWFjLWtleS1vYmo7DQo+ICB+fn5+DQo+ICB7OiBhcnR3b3JrLWFsaWduPSJs ZWZ0In0NCj4gDQo+IEBAIC05MDIsMTMgKzkwMiwxMyBAQCBiYWJlbC1tYWMtdGVzdDoNCj4gICAg YXMgYSBiaW5hcnkgc3RyaW5nLg0KPiANCj4gDQo+IC0jIyBEZWZpbml0aW9uIG9mIGJhYmVsLWR0 bHMtY2VydC1zZXRzLW9iag0KPiArIyMgRGVmaW5pdGlvbiBvZiBiYWJlbC1kdGxzLWNlcnQtc2V0 LW9iag0KPiANCj4gIH5+fn4NCj4gICAgb2JqZWN0IHsNCj4gICAgICAgICBib29sZWFuICAgICAg ICAgICAgICAgcncgYmFiZWwtZHRscy1kZWZhdWx0LWFwcGx5Ow0KPiAtICAgICAgIGJhYmVsLWR0 bHMtY2VydHMtb2JqICBydyBiYWJlbC1kdGxzLWNlcnRzPDAuLio+Ow0KPiAtICAgfSBiYWJlbC1k dGxzLW9iajsNCj4gKyAgICAgICBiYWJlbC1kdGxzLWNlcnQtb2JqICAgcncgYmFiZWwtZHRscy1j ZXJ0czwwLi4qPjsNCj4gKyAgIH0gYmFiZWwtZHRscy1jZXJ0LXNldC1vYmo7DQo+ICB+fn5+DQo+ ICB7OiBhcnR3b3JrLWFsaWduPSJsZWZ0In0NCj4gDQo+IEBAIC05MjQsMTQgKzkyNCwxNCBAQCBi YWJlbC1kdGxzLWRlZmF1bHQtYXBwbHk6DQo+ICAgIEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9v c2UNCj4gICAgdG8gZXhwb3NlIHRoaXMgcGFyYW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuDQo+ IA0KPiAtYmFiZWwtZHRscy1jZXJ0czoNCj4gLTogQSBzZXQgb2YgYmFiZWwtZHRscy1rZXlzLW9i aiBvYmplY3RzLiBUaGlzIGNvbnRhaW5zIGJvdGggY2VydGlmaWNhdGVzDQo+ICtiYWJlbC1kdGxz LWNlcnQ6DQo+ICs6IEEgc2V0IG9mIGJhYmVsLWR0bHMtY2VydC1vYmogb2JqZWN0cy4gVGhpcyBj b250YWlucyBib3RoIGNlcnRpZmljYXRlcw0KPiAgICBmb3IgdGhpcyBpbXBsZW1lbnRhdGlvbiB0 byBwcmVzZW50IGZvciBhdXRoZW50aWNhdGlvbiwgYW5kIHRvIGFjY2VwdA0KPiAgICBmcm9tIG90 aGVycy4gQ2VydGlmaWNhdGVzIHdpdGggYSBub24tZW1wdHkgYmFiZWwtY2VydC1wcml2YXRlLWtl eSBjYW4NCj4gICAgYmUgcHJlc2VudGVkIGJ5IHRoaXMgaW1wbGVtZW50YXRpb24gZm9yIGF1dGhl bnRpY2F0aW9uLg0KPiANCj4gDQo+IC0jIyBEZWZpbml0aW9uIG9mIGJhYmVsLWR0bHMtY2VydHMt b2JqDQo+ICsjIyBEZWZpbml0aW9uIG9mIGJhYmVsLWR0bHMtY2VydC1vYmoNCj4gDQo+ICB+fn5+ DQo+ICAgIG9iamVjdCB7DQo+IEBAIC05NDAsNyArOTQwLDcgQEAgYmFiZWwtZHRscy1jZXJ0czoN Cj4gICAgICAgICBzdHJpbmcgICAgICAgICAgICAgICAgcncgYmFiZWwtY2VydC10eXBlOw0KPiAg ICAgICAgIGJpbmFyeSAgICAgICAgICAgICAgICAtLSBiYWJlbC1jZXJ0LXByaXZhdGUta2V5Ow0K PiAgICAgICAgW29wZXJhdGlvbiAgICAgICAgICAgICAgICBiYWJlbC1jZXJ0LXRlc3Q7XQ0KPiAt ICAgfSBiYWJlbC1kdGxzLWNlcnRzLW9iajsNCj4gKyAgIH0gYmFiZWwtZHRscy1jZXJ0LW9iajsN Cj4gIH5+fn4NCj4gIHs6IGFydHdvcmstYWxpZ249ImxlZnQifQ0KPiANCj4gLS0NCj4gMi4yNS4w DQo= From nobody Wed Jan 22 18:34:56 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666912006F for ; Wed, 22 Jan 2020 18:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tM8suAXMhOb for ; Wed, 22 Jan 2020 18:34:53 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 81A16120018 for ; Wed, 22 Jan 2020 18:34:53 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id n96so473235pjc.3 for ; Wed, 22 Jan 2020 18:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eCRKDxaQ2z1bSMNF28WeZXPTGnLl90kVJa0d/iR2cNs=; b=JJx1VkhSa8an9YffpQEomUiy5aT6GDBWYoY3gBUyM26caOkcNjiAlZNuaQwi5MY5Os zY3/qXZWw0gsehDDhfizlMRNiezq1KrqsDUpKTBfVOEQjixNxevNm+MSwTWyTSJ9OlFA xKUp572nJo1I80WlB516cCMcPWdm7EXp5NmPB7IBsBw2u5ZlkTTIlH5SATXqg0+zV2Vx X+BRf9vi9QKwTmU/TjVVrKAAA86g/u7DoVKbyarteQ7/PSlSrQ7odngIZZP62iw8SZDF 1Fp+fN5QcpgsF3xt1UVHv15LRibrn1b+XZgoQBIioIpCHcUOXYIbfGUsbyCYmIeyTyrz sZLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eCRKDxaQ2z1bSMNF28WeZXPTGnLl90kVJa0d/iR2cNs=; b=nALPEAG4m/+YWXkHPX7cOo1Y2fyLZB2nUVltIpuR5D47XZMZ/eAQ1p5q3rp8pqPILM bWnapRcfoqbDiwiNON4pyXIsEfTSqmRqxHcj5gJQUjh2YQ5TPW7HGVz6wOzfvbeNLAwI U9TOm0/9Ti2fU5TkhgnTlR91igiF4O7EG0OYyen+FURJ+FXQ/YyB/Os+zUTwIyiYoz0i sMT1uhI8blIMR59ReApS3CpU6DeRz4Xig3VW9pHpZWHmBWN0t2ynoGjUS4mdtiVEito0 luPdG/WbQdj1usqH4AaCgmXRdL4TTJAscI7PcLhGVCL6WaUeLeHfKAOuyyO1Kpypv4ON ltSA== X-Gm-Message-State: APjAAAVQn0pRByx7Hz6maafXYBgZl1ryPJcle6XMqa6n45ys/h8bAfsW sfGHJrAGJvIPmlp2BRwRx5U= X-Google-Smtp-Source: APXvYqxdp/nHG7vkmlwANcG/zkbSanVr8mLMfhuRYmxjy3fHe6SBNYcAN1YgqlgDPx9bDCexeCAsxQ== X-Received: by 2002:a17:90a:2203:: with SMTP id c3mr1847726pje.68.1579746892881; Wed, 22 Jan 2020 18:34:52 -0800 (PST) Received: from [10.33.123.108] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id a23sm263467pfg.82.2020.01.22.18.34.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 18:34:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611537595E5@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 22 Jan 2020 18:34:50 -0800 Cc: =?utf-8?Q?Antonin_D=C3=A9cimo?= , "babel@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5527E0D9-E433-424A-8DD1-2356ED4EAF4A@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E611537595E5@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] [patch] Info model: fix little inconsistencies in naming, use singular for objects. X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 02:34:55 -0000 Hi Barbara, You are right. The YANG model maintains list names which are plural. It = does not define the -obj objects. As such, the YANG model is not = impacted. Thanks. > On Jan 21, 2020, at 1:26 PM, STARK, BARBARA H wrote: >=20 > Hi Antonin, > I don't remember why I made them plural. I'm sure it was because I saw = it done that way, somewhere. I try to avoid having original thoughts. > But I agree with you completely. In my BBF TR-181 data model, the = object names are all singular, because that's the BBF convention. > Since it looks like we've got some other little changes coming in, it = wouldn't bother me to make the object names all singular. But I don't = know how Mahesh feels about this. I know the YANG model maintains the = plural forms; but the list names would still be plural (only the -obj = definitions would change to singular) -- so the YANG model wouldn't need = to change.=20 > Barbara >=20 >> Hello Barbara, hello Mahesh, >>=20 >> While reading carefully the Information Model with all the recent = discussions, >> I've found some small inconsistencies in the naming of objects which = I've >> fixed in the patch below. >>=20 >> What bothered me more was that the name of object types was = pluralized. >> I'm much more comfortable with singular, for instance I find it = better to read >> "Definition of babel-route-obj" and then the composition of the = object, >> rather than "Definition of >> babel-routes-obj": why was it pluralized? >> I also find it better to have the field (for instance) = "babel-routes<0..*>;" be a >> set of objects of type "babel-route-obj". >>=20 >> -- Antonin >>=20 >> --- >> draft-ietf-babel-information-model.md | 56 = +++++++++++++-------------- >> 1 file changed, 28 insertions(+), 28 deletions(-) >>=20 >> diff --git a/draft-ietf-babel-information-model.md >> b/draft-ietf-babel-information-model.md >> index ad2a64a..9b66f2d 100644 >> --- a/draft-ietf-babel-information-model.md >> +++ b/draft-ietf-babel-information-model.md >> @@ -15,7 +15,7 @@ title: Babel Information Model >> area: Routing >> wg: Babel routing protocol >> kw: Babel >> -date: 2019 >> +date: 2020 >> author: >> - ins: B. H. Stark >> name: Barbara Stark >> @@ -332,10 +332,10 @@ model definitions in subsequent sections, the = error >> is in this overview. >> [boolean rw babel-stats-enable;] >> [operation babel-stats-reset;] >> babel-constants-obj ro babel-constants; >> - babel-interfaces-obj ro babel-interfaces<0..*>; >> - babel-routes-obj ro babel-routes<0..*>; >> - [babel-mac-key-sets-obj rw babel-mac-key-sets<0..*>;] >> - [babel-dtls-cert-sets-obj rw babel-dtls-cert-sets<0..*>;] >> + babel-interface-obj ro babel-interfaces<0..*>; >> + babel-route-obj ro babel-routes<0..*>; >> + [babel-mac-key-set-obj rw babel-mac-key-sets<0..*>;] >> + [babel-dtls-cert-set-obj rw babel-dtls-cert-sets<0..*>;] >> } babel-information-obj; >> ~~~~ >> {: artwork-align=3D"left"} >> @@ -407,14 +407,14 @@ babel-routes: >> node. >>=20 >> babel-mac-key-sets: >> -: A babel-mac-key-sets-obj object. If this >> +: A set of babel-mac-key-set-obj objects. If this >> object is implemented, it >> provides access to parameters related to the MAC security = mechanism. >> An implementation MAY choose >> to expose this object as read-only ("ro"). >>=20 >> babel-dtls-cert-sets: >> -: A babel-dtls-cert-sets-obj object. If this >> +: A set of babel-dtls-cert-set-obj objects. If this >> object is implemented, it >> provides access to parameters related to the DTLS security = mechanism. >> An implementation MAY choose >> @@ -446,7 +446,7 @@ babel-mcast-group: >> to expose this parameter as read-only ("ro"). >>=20 >>=20 >> -## Definition of babel-interfaces-obj >> +## Definition of babel-interface-obj >>=20 >>=20 >> ~~~~ >> @@ -468,8 +468,8 @@ babel-mcast-group: >> [boolean rw babel-packet-log-enable;] >> [reference ro babel-packet-log;] >> [babel-if-stats-obj ro babel-if-stats;] >> - babel-neighbors-obj ro babel-neighbors<0..*>; >> - } babel-interfaces-obj; >> + babel-neighbor-obj ro babel-neighbors<0..*>; >> + } babel-interface-obj; >> ~~~~ >> {: artwork-align=3D"left"} >>=20 >> @@ -594,7 +594,7 @@ babel-if-stats: >> : Statistics collection object for this interface. >>=20 >> babel-neighbors: >> -: A set of babel-neighbors-obj objects. >> +: A set of babel-neighbor-obj objects. >>=20 >>=20 >> ## Definition of babel-if-stats-obj >> @@ -631,7 +631,7 @@ babel-received-packets: >> : A count of the number of Babel packets received on this interface. >>=20 >>=20 >> -## Definition of babel-neighbors-obj >> +## Definition of babel-neighbor-obj >>=20 >> ~~~~ >> object { >> @@ -645,7 +645,7 @@ babel-received-packets: >> [uint ro babel-ucast-hello-interval;] >> [uint ro babel-rxcost;] >> [uint ro babel-cost;] >> - } babel-neighbors-obj; >> + } babel-neighbor-obj; >> ~~~~ >> {: artwork-align=3D"left"} >>=20 >> @@ -727,7 +727,7 @@ babel-cost: >> This is a 16-bit unsigned integer. >>=20 >>=20 >> -## Definition of babel-routes-obj >> +## Definition of babel-route-obj >>=20 >> ~~~~ >> object { >> @@ -741,7 +741,7 @@ babel-cost: >> ip-address ro babel-route-next-hop; >> boolean ro babel-route-feasible; >> boolean ro babel-route-selected; >> - } babel-routes-obj; >> + } babel-route-obj; >> ~~~~ >> {: artwork-align=3D"left"} >>=20 >> @@ -808,13 +808,13 @@ babel-route-selected: >> is being advertised). >>=20 >>=20 >> -## Definition of babel-mac-key-sets-obj >> +## Definition of babel-mac-key-set-obj >>=20 >> ~~~~ >> object { >> boolean rw babel-mac-default-apply; >> - babel-mac-keys-obj rw babel-mac-keys<0..*>; >> - } babel-mac-obj; >> + babel-mac-key-obj rw babel-mac-keys<0..*>; >> + } babel-mac-key-set-obj; >> ~~~~ >> {: artwork-align=3D"left"} >>=20 >> @@ -831,9 +831,9 @@ babel-mac-default-apply: >> to expose this parameter as read-only ("ro"). >>=20 >> babel-mac-keys: >> -: A set of babel-mac-keys-obj objects. >> +: A set of babel-mac-key-obj objects. >>=20 >> -## Definition of babel-mac-keys-obj >> +## Definition of babel-mac-key-obj >>=20 >> ~~~~ >> object { >> @@ -843,7 +843,7 @@ babel-mac-keys: >> binary -- babel-mac-key-value; >> string rw babel-mac-key-algorithm; >> [operation babel-mac-key-test;] >> - } babel-mac-keys-obj; >> + } babel-mac-key-obj; >> ~~~~ >> {: artwork-align=3D"left"} >>=20 >> @@ -902,13 +902,13 @@ babel-mac-test: >> as a binary string. >>=20 >>=20 >> -## Definition of babel-dtls-cert-sets-obj >> +## Definition of babel-dtls-cert-set-obj >>=20 >> ~~~~ >> object { >> boolean rw babel-dtls-default-apply; >> - babel-dtls-certs-obj rw babel-dtls-certs<0..*>; >> - } babel-dtls-obj; >> + babel-dtls-cert-obj rw babel-dtls-certs<0..*>; >> + } babel-dtls-cert-set-obj; >> ~~~~ >> {: artwork-align=3D"left"} >>=20 >> @@ -924,14 +924,14 @@ babel-dtls-default-apply: >> An implementation MAY choose >> to expose this parameter as read-only ("ro"). >>=20 >> -babel-dtls-certs: >> -: A set of babel-dtls-keys-obj objects. This contains both = certificates >> +babel-dtls-cert: >> +: A set of babel-dtls-cert-obj objects. This contains both = certificates >> for this implementation to present for authentication, and to = accept >> from others. Certificates with a non-empty babel-cert-private-key = can >> be presented by this implementation for authentication. >>=20 >>=20 >> -## Definition of babel-dtls-certs-obj >> +## Definition of babel-dtls-cert-obj >>=20 >> ~~~~ >> object { >> @@ -940,7 +940,7 @@ babel-dtls-certs: >> string rw babel-cert-type; >> binary -- babel-cert-private-key; >> [operation babel-cert-test;] >> - } babel-dtls-certs-obj; >> + } babel-dtls-cert-obj; >> ~~~~ >> {: artwork-align=3D"left"} >>=20 >> -- >> 2.25.0 Mahesh Jethanandani mjethanandani@gmail.com