From nobody Fri Oct 9 07:03:39 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852073A010A; Fri, 9 Oct 2020 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h50wFgwCn0IM; Fri, 9 Oct 2020 07:03:35 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EEB3A0D2A; Fri, 9 Oct 2020 07:03:03 -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 099E2wsu026086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Oct 2020 16:02:58 +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 099E2w4S018719; Fri, 9 Oct 2020 16:02:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 27C3812572F; Fri, 9 Oct 2020 16:02:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 7kFv-5cY2UFF; Fri, 9 Oct 2020 16:02:56 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 73998125728; Fri, 9 Oct 2020 16:02:56 +0200 (CEST) Date: Fri, 09 Oct 2020 16:02:56 +0200 Message-ID: <87blhbqyy7.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Martin Vigoureux'" , "'draft-ietf-babel-information-model@ietf.org'" , Babel at IETF In-Reply-To: References: <57d1a7c8-de0d-9713-f585-33934eeff2d0@nokia.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 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]); Fri, 09 Oct 2020 16:02:58 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 09 Oct 2020 16:02:58 +0200 (CEST) X-Miltered: at korolev with ID 5F806D92.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F806D92.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F806D92.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F806D92.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 : 5F806D92.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F806D92.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] AD review of draft-ietf-babel-information-model X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 14:03:38 -0000 Hi Barbara, Sorry for the delay, but we've been very busy organising teaching in a way that respects the current restrictions while still being of reasonable quality. It's a lot of stress, but also a lot of fun. > In contemplating your unnatural silence, I realized you weren't on any > of the lists included in this thread. The basic question is whether we > need config parameters for source-specific routing. It is my opinion that no such parameter is needed. 1. Source-specific has no effect unless a source-specific route is redistributed into the network. If no such route has been redistributed, then source-specific has no effect. If such a route has been distrbuted, then it has probably been redistributed for a reason. I see source-specific as analogous to IPv4: there is no knob to disable IPv4, since IPv4 routing will only happen if IPv4 routes are redistributed into the network. 2. Should the need arise, source-specific can be disabled by defining the right filtering rules. For example, in babeld you can say in src-ge 1 deny and all source-specific routes will be dropped. This, again, is analogous to IPv4: in ip 0.0.0.0/0 deny will effectively disable IPv4 routing. -- Juliusz From nobody Sat Oct 10 07:15:01 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2A3A0D72; Sat, 10 Oct 2020 07:14:58 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <160233929845.16094.8119522129789585976@ietfa.amsl.com> Date: Sat, 10 Oct 2020 07:14:58 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-source-specific-06.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: Sat, 10 Oct 2020 14:14:59 -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 : Source-Specific Routing in Babel Authors : Matthieu Boutier Juliusz Chroboczek Filename : draft-ietf-babel-source-specific-06.txt Pages : 11 Date : 2020-10-10 Abstract: 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 and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-source-specific-06 https://datatracker.ietf.org/doc/html/draft-ietf-babel-source-specific-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-source-specific-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 10 07:19:54 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89103A14E3 for ; Sat, 10 Oct 2020 07:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k2gnfSRSVPdQ for ; Sat, 10 Oct 2020 07:19:51 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247A23A14E7 for ; Sat, 10 Oct 2020 07:19:50 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 09AEJnuH019365 for ; Sat, 10 Oct 2020 16:19:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5CEDAD2162 for ; Sat, 10 Oct 2020 16:19:49 +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 9GE0H48Q2qOn for ; Sat, 10 Oct 2020 16:19:47 +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 9FEF0D215F for ; Sat, 10 Oct 2020 16:19:47 +0200 (CEST) Date: Sat, 10 Oct 2020 16:19:47 +0200 Message-ID: <87pn5qb1to.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <160233929845.16094.8119522129789585976@ietfa.amsl.com> References: <160233929845.16094.8119522129789585976@ietfa.amsl.com> 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]); Sat, 10 Oct 2020 16:19:49 +0200 (CEST) X-Miltered: at korolev with ID 5F81C305.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F81C305.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 : 5F81C305.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] I-D Action: draft-ietf-babel-source-specific-06.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: Sat, 10 Oct 2020 14:19:53 -0000 > Filename : draft-ietf-babel-source-specific-06.txt This revision removes all references to draft-ietf-rtgwg-dst-src-routing, which appear to be dead. This required expanding the Security Considerations changes. There are two normative changes: - in Section 4, first bullet point, MAY becomes SHOULD; - in Section 4, second bullet point, it is clarified that an implementation does not need to implement disambiguation, and that it may ignore source-specific routes instead. -- Juliusz From nobody Tue Oct 13 08:23:12 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 205823A0905; Tue, 13 Oct 2020 08:23:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-babel-source-specific@ietf.org, martin.vigoureux@nokia.com, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160260258706.16576.12658657825372553806@ietfa.amsl.com> Date: Tue, 13 Oct 2020 08:23:07 -0700 Archived-At: Subject: [babel] Last Call: (Source-Specific Routing in Babel) to Proposed Standard 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, 13 Oct 2020 15:23:07 -0000 The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'Source-Specific Routing in Babel' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Oct 13 08:24:01 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAA03A091B; Tue, 13 Oct 2020 08:23:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk CC: martin.vigoureux@nokia.com, babel-chairs@ietf.org, draft-ietf-babel-information-model@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160260263439.13297.9082772955065967646@ietfa.amsl.com> Date: Tue, 13 Oct 2020 08:23:54 -0700 Archived-At: Subject: [babel] Last Call: (Babel Information Model) to Informational RFC 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, 13 Oct 2020 15:24:00 -0000 The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'Babel Information Model' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-10-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This Babel Information Model provides structured data elements for a Babel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Oct 14 13:51:13 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9BC3A1078; Wed, 14 Oct 2020 13:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, 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 guWJoNLheddR; Wed, 14 Oct 2020 13:51:10 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 6ECE83A1076; Wed, 14 Oct 2020 13:51:10 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id l8so953681ioh.11; Wed, 14 Oct 2020 13:51:10 -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=AaSuqjqz0o4/xTkYqCocjz01Bjx2bPNP3clqHRTxA10=; b=csxZ1K57ETidK4+ZJIi82L+dZK6G/TSnktIIoiXNjJkG2qW9J7dgJdbID3xJnyziSh ht3KMcHQ2f6ZUI3TEtgo3JWgv0O8kBSfIwbK7M6IWc5kRg5aspyU8EteksY+nllfSe0D RBKQYBEGZvEvGLQPa/JvnaWmMB/GfOItJ2fIovaQBxbZwQ6PHcm6qxD7xIejiYChqoIT tIhz2c8o1ziiD8s8gCJZ9AWShHsFwZ6H1apqYBk34+hbVJljsjvJwglKZObWHyOZgjk+ MthxRfZsxTWRcx9gCmrukaeePjuYHHRL5S/Mh9MhyAYWpCsc2gYacF6aSuIQVSw9UzK2 +5wg== 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=AaSuqjqz0o4/xTkYqCocjz01Bjx2bPNP3clqHRTxA10=; b=qIUf37rYI6HnpQjxxFCHZErqfkTOmbvlM+p6ecbyfLma5nA7ncyr+M/7FeLitnH1Dv RWz+2iQ3o3IcG+XOnnGxYYQaugP6wWYdw9/LBQEBT2volfdYWpCyQWW95rKIVLFTreda 1UnfT/aJuF658lB1ZDTH/O76tT3o6JfZXFT2sZ9H85s+axN2RLmD177hA0hGrV8jPJlM byb0K0roaOt345TmhtOVKTdY3FIDRQeV52JqGbfAof41hYT7Gs5W3lOyVJawnzcAwg9I /HKt9fCmom3YJGwRwkvLpWeC/27Re9s+HYFuCfYDL7F6eEO7ySCK9hi0C93kucnE+5GD d0Qg== X-Gm-Message-State: AOAM531OoIi4enZXy2F0cMpOYlOxYjaAEc/cnjKtv0/fYDwzeWQgxXD9 lLW6K9tnyuivZvxGp6HZO+tBdIy42Fr8B/ShAK73nE/tzMA= X-Google-Smtp-Source: ABdhPJx2fpo8S+jOpdD8E97FL61quvA1bj5nJwHgVVbS31AT9iARFCbWEFwCsxOtsufV8yjEBvSbW9qrnIx927mRSSg= X-Received: by 2002:a02:ca03:: with SMTP id i3mr1131080jak.50.1602708669247; Wed, 14 Oct 2020 13:51:09 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Wed, 14 Oct 2020 16:50:58 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Call for presentations, Babel WG meeting at November IETF meeting 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, 14 Oct 2020 20:51:12 -0000 Hi, If you would like to present at the Babel WG meeting during the November IETF meeting (16-20 November) please post to this list or contact the chairs. This meeting will be virtual and the time of the Babel WG meeting slot has not yet been set, but this IETF meeting was originally scheduled to be in Bangkok so the daily meeting hours will be over a time window convenient for Bangkok's time zone: 05:00 to 11:00 UTC each day. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com From nobody Fri Oct 16 07:37:33 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBB63A0F8C for ; Fri, 16 Oct 2020 07:37:32 -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 Vm29kQOM4pGr for ; Fri, 16 Oct 2020 07:37:30 -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 0E24C3A09F0 for ; Fri, 16 Oct 2020 07:37:29 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 09GEbRL8015830; Fri, 16 Oct 2020 16:37: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 64D3FBCBDB; Fri, 16 Oct 2020 16:37: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 mnCQ8orkxJWg; Fri, 16 Oct 2020 16:37:25 +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 53A0FBCBB4; Fri, 16 Oct 2020 16:37:25 +0200 (CEST) Date: Fri, 16 Oct 2020 16:37:25 +0200 Message-ID: <87zh4mi6e2.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org, babel-users@lists.alioth.debian.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=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 16 Oct 2020 16:37:27 +0200 (CEST) X-Miltered: at korolev with ID 5F89B027.007 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F89B027.007 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 : 5F89B027.007 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] IETF-109 online 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, 16 Oct 2020 14:37:32 -0000 Dear all, IETF-109 will be held online from 16 to 20 November. There might or might not be a Babel meeting. They appear to have listened to our complaints, and requesting a fee waiver no longer requires slaughtering an immaculate goat over your keyboard. In order to participate for free, you need to: 1. Open an account on the IETF datatracker (unless you already have one): https://datatracker.ietf.org/accounts/create/ 2. Submit a waiver request on: https://www.ietf.org/forms/109-registration-fee-waiver/ I don't know how busy the secretariat is, but just in case, I would recommend doing that earlier rather than later. Regards, -- Juliusz From nobody Sat Oct 17 20:45:07 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEAD3A139C; Sat, 17 Oct 2020 20:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[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, 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 BqExVPFngwWT; Sat, 17 Oct 2020 20:45:03 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1EF3A0B3B; Sat, 17 Oct 2020 20:45:03 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id t12so7063661ilh.3; Sat, 17 Oct 2020 20:45:03 -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=HBOi8iHM7l/dBs1qp08Jq/kDmsI6T8Xfh06nk+Wff7c=; b=iXPmDo+GBpPEJ73KbJVNlHmg0qq5dxQU1BrIQ4dAf66KY2hOayYKLguvn7iXZOVyF2 irMhmRIlKhP7FDHb0XfX3oPIWz7IbF0pwKgLmZ+h6rgX9dgcVw3CfnM+wsWQW0nQcU+y sFYoqZn8udHfOhH9LYezjNNbZQJ1AC3k6u3D5AxG/J5+atjIzxtRk32/ExoMDT7LQEdt BCu7uXrgi2v3LgrfBJ6UE8US/9fe9swqVZlCDKhC7N8nWauXBv81eFpM3thiakkU8d96 hlmz6aR/PIY3K8BKB9spBMfYDHibaJe2Fm8pLe6S4RPBQlArCLNEYcNI9WCDttILR9o4 GsEA== 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=HBOi8iHM7l/dBs1qp08Jq/kDmsI6T8Xfh06nk+Wff7c=; b=biinM3kCIbXNJ3+86drCCVKFIUHRubf7MUJfrJomyyXtkjPyJ5p/Cfc6Lcppyd6LFT dSuyd04e1FglNpxKim4Aq3242FiVIIZUzVkp2Ef+0ukLjcgEZgQw97z7aguSVGEgeCsH 0swGbMdp2BAGAxTd3zkfMD6ra/Sj+9KpB2RWx+CmCaOxSNX5oCgaYonuhoaxJcMW+Q3i C6oc4moMVnzCggTDwUFIJ6uwL+VwaNF3iJvqQBbwLdckwt4VXA5jnpeGMMHPLPewejuQ zd0HIq41M3zJ8TSwE/FQ5+8lraR1IZhho5LoqgvOYVy/F5OyJe1g21wb6oAk/7e9Vn8q TVog== X-Gm-Message-State: AOAM532j84YcOeJiFXxBRz4Xtxxy/YQoEKtxBZNmeWiffxFNZkxHshO0 FX0bLXaAqbyZf+MWNudRt3OtCkLcoQBzXC0POq9g0zgf2+w= X-Google-Smtp-Source: ABdhPJyx9ZaLketzjrzDc9bXgtRWernYixFiuXUB3a5SaUH3FBMqIBpCnFMT4QgJc2qF2zCBJPsciAZEFgKw49Zo+lk= X-Received: by 2002:a92:bb0d:: with SMTP id w13mr7742130ili.168.1602992702622; Sat, 17 Oct 2020 20:45:02 -0700 (PDT) MIME-Version: 1.0 References: <87zh4mi6e2.wl-jch@irif.fr> In-Reply-To: <87zh4mi6e2.wl-jch@irif.fr> From: Donald Eastlake Date: Sat, 17 Oct 2020 23:44:51 -0400 Message-ID: To: Juliusz Chroboczek , Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] [Babel-users] IETF-109 online 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, 18 Oct 2020 03:45:06 -0000 Hi Juliusz, Thanks for your message below. The Babel WG meeting has been tentatively scheduled for UTC: Tuesday November 17th 07:30 to 08:30 Bangkok time: Tuesday November 17th 14:30 to 15:30 However, at this point no one has requested to present and if there aren't any requests in the next couple of weeks, the meeting will be cancelled. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Oct 16, 2020 at 10:37 AM Juliusz Chroboczek wrote: > > Dear all, > > IETF-109 will be held online from 16 to 20 November. There might or might > not be a Babel meeting. > > They appear to have listened to our complaints, and requesting a fee > waiver no longer requires slaughtering an immaculate goat over your > keyboard. In order to participate for free, you need to: > > 1. Open an account on the IETF datatracker (unless you already have one): > > https://datatracker.ietf.org/accounts/create/ > > 2. Submit a waiver request on: > > https://www.ietf.org/forms/109-registration-fee-waiver/ > > I don't know how busy the secretariat is, but just in case, I would > recommend doing that earlier rather than later. > > Regards, > > -- Juliusz > > _______________________________________________ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users From nobody Tue Oct 20 03:21:55 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE86C3A1120; Tue, 20 Oct 2020 03:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-wDxc6BQGIr; Tue, 20 Oct 2020 03:21:51 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400073.outbound.protection.outlook.com [40.107.140.73]) (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 6F5A13A111C; Tue, 20 Oct 2020 03:21:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cGwK31M5vnXKglQcIVCDNUSt8ATXqr14eumZUOOXr5S/raaz2MkLP/wDKLqYGPApdzU/v/axHamEV4qxdPtPxY6j5QIabUn0yUvaEeKIrOBYhGOOb/6G2er+iOdwjvPXD5MnWTlRiZOLBf/Ku2xpIclueGsC/cJr+6s431iPqx2649olgU8xvmfRIScOQfrubBCPulv8lGX1PC1rX4PoS6gwgaLgYU7ZIiRl3GTXTn9Qod0DYmWbrres0QNz+lQuL7U59i+Wycl0xgh2UW0Zu+IbgrbslTxcPojQYWfQwLSikpBclk9RBsQQq+kAim8gbAh0VO0jchx/0sNJ2jKYZg== 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=iAt8l3qU9ueAgHCdrdWwX+k0fkJ5gSrshXuy0d4Y5Fw=; b=hyCdr9FVQhG0vCl18njhuIj682i+RSwiyPPLXlH3Zjz+RG6NDdsX2aJUdtwEa34TrGvBY00QnNWzlFGGIRghIkgwSSpHp67LLkSI6nzEiVkVC/Cmx1eIQ/5XTnPGH10hxHm24xPRnQD0mxqQQTPSHfXl8OdiENjkg1dWL6ty8vYf/ZkekV63FzlLc4XVVJkb0+PJiDoDd6HG1/9yuwjxihNrW5QKtxYkgY/dcVOu2YHdaOQVO0+vNAo70O4WBwdqlWt3/fDgWuII2vNNgnmxQtIfmDHF16qeMtmdimVS90r1zPNShZ+I4vSKcyIw/yhqQm8IoRpQPTRUuQfkkahAfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iAt8l3qU9ueAgHCdrdWwX+k0fkJ5gSrshXuy0d4Y5Fw=; b=gH34/ZT4pf/LJMnfKfJ+itmJK4IYtLM5vVwFBqLzFY+GBPnV/8RSXWzPXHpTAU6RbkhYwN4aAJEz/E552agD/t/qfzN6hGuCYpKO8tfuY4K6LDulJw97hRTCUklmYxt53jipCK7qq3ri35ynqbQ/Wm4KzwoDyV1FE1PpiMDqkfs= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=apnic.net; Received: from TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) by TYAPR04MB2431.apcprd04.prod.outlook.com (2603:1096:404:1d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.24; Tue, 20 Oct 2020 10:21:42 +0000 Received: from TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::88bd:7d3f:b0e8:435a]) by TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::88bd:7d3f:b0e8:435a%7]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 10:21:42 +0000 From: Geoff Huston Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> Date: Tue, 20 Oct 2020 21:21:31 +1100 Cc: rtg-dir@ietf.org, draft-ietf-babel-information-model.all@ietf.org, last-call@ietf.org, babel@ietf.org To: rtg-ads@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Originating-IP: [2001:44b8:110b:5100:794a:3b8d:58a4:7e02] X-ClientProxiedBy: MEAPR01CA0039.ausprd01.prod.outlook.com (2603:10c6:201::27) To TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from 2001-44b8-110b-5100-794a-3b8d-58a4-7e02.static.ipv6.internode.on.net (2001:44b8:110b:5100:794a:3b8d:58a4:7e02) by MEAPR01CA0039.ausprd01.prod.outlook.com (2603:10c6:201::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Tue, 20 Oct 2020 10:21:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e5bca6ad-7ea9-4d38-7e2d-08d874e1efb6 X-MS-TrafficTypeDiagnostic: TYAPR04MB2431: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +CrfEB2PqjRPKSr0GafMoyAP/+UknQUCXk/iph2HFI/Clzl1lAtmxIcEfhaI3Z4N2yUtj+1/YjDjecL/uIPDTjUYy5MmpK7DQYhu+co59yevq+G4nW+wQn6JNAV0JIhODurAopTFc29b7A/LvCozqp4/1ZT3M6Pq2aqEFkKYpBwYq8k3ibLMpE0haD++09UP82QebOtpXD31m5ojVULeCfJsFIgrlpVrw0pLVqUQVgizHnHH/ClIktDl9ZbuxxFcjKmzgoon7KNX1AG3HW9l95pDDv/Nt4mOvvqYcUOSBhU6S8bSUt7D2bVcR33iQHRy6yv6lsdaXS6sEfz8Avb6H00IMXvfLtgAUwDVWfwgmCw2kcCj2QqA30iBkrrJVCE2dAHjAwUn/LMFGIEAkygfMQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR04MB2286.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(39840400004)(136003)(396003)(66476007)(66556008)(6512007)(316002)(66946007)(8936002)(5660300002)(36756003)(4326008)(2906002)(83380400001)(8676002)(52116002)(6506007)(6666004)(6916009)(2616005)(450100002)(6486002)(33656002)(478600001)(86362001)(16526019)(186003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: q8Jlcs8rV5Xaxwv6UXz5C0MXSbqlQN74NX02rrHS+o9o3p/VVLBNaeWBeBV7DDFsm0pJkwRWLYxzKZDOOtmtMAn7ssWAnbHj34IMHRxNm1VAwZEh4lRrht04GK73FkQbMoIM326ZP/qjvXQMDJsW1Bv8nJM+xdbLe/r9ghVHPbRk4fbuDkQoCRurEwaIHnY7ehnjz0Q5mQbMMtr+ugXgAcalVEDSYAAfbuqoROSuRYWzGL+2hOFehthaRjF1MSsl59KBh56BqC5qB5NaswhYgsluhNFlw6FbwXqp75zWAmJIMMiJ9dw0DbUl8eTnAMr4kyKNwPB7+e50ptwrvARlIBmX2rUAU+2fYZ2Y2SV+hf3/Ewoa6BJtVWGDwDfYd/CbzngizLF/tn3eQQ57rb1101e/2V9miOJSVyZ57pXuhSQdOW0UHhsvX6QEjahr1GCWm54aQxtRRs75UsGOlGd/vkSU5SP8B436EcsDmpCnFVtp31bM458V0GMft7giSp4Tja16mdRbU4TCS5NRSvTsfC5KWBOl6UNaE0j5k1dr2svqctV34lLeY4vV0MpKaR4bAW/e2ZQH1UbeAGPmrKD2lPxcwTRWX6lFoKvgfRlBZwdYcPxdfU9c1GjcWaDdACw8vYfZyh+4Dhgf22MnFzpvQmPoC2FNYZWZuR3DSDTedDQmMu4MVcjx5jfFE7JGF+JLzEfL8yp4IlsTVwMCiw1OzQ== X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: e5bca6ad-7ea9-4d38-7e2d-08d874e1efb6 X-MS-Exchange-CrossTenant-AuthSource: TYAPR04MB2286.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2020 10:21:42.0757 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2HApUGx7eaDKY+kqOvXN41w4Qfeo2zgrBGTnbTq4l9eDCPb+GLndu4DG4xSVNXTK X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR04MB2431 Archived-At: Subject: [babel] RtgDir review: draft-ietf-babel-information-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, 20 Oct 2020 10:21:53 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts a= s they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: raft-ietf-babel-information-model-11.txt=20 Reviewer: Geoff Huston=20 Review Date: date=20 IETF LC End Date: 27 Oct 2020 Intended Status: Informational Summary:=20 No issues found. This document is ready for publication. Comments: This document provides an information model for the Babel protocol. It uses a pseudo programming language like notation to enumerate a lisdt of objects that collectively comprise the information model. It appears that the primary purpose of this document is as a reference source for implementors of this protocol. This is not an easily readable document, but I believe that was never the intention. This is a list of objects and the hierarchical structure in whic= h the objects are placed. The document does not attempt to justify why these objects are listed here, nor does it elaborate as to their intended role other than a brief functional desription of the information that is denoted by the object. Major Issues: None Minor Issues: None Nits: It seems anomalous to this reviewer that it goes to the bit lengths of some integer valued objects, yet leaves string objects undefined in terms of any maximum length.=20 "centiseconds"? Really? "tenths of seconds" would be clearer to most readers! From nobody Tue Oct 20 03:53:18 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9F03A1160 for ; Tue, 20 Oct 2020 03:53:16 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPsfCikiiA-R for ; Tue, 20 Oct 2020 03:53:15 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 DE1C33A115A for ; Tue, 20 Oct 2020 03:53:15 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id p9so1621475ilr.1 for ; Tue, 20 Oct 2020 03:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=A5iqc/qWUDB8VTYzoJID1XlV9/ofsIbMYXcn9dY3SyM=; b=MxgFKZD5w1hLjqiNMZl0XSPTEaqEecAP8GJWC/h0EqFFQBy2SgDoz+aJXNREEL7v1l gwQMZmwH/1H7fUmgegTFquvTNouG1UA/0wy6FfBYMsox5hGQGI1JFAqYy6UqwrXsBjoF YGfEOArDVDQ2+dwi/qpO6naje81o0ripXGz8w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=A5iqc/qWUDB8VTYzoJID1XlV9/ofsIbMYXcn9dY3SyM=; b=tg1BNK1ISFTgsykXTD3nBszr6B2JTaAili30kSBEYXjGdsMl6zSKmm5v/iHnsfCfwU oN433DoHmRF8Ub3X6lvFy5RAaZxRpZtpx6maJhMrWFstUfWRo+A8AutK46PgkhM8VXLQ a+HFNd2oZxUICGEWbqJg34Tn4PyJnwAc8cfHDxygfPpXpA5PluDMnGbLYaDQoXOesSiq 1H80HfsKSJesbItZ5lmjsldo3fvSWpGWTTRJ/+54Au5aOEUtJ2aJkr6F/PyACdAconQ/ mKMlqxj78kGZaKowmAojvKMzKWSw7fswG0JhaXaKX3gYJges9hJiJpc8iHVH9Vv6SYD5 AdIA== X-Gm-Message-State: AOAM5328f5jintfDiwxm1Ix+T/1WnJizEmT59eLLD/u1iaWzqHCUjG31 jCMmvD0FXymDt5th+aVUyT8/MQ== X-Google-Smtp-Source: ABdhPJzYVl5f9MnJpgv2iv6ER7+U8Nf0fciEz62r8RcRBmMbRMHjuRSewL6x1HNoz86k52Mk9LfDMA== X-Received: by 2002:a92:b109:: with SMTP id t9mr1322513ilh.191.1603191195057; Tue, 20 Oct 2020 03:53:15 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e784:c7:e8c3:131d:a176:6097? ([2607:f2c0:e784:c7:e8c3:131d:a176:6097]) by smtp.gmail.com with ESMTPSA id 128sm1265772iow.50.2020.10.20.03.53.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Oct 2020 03:53:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Joe Abley In-Reply-To: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, babel@ietf.org, draft-ietf-babel-information-model.all@ietf.org, last-call@ietf.org Date: Tue, 20 Oct 2020 06:53:12 -0400 Message-Id: References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> To: Geoff Huston X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [babel] [Last-Call] RtgDir review: draft-ietf-babel-information-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, 20 Oct 2020 10:53:17 -0000 (I am not on all these lists in the headers but I'll leave the recipient lis= t intact anyway.) On Oct 20, 2020, at 06:22, Geoff Huston wrote: > "centiseconds"? Really? "tenths of seconds" would be clearer to most > readers! Perhaps this was intentional, but a centisecond is a hundredth of a second, n= ot a tenth (just as a centimetre is a hundredth of a metre). A tenth of a se= cond is a decisecond. Centi- is a metric prefix recognised by SI (in which system the second is a b= ase unit) so I think it's fair to say that centisecond is not an outlandish c= hoice of unit, although millisecond would be more consistent in many enginee= ring contexts. But apparently the SI system units is not taught in schools everywhere even t= oday (notably in much of the US) so maybe spelling it out as you suggest is r= easonable.=20 Joe= From nobody Tue Oct 20 05:49:40 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86723A0A6E; Tue, 20 Oct 2020 05:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JxV6bfkyV3cv; Tue, 20 Oct 2020 05:49:34 -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 E16D23A0A63; Tue, 20 Oct 2020 05:49:32 -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 09KCnMmR010214; Tue, 20 Oct 2020 14:49:22 +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 CED4A20035; Tue, 20 Oct 2020 14:49:22 +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 0gqMhzqhvafg; Tue, 20 Oct 2020 14:49:20 +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 4E6502000F; Tue, 20 Oct 2020 14:49:20 +0200 (CEST) Date: Tue, 20 Oct 2020 14:49:20 +0200 Message-ID: <87v9f5vz8v.wl-jch@irif.fr> From: Juliusz Chroboczek To: Joe Abley Cc: Geoff Huston , rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org, last-call@ietf.org In-Reply-To: References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> 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]); Tue, 20 Oct 2020 14:49:22 +0200 (CEST) X-Miltered: at korolev with ID 5F8EDCD2.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F8EDCD2.004 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 : 5F8EDCD2.004 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] [Last-Call] RtgDir review: draft-ietf-babel-information-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, 20 Oct 2020 12:49:36 -0000 >> "centiseconds"? Really? "tenths of seconds" would be clearer to most >> readers! > Perhaps this was intentional, but a centisecond is a hundredth of a second, The wording is consistent with Section 4.1.2 of draft-ietf-babel-rfc6126bis: Relative times are carried as 16-bit values specifying a number of centiseconds (hundredths of a second). It then goes on to justify this somewhat unusual choice of units: This allows times up to roughly 11 minutes with a granularity of 10ms, which should cover all reasonable applications of Babel > maybe spelling it out as you suggest is reasonable. I agree, a parenthetical remark to define the unit would be helpful, simlarly to what is done in rfc6126bis. -- Juliusz From nobody Tue Oct 20 09:36:58 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EF33A1193; Tue, 20 Oct 2020 09:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZZElOaxzsyV; Tue, 20 Oct 2020 09:36:54 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410057.outbound.protection.outlook.com [40.107.141.57]) (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 BCA763A0B08; Tue, 20 Oct 2020 09:36:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cGrtqmngDWjEug/Cg1UZ3UEJ8A1wClxzhIjDYzu3gA+iPn7a8AFPIvK0Q/8BVbz1DjFnbBwDU9SDU1qJt3Tg5yQuU25IvUxCSmF/lLRaWAwWiOF2+pwB6+mJP7Ho+sXpW7klx4rWHsqEjlxa9e1+tVj4AgTLeTeMCram1CUohl+aueS5SA9y4bBRhFKG5X/o9DDrtrZzCFZbgMjxHejoi75mtkSU+rgIlkbB7jRFBnj6jxAGn+3XbrfUHrBgncTcJzJN3D1P6pEL9VqwI3p+qvk7IABqwnlUideERIFEvE/QlIyDXMGtdKFWKkIYEp3R+84Nd4WC7cFxdg1hQAlhtQ== 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=6synFCYSCD1Hnyp94xqTEWg2h2yH8l5MOzPi9i7C/4c=; b=eYY8SAEerPMFP95u5OBm/aTThhF94qsjpIL+tvHfZSaN/6+HQMF2gGOQOkGbxA+KSdQkf1y8PjLHmvPxikkaTlPMKV9EQlZTrXZX3zmbnEetBBW41OOSjRkRTi5Etz7uqkbJHs4qcDSg7k5d8mJpc3Vlt0D1faxEaJuUQTRwX0wPd+d3IiyePEdZ39sElj+qnWRPQWk/yElJ5pQed7U0lhVxvHeBBtJXDblNyoZ5cyB3cUqCWDunwW8+otOHG/jVhXBhFCpCwnPTE5sVoz+QB/rDQqVfvhKm7ZHN023s7jW8wTumLmlqWhQLctRZ35DvfUnp0GgMvd9acv6VYiiztw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6synFCYSCD1Hnyp94xqTEWg2h2yH8l5MOzPi9i7C/4c=; b=e7DJMau/gO45WPAaJduWYsNqlE+T8Oj3r/JgfR7E4qUe2Kb41cerPppukJM1lcfjL9nJUvb48+Qstz2Wq4MoIVCec7qdQHgA5z3HeODyO47toB9lAgjSAPYgZxjsQYxZE4BKDN2WCsaP9MR++J/Y1xtJc9xnRxMU1Qd2OiLYWrU= Authentication-Results: irif.fr; dkim=none (message not signed) header.d=none;irif.fr; dmarc=none action=none header.from=apnic.net; Received: from TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) by TYAPR04MB2429.apcprd04.prod.outlook.com (2603:1096:404:19::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Tue, 20 Oct 2020 16:36:48 +0000 Received: from TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::88bd:7d3f:b0e8:435a]) by TYAPR04MB2286.apcprd04.prod.outlook.com ([fe80::88bd:7d3f:b0e8:435a%7]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 16:36:48 +0000 Content-Type: text/plain; charset=utf-8 From: Geoff Huston In-Reply-To: <87v9f5vz8v.wl-jch@irif.fr> Date: Wed, 21 Oct 2020 03:36:42 +1100 Cc: Joe Abley , rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A4D5F57-4F4D-4DE3-BEC2-EB7118069CA2@apnic.net> References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> <87v9f5vz8v.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Originating-IP: [2001:44b8:110b:5100:e534:865:310b:fb5b] X-ClientProxiedBy: SYBPR01CA0173.ausprd01.prod.outlook.com (2603:10c6:10:52::17) To TYAPR04MB2286.apcprd04.prod.outlook.com (2603:1096:404:24::20) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:44b8:110b:5100:e534:865:310b:fb5b] (2001:44b8:110b:5100:e534:865:310b:fb5b) by SYBPR01CA0173.ausprd01.prod.outlook.com (2603:10c6:10:52::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Tue, 20 Oct 2020 16:36:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 33e3e57f-52fe-4723-d5be-08d875165701 X-MS-TrafficTypeDiagnostic: TYAPR04MB2429: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sqq4IOzsAkce9GwElNfITD3lRbLpOMaJMVg+SR8RLLXYel2GlRuOvZxWgTyHMoIU6wt7QymMY6xZXpKFlHMwg0u/Z8h42FhCTjWvjvJ5UzNsK8w4d9ixuV8sdMKYzoq+9LkFa+Ab81KmiwhR3UgQANX4Qmj1Ee6DYvyLFrT/V5yzxGFkDAvyQgJ1scUHGoLsWMO1U36ZOoC4GSRUWntb3/RRAbaib2D11+tnDwcpmsOU9iV2xHRXFrF6nSXhp/qnkoe1Zbk1t8nH9HsMNn0h9Dpg8pxKudzpQLnQU5E0Dt/Xbu0OJDK5weoFSC/q2WUG85mJeplK3viW0oPYUfdOvQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR04MB2286.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39830400003)(396003)(136003)(346002)(376002)(366004)(52116002)(8676002)(6666004)(4326008)(6486002)(186003)(16526019)(8936002)(2616005)(33656002)(83380400001)(478600001)(36756003)(86362001)(2906002)(66946007)(53546011)(5660300002)(6916009)(66476007)(66556008)(316002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: AXB9XuBx9T+8igsyvziKuGrDrZspaXwITv0Ri0vU77tQ2SqpF6LlaUzn4iStWp9HaDslEjhh1ID8sUx8BEbj3uTSOhJRZVsNtkvZf04SB6IjjNKVmXxxrYMLkXZTeGhQdUa6PTO2GR0KPqY4cqczJz+St2C3MqXFjVmPKkh2GMT32kxFJF0XshlY77bPDa4+YTGHCNAVIpHbSRWSyRr2b6w0bpj39xdUZiCmBowuKV5oLkdm/YIb6aEJJI5SKk1g30eCF9O8JXmF4ALMBQye+jE6UpANvh/qPqafeYl8N1l5OBVikOzHpWr/n2URSulq6x36ZKTAiNIRdU0DldQMuir8hxSVVOlhKkjcviA2oC5isNqqZ2BkHpoBgS0R2v5/b2FywXoOR27S2Ken2uhPiKwfOpkyvvx/EiNhFbJ5yx2kEAAGD/wEw5v0GMOMkEi0Kc0LcmVJ6epgywOdjU4sJIKLIL5qW6ltraIGIX+U90fmR0hP8LWAcN4PAtlso91Q4ITABfqxgxhlH89LQIBePUV+hneu/Ovwhf5XDXzq+PIAXH6EeL+WmcywveUe/foptN8xJUAcugUELY60lG34nAZEcNAJP2IKXctq2h8F0kQiejioK4+U4e6k1tXhqkLCvQsPdb4anPEKCSEX9DyIAzdpdDMnRJ8JJQhHOwnIU0hU/7Rg9Ue5d7eBjbkFMPmnQD0T1nLnVZ+6CByFROUu6A== X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: 33e3e57f-52fe-4723-d5be-08d875165701 X-MS-Exchange-CrossTenant-AuthSource: TYAPR04MB2286.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2020 16:36:48.3522 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XMwVahXFe9vvUuk7pJu0sRAcgympUSJ14sl+izzUU+KL4NAbbQmReTpdK8/M+cOc X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR04MB2429 Archived-At: Subject: Re: [babel] [Last-Call] RtgDir review: draft-ietf-babel-information-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, 20 Oct 2020 16:36:57 -0000 I=E2=80=99m was not raising an issue with the use of units of one tenth of = a second - I was expressing the thought that the term =E2=80=9Ccentisecond= =E2=80=9D is an unusual term in English, and as a native speaker I haver al= so followed a convention of using the units of =E2=80=9Ctenths of seconds= =E2=80=9D, =E2=80=9Chundredths of a second=E2=80=9D and then heading to mil= liseconds, nano seconds. Until now I had never seen the term =E2=80=9Ccenti= seconds=E2=80=9D and I would claim that I am familiar with scientific Engli= sh. Its as if I used terms such as furlongs, chains and perches in an RFC - yes= they are =3Dunits of measurement with a defined meaning but its not a comm= only used term and it would look strange. I have a similar reation of centi= second (and decisecond). But it's not my RFC and frankly I don't care all that much. The review temp= late wanted my nits with the document so I provided my nits. I think the st= ring nit is more critical than the one about the latin prefix for seconds. = Why define some intergers as unsigned 16 bit values yet leave strings of un= defined maximum length. Can I stuff a novel into the field? How about all o= f wikipedia? The point is why is the document inconsistent about its treatm= ent opf the range of acceptable values in terms of size? > On 20 Oct 2020, at 11:49 pm, Juliusz Chroboczek wrote: >=20 >>> "centiseconds"? Really? "tenths of seconds" would be clearer to most >>> readers! >=20 >> Perhaps this was intentional, but a centisecond is a hundredth of a seco= nd, >=20 > The wording is consistent with Section 4.1.2 of draft-ietf-babel-rfc6126b= is: >=20 > Relative times are carried as 16-bit values specifying a number of > centiseconds (hundredths of a second). >=20 > It then goes on to justify this somewhat unusual choice of units: >=20 > This allows times up to roughly 11 minutes with a granularity of 10ms, > which should cover all reasonable applications of Babel >=20 >> maybe spelling it out as you suggest is reasonable. >=20 > I agree, a parenthetical remark to define the unit would be helpful, > simlarly to what is done in rfc6126bis. >=20 > -- Juliusz From nobody Tue Oct 20 10:20:55 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D363A11BC; Tue, 20 Oct 2020 10:20:52 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 Sz6oz_U9rdLr; Tue, 20 Oct 2020 10:20:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5770E3A11BB; Tue, 20 Oct 2020 10:20:50 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09KHKdlk005626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2020 13:20:43 -0400 Date: Tue, 20 Oct 2020 10:20:38 -0700 From: Benjamin Kaduk To: Geoff Huston Cc: Juliusz Chroboczek , rtg-dir@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org, rtg-ads@ietf.org, last-call@ietf.org, Joe Abley Message-ID: <20201020172038.GN39170@kduck.mit.edu> References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> <87v9f5vz8v.wl-jch@irif.fr> <8A4D5F57-4F4D-4DE3-BEC2-EB7118069CA2@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8A4D5F57-4F4D-4DE3-BEC2-EB7118069CA2@apnic.net> Archived-At: Subject: Re: [babel] [Last-Call] RtgDir review: draft-ietf-babel-information-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, 20 Oct 2020 17:20:53 -0000 On Wed, Oct 21, 2020 at 03:36:42AM +1100, Geoff Huston wrote: > I’m was not raising an issue with the use of units of one tenth of a second - I was expressing the thought that the term “centisecond” is an unusual term in English, and as a native speaker I haver also followed a convention of using the units of “tenths of seconds”, “hundredths of a second” and then heading to milliseconds, nano seconds. Until now I had never seen the term “centiseconds” and I would claim that I am familiar with scientific English. For what little it's worth, I think I have pretty solid credentials for "familiarity with scientific English" (Ph.D. in Chemistry), and I find the deci- and centi- SI prefixes to be completely natural. It is perhaps interesting that deca- and hecto- are not so natural, which I might ascribe to the liter being a rather large volume on laboratory scales, so that centiliters and deciliters are often used. -Ben From nobody Tue Oct 20 11:10:13 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B703A1272; Tue, 20 Oct 2020 11:10:11 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <160321741182.20077.1775706618101177377@ietfa.amsl.com> Date: Tue, 20 Oct 2020 11:10:11 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-v4viav6-00.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, 20 Oct 2020 18:10:12 -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 : IPv4 routes with an IPv6 next-hop in the Babel routing protocol Authors : Theophile Bastian Juliusz Chroboczek Filename : draft-ietf-babel-v4viav6-00.txt Pages : 8 Date : 2020-10-20 Abstract: This document defines an extension to the Babel routing protocol that allows annoncing routes to an IPv4 prefix with an IPv6 next-hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-v4viav6-00 https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 20 12:34:23 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC113A0FDE for ; Tue, 20 Oct 2020 12:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 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, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=ens.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9KWPRbpSlSt for ; Tue, 20 Oct 2020 12:34:19 -0700 (PDT) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) (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 86C723A133F for ; Tue, 20 Oct 2020 12:34:19 -0700 (PDT) X-ENS-nef-client: 129.199.1.22 ( name = clipper-gw.ens.fr ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ens.fr; s=default; t=1603222457; bh=Vv1G4GHYrgdzazTzo/w+MiDUuVVqV25mikjqacKS8CU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZTE8V+MX/VUeKMIlUUtV8R/WR8d6kxygx/mB9igBEitNwQgNlaMWFHM5NGYTRs/kb pDCZn9CJaAlzUXPz25CGzLBba56pOHR95bX4o7Lsh0YA0MQ/pGIw9JXbS+nsREfiWD xuIH3uLRkyYC+DaL15PuVNICFIhgn4dBzDjQVdQk= Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 09KJYGKB018276 for ; Tue, 20 Oct 2020 21:34:17 +0200 Received: from [192.168.1.120] using smtps by clipper.ens.fr (8.14.4/jb-1.1) id 09KJYG49107640 for ; Tue, 20 Oct 2020 21:34:16 +0200 (authenticated user tbastian) X-ENS-Received: (82-65-169-4.subs.proxad.net [82.65.169.4]) X-Envelope-To: To: babel@ietf.org References: <160321741182.20077.1775706618101177377@ietfa.amsl.com> From: =?UTF-8?Q?Th=c3=a9ophile_Bastian?= Message-ID: <42028b97-c2ff-6a25-e8ac-c77129caac73@ens.fr> Date: Tue, 20 Oct 2020 21:34:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <160321741182.20077.1775706618101177377@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Tue, 20 Oct 2020 21:34:17 +0200 (CEST) Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-00.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, 20 Oct 2020 19:34:22 -0000 Hello everyone, > 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 : IPv4 routes with an IPv6 next-hop in the Babel routing protocol > Authors : Theophile Bastian > Juliusz Chroboczek > Filename : draft-ietf-babel-v4viav6-00.txt > Pages : 8 > Date : 2020-10-20 With much delay (sorry about this, I got caught in too many things at once), I uploaded `draft-ietf-babel-v4viav6-00` as discussed in IETF108, which replaces `draft-bastian-babel-v4ov6-NN`. In this submission, I only updated the submission name, slightly changed the title and the date. I will shortly begin to work on an updated version, which will — use "v4-via-v6" instead of "v4-over-v6" (thanks Barbara for the name, it is definitely better); — address the ICMPv4 issue (if a machine has no IPv4 address at all on any interface, it is unable to send ICMPv4 packet). Cheers, -- Théophile Bastian From nobody Tue Oct 20 13:14:46 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06D83A135D for ; Tue, 20 Oct 2020 13:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TkqTFRh0f3V2 for ; Tue, 20 Oct 2020 13:14:43 -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 CAB1E3A1356 for ; Tue, 20 Oct 2020 13:14:42 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 09KKEcAj000898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Oct 2020 22:14:38 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 09KKEcMD026553; Tue, 20 Oct 2020 22:14:38 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7D43226B69; Tue, 20 Oct 2020 22:14:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Pz8fZl34j9nq; Tue, 20 Oct 2020 22:14:32 +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 1334826B62; Tue, 20 Oct 2020 22:14:31 +0200 (CEST) Date: Tue, 20 Oct 2020 22:14:30 +0200 Message-ID: <873628wt7d.wl-jch@irif.fr> From: Juliusz Chroboczek To: =?ISO-8859-1?Q?Th=E9ophile?= Bastian Cc: babel@ietf.org In-Reply-To: <42028b97-c2ff-6a25-e8ac-c77129caac73@ens.fr> References: <160321741182.20077.1775706618101177377@ietfa.amsl.com> <42028b97-c2ff-6a25-e8ac-c77129caac73@ens.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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 20 Oct 2020 22:14:38 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 20 Oct 2020 22:14:38 +0200 (CEST) X-Miltered: at korolev with ID 5F8F452E.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F8F452E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F8F452E.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F8F452E.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 : 5F8F452E.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F8F452E.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-00.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, 20 Oct 2020 20:14:45 -0000 > — use "v4-via-v6" instead of "v4-over-v6" (thanks Barbara for the name, it > is definitely better); Margaret, I believe. -- Juliusz From nobody Tue Oct 20 13:16:07 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF7A3A135A; Tue, 20 Oct 2020 13:16:01 -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 8kB56eX9jmKL; Tue, 20 Oct 2020 13:15:59 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 CA8FD3A1356; Tue, 20 Oct 2020 13:15:59 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id o7so25871pgv.6; Tue, 20 Oct 2020 13:15: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=7sopEZgAElrZvNUVhvjrvtlMpOHi/8RqRd8mXHvxYLo=; b=DhstvAg/Uuk1U0Ewcsevk+HZLiCu9OrjMppNHwqKLX8Fv+TFDRc5V23xAtlySH1nJM XQQNIMkgcqBkRXJm9vyPPsgYmEledoJpeUi174zJTM/4GHopqLvMwcpv4FwuweIxd6n8 L9MQK3jYS4EBm+vi3YVX8Pqw+k36cBSx5NAMDB8RUjrc17M0bESmLUgQsYIZPbg0/oDG z9z6oJ+OoEnys3C7av1uZP0YMC8mQ9JJS2WB8WmHEHIk202cCPC5hKx7zdQt3KfMSSzh /NcxRfcAOD/Swp1xmc0L4bMCzTxFDTYHq/9y0Fp32qA7blSme60jBaxFE+LZJOt84s/Q hPiQ== 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=7sopEZgAElrZvNUVhvjrvtlMpOHi/8RqRd8mXHvxYLo=; b=jZv2xZrGFk6c9kT9OE8GfLwS5QMSJCCSGiHGGEY+VyigjCOpz3dNGr11jBbUnOQb46 rlL4QL2kHybbsh8g24LSZx9sIk2mEdyz09xk7xayXm+AGSpLCGbjRH46E4QXo8+JOYDV ++oUkMfa9tuSH1+Qm1cdG5I2UXizf7OQF6kkhpBVYmQn7N+mBPn4t/oLt1SvJnK7CpRS BxYRqXzjFsJ6EqZbKPhK1oJXMj5mEz5eDjFPJ01kl2OLJ39dAeUdodVCX9JIylXHQpSG Rz4JkQ8pPOe5ttxreGsfg8dvlysj6Z8MPrJptiUzxA/bYwTfxOREpvXXaGEn+So0HcFQ QiLA== X-Gm-Message-State: AOAM533meSc+DHElPKwIbBfXJceuBudWBEPBxKPBweiYzx6i1ZTekz5O MDaXrFmoSuaJG62Vb/q6Dfs= X-Google-Smtp-Source: ABdhPJzvc0/H+UpSNU8DbkWO2gAIC3tFNQZSv6q1xb0BwXE3ANxZ3mRJYOyB6eE5DZaXTBpSPm/H4Q== X-Received: by 2002:a63:210d:: with SMTP id h13mr57293pgh.280.1603224959272; Tue, 20 Oct 2020 13:15:59 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:8843:8d02:a04f:df46? ([2601:647:5600:5020:8843:8d02:a04f:df46]) by smtp.gmail.com with ESMTPSA id bj17sm41720pjb.15.2020.10.20.13.15.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 13:15:57 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <353238C9-012E-4426-B8AD-41B28510D019@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E0F960E7-6A5F-4026-A829-5D07D202CAD3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 20 Oct 2020 13:15:56 -0700 In-Reply-To: <8A4D5F57-4F4D-4DE3-BEC2-EB7118069CA2@apnic.net> Cc: Juliusz Chroboczek , Joe Abley , rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org, last-call@ietf.org To: Geoff Huston References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> <87v9f5vz8v.wl-jch@irif.fr> <8A4D5F57-4F4D-4DE3-BEC2-EB7118069CA2@apnic.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [babel] [Last-Call] RtgDir review: draft-ietf-babel-information-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, 20 Oct 2020 20:16:01 -0000 --Apple-Mail=_E0F960E7-6A5F-4026-A829-5D07D202CAD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Geoff, Appreciate your review and pointing out the nits as you see them. > On Oct 20, 2020, at 9:36 AM, Geoff Huston wrote: >=20 > Why define some intergers as unsigned 16 bit values yet leave strings = of undefined maximum length. Can I stuff a novel into the field? How = about all of wikipedia? The point is why is the document inconsistent = about its treatment opf the range of acceptable values in terms of size? The reason some variables have fixed length by virtue of the fact that = they are unsigned int or unsigned short is because we have a better = sense of what the range of those values are. For example, you do not = want the babel-mcast-hello-interval to be more than 32 bit long. The = same is not true for something like babel-interface-metric-algorithm, = which is a name. While we could artificially limit the string value to = say 40 characters, what is to say that someone cannot come up with a = name that is 41 characters long. Implementations of this information model, whether they are YANG data = model or some other modeling language can choose to further restrict the = size of the string. But even there, I have seen YANG models deferring it = to particular implementations to refine the definition by adding a size = attribute to the node. At an information model level we are poor judges = of what size string is ok for any given variable. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E0F960E7-6A5F-4026-A829-5D07D202CAD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Geoff,

Appreciate = your review and pointing out the nits as you see them.

On Oct 20, 2020, at 9:36 AM, Geoff Huston <gih@apnic.net> = wrote:

Why define some intergers as = unsigned 16 bit values yet leave strings of undefined maximum length. = Can I stuff a novel into the field? How about all of wikipedia? The = point is why is the document inconsistent about its treatment opf the = range of acceptable values in terms of = size?

The reason some = variables have fixed length by virtue of the fact that they are unsigned = int or unsigned short is because we have a better sense of what the = range of those values are. For example, you do not want the = babel-mcast-hello-interval to be more than 32 bit long. The same is not = true for something like babel-interface-metric-algorithm, which is a = name. While we could artificially limit the string value to say 40 = characters, what is to say that someone cannot come up with a name that = is 41 characters long.

Implementations= of this information model, whether they are YANG data model or some = other modeling language can choose to further restrict the size of the = string. But even there, I have seen YANG models deferring it to = particular implementations to refine the definition by adding a size = attribute to the node. At an information model level we are poor judges = of what size string is ok for any given variable.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_E0F960E7-6A5F-4026-A829-5D07D202CAD3-- From nobody Tue Oct 20 13:29:27 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CE23A0975; Tue, 20 Oct 2020 13:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TdvsuXSenFSO; Tue, 20 Oct 2020 13:29:23 -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 420E53A0967; Tue, 20 Oct 2020 13:29:22 -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 09KKTFI5004918; Tue, 20 Oct 2020 22:29:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E5E0F26D16; Tue, 20 Oct 2020 22:29:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QwHiYGRbMGA8; Tue, 20 Oct 2020 22:29:14 +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 1CE8926D12; Tue, 20 Oct 2020 22:29:14 +0200 (CEST) Date: Tue, 20 Oct 2020 22:29:13 +0200 Message-ID: <871rhswsiu.wl-jch@irif.fr> From: Juliusz Chroboczek To: Geoff Huston Cc: Joe Abley , rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org, last-call@ietf.org In-Reply-To: <8A4D5F57-4F4D-4DE3-BEC2-EB7118069CA2@apnic.net> References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> <87v9f5vz8v.wl-jch@irif.fr> <8A4D5F57-4F4D-4DE3-BEC2-EB7118069CA2@apnic.net> 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]); Tue, 20 Oct 2020 22:29:15 +0200 (CEST) X-Miltered: at korolev with ID 5F8F489B.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F8F489B.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5F8F489B.003 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] [Last-Call] RtgDir review: draft-ietf-babel-information-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, 20 Oct 2020 20:29:26 -0000 > Why define some intergers as unsigned 16 bit values yet leave strings of > undefined maximum length. Can I stuff a novel into the field? How about > all of wikipedia? The point is why is the document inconsistent about > its treatment opf the range of acceptable values in terms of size? Right. You may have a point. The information model consistently limits integer values to the range supported by the protocol -- e.g. where the protocol uses a 16-bit unsigned field to carry a value, the information model specifies that the value must not exceed 65535. The string values, on the other hand, are not carried by the protocol -- they are strictly the private business of the management interface. Their size is only limited by a particular management interface, and whatever protocols are used to carry the configuration data (e.g. whether your XML parser is able to carry the full text of War and Peace within an attribute value). So where should their size be limited? In the information model? In the YANG document? In the release notes of a particular implementation of the YANG model? All of the above? -- Juliusz From nobody Thu Oct 22 01:53:37 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE523A0EF0; Thu, 22 Oct 2020 01:53:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even via Datatracker To: Cc: babel@ietf.org, draft-ietf-babel-information-model.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160335680561.31770.717841242125658048@ietfa.amsl.com> Reply-To: Roni Even Date: Thu, 22 Oct 2020 01:53:25 -0700 Archived-At: Subject: [babel] Genart last call review of draft-ietf-babel-information-model-11 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, 22 Oct 2020 08:53:27 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-babel-information-model-?? Reviewer: Roni Even Review Date: 2020-10-22 IETF LC End Date: 2020-10-27 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as informational RFC Major issues: Minor issues: Nits/editorial comments: From nobody Fri Oct 23 14:17:10 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D48643A1056; Fri, 23 Oct 2020 14:15:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: babel@ietf.org, martin.vigoureux@nokia.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774685.5087.9008756521484640787@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:46 -0700 Archived-At: Subject: [babel] babel - Requested session has been scheduled for IETF 109 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: Fri, 23 Oct 2020 21:15:50 -0000 Dear Donald Eastlake, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. babel Session 1 (1:00 requested) Tuesday, 17 November 2020, Session II 1430-1530 Room Name: Room 5 size: 505 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/babel.ics Request Information: --------------------------------------------------------- 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: 20 Conflicts to Avoid: Chair Conflict: bess idr rtgwg dnsop Technology Overlap: homenet manet rtgarea lpwan Key Participant Conflict: netconf netmod People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 24 02:20:35 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1B3A00C4; Sat, 24 Oct 2020 02:20:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: last-call@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160353123448.4709.4647332742303591712@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Sat, 24 Oct 2020 02:20:34 -0700 Archived-At: Subject: [babel] Genart last call review of draft-ietf-babel-source-specific-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 09:20:35 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-babel-source-specific-06 Reviewer: Dan Romascanu Review Date: 2020-10-24 IETF LC End Date: 2020-10-27 IESG Telechat date: Not scheduled for a telechat Summary: Ready. This document describes an extension for source-specific routing (also known as Source-Address Dependent Routing, SADR) to the Babel routing protocol. It's a well written, clear and complete document. Major issues: Minor issues: Nits/editorial comments: From nobody Sat Oct 24 02:24:18 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FBE3A0115; Sat, 24 Oct 2020 02:24:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: last-call@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160353145725.25780.13209881668449255473@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Sat, 24 Oct 2020 02:24:17 -0700 Archived-At: Subject: [babel] Opsdir last call review of draft-ietf-babel-source-specific-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 09:24:17 -0000 Reviewer: Dan Romascanu Review result: Ready Ready. This document describes an extension for source-specific routing (also known as Source-Address Dependent Routing, SADR) to the Babel routing protocol. It's a well written, clear and complete document. >From an operational point of view, operators should pay special attention to section 6 - Compatibility to the base protocol: > The protocol extension defined in this document is, to a great extent, interoperable with the base protocol defined in [BABEL] (and all previously standardised extensions). More precisely, if non- source-specific routers and source-specific routers are mixed in a single routing domain, Babel's loop-avoidance properties are preserved, and, in particular, no persistent routing loops will occur. > However, this extension is encoded using mandatory sub-TLVs, introduced in [BABEL], and therefore is not compatible with the older version of the Babel Routing Protocol [RFC6126] which does not support such sub-TLVs. Consequently, this extension MUST NOT be used with routers implementing RFC 6126, otherwise persistent routing loops may occur. There are no manageability considerations in this document. I assume that management actions and objects, if relevant, will be included in complementary documents. From nobody Sun Oct 25 10:35:16 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9783A0B98; Sun, 25 Oct 2020 10:35:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: draft-ietf-babel-source-specific.all@ietf.org, last-call@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160364731499.17476.11455568556595523172@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Sun, 25 Oct 2020 10:35:15 -0700 Archived-At: Subject: [babel] Secdir last call review of draft-ietf-babel-source-specific-06 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: Sun, 25 Oct 2020 17:35:15 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Has Nits Section 7, Second Paragraph: “A node MUST NOT send more that one Source Prefix sub-TLV in a TLV, and a node receiving more than one Source Prefix sub-TLV in a single TLV SHOULD ignore this TLV. It MAY ignore the whole packet.” 1. “That” -> “Than” 2. This paragraph implies that a node might accept the TLV with more than one Source Prefix sub-TLV, but it does not state when a node can do that. You might want to elaborate on the conditions that a node is allowed to do that. Otherwise, the security considerations section seems reasonable and addresses the issues that might arise because of the added flexibility of the source prefix. Regards, Rifaat From nobody Sun Oct 25 18:45:31 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F327E3A179B; Sun, 25 Oct 2020 18:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.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, 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 I0V86WsSLJ4y; Sun, 25 Oct 2020 18:45:27 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 97D323A1798; Sun, 25 Oct 2020 18:45:27 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id p15so8428750ioh.0; Sun, 25 Oct 2020 18:45:27 -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=NSkL7CC1EOiFDQ7eMzAvm2puzb7kZJFPGtGZRLVz7uI=; b=ivv1Ls9hVf/1mxDNwcuednpU7PfjfpiKMS/meNfDI0KBdnx8xWhH/mS1nmI2yQGCmB J/C7K/C1NZRIvpUlN51B7gZlUzQ4zMduF+TtmiKrHt9GFBJIAH3FUITcqiGf6hCYn7NG Xc1/Qlqt7Pgxqh1oTf2llvWyX1DW0Q3kmS/bO6tUjeQNF8CpRAN+DMkSaJPnPCwPD8JZ mi59+QwPzaQsR9BQ5TKpSs3fnBTU1/7NqRSEK3wtQzlOHJd1xjLQWzNFEGyZQ42aibIS lcQIAyBw3xHIXFjQBk0+kuGKHDHlzJqKGp5mlEo97qfGHBwykGleHsnj/N+PlcQhsHpr IYfQ== 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=NSkL7CC1EOiFDQ7eMzAvm2puzb7kZJFPGtGZRLVz7uI=; b=t4nnpr1pspw+vWLJ3SeorZBoQvvCg7Pqo+Az9craMyT/uD4gMifq6dT8VYa+nOFL+3 JhRoXCk4xi2fsiR7sHGLGRHielaO3AKrkOExP/6NvsSGNGA5voLNOG5Fx4R5G0eNBpHU Lejs8uyuVXZDeANPRk+GBlLtnuziz6Q8KHrfV0903T5huyU57KGGq7LR/8i8U9LKEvhU rn8OVHGqwhO1W7j029iXC24cEVa92HYtm/fFGItsq1ZAEqg9TUkf7e50RJRYIyrAt6VL bernUJDE2HpyHIDz9NQOA3GFd1M8L3hNCLOH5UbvLD5rm7PwatTouFenUqLp6iZdmwk9 1FZQ== X-Gm-Message-State: AOAM533Q8g8L1weWKPeVbUSr2QJZkekjABf1Roz4PcDmO2rH0AiwQ/fv AsIJYblHMIbsWTM9tin66aZUzz8LRJ2I+IVEegk= X-Google-Smtp-Source: ABdhPJxSpdCN1DjvqEgMv0MD/kkYSc4j/IbR9ydrThMJ59I7XMZx+04hofhDrcjnWyIi/duKjAE7ONOhutpI+hMgwvw= X-Received: by 2002:a05:6602:2d8c:: with SMTP id k12mr3027514iow.46.1603676726692; Sun, 25 Oct 2020 18:45:26 -0700 (PDT) MIME-Version: 1.0 References: <87zh4mi6e2.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Sun, 25 Oct 2020 21:45:15 -0400 Message-ID: To: Juliusz Chroboczek , Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] [Babel-users] IETF-109 online 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, 26 Oct 2020 01:45:29 -0000 Hi, The upcoming IETF meeting schedule is now "final" although it is always possible it could change. In any case the day and time of the possible BABEL WG meeting has been confirmed as shown below. However, there are currently no presentations scheduled. If that is still the case by 2 November, I plan to cancel the meeting. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Sat, Oct 17, 2020 at 11:44 PM Donald Eastlake wrote: > > Hi Juliusz, > > Thanks for your message below. > > The Babel WG meeting has been tentatively scheduled for > UTC: Tuesday November 17th 07:30 to 08:30 > Bangkok time: Tuesday November 17th 14:30 to 15:30 > > However, at this point no one has requested to present and if there > aren't any requests in the next couple of weeks, the meeting will be > cancelled. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > On Fri, Oct 16, 2020 at 10:37 AM Juliusz Chroboczek wrote: > > > > Dear all, > > > > IETF-109 will be held online from 16 to 20 November. There might or might > > not be a Babel meeting. > > > > They appear to have listened to our complaints, and requesting a fee > > waiver no longer requires slaughtering an immaculate goat over your > > keyboard. In order to participate for free, you need to: > > > > 1. Open an account on the IETF datatracker (unless you already have one): > > > > https://datatracker.ietf.org/accounts/create/ > > > > 2. Submit a waiver request on: > > > > https://www.ietf.org/forms/109-registration-fee-waiver/ > > > > I don't know how busy the secretariat is, but just in case, I would > > recommend doing that earlier rather than later. > > > > Regards, > > > > -- Juliusz > > > > _______________________________________________ > > Babel-users mailing list > > Babel-users@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users From nobody Mon Oct 26 05:26:20 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FF93A0962; Mon, 26 Oct 2020 05:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2GMaAiXjMKRe; Mon, 26 Oct 2020 05:26:17 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571573A0949; Mon, 26 Oct 2020 05:26:16 -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 09QCQEDH009581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Oct 2020 13:26:14 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 09QCQEcn012524; Mon, 26 Oct 2020 13:26:14 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 2677D108003; Mon, 26 Oct 2020 13:26:14 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id R_5IzU8Twd8i; Mon, 26 Oct 2020 13:26:12 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 96BAB108001; Mon, 26 Oct 2020 13:26:09 +0100 (CET) Date: Mon, 26 Oct 2020 13:26:09 +0100 Message-ID: <875z6xyxzy.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs , babel-users@lists.alioth.debian.org In-Reply-To: References: <87zh4mi6e2.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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 26 Oct 2020 13:26:14 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 26 Oct 2020 13:26:14 +0100 (CET) X-Miltered: at korolev with ID 5F96C066.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5F96C066.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F96C066.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5F96C066.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 : 5F96C066.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5F96C066.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] [Babel-users] IETF-109 online 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, 26 Oct 2020 12:26:19 -0000 Added babel-users to CC. > However, there are currently no presentations scheduled. If that is > still the case by 2 November, I plan to cancel the meeting. I think that's the right thing to do. The only important drafts that are not currently in the hands of either the IESG or the RFC Editor are RTT and 4via6, and we have nothing new to say on either subject. (I've got shell shock after one year of bullying by the IESG, so I'm not willing to push RTT right now; as to 4via6, it is not ready, see point (γ) below.) I believe that we've done all that was needed as far as specifications are concerned, the current priorities are implementation and research: α. get HMAC into babeld and BIRD mainline; β. decide whether to update FRR to comply with 6126bis, or to remove Babel from FRR (FRR Babel has no maintainer); γ. redo the experiments with 4via6 with ICMP in mind, write a paper or a technical report on the subject; δ. update the 4via6 draft once we've reached a conclusion. I suggest discussion of these should happen on babel-users rather than babel@ietf. — Juliusz From nobody Mon Oct 26 07:01:59 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62983A0B7E; Mon, 26 Oct 2020 07:01:52 -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, 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 6R2K0NTDgRXC; Mon, 26 Oct 2020 07:01:51 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 B61393A0B83; Mon, 26 Oct 2020 07:01:50 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id n18so12704671wrs.5; Mon, 26 Oct 2020 07:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Fc2x8ry9KJfE9ldsu9GUOMGCiY4+B68oCN02wnZzT/g=; b=q5f+oA5ZEGwp8Q0isN1h0QLsw9OIyoci71yrZX5JIOOyLPG6wKem/pg+DS2pbD2mzv /H5FNzk1+lbqlzqYHL45jme1VSfz1vidisyzUEWVXvz89ChU8V5N1/OakHjCgLgt4UrC cIWPR3tJIZaFJXCCAf+Wpq43fKJbNV9e583tZVTC1gwrNuzlYX/KyRExFI3pyXQjM2vs wjDEQhQQRlOv8bxCSRY1K0MCTxkLHSXwsA/ppdo+i8EpQUYGSgcL+FAeQO64WAJsQhpR IB23jvvDQ7H8B4ax5L/O4MXGiZVtZOepNz2K/gWKBv6l9pQCS8UWNZRpNDBn2+Tdp5TL xKfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Fc2x8ry9KJfE9ldsu9GUOMGCiY4+B68oCN02wnZzT/g=; b=lgHs534lpZZIvRRH4DYnRsjB7i2Tutqgcu+VJVGhhqcj6HZVNtc0csCabwX7aiDWNh BUbCBxj7T5JcWlzvkmK9jefLYLctaLIvfRIKTVQNKBSMG48cxanvKqE/ueppS7BTXRQD JTluzR3fZ2+vV+aMH8ffLKty892prD3LPCVcwSY3QQnJCLWDxtT0CjXkr7A/ER6oEvIc MTf9fyVJRomebSbQISNs9JL3X4SdfcfVPtnzfZTtsPaP5odZ6vYhy5cIovFBkYcv+fWI 9zWAzSh5CoWr2kd/qqr0bS5d4c87QBV0p957UqZaFrWhPG2OJR0C6bs563zn5ls4s3WZ HInA== X-Gm-Message-State: AOAM532t+383UJGjM6ROPiF1m2Z2pLoUCfr5QtJvlkd3npookww3GKRL WopJ7O0Yxew4p89zRI6aqprJ1EwEjKk= X-Google-Smtp-Source: ABdhPJy8OJqmbeRLu0w1EwMfTvkuIUnFqcq+dO57ouBdbzDHTxPNVeUeuwsd9KODNlCArC/EtxyeNg== X-Received: by 2002:adf:bb07:: with SMTP id r7mr19148499wrg.150.1603720909003; Mon, 26 Oct 2020 07:01:49 -0700 (PDT) Received: from kobain.localdomain (243.2.26.109.rev.sfr.net. [109.26.2.243]) by smtp.gmail.com with ESMTPSA id a3sm20795181wmb.46.2020.10.26.07.01.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Oct 2020 07:01:48 -0700 (PDT) From: =?UTF-8?q?Antonin=20D=C3=A9cimo?= To: last-call@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org Date: Mon, 26 Oct 2020 15:01:47 +0100 Message-Id: <20201026140147.19834-1-antonin.decimo@gmail.com> X-Mailer: git-send-email 2.29.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] Last Call: , naming inconsistencies 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, 26 Oct 2020 14:01:53 -0000 --- Dear all, I=E2=80=99ve found some inconsistencies in the naming of some fields in the Babel Information Model. I=E2=80=99ve already send mails about them; but I= =E2=80=99m afraid my mails might have fallen in limbo. The issue is minor. Below is a patch for the fields. Best regards, Antonin draft-ietf-babel-information-model.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-babel-information-model.md b/draft-ietf-babel-infor= mation-model.md index 7990b7a..1588797 100644 --- a/draft-ietf-babel-information-model.md +++ b/draft-ietf-babel-information-model.md @@ -179,8 +179,8 @@ The Information Model is hierarchically structured as f= ollows: +-- babel-information=0D +-- babel-implementation-version=0D +-- babel-enable=0D - +-- router-id=0D - +-- self-seqno=0D + +-- babel-self-router-id=0D + +-- babel-self-seqno=0D +-- babel-metric-comp-algorithms=0D +-- babel-security-supported=0D +-- babel-mac-algorithms=0D @@ -534,7 +534,7 @@ babel-mac-enable: An implementation MAY choose=0D to expose this parameter as read-only ("ro").=0D =0D -babel-if-mac-keys-sets:=0D +babel-if-mac-key-sets:=0D : List of references to the babel-mac entries that apply to this=0D interface. When an interface instance is created, all babel-mac-key-sets= =0D instances with babel-mac-default-apply "true" will be included=0D @@ -828,7 +828,7 @@ babel-mac-default-apply: applied to all new babel-interface instances, by default.=0D If "true", this instance is applied to=0D new babel-interfaces instances at the time they are created, by includin= g=0D - it in the babel-interface-mac-keys list.=0D + it in the babel-if-mac-key-sets list.=0D If "false", this instance is not applied to new babel-interfaces=0D instances when they are created.=0D An implementation MAY choose=0D --=20 2.29.1 From nobody Mon Oct 26 07:54:46 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA63A0C06; Mon, 26 Oct 2020 07:54:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: last-call@ietf.org, babel@ietf.org, draft-ietf-babel-information-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160372407981.20077.17795340180313190981@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Mon, 26 Oct 2020 07:54:39 -0700 Archived-At: Subject: [babel] Secdir last call review of draft-ietf-babel-information-model-11 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: Mon, 26 Oct 2020 14:54:40 -0000 Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines an informational model for Babel routing protocol. This informational model can be used as a basis for creating various data models (e.g. YANG). The document is properly structured and well written, however I think that it has some issues concerned with security. Issues. 1. Section 3.1: babel-mac-algorithms: List of supported MAC computation algorithms. Possible values include "HMAC-SHA256", "BLAKE2s". BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the desired size of the MAC is a parameter for it. Where the size of MAC is specified? For HMAC with SHA256 I can at least imagine that full 256 bits output is used as a MAC... 2. Section 3.9: babel-cert-test: An operation that allows a hash of the provided input string to be created using the certificate public key and the SHA-256 hash algorithm. Input to this operation is a binary string. The output of this operation is the resulting hash, as a binary string. I failed to understand what this operation should do. Literally reading it is intended to produce SHA2-256 hash of public key and some arbitrary string (concatenated? in what order?). But then I failed to understand the purpose of this test. I would have understood if this operation provides signing of the arbitrary string using private key and SHA2-256 as a hash function (similarly to babel-mac-key-test), but it in not what is written... 3. Section 5 (Security Considerations): I think that text about keys (their length and properties) needs some expansion. First, there are no any RFC2119 words discouraging using short and weak keys (there is some text, but without RFC2119 words and with no references it's just hand waving). Note, that draft-ietf-babel-hmac-12 has some text about the properties of the keys, so I believe at least it must be referenced here. I also suspect that explicitly allowing zero-length and short keys will lead to situations when some network operators will use them (because they are not prohibited), thus subverting security properties of MAC... Nits. 1. Section 1 (Introduction): [I-D.ietf-babel-hmac] defines a security mechanism that allows Babel packets to be cryptographically authenticated, and [I-D.ietf-babel-dtls] defines a security mechanism that allows Babel packets to be encrypted. DTLS provides both confidentiality and authentication of data, so to be formally correct, please add "both authenticated and" before "encrypted". 2. Section 2 (Overview) at the very end: Note that this overview is intended simply to be informative and is not normative. If there is any discrepancy between this overview and the detailed information model definitions in subsequent sections, the error is in this overview. This phrase makes me puzzled. The tree-like description of the information model in the Overview is very useful, however this phrase seems to discourage using it, because authors are not sure it is correct. I think it would be better for readers if authors double check that no discrepancy exists between the overview and the subsequent detailed description and remove this phrase. 3. Section 3.3: babel-mac-verify A Boolean flag indicating whether MAC hashes in incoming Babel packets are required to be present and are verified. If this parameter is "true", incoming packets are required to have a valid MAC hash. An implementation MAY choose to expose this parameter as read-only ("ro"). "MAC hashes" is strange wording, "MAC values" or just "MACs" are better in my opinion. 4. Section 3.8: babel-mac-key-use-sign: Indicates whether this key value is used to sign sent Babel packets. Sent packets are signed using this key if the value is "true". If the value is "false", this key is not used to sign sent Babel packets. An implementation MAY choose to expose this parameter as read-only ("ro"). "Sign" is not a good word when you describe symmetric key operations (which computing MAC belongs to). Although it is often used informally, I think that RFC should be more meticulous in selecting words. I'd rather replace it with "compute MAC" and rename the entry to babel-mac-key-use-compute or babel-mac-key-use-mac (if it is possible). Note, that using "verify MAC" is OK. 5. Section 3.8: babel-mac-key-value: ... This value is of a length suitable for the associated babel-mac-key- algorithm. If the algorithm is based on the HMAC construction [RFC2104], the length MUST be between 0 and the block size of the underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes inclusive, as described in [RFC7693]. I wonder of the rationale for imposing the above restrictions on HMAC key length. HMAC can use keys of any length, but if the key is greater than block size of underlying hash function, then it's first hashed (small performance penalty). So I imagine that the rationale is to avoid this penalty. However, as RFC2104 states, key sizes greater than output length of the underlying hash function (32 bytes in case of SHA2-256) would not significantly increase the function strength, so it's just a waste of space. See also Issue 3 above. 6. Section 3.8: babel-mac-key-test: An operation that allows the MAC key and hash algorithm to be tested to see if they produce an expected outcome. Input to this operation is a binary string. The implementation is expected to create a hash of this string using the babel-mac-key- value and the babel-mac-key-algorithm. The output of this operation is the resulting hash, as a binary string. The text mixes up words "hash" and "MAC". MAC is not a hash (even if MAC algorithm is often based on hash function). As with my previous grunt, I'd like RFC to be more meticulous in selecting words. Please, avoid using "hash" here. 7. Section 5 (Security Considerations): ... This model requires that private keys never be exposed. The Babel security mechanisms that make use of these credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac]) identify what credentials can be used with those mechanisms. Please add "and MAC keys" after "private keys" since formally private keys are only defined for public key cryptography. 8. Section 5 (Security Considerations): MAC keys are allowed to be as short as zero-length. This is useful for testing. I wonder what's benefit of allowing zero-length keys for testing purposes. What is intended to be tested in this case? Implementation of MAC? Is it really needed outside test lab? Am I missing something? 9. Section 5 (Security Considerations): Short (and zero-length) keys and keys that make use of only alphanumeric characters are highly susceptible to brute force attacks. Formally, brute force attack with zero-length keys is not defined, since there is no key to find and all is in clear. Comments. 1. The document contains an entry in the Informational model defining which hash functions can be used with HMAC authentication. However, there is no corresponding entry of which ciphersuites can be used with DTLS. Is it up to DTLS library to select ciphersuites? From nobody Mon Oct 26 08:46:52 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4C3A0C70; Mon, 26 Oct 2020 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LjNIhgl_Zp6b; Mon, 26 Oct 2020 08:46:49 -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 D0CCB3A0D90; Mon, 26 Oct 2020 08:46:32 -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 09QFkSAf022467; Mon, 26 Oct 2020 16:46:28 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D716010B82D; Mon, 26 Oct 2020 16:46:28 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id dnfT-Q_CSl3X; Mon, 26 Oct 2020 16:46:22 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3E7DF10B82A; Mon, 26 Oct 2020 16:46:18 +0100 (CET) Date: Mon, 26 Oct 2020 16:46:18 +0100 Message-ID: <871rhlyoqd.wl-jch@irif.fr> From: Juliusz Chroboczek To: Valery Smyslov Cc: , last-call@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org In-Reply-To: <160372407981.20077.17795340180313190981@ietfa.amsl.com> References: <160372407981.20077.17795340180313190981@ietfa.amsl.com> 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, 26 Oct 2020 16:46:29 +0100 (CET) X-Miltered: at korolev with ID 5F96EF54.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F96EF54.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5F96EF54.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Secdir last call review of draft-ietf-babel-information-model-11 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, 26 Oct 2020 15:46:51 -0000 > babel-mac-algorithms: List of supported MAC computation algorithms. > Possible values include "HMAC-SHA256", "BLAKE2s". > BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the desired > size of the MAC is a parameter for it. Where the size of MAC is specified? For > HMAC with SHA256 I can at least imagine that full 256 bits output is used as a > MAC... Right. The intent is that Blake2s is used with 32-octet keys and 16-octet hashes (collision-resistance is not a concern for Babel-MAC while dictionary attacks are). Barbara, I think that you should explicitly state that Blake2s implies 128-bit hashes. (You may also consider renaming BLAKE2s to BLAKE2s-128.) > babel-mac-key-value: > I wonder of the rationale for imposing the above restrictions on HMAC key > length. HMAC can use keys of any length, but if the key is greater than block > size of underlying hash function, then it's first hashed (small performance > penalty). So I imagine that the rationale is to avoid this penalty. This was discussed at length on the mailing list. It's not about performance, it's about making it more difficult to use an unsafe procedure for generating keys. Since Babel-MAC is vulnerable to dictionary attacks, the key must either be drawn randomly or generated using a procedure that is hardened against such attacks (scrypt, etc.). Applying the procedure described in RFC 2104 to a user-provided passphrase is not safe, and therefore we try to make it difficult for a naive user to do so. I am opposed to putting the RFC 2104 hashing procedure in the information model. Doing so would be a disservice to our users. > Short (and zero-length) keys and keys that make use of only > alphanumeric characters are highly susceptible to brute force > attacks. > Formally, brute force attack with zero-length keys is not defined, since there > is no key to find and all is in clear. The key length is not carried in the clear by the protocol. Guessing the key length requires a brute-force attack, even when it is zero. > 1. The document contains an entry in the Informational model defining which > hash functions can be used with HMAC authentication. However, there is no > corresponding entry of which ciphersuites can be used with DTLS. Is it up to > DTLS library to select ciphersuites? Yes. Babel-DTLS is intended to inherit the security properties of the system's DTLS library. If the DTLS library is unsafe, then Babel-DTLS must not be used until the library is fixed. -- Juliusz From nobody Tue Oct 27 09:07:07 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1C73A0FEC; Tue, 27 Oct 2020 09:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 oDY2C6Vhk5oq; Tue, 27 Oct 2020 09:07:00 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2AA013A0FF0; Tue, 27 Oct 2020 09:07:00 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CEFE7B3ED385C6BCC06D; Tue, 27 Oct 2020 16:06:58 +0000 (GMT) Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 16:06:58 +0000 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 28 Oct 2020 00:06:55 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Wed, 28 Oct 2020 00:06:56 +0800 From: "Hejia (Jia)" To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-babel-source-specific.all@ietf.org" , "babel@ietf.org" Thread-Topic: RtgDir Last Call Review: draft-ietf-babel-source-specific-06 Thread-Index: AQHWrHVK/hFINaWsq0uISbw5qfgprw== Date: Tue, 27 Oct 2020 16:06:56 +0000 Message-ID: <38f2e15c65ed40628afe70f73822d1ec@huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.104.35] Content-Type: multipart/alternative; boundary="_000_38f2e15c65ed40628afe70f73822d1echuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [babel] RtgDir Last Call Review: draft-ietf-babel-source-specific-06 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, 27 Oct 2020 16:07:02 -0000 --_000_38f2e15c65ed40628afe70f73822d1echuaweicom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-babel-source-specific-06.txt Reviewer: Jia He Review Date: Oct. 27, 2020 IETF LC End Date: date-if-known Intended Status: Standards Track Summary: This document is basically ready for publication, but I have one minor conc= ern that I think should be considered before publication. Comments: The draft is clearly writtern and easy to understand. It describes the exte= nsions to the Babel routing protocol to support source-specific routing. Major Issues: No major issues found. Minor Issues: In Paragraph 5, it is written as "In the original protocol, three TLVs carry a destination prefix: Updates, Route Requests and Seqno Requests. This specification extends these messages to optionally carry a Source Prefix sub-TLV, as described in Section 7 below. The sub-TLV is marked as mandatory, so that an unextended implementation will silently ignore the whole enclosing TLV. " I understand the the Source Prefix sub-TLV is mandatory to support the func= tions defined in this specification. However, "optionally" used in the par= agraph above is confusing. One suggestion is to simply delete "optionally" = in the sentence. B.R. Jia --_000_38f2e15c65ed40628afe70f73822d1echuaweicom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected as the Routing Directorate reviewer for = this draft. The Routing Directorate seeks to review all routing or routing-= related drafts as they pass through IETF last call and IESG review, and som= etimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more inform= ation about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Rout= ing ADs, it would be helpful if you could consider them along with any othe= r IETF Last Call comments that you receive, and strive to resolve them thro= ugh discussion or by updating the draft. 


Document: draft-ietf-babel-source-specific-06.tx= t
Reviewer: Jia He 
Review Date: Oct. 27, 2020
IETF LC End Date: date-if-known
Intended Status: Standards Track


Summary: 

This document is basically ready for publication, but I have = one minor concern that I think should be considered before publication.

Comments: 

The draft is clearly writtern and easy to understand. It desc= ribes the extensions to the Babel routing protocol to support source-specif= ic routing.


Major Issues: 

No major issues found.

Minor Issues: 

In Paragraph 5, it is written as 

"In the original protocol, three TLVs carry a destination prefix:
   Updates, Route Requests and Seqno Requests.  This specifi= cation
   extends these messages to optionally carry a Source Prefix sub-TLV,
   as described in Section 7 below.  The sub-TLV is marked a= s mandatory,
   so that an unextended implementation will silently ignore the = whole
   enclosing TLV. "

I understand the the Source Prefix sub-TLV is mandatory to su= pport the functions defined in this specification.  However, "opt= ionally" used in the paragraph above is confusing. One suggestion is t= o simply delete "optionally" in the sentence. 



B.R.

Jia 







--_000_38f2e15c65ed40628afe70f73822d1echuaweicom_-- From nobody Wed Oct 28 06:58:39 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8393B3A0975; Wed, 28 Oct 2020 06:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 avvNlNCKzMew; Wed, 28 Oct 2020 06:58:31 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461C63A0874; Wed, 28 Oct 2020 06:58:03 -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 09SDw1tG024241; Wed, 28 Oct 2020 14:58:01 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 34BA2D1706; Wed, 28 Oct 2020 14:58:01 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id BfzL99L8Kmiv; Wed, 28 Oct 2020 14:57:59 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 63EFED1704; Wed, 28 Oct 2020 14:57:59 +0100 (CET) Date: Wed, 28 Oct 2020 14:57:58 +0100 Message-ID: <87pn52fo61.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dan Romascanu Cc: , last-call@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org In-Reply-To: <160353145725.25780.13209881668449255473@ietfa.amsl.com> References: <160353145725.25780.13209881668449255473@ietfa.amsl.com> 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]); Wed, 28 Oct 2020 14:58:01 +0100 (CET) X-Miltered: at korolev with ID 5F9978E9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F9978E9.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 : 5F9978E9.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] Opsdir last call review of draft-ietf-babel-source-specific-06 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, 28 Oct 2020 13:58:33 -0000 >> From an operational point of view, operators should pay special attention to >> section 6 - Compatibility to the base protocol: Right. Of the 5 implementations of Babel, there are two that are actively deployed in production. Both have been updated to interoperate with 6126bis in late 2018, two years ago. We have done our best to ensure the updated versions have been deployed by now, and therefore that it is safe to deploy source-specific, but of course we cannot be sure. -- Juliusz From nobody Wed Oct 28 07:00:15 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AABE3A096B; Wed, 28 Oct 2020 07:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N_xNq2Xu6w3G; Wed, 28 Oct 2020 07:00:13 -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 4814D3A1090; Wed, 28 Oct 2020 07:00: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 09SE03lo025078; Wed, 28 Oct 2020 15:00:03 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 374ADD17A7; Wed, 28 Oct 2020 15:00:03 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2BeFXp7iXc5o; Wed, 28 Oct 2020 15:00:01 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 70809D17A1; Wed, 28 Oct 2020 15:00:01 +0100 (CET) Date: Wed, 28 Oct 2020 15:00:00 +0100 Message-ID: <87o8kmfo2n.wl-jch@irif.fr> From: Juliusz Chroboczek To: Rifaat Shekh-Yusef Cc: , draft-ietf-babel-source-specific.all@ietf.org, last-call@ietf.org, babel@ietf.org In-Reply-To: <160364731499.17476.11455568556595523172@ietfa.amsl.com> References: <160364731499.17476.11455568556595523172@ietfa.amsl.com> 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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 28 Oct 2020 15:00:03 +0100 (CET) X-Miltered: at korolev with ID 5F997963.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F997963.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 : 5F997963.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Secdir last call review of draft-ietf-babel-source-specific-06 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, 28 Oct 2020 14:00:15 -0000 > “A node MUST NOT send more that one Source Prefix sub-TLV in a TLV, > and a node receiving more than one Source Prefix sub-TLV in a single > TLV SHOULD ignore this TLV. It MAY ignore the whole packet.” > 2. This paragraph implies that a node might accept the TLV with more than one > Source Prefix sub-TLV, but it does not state when a node can do that. You might > want to elaborate on the conditions that a node is allowed to do that. Right. I've made this a MUST, which reflects implementation practice. Group, please feel free to object if you think this is the wrong choice. -- Juliusz From nobody Wed Oct 28 07:06:35 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD663A099F; Wed, 28 Oct 2020 07:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tAnPp4xAL1VH; Wed, 28 Oct 2020 07:06: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 E37CA3A0997; Wed, 28 Oct 2020 07:06:27 -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 09SE6Ahj028035; Wed, 28 Oct 2020 15:06:10 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9E2F8D195A; Wed, 28 Oct 2020 15:06:10 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id LEs6TaewgwqV; Wed, 28 Oct 2020 15:06:09 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C46E3D1958; Wed, 28 Oct 2020 15:06:08 +0100 (CET) Date: Wed, 28 Oct 2020 15:06:07 +0100 Message-ID: <87mu06fnsg.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Hejia (Jia)" Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-source-specific.all@ietf.org" , "babel@ietf.org" In-Reply-To: <38f2e15c65ed40628afe70f73822d1ec@huawei.com> References: <38f2e15c65ed40628afe70f73822d1ec@huawei.com> 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]); Wed, 28 Oct 2020 15:06:10 +0100 (CET) X-Miltered: at korolev with ID 5F997AD2.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F997AD2.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5F997AD2.003 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] RtgDir Last Call Review: draft-ietf-babel-source-specific-06 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, 28 Oct 2020 14:06:30 -0000 > In Paragraph 5, it is written as > This specification > extends these messages to optionally carry a Source Prefix sub-TLV, > [...] > The sub-TLV is marked as mandatory, > I understand the the Source Prefix sub-TLV is mandatory to support the > functions defined in this specification. However, "optionally" used in > the paragraph above is confusing. One suggestion is to simply delete > "optionally" in the sentence. I most respectfully disagree. The sub-TLV is optional -- non-specific routes don't carry the sub-TLV, which is the whole reason why the extension interoperates with unextended Babel. This is expanded upon in Section 5: A node obeying this specification MUST NOT send a TLV with a zero-length source prefix: instead, it sends a TLV with no Source Prefix sub-TLV. I think it's important to stress this fact in this paragraph. I've avoided the term "optional", which I believe is what you're objecting to: This specification extends these messages so that they may carry a Source Prefix sub-TLV, I don't like the formulation very much, so I'll be grateful if you can find a better wording. -- Juliusz From nobody Wed Oct 28 07:16:14 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B573C3A0976; Wed, 28 Oct 2020 07:16:12 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <160389457270.26179.18202830539503471168@ietfa.amsl.com> Date: Wed, 28 Oct 2020 07:16:12 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-source-specific-07.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: Wed, 28 Oct 2020 14:16:13 -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 : Source-Specific Routing in Babel Authors : Matthieu Boutier Juliusz Chroboczek Filename : draft-ietf-babel-source-specific-07.txt Pages : 11 Date : 2020-10-28 Abstract: 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 and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-source-specific-07 https://datatracker.ietf.org/doc/html/draft-ietf-babel-source-specific-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-source-specific-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 28 08:09:50 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28263A0A4F; Wed, 28 Oct 2020 08:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjb_i1e6gCgY; Wed, 28 Oct 2020 08:09:44 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892453A0A07; Wed, 28 Oct 2020 08:09:42 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1603897780; bh=xcM9fMc6mYay+UQq1lWdtKNWEfmwAftQ8TvUh88U6Pg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=qP5arfTFQNHx6VacQnTHNn0hBZ4Mx+iu+vBeZcYSqsV3slXdRgyufuEvUDjlLaQ4i OXeqniZGFxgfHGyWhv871W3iRdgKRoT5Kj1fJXJ4KqDwKYkFnbq08nqELFDfMi5iVK NbldiGbVkIHUSgPM0UX6qmICCxIBl+bRGEvBakuPGNGNQBlxT2CWUlsyK8/AblXv5n T+b/cjLvm4VleNcgJiZ8TphIi4E7DtqExOkb7OYMffZPebw3Y+remoKfby1dp8Axhy 8wYBknTxBg5mliB/QRcCsZ9csMgilFet6/q53kFpHBtNmGqp01hPHfMEsMvv8AEUhX RFl9pDIJU5Omg== To: Juliusz Chroboczek , Rifaat Shekh-Yusef Cc: last-call@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org, secdir@ietf.org In-Reply-To: <87o8kmfo2n.wl-jch@irif.fr> References: <160364731499.17476.11455568556595523172@ietfa.amsl.com> <87o8kmfo2n.wl-jch@irif.fr> Date: Wed, 28 Oct 2020 16:09:39 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mu06mlos.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Secdir last call review of draft-ietf-babel-source-specific-06 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, 28 Oct 2020 15:09:46 -0000 Juliusz Chroboczek writes: >> =E2=80=9CA node MUST NOT send more that one Source Prefix sub-TLV in a= TLV, >> and a node receiving more than one Source Prefix sub-TLV in a single >> TLV SHOULD ignore this TLV. It MAY ignore the whole packet.=E2=80=9D > >> 2. This paragraph implies that a node might accept the TLV with more tha= n one >> Source Prefix sub-TLV, but it does not state when a node can do that. Yo= u might >> want to elaborate on the conditions that a node is allowed to do that. > > Right. I've made this a MUST, which reflects implementation practice. > Group, please feel free to object if you think this is the wrong > choice. SGTM. -Toke From nobody Wed Oct 28 16:09:43 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259273A0A8F; Wed, 28 Oct 2020 16:09:42 -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 2WUbihlmsSsj; Wed, 28 Oct 2020 16:09:40 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913DE3A0A90; Wed, 28 Oct 2020 16:09:40 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id d24so1018187ljg.10; Wed, 28 Oct 2020 16:09:40 -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=gkHrB5j9y4WAK2GkxzYCi9Bp1Ziv7BqjU+9s7GWr9AA=; b=l1wsOZnusKEa+PKuWqRvi0s6dyvFOOkKNVWl59a/Rw5974bF2kZ8LI7CkuHVe0FaQH L88UWsw00lB7zEvqwqhHqExM/wOHi+t+0ekIvIcPxa7UR4aUCyCSW6tHifn4uTQH67wl WM7J17xc8iHCcVLx8EzPfd59bzu1qk4mzAYN2BtbqF8vVtAoiTHQsZ79upTyRQjwOl+m cYMmQOH8IRClvrwbHDxnLF4/xGoo7FvbpXxqiI9W9H2GRXJlCH3UhV0CnAOnFsX9/z+N YvwSoiHpTM6x2SIWVoNrnkS21Rn1FzKMu3sZXKi1Q/uG3JsEf5mFWZeVAlooe2xvpNCL 7R6Q== 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=gkHrB5j9y4WAK2GkxzYCi9Bp1Ziv7BqjU+9s7GWr9AA=; b=fvNzFyQ6sWABO7lZy+d2tE9lY1/XNiW1ns5LXenReFeMD79FBu4uKbMEXLB5aJjFy1 twLvL+G/wrtgQz5iD6ijvZ/nXhmRK7dYYHpfPIAUguhfg5j1QFJpg2i5WdglBjX9rhB1 vIYYfLI6eXdXgM+UgbYzl04YfjyJBcGg29rt69gF5YBho9qb6p9YNH9qe8ELDY4uPPDT lMZaJYF6YEf1ronYiCZuG+3+OPtZkFSP8kk9WJIx7tHvtYpuPzkHxdX5HOmYgd8WceXD FIsr65kjyJr5qPi/AARtKJk4eXoDTcy6eUdvfH3lDGiisLaw86GHJw/p2LXeUp+zRwLf rYpA== X-Gm-Message-State: AOAM531VPwPVmPXuS89GNXMyrERE0BWo5n1gf2cS/21GqV2z3GLuMnqD eIodL8+zipmeo5lLsBtt7e+/u1bTlOJFMUKHdA3wOOGWx3g= X-Google-Smtp-Source: ABdhPJyuy9VGK05E7k4Ni73IvF96+8VcHtnOe+shv5X4HPafaBOxNvLOaFERv3sOAvQlw6ZDGzRdutmyWRMPZV+ndsM= X-Received: by 2002:a2e:9882:: with SMTP id b2mr542460ljj.247.1603926578814; Wed, 28 Oct 2020 16:09:38 -0700 (PDT) MIME-Version: 1.0 References: <160364731499.17476.11455568556595523172@ietfa.amsl.com> <87o8kmfo2n.wl-jch@irif.fr> <87mu06mlos.fsf@toke.dk> In-Reply-To: <87mu06mlos.fsf@toke.dk> From: David Schinazi Date: Wed, 28 Oct 2020 16:09:26 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Juliusz Chroboczek , Rifaat Shekh-Yusef , last-call@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, Babel at IETF , secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000f9e32105b2c34130" Archived-At: Subject: Re: [babel] [Last-Call] Secdir last call review of draft-ietf-babel-source-specific-06 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, 28 Oct 2020 23:09:42 -0000 --000000000000f9e32105b2c34130 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable SGTM2 On Wed, Oct 28, 2020 at 8:10 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Juliusz Chroboczek writes: > > >> =E2=80=9CA node MUST NOT send more that one Source Prefix sub-TLV in= a TLV, > >> and a node receiving more than one Source Prefix sub-TLV in a singl= e > >> TLV SHOULD ignore this TLV. It MAY ignore the whole packet.=E2=80= =9D > > > >> 2. This paragraph implies that a node might accept the TLV with more > than one > >> Source Prefix sub-TLV, but it does not state when a node can do that. > You might > >> want to elaborate on the conditions that a node is allowed to do that. > > > > Right. I've made this a MUST, which reflects implementation practice. > > Group, please feel free to object if you think this is the wrong > > choice. > > SGTM. > > -Toke > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call > --000000000000f9e32105b2c34130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SGTM2

On Wed, Oct 28, 2020 at 8:10 AM Toke H=C3=B8iland-J= =C3=B8rgensen <toke=3D40toke= .dk@dmarc.ietf.org> wrote:
Juliusz Chroboczek <jch@irif.fr> writes:

>>=C2=A0 =C2=A0=E2=80=9CA node MUST NOT send more that one Source Pre= fix sub-TLV in a TLV,
>>=C2=A0 =C2=A0 and a node receiving more than one Source Prefix sub-= TLV in a single
>>=C2=A0 =C2=A0 TLV SHOULD ignore this TLV.=C2=A0 It MAY ignore the w= hole packet.=E2=80=9D
>
>> 2. This paragraph implies that a node might accept the TLV with mo= re than one
>> Source Prefix sub-TLV, but it does not state when a node can do th= at. You might
>> want to elaborate on the conditions that a node is allowed to do t= hat.
>
> Right.=C2=A0 I've made this a MUST, which reflects implementation = practice.
> Group, please feel free to object if you think this is the wrong
> choice.

SGTM.

-Toke

--
last-call mailing list
last-call@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/last-call
--000000000000f9e32105b2c34130-- From nobody Thu Oct 29 09:13:21 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768193A09E7 for ; Thu, 29 Oct 2020 09:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTMUmEH4B28X for ; Thu, 29 Oct 2020 09:13:19 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 126C03A09D4 for ; Thu, 29 Oct 2020 09:13:19 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id k18so383725wmj.5 for ; Thu, 29 Oct 2020 09:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q4cqWYRHNqP1q6gzM+8xmJh6Jox+R0Xz1UMpPYGaYoc=; b=DWVA5HPffbxq/nHZfzzk11IvDa4AhrVIB06mLZPczCHJ5oE2l9VcWA6ZLBz5obE3EA eJ8WwlsF2C2m7M/ln7Q83i8GqlbV/wyxSuPesnZH4APbYkO3m1J+RCKXjWlIqt4UFS/R 7XW9WViIr+bHCKgFFuq/Zmf+RjNlJGa2wkwRssvylMTPchSXMAnklZ4NCy54mtnXMO/4 f/+eVjWekDK4QHjsU49sIFRacCVjQ2XtLf8/OOatQnYB8faFk3S4ACT3p+fGzJjpIr2X rYag+EH5JaP+CDUvXukoOe8pOTSQNDJLk8oaawVJ3FHiNLTMe/0YhmPk97UvLRpO1Y/U YUng== 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=Q4cqWYRHNqP1q6gzM+8xmJh6Jox+R0Xz1UMpPYGaYoc=; b=VxE02oiZxlKXhA8XFRLmlxZOdf5NAe43R7dsvJVRn5SJsfKOFKz05cwcFAqY0G+URf /K+NFGu0vRgr/P+DDCp2rn3alyf186UIT+VJW0ZYtvz64g7IoknBD/kEFXTgoMph7Y6G AClCrBjx+O+YYxkNYLsh4K5xyMLbDNUo+b/+psAOb3BghDUTnoIjdpHq4JTXgdWil9M6 gHydWgvK99Wuk5OLfJV+dVzb3u4oNaqLb6SUQevhSUte+TpjVfaHKCt6hL/GCEUyfw75 jj2IatpXJ8Yq+tqsTPfNF16C3lBHiqSenFIehochWNB/NrOAxs1njjw+KJVa8DX3EHLj 6ayQ== X-Gm-Message-State: AOAM530+sLPPjms6zzbknp5zdZPB2iDquuL5dwB8xwNY1iWRXwFCjvZr gjUMyOxGo7Hg6/F8KRhuPnf6a+XyX3C5kkGEtdyBTA== X-Google-Smtp-Source: ABdhPJyKMUyd5YnjOjf4EZFhFu+Y3chJWyCGDZTIzO9EJMrwqTOYJfqwJ+kTgxfRmEtM4/mpIEp1l0+vBTFl2mwNauo= X-Received: by 2002:a1c:59c3:: with SMTP id n186mr656403wmb.32.1603987997237; Thu, 29 Oct 2020 09:13:17 -0700 (PDT) MIME-Version: 1.0 References: <38f2e15c65ed40628afe70f73822d1ec@huawei.com> <87mu06fnsg.wl-jch@irif.fr> In-Reply-To: <87mu06fnsg.wl-jch@irif.fr> From: Gabriel Kerneis Date: Thu, 29 Oct 2020 17:12:41 +0100 Message-ID: To: Juliusz Chroboczek Cc: "Hejia (Jia)" , "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-babel-source-specific.all@ietf.org" , "babel@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cd13df05b2d18e10" Archived-At: Subject: Re: [babel] RtgDir Last Call Review: draft-ietf-babel-source-specific-06 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, 29 Oct 2020 16:13:21 -0000 --000000000000cd13df05b2d18e10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 28, 2020 at 3:06 PM Juliusz Chroboczek wrote: > This specification extends these messages so that they may carry > a Source Prefix sub-TLV, > > I don't like the formulation very much, so I'll be grateful if you can > find a better wording. > > Suggestion: "This specification extends these messages to allow them to carry =E2=80=A6= " Gabriel --000000000000cd13df05b2d18e10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Oct 28, 2020 at 3:06 PM Juliusz C= hroboczek <jch@irif.fr> wrote:
=
=C2=A0 =C2=A0This s= pecification extends these messages so that they may carry
=C2=A0 =C2=A0a Source Prefix sub-TLV,

I don't like the formulation very much, so I'll be grateful if you = can
find a better wording.


Suggestion:
"This speci= fication extends these messages to allow them to carry =E2=80=A6"

Gabriel
--000000000000cd13df05b2d18e10-- From nobody Thu Oct 29 20:33:53 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC973A0DD8; Thu, 29 Oct 2020 20:33:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160402882613.17493.9555978018041518117@ietfa.amsl.com> Date: Thu, 29 Oct 2020 20:33:46 -0700 Archived-At: Subject: [babel] Barry Leiba's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) 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: Fri, 30 Oct 2020 03:33:47 -0000 Barry Leiba has entered the following ballot position for draft-ietf-babel-source-specific-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for an easy read. I have only some minor comments: — Section 5.2 — Please expand “AE” on first use. You should also do the same in Section 4.1.4 of draft-ietf-babel-rfc6126bis. A node MUST NOT send a wildcard retraction with an attached source prefix, and a node that receives a wildcard retraction with a source prefix MUST ignore it. The “it” here is ambiguous: please specify “MUST ignore the source prefix” or “MUST ignore the retraction”. The same comment applies also to the subsequent paragraph. — Section 6.1 — For what it’s worth, I don’t find the diagram to add anything to the text, and I wouldn’t have a clue what the diagram was trying to say without the text. Packets destined to D but not sourced in S will be forwarded by A to B, and by B to A, causing a persistent routing loop That text is describing not what will happen with this standard, but what *would* happen if this standard didn’t correct for it. So please change “will be forwarded” to”would be forwarded”, or perhaps “would then be forwarded”. And in the previous sentence, change “merely ignores” to “merely ignored”. These make it clearer that they’re talking about a hypothetical situation that’s counter to what’s specified herein. From nobody Fri Oct 30 18:36:26 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 584793A1283; Fri, 30 Oct 2020 18:36:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160410817933.20181.137158173131306726@ietfa.amsl.com> Date: Fri, 30 Oct 2020 18:36:19 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 01:36:20 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-source-specific-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.1 Note that the route entry contains a source (see sections 2 and 3.2.5 of [BABEL]) which itself contains a source prefix. These are two very different concepts that should not be confused. I appreciate having this note; thanks. I wonder if it is worth reiterating that the stock [BABEL] "source prefix" is the prefix of the source of the routing information, to jog the reader's memory. Section 5.1 Prefix sub-TLV. When a node receives a source-specific Update (prefix, source prefix, router-id, seqno, metric) from a neighbour neigh, it behaves as described in [BABEL] Section 3.5.4, except that It looks like some section renumbering has occurred, as §3.5.3 of draft-ietf-babel-rfc6126bis-20 looks much more relevant than §3.5.4 does. the entry under consideration is indexed by (prefix, source prefix, neigh) rather than just (prefix, neigh). [The two prefix lengths are implicit now, though were explicit in [BABEL]?] Section 5.2 We should probably expand "AE" on first use. Section 6.2 Is there also the possibility of a kind of starvation where source-specific routers do not get source-specific routes because the source-specific routes are dropped by non-source-specific routers between them and the source of the route advertisement? Intuitively, it seems that once you have a connected backbone of source-specific routers this would only happen if a given source-specific router only has paths to the backbone that go through non-source-specific routers, and so the router in question is effectively operating in a non-source-specific mode, but perhaps there are more interesting scenarios in the absence of such a backbone. A simple yet sufficient condition for avoiding starvation is to build a connected source-specific backbone that includes all of the edge routers, [...] I'm not sure I understand what "connected backbone that includes all of the edge routers" is intended to mean. If the edge routers are to be included in the connected backbone (i.e., to implement source-specific), then wouldn't that make the connected backbone basically all routers? Or is the intent that any given edge router has a link to a router in the backbone? Or something else? Section 7.1 If I recall correctly, Babel sub-TLVs do not admit sub-sub-TLVs, so we would treat a sub-TLV "length" that indicates more bytes of payload than indicated by the "source plen" as an encoding error and reject the sub-TLV, right? Source Plen The length of the advertised source prefix. This MUST NOT be 0. Please use "length in bits" to match 6126bis. Section 7.3 Should we consider being consistent about the use of parentheses around "route" in the section heading and section body? Section 7.4 Just to check my understanding: we do not expect issues where (e.g.) a source-specific seqno request is sent to a non-source-specific node and thus dropped, because seqno requests are supposed to be sent only to nodes that are or in the past were advertising a (possibly non-feasible) route for that prefix. Such a source-specific advertisement would only be sent by a source-specific node, that would accordingly not drop the seqno request. Section 9 I was surprised to see in a quick check of 6126bis that there did not seem to be a prominent mention in the security considerations of "make sure your parser handles TLVs that indicate a length larger than the size of the packet". Should there be one? Other than that (which is not really even a comment on this document), I like the security considerations here: they're clear on the consequences of the new behaviors from this protocol extension, and give enough examples of how that might impact the security properties of the system as a whole. Thank you! The extension defined in this document adds a new sub-TLV to three TLVs already present in the original Babel protocol, and does not change the security properties of the protocol itself. However, the We might as well toss another [BABEL] in here; they're cheap. Section 11.1 We cite BCP84 as part of the line "which is compatible with [BCP84]". That in and of itself does not necessarily seem like enough to justify a normative relationship, though perhaps there are other reasons why it is needed. From nobody Sat Oct 31 07:14:59 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5303C3A0BBC; Sat, 31 Oct 2020 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vUjkyCs56lFl; Sat, 31 Oct 2020 07:14:56 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22DCB3A0BBA; Sat, 31 Oct 2020 07:14:55 -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 09VEErZw031074; Sat, 31 Oct 2020 15:14:53 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 16E08B9272; Sat, 31 Oct 2020 15:14:53 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1YGhIKLQ0cRr; Sat, 31 Oct 2020 15:14:13 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B3C41B925B; Sat, 31 Oct 2020 15:14:12 +0100 (CET) Date: Sat, 31 Oct 2020 15:14:10 +0100 Message-ID: <87lffma3f1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: "The IESG" , draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake In-Reply-To: <160410817933.20181.137158173131306726@ietfa.amsl.com> References: <160410817933.20181.137158173131306726@ietfa.amsl.com> 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]); Sat, 31 Oct 2020 15:14:53 +0100 (CET) X-Miltered: at korolev with ID 5F9D715D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F9D715D.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 : 5F9D715D.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] Benjamin Kaduk's No Objection on draft-ietf-babel-source-specific-07: (with 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: Sat, 31 Oct 2020 14:14:58 -0000 Thanks, Benjamin. I agree with almost all of your comments, I'll try to do an update in the second half of next week and come back to you. > A simple yet sufficient condition for avoiding starvation is to build > a connected source-specific backbone that includes all of the edge > routers, [...] > I'm not sure I understand what "connected backbone that includes all of > the edge routers" is intended to mean. If the edge routers are to be > included in the connected backbone (i.e., to implement source-specific), > then wouldn't that make the connected backbone basically all routers? > Or is the intent that any given edge router has a link to a router in > the backbone? Or something else? Thanks, that's very helpful. By listing some possible misinterpretations, you've given me exactly the guidance I need in order to clarify this section. -- Juliusz From nobody Sat Oct 31 18:36:15 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AEE3A0C6D; Sat, 31 Oct 2020 18:36:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160419457047.13941.8784738161520575163@ietfa.amsl.com> Date: Sat, 31 Oct 2020 18:36:10 -0700 Archived-At: Subject: [babel] Barry Leiba's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) 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: Sun, 01 Nov 2020 01:36:11 -0000 Barry Leiba has entered the following ballot position for draft-ietf-babel-information-model-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a couple of minor comments here: — Section 1.1 — Please use the exact BCP 14 boilerplate from RFC 8174. — Section 1.2 — For “datetime”, I suggest adding “Section 5.6” to the reference to RFC 3339, to make the specific format easier to find. And I think the use of 3339 in the definition of the type makes it a normative reference. Similarly, the use of ISO.10646 to define “string” makes it normative.