From nobody Sun Aug 1 14:39:10 2021 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 709333A12AB; Sun, 1 Aug 2021 14:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Rc5XHRiixsMS; Sun, 1 Aug 2021 14:39:04 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 E96ED3A12A5; Sun, 1 Aug 2021 14:39:03 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id r6so9787517ioj.8; Sun, 01 Aug 2021 14:39:03 -0700 (PDT) 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=Ep04wMaIJRFxHl1HWlNcu2VyvpfXNtkAZhEXJPzgzlA=; b=OObn/S4yE3nSnD8/OoVXiVUil6AV5Jc3En2xFTLEoolLW4TYaWCIF/j5bclP6bsyUi fBZxdAEhTQhsgF/M9gP2ejaWnQmtsmxfs28M0VMBU6l7KFU4IPou9uyexAjWEDJz2fCe xpy6b5NTXbuW6JpJca7HGeV7HP/8jh/sWk/53QLqa4yU72wKOckTecZWLekM2tQKSYfD PBNhXRW4veV994pSDMw0PScl3hfR3FSEza0Qnm1nXfJztTv891hWFYFeqt1j2PVXzLGh PBvBDih1LoKDqL3s9sZdtmB2qtCTFIg3Rqi6aBpmteyL/4zQpHKCsEh6A9SFFX/MGqIt ARzw== 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=Ep04wMaIJRFxHl1HWlNcu2VyvpfXNtkAZhEXJPzgzlA=; b=WqsVVfcn4S4xnIJgvIMy8Xdy72itRmodBbd3GFctTy8D5EV4sKvmhRLs1CbBkx59nf GlP/QbKnWY8ErTnW0sj50RSjhVGls+stQLyn28XQc/q6b4ehvXkIzFJ0Mn9Tr8q7WUhu vQLCp9/GHHipN1w4Kqqvm13DX+nd9O8PvXeUYHEV4qbVkUiyQKVDHtgu0ArK6fEavE7U mcBTstpW7s80ya3FHft6g8ExzJVpxUHZOips+UPQUMUO6b3Jnn6C9EzAqKcpBoCuCrRn Kqw67xEu8g3ATRMr3eaLlV+cDRgnD+XlKGyzNwuqNzGkNnEupJv6Y6SuFMZ0kYi+MLKH bjDQ== X-Gm-Message-State: AOAM533sWBYrZw8kdIVCi5qrfGGGWybL7pLkeKY579blpnuvFmB/FH+D JfFxft4/fFeBCCwEErkC9iuzxDybZ3RgQom1t8MKQVdApZ0= X-Google-Smtp-Source: ABdhPJxGvn/OVxdbHhM7b2oZ98Gv4YlZYZsWelKQZNEmV3EYgfBP+53V64WmV1mDkJVY218Zh731AskL+Gvi3m3Xy0I= X-Received: by 2002:a05:6638:1608:: with SMTP id x8mr11708801jas.115.1627853942368; Sun, 01 Aug 2021 14:39:02 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Sun, 1 Aug 2021 17:38:51 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="000000000000fb2bbb05c886479f" Archived-At: Subject: [babel] Babel draft minutes, meeting materials 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, 01 Aug 2021 21:39:09 -0000 --000000000000fb2bbb05c886479f Content-Type: text/plain; charset="UTF-8" Hi, Draft minutes for the Babel WG meeting and other meeting materials are linked off the web page at https://datatracker.ietf.org/meeting/111/session/babel Thanks to Barbara Stark for taking minutes. A video of the session is available at https://www.youtube.com/watch?v=uM1McPr4oK8 Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --000000000000fb2bbb05c886479f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Draft minutes for the Babel WG meet= ing and other meeting materials are linked off the web page at=C2=A0https://datatra= cker.ietf.org/meeting/111/session/babel

Thanks= to Barbara Stark for taking minutes.

A video of t= he session is available at=C2=A0https://www.youtube.com/watch?v=3DuM1McPr4oK8

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
--000000000000fb2bbb05c886479f-- From nobody Sun Aug 1 14:56:39 2021 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 EDA0D3A1434; Sun, 1 Aug 2021 14:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2Ev1FlSdPu4A; Sun, 1 Aug 2021 14:56:33 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D963A1431; Sun, 1 Aug 2021 14:56:32 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 171LuRsH025294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Aug 2021 23:56:27 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 171LuRYd007123; Sun, 1 Aug 2021 23:56:27 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 04BC8D323C; Sun, 1 Aug 2021 23:56:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id TIuUkFzMLcQX; Sun, 1 Aug 2021 23:56:22 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 92861D3239; Sun, 1 Aug 2021 23:56:22 +0200 (CEST) Date: Sun, 01 Aug 2021 23:56:22 +0200 Message-ID: <87a6m0omm1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 01 Aug 2021 23:56:27 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 01 Aug 2021 23:56:27 +0200 (CEST) X-Miltered: at korolev with ID 6107188B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 6107188B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 6107188B.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 6107188B.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 : 6107188B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 6107188B.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 draft minutes, meeting materials 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, 01 Aug 2021 21:56:38 -0000 > Draft minutes for the Babel WG meeting and other meeting materials are linked > off the web page at https://datatracker.ietf.org/meeting/111/session/babel > > Thanks to Barbara Stark for taking minutes. Thanks indeed. Minor correction -- I did not suggest that the DS should use TRILL, I tried to imply that the DS suffers from the same issue as Perlman outlined about TRILL: it's trying to do routing at layer 2, which causes a lot of extra complexity. My take is that it should be possible to do the DS at layer 3, similarly to what the LTE core network does. I never said TRILL does beatiful routing. Why not use it? I said something like Why not do the routing at layer 3, where it belongs? Other than that minor issue, thanks for the minutes. -- Juliusz From nobody Mon Aug 2 08:23:01 2021 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 F19F73A097E; Mon, 2 Aug 2021 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 dyKShTCT-vCV; Mon, 2 Aug 2021 08:22:53 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 AB7EC3A0989; Mon, 2 Aug 2021 08:22:53 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id f11so20657676ioj.3; Mon, 02 Aug 2021 08:22:53 -0700 (PDT) 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=6i2nRP4f6PYqIQaikw3H4J4EUzIFPxFc+XblcaCwVqU=; b=dHbVataX63+l5rBOPG6TPTx70o4vX1zGU71QR31SgGUuviFcC6Fp48r6jDzJkG9XZK si8rcTKJJ5WzpvmhuAlbt4E+vx6ZC4PNN4EXLXMm09yAHNTx3txR8TLDyJreM6plPskK sk4MhJzx7vdp3o7koLIhd1utkrTO9hKMg8PJxL9M1IyrXFnKYGSsSkXNrWx5SZx5ZzAC U0kI6lO9PURjyGK1/nDKC0k2CTBMDeY2+1S4LTUG4c3/GjLjTNElR1G5jRAOk1ERFp0h 2l0p4/RdWtv6JKTkoVqnF4srxFo7s+YAsNNMp4+BRQbdHyDD7kmNlFw9aGdM9An7ObY8 6MSQ== 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=6i2nRP4f6PYqIQaikw3H4J4EUzIFPxFc+XblcaCwVqU=; b=XBUlR8QzVqjc0N1WRlv9JSCdItCAjQ9Tn/fNjse35Mg1d3KmnAWyEaUhKy6cbavUZE gl2KwQ94dUFII86oprqGCg5DBkqZbC+011Za9IZ8CqVnBbUJC6UqnVMNpqW5Q6dhYmYJ SJPfml0nF+h316MIrXQGV1UCrUsrh17KtuTDfMsF3LlgVo/I3ec1y+FOHIFt8qBJCWH3 est/n2b4lYZtVjTsbYHCjpKPchNDqUJk5aT+ntJRV/gsXj3WsAhlOOI0aFo9cAJzm2/H Dkh8W/vl88Qj3uIIeOvjasUH0y0kGyWT6JhvGhYC6pnynhqAyr55GD86jWsTuE9ZKf8t +irg== X-Gm-Message-State: AOAM532qq2HGvqNRg+FkNnumQ6M1qWujCUyAYR709OZBJ+4OlplwPEvk cbD7S4CAo3Ijn8aqV3+GBzp9vfCPERaU/iJy9HKdLZEg X-Google-Smtp-Source: ABdhPJz9SgySG0r8gutpw2wvqse5Hp4XePAOxkYyQGowrY5jpQvu/BqXOpkX/+7dFUzlJO6098NFYG3zvvCGpQw1ySE= X-Received: by 2002:a5d:9304:: with SMTP id l4mr3651443ion.167.1627917772364; Mon, 02 Aug 2021 08:22:52 -0700 (PDT) MIME-Version: 1.0 References: <87a6m0omm1.wl-jch@irif.fr> In-Reply-To: <87a6m0omm1.wl-jch@irif.fr> From: Donald Eastlake Date: Mon, 2 Aug 2021 11:22:41 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , babel-chairs Content-Type: multipart/alternative; boundary="0000000000008b9eb405c89524c1" Archived-At: Subject: Re: [babel] Babel draft minutes, meeting materials 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, 02 Aug 2021 15:22:59 -0000 --0000000000008b9eb405c89524c1 Content-Type: text/plain; charset="UTF-8" Hi Juliusz, I have endeavored to improve the minutes based on your comments, adding a link to the video, etc. If you think any further changes are needed, I suggest you provide text. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Sun, Aug 1, 2021 at 5:56 PM Juliusz Chroboczek wrote: > > Draft minutes for the Babel WG meeting and other meeting materials are > linked > > off the web page at > https://datatracker.ietf.org/meeting/111/session/babel > > > > Thanks to Barbara Stark for taking minutes. > > Thanks indeed. > > Minor correction -- I did not suggest that the DS should use TRILL, > I tried to imply that the DS suffers from the same issue as Perlman > outlined about TRILL: it's trying to do routing at layer 2, which causes > a lot of extra complexity. My take is that it should be possible to do > the DS at layer 3, similarly to what the LTE core network does. > > I never said > > TRILL does beatiful routing. Why not use it? > > I said something like > > Why not do the routing at layer 3, where it belongs? > > Other than that minor issue, thanks for the minutes. > > -- Juliusz > --0000000000008b9eb405c89524c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

I have endeavored=C2=A0to i= mprove the minutes based on your comments, adding a link to the video, etc.= If you think any further changes are needed, I suggest you provide text.

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


On S= un, Aug 1, 2021 at 5:56 PM Juliusz Chroboczek <jch@irif.fr> wrote:
> Draft minutes for the Babel WG meeting and other meet= ing materials are linked
> off the web page at https://datatracker.i= etf.org/meeting/111/session/babel
>
> Thanks to Barbara Stark for taking minutes.

Thanks indeed.

Minor correction -- I did not suggest that the DS should use TRILL,
I tried to imply that the DS suffers from the same issue as Perlman
outlined about TRILL: it's trying to do routing at layer 2, which cause= s
a lot of extra complexity.=C2=A0 My take is that it should be possible to d= o
the DS at layer 3, similarly to what the LTE core network does.

I never said

=C2=A0 TRILL does beatiful routing. Why not use it?

I said something like

=C2=A0 Why not do the routing at layer 3, where it belongs?

Other than that minor issue, thanks for the minutes.

-- Juliusz
--0000000000008b9eb405c89524c1-- From nobody Mon Aug 2 08:58:17 2021 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 504BC3A0860; Mon, 2 Aug 2021 08:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 tKzjhNA21JjS; Mon, 2 Aug 2021 08:58:10 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6033A085C; Mon, 2 Aug 2021 08:58:09 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 172Fw2T6006643; Mon, 2 Aug 2021 17:58:02 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E3304170C; Mon, 2 Aug 2021 17:58:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id r2ndRsbAXKeU; Mon, 2 Aug 2021 17:58:00 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5EE91170A; Mon, 2 Aug 2021 17:58:00 +0200 (CEST) Date: Mon, 02 Aug 2021 17:58:00 +0200 Message-ID: <87lf5j4z5j.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: babel-chairs , Babel at IETF In-Reply-To: References: <87a6m0omm1.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 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, 02 Aug 2021 17:58:02 +0200 (CEST) X-Miltered: at korolev with ID 6108160A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 6108160A.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 : 6108160A.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 draft minutes, meeting materials 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, 02 Aug 2021 15:58:16 -0000 > I have endeavored to improve the minutes based on your comments, Perfect, thanks. From nobody Tue Aug 3 08:12:15 2021 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 A21FD3A26B5 for ; Tue, 3 Aug 2021 08:12:12 -0700 (PDT) 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 C5YkKg0dTQgF for ; Tue, 3 Aug 2021 08:12:08 -0700 (PDT) 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 248E73A26DA for ; Tue, 3 Aug 2021 08:12:08 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 173F71rv029759 for ; Tue, 3 Aug 2021 11:12:07 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 3a6w2e9bpm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 03 Aug 2021 11:12:01 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 173FBxg8002663 for ; Tue, 3 Aug 2021 11:12:00 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 173FBvaF002620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 3 Aug 2021 11:11:58 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id D439D4009E70 for ; Tue, 3 Aug 2021 15:11:57 +0000 (GMT) Received: from MISOUT7MSGEX2DF.ITServices.sbc.com (unknown [135.66.184.225]) by zlp27130.vci.att.com (Service) with ESMTP id BD5A04005651 for ; Tue, 3 Aug 2021 15:11:57 +0000 (GMT) Received: from MISOUT7MSGED1DA.ITServices.sbc.com (135.66.184.175) by MISOUT7MSGEX2DF.ITServices.sbc.com (135.66.184.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 3 Aug 2021 11:11:57 -0400 Received: from MISOUT7MSGETA03.tmg.ad.att.com (144.160.12.222) by MISOUT7MSGED1DA.ITServices.sbc.com (135.66.184.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Tue, 3 Aug 2021 11:11:57 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.105) by edgeso3.exch.att.com (144.160.12.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Tue, 3 Aug 2021 11:11:49 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VPAMx4wBsBjHcIel5RlpZWATweR39yepyIN6J1vfVYFZKBkjT+CpKTds6BSxNqpvCSwrZSrAqLhiLvWOdI/jc/ShPYsoQLOAXF0+ulzoh0hTP2R7X3y4XRNW8uic+GfREaaMITga7+/hifl9S8oWz3F3BXQH9wN3Ht6KpC7QhZB7gcJ6i2tYaXA3N84EUDVdY+sPgrMlJiyB9+xvLQ/cqHlLXLk037BmF6XgB4nW1OjBf0mpeLA7YXZY5uAgE1dLmRFNgvoECrV8cTBrpaJGM9E253AiTMUdciQbyQgj6G9dPn3t3XH3LOEUXmRwe1qU3JPG+9jKfi+feuoaRL8i4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nOh3CyHZx6zr8tBYwRbFiY7FkNoq6dEcT0Y7JR/UChg=; b=k2MkkPM1hnOhrE+6rBE8oy5Zta6Tt5C9SYn7Ja6rjxKxGi/khns+dvGdGiyoTjg+Trci2nKBc0b708WbRMfaTHw4LZFYvDXBSwQwCAvZB5XXoCl0+pQRp3iqDIRPOULsF5Tglycc9Q+Adc6b8P3cNnN6x/xp48IGuvzPZXDW+Dtn4A9d17s6svMgcg7jxFARb3GU63Bi9YAFLvibgkMAu6eQ7rELHhRM8rj4QVzKqVcKGZnfnGfVe+Su2SNqvIdG7pzns0v2kEe026SwyZbfPLi7poJGP5HrX+97EOxtSmVrJd/g7ifb3RcgU9h4n4y2p7T/CWzngdyP2UwGH47qPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nOh3CyHZx6zr8tBYwRbFiY7FkNoq6dEcT0Y7JR/UChg=; b=UeaV0meF+crgnadUZoVkpdDvQMmJP+jceQOH/V4S7NYARkkRgNKvFt5Ks2yNLJkUeJdBNlVkcU2KkFp5GRLYUBz89ySt4tqWxAKSFyvw2FhUhEZNHiMyyOXxSwwGLlP6JgdlvwsqTv23nA5DsIhaaYXRuXRD6sdeBc+8EXvxGNI= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB5308.namprd02.prod.outlook.com (2603:10b6:5:43::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.20; Tue, 3 Aug 2021 15:11:49 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130%3]) with mapi id 15.20.4373.026; Tue, 3 Aug 2021 15:11:49 +0000 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: Babel DTLS and YANG Thread-Index: AdeIcm50meF1WZcvSGKFzTuShDENOw== Date: Tue, 3 Aug 2021 15:11:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61820726-5ea3-477f-845c-08d956910434 x-ms-traffictypediagnostic: DM6PR02MB5308: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T4jxmSPfx6FJ8Z5ElCDKMq0BRyEniLTU9C5T14iWM8MgNwq4ChZ6YZASmiqM7X8JNvacUzs0cBqk/Bh7S+/Fzq5mmwqM+e/B9csRcvRFYqgjXPG5c3GHKJz1PGvHEbFxiGixLUpxM4pFiklQvJIHVcK/O++4yMpN+/6r23sFcdKkaLJduaw+0RcsXYwt1EoNiskvmk+yYJuUgfo8OkhRiB6eIO1AI+BpZC7xWorOIszXZBCN3z1ddRLzZO27bn2WvAKDi3+jWsjUV7Y6LAzYwF+ML9OrBlv2T9MBbs9wuf9fTXOADYKIjYilvLYfOlW8ENOR2ecBD0F29ag+OG6DzCiPjvMa+O+X2VBpphAZjIG9/5HIYSsoe8IYuS+y3/HcjG3cpAnZDqHyPOxnmjXgD+TiOqLJnmPubpv30Vc8voHRdgmTnt3eBfgc/8Lcky7cY8EqedcQUYgXxU2RAeptiy3A1gC5XVm1FNHtGjrzKFWMDDKp9sBDHTAK+nyR21nSl4lOX9rU9CfJrA+x1ErqDIRCuPOGiL1sYJ9IqYy3OHCKgLsTiFaQ+dsmdKDTJk5hdGTFrr9ErQwcvfc94X7YoNIRhEDbyVoUefisTtPNY/rgkmfcCdZhkKlHDdOyASvJxJpJA/DpOJFAgdrJxTGDiMXZDpqyQKEoWw75QTbDFE+3hkVmMjLGVcxmuAiuBnvpEpA94m2doiPN8N3HTNs0Ay+UAwAlehZPuBynwp6Brus= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(39860400002)(346002)(366004)(136003)(52536014)(7696005)(76116006)(26005)(186003)(6506007)(71200400001)(66946007)(66476007)(66556008)(64756008)(66446008)(3480700007)(33656002)(86362001)(122000001)(8676002)(5660300002)(82202003)(38070700005)(8936002)(6916009)(316002)(9686003)(55016002)(478600001)(38100700002)(2906002)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?D1qB17lm36JWMzo8xGP/Ku3BuirgGJEHgtMQlvGUizJV1wjL4dHHkj28X0Px?= =?us-ascii?Q?zcYxoXhlgNT3ZXz0C91taeSivS7EIkeYE85UsE3NISMgtEz0bXrLlrCJaVz4?= =?us-ascii?Q?7quVy8QCUiSNNsjFa5e5rqeSOoLWAt4spfxb55NisS19lpzIsCaOuZe6XvfR?= =?us-ascii?Q?kugdRj4vEUiN3oytQqKod+3E55Jc9i0AC0Xvr+uXGKnqWSpJnMPJ1KH4u7on?= =?us-ascii?Q?UBU3O7FFM25Z3Y9VNT/B718E+0LdZF66vsQiF5bEL12Do8r7OGp/hdBGVYIM?= =?us-ascii?Q?IY+pD0yIgRd/4xtA5NRYYpHEldtb9TNJY7whkTJXb5R3pYnMYhZIY9znmoFI?= =?us-ascii?Q?l4q9mi4sPnEnJMuXOBaaFSPKXODY7fkxQry5zPTFKiEqtCmTrZL2oqj49Ejw?= =?us-ascii?Q?GR2hauoMuFDxLwY3dwBWbKWWRgFNwk/3NeAsmlFdIHhHG5DbStB/TNmwyKVX?= =?us-ascii?Q?VNmD3/rwYM6L17hV/Sp/uHQQCEjvbsTgd9qypkYMKHHf8uX8tO0FK3ZsYYax?= =?us-ascii?Q?R+MgJrt+EeWkVxu44WIXBFnS8GgfAN6C7oB6x2/I35dPc2iIkb8GbQ94Fytz?= =?us-ascii?Q?fzZcyiyn7Olx/B6xfGCWuwOJHR1PVgQQXEfjebxngdrFgZevfbN5Y+yPsCDi?= =?us-ascii?Q?RNMnzJbycyqGTkYJJ+UW/DHuSQX1G/yuaTHSyGrpJDgmuiojC62GLmxjQhtY?= =?us-ascii?Q?0gJS5HwpUEfruCfVMuSl//oC0xhKoBMcKUx0wo9m9zu+0qKGxr2FxiEibz+q?= =?us-ascii?Q?Wl9MS9zmHKhwkr5g2HBV3Kf7n6i91JHA/XXwa3tIN1ItJx/23SlrH984wgGx?= =?us-ascii?Q?cE/oWlcR0MLPUCdabPlu4AfWy0PnAck3CTN02xiAPupRhhFiOZow+XkQU2XU?= =?us-ascii?Q?Utl3qQK4bKutewoHHW1/WLJbjfFc7I7mr7I1v+SS8JFNlU04zGs5I7w/5cMr?= =?us-ascii?Q?8GXc3BTqDYfLQv+EaKlt4zono9T72o5e9I1w5b5BfcRmuKJ6gjW6hUaSApUO?= =?us-ascii?Q?zU1Su+K2QgwVwIZeoC+Lw2qkr7g6g0ZHgF/yyE0UqnpCgfPM1fp4Q9xwBSe+?= =?us-ascii?Q?74D04jewXTqCj3wA9QLOWSCtISp3LkgRrHjAhTTSH09rn6ijfyM/TI24WY44?= =?us-ascii?Q?KRG7odXXbO+9gZZUQDrplK+hpyF8FqwUQYQZ6x9dFNqvd4ZhWm6Hw+ZJCV02?= =?us-ascii?Q?YHvQYy4b+pd+UdvqCJ+EjDyPUntLvifvnboj6LqiLDH0WdI9o7s5f/1hdu5d?= =?us-ascii?Q?FQYsZG5F8CiQEfn8KouPEHYfMb2//jndXWIk2TfDny2DqhNmIk6hVvm9wNKR?= =?us-ascii?Q?y+7lvg9VtU5KqO99p4AbKpcM?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61820726-5ea3-477f-845c-08d956910434 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 15:11:48.9039 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Rutqn83rl1Dpd0VWyIg0zNWzEueHpfCdmWvd50jCwOA1Q4f3irzAXcb0tWp1EK/P X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB5308 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: E16AA0866255BBD11175DB788498529181C8771C1684CC4D24FB42E20D97AE552 X-Proofpoint-GUID: GqRmgwrXggEObv8UY8ijaIdblA-6zWRq X-Proofpoint-ORIG-GUID: GqRmgwrXggEObv8UY8ijaIdblA-6zWRq X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-03_04:2021-08-03, 2021-08-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 malwarescore=0 clxscore=1011 suspectscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=847 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108030100 Archived-At: Subject: [babel] Babel DTLS and YANG 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, 03 Aug 2021 15:12:13 -0000 Hi Babelers, We're getting some comments on the YANG model that we need a little help wi= th. Specifically, we need help with the modeling of the DTLS private key. For DTLS, we've included data model support for X.509 certificates and Raw = Public Key. The certificate type (X.509 or Raw Public Key) is specified for every certi= ficate. Both have distinct public and private keys. Public keys are provided via the data model in PEM format. The public key PEM file includes info about the cipher suite that was used = to create the pair (RSA, Elliptic Curve, etc.) and therefore needs to be ne= gotiated in DTLS handshaking.=20 But for the private key, we had come to a consensus that the Babel implemen= tation just wanted the binary private key value.=20 If the private key were expressed in PKCS#8 (generic key format) PEM, we wo= uld have: -----BEGIN PRIVATE KEY----- BASE64 ENCODED DATA -----END PRIVATE KEY----- Within the base64 encoded data the following DER structure is present: ------------------------------------- PrivateKeyInfo ::=3D SEQUENCE { version Version, algorithm AlgorithmIdentifier, PrivateKey OCTET STRING } AlgorithmIdentifier ::=3D SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } --------------------------------------- AlgorthmIdentifier identifies the cipher suite. But it sounds like the binary private key value Babel is providing is just = the "PrivateKey" part of this.=20 Is that correct? If so, doesn't the implementation need to know the "Algori= thmIdentifier"? Or (since we supply the public key with the private key) ca= n or does the Babel implementation pick this up from the associated public = key? Thx, Barbara From nobody Wed Aug 4 11:35:17 2021 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 B89E53A1084; Wed, 4 Aug 2021 11:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 vk8qrwFMivtz; Wed, 4 Aug 2021 11:34:59 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 CBAB43A107A; Wed, 4 Aug 2021 11:34:58 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id mt6so4319262pjb.1; Wed, 04 Aug 2021 11:34:58 -0700 (PDT) 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=fzx24115GAnJFQ5uBvx2xkezPQ9ysRgTLiSYiHN1emg=; b=FpYfZHZoDxGhPwnhiUWpI3S7VJdpi2fYt5eo2xv0td2Y8i9ia/xOVcFjqEeu9vVSlH ogQodd9vIf/oMghIFEdCgkwr1xooHMsm+VIPh1lMopcVdzCb638AKyuVMfqyQZlsEGG/ UEZrLHWh5D8naJwHRZBFxtqZ2oFiK+PJ+zUhqPlmyLtDiGJqAPZaxQWCRwFoa2Pbv+yR F+tIr/q4CvvAAfXD/1A8bIQ+V5d7bIqosQS66YscLji/cfj7HPAtv5CJIW0Wv1kxHcl2 wZeHSIkLAU9Y+0LeawnT+/RYST7NEm/mTmLQjMk+WeJVhTIcgBNJ36QgxxeonPbjCBWc 4ePA== 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=fzx24115GAnJFQ5uBvx2xkezPQ9ysRgTLiSYiHN1emg=; b=kekXuoHbTlkK2PVxG8CCz4q7HXYvPxpw8Pj2pEWMnibWgYRzisopS5sU4EIj/kxKmy Hh3CSHeU4ynBh7HsdbG1VGRfIYznkeHSptsPnTBG5xPvUC1fEThAEUAFzj5aHVLJEiuH zJxoCp2XFbaDAY/v11pZ68tTwNNBZIjowli/KNHR3radvi4Oiw2OlLFc6tJVXI3MlqEg ppvGGnx9YklZTErNOUp46YuGCKhJhWfma/DJp5wAwVLcEjtDOIYOeLEAjsZ3KfvlGLwS tQGl63ErvMDoNrwTvxfOz55qBQs0qXS0cYYRvrw0UUNR+btw0tafQ2pFXNwfFvuU8deO v+kQ== X-Gm-Message-State: AOAM531Oy9HBhROa3RaEFhRsRnC3STK9FkOVPpjK+iTYZt8iOtOA21I2 hmVe4MrLcK1KxynuwePhgz4= X-Google-Smtp-Source: ABdhPJwHZYMir7mqkCAfCCLBXsFB36gFSACaVhRyrmtp9alGNKbvYO3vt//EzYLVRpGNtUIM7VdJow== X-Received: by 2002:a17:902:6bc8:b029:117:6a8a:f7af with SMTP id m8-20020a1709026bc8b02901176a8af7afmr490265plt.51.1628102097026; Wed, 04 Aug 2021 11:34:57 -0700 (PDT) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id h5sm3671328pfv.145.2021.08.04.11.34.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Aug 2021 11:34:56 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <6CDF1D68-7F33-4598-BA75-D6D824A04F1F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EE623D5B-92DF-4AAC-AFB9-09FC7A8249DA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 4 Aug 2021 11:34:52 -0700 In-Reply-To: <20210720235506.GX88594@kduck.mit.edu> Cc: The IESG , draft-ietf-babel-yang-model@ietf.org, babel-chairs , Babel at IETF , Donald Eastlake To: Benjamin Kaduk References: <162148379451.10850.9563671396439074857@ietfa.amsl.com> <99514803-6C88-40F8-B924-315945B052C1@gmail.com> <20210720235506.GX88594@kduck.mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT) 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, 04 Aug 2021 18:35:09 -0000 --Apple-Mail=_EE623D5B-92DF-4AAC-AFB9-09FC7A8249DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, No worries. See inline, and for brevity reasons I will also skip = =E2=80=9Cok=E2=80=9D, and other responses that would have acknowledged = but do not require a specific response. > On Jul 20, 2021, at 4:55 PM, Benjamin Kaduk wrote: >=20 > Hi Mahesh, Barbara, >=20 > My humble apologies for not responding earlier; this really was an > unreasonable amount of time for you to wait. >=20 > Responses inline, though for brevity I will omit remarks of the form > "sounds good", "thank you", etc. >=20 > On Tue, Jun 08, 2021 at 08:47:14AM -0700, Mahesh Jethanandani wrote: >> Hi Benjamin, >>=20 >> Thank you first of all for a detailed review. Some of the = comments/changes suggested here may impact the information model that = this draft depends on. The information model is in AUTH48 state at this = time. >>=20 >> This response includes feedback from my co-author Barbara. >>=20 >>> On May 19, 2021, at 9:09 PM, Benjamin Kaduk via Datatracker = wrote: >>>=20 >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-babel-yang-model-10: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> This is kind of nitpicky, and I'm sorry to pull out the heavy hammer = of >>> DISCUSS for it, but for the "dtls-cached-info" leaf with = description: >>>=20 >>> "Indicates whether the cached_info extension is = included >>> in ClientHello and ServerHello packets. The extension >>> is included if the value is 'true'."; >>>=20 >>> It is factually false to just say that "the extension is included if = the >>> value is true", and it contradicts the DTLS specification to say so. = In >>> particular, the extension can only be included in the ServerHello >>> message if it was present in the ClientHello message being responded = to. >>> So maybe we can say "enabled for inclusion" or append "when = permitted by >>> the protocol", or something similar? >>=20 >> How about this? >>=20 >> OLD: >> "Indicates whether the cached_info extension is included >> in ClientHello and ServerHello packets. The extension >> is included if the value is 'true'."; >>=20 >> NEW: >> "Indicates whether use of cached_info extension is = enabled. >> The extension is enabled for inclusion if the value is = 'true'."; >=20 > Both this form and Barbara's revision will address my concern. = Barbara's > version removes any ambiguity about what the "inclusion" would be in, = so > that seems preferred to me. Ok. Will use Barbara=E2=80=99s version. >=20 >>=20 >>>=20 >>> There's also a few places where we didn't quite clean up all the = fallout >>> from switching from enumerations to identities (for MAC and >>> DTLS-adjacent algorithms), that really ought to get fixed before >>> publication. I try to note them in the COMMENT. >>>=20 >>> I also think we need to be a bit more specific about the structure = of >>> the (binary) private-key leaf/values provided when a certificate = entry >>> is created. Ideally this would just be by reference to some other = spec, >>> but the situation is unfortunately messy. (It doesn't help that we >>> allow DTLS 1.2, which allows certificates that are used for = key-exchange >>> as opposed to signing, and those are not terribly mainstream.) We = may >>> need to pull in some other experts to figure out the right way to = write >>> about this. >>=20 >> Ok. The way I am reading this is that we need to wait to hear more = from the experts that you cite before making any changes. >>=20 >> Note, in WG discussion the ask was for the format of the private-key = to be binary. I am not an expert, but would it help if the description = said something about using PEM format for the private-key? >=20 > I think binary is probably fine; a PEM encoding is just base64 = encoding and > sometimes a little bit of a hint as to what the contained structure = is. > But my recollection is that the PEM type indication for certificate = private > keys is not always precise enough to indicate what is to be used, so = an > implementation would need to consult the "type" sibling leaf anyway in > order to process the "private-key"...but it's not entirely clear that = just > "type" is enough information on its own. >=20 > It is possible that we can find the necessary references without = pulling in > an external expert, but if we get stuck I would probably ask Russ = Housley > or Sean Turner for help. >=20 > As a starting point, I note that RFC 4211 lists several Private Key > structures in Section 4.2.2 in ASN.1 syntax. We would presumably = require > that the binary value exposed by the YANG module be the DER-encoded = version > of that ASN.1 structure. RFC 5915 has a private-key structure for ECC > keys. The complications then come in specifying how the other YANG > elements determine which (DER-encoded) ASN.1 structure is used for the > "private-key" contents. In particular, "dtls-cert-type" indicates = only a > "certificate type" in the TLS sense -- X.509, raw public key, and the = like. > Both X.509 certificates and raw public keys can use keys from = different > cryptosystems or cryptographic algorithms. So I find it pretty > inescapable that we'll need some in-band signaling about whether the > private-key is a basic RSA key, or perhaps an RSA-PSS key that has = some > specific associated parameters, vs a DH or DSA key, or ECDH, ECDSA, = EdDSA, > etc. With in-band signaling comes the need for a table or enumeration = of > what the different (currently supported) key structures are. It seems = that > draft-ietf-netconf-crypto-types may have a start at private-key = structures > of this sort, though I have not been following that work closely (it = seems > to be in WGLC at the moment). >=20 We will need to go back to the WG to discuss this. Let us get back to = you on this. >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Section 2.2 >>>=20 >>> In addition to information like the version number implemented by >>> this device, the model contains subtrees on 'constants', >>> 'interfaces', 'routes' and 'security'. >>>=20 >>> I don't see a 'security' node, but rather separate 'mac-key-set' and >>> 'dtls' nodes, both of which contain subtrees. >>=20 >> Fixed. >>=20 >>>=20 >>> Section 2.3 >>>=20 >>> A router running Babel routing protocol can determine the = parameters >>> it needs to use for an interface based on the interface name. = [...] >>>=20 >>> Is this always true, or only sometimes? >>=20 >> How about this? >>=20 >> OLD: >> A router running Babel routing protocol can determine the = parameters >> it needs to use for an interface based on the interface name. >>=20 >> NEW: >> A router running Babel routing protocol can sometimes determine the = parameters >> it needs to use for an interface based on the interface name. >>=20 >>>=20 >>> Transport Layer Security Version 1.2 [RFC6347], The Blake2 >>>=20 >>> (DTLS 1.3 is in the RFC Editor's queue, FWIW.) >>=20 >> Replaced it with reference to draft-ietf-tls-dtls13. >>=20 >>>=20 >>> leaf router-id { >>> type binary; >>> description >>> "router-id of the source router for which this route is >>> advertised."; >>=20 >>>=20 >>> IIRC we can do length constraints in YANG, and in Babel router-ids = are 8 >>> octets. Should we enshrine that in the YANG? >>=20 >> What would the constraint statement look like? For 'type uint32' I = see=20 >>=20 >> length =E2=80=9C1..4294967295=E2=80=9D; >>=20 >> but I am not sure for 'type binary=E2=80=99 what it would look like. >=20 > My understanding from > https://datatracker.ietf.org/doc/html/rfc7950#section-9.8.1 is that = "length > 8" indicates an 8-octet value. Ok. Added it. >=20 >>>=20 >>> leaf next-hop { >>> type inet:ip-address; >>> description >>> "The next-hop address of this route. This will be empty = if >>> this route has no next-hop address."; >>>=20 >>> What does it mean for an inet:ip-address to be "empty"? That the = node >>> is absent? >>=20 >> Yes, that the node is absent. Would it help if it said the following? >>=20 >> OLD: >> "The next-hop address of this route. This will be empty if >> this route has no next-hop address.=E2=80=9D; >>=20 >> NEW: >> "The next-hop address of this route. This will be NULL if >> this route has no next-hop address.=E2=80=9D; >=20 > I think so, yes. >=20 >>>=20 >>> "List of supported certificate types, in order of >>> preference. The values MUST be among those listed in >>> dtls-cert-types. This list is used to populate the >>>=20 >>> Since the element is of type leafref to the actual list of certs, it >>> seems like this MUST is achieved by construction (and thus need not = be >>> listed specifically). Though, "dtls-cert-types" appears in this >>> document only as the base identity for Babel DTLS certificate types, = so >>> this phrasing seems a bit odd...perhaps it is fallout from an >>> enumeration/identity conversion. >>=20 >> You are right. There is nothing to say that the leaf-list = =E2=80=98dtls-cert-prefer=E2=80=99 could not be just=20 >>=20 >> type identityref { >> base dtls-cert-types; >> } >>=20 >> which would a list of certificate types this particular = implementation supports. The assumption is that the list of certificate = types that the implementation can support is not different from what it = does support. @Barbara, would it be ok for the data model to just keep = one list of certificate types? >=20 > I see there was an additional follow-up; that text looks good modulo = the > duplicate word "in in" across the line break. >=20 >>>=20 >>> server_certificate_type extension in a Client Hello. >>> Values that are present in at least one instance in = the >>> certs object under dtls of a referenced dtls instance >>> and that have a non-empty private-key will be used to >>> populate the client_certificate_type extension in a >>> Client Hello."; >>>=20 >>> Since the DTLS server picks which certificate types are actually = used, >>> it is conceivable that the preference order in this list could also = be >>> used as input to the server's choice of type. That said, I don't = think >>> there is universal API support for DTLS servers accepting a = preference >>> list directly, so we would not want to imply that this list would = always >>> be used in such a fashion. But it could be used in such a fashion. >>=20 >> Based on what I understood of your comment, what do you think of this = change? Or did I completely misunderstand you?? >=20 > Sorry for my rambly comment, which is really more of a side note than > something intended to change the document. The OLD text is better = than the > NEW. My question (to the extent there was a question) here was along = the > lines of whether we should be more precise about whether "used to = populate" > includes retaining the preference order. I don't think it's currently > possible to actually do that, though, so my recommendation is to leave = this > text unchanged. >=20 >> OLD: >>=20 >> This list is used to populate the >> server_certificate_type extension in a Client Hello. >> Values that are present in at least one instance in the >> certs object under dtls of a referenced dtls instance >> and that have a non-empty private-key will be used to >> populate the client_certificate_type extension in a >> Client Hello. >>=20 >> NEW: >>=20 >> This list could be used to populate the >> server_certificate_type extension in a Client Hello. >> Values that are present in at least one instance in the >> certs object under dtls of a referenced dtls instance >> and that have a non-empty private-key will be used to >> populate the client_certificate_type extension in a >> Client Hello. >>=20 >>>=20 >>> container stats { >>> config false; >>> description >>> "Statistics collection object for this interface."; >>>=20 >>> Often, YANG models with such statistics containers will also include = a >>> leaf to indicate the "discontinuity time" at which the counters were >>> last reset. >>=20 >> Hmm. I wonder if that is not an implementation level detail. >=20 > My understanding is that it is not typically treated as an = implementation > detail, but my understanding is just an inference based on seeing a = number > of YANG modules go by during my time as an AD. Rob Wilton might have = a > better sense, or we could ask a YANG doctor for help (or both). Ok. I have added a =E2=80=98discontinuity-counter=E2=80=99 from other = YANG models, and is pretty much a cut-and-paste :-(. I imagine it is not = controversial addition, but do want to inform the WG, here, about the = addition. >=20 >>>=20 >>> leaf hello-mcast-history { >>> type string; >>> description >>> "The multicast Hello history of whether or not the >>> multicast Hello packets prior to exp-mcast- >>> hello-seqno were received, with a '1' for the most >>> recent Hello placed in the most significant bit and >>> prior Hellos shifted right (with '0' bits placed >>> between prior Hellos and most recent Hello for any >>> not-received Hellos); represented as a string using >>> utf-8 encoded hex digits where a '1' bit =3D Hello >>> received and a '0' bit =3D Hello not received."; >>>=20 >>> I'd consider adding a few more words to confirm that this is the hex >>> representation of a bitstring (so, all hex digits are possible), not = a >>> string consisting of only '1' and '0' characters. >>> (Likewise for hello-ucast-history.) >>=20 >> But doesn=E2=80=99t the model already say that in the last sentence? = If not, can you suggest text? >=20 > I think you are correct that the model basically says that already. = My > concern was that since we use the quoted forms "'1' bit" and "'0' = bit", > someone might think that we are using only binary digits (which are, = after > all, a subset of hex digits) and write out a binary representation = rather > than a hex one. This is, admittedly, a little farfetched, but since I > already opened the topic, my attempt at rewording would be "[...] > represented as a string of utf-encoded hex digits. A bit that is set > indicates that the corresponding Hello was received, and a bit that is > cleared indicates that the corresponding Hello was not received". Ok. I have edited the text and it now reads as: =E2=80=9C... represented as a string of utf-8 encoded hex digits. A bit that is set indicates that the corresponding Hello was received, and a bit that is cleared indicates that the corresponding Hello was not received." >=20 >>>=20 >>> leaf exp-mcast-hello-seqno { >>> type uint16; >>> default "0"; >>> description >>> "Expected multicast Hello sequence number of next = Hello >>> to be received from this neighbor; if multicast = Hello >>> packets are not expected, or processing of multicast >>> packets is not enabled, this MUST be NULL."; >>>=20 >>> It's not really clear to me that assigning semantics to a NULL leaf >>> makes sense when there is a default value for it (that has already >>> assigned semantics to an absent leaf). >>> (et seq) >>=20 >> Ok. Will remove the default value. >>=20 >>>=20 >>> leaf value { >>> type binary; >>> mandatory true; >>> description >>> "The value of the MAC key. An implementation MUST NOT >>> allow this parameter to be read. This can be done by >>>=20 >>> I believe that we can incorporate this restriction in the YANG = itself >>> with something like "nacm:default-deny-all". >>=20 >> Ok. Will add 'nacm:default-deny-all' and drop the text =E2=80=9CAn = implementation .. subsequently writeable=E2=80=9D. >>=20 >>>=20 >>> description >>> "The name of the MAC algorithm used with this key. = The >>> value MUST be the same as one of the enumerations >>> listed in the mac-algorithms parameter."; >>>=20 >>> It's now an identityref, not a name. Accordingly, there are also = not >>> any enumerations listed in the mac-algorithms parameter. >>=20 >> How about this? >>=20 >> OLD: >>=20 >> "The name of the MAC algorithm used with this key. The >> value MUST be the same as one of the enumerations >> listed in the mac-algorithms parameter.=E2=80=9D; >>=20 >> NEW: >>=20 >> "The MAC algorithm used with this key. The >> value MUST be one of the identities >> listed with the base of 'mac-algorithms'.=E2=80=9D; >>=20 >>>=20 >>> description >>> "The name of the certificate type of this object >>> instance. The value MUST be the same as one of the >>> enumerations listed in the dtls-cert-types >>> parameter. This value can only be provided when this >>>=20 >>> Similarly, this is also identityref, and also has no enumerations = listed >>> in the dtls-cert-types parameter. >>=20 >> How about this? >>=20 >> OLD: >>=20 >> "The name of the certificate type of this object >> instance. The value MUST be the same as one of the >> enumerations listed in the dtls-cert-types >> parameter.=20 >>=20 >> NEW: >>=20 >> "The certificate type of this object >> instance. The value MUST be the same as one of the >> identities listed with the base of 'dtls-cert-types'.=20= >>=20 >>>=20 >>> leaf private-key { >>> type binary; >>> mandatory true; >>> description >>> "The value of the private key. If this is non-empty, >>> this certificate can be used by this implementation = to >>> provide a certificate during DTLS handshaking. An >>> implementation MUST NOT allow this parameter to be >>> read. This can be done by always providing an empty >>>=20 >>> (nacm:default-deny-all could be useful here as well) >>=20 >> Ok. Will add it and drop the appropriate text around it. >>=20 >>>=20 >>> string, or through permissions, or other means. This >>> value can only be provided when this instance is >>> created, and is not subsequently writable."; >>>=20 >>> It is perhaps a bit limiting to require the actual private key value = to >>> be supplied, since that would preclude the use of (e.g.) HSM-based >>> private keys. But since we are basically inheriting from the >>> information model here, I won't press it too hard. >>>=20 >>> Section 4 >>>=20 >>> It might be worth referencing the security considerations of >>> 8966/8967/8968 as being applicable. >>=20 >> I understand that the Babel protocol itself is a insecure protocol. = But I am not clear on how that is applicable to the YANG model that is = used to configure or read the *state* of the protocol (over a secure = interface). How about we add this? Thanks to Barbara for providing the = text. >>=20 >> "The security considerations outlined here are specific to the YANG = data model, and do not cover security considerations of the Babel = protocol or its security mechanisms [RFC8966][RFC8967][RFC8968]. Each of = these have their own Security Considerations section for considerations = that are specific to it." >=20 > That looks wonderful; thank you! >=20 >>>=20 >>> The security (privacy, really) considerations of RFC 7924 are also >>> arguably relevant, relating to the use of the TLS "cached_info" >>> extension. >>=20 >> Isn=E2=80=99t this something that is relevant to RFC8968? The YANG = model is merely allowing for the configuration of the capability = specified in RFC8968. Shouldn=E2=80=99t any security considerations for = =E2=80=9Ccached_info=E2=80=9D therefore be mentioned there? >=20 > okay. My "arguably" was intended to imply "and also arguably not" >=20 >>>=20 >>> Are there any security and/or privacy considerations relating to the >>> logging of babel packets? >>=20 >> We say the following in the security considerations section. >>=20 >> 'babel': Access to the information in the various nodes can = disclose >> the network topology. Additionally, the routes used by a network >> device may be used to mount a subsequent attack on traffic = traversing >> the network device. >=20 > Hmm, my understanding was that the routes used by a given device are a > function of the received packets but that the packets themselves can > contain more information than just the routes currently used. If = that's > the case, then enabling a full packet log would disclose that "more > information", but I don't know offhand exactly what that information = is, I > can't write good text to use here. Ok. How about if we add this in the config true section of the Security = Considerations section? =E2=80=98packet-log-enable=E2=80=99 and =E2=80=98packet-log=E2=80=99: = Enabling the logging of packets and unintended access to the log files = gives an attacker detailed knowledge of the network, and allow it to = launch an attack on the traffic traversing the network device. >=20 >>>=20 >>> There are a number of data nodes defined in the YANG module which = are >>> writable/created/deleted (i.e., config true, which is the default). >>>=20 >>> I don't think "writable/created/deleted" is part of the template. >>=20 >> Thanks to Barbara for digging this out: >>=20 >> https://datatracker.ietf.org/doc/html/rfc8407.html#section-3.7.1 = : >>=20 >> There are a number of data nodes defined in this YANG module that are >> writable/creatable/deletable >=20 > My mistake, apologies for that. > I think I typically use > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines as the > reference, but the phrase in question appears there as well. >=20 >>>=20 >>> 'babel/hmac' and 'babel/dtls': These contain security credentials >>> that influence whether packets are trusted. >>>=20 >>> I'd consider making two separate (but related) points about = controlling >>> whether incoming packets are trusted, and whether outgoing packets = are >>> produced in a way such that the receiver will treat them as trusted. >>> (Changing just the use-send/use-verify values can allow for a valid = key >>> to be misused, without changing the actual keys being used, which = could >>> present an interesting attack in some scenarios.) >>=20 >> Ok. How about this? Thanks again to Barbara for providing the text. >>=20 >> =E2=80=9CThese contain security credentials >> that influence whether incoming packets are trusted, and whether = outgoing packets are >> produced in a way such that the receiver will treat them as = trusted.=E2=80=9D >>=20 >>>=20 >>> Some of the readable data or config false nodes in this YANG module >>> may be considered sensitive or vulnerable in some network >>> [...] >>> 'babel/hmac' and 'babel/dtls': These contain security credentials, >>> include private credentials of the router. >>>=20 >>> We do require the actual secret keys to not be readable, so we might >>> consider phrasing this more as a reiteration of that requirement = than a >>> statement of risk if they are read out. >>=20 >> How about this? Thanks Barbara. >>=20 >> 'babel/hmac' and 'babel/dtls': These contain security credentials, >> including private credentials of the router; however it is >> required that these values not be readable. >>=20 >>>=20 >>> Some of the RPC operations in this YANG module may be considered >>> sensitive or vulnerable in some network environments. It is thus >>> important to control access to these operations. These are the >>> operations and their sensitivity/vulnerability from a RPC operation >>> perspective: >>>=20 >>> This model does not define any RPC operations. >>>=20 >>> We do define a couple of actions, though, which are like RPCs except >>> "[t]he difference between an action and an rpc is that an action is = tied >>> to a node in the datastore, whereas an rpc is not". This is perhaps = an >>> omission in the YANG security considerations template, but I don't = think >>> we should let that stop us from noting the actions we define are >>> carefully designed to have minimal security impact and minimal >>> side-channel leakage. (Well, I guess that's not hard for the >>> stats-reset one, but for the MAC key test one it's quite important.) >>=20 >> How about this? >>=20 >> OLD: >>=20 >> This model does not define any RPC operations. >>=20 >> NEW: >>=20 >> This model defines two actions, one of which >> allows for MAC key and MAC algorithm to be tested.=20 >> It does not allows for them to be changed. >=20 > That's an improvement, certainly. I would propose >=20 > NEW 2: >=20 > This model defines two actions. Resetting the statistics within an > interface container would be visible to any monitoring processes, = which > should be designed to account for the possibility of such a reset. > The "test" action allows for validation that a MAC key and MAC = algorithm > have been properly configured. The MAC key is a sensitive piece of > information, and it is important to prevent an attacker that does not = know > the MAC key from being able to determine the MAC value of an > attacker-influenced plaintext. The "test" action has been designed = to > not reveal such information directly. Such information might also be > revealed indirectly, due to side channels such as the time it takes = to > produce a response to the action. Implementations SHOULD use a > constant-time comparison between the input mac and the locally = generated > MAC value for comparison, in order to avoid such side channel = leakage. I am fine with this proposed text. >=20 >>>=20 >>> Section 6.1 >>>=20 >>> I don't have a great sense for why RFC 4868 needs to be normative. >>=20 >> RFC 4868 is cited as a reference in the YANG model, which is = normative. >>=20 >>>=20 >>> RFC 8968 seems missing as a listed reference at all (which would of >>> course need to be normative as 8967 is). >>=20 >> Agreed. >>=20 >>>=20 >>> Section 6.2 >>>=20 >>> I think RFC 7693 should be normative, since you need it in order to = do >>> the blake2 stuff. >>=20 >> Ok. Will move it to normative section. >>=20 >>>=20 >>> RFC 8341 might become normative if we add nacm:default-deny-all = stanzas. >>=20 >> Agreed. >>=20 >>>=20 >>> NITS >>>=20 >>> The tree diagram and the prose use different orders for the various >>> child elements, which is a little distracting. >>=20 >> Ok. Will fix the order. >>=20 >>>=20 >>> Section 1 >>>=20 >>> [RFC8966]. The data model is defined using YANG 1.1 [RFC7950] data >>> modeling language and is Network Management Datastore Architecture >>>=20 >>> "the YANG [data modeling language]" >>=20 >>>=20 >>> Section 2.1 >>>=20 >>> Information Model and this data module. The information model >>> mandates the definition of some of the attributes, e.g. 'babel- >>>=20 >>> comma after "e.g." (as well as before). (I'll try to only note it = once, >>> though it appears many times.) Likewise for "i.e." >>=20 >>>=20 >>> Section 2.2 >>>=20 >>> In addition to information like the version number implemented by >>> this device, the model contains subtrees on 'constants', >>>=20 >>> The actual data model (and the information model, for that matter) = show >>> that the 'version' leaf contains "the name and version of this >>> implementation of the Babel protocol". The text here suggests that = it >>> contains the protocol version number implemented by the device, = which is >>> different. So I'd suggest "the implementation and version used by = this >>> device" instead. >>=20 >>>=20 >>> The 'interfaces' subtree describes attributes such as 'interface' >>> object that is being referenced, the type of link, e.g. wired, >>>=20 >>> "the 'interface'" >>=20 >> Ok to the above suggested changes. >>=20 >>>=20 >>> wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- >>> horizon' and whether the interface is enabled or not. >>>=20 >>> I suggest using semicolons for the outer layer of grouping, to avoid >>> overloading commas for different hierarchies of separation. >>=20 >> Something like this? >>=20 >> OLD: >>=20 >> The 'interfaces' subtree describes attributes such as 'interface' >> object that is being referenced, the type of link, e.g. wired, >> wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- >> horizon' and whether the interface is enabled or not. >>=20 >> NEW: >>=20 >> The 'interfaces' subtree describes attributes such as 'interface' >> object that is being referenced, the type of link, e.g., wired, >> wireless or tunnel; as enumerated by 'metric-algorithm' and 'split- >> horizon=E2=80=99; and whether the interface is enabled or not. >=20 > When I was reading it, my expectation was something like >=20 > NEW 2: >=20 > The 'interfaces' subtree describes attributes such as the = 'interface' > object that is being referenced; the type of link, e.g., wired, > wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- > horizon=E2=80=99; and whether the interface is enabled or not. >=20 > but I trust your understanding of how the technology works more than = my > understanding! As I understand it, the interface can be described as being either = =E2=80=98wired', =E2=80=98wireless' or =E2=80=98tunnel'. It can be = further described by setting values of =E2=80=98metric-algorithm=E2=80=99 = and =E2=80=99split-horizon=E2=80=99. Finally, the interface can be = enabled or disabled. So I would suggest one small change to your NEW 2. NEW 3: The 'interfaces' subtree describes attributes such as the 'interface' object that is being referenced; the type of link, e.g., wired, wireless or tunnel; it is enumerated by 'metric-algorithm' and 'split- horizon=E2=80=99; and whether the interface is enabled or not. >=20 >>=20 >>>=20 >>> Finally, for security two subtree are defined to contain MAC keys = and >>> DTLS certificates. The 'mac-key-set' subtree contains keys used = with >>>=20 >>> "subtrees" >>=20 >>>=20 >>> interfaces. The dtls subtree contains certificates used with DTLS >>>=20 >>> single quotes for 'dtls'. >>> "the DTLS" >>=20 >>>=20 >>> Section 2.3 >>>=20 >>> Similarly, an interface that is a metered 3G link, and used for >>> fallback connectivity needs much higher default time constants, = e.g. >>>=20 >>> Comma after "connectivity". >>=20 >>>=20 >>> HMAC: Keyed-Hashing for Message Authentication [RFC2104], Using >>> HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4868], Datagram >>>=20 >>> The "with IPsec" part of RFC 4868's title seems to have been = dropped. >>=20 >> Ok to the above suggested changes. >>=20 >>>=20 >>> "This implementation supports two-out-of-three metric >>> comp algorithm."; >>>=20 >>> "the two-out-of-three". >>> Also, do we really need to (silently) abbreviate "metric = computation" >>> (multiple occurrences)? >>=20 >> Should be: >>=20 >> =E2=80=9Cthe =E2=80=99two-out-of-three=E2=80=99=E2=80=9D.=20 >>=20 >> Will fix metric comp occurrences. >>=20 >>>=20 >>> "This implementation supports Expected Transmission Count >>>=20 >>> "the Expected" >>=20 >> Ok. >>=20 >>>=20 >>> "This implementation supports hmac-sha256 MAC algorithm."; >>>=20 >>> "the hmac-sha256" >>>=20 >>> "This implementation supports x-509 certificate type."; >>>=20 >>> "the X.509" >>=20 >> Ok to both. >>=20 >>>=20 >>> "This implementation supports raw-public-key certificate >>> type."; >>>=20 >>> Missing article, per the theme, but I think it would also be more >>> conventional to spell the name as "RawPublicKey". >>=20 >> Ok. That was done to be consistent with the IM. >>=20 >>>=20 >>> base metric-comp-algorithms; >>> if-feature "etx-supported"; >>> description >>> "Expected Transmission Count."; >>=20 >>>=20 >>> I'd put an "algorithm" in here somewhere >>=20 >>=20 >> How about: >>=20 >> =E2=80=9CExpected Transmission Count (ETX) metric compilation = algorithm.=E2=80=9D >>=20 >>>=20 >>> "BLAKE2s algorithms supported. Specifically, BLAKE2-128 is >>> supported."; >>>=20 >>> I'd just say "BLAKE2-128 algorithm supported." >>=20 >> Then shouldn=E2=80=99t the feature say >>=20 >> feature blake2-128-supported? >=20 > My understanding of the nit (if any) here was about "algorithms" = (plural) vs > "algorithm" (singular), since this is a single YANG identity that can = only > have a single semantic. So, we could choose to make it be "indicates = that > BLAKE2-128 and BLAKE2-256 are both supported" or just "indicates that > BLAKE2-128 is supported". Given the second sentence, my understanding = is > that this particular YANG identity indicates that BLAKE2-128 is = supported, > even if the feature "blake2s-supported" might in the future indicate > whether some other blake2s variant is supported in addition to this = one. > If this YANG identity only indicates that a single algorithm is = supported, > I don't think the plural "algorithms" adds much value, and once that = part > is gone then the value of the first sentence comes into question as = well. My intent of naming the feature =E2=80=98blake2-supported=E2=80=99 was = to include *all* BLAKE2 algorithms, even if there is support only for = BLAKE2-128. I can drop the second sentence in the description to just = say: "This implementation supports all blake2s MAC algorithms.=E2=80=9D; >=20 >>>=20 >>> "Raw Public Key type."; >>>=20 >>> "certificate type" >>=20 >>>=20 >>> leaf router-id { >>> type binary; >>>=20 >>> (If length constraint is applied earlier, it should apply here as = well.) >>>=20 >>> "Indicates whether statistics collection is enabled = (true) >>> or disabled (false) on all interfaces. When enabled, >>> existing statistics values are not cleared and will be >>> incremented as new packets are counted."; >>>=20 >>> I suggest "on transition to enabled". >>> (Also, thank you for clearly spelling out which behaviors true/false = map >>> to!) >>=20 >>>=20 >>> A value of true indicates split horizon optimization >>> is used."; >>> "the split" >>>=20 >>> "List of references to the mac entries that apply >>> to this interface. When an interface instance is >>> created, all mac instances with default-apply 'true' >>>=20 >>> s/mac/MAC/ (twice) >>>=20 >>> "Indicates whether the cached_info extension is = included >>> in ClientHello and ServerHello packets. The extension >>>=20 >>> s/packets/messages/. >>=20 >> Ok to the above suggested changes. >>=20 >>> Also, it's conventional to refer to TLS extension names enclosed by >>> double quotes, but I guess in the context of a YANG leaf description >>> that's not really feasible. >>=20 >> Correct. >>=20 >>>=20 >>> dtls-cert-types. This list is used to populate the >>> server_certificate_type extension in a Client Hello. >>>=20 >>> s/Client Hello/ClientHello/. >>>=20 >>> list mac-key-set { >>> key "name"; >>>=20 >>> description >>> "A mac key set object. If this object is implemented, it >>> provides access to parameters related to the MAC = security >>> mechanism."; >>>=20 >>> s/mac/MAC/ >>>=20 >>> "A string that uniquely identifies the mac object."; >>>=20 >>> s/mac/MAC key/ >>>=20 >>> If 'true', this instance is applied to new babel- >>> interfaces instances at the time they are created, >>> by including it in the mac-key-sets list under >>> interfaces. If 'false', this instance is not applied >>>=20 >>> s/under interfaces/under the interface/ >>>=20 >>> to new interfaces instances when they are created."; >>>=20 >>> s/interfaces/interface/ >>>=20 >>> If 'true', this instance is applied to new interfaces >>> instances at the time they are created, by including = it >>> in the dtls-certs list under interfaces. If 'false', >>>=20 >>> s/under interfaces/under the interface/ >>>=20 >>> this instance is not applied to new interfaces >>> instances when they are created."; >>>=20 >>> s/interfaces/interface/ >>=20 >> Ok to make the above suggested changes. >>=20 >> Thanks again for a detailed review! >=20 > And thank you for the detailed responses and updates; as I noted in = the > preface, the ones I did not reply to all look good! >=20 > My apologies once more for the slow response time, >=20 > Ben Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_EE623D5B-92DF-4AAC-AFB9-09FC7A8249DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Ben,

No worries. See inline, and for brevity = reasons I will also skip =E2=80=9Cok=E2=80=9D, and other responses that = would have acknowledged but do not require a specific response.

On Jul 20, 2021, at 4:55 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

Hi Mahesh, Barbara,

My humble = apologies for not responding earlier; this really was an
unreasonable amount of time for you to wait.

Responses inline, though for brevity I will omit remarks of = the form
"sounds good", "thank you", etc.

On Tue, Jun 08, 2021 at 08:47:14AM -0700, Mahesh Jethanandani = wrote:
Hi = Benjamin,

Thank you first of all for a = detailed review. Some of the comments/changes suggested here may impact = the information model that this draft depends on. The information model = is in AUTH48 state at this time.

This = response includes feedback from my co-author Barbara.

On May 19, 2021, at 9:09 = PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:

Benjamin Kaduk has entered the following ballot position = for
draft-ietf-babel-yang-model-10: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

This is kind of nitpicky, and I'm = sorry to pull out the heavy hammer of
DISCUSS for it, but = for the "dtls-cached-info" leaf with description:

=             &n= bsp;"Indicates whether the cached_info extension is included
=             &n= bsp; in ClientHello and ServerHello packets. The extension
=             &n= bsp; is included if the value is 'true'.";

It is factually false to just say that "the extension is = included if the
value is true", and it contradicts the = DTLS specification to say so.  In
particular, the = extension can only be included in the ServerHello
message = if it was present in the ClientHello message being responded to.
So maybe we can say "enabled for inclusion" or append "when = permitted by
the protocol", or something similar?

How about this?

OLD:
=            "Indicat= es whether the cached_info extension is included
=             in= ClientHello and ServerHello packets. The extension
=             is= included if the value is 'true'.";

NEW:
=            "Indicat= es whether use of cached_info extension is enabled.
=             Th= e extension is enabled for inclusion if the value is 'true'.";

Both this form and Barbara's = revision will address my concern.  Barbara's
version = removes any ambiguity about what the "inclusion" would be in, so
that seems preferred to me.

Ok. Will = use Barbara=E2=80=99s version.




There's also a few places where = we didn't quite clean up all the fallout
from switching = from enumerations to identities (for MAC and
DTLS-adjacent = algorithms), that really ought to get fixed before
publication.  I try to note them in the COMMENT.

I also think we need to be a bit more specific = about the structure of
the (binary) private-key = leaf/values provided when a certificate entry
is created. =  Ideally this would just be by reference to some other spec,
but the situation is unfortunately messy.  (It doesn't = help that we
allow DTLS 1.2, which allows certificates = that are used for key-exchange
as opposed to signing, and = those are not terribly mainstream.)  We may
need to = pull in some other experts to figure out the right way to write
about this.

Ok. The = way I am reading this is that we need to wait to hear more from the = experts that you cite before making any changes.

Note, in WG discussion the ask was for the format of the = private-key to be binary. I am not an expert, but would it help if the = description said something about using PEM format for the = private-key?

I think binary is = probably fine; a PEM encoding is just base64 encoding and
sometimes a little bit of a hint as to what the contained = structure is.
But my recollection is that the PEM type = indication for certificate private
keys is not always = precise enough to indicate what is to be used, so an
implementation would need to consult the "type" sibling leaf = anyway in
order to process the "private-key"...but it's = not entirely clear that just
"type" is enough information = on its own.

It is possible that we can find = the necessary references without pulling in
an external = expert, but if we get stuck I would probably ask Russ Housley
or Sean Turner for help.

As a = starting point, I note that RFC 4211 lists several Private Key
structures in Section 4.2.2 in ASN.1 syntax.  We would = presumably require
that the binary value exposed by the = YANG module be the DER-encoded version
of that ASN.1 = structure.  RFC 5915 has a private-key structure for ECC
keys.  The complications then come in specifying how the = other YANG
elements determine which (DER-encoded) ASN.1 = structure is used for the
"private-key" contents.  In = particular, "dtls-cert-type" indicates only a
"certificate = type" in the TLS sense -- X.509, raw public key, and the like.
Both X.509 certificates and raw public keys can use keys from = different
cryptosystems or cryptographic algorithms. =  So I find it pretty
inescapable that we'll need some = in-band signaling about whether the
private-key is a basic = RSA key, or perhaps an RSA-PSS key that has some
specific = associated parameters, vs a DH or DSA key, or ECDH, ECDSA, EdDSA,
etc.  With in-band signaling comes the need for a table = or enumeration of
what the different (currently supported) = key structures are.  It seems that
draft-ietf-netconf-crypto-types may have a start at = private-key structures
of this sort, though I have not = been following that work closely (it seems
to be in WGLC = at the moment).


We will = need to go back to the WG to discuss this. Let us get back to you on = this.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Section 2.2

 In addition to information like the version number = implemented by
 this device, the model contains = subtrees on 'constants',
 'interfaces', 'routes' and = 'security'.

I don't see a 'security' node, = but rather separate 'mac-key-set' and
'dtls' nodes, both = of which contain subtrees.

Fixed.


Section 2.3

=  A router running Babel routing protocol can determine the = parameters
 it needs to use for an interface based = on the interface name.  [...]

Is this = always true, or only sometimes?

How about this?

OLD:
  A router running Babel routing protocol can = determine the parameters
  it needs to use for = an interface based on the interface name.

NEW:
  A router running Babel = routing protocol can sometimes determine the parameters
=   it needs to use for an interface based on the interface = name.


 Transport Layer Security Version 1.2 = [RFC6347], The Blake2

(DTLS 1.3 is in the = RFC Editor's queue, FWIW.)

Replaced it with reference to draft-ietf-tls-dtls13.


       leaf router-id = {
=          type binary;
=          description
=            "router-= id of the source router for which this route is
=             ad= vertised.";


IIRC we can do length = constraints in YANG, and in Babel router-ids are 8
octets. =  Should we enshrine that in the YANG?

What would the constraint statement look like? For 'type = uint32' I see

length = =E2=80=9C1..4294967295=E2=80=9D;

but I am = not sure for 'type binary=E2=80=99 what it would look like.

My understanding from
https://datatracker.ietf.org/doc/html/rfc7950#section-9.8.1= is that "length
8" indicates an 8-octet value.

Ok. Added = it.



=        leaf next-hop {
=          type = inet:ip-address;
=          description
=            "The = next-hop address of this route. This will be empty if
=             th= is route has no next-hop address.";

What = does it mean for an inet:ip-address to be "empty"?  That the = node
is absent?

Yes, that the node is absent. Would it help if it said the = following?

OLD:
=          "The next-hop = address of this route. This will be empty if
=           this route = has no next-hop address.=E2=80=9D;

NEW:
         "The = next-hop address of this route. This will be NULL if
=           this route = has no next-hop address.=E2=80=9D;

I think so, yes.


=             &n= bsp;"List of supported certificate types, in order of
=             &n= bsp; preference. The values MUST be among those listed in
=             &n= bsp; dtls-cert-types. This list is used to populate the

Since the element is of type leafref to the = actual list of certs, it
seems like this MUST is achieved = by construction (and thus need not be
listed = specifically).  Though, "dtls-cert-types" appears in this
document only as the base identity for Babel DTLS certificate = types, so
this phrasing seems a bit odd...perhaps it is = fallout from an
enumeration/identity conversion.

You are right. There is nothing = to say that the leaf-list =E2=80=98dtls-cert-prefer=E2=80=99 could not = be just

=            type = identityref {
=             &n= bsp;base dtls-cert-types;
=            }

which would a list of certificate types this = particular implementation supports. The assumption is that the list of = certificate types that the implementation can support is not different = from what it does support. @Barbara, would it be ok for the data model = to just keep one list of certificate types?
I see there was an additional follow-up; that text looks = good modulo the
duplicate word "in in" across the line = break.


=             &n= bsp; server_certificate_type extension in a Client Hello.
=             &n= bsp; Values that are present in at least one instance in the
=             &n= bsp; certs object under dtls of a referenced dtls instance
=             &n= bsp; and that have a non-empty private-key will be used to
=             &n= bsp; populate the client_certificate_type extension in a
=             &n= bsp; Client Hello.";

Since the DTLS = server picks which certificate types are actually used,
it = is conceivable that the preference order in this list could also be
used as input to the server's choice of type.  That = said, I don't think
there is universal API support for = DTLS servers accepting a preference
list directly, so we = would not want to imply that this list would always
be = used in such a fashion.  But it could be used in such a fashion.

Based on what I understood of = your comment, what do you think of this change? Or did I completely = misunderstand you??

Sorry for = my rambly comment, which is really more of a side note than
something intended to change the document.  The OLD text = is better than the
NEW.  My question (to the extent = there was a question) here was along the
lines of whether = we should be more precise about whether "used to populate"
includes retaining the preference order.  I don't think = it's currently
possible to actually do that, though, so my = recommendation is to leave this
text unchanged.

OLD:

=            This = list is used to populate the
=             se= rver_certificate_type extension in a Client Hello.
=             Va= lues that are present in at least one instance in the
=             ce= rts object under dtls of a referenced dtls instance
=             an= d that have a non-empty private-key will be used to
=             po= pulate the client_certificate_type extension in a
=             Cl= ient Hello.

NEW:

=            This = list could be used to populate the
=             se= rver_certificate_type extension in a Client Hello.
=             Va= lues that are present in at least one instance in the
=             ce= rts object under dtls of a referenced dtls instance
=             an= d that have a non-empty private-key will be used to
=             po= pulate the client_certificate_type extension in a
=             Cl= ient Hello.


=          container stats = {
=            config = false;
=            descript= ion
=             &n= bsp;"Statistics collection object for this interface.";

Often, YANG models with such statistics containers will also = include a
leaf to indicate the "discontinuity time" at = which the counters were
last reset.

Hmm. I wonder if that is not an = implementation level detail.

My = understanding is that it is not typically treated as an = implementation
detail, but my understanding is just an = inference based on seeing a number
of YANG modules go by = during my time as an AD.  Rob Wilton might have a
better sense, or we could ask a YANG doctor for help (or = both).

Ok. I have added a =E2=80=98discontinuity-counter=E2= =80=99 from other YANG models, and is pretty much a cut-and-paste :-(. I = imagine it is not controversial addition, but do want to inform the WG, = here, about the addition.



=            leaf = hello-mcast-history {
=             &n= bsp;type string;
=             &n= bsp;description
=             &n= bsp;  "The multicast Hello history of whether or not the
=             &n= bsp;   multicast Hello packets prior to exp-mcast-
=             &n= bsp;   hello-seqno were received, with a '1' for the = most
=             &n= bsp;   recent Hello placed in the most significant bit = and
=             &n= bsp;   prior Hellos shifted right (with '0' bits = placed
=             &n= bsp;   between prior Hellos and most recent Hello for = any
=             &n= bsp;   not-received Hellos); represented as a string = using
=             &n= bsp;   utf-8 encoded hex digits where a '1' bit =3D = Hello
=             &n= bsp;   received and a '0' bit =3D Hello not = received.";

I'd consider adding a few more = words to confirm that this is the hex
representation of a = bitstring (so, all hex digits are possible), not a
string = consisting of only '1' and '0' characters.
(Likewise for = hello-ucast-history.)

But = doesn=E2=80=99t the model already say that in the last sentence? If not, = can you suggest text?

I think = you are correct that the model basically says that already.  My
concern was that since we use the quoted forms "'1' bit" and = "'0' bit",
someone might think that we are using only = binary digits (which are, after
all, a subset of hex = digits) and write out a binary representation rather
than = a hex one.  This is, admittedly, a little farfetched, but since = I
already opened the topic, my attempt at rewording would = be "[...]
represented as a string of utf-encoded hex = digits.  A bit that is set
indicates that the = corresponding Hello was received, and a bit that is
cleared = indicates that the corresponding Hello was not received".

Ok. I have = edited the text and it now reads as:

            =    =E2=80=9C... represented as a string of
  =              utf-8 encoded hex = digits. A bit that is set indicates
      =          that the corresponding Hello was = received, and a bit
            =    that is cleared indicates that the corresponding = Hello
              =  was not received."



=            leaf = exp-mcast-hello-seqno {
=             &n= bsp;type uint16;
=             &n= bsp;default "0";
=             &n= bsp;description
=             &n= bsp;  "Expected multicast Hello sequence number of next = Hello
=             &n= bsp;   to be received from this neighbor; if multicast = Hello
=             &n= bsp;   packets are not expected, or processing of = multicast
=             &n= bsp;   packets is not enabled, this MUST be NULL.";

It's not really clear to me that assigning = semantics to a NULL leaf
makes sense when there is a = default value for it (that has already
assigned semantics = to an absent leaf).
(et seq)

Ok. Will remove the default value.


=            leaf = value {
=             &n= bsp;type binary;
=             &n= bsp;mandatory true;
=             &n= bsp;description
=             &n= bsp;  "The value of the MAC key. An implementation MUST NOT
=             &n= bsp;   allow this parameter to be read. This can be done = by

I believe that we can incorporate this = restriction in the YANG itself
with something like = "nacm:default-deny-all".

Ok. = Will add 'nacm:default-deny-all' and drop the text =E2=80=9CAn = implementation .. subsequently writeable=E2=80=9D.


=             &n= bsp;description
=             &n= bsp;  "The name of the MAC algorithm used with this key. = The
=             &n= bsp;   value MUST be the same as one of the = enumerations
=             &n= bsp;   listed in the mac-algorithms parameter.";

It's now an identityref, not a name. =  Accordingly, there are also not
any enumerations = listed in the mac-algorithms parameter.

How about this?

OLD:

=             &n= bsp;"The name of the MAC algorithm used with this key. The
=             &n= bsp; value MUST be the same as one of the enumerations
= =             &n= bsp; listed in the mac-algorithms parameter.=E2=80=9D;

NEW:

=             &n= bsp;"The MAC algorithm used with this key. The
=             &n= bsp; value MUST be one of the identities
=             &n= bsp; listed with the base of 'mac-algorithms'.=E2=80=9D;


=             &n= bsp;description
=             &n= bsp;  "The name of the certificate type of this object
=             &n= bsp;   instance. The value MUST be the same as one of = the
=             &n= bsp;   enumerations listed in the dtls-cert-types
=             &n= bsp;   parameter. This value can only be provided when = this

Similarly, this is also identityref, = and also has no enumerations listed
in the dtls-cert-types = parameter.

How about this?

OLD:

=             &n= bsp;"The name of the certificate type of this object
=             &n= bsp; instance. The value MUST be the same as one of the
=             &n= bsp; enumerations listed in the dtls-cert-types
=             &n= bsp; parameter.

NEW:

=             &n= bsp;"The certificate type of this object
=             &n= bsp; instance. The value MUST be the same as one of the
=             &n= bsp; identities listed with the base of 'dtls-cert-types'.


=            leaf = private-key {
=             &n= bsp;type binary;
=             &n= bsp;mandatory true;
=             &n= bsp;description
=             &n= bsp;  "The value of the private key. If this is non-empty,
=             &n= bsp;   this certificate can be used by this = implementation to
=             &n= bsp;   provide a certificate during DTLS handshaking. = An
=             &n= bsp;   implementation MUST NOT allow this parameter to = be
=             &n= bsp;   read. This can be done by always providing an = empty

(nacm:default-deny-all could be = useful here as well)

Ok. Will = add it and drop the appropriate text around it.


=             &n= bsp;   string, or through permissions, or other means. = This
=             &n= bsp;   value can only be provided when this instance = is
=             &n= bsp;   created, and is not subsequently writable.";

It is perhaps a bit limiting to require the = actual private key value to
be supplied, since that would = preclude the use of (e.g.) HSM-based
private keys. =  But since we are basically inheriting from the
information model here, I won't press it too hard.

Section 4

It = might be worth referencing the security considerations of
8966/8967/8968 as being applicable.

I understand that the Babel = protocol itself is a insecure protocol. But I am not clear on how that = is applicable to the YANG model that is used to configure or read the = *state* of the protocol (over a secure interface). How about we add = this? Thanks to Barbara for providing the text.

"The security considerations outlined here are specific to = the YANG data model, and do not cover security considerations of the = Babel protocol or its security mechanisms [RFC8966][RFC8967][RFC8968]. = Each of these have their own Security Considerations section for = considerations that are specific to it."

That looks wonderful; thank you!


The security (privacy, really) considerations = of RFC 7924 are also
arguably relevant, relating to the = use of the TLS "cached_info"
extension.

Isn=E2=80=99t this something that = is relevant to RFC8968? The YANG model is merely allowing for the = configuration of the capability specified in RFC8968. Shouldn=E2=80=99t = any security considerations for =E2=80=9Ccached_info=E2=80=9D therefore = be mentioned there?

okay. =  My "arguably" was intended to imply "and also arguably not"


Are there any security and/or = privacy considerations relating to the
logging of babel = packets?

We say the following = in the security considerations section.

=   'babel': Access to the information in the various nodes can = disclose
  the network topology. =  Additionally, the routes used by a network
=   device may be used to mount a subsequent attack on traffic = traversing
  the network device.

Hmm, my understanding was that = the routes used by a given device are a
function of the = received packets but that the packets themselves can
contain= more information than just the routes currently used.  If = that's
the case, then enabling a full packet log would = disclose that "more
information", but I don't know offhand = exactly what that information is, I
can't write good text = to use here.

Ok. How about if we add this in the config true section = of the Security Considerations section?

=E2=80=98packet-log-enable=E2=80=99 and = =E2=80=98packet-log=E2=80=99: Enabling the logging of packets and = unintended access to the log files gives an attacker detailed knowledge = of the network, and allow it to launch an attack on the traffic = traversing the network device.




 There are a number of = data nodes defined in the YANG module which are
=  writable/created/deleted (i.e., config true, which is the = default).

I don't think = "writable/created/deleted" is part of the template.

Thanks to Barbara for digging = this out:

https://datatracker.ietf.org/doc/html/rfc8407.html#section-3.7.= 1 <https://datatracker.ietf.org/doc/html/rfc8407.html#section-3.7.= 1>:

There are a number of data nodes = defined in this YANG module that are
writable/creatable/deletable

My mistake, apologies for that.
I think I = typically use
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines as the
reference, but the phrase in question appears = there as well.


=  'babel/hmac' and 'babel/dtls': These contain security = credentials
 that influence whether packets are = trusted.

I'd consider making two separate = (but related) points about controlling
whether incoming = packets are trusted, and whether outgoing packets are
produced in a way such that the receiver will treat them as = trusted.
(Changing just the use-send/use-verify values can = allow for a valid key
to be misused, without changing the = actual keys being used, which could
present an interesting = attack in some scenarios.)

Ok. = How about this? Thanks again to Barbara for providing the text.

 =E2=80=9CThese contain security = credentials
 that influence whether incoming packets = are trusted, and whether outgoing packets are
=  produced in a way such that the receiver will treat them as = trusted.=E2=80=9D


 Some of the readable data or config = false nodes in this YANG module
 may be considered = sensitive or vulnerable in some network
 [...]
 'babel/hmac' and 'babel/dtls': These contain security = credentials,
 include private credentials of the = router.

We do require the actual secret = keys to not be readable, so we might
consider phrasing = this more as a reiteration of that requirement than a
statement of risk if they are read out.

How about this? Thanks = Barbara.

  'babel/hmac' and = 'babel/dtls': These contain security credentials,
=   including private credentials of the router; however it = is
  required that these values not be = readable.


 Some of the RPC operations in this YANG = module may be considered
 sensitive or vulnerable in = some network environments.  It is thus
=  important to control access to these operations.  These are = the
 operations and their sensitivity/vulnerability = from a RPC operation
 perspective:

 This model does not define any RPC operations.

We do define a couple of actions, though, = which are like RPCs except
"[t]he difference between an = action and an rpc is that an action is tied
to a node in = the datastore, whereas an rpc is not".  This is perhaps an
omission in the YANG security considerations template, but I = don't think
we should let that stop us from noting the = actions we define are
carefully designed to have minimal = security impact and minimal
side-channel leakage. =  (Well, I guess that's not hard for the
stats-reset = one, but for the MAC key test one it's quite important.)

How about this?

OLD:

  This model = does not define any RPC operations.

NEW:

  This model defines two actions, = one of which
  allows for MAC key and MAC = algorithm to be tested.
  It does not allows = for them to be changed.

That's = an improvement, certainly.  I would propose

NEW 2:

 This model defines = two actions.  Resetting the statistics within an
=  interface container would be visible to any monitoring processes, = which
 should be designed to account for the = possibility of such a reset.
 The "test" action = allows for validation that a MAC key and MAC algorithm
=  have been properly configured.  The MAC key is a sensitive = piece of
 information, and it is important to = prevent an attacker that does not know
 the MAC key = from being able to determine the MAC value of an
=  attacker-influenced plaintext.  The "test" action has been = designed to
 not reveal such information directly. =  Such information might also be
 revealed = indirectly, due to side channels such as the time it takes to
 produce a response to the action. =  Implementations SHOULD use a
 constant-time = comparison between the input mac and the locally generated
=  MAC value for comparison, in order to avoid such side channel = leakage.

I am fine with this proposed text.



Section 6.1

I don't have a great sense for why RFC 4868 needs to be = normative.

RFC 4868 is cited = as a reference in the YANG model, which is normative.


RFC 8968 = seems missing as a listed reference at all (which would of
course need to be normative as 8967 is).

Agreed.


Section = 6.2

I think RFC 7693 should be normative, = since you need it in order to do
the blake2 stuff.

Ok. Will move it to normative = section.


RFC 8341 might become normative if we add = nacm:default-deny-all stanzas.

Agreed.


NITS

The tree = diagram and the prose use different orders for the various
child elements, which is a little distracting.

Ok. Will fix the order.


Section 1

 [RFC8966]. =  The data model is defined using YANG 1.1 [RFC7950] data
 modeling language and is Network Management Datastore = Architecture

"the YANG [data modeling = language]"


Section 2.1

 Information Model and this data module.  The = information model
 mandates the definition of some = of the attributes, e.g.  'babel-

comma = after "e.g." (as well as before).  (I'll try to only note it = once,
though it appears many times.)  Likewise for = "i.e."


Section 2.2

=  In addition to information like the version number implemented = by
 this device, the model contains subtrees on = 'constants',

The actual data model (and the = information model, for that matter) show
that the = 'version' leaf contains "the name and version of this
implementation of the Babel protocol".  The text here = suggests that it
contains the protocol version number = implemented by the device, which is
different.  So = I'd suggest "the implementation and version used by this
device" instead.


=  The 'interfaces' subtree describes attributes such as = 'interface'
 object that is being referenced, the = type of link, e.g. wired,

"the = 'interface'"

Ok to the above = suggested changes.


 wireless or tunnel, as enumerated by = 'metric-algorithm' and 'split-
 horizon' and whether = the interface is enabled or not.

I suggest = using semicolons for the outer layer of grouping, to avoid
overloading commas for different hierarchies of = separation.

Something like = this?

OLD:

=   The 'interfaces' subtree describes attributes such as = 'interface'
  object that is being referenced, = the type of link, e.g. wired,
  wireless or = tunnel, as enumerated by 'metric-algorithm' and 'split-
=   horizon' and whether the interface is enabled or not.

NEW:

=   The 'interfaces' subtree describes attributes such as = 'interface'
  object that is being referenced, = the type of link, e.g., wired,
  wireless or = tunnel; as enumerated by 'metric-algorithm' and 'split-
=   horizon=E2=80=99; and whether the interface is enabled or = not.

When I was reading it, my = expectation was something like

NEW 2:

  The 'interfaces' subtree = describes attributes such as the 'interface'
=   object that is being referenced; the type of link, e.g., = wired,
  wireless or tunnel, as enumerated by = 'metric-algorithm' and 'split-
  horizon=E2=80=99= ; and whether the interface is enabled or not.

but I trust your understanding of how the technology works = more than my
understanding!

As I = understand it, the interface can be described as being either =E2=80=98wir= ed', =E2=80=98wireless' or =E2=80=98tunnel'. It can be further described = by setting values of =E2=80=98metric-algorithm=E2=80=99 and = =E2=80=99split-horizon=E2=80=99. Finally, the interface can be enabled = or disabled. So I would suggest one small change to your NEW = 2.

NEW 3:

  The 'interfaces' subtree describes = attributes such as the 'interface'
  object that = is being referenced; the type of link, e.g., wired,
  wireless or tunnel; it is enumerated by = 'metric-algorithm' and 'split-
  horizon=E2=80=99;= and whether the interface is enabled or not.




=  Finally, for security two subtree are defined to contain MAC keys = and
 DTLS certificates.  The 'mac-key-set' = subtree contains keys used with

"subtrees"


 interfaces.  The dtls subtree = contains certificates used with DTLS

single = quotes for 'dtls'.
"the DTLS"

Section = 2.3

 Similarly, an interface that is = a metered 3G link, and used for
 fallback = connectivity needs much higher default time constants, e.g.

Comma after "connectivity".


 HMAC: Keyed-Hashing for Message = Authentication [RFC2104], Using
 HMAC-SHA-256, = HMAC-SHA-384, and HMAC-SHA-512 [RFC4868], Datagram

The "with IPsec" part of RFC 4868's title seems to have been = dropped.

Ok to the above = suggested changes.


=        "This implementation supports = two-out-of-three metric
=         comp algorithm.";

"the two-out-of-three".
Also, do = we really need to (silently) abbreviate "metric computation"
(multiple occurrences)?

Should be:

=E2=80=9Cthe = =E2=80=99two-out-of-three=E2=80=99=E2=80=9D.

Will fix metric comp occurrences.


=        "This implementation supports = Expected Transmission Count

"the = Expected"

Ok.


=        "This implementation supports = hmac-sha256 MAC algorithm.";

"the = hmac-sha256"

=        "This implementation supports = x-509 certificate type.";

"the X.509"

Ok to both.


=        "This implementation supports = raw-public-key certificate
=         type.";

Missing article, per the theme, but I think it would also be = more
conventional to spell the name as "RawPublicKey".

Ok. That was done to be = consistent with the IM.


=      base metric-comp-algorithms;
=      if-feature "etx-supported";
=      description
=        "Expected Transmission = Count.";


I'd put an "algorithm" in here = somewhere


How = about:

=E2=80=9CExpected Transmission Count = (ETX) metric compilation algorithm.=E2=80=9D


=        "BLAKE2s algorithms supported. = Specifically, BLAKE2-128 is
=         supported.";

I'd just say "BLAKE2-128 algorithm = supported."

Then shouldn=E2=80=99= t the feature say

feature = blake2-128-supported?

My = understanding of the nit (if any) here was about "algorithms" (plural) = vs
"algorithm" (singular), since this is a single YANG = identity that can only
have a single semantic.  So, = we could choose to make it be "indicates that
BLAKE2-128 = and BLAKE2-256 are both supported" or just "indicates that
BLAKE2-128 is supported".  Given the second sentence, my = understanding is
that this particular YANG identity = indicates that BLAKE2-128 is supported,
even if the = feature "blake2s-supported" might in the future indicate
whether some other blake2s variant is supported in addition = to this one.
If this YANG identity only indicates that a = single algorithm is supported,
I don't think the plural = "algorithms" adds much value, and once that part
is gone = then the value of the first sentence comes into question as well.

My intent = of naming the feature =E2=80=98blake2-supported=E2=80=99 was to include = *all* BLAKE2 algorithms, even if there is support only for BLAKE2-128. I = can drop the second sentence in the description to just = say:

 "This implementation = supports all blake2s MAC algorithms.=E2=80=9D;




=        "Raw Public Key type.";

"certificate type"


=        leaf router-id {
=          type binary;

(If length constraint is applied earlier, it = should apply here as well.)

=            "Indicat= es whether statistics collection is enabled (true)
=             or= disabled (false) on all interfaces. When enabled,
=             ex= isting statistics values are not cleared and will be
=             in= cremented as new packets are counted.";

I = suggest "on transition to enabled".
(Also, thank you for = clearly spelling out which behaviors true/false map
to!)


=             &n= bsp; A value of true indicates split horizon optimization
=             &n= bsp; is used.";
"the split"

=             &n= bsp;"List of references to the mac entries that apply
=             &n= bsp; to this interface. When an interface instance is
=             &n= bsp; created, all mac instances with default-apply 'true'

s/mac/MAC/ (twice)

= =             &n= bsp;"Indicates whether the cached_info extension is included
=             &n= bsp; in ClientHello and ServerHello packets. The extension

s/packets/messages/.

Ok to the above suggested = changes.

Also, it's conventional to refer to TLS extension names = enclosed by
double quotes, but I guess in the context of a = YANG leaf description
that's not really feasible.

Correct.


=             &n= bsp; dtls-cert-types. This list is used to populate the
=             &n= bsp; server_certificate_type extension in a Client Hello.

s/Client Hello/ClientHello/.

       list mac-key-set = {
=          key "name";

=          description
=            "A mac = key set object. If this object is implemented, it
=             pr= ovides access to parameters related to the MAC security
=             me= chanism.";

s/mac/MAC/

=             &n= bsp;"A string that uniquely identifies the mac object.";
s/mac/MAC key/

=             &n= bsp; If 'true', this instance is applied to new babel-
= =             &n= bsp; interfaces instances at the time they are created,
=             &n= bsp; by including it in the mac-key-sets list under
=             &n= bsp; interfaces. If 'false', this instance is not applied

s/under interfaces/under the interface/

=             &n= bsp; to new interfaces instances when they are created.";

s/interfaces/interface/

=             &n= bsp; If 'true', this instance is applied to new interfaces
=             &n= bsp; instances at the time they are created, by including it
=             &n= bsp; in the dtls-certs list under interfaces. If 'false',

s/under interfaces/under the interface/

=             &n= bsp; this instance is not applied to new interfaces
=             &n= bsp; instances when they are created.";

s/interfaces/interface/

Ok to make the above suggested changes.

Thanks again for a detailed review!

And thank you for the detailed = responses and updates; as I noted in the
preface, the ones = I did not reply to all look good!

My = apologies once more for the slow response time,

Ben




= --Apple-Mail=_EE623D5B-92DF-4AAC-AFB9-09FC7A8249DA-- From nobody Thu Aug 5 17:07:34 2021 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 23A833A1278 for ; Thu, 5 Aug 2021 17:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 K0v0XSGHXC73 for ; Thu, 5 Aug 2021 17:07:27 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 9A7043A1275 for ; Thu, 5 Aug 2021 17:07:27 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id mt6so12975822pjb.1 for ; Thu, 05 Aug 2021 17:07:27 -0700 (PDT) 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=BVyUPBKjkN7hdoOE1L2kSM3ZVd9jzwpDAp4ewGRCAEw=; b=VLUeuplk+a1ksfx9p/tFtbxylnvzY/Eyw9jLdD8zRxqtzGIeSIFkeGUGaTLtGoiWR2 wmT+AMlP1GWWVg2R07SgDs4bIe6SR6ohcfNZ9WdjqUda0LSgtBjgCaeSX2l4mo9S/5KT F4YwcjiOmIeuF/9RU6+Lf7q6WVlZN0zFnAIWucowjj6eORkYx/dQVqBR25H3UiaQfDNo wWEAEwvWBkUKTEMRn30/PvanltzylZrUOo9dyklZMFeoIoCSzuUX1aSy2PE7IcjRclYp jytCCQP29IDhpc25WrFe2hR+YxFgvbkrdHo5FP/OFGmXiuBoPYQiiL8S3Y5gZIFWJvtQ IFGw== 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=BVyUPBKjkN7hdoOE1L2kSM3ZVd9jzwpDAp4ewGRCAEw=; b=qL2q8wi0mmR8HdF2NbWlU0Cfgzr7m6eV9ijHw27oxcsdBHRO/pv06lw69ORzxJach3 y7z6FahfSkK9alLZoTtG/zFTFMjH3GTylyAnvijt5XVr7LgIq1rd7CqdNwUCTtpJ/3vN I9HUry8mxLrKTeh6bOBjyH54b7IHUyzHJtugPbBZxUPihBXk9VtBc8df2Czs7zS/sR7P ZyuSQQKJ2S+W95TCn6RLqiVTSxOc+0M4osuseLjjRub3+vU+hXv7vdCYzWIWxjF1mKBx HRW7rcND+T/ICLxd6zr1fH8JYdDPblOEsDPjUhBBVMq7LpQGOe+IE7LF9BJ0b4njx5i7 EU4A== X-Gm-Message-State: AOAM532FeuDmgt4xKfBaUBe94Sk9uyqqg8q/gSEyjU+GfPEgzG2bmR2l DWwa0CR1i1Lr2i97zo2/AaZVugA54zA= X-Google-Smtp-Source: ABdhPJywda8CCPVXSdyDxo5UMvXcGzJyNRLdpED4sepCNFyVCQb9q5DO7UVWto92mJBe8Ysvboa43g== X-Received: by 2002:a17:90a:8b95:: with SMTP id z21mr17282506pjn.131.1628208445417; Thu, 05 Aug 2021 17:07:25 -0700 (PDT) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id b190sm4788682pgc.91.2021.08.05.17.07.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Aug 2021 17:07:24 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5AFE99CC-440C-485F-9120-A526835343FE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Thu, 5 Aug 2021 17:07:23 -0700 In-Reply-To: Cc: "STARK, BARBARA H" To: "babel@ietf.org" References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [babel] Babel DTLS and YANG 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, 06 Aug 2021 00:07:32 -0000 --Apple-Mail=_5AFE99CC-440C-485F-9120-A526835343FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Babel WG, We, the authors, have not heard from the WG on this thread, so here are = a list of suggested changes we are proposing to address the comments = received as part of IESG review. Since the changes are substantial, we = need to make sure that the WG is ok with these changes. The first is address the question Barbara raises below. We would like to = introduce a new leaf called =E2=80=98algorithm=E2=80=99 which is a = identity reference to one of the =E2=80=98private-key-formats=E2=80=99 = defined in ietf-crypto-types module, that will identify the type of = algorithm used to encode the private key. That module identifies three = algorithms, RSA, EC, and One Asymmetric. The change will look something = like this: + + leaf algorithm { + nacm:default-deny-write; + type identityref { + base ct:private-key-format; + } + mandatory true; + description + "Identifies the algorithm identity with which the + private-key has been encoded. This value can only be + provided when this instance is created, and is not + subsequently writable."; + } The second, and this is where the bad news comes in, is that the = ietf-crypto-types module is part of draft-ietf-netconf-crypto-types. = Yes, it is a draft, though in LC, so most likely this draft will end up = in MISSREF queue. The third, and this was my an oversight on my part, are lines which I = have introduced new as part of the model to protect any data that we do = not want either read or subsequently written; or read at all. In = particular, the private key within a cert are now protected by something = called =E2=80=98default-deny-all=E2=80=99, which per RFC 8341 defines it = as: "Used to indicate that the data model node controls a very sensitive security system parameter. If present, the NETCONF server will only allow the designated 'recovery session' to have read, write, or execute access to the node. An explicit access control rule is required for all other users. Similarly, nodes that were identified as =E2=80=9CThis value can only be = provided when this instance is created, and is not subsequently = writeable=E2=80=9D in the Babel Information Model, are now protected by = the flag =E2=80=98default-deny-write=E2=80=99 from RFC 8341, which = describes the flag as: "Used to indicate that the data model node represents a sensitive security system parameter. If present, the NETCONF server will only allow the designated 'recovery session' to have write access to the node. An explicit access control rule is required for all other users. If you have objections to these changes, please raise it now. Otherwise, = silence will be considered consensus =F0=9F=A4=90. Donald, would you say = a week is plenty of time to raise any objection? Cheers. > On Aug 3, 2021, at 8:11 AM, STARK, BARBARA H wrote: >=20 > Hi Babelers, > We're getting some comments on the YANG model that we need a little = help with. > Specifically, we need help with the modeling of the DTLS private key. > For DTLS, we've included data model support for X.509 certificates and = Raw Public Key. > The certificate type (X.509 or Raw Public Key) is specified for every = certificate. > Both have distinct public and private keys. > Public keys are provided via the data model in PEM format. > The public key PEM file includes info about the cipher suite that was = used to create the pair (RSA, Elliptic Curve, etc.) and therefore needs = to be negotiated in DTLS handshaking.=20 >=20 > But for the private key, we had come to a consensus that the Babel = implementation just wanted the binary private key value.=20 >=20 > If the private key were expressed in PKCS#8 (generic key format) PEM, = we would have: > -----BEGIN PRIVATE KEY----- > BASE64 ENCODED DATA > -----END PRIVATE KEY----- >=20 > Within the base64 encoded data the following DER structure is present: > ------------------------------------- > PrivateKeyInfo ::=3D SEQUENCE { > version Version, > algorithm AlgorithmIdentifier, > PrivateKey OCTET STRING > } >=20 > AlgorithmIdentifier ::=3D SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL > } > --------------------------------------- >=20 > AlgorthmIdentifier identifies the cipher suite. > But it sounds like the binary private key value Babel is providing is = just the "PrivateKey" part of this.=20 > Is that correct? If so, doesn't the implementation need to know the = "AlgorithmIdentifier"? Or (since we supply the public key with the = private key) can or does the Babel implementation pick this up from the = associated public key? >=20 > Thx, > Barbara >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_5AFE99CC-440C-485F-9120-A526835343FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Babel WG,

We, the = authors, have not heard from the WG on this thread, so here are a list = of suggested changes we are proposing to address the comments received = as part of IESG review. Since the changes are substantial, we need to = make sure that the WG is ok with these changes.

The first is address the question = Barbara raises below. We would like to introduce a new leaf called = =E2=80=98algorithm=E2=80=99 which is a identity reference to one of the = =E2=80=98private-key-formats=E2=80=99 defined in ietf-crypto-types = module, that will identify the type of algorithm used to encode the = private key. That module identifies three algorithms, RSA, EC, and One = Asymmetric. The change will look something like this:

+
+          leaf = algorithm {
+          =   nacm:default-deny-write;
+  =           type identityref {
+              base = ct:private-key-format;
+  =           }
+  =           mandatory true;
+            = description
+          =     "Identifies the algorithm identity with which = the
+           =     private-key has been encoded. This value can only = be
+           =     provided when this instance is created, and is = not
+           =     subsequently writable.";
+  =         }

The second, and this is where the bad news = comes in, is that the ietf-crypto-types module is part = of draft-ietf-netconf-crypto-types. Yes, it is a draft, though in = LC, so most likely this draft will end up in MISSREF = queue.

The third, and this was my an = oversight on my part, are lines which I have introduced new as part of = the model to protect any data that we do not want either read or = subsequently written; or read at all. In particular, the private key = within a cert are now protected by something called = =E2=80=98default-deny-all=E2=80=99, which per RFC 8341 defines it = as:

         "Used to indicate that =
the data model node
          controls a very sensitive security system parameter.

          If present, the NETCONF server will only allow the designated
          'recovery session' to have read, write, or execute access to
          the node.  An explicit access control rule is required for all
          other users.

Similarly, = nodes that were identified as =E2=80=9CThis value can only be provided = when this instance is created, and is not subsequently writeable=E2=80=9D = in the Babel Information Model, are now protected by the flag = =E2=80=98default-deny-write=E2=80=99 from RFC 8341, which describes the = flag as:

         =
"Used to indicate that the data model node
          represents a sensitive security system parameter.

          If present, the NETCONF server will only allow the designated
          'recovery session' to have write access to the node.  An
          explicit access control rule is required for all other =
users.

If you = have objections to these changes, please raise it now. Otherwise, = silence will be considered consensus =F0=9F=A4=90. Donald, would you say = a week is plenty of time to raise any objection?

Cheers.

On Aug 3, 2021, at 8:11 AM, = STARK, BARBARA H <bs7652@att.com> wrote:

Hi = Babelers,
We're getting some comments on the YANG model = that we need a little help with.
Specifically, we need = help with the modeling of the DTLS private key.
For DTLS, = we've included data model support for X.509 certificates and Raw Public = Key.
The certificate type (X.509 or Raw Public Key) is = specified for every certificate.
Both have distinct public = and private keys.
Public keys are provided via the data = model in PEM format.
The public key PEM file includes info = about the cipher suite that was used to create the pair (RSA, Elliptic = Curve, etc.) and therefore needs to be negotiated in DTLS handshaking. =

But for the private key, we had come to a = consensus that the Babel implementation just wanted the binary private = key value.

If the private key were = expressed in PKCS#8 (generic key format) PEM, we would have:
-----BEGIN PRIVATE KEY-----
BASE64 ENCODED = DATA
-----END PRIVATE KEY-----

Within the base64 encoded data the following DER structure is = present:
-------------------------------------
PrivateKeyInfo ::=3D SEQUENCE {
 version =         Version,
=  algorithm =       AlgorithmIdentifier,
=  PrivateKey      OCTET STRING
}

AlgorithmIdentifier ::=3D = SEQUENCE {
 algorithm =       OBJECT IDENTIFIER,
=  parameters      ANY DEFINED BY algorithm = OPTIONAL
}
---------------------------------------

AlgorthmIdentifier identifies the cipher suite.
But it sounds like the binary private key value Babel is = providing is just the "PrivateKey" part of this.
Is that = correct? If so, doesn't the implementation need to know the = "AlgorithmIdentifier"? Or (since we supply the public key with the = private key) can or does the Babel implementation pick this up from the = associated public key?

Thx,
Barbara

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_5AFE99CC-440C-485F-9120-A526835343FE-- From nobody Sun Aug 8 21:36:07 2021 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 9FF4F3A26E4 for ; Sun, 8 Aug 2021 21:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=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 EK0jWkip8XQG for ; Sun, 8 Aug 2021 21:36:01 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4A4563A26E5 for ; Sun, 8 Aug 2021 21:36:01 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id l20so23633303iom.4 for ; Sun, 08 Aug 2021 21:36:01 -0700 (PDT) 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=ny99i3HApF7ZsJbX2uADLt2B7BceGHGODoRiTCusw6A=; b=c88yg6YMOlMAFTme2snsrjYu0KNZyTodLq/Ma8fcQu+1elpR2+SxvbXeVh0KwZlyK/ P7pyAkRe60E6QrgogEo2oUtlNorTORgW54n2Z9vOZDUTlB3E3E1O7iix7LLSZNTLdHhv FXSHNhtHeAxf18IlWAZKXHeYr+1Dtq4u7VlISh3l/M5EX4stvuviLtSOVwhTHPeOZ5ko x75L3eSIL3tCcrKIhoC4WWoyIvbwWJ7hZgJwwJwtSwb24ClYzFp54DlHV1SYGHO+Z9ul bqexDpc5Xtv11YEf12w3Gh+5zf5KO2D7uYaWmfurBBitme+cARzqi3+Xx8OYNdqROLOO yTkA== 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=ny99i3HApF7ZsJbX2uADLt2B7BceGHGODoRiTCusw6A=; b=OdAkI4IwvYgXQMrNXc/3P2Ky8No8HuMwafBz7CD8YlfjypYyzCCnE9up4f9NhO7d+C ls6EqrblXxlewq+TLwCHKyUpWZaVTImz0MtwLutHHj/G2toaHNTBATnal70r7hKktRDu oRwhthcvkI5PO8J33/Br/TBrmpdkTIrYb2hERbvKWMxWtFePAwgegYGwkHqAtMAli4DW 0FPfc9s5trWWdkmao2yvu2BAOz+wGfbgrWrK7hcR8+Q6pzFWMBDrqmOnlImdvITOnzkd xG1akzZBuRSDE9t8j3Qpj340poaEWEKh1rznnXqsOd0hldHTnjVJrTkMaB9bSdT5DmO3 Ur4A== X-Gm-Message-State: AOAM532x/9cd6RlaLBE9tkyPFgOklZ+Q+EE7C5Ft06vEEsSzHUiEvTfo fy/EMxTbcHRQdqqwuDDfYgCiXJCVRkOM9zjBL4s= X-Google-Smtp-Source: ABdhPJx6sRlAS18I8cWElyKSLtI7RYe7Yuh2egnTZT/2l1Oiq1Xw3Ktyo6OpesTlmQJ5KMEeLd3XEDik4yYTJ/z4tz0= X-Received: by 2002:a5e:830b:: with SMTP id x11mr100368iom.185.1628483759628; Sun, 08 Aug 2021 21:35:59 -0700 (PDT) MIME-Version: 1.0 References: <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com> In-Reply-To: <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com> From: Donald Eastlake Date: Mon, 9 Aug 2021 00:35:48 -0400 Message-ID: To: Mahesh Jethanandani Cc: "babel@ietf.org" , "STARK, BARBARA H" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel DTLS and YANG 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, 09 Aug 2021 04:36:06 -0000 Hi Mahesh, I would agree that a week is a reasonable length of time for people to complain if they object to these changes. 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 Thu, Aug 5, 2021 at 8:07 PM Mahesh Jethanandani wrote: > > Hi Babel WG, > > We, the authors, have not heard from the WG on this thread, so here are a= list of suggested changes we are proposing to address the comments receive= d as part of IESG review. Since the changes are substantial, we need to mak= e sure that the WG is ok with these changes. > > The first is address the question Barbara raises below. We would like to = introduce a new leaf called =E2=80=98algorithm=E2=80=99 which is a identity= reference to one of the =E2=80=98private-key-formats=E2=80=99 defined in i= etf-crypto-types module, that will identify the type of algorithm used to e= ncode the private key. That module identifies three algorithms, RSA, EC, an= d One Asymmetric. The change will look something like this: > > + > + leaf algorithm { > + nacm:default-deny-write; > + type identityref { > + base ct:private-key-format; > + } > + mandatory true; > + description > + "Identifies the algorithm identity with which the > + private-key has been encoded. This value can only be > + provided when this instance is created, and is not > + subsequently writable."; > + } > > The second, and this is where the bad news comes in, is that the ietf-cry= pto-types module is part of draft-ietf-netconf-crypto-types. Yes, it is a d= raft, though in LC, so most likely this draft will end up in MISSREF queue. > > The third, and this was my an oversight on my part, are lines which I hav= e introduced new as part of the model to protect any data that we do not wa= nt either read or subsequently written; or read at all. In particular, the = private key within a cert are now protected by something called =E2=80=98de= fault-deny-all=E2=80=99, which per RFC 8341 defines it as: > > "Used to indicate that the data model node > controls a very sensitive security system parameter. > > If present, the NETCONF server will only allow the designated > 'recovery session' to have read, write, or execute access to > the node. An explicit access control rule is required for all > other users. > > > Similarly, nodes that were identified as =E2=80=9CThis value can only be = provided when this instance is created, and is not subsequently writeable= =E2=80=9D in the Babel Information Model, are now protected by the flag =E2= =80=98default-deny-write=E2=80=99 from RFC 8341, which describes the flag a= s: > > "Used to indicate that the data model node > represents a sensitive security system parameter. > > If present, the NETCONF server will only allow the designated > 'recovery session' to have write access to the node. An > explicit access control rule is required for all other users. > > > If you have objections to these changes, please raise it now. Otherwise, = silence will be considered consensus =F0=9F=A4=90. Donald, would you say a = week is plenty of time to raise any objection? > > Cheers. > > On Aug 3, 2021, at 8:11 AM, STARK, BARBARA H wrote: > > Hi Babelers, > We're getting some comments on the YANG model that we need a little help = with. > Specifically, we need help with the modeling of the DTLS private key. > For DTLS, we've included data model support for X.509 certificates and Ra= w Public Key. > The certificate type (X.509 or Raw Public Key) is specified for every cer= tificate. > Both have distinct public and private keys. > Public keys are provided via the data model in PEM format. > The public key PEM file includes info about the cipher suite that was use= d to create the pair (RSA, Elliptic Curve, etc.) and therefore needs to be = negotiated in DTLS handshaking. > > But for the private key, we had come to a consensus that the Babel implem= entation just wanted the binary private key value. > > If the private key were expressed in PKCS#8 (generic key format) PEM, we = would have: > -----BEGIN PRIVATE KEY----- > BASE64 ENCODED DATA > -----END PRIVATE KEY----- > > Within the base64 encoded data the following DER structure is present: > ------------------------------------- > PrivateKeyInfo ::=3D SEQUENCE { > version Version, > algorithm AlgorithmIdentifier, > PrivateKey OCTET STRING > } > > AlgorithmIdentifier ::=3D SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL > } > --------------------------------------- > > AlgorthmIdentifier identifies the cipher suite. > But it sounds like the binary private key value Babel is providing is jus= t the "PrivateKey" part of this. > Is that correct? If so, doesn't the implementation need to know the "Algo= rithmIdentifier"? Or (since we supply the public key with the private key) = can or does the Babel implementation pick this up from the associated publi= c key? > > Thx, > 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 From nobody Fri Aug 13 11:21:02 2021 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 21D783A2186 for ; Fri, 13 Aug 2021 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=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 dzwoiWLBD0q5 for ; Fri, 13 Aug 2021 11:20:55 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 ED4513A2187 for ; Fri, 13 Aug 2021 11:20:54 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id y1so14457214iod.10 for ; Fri, 13 Aug 2021 11:20:54 -0700 (PDT) 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=PXlm3BCbAVhly/Hqo3Dzov0ahyM+03T2Ep1rCrr+2WI=; b=AHs9Pap2ZddaBkJnrQh5dOP3C/qNcVclHn6HqP/1xO/wEmwkUEB9XtnYUou/rkuanH WO2vnaZSEVsVzx34PH/V7FN9LXQZD54OxzXzhFws1T3AMQ54+zbAjEf2VBFn+PczUtmS 5rDKeduBk3zQGju7jChAhDDyTvWV+Lm/LE1AuhINmTvgx5RJo3MmNPLPtW4fdHdbLFPm cT763HzMD3KR5KHYS3/sZ5+gQsJpkORMPru0DTxeDsoug4ycFJlM066FZigdgivqgK9J vMybyEFGE/Ku81OawrxFJTlsg16DPW4p2u5NLDQcgxOmenAEILDgY/7tubHyzUtV5ro0 +q1Q== 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=PXlm3BCbAVhly/Hqo3Dzov0ahyM+03T2Ep1rCrr+2WI=; b=WrBn/ypqKTis9rYXwXcCSpMPgMh9IMySfPqxoTmJ/Wzfw+q5yQvfOf/cQdEMGFuNBO BHx6Ncf1pGySwq6N8xkM+yGNTu38S5LC6LDgC82ftph56t2MqdTT74cHQxSxKMYB0o9s +5FyBF/+1JooKBxZb2GuNK5HQISvGkmv53NeFozDJLht3x4ggtAIAeIpOintSeF8bQe9 BtZ5vGfWrkfVFQmiOssRwoiUj89dbx3MDI7SDdPrQBsNSGx4WbN5qICXRhKlFjJeq/zO WCeiqGTzzdvAnkwZ5iB/fGZUtKy7IYWy1YDW4i3Epf2kSK4X0flMX4atEBMm8AVMRxzA /4DA== X-Gm-Message-State: AOAM530OZ0PZzVlIKZLrdHSxUVCxQhrdMv9U0uFWuMTZyczILvSynvfG M0jmBoFu9KCMVevzW8XLvvGFtai7WzOh12VpYUw= X-Google-Smtp-Source: ABdhPJwV4bHTe7c1IWYP7dJ6IYrin2AnK7mxrMvE/JlttAial6eKbtYFhS1QM9dtJYdUhs1jEIaMI8q77JinR51gQlw= X-Received: by 2002:a5d:8986:: with SMTP id m6mr2910167iol.87.1628878853338; Fri, 13 Aug 2021 11:20:53 -0700 (PDT) MIME-Version: 1.0 References: <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com> In-Reply-To: <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com> From: Donald Eastlake Date: Fri, 13 Aug 2021 14:20:42 -0400 Message-ID: To: Mahesh Jethanandani Cc: "babel@ietf.org" , "STARK, BARBARA H" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel DTLS and YANG 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, 13 Aug 2021 18:21:00 -0000 Hi Mahesh, Since no one has objected, you can go ahead with the changes. 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 Thu, Aug 5, 2021 at 8:07 PM Mahesh Jethanandani wrote: > > Hi Babel WG, > > We, the authors, have not heard from the WG on this thread, so here are a= list of suggested changes we are proposing to address the comments receive= d as part of IESG review. Since the changes are substantial, we need to mak= e sure that the WG is ok with these changes. > > The first is address the question Barbara raises below. We would like to = introduce a new leaf called =E2=80=98algorithm=E2=80=99 which is a identity= reference to one of the =E2=80=98private-key-formats=E2=80=99 defined in i= etf-crypto-types module, that will identify the type of algorithm used to e= ncode the private key. That module identifies three algorithms, RSA, EC, an= d One Asymmetric. The change will look something like this: > > + > + leaf algorithm { > + nacm:default-deny-write; > + type identityref { > + base ct:private-key-format; > + } > + mandatory true; > + description > + "Identifies the algorithm identity with which the > + private-key has been encoded. This value can only be > + provided when this instance is created, and is not > + subsequently writable."; > + } > > The second, and this is where the bad news comes in, is that the ietf-cry= pto-types module is part of draft-ietf-netconf-crypto-types. Yes, it is a d= raft, though in LC, so most likely this draft will end up in MISSREF queue. > > The third, and this was my an oversight on my part, are lines which I hav= e introduced new as part of the model to protect any data that we do not wa= nt either read or subsequently written; or read at all. In particular, the = private key within a cert are now protected by something called =E2=80=98de= fault-deny-all=E2=80=99, which per RFC 8341 defines it as: > > "Used to indicate that the data model node > controls a very sensitive security system parameter. > > If present, the NETCONF server will only allow the designated > 'recovery session' to have read, write, or execute access to > the node. An explicit access control rule is required for all > other users. > > > Similarly, nodes that were identified as =E2=80=9CThis value can only be = provided when this instance is created, and is not subsequently writeable= =E2=80=9D in the Babel Information Model, are now protected by the flag =E2= =80=98default-deny-write=E2=80=99 from RFC 8341, which describes the flag a= s: > > "Used to indicate that the data model node > represents a sensitive security system parameter. > > If present, the NETCONF server will only allow the designated > 'recovery session' to have write access to the node. An > explicit access control rule is required for all other users. > > > If you have objections to these changes, please raise it now. Otherwise, = silence will be considered consensus =F0=9F=A4=90. Donald, would you say a = week is plenty of time to raise any objection? > > Cheers. > > On Aug 3, 2021, at 8:11 AM, STARK, BARBARA H wrote: > > Hi Babelers, > We're getting some comments on the YANG model that we need a little help = with. > Specifically, we need help with the modeling of the DTLS private key. > For DTLS, we've included data model support for X.509 certificates and Ra= w Public Key. > The certificate type (X.509 or Raw Public Key) is specified for every cer= tificate. > Both have distinct public and private keys. > Public keys are provided via the data model in PEM format. > The public key PEM file includes info about the cipher suite that was use= d to create the pair (RSA, Elliptic Curve, etc.) and therefore needs to be = negotiated in DTLS handshaking. > > But for the private key, we had come to a consensus that the Babel implem= entation just wanted the binary private key value. > > If the private key were expressed in PKCS#8 (generic key format) PEM, we = would have: > -----BEGIN PRIVATE KEY----- > BASE64 ENCODED DATA > -----END PRIVATE KEY----- > > Within the base64 encoded data the following DER structure is present: > ------------------------------------- > PrivateKeyInfo ::=3D SEQUENCE { > version Version, > algorithm AlgorithmIdentifier, > PrivateKey OCTET STRING > } > > AlgorithmIdentifier ::=3D SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL > } > --------------------------------------- > > AlgorthmIdentifier identifies the cipher suite. > But it sounds like the binary private key value Babel is providing is jus= t the "PrivateKey" part of this. > Is that correct? If so, doesn't the implementation need to know the "Algo= rithmIdentifier"? Or (since we supply the public key with the private key) = can or does the Babel implementation pick this up from the associated publi= c key? > > Thx, > 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 From nobody Fri Aug 13 16:08:05 2021 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 CED913A29E7; Fri, 13 Aug 2021 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QaAOwZ1G_Ig9; Fri, 13 Aug 2021 16:08:00 -0700 (PDT) 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 CC9AC3A29E6; Fri, 13 Aug 2021 16:07:59 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id bo18so17651872pjb.0; Fri, 13 Aug 2021 16:07:59 -0700 (PDT) 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=fGDFuJDQS3GDtFbBQuEKOG2UJ0n+0LKgZc77LRXA0qI=; b=f+jE19h0tw4sOV2gwdnvJX39DznBpAOCEGesH8c4eN4t2OhVuAHP5BfgZmwBWxxTCj g4LhxUHeCKGJYzIqLjXOgB7aixoXEnHPdS4fAQIBn8dzylJobg/BOG5o1Rwg9MwurnDk ft+kuHFwUdwjDxvayYMMNnSvupvzgvrrze3TX+EV/60tfbmmTuh9D7+ni/rgsa30i4E0 xIpJ9J+M7zDBvUqugMrS+FmsMv1B4GGNST7gIYvn+psPUq/22UFzxtI05SsHkrnE/lAQ rNMzFELg6pAKVmQHG3CNkwra/a3WXbYvmb259xAtoJtBJIpgtAgptHkTrJTNE8apnDeM EaQw== 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=fGDFuJDQS3GDtFbBQuEKOG2UJ0n+0LKgZc77LRXA0qI=; b=szL5AfQH5kGqTW8Q73rftDlSoJQjZO/wIiYUWvJaekWTimemxVOwIWpfeB7PlWL2ei sYREC3X70t1I/ZMLKuJq5CeTyunYSqjmY02Ux5WYRW+J6dmicXjPzz31a3pWehNavMcc qD/4Y92icKRCmGE7rI6XwiD4Sdk1ES7XamlQCj/0O4nvW4SX/d81lYr+3c9vZKNcZyBR TC2xiLi7VaCSTI1Gje97pQjABxZ3NTKnYu/3tRbTHa3TS2502xTo4wGNlDAjP9GPLZGD n8GjH/0KCss47pyPrJqkTPUrdVMDA/PS0KWFpc7EU7XwoZW4efYeiptZHPJ5QwpOGCHV sI9Q== X-Gm-Message-State: AOAM531Qf3YPlNo+VKmKUtWJNMAe7n/5JC3q2bnzgaFPX2aTWYgOZdtv XFHyOVGN1thQ1jOPZVQxFiM= X-Google-Smtp-Source: ABdhPJwGi0EpPtBkC9Bal3X9iO3nnJuVs51Hmk9ZHZpdsT7mDAU28m8szB9+bdL+A+vNGJon53lqug== X-Received: by 2002:a17:902:a988:b029:12c:4609:f182 with SMTP id bh8-20020a170902a988b029012c4609f182mr3769425plb.14.1628896077980; Fri, 13 Aug 2021 16:07:57 -0700 (PDT) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id y23sm3630611pfb.130.2021.08.13.16.07.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Aug 2021 16:07:57 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <64B3C6BC-8637-48E8-822D-487CF8A12EAB@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FC532DA2-FDB9-4B8D-BD61-B8AE53741D6A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 13 Aug 2021 16:07:54 -0700 In-Reply-To: <6CDF1D68-7F33-4598-BA75-D6D824A04F1F@gmail.com> Cc: The IESG , draft-ietf-babel-yang-model@ietf.org, babel-chairs , Babel at IETF , Donald Eastlake To: Benjamin Kaduk References: <162148379451.10850.9563671396439074857@ietfa.amsl.com> <99514803-6C88-40F8-B924-315945B052C1@gmail.com> <20210720235506.GX88594@kduck.mit.edu> <6CDF1D68-7F33-4598-BA75-D6D824A04F1F@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT) 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, 13 Aug 2021 23:08:03 -0000 --Apple-Mail=_FC532DA2-FDB9-4B8D-BD61-B8AE53741D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, There was one AI on my plate to get back to you on. See below. In addition, I had sent my responses to the remaining comments. Let me = know if you are good with them. > On Aug 4, 2021, at 11:34 AM, Mahesh Jethanandani = wrote: >=20 >>>=20 >>>=20 >>>>=20 >>>> There's also a few places where we didn't quite clean up all the = fallout >>>> from switching from enumerations to identities (for MAC and >>>> DTLS-adjacent algorithms), that really ought to get fixed before >>>> publication. I try to note them in the COMMENT. >>>>=20 >>>> I also think we need to be a bit more specific about the structure = of >>>> the (binary) private-key leaf/values provided when a certificate = entry >>>> is created. Ideally this would just be by reference to some other = spec, >>>> but the situation is unfortunately messy. (It doesn't help that we >>>> allow DTLS 1.2, which allows certificates that are used for = key-exchange >>>> as opposed to signing, and those are not terribly mainstream.) We = may >>>> need to pull in some other experts to figure out the right way to = write >>>> about this. >>>=20 >>> Ok. The way I am reading this is that we need to wait to hear more = from the experts that you cite before making any changes. >>>=20 >>> Note, in WG discussion the ask was for the format of the private-key = to be binary. I am not an expert, but would it help if the description = said something about using PEM format for the private-key? >>=20 >> I think binary is probably fine; a PEM encoding is just base64 = encoding and >> sometimes a little bit of a hint as to what the contained structure = is. >> But my recollection is that the PEM type indication for certificate = private >> keys is not always precise enough to indicate what is to be used, so = an >> implementation would need to consult the "type" sibling leaf anyway = in >> order to process the "private-key"...but it's not entirely clear that = just >> "type" is enough information on its own. >>=20 >> It is possible that we can find the necessary references without = pulling in >> an external expert, but if we get stuck I would probably ask Russ = Housley >> or Sean Turner for help. >>=20 >> As a starting point, I note that RFC 4211 lists several Private Key >> structures in Section 4.2.2 in ASN.1 syntax. We would presumably = require >> that the binary value exposed by the YANG module be the DER-encoded = version >> of that ASN.1 structure. RFC 5915 has a private-key structure for = ECC >> keys. The complications then come in specifying how the other YANG >> elements determine which (DER-encoded) ASN.1 structure is used for = the >> "private-key" contents. In particular, "dtls-cert-type" indicates = only a >> "certificate type" in the TLS sense -- X.509, raw public key, and the = like. >> Both X.509 certificates and raw public keys can use keys from = different >> cryptosystems or cryptographic algorithms. So I find it pretty >> inescapable that we'll need some in-band signaling about whether the >> private-key is a basic RSA key, or perhaps an RSA-PSS key that has = some >> specific associated parameters, vs a DH or DSA key, or ECDH, ECDSA, = EdDSA, >> etc. With in-band signaling comes the need for a table or = enumeration of >> what the different (currently supported) key structures are. It = seems that >> draft-ietf-netconf-crypto-types may have a start at private-key = structures >> of this sort, though I have not been following that work closely (it = seems >> to be in WGLC at the moment). >>=20 >=20 > We will need to go back to the WG to discuss this. Let us get back to = you on this. >=20 This is what I proposed to the WG to resolve this issue, and did not = receive any objection. Let me know if you are ok with it. We would like to introduce a new leaf called =E2=80=98algorithm=E2=80=99 = which is a identity reference to one of the =E2=80=98private-key-formats=E2= =80=99 defined in ietf-crypto-types module, that will identify the type = of algorithm used to encode the private key. That module identifies = three algorithms, RSA, EC, and One Asymmetric. The change will look = something like this: + + leaf algorithm { + nacm:default-deny-write; + type identityref { + base ct:private-key-format; + } + mandatory true; + description + "Identifies the algorithm identity with which the + private-key has been encoded. This value can only be + provided when this instance is created, and is not + subsequently writable."; + } The second, and this was my an oversight on my part, are lines which I = have introduced new as part of the model to protect any data that we do = not want either read or subsequently written; or read at all. In = particular, the private key within a cert is now protected by = =E2=80=98default-deny-all=E2=80=99, per RFC 8341. Similarly, nodes that = were identified as =E2=80=9CThis value can only be provided when this = instance is created, and is not subsequently writeable=E2=80=9D in the = Babel Information Model, are now protected by the flag = =E2=80=98default-deny-write=E2=80=99 from RFC 8341. There are four = instances of this flag in the model, including the one in the above = addition.=20 Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_FC532DA2-FDB9-4B8D-BD61-B8AE53741D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben,

There was one = AI on my plate to get back to you on. See below.

In addition, I had sent my responses to = the remaining comments. Let me know if you are good with them.

On Aug 4, 2021, at 11:34 AM, Mahesh = Jethanandani <mjethanandani@gmail.com> wrote:




There's also a few places where = we didn't quite clean up all the fallout
from switching = from enumerations to identities (for MAC and
DTLS-adjacent = algorithms), that really ought to get fixed before
publication.  I try to note them in the COMMENT.

I also think we need to be a bit more specific = about the structure of
the (binary) private-key = leaf/values provided when a certificate entry
is created. =  Ideally this would just be by reference to some other spec,
but the situation is unfortunately messy.  (It doesn't = help that we
allow DTLS 1.2, which allows certificates = that are used for key-exchange
as opposed to signing, and = those are not terribly mainstream.)  We may
need to = pull in some other experts to figure out the right way to write
about this.

Ok. The = way I am reading this is that we need to wait to hear more from the = experts that you cite before making any changes.

Note, in WG discussion the ask was for the format of the = private-key to be binary. I am not an expert, but would it help if the = description said something about using PEM format for the = private-key?

I think binary is = probably fine; a PEM encoding is just base64 encoding and
sometimes a little bit of a hint as to what the contained = structure is.
But my recollection is that the PEM type = indication for certificate private
keys is not always = precise enough to indicate what is to be used, so an
implementation would need to consult the "type" sibling leaf = anyway in
order to process the "private-key"...but it's = not entirely clear that just
"type" is enough information = on its own.

It is possible that we can find = the necessary references without pulling in
an external = expert, but if we get stuck I would probably ask Russ Housley
or Sean Turner for help.

As a = starting point, I note that RFC 4211 lists several Private Key
structures in Section 4.2.2 in ASN.1 syntax.  We would = presumably require
that the binary value exposed by the = YANG module be the DER-encoded version
of that ASN.1 = structure.  RFC 5915 has a private-key structure for ECC
keys.  The complications then come in specifying how the = other YANG
elements determine which (DER-encoded) ASN.1 = structure is used for the
"private-key" contents.  In = particular, "dtls-cert-type" indicates only a
"certificate = type" in the TLS sense -- X.509, raw public key, and the like.
Both X.509 certificates and raw public keys can use keys from = different
cryptosystems or cryptographic algorithms. =  So I find it pretty
inescapable that we'll need some = in-band signaling about whether the
private-key is a basic = RSA key, or perhaps an RSA-PSS key that has some
specific = associated parameters, vs a DH or DSA key, or ECDH, ECDSA, EdDSA,
etc.  With in-band signaling comes the need for a table = or enumeration of
what the different (currently supported) = key structures are.  It seems that
draft-ietf-netconf-crypto-types may have a start at = private-key structures
of this sort, though I have not = been following that work closely (it seems
to be in WGLC = at the moment).


We will need = to go back to the WG to discuss this. Let us get back to you on = this.


This is what I proposed to the WG to resolve this = issue, and did not receive any objection. Let me know if you are ok with = it.

We would like to = introduce a new leaf called =E2=80=98algorithm=E2=80=99 which is a = identity reference to one of the =E2=80=98private-key-formats=E2=80=99 = defined in ietf-crypto-types module, that will identify the type of = algorithm used to encode the private key. That module identifies three = algorithms, RSA, EC, and One Asymmetric. The change will look something = like this:

+
+    =       leaf algorithm {
+            = nacm:default-deny-write;
+    =         type identityref {
+              = base ct:private-key-format;
+    =         }
+    =         mandatory true;
+            = description
+    =           "Identifies the algorithm identity = with which the
+     =           private-key has been encoded. This = value can only be
+     =           provided when this instance is = created, and is not
+     =           subsequently = writable.";
+    =       }

The second, and this was my an = oversight on my part, are lines which I have introduced new as part of = the model to protect any data that we do not want either read or = subsequently written; or read at all. In particular, the private key = within a cert is now protected by =E2=80=98default-deny-all=E2=80=99, = per RFC 8341. Similarly, nodes that were identified as =E2=80=9CThis = value can only be provided when this instance is created, and is not = subsequently writeable=E2=80=9D in the Babel Information Model, are now = protected by the flag =E2=80=98default-deny-write=E2=80=99 from RFC = 8341. There are four instances of this flag in the model, including the = one in the above addition. 

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_FC532DA2-FDB9-4B8D-BD61-B8AE53741D6A-- From nobody Tue Aug 17 12:08:22 2021 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 D76AE3A2BB6; Tue, 17 Aug 2021 12:08:20 -0700 (PDT) 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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <162922730069.8996.13090730301811708198@ietfa.amsl.com> Date: Tue, 17 Aug 2021 12:08:20 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-yang-model-11.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, 17 Aug 2021 19:08:21 -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-11.txt Pages : 43 Date : 2021-08-17 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 17 12:17:12 2021 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 DEBAF3A03FE for ; Tue, 17 Aug 2021 12:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 XUGIsqfMJv2y for ; Tue, 17 Aug 2021 12:17:06 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 0EF753A03EC for ; Tue, 17 Aug 2021 12:17:06 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id j1so705290pjv.3 for ; Tue, 17 Aug 2021 12:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=jYvFbpeIBWgxT09jpff7FYPovDmIAR3vNNWtm/sBjXQ=; b=jcicCemqZDF+UTFJrYWPWmRPtCtbf8XDLW8M8lKbBCyKH8IEvhx93zM9Uesc0yzsax ApTO7k+sQU43d9XKq4t5ZQqtcQKhl/w7jJkw4xHjXUGKScfOixgqnS3iEF2zfkM0hMib ve9x1zyZruLnY6BUiFI3pJn5WhMhF/EnnXKqNhEBZghxuxOTvOhyLQxD9JWit6GTfT+1 24ohKEsPLaZiQAcIhaHsbwF5pDtVKOKbn1WUyrHenH97SldnrKoqJxQKPb4BYY0Q2eGj 4aavUS6hJ0l1ijkfys2NQ71uq2/VQPYwylIVaWH+t9ZdpuYdrQvQPhdtZV4qkIx6kLUd +F9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=jYvFbpeIBWgxT09jpff7FYPovDmIAR3vNNWtm/sBjXQ=; b=pOEibwHbKH0h2wUOZ0EFnBegd2RKNey+rxFdjt7WggtaUlnOmRHWBgmHth0HJsTsUp R9ygo5HocirD+rEBKUZWKxhdr1odzksd1TKT+qrMJ6QxCCqirZF1vNKnRaeaiAEwFv5m mdIh+7NXQzqJIKC0rsaTQ7mJS/9JC+f7ONkuIaytklLGpuD7UfEsaX/OeafN7mEZxCNH o+bpTWSpylYeSr3xE2uou5AhCItL0Kiy1Cd8t9VlY0mf8k0NPMJT+iwUBA/duiF1hZ/c PZe5FIM3uYOPHlVMSU7IBLFgb2uiQLbeKtnXaH4/BcyPWZwjAD4XHd4/PU9UhbBqpm9J UEVg== X-Gm-Message-State: AOAM531lUNQHF4mdDxtvCakSkMcOWl/Fm7Lh77Ytx70ru7VhtRyVBc2Z 2nxzWOHx/Hsn8oU2p/R+dqu+c/dmfe0= X-Google-Smtp-Source: ABdhPJx/F8nzatUQqU4y8HzsvOE3YzLUxvKM35mOhYknWD5LLPbAA4ckBcd+e3fs0IH24GoBg+KG2g== X-Received: by 2002:a17:90a:9c6:: with SMTP id 64mr3584729pjo.155.1629227824339; Tue, 17 Aug 2021 12:17:04 -0700 (PDT) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id r10sm2888618pjd.49.2021.08.17.12.17.02 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Aug 2021 12:17:03 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_0C7FC61D-FAFC-438B-97EA-ABDC0F7D614C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 17 Aug 2021 12:17:02 -0700 References: <162922730069.8996.13090730301811708198@ietfa.amsl.com> To: babel@ietf.org In-Reply-To: <162922730069.8996.13090730301811708198@ietfa.amsl.com> Message-Id: <1F1291E6-8895-47FA-9C64-71DDAC2993A4@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-yang-model-11.txt 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, 17 Aug 2021 19:17:11 -0000 --Apple-Mail=_0C7FC61D-FAFC-438B-97EA-ABDC0F7D614C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version of the draft addresses comments received as part of IESG = review. Cheers. > On Aug 17, 2021, at 12:08 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : YANG Data Model for Babel > Authors : Mahesh Jethanandani > Barbara Stark > Filename : draft-ietf-babel-yang-model-11.txt > Pages : 43 > Date : 2021-08-17 >=20 > Abstract: > This document defines a data model for the Babel routing protocol. > The data model is defined using the YANG data modeling language. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ >=20 > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-babel-yang-model-11 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_0C7FC61D-FAFC-438B-97EA-ABDC0F7D614C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = version of the draft addresses comments received as part of IESG review. = Cheers.

On Aug 17, 2021, at 12:08 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Babel routing protocol WG of the IETF.

=        Title =           : YANG Data = Model for Babel
=        Authors =         : Mahesh Jethanandani
=             &n= bsp;           &nbs= p;Barbara Stark
Filename =        : = draft-ietf-babel-yang-model-11.txt
Pages =           : 43
= Date =            : = 2021-08-17

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 is also an htmlized version = available at:
https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-mod= el-11

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-babel-yang-model= -11


Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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




= --Apple-Mail=_0C7FC61D-FAFC-438B-97EA-ABDC0F7D614C-- From nobody Thu Aug 19 09:02:11 2021 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 650BF3A0033; Thu, 19 Aug 2021 09:02:08 -0700 (PDT) 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, babel@ietf.org, d3e3e3@gmail.com, martin.vigoureux@nokia.com X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162938892769.18264.7883574712514765856@ietfa.amsl.com> Date: Thu, 19 Aug 2021 09:02:08 -0700 Archived-At: Subject: [babel] babel - New Meeting Session Request for IETF 112 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: Thu, 19 Aug 2021 16:02:09 -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: 18 Conflicts to Avoid: People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Aug 22 20:08:03 2021 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 00A633A1150; Sun, 22 Aug 2021 20:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 vz8RZ4oJeYgV; Sun, 22 Aug 2021 20:07:57 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 E23DD3A114C; Sun, 22 Aug 2021 20:07:56 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id u7so15707034ilk.7; Sun, 22 Aug 2021 20:07:56 -0700 (PDT) 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=Wuh/ie380zX6B1ewWcxQb/0jMv5h6050nJ4fR/cLeFQ=; b=lHpDpkjUcIjhveSByUfkatBXsjngB1GRJwAmjj0/m9Lxpn0Oe1x43wVUI2a2EvqWqH LN8PIjQrcRlBxU6pXH/+wYd4biM4LxHFstgcjA7dwmG8Rxd51MnOiR3cw8WUE1oL0Fmj ZMOVCYI5uPAUbsywn5VJHjkMR808IIVR/uO+aVJMoarMQYJrhIW+Tis9LhhkFwSOvY9K T0LKMFi0z7XBVXafEXTm1YqG9jea27SqKGIuMKhjWG5nfrlnxocxZaHdpXG4hAYcsi9e ieOrezSqmekrZp0dN2fWX+Kn7JeKacwf7q/Z+jAYk4onU5piPYdyOABFyjX5rzprvw7g I4DQ== 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=Wuh/ie380zX6B1ewWcxQb/0jMv5h6050nJ4fR/cLeFQ=; b=Ov5+t9jZW3RhQMY6SV9z3/5Bu7Ell9dsEuQLkHImuRAW8/tkUlXSWSL5JUIMG0itXh B8LOTC3YIiYuBnXACFZ1amyE00oBqMc28rng3KjRQJYcTBVwxv5VSrisy9e7vXTKssyo qg55o8i9F/yaqQXT+vEqI6FFpXeTRklMZhvz6VpLp9HxidoXNy55xSGOr/9u5S0nxzFM INYKXmecGDh65PYVCWPW8rhlS846rRvKVjfVal+nrwbNTe65SindeydJuCkKb/PiiKtd 3H7CfJV28HgMmxGRKyZhkWpVaKl49SaHa7QrIIg77XVzc0NRwalVllwI5A/kODQTYj7G Zxow== X-Gm-Message-State: AOAM533Tk3WRxRpaAAMCAzb8tgh7ndnhBPJNDBw9f+7b+m9lliAdGYYR 9osVkh0AunHGHCmTRhmOxbov0Jg1JKo57nqoyERcGmk5Hx8= X-Google-Smtp-Source: ABdhPJwj13SznpadznoLgE0GYb4sl/zGid0PYdZVKd4L1MZ6yP6cQ/U9jpZUoH+jcByrNLn/3QWhHKrsSGu9oVZW2xs= X-Received: by 2002:a05:6e02:1aa2:: with SMTP id l2mr13433324ilv.168.1629688074968; Sun, 22 Aug 2021 20:07:54 -0700 (PDT) MIME-Version: 1.0 References: <162938892769.18264.7883574712514765856@ietfa.amsl.com> In-Reply-To: <162938892769.18264.7883574712514765856@ietfa.amsl.com> From: Donald Eastlake Date: Sun, 22 Aug 2021 23:07:44 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="000000000000cda3b905ca315291" Archived-At: Subject: Re: [babel] babel - New Meeting Session Request for IETF 112 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, 23 Aug 2021 03:08:02 -0000 --000000000000cda3b905ca315291 Content-Type: text/plain; charset="UTF-8" Hi, As you may have noticed, the conflicts to avoid in the Babel WG meeting request did not appear in the message below. This is a new bug in the meeting request tool. Anyway, the Conflicts to Avoid were as follows (which could be changed if needed): 6man bess idr nvo3 rtgwg sfc homenet lpwan manet rtgarea You can see all the meeting requests that have been submitted so far for the November IETF meeting here: https://datatracker.ietf.org/meeting/requests Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Thu, Aug 19, 2021 at 12:02 PM IETF Meeting Session Request Tool < session-request@ietf.org> wrote: > > > 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: 18 > Conflicts to Avoid: > > > > > > > > > People who must be present: > Donald E. Eastlake 3rd > Russ White > Martin Vigoureux > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > > --000000000000cda3b905ca315291 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As you may have noticed, the conflicts to avoid= in the Babel WG meeting request did not appear in the message below. This = is a new bug in the meeting request tool. Anyway, the Conflicts to Avoid we= re as follows (which could be changed if needed):
6man bess idr nvo3 rtgwg sfc
homenet lpwan = manet rtgarea

You can see all the meeting requ= ests that have been submitted so far for the November IETF meeting here: https://datatracker= .ietf.org/meeting/requests

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

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 P= anoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


On Thu, Aug 19, 202= 1 at 12:02 PM IETF Meeting Session Request Tool <session-request@ietf.org> wrote:


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):=C2=A0 1 Hour
Number of Attendees: 18
Conflicts to Avoid:








People who must be present:
=C2=A0 Donald E. Eastlake 3rd
=C2=A0 Russ White
=C2=A0 Martin Vigoureux

Resources Requested:

Special Requests:

---------------------------------------------------------


--000000000000cda3b905ca315291-- From nobody Thu Aug 26 16:00:59 2021 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 2EFB03A011B; Thu, 26 Aug 2021 16:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qB2t62ZhPG2X; Thu, 26 Aug 2021 16:00:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615163A0128; Thu, 26 Aug 2021 16:00:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A0EAEF406F0; Thu, 26 Aug 2021 15:59:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, babel@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210826225947.A0EAEF406F0@rfc-editor.org> Date: Thu, 26 Aug 2021 15:59:47 -0700 (PDT) Archived-At: Subject: [babel] =?utf-8?q?RFC_9079_on_Source-Specific_Routing_in_the_Bab?= =?utf-8?q?el_Routing_Protocol?= 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, 26 Aug 2021 23:00:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9079 Title: Source-Specific Routing in the Babel Routing Protocol Author: M. Boutier, J. Chroboczek Status: Standards Track Stream: IETF Date: August 2021 Mailbox: boutier@irif.fr, jch@irif.fr Pages: 13 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-babel-source-specific-08.txt URL: https://www.rfc-editor.org/info/rfc9079 DOI: 10.17487/RFC9079 Source-specific routing, also known as Source Address Dependent Routing (SADR), is an extension to traditional next-hop routing where packets are forwarded according to both their destination address and their source address. This document describes an extension for source-specific routing to the Babel routing protocol. This document is a product of the Babel routing protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Aug 26 16:12:13 2021 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 519F03A1437 for ; Thu, 26 Aug 2021 16:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FKProt9VlQF0 for ; Thu, 26 Aug 2021 16:12:05 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B98E3A1434 for ; Thu, 26 Aug 2021 16:12:04 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 17QNC0Vm014015 for ; Fri, 27 Aug 2021 01:12:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E267FE1DED for ; Fri, 27 Aug 2021 01:12:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id O9NPwycf_JPi for ; Fri, 27 Aug 2021 01:11:58 +0200 (CEST) Received: from pirx.irif.fr (user-5-173-18-3.play-internet.pl [5.173.18.3]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 98673E1DE8 for ; Fri, 27 Aug 2021 01:11:58 +0200 (CEST) Date: Fri, 27 Aug 2021 01:11:50 +0200 Message-ID: <87o89jiyx5.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org References: <20210826225952.9555BF40716@rfc-editor.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: message/rfc822 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 27 Aug 2021 01:12:00 +0200 (CEST) X-Miltered: at korolev with ID 61281FC0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 61281FC0.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 : 61281FC0.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: [babel] Fwd: [homenet] RFC 9080 on Homenet Profile of the Babel Routing Protocol 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, 26 Aug 2021 23:12:12 -0000 Delivered-To: jch@irif.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1630018958; bh=8751+2op1QUMB8nhbacqfJlXTHMnl+D05XxQBlYUt6Q=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=WozIrQcOytZr2ZVZYL36ocC9rGBZa/UdxfHiEbDYD+RL9kr9UfKyJ7ubegkLJJSAZ mPwo/W/ZBZTH6OhdQtWQX8Mf7f8TgWQVOvuOQ9XxJL/9e4x7gutvS/TetGdDHCYpvl WtCozoItkmbUJpSJqPR7v7ggiv4L8DtG6q/+Uk5Y= X-Mailbox-Line: From homenet-bounces@ietf.org Thu Aug 26 16:02:28 2021 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1630018832; bh=8751+2op1QUMB8nhbacqfJlXTHMnl+D05XxQBlYUt6Q=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=ZBI61Rhcil+rS310Jij7/vo/O2FX73iZcbp/O3S9CILw76rxRunCbZfmwCi99yy88 bGOeeKpOf+46gY0Yo9yUcMA7g7itS3S240auK/wTzl4gLiUfrkayp8jWalnpYxaxx8 JDWkoXYoDSM1x64vNYkkBkhNmGVHNmVwRvDPUK7M= X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20210826225952.9555BF40716@rfc-editor.org> Date: Thu, 26 Aug 2021 15:59:52 -0700 (PDT) Archived-At: Subject: [homenet] =?utf-8?q?RFC_9080_on_Homenet_Profile_of_the_Babel_Rou?= =?utf-8?q?ting_Protocol?= X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: drafts-update-ref@iana.org, homenet@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: homenet-bounces@ietf.org Sender: "homenet" A new Request for Comments is now available in online RFC libraries. RFC 9080 Title: Homenet Profile of the Babel Routing Protocol Author: J. Chroboczek Status: Standards Track Stream: IETF Date: August 2021 Mailbox: jch@irif.fr Pages: 8 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-homenet-babel-profile-07.txt URL: https://www.rfc-editor.org/info/rfc9080 DOI: 10.17487/RFC9080 This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of the Homenet protocol suite, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel. This document is a product of the Home Networking Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet From nobody Thu Aug 26 17:22:48 2021 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 9FD0B3A1A5B for ; Thu, 26 Aug 2021 17:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 x8J9LXAWxPzY for ; Thu, 26 Aug 2021 17:22:40 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 8DA393A1A59 for ; Thu, 26 Aug 2021 17:22:40 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id f11-20020a17090aa78b00b0018e98a7cddaso3572383pjq.4 for ; Thu, 26 Aug 2021 17:22:40 -0700 (PDT) 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=OS3YtR4vS0mOSl/wiOhdYsO8ccFGjN2yogVULEv7p48=; b=PYW4ShGtZDvR/4uIFW1iCZTL8DDkn6X17yVkZ2X/LlgWLE51umKQIh8KEh/3LYmjfM ciX8PaR1FZocEgDZaCxrT/jozR7q4oDJUGXFxpORbWpejgOUMW37gY0biCX9XlX2rEz6 p9eOhla8YGviz9wcl4tPRbPWqx2k0MvTQf7XIBHCDDcQvu/DpafeCF4zH82Kay+x9ki5 Wcb3VruJ0nsTLZPYKsfPxrSgoxy7bzswrGnmigzY6nCRlJdPuct/5sO1VgTJkWXHLtQg r4aGVkOF6MnH2KzXa+1dhCyz2ZN3TXP4ifWTgm+9abtp9DSYzbPtEzUk7w87B1BWJ2YW 4dvQ== 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=OS3YtR4vS0mOSl/wiOhdYsO8ccFGjN2yogVULEv7p48=; b=um7UiqXY4TCpxmFVDkC/1XQAYvbFhQK03B9SFuI1jMdOV0WGc7dP+Y0ZAon6QfJBL0 3znJ1weB08qoAHtYgfNnAOrBOyG6j+GkIPvmA3rnW4Aef4GK9sq5zqwArtTe6YkRTqo4 Yw51eOR3vsLxrfRE34xTRhRffkymapX67sVXkLFO6E/0bNiJVPbI+NMAvtVbBZCfMcng fHchNWkJPuUZ9RGB/JhvkXg5SNFMM5WLtBLChmcvMvxOcPlpgDQH5ECKbv30XcRjfr6y JU7pmDgsOJp66ovSQ3FyyFF/pVTdtEdURT+BcfgmXE3+x9m3W91ynnMOwO8o/4l0/gn1 pjYw== X-Gm-Message-State: AOAM533BVzC2r4VvJaBFhy9bCY8HXuGq56Z7T73T9QoYA4WOU+IHFnY8 Kj+vZv/SoNLbURvmMdYsMs1EwYBqx2s= X-Google-Smtp-Source: ABdhPJyTnb+uTkewU2PNq2kc/UdbtWF9I6+ZWCCD39KaE+8k1ZONzQYpFrcqqD8hVyjJVfLnedwc9Q== X-Received: by 2002:a17:90b:384a:: with SMTP id nl10mr19705604pjb.65.1630023759440; Thu, 26 Aug 2021 17:22:39 -0700 (PDT) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id q3sm4748395pgf.18.2021.08.26.17.22.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 17:22:38 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <9FF32FE2-80CD-438D-9E4B-54031CDAB3DA@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CC24DA05-CD77-491B-841A-ED142101D3FF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Thu, 26 Aug 2021 17:22:37 -0700 In-Reply-To: <87o89jiyx5.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <20210826225952.9555BF40716@rfc-editor.org> <87o89jiyx5.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [babel] [homenet] RFC 9080 on Homenet Profile of the Babel Routing Protocol 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, 27 Aug 2021 00:22:47 -0000 --Apple-Mail=_CC24DA05-CD77-491B-841A-ED142101D3FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Congratulations! > On Aug 26, 2021, at 4:11 PM, Juliusz Chroboczek wrote: >=20 >=20 > From: rfc-editor@rfc-editor.org > Subject: [homenet] RFC 9080 on Homenet Profile of the Babel Routing = Protocol > Date: August 26, 2021 at 3:59:52 PM PDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org, homenet@ietf.org, = rfc-editor@rfc-editor.org >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 9080 >=20 > Title: Homenet Profile of the Babel=20 > Routing Protocol=20 > Author: J. Chroboczek > Status: Standards Track > Stream: IETF > Date: August 2021 > Mailbox: jch@irif.fr > Pages: 8 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-homenet-babel-profile-07.txt >=20 > URL: https://www.rfc-editor.org/info/rfc9080 >=20 > DOI: 10.17487/RFC9080 >=20 > This document defines the exact subset of the Babel routing protocol > and its extensions that is required by an implementation of the > Homenet protocol suite, as well as the interactions between the Home > Networking Control Protocol (HNCP) and Babel. >=20 > This document is a product of the Home Networking Working Group of the = IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the=20 > standardization state and status of this protocol. Distribution of = this=20 > memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_CC24DA05-CD77-491B-841A-ED142101D3FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Congratulations!

On Aug 26, 2021, at 4:11 PM, = Juliusz Chroboczek <jch@irif.fr> wrote:


From: = rfc-editor@rfc-editor.org
Subject: = [homenet] RFC = 9080 on Homenet Profile of the Babel Routing Protocol
Date: August 26, 2021 at 3:59:52 PM PDT
To: = ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: = drafts-update-ref@iana.org, homenet@ietf.org, rfc-editor@rfc-editor.org


A new Request for Comments is now available in = online RFC libraries.


=        RFC 9080

       Title: =      Homenet Profile of the Babel
= =             &n= bsp;      Routing Protocol
=        Author: =     J. Chroboczek
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       August 2021
=        Mailbox:    jch@irif.fr
=        Pages: =      8
=        Updates/Obsoletes/SeeAlso: =   None

=        I-D Tag: =    draft-ietf-homenet-babel-profile-07.txt

=        URL: =        https://www.rfc-editor.org/info/rfc9080

       DOI: =        10.17487/RFC9080

This document defines the exact subset of the = Babel routing protocol
and its extensions that is required = by an implementation of the
Homenet protocol suite, as = well as the interactions between the Home
Networking = Control Protocol (HNCP) and Babel.

This = document is a product of the Home Networking Working Group of the = IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an = Internet Standards Track
protocol for the Internet = community, and requests discussion and suggestions
for = improvements.  Please refer to the current edition of the = Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol. =  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce = and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For = downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are = for
unlimited distribution.

The RFC Editor Team
Association Management = Solutions, LLC

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


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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_CC24DA05-CD77-491B-841A-ED142101D3FF-- From nobody Sun Aug 29 12:52:35 2021 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 327233A10B8 for ; Sun, 29 Aug 2021 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7CVUYez_uo5X for ; Sun, 29 Aug 2021 12:52:28 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A7A3A10B6 for ; Sun, 29 Aug 2021 12:52:26 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 17TJqMg5001125 for ; Sun, 29 Aug 2021 21:52:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 61B812DCEB for ; Sun, 29 Aug 2021 21:52:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id X5c3kYsf-hlb for ; Sun, 29 Aug 2021 21:52:21 +0200 (CEST) Received: from pirx.irif.fr (user-5-173-24-11.play-internet.pl [5.173.24.11]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8C4B42DCE7 for ; Sun, 29 Aug 2021 21:52:21 +0200 (CEST) Date: Sun, 29 Aug 2021 21:52:13 +0200 Message-ID: <87wno4qb9u.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 29 Aug 2021 21:52:23 +0200 (CEST) X-Miltered: at korolev with ID 612BE576.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 612BE576.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 : 612BE576.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: [babel] =?iso-8859-1?q?St=E9phane_Bortzmeyer_about_Source-specif?= =?iso-8859-1?q?ic?= 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, 29 Aug 2021 19:52:33 -0000 Hi, Stéphane Bortzmeyer has publishes one of his usually excellent blog entries. This time about RFC 9079, Source-specific in Babel. https://www.bortzmeyer.org/9079.html (In French.) -- Juliusz From nobody Mon Aug 30 07:46:48 2021 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 DDB223A14F3 for ; Mon, 30 Aug 2021 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 XxQiW6mG8K4i for ; Mon, 30 Aug 2021 07:46:40 -0700 (PDT) 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 CAB5F3A14EE for ; Mon, 30 Aug 2021 07:46:39 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id b4so16317591ilr.11 for ; Mon, 30 Aug 2021 07:46:39 -0700 (PDT) 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; bh=MJbma2yE33p9jtI3LzpYJIS7ILuD6cqmYQZrwhTwNIg=; b=KaiuEg3uA77P4Llem+BgCMuHam/OahF1KQbN9EtcqJDQi3xT5W2gsuRD0oze360Dom XS6St6bI0lxo7Wn6NeQllmXRlGcPj6F9TvFCrls2dh0F/1QERSkGS6QPpjrl/kU005xS uIym/7okpImYMB/bIYV2F1+tv6qvoAy4StGRIb6+3HnJ7v4t1mpZ3eyMHsWJLIGR95IV a4rc6ng2eMu6kVRyMfF4CfnOjg8iGT7S7pmXQC/MwSufdmWmXk7nkZVkMKRn4IPYg4fc ZENKjEuxRtfsprnfatJZkHgMEetki2wr0OGpLBje5SDWovdUsUWgweTzOp/E9WqxOre9 3kCA== 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; bh=MJbma2yE33p9jtI3LzpYJIS7ILuD6cqmYQZrwhTwNIg=; b=WdgMCykoB60s67b6bR305gEdc4/n4k/33rRKZjMZLQw2sgvNAl8/8e5So09jCs6w6O 5zWbYp87K1x1nmL5v5m54J0pL0MHpnw5Gy4k3w8KjTbXGV8IOev8gkESdPQfHPhMmTGH AsisP0mNt8tcbOpUVhin2OaYwW4tAlhmwqqTNUeJktePHgJn2MMY0+n4qCibc4QiaZn2 Iqxdve4Ywe49RBswDe1KozPaN5wIW1IigqjcsnD3ewgME6eWmgcuq9IpaL3aAIV0jhWb hyyGfU0khtGYfqmYfa4bwatf4VTzvFVIwMv4ddl7wQLJxAqgmnu068rcrOO0yDmPDHSD q3IQ== X-Gm-Message-State: AOAM532XBA1kF3gmH6oz8nfZVPyzTD9Jdwwve69DOW9nFaEIGJg55CpJ AlvLoa2FdZ+7c6RKkpW1qFzaTt+NsyWyMUhyLXpFWubV X-Google-Smtp-Source: ABdhPJzJBKnsVL096yPY1HDoeRMxmqz7VbzCZkAP0P6hCCQq5pBDwmHTZQAmwD5xymMK49B2TVN0IFkN93CarwayL20= X-Received: by 2002:a92:194c:: with SMTP id e12mr15610748ilm.199.1630334797072; Mon, 30 Aug 2021 07:46:37 -0700 (PDT) MIME-Version: 1.0 References: <163033223438.8507.13442799687479808565@ietfa.amsl.com> In-Reply-To: <163033223438.8507.13442799687479808565@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 30 Aug 2021 10:46:26 -0400 Message-ID: To: babel@ietf.org Content-Type: multipart/alternative; boundary="00000000000071cba405cac7e6cb" Archived-At: Subject: [babel] Fwd: NomCom 2021-2022 Call for Nominations 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, 30 Aug 2021 14:46:46 -0000 --00000000000071cba405cac7e6cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI. 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 ---------- Forwarded message --------- From: NomCom Chair 2021 Date: Mon, Aug 30, 2021 at 10:05 AM Subject: NomCom 2021-2022 Call for Nominations To: IETF Announcement List Cc: Finally! The moment we've all been waiting for: C A L L F O R N O M I N A T I O N S ! ! ! The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations from now until Monday, October 11, 2021. The open positions and more information are found at the NomCom web site: https://datatracker.ietf.org/nomcom/2021/ They are also included below for convenience. Nominations may be made by selecting the Nominate link at the top of the NomCom 2021 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2021/nominate/ Self-nomination is welcome! Note: Nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ If you are unable to use the web form, nominations may instead be made by email to nomcom-2021 at ietf dot org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The finalized questionnaires will be available no later than Monday, September 6, 2021 (preliminary versions are already posted) and have a submission deadline of Monday, October 18, 2021. NomCom 2021-22 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 8713: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way, e.g., anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP 10 remain in effect. All feedback and all NomCom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the NomCom to tell the nominee that you were the one who made the nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't mark the field we won=E2=80=99t tell= . In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before Monday, October 11, 2021. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for nominee management permission, as it is easier to decline the nomination than put one in late. The NomCom appoints individuals to fill open slots on the IAB, IESG, the IETF Trust and the LLC Board: ART AD: 1 position INT AD: 1 position OPS AD: 1 position RTG AD: 1 position SEC AD: 1 position TSV AD: 1 position IETF Trust: 1 position IETF LLC: 1 position IAB: 6 positions The list of people and posts whose terms end with the March 2022 IETF meeting, and thus the positions for which this NomCom is responsible, is: [An asterisk (*) next to a person's name indicates they do not intend to accept renomination.] LLC Board (3-year term) Jason Livingood IETF Trust (3-year term) Kathleen Moriarty IAB (2-year term) Ben Campbell * Cullen Jennings Mirja K=C3=BChlewind Jared Mauch Tommy Pauly Jiankang Yao IESG (2-year term) Murray Kucherawy, ART AD Erik Kline, INT AD Robert Wilton, OPS AD Martin Vigoureux, RTG AD Benjamin Kaduk, SEC AD * Martin Duke, TSV AD Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, in individual tabs at: https://datatracker.ietf.org/nomcom/2021/requirements/ In addition to nominations, the NomCom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions=E2=80=99 responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-2021 at ietf dot org. Thank you for your help in identifying qualified nominees! Thanks, Gabriel Montenegro IETF NomCom Chair 2021-22 nomcom-chair-2021 at ietf dot org --00000000000071cba405cac7e6cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI.

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=A0d3e3e3@gmail.com

--= -------- Forwarded message ---------
From: NomCom Chair 2021 <nomcom-chair-2021@ietf.org><= /span>
Date: Mon, Aug 30, 2021 at 10:05 AM
Subject: NomCom 2021-2022 = Call for Nominations
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: <ietf@ietf.org>


Finally! The = moment we've all been waiting for:

=C2=A0 =C2=A0C A L L=C2=A0 =C2=A0 =C2=A0 =C2=A0F O R=C2=A0 =C2=A0 =C2=A0 = =C2=A0N O M I N A T I O N S=C2=A0 ! ! !

The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations
from now until Monday, October 11, 2021.

The open positions and more information are found at the NomCom web site:
https://datatracker.ietf.org/nomcom/2021/

They are also included below for convenience.

Nominations may be made by selecting the Nominate link at the top of the NomCom 2021 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2021/nominate/=

Self-nomination is welcome!

Note:=C2=A0 Nominations made using the web tool require an ietf.org datatracker <= br> account. You can create a datatracker ietf.org account if you don't have one =
already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

If you are unable to use the web form, nominations may instead be made by e= mail
to nomcom-2021 at ietf dot org. If using email, please include the word &qu= ot;Nominate"
in the Subject and indicate in the email who is being nominated, their emai= l
address (to confirm acceptance of the nomination), and the position for whi= ch you
are making the nomination. If you are nominating someone other than yoursel= f,
please tell us if we may tell the nominee that you were the one who made th= e
nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so.

Willing nominees will be asked to fill out a questionnaire specific to the = position
for which they are nominated. The finalized questionnaires will be availabl= e no
later than Monday, September 6, 2021 (preliminary versions are already post= ed)
and have a submission deadline of Monday, October 18, 2021.

NomCom 2021-22 will follow the policy for "Open Disclosure of Willing =
Nominees" described in BCP 10/RFC 8713: "The list of
nominees willing to be considered for positions under review in the current=
NomCom cycle is not confidential". Willing nominees for each position = will be
listed in a publicly accessible way, e.g., anyone with a datatracker accoun= t may
access the lists. Additionally, the nomination form asks if we may share yo= ur own
name with the nominee. In all other ways, the confidentiality requirements = of BCP
10 remain in effect. All feedback and all NomCom deliberations will remain =
confidential and will not be disclosed.

There is a field on the form you can mark in order to allow the NomCom to t= ell
the nominee that you were the one who made the nomination. This defaults to=
=E2=80=9Cno=E2=80=9D - so if you don't mark the field we won=E2=80=99t = tell.

In order to ensure time to collect sufficient community feedback about each= of
the willing nominees, nominations must be received by the NomCom on or befo= re
Monday, October 11, 2021.

Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for nominee management
permission, as it is easier to decline the nomination than put one in late.=

The NomCom appoints individuals to fill open slots on the IAB, IESG, the IE= TF
Trust and the LLC Board:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ART AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 INT AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPS AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTG AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SEC AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TSV AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF Trust: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF LLC: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB: 6 positions

The list of people and posts whose terms end with the
March 2022 IETF meeting, and thus the positions for which this NomCom is responsible, is:

[An asterisk (*) next to a person's name indicates they do not intend t= o accept
renomination.]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 LLC Board (3-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jason Livingood

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF Trust (3-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kathleen Moriarty
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB (2-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ben Campbell *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mirja K=C3=BChlewin= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jared Mauch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tommy Pauly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jiankang Yao

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IESG (2-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Murray Kucherawy, A= RT AD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Erik Kline, INT AD<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Robert Wilton, OPS = AD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Martin Vigoureux, R= TG AD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Benjamin Kaduk, SEC= AD *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Martin Duke, TSV AD=

Please be resourceful in identifying possible candidates for these position= s, as
developing our talent is a very crucial requirement for the IETF, and also,= please
consider accepting a nomination. You'll find extensive information abou= t specific
positions, in individual tabs at:

https://datatracker.ietf.org/nomcom/2021/requi= rements/

In addition to nominations, the NomCom seeks community input on the positio= ns
themselves. We need and welcome the community's views and input on the = jobs
within each organization. If you have ideas on the positions=E2=80=99 respo= nsibilities
(more, less, different), please let us know.

Please send suggestions and feedback about this to nomcom-2021 at ietf dot = org.

Thank you for your help in identifying qualified nominees!

Thanks,

Gabriel Montenegro
IETF NomCom Chair 2021-22
nomcom-chair-2021 at ietf dot org

--00000000000071cba405cac7e6cb--