From nobody Tue Jun 1 02:00:31 2021 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1763A0C53 for ; Tue, 1 Jun 2021 02:00:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162253802848.27713.10510661042286035316@ietfa.amsl.com> Date: Tue, 01 Jun 2021 02:00:28 -0700 From: IETF Secretariat Archived-At: Subject: [babel] Milestones changed for babel WG 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, 01 Jun 2021 09:00:29 -0000 Changed milestone "IESG submission of IPv4 via IPv6", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/babel/about/ From nobody Tue Jun 1 13:15:43 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2923A25F5 for ; Tue, 1 Jun 2021 13:15:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxtvd2qF4jNv for ; Tue, 1 Jun 2021 13:15:39 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 09D203A25F4 for ; Tue, 1 Jun 2021 13:15:38 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id r4so45827iol.6 for ; Tue, 01 Jun 2021 13:15:38 -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=kEevcqNPACN9hsN1axSxvsgUBV654fQN68TC6nroxGg=; b=bfTjqdKkwdLj5fiucyJwfS8zoZx1TevEHZpQ0dLdDjc3HdJmPFJ3XMVN9alrDrCBGf tpwNhdJx7cg2kZS5cSkYbwUcvao0/rYPUotedskiYU3vUZZdfRlKfmVBrkvRFtSD8VtP Wb/NsYTSxS10GsK5hBV2YP9mNT1gP43WRBF8RrW5RVaO/EwYJBnva9Nlm5YMShODWbRc RrIb3DFnFtCvXYayR5fZBioy/k82lB1dejVb1T2J1AD+i/SKCBCFqijV92gpPy9y1oMd uSzk/q4dNX2Xp4cubI/fiTu4UMqPJVZMDTV1MxnrGNqmc9rHPJRNpwR9cAj/eLeQWwOt 2oSw== 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=kEevcqNPACN9hsN1axSxvsgUBV654fQN68TC6nroxGg=; b=BS2CN9q1xcsbmjSxJDm1+YQIhY220wewhgjYBPYWEhPvJQOlaX9hhAeGn9uAAPzwEe 2N9wPmFr7maSBUqv6t/cqiicO0fRX61xN33phHd7hVlgh3zc1+ETNgFYe0Wn7GcFgTdk +p3JTpmOWGt2OOav62qJYlxTAx0/5TyvdMiLVKhT2EpRKAxE/0azrGtzb1d5yDPDbAmx CrzKbFrOJiuVHzGNJVWvtVm2ujoWriRJXn1EP08xs53A+9eWxHahbHFRzXPk937Uo7cq +1CeK+f4Ty20GAJRqm7V7A2NreVJ2xBrmFkLvVrPMzPuAoAcFqL1EAThbuC6+F9RFEgn hzOQ== X-Gm-Message-State: AOAM533b/ysqTewZcLK2wg1KtHQkFaZVvm4S7osLShVlZXSsyF6Pf7pD gNO8NTzXlDWe7CZkG0dPcumQ+9Qtcg07PyKgQkU= X-Google-Smtp-Source: ABdhPJzPhGSpDAz1lCCWFBJDhgh0eZB+E2E/4ov2R1+wsbcM8QqGkqNMXcezM32MhFCFNHljuiOfnv9lvAD0JB82QxY= X-Received: by 2002:a5d:8190:: with SMTP id u16mr18178703ion.158.1622578536130; Tue, 01 Jun 2021 13:15:36 -0700 (PDT) MIME-Version: 1.0 References: <87v976voss.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Tue, 1 Jun 2021 16:15:25 -0400 Message-ID: To: David Schinazi Cc: Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Adding two babel milestones 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, 01 Jun 2021 20:15:42 -0000 Hi David, On Thu, May 27, 2021 at 11:36 AM David Schinazi wrote: > > On Thu, May 27, 2021 at 6:54 AM Donald Eastlake wrote: >> >> Hi David, >> >> On Wed, May 26, 2021 at 2:41 PM David Schinazi wrote: >> > >> > On Tue, May 25, 2021 at 9:02 PM Donald Eastlake wrote: >> >> >> >> ... >> >> ... >> >> >> ... >> >> >> >> ... >> >> >> I tend to think of multicast as being either discovery multicast or >> >> application multicast. For application multicast, generally you can >> >> use head end replication and unicast which is less efficient in terms >> >> of link utilization and generally has higher latency due to multiple >> >> copies being sent on a link but might be simpler; on the other hand, >> >> if there are lots of sources and multicast groups, these head ends >> >> have to all keep track of who to unicast to. For discovery, you can't >> >> do everything with unicast because, by definition, you want to be able >> >> to find nodes that you don't know about yet; but you can probably get >> >> away with unicast + link local multicast for some definition of link. >> >> So I agree you can find some way to do everything with unicast and >> >> link local multicast but that doesn't mean it is the best way to do >> >> everything. >> > >> > In my mind, the best way to perform discovery is to combine unicast >> > and link-local multicast. That's what we use in DNSSD which is AFAIK >> > the IETF-recommended way to perform service discovery. >> >> OK for discovery although I'm not aware of anything that explicitly >> states that that is an IETF recommendation. >> >> Here are the first two application multicast uses that come to mind: >> >> Say you have a provider network with multiple tenants attached. >> Multicast packets arriving from a tenant need to be sent out to other >> islands of that tenant connected to your provider network. I don't >> want to get too bogged down in details of topology and optimizations >> and stuff but I think that some form of tree distribution is needed to >> scale. Interconnecting pieces of the same VLAN is similar. 802.1 >> bridging and TRILL routing are examples of complete packet forwarding >> systems that handle unicast and multicast and build such distribution >> trees. > > In this example, what's the application? What application data are the > multicast packets arriving from a tenant carrying? Well, to the tenant your network looks like a link so you unavoidably have the "link-local" tenant multicast. For example, for each of possibly many connections to islands of a tenant you might have a bridge and behind that an IP router so you would have BPDUs, LLDPDUs, VLAN registration messages, LAGPDUs, etc., and then maybe ARP/ND/RA and IS-IS Hellos and LSPs and SNPs etc. And there could be other discovery services running... (And actually, TRILL fits exactly between bridging and routing so a bridged LAN looks like a link to TRILL but a TRILL campus looks like a link to IP routing, so you could have TRILL "link-local" multicast packets in addition to bridging and IP routing multicast packets.) As to what you might consider "real" applications, I think it is somewhat of a chicken and egg problem. Since non-link-local multicast isn't supported that much, applications tend to avoid it which decreases the incentive to implement it, and so on. >> Another application is streaming media. IP-TV in access networks >> pretty much always uses multicast. > > > Definitely agree with this example, I think it's the main use of non-link-local > multicast on the Internet today. > > All this said, if you really want to add the milestone, I'll back off. I'm just > commenting that this would be the first milestone we have that wasn't > backed by support from implementers of Babel. I've only added the IPv4 via IPv6 milestone. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 2386 Panoramic Circle, Apopka, FL 32703 USA >> d3e3e3@gmail.com From nobody Wed Jun 2 13:04:42 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42073A1920; Wed, 2 Jun 2021 13:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B8ZCGVvAfhZ; Wed, 2 Jun 2021 13:04:26 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130103.outbound.protection.outlook.com [40.107.13.103]) (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 9FF1D3A191E; Wed, 2 Jun 2021 13:04:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HtYFy9QqsL8JVLwUSv6b6DwQx2T/BGFVMvjzpd6Jrpynw88sPGekh51s4ZwFDLQdKpN/qlhTOLdyxUWn5ZkDtUCE+LVdkfuQ3NLhpsLR/2RuCmt63wGyyBb1S2NLu+DMHzRMIxnkSqhmS+gatO61C+tp23dcuvPHYjtGcDygNFsyujM6pEhMcYzmOmseH9/Jy4+oF6i8IYL8yEV+fKNhIibqF8VtflFGWhRLyejiWAlaGkNZp6LRR+sRQoSqEzGUOHmbZQc11bxrlnxH/CkFGpRBIDYXTHwhN1c7eviMnBbkLi+H8Fj3/4Yp9ncZFe+Da71aLN+Ris+nC7ndPicmHQ== 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=86i0lWKzzYoFnE11yIXW+vvVZN4gwzfCMv2my0xcqsI=; b=nLhjcyqlRxgfc2Poltl7+i017jRGEjhNR3ekSwdOl+4AIrF+L6/f3Go10KVx7Zr+LQifwPBn/aRa9emqV7+D9qB3Dn2k3WFjtHFU9M4yEA1O2cINrIgRakatGuXSGBUka7HVJj3oBk+rBgL4rTKzHzj2yiKZN8Tv1n1jFirT2btUTzIhUCrfIJ5fIwASzsLt3h4uLoZ7MKZsfH7vx4JfjatD36JM3H8AItu3Ax5osPpdAgoU3liYNlhkPWyeFj7/Mr/apqpYn4RcdXVAuMXtk4/a3MPnOKSYNmJDFUnlgPn2acMNd0QM8+F29G3W0IOs6+FA1wyz3fO3qdhyewaTaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=86i0lWKzzYoFnE11yIXW+vvVZN4gwzfCMv2my0xcqsI=; b=w6g2my2251/tyzowRngCozBKxc4gli+UmbY6wv7LStJ9W7fr9PXCdNzgGt4+/sLpeJ5NEgrY/Wc21WHYAayjLH3SQ4mQW/lWxvettt7tiz+1maUiV+KhILFt1t6L1HPzlKwSZxxYZtTlQnd4YlSx8qST+QMyDrDhdX149hsA2Jc= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia.com; Received: from AM6PR07MB5560.eurprd07.prod.outlook.com (2603:10a6:20b:6f::22) by AM6PR07MB3975.eurprd07.prod.outlook.com (2603:10a6:209:33::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.14; Wed, 2 Jun 2021 20:04:22 +0000 Received: from AM6PR07MB5560.eurprd07.prod.outlook.com ([fe80::79ba:ddfb:6bf3:9a66]) by AM6PR07MB5560.eurprd07.prod.outlook.com ([fe80::79ba:ddfb:6bf3:9a66%5]) with mapi id 15.20.4195.019; Wed, 2 Jun 2021 20:04:22 +0000 To: Mahesh Jethanandani , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= Cc: babel-chairs , Babel at IETF , draft-ietf-babel-yang-model@ietf.org, The IESG , Donald Eastlake , =?UTF-8?Q?=c3=89ric_Vyncke?= References: <162124475990.8618.15255310968103028424@ietfa.amsl.com> <39A68691-1C3F-4EF8-8621-D2FC5707B5AA@gmail.com> <20210519.084054.1713468977677987317.id@4668.se> From: Martin Vigoureux Message-ID: Date: Wed, 2 Jun 2021 22:04:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-Originating-IP: [131.228.2.21] X-ClientProxiedBy: CH0PR07CA0017.namprd07.prod.outlook.com (2603:10b6:610:32::22) To AM6PR07MB5560.eurprd07.prod.outlook.com (2603:10a6:20b:6f::22) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [172.30.2.231] (131.228.2.21) by CH0PR07CA0017.namprd07.prod.outlook.com (2603:10b6:610:32::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.15 via Frontend Transport; Wed, 2 Jun 2021 20:04:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 936ffe00-2ff1-457f-0d1b-08d926019d46 X-MS-TrafficTypeDiagnostic: AM6PR07MB3975: 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: 1vxS0jo8SJAdfoRcXxWJaHEWUQYdOslmLjeMgED2A20g0UeMVEOxiYDi4W0uBhzJkkqiMRC2u7xQxqJr0ypZQMir3+dIMFtVi4Mb0oPRXPb+tXBvdHRE4/VfGZRBquBpDUpilZa9Th9QlfGcH96YhhpK4TcqasJ6mAVJiXg7wKROE2USJqVXlqPFomh1y3gnxDcTAwqumO4GIbWpBXBIEmrrhY1k1QbLLcVwaOWyY6pL8MIVexforTICg0r8ri9ZFgS63B9NBGwCyKj+uLXAWwANUSDsazcjfAT5skPfCY4lEWbm5PTuPdpJEk0uneN8+jOMz0oQ5nsN7i4VjW3ct2vbtuU88J7As4bDcDkwk2lICHstOC8O91WnA1P7ubp9Qpon2MNGzOC7SQlVsoxOygqy5meUHlVrTcde2700RFDf4yfF4meSAfFLCJN7jpAjeqY5jGP93uhXNMg4D8uo4xh93Rq2H4TXIdxpPML63hpm/EsEc5ftLejAUhkVGIWrA7QOCQjGS7bfywBki3+Luqm5U7GPyYNHi6LbF1QEAKQ5YhVoVdQOInQix8e5Wwcfjlync5a3IUdSxkP3NzMWT5ihn7znA514eFUyZ0JEvmqrtH66TLNifNXY1mJoO/Pe9h845puyKTWtkVqVkDWAI9UAj0mv7io8cIrFgOD7MGpal1QvbxhxBF7fHhpz1Uxkgcb5W0e/1FL+xvq4/200PQoONLPr908pCgYWWicbGO/2o/w5GLd5iJVLz7a30GWszOkVMNekQjIS8hHBmCNCWTzcMVKhnm25wICrKjl6Q+M3KqLChbzFO5WKCHHNNeg04rMf81+HwG34LMgkVEqXKQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5560.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(376002)(396003)(39860400002)(110136005)(54906003)(31696002)(956004)(966005)(16799955002)(2616005)(26005)(478600001)(6486002)(66946007)(16526019)(36756003)(316002)(224303003)(52116002)(44832011)(83380400001)(8936002)(4326008)(66556008)(186003)(86362001)(38350700002)(31686004)(16576012)(66476007)(2906002)(38100700002)(5660300002)(66574015)(6666004)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?OVlTR3ZuOGxPY2x2Nko4Qy9BZ1ZRbzUzT0RTcVhndUo3QnBhN05hR285Vkox?= =?utf-8?B?T3pMMlF2anFjbE0rSHRTUGRqUHQzMlBTOHQveHg1SnJGcURqTHdpcHU3N2xU?= =?utf-8?B?ZFJtWHgwYkZSdkR2Qk0rY2ZCb2lCSFR5UExkc09TMlgxVjZZbDRzS1pnWk1z?= =?utf-8?B?bmxwdmNmbE0yV1FRcVZJZGFlckoxdGJNVEZIRXR6QkRGSCt2TDBCRWQ4Q2NZ?= =?utf-8?B?YzBiSlJxLzh2RVlWRVE0bzMzb1JGTlVmbUVpM1kwUkN0SjdISlFDRUx1d1Rh?= =?utf-8?B?dUJDazUvSFF4SEdnTnpmNW80bWpkbGdKQVorUWRyZFF3UXlkM0g0RWZZbHFl?= =?utf-8?B?UEVoMHRVblM0SW5rK3ZDRnNkSlNQM2dwM3owK1JNZVNSMENxWUZVa0RSWVBU?= =?utf-8?B?Mm9TTTRIS2NFaXJhb0swaG5MVlA1bWNtZWwvK2dmdU9oSyt4Qm5aOWR5U3NY?= =?utf-8?B?UDc3UkRwOTUzR1dsUERtOUZOTXpJZUQ5Qnh0S29IdTRoWVZGa3J6ZXJpRGg1?= =?utf-8?B?bnlUb1Q2c3VKMjE5R3Q0NHJsdTBkbGtQaDFWRnhwVDZUS2JBTitnWjIyMzBP?= =?utf-8?B?anpJbE9JUHdlUlR0TWZYbW5TdzU0Y0E3alRUejJabmNacUtzM2RzYmFHVDVn?= =?utf-8?B?S09mOEQ5ZWJtcnByamdaQU5LcC96aEI3cVNSWll3ekpRd0I3RnJjNHU0Z3FQ?= =?utf-8?B?TjF4RWJqV0k4czYzbnZDSDVkai9ySmUydVlDWDFUeEd5UDZkWmVvTk5uWVZI?= =?utf-8?B?bE1ncjg0RDJ1NVYvSnFoZTd6RTRpRU9iUjFMRjNPWmx6SWhWRFVqQzJ3a3RK?= =?utf-8?B?QzRMMlNqa290ek8vQzBCNUwvZXRJblZHaklJTnAzWkVJMCtxN1FaN3V5L2hm?= =?utf-8?B?YnlrMW1KQU9UUXhxVm9STkFYU0MzWUNaamdLcE1aZXhFNU4wOWlRWmF2Q2s0?= =?utf-8?B?TktCckVxOGJsOHU0RGcyV2thQ3hPWkFRSWQrS3loUkt5QVREcGhQc1d5UEFt?= =?utf-8?B?Wnd0bTBaRmMwN1ZmUTlUN09ZZktSRmVwQmZMRWI1K2Q5bW51YmtucUovMHBi?= =?utf-8?B?TkorcTI3Q1g3bkZ4U0pXZXhYQ1dIUDJFVFZ3KytlZHoyZGpZd0UxQWlidmcw?= =?utf-8?B?S2xJRHdNNDF6MnE4Qkt3amc2c3VyeG5OdVc1YkZ0NWFSalNrZzRZS3JxR0Y4?= =?utf-8?B?eWNvaTFjMlBocnhjYWZOSEZ5Sk9mMGlhelhZR0tpQmxOMnJWeTRRR0Y2U2lT?= =?utf-8?B?S1B2djUrVlVWWVN3ZmtyNi80VnNldnZpbEFTdDVRbk5aM3FxSDlNeDEzWmNs?= =?utf-8?B?dXZWTk10V1NqWnZHODAxSk5UdFp6TGFXbkFuT0R5c202enNBQ01RMk9FQ3dI?= =?utf-8?B?UjBOYlNZSlR2UEJabjQ1dXhUc3cxbG1KSVB4aHIrenBpMDMyK04vU1ZuVDda?= =?utf-8?B?eGw5eXNVNVNMa2ZGakhDcU13QVZHaFB4QXZPeEI4T2E3elBBbHJaeW9uNXJ2?= =?utf-8?B?ai9EeHVtMWZiS0lha0YveDM1ZThpVWZVWHdLQjFHUUI4cVZnN2paQnI0dkph?= =?utf-8?B?WUhWL0hmMFQzTXQ4RVNpbDdtQnlDQjJwalRVQ084dWFJblREU2FsUS8xZTA2?= =?utf-8?B?NStMTjNMRUJuNU5KQzlSbE4zQ1hhQW1xMWUzT3UycVNFbThYYTJybTNTUWgx?= =?utf-8?B?aGllc3pERFh4QU5NbmhsTTZLR1ZOM3hYMEJxMW9hVEhCbnF4em1oaVNmL2tQ?= =?utf-8?Q?NOwEl7USfcAb71i8V92Mhv5YPtiOc3OTBWnwemW?= X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 936ffe00-2ff1-457f-0d1b-08d926019d46 X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5560.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2021 20:04:22.6091 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: S6+A/5nz5Gh1y3we/XLP1RaLglsppNVYQU+tLHUaiv/WmxcVEI+2L9qaHD0c7hHSHvcJb9tELmXQ1B8JuNY/7Hh1woj7zbh/YO02sUNuQRk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3975 Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-bab?= =?utf-8?q?el-yang-model-10=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 20:04:31 -0000 Martin, Mahesh, so what is the conclusion on that? Thank you -m Le 2021-05-19 à 17:18, Mahesh Jethanandani a écrit : > Hi Martin, > >> On May 18, 2021, at 11:40 PM, Martin Björklund > > wrote: >> >> Hi, >> >>>> >>>> The YANG module does not compile correctly with PYANG, it should be >>>> easy to fix >>>> though :-) See: >>>> https://yangcatalog.org/results/ietf-babel@2021-05-12_ietf.html >>>> Or is it a PYANG error ? >>> >>> This is a tooling error (even though I have gone ahead and changed it >>> in the model). The ABNF grammar says the following for identity-stmt >>> in RFC 7950. >>> >>>   identity-stmt       = identity-keyword sep identifier-arg-str optsep >>>                         (";" / >>>                          "{" stmtsep >>>                              ;; these stmts can appear in any order >>>                              *if-feature-stmt >>>                              *base-stmt >>>                              [status-stmt] >>>                              [description-stmt] >>>                              [reference-stmt] >>>                          "}") stmtsep >>> >>> According to it, the ‘if-feature’ and ‘base-stmt’ can appear in any >>> order. But for some reason pyang version 2.4.0 insists on a particular >>> order. I will bring this up with tooling folks. >> >> This is not a tooling error.  The error message is: >> >> ietf-babel@2021-05-12.yang :148: >> error: keyword "if-feature" not in >>    canonical order (see RFC 6020, Section 12) >> >> [side note: the RFC ref in this error message should be updated to RFC >> 7950 Section 14] >> >> The referenced section says: >> >>   The ABNF grammar [RFC5234] [RFC7405] defines the canonical order. >> >> When we publish YANG models in RFCs we use the canonical order in >> order to have a consistent format.  pyang checks this when the flag >> --ietf is used. > > I am trying to understand, and this is more for my education, what rule > within the grammar is determining the canonical order? > > Also, should pyang report this as an error, or maybe a warning might be > better? After all, this is being done for consistency reasons. > >> >> >> /martin >> >> >> >>> >>>> >>>> >>>> >>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> >>> ---------------------------------------------------------------------- >>>> >>>> == COMMENTS == >>>> >>>> The related links on should be updated. E.g., the YANG catalog entry >>>> should be: >>>> https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-babel@2021-05-12 >>>> >>>> -- Section 2.2 -- >>>> I usually use the expanded tree view rather the YANG module itself to >>>> get a >>>> global view. Is there any reason why the full tree view is not >>>> included? >>> >>> Added this to the Appendix. >>> >>>> >>>> -- Section 5 -- >>>> Is there any reason why the doc shepherd is not acknowledged ? >>>> >>>> == NITS == >>>> >>>> -- Section 2.3 -- >>>> s/MAC based security/MAC-based security/ ? >>> >>> Fixed. >>> >>> Thanks. >>> >>> Mahesh Jethanandani >>> mjethanandani@gmail.com > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > From nobody Wed Jun 2 13:16:00 2021 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6890D3A1988; Wed, 2 Jun 2021 13:15:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-babel-yang-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <162266495440.5142.14129041655900358971@ietfa.amsl.com> Date: Wed, 02 Jun 2021 13:15:54 -0700 Archived-At: Subject: [babel] Warren Kumari's No Objection on draft-ietf-babel-yang-model-10: (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: Wed, 02 Jun 2021 20:15:55 -0000 Warren Kumari has entered the following ballot position for draft-ietf-babel-yang-model-10: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm clearing my discuss; I trust that it will be addressed. From nobody Wed Jun 2 13:21:13 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C673A19B3; Wed, 2 Jun 2021 13:21:02 -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 hpgKLdoejyII; Wed, 2 Jun 2021 13:20:57 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 C26613A19B1; Wed, 2 Jun 2021 13:20:56 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id k22-20020a17090aef16b0290163512accedso2175664pjz.0; Wed, 02 Jun 2021 13:20:56 -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=3mPNPF6cie2IZ/tIEZMIsd8bhTZ2yDLJz2OrY4L3z7I=; b=Eg1s3kFLwinjubFhI06vRBLXZy5l+wsOThegQv1XarMWCJ+0TanxDgtRjLa7pv8DHs aQHQ0FSIQK+fxuePtBRbPEjgnxtHDE82l6LZYwZqT2xZpC+UXrODiIHu+N9VBOmGcq8N J0BP7Qong7jnTMgbThH7XMTRvXGjox+WSv8AOLJtKxQodPKtelN3YQhG+2PXpgpDd8TR crRyK49KMVMuTU8u4rTn+tJ1jhzTxnGEiokoTDSYNAhVT2BZzS/c24aSbXniTn5ZcJEm UBs3crk13dScG6M395aGPdM0GhQv1RF7q8xwN7TlDpax/cwdmRzb3et/TEB7Eiwvik1J 8mug== 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=3mPNPF6cie2IZ/tIEZMIsd8bhTZ2yDLJz2OrY4L3z7I=; b=O1XxtBRoo46SWh0Mq/B1AS17x8F0ZzKnCZ05D+JRcNOvQUuO5E6iXmyo8LPsifmeeq xJmvre3Y5rcHY/1tQ1bCg3A4W3vYxCFkuavSmZTccQW3AbUxHgnZ4uG7QtA3O5H70hAy g8Sg0pANWbaQvnXjyS3tXYBwp4e6QOW6JFn4jXaw8D36ldfZgResYP1bY93HiuymrH2y Oe9pyjTGvIiwtAeLp9zNm940Lt1N5PLyiwhLryyCeoMlPXZ7XUH+zKlCeixDCS3/kscB pZnI2HScK9TbrjKlVAXAlI1FsqRhsHAg3RIuuXogkDPjYKy8VkgCOgmvvuK4NNnQR1cK vi6Q== X-Gm-Message-State: AOAM530Dsc9R+KXe9ESFute+YokDY3xOf4LNElakGnKi52abHJGWmf7h oRuXY3PtWmkRaeuhyL1oWms= X-Google-Smtp-Source: ABdhPJy7ZGkBnZ5fDCm8VGjjKlx97y/oUCOiJbX1oGM+uXLUXjyyltf2NxRPZmgd+Tl2fo+Par53Hw== X-Received: by 2002:a17:90a:1b68:: with SMTP id q95mr7339950pjq.116.1622665255247; Wed, 02 Jun 2021 13:20:55 -0700 (PDT) Received: from smtpclient.apple ([66.129.239.11]) by smtp.gmail.com with ESMTPSA id a129sm385041pfa.118.2021.06.02.13.20.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Jun 2021 13:20:54 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <7BF282B2-79CA-442A-BF9C-31940F9F2749@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F268F033-6C27-4CFE-8A64-8B82B5AFC411" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 2 Jun 2021 13:20:50 -0700 In-Reply-To: Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , babel-chairs , Babel at IETF , draft-ietf-babel-yang-model@ietf.org, The IESG , Donald Eastlake , =?utf-8?Q?=C3=89ric_Vyncke?= To: Martin Vigoureux References: <162124475990.8618.15255310968103028424@ietfa.amsl.com> <39A68691-1C3F-4EF8-8621-D2FC5707B5AA@gmail.com> <20210519.084054.1713468977677987317.id@4668.se> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-bab?= =?utf-8?q?el-yang-model-10=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 20:21:03 -0000 --Apple-Mail=_F268F033-6C27-4CFE-8A64-8B82B5AFC411 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin V, I have modified the model to comply with the strict checking that Martin = B suggests. Thanks. > On Jun 2, 2021, at 1:04 PM, Martin Vigoureux = wrote: >=20 > Martin, Mahesh, >=20 > so what is the conclusion on that? >=20 > Thank you > -m >=20 > Le 2021-05-19 =C3=A0 17:18, Mahesh Jethanandani a =C3=A9crit : >> Hi Martin, >>> On May 18, 2021, at 11:40 PM, Martin Bj=C3=B6rklund = > wrote: >>>=20 >>> Hi, >>>=20 >>>>>=20 >>>>> The YANG module does not compile correctly with PYANG, it should = be >>>>> easy to fix >>>>> though :-) See: >>>>> https://yangcatalog.org/results/ietf-babel@2021-05-12_ietf.html >>>>> Or is it a PYANG error ? >>>>=20 >>>> This is a tooling error (even though I have gone ahead and changed = it >>>> in the model). The ABNF grammar says the following for = identity-stmt >>>> in RFC 7950. >>>>=20 >>>> identity-stmt =3D identity-keyword sep identifier-arg-str = optsep >>>> (";" / >>>> "{" stmtsep >>>> ;; these stmts can appear in any order >>>> *if-feature-stmt >>>> *base-stmt >>>> [status-stmt] >>>> [description-stmt] >>>> [reference-stmt] >>>> "}") stmtsep >>>>=20 >>>> According to it, the =E2=80=98if-feature=E2=80=99 and = =E2=80=98base-stmt=E2=80=99 can appear in any >>>> order. But for some reason pyang version 2.4.0 insists on a = particular >>>> order. I will bring this up with tooling folks. >>>=20 >>> This is not a tooling error. The error message is: >>>=20 >>> ietf-babel@2021-05-12.yang :148: = error: keyword "if-feature" not in >>> canonical order (see RFC 6020, Section 12) >>>=20 >>> [side note: the RFC ref in this error message should be updated to = RFC >>> 7950 Section 14] >>>=20 >>> The referenced section says: >>>=20 >>> The ABNF grammar [RFC5234] [RFC7405] defines the canonical order. >>>=20 >>> When we publish YANG models in RFCs we use the canonical order in >>> order to have a consistent format. pyang checks this when the flag >>> --ietf is used. >> I am trying to understand, and this is more for my education, what = rule within the grammar is determining the canonical order? >> Also, should pyang report this as an error, or maybe a warning might = be better? After all, this is being done for consistency reasons. >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>>=20 >>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> =3D=3D COMMENTS =3D=3D >>>>>=20 >>>>> The related links on should be updated. E.g., the YANG catalog = entry >>>>> should be: >>>>> = https://www.yangcatalog.org/yang-search/module_details.php?module=3Dietf-b= abel@2021-05-12 >>>>>=20 >>>>> -- Section 2.2 -- >>>>> I usually use the expanded tree view rather the YANG module itself = to >>>>> get a >>>>> global view. Is there any reason why the full tree view is not >>>>> included? >>>>=20 >>>> Added this to the Appendix. >>>>=20 >>>>>=20 >>>>> -- Section 5 -- >>>>> Is there any reason why the doc shepherd is not acknowledged ? >>>>>=20 >>>>> =3D=3D NITS =3D=3D >>>>>=20 >>>>> -- Section 2.3 -- >>>>> s/MAC based security/MAC-based security/ ? >>>>=20 >>>> Fixed. >>>>=20 >>>> Thanks. >>>>=20 >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >> Mahesh Jethanandani >> mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F268F033-6C27-4CFE-8A64-8B82B5AFC411 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Martin V,

I have = modified the model to comply with the strict checking that Martin B = suggests.

Thanks.

On Jun 2, 2021, at 1:04 PM, = Martin Vigoureux <martin.vigoureux@nokia.com> wrote:

Martin, Mahesh,

so what is the = conclusion on that?

Thank you
-m

Le 2021-05-19 =C3=A0 17:18, = Mahesh Jethanandani a =C3=A9crit :
Hi Martin,
On May 18, 2021, at 11:40 PM, Martin Bj=C3=B6rklu= nd <mbj+ietf@4668.se= <mailto:mbj+ietf@4668.se>> wrote:

Hi,


The YANG = module does not compile correctly with PYANG, it should be
easy to fix
though :-) See:
https://yangcatalog.org/results/ietf-babel@2021-05-12_ietf.html=
Or is it a PYANG error ?
This is a tooling error (even though I have gone ahead and = changed it
in the model). The ABNF grammar says the = following for identity-stmt
in RFC 7950.

  identity-stmt =       =3D identity-keyword sep = identifier-arg-str optsep
          &nb= sp;            = ; (";" /
          &nb= sp;            = ;  "{" stmtsep
          &nb= sp;            = ;      ;; these stmts can appear in any = order
          &nb= sp;            = ;      *if-feature-stmt
          &nb= sp;            = ;      *base-stmt
          &nb= sp;            = ;      [status-stmt]
          &nb= sp;            = ;      [description-stmt]
          &nb= sp;            = ;      [reference-stmt]
          &nb= sp;            = ;  "}") stmtsep

According to it, = the =E2=80=98if-feature=E2=80=99 and =E2=80=98base-stmt=E2=80=99 can = appear in any
order. But for some reason pyang version = 2.4.0 insists on a particular
order. I will bring this up = with tooling folks.

This is = not a tooling error.  The error message is:

ietf-babel@2021-05-12.yang <mailto:ietf-babel@2021-05-12.yang>:148: error: keyword = "if-feature" not in
   canonical order (see = RFC 6020, Section 12)

[side note: the RFC = ref in this error message should be updated to RFC
7950 = Section 14]

The referenced section says:

  The ABNF grammar [RFC5234] = [RFC7405] defines the canonical order.

When = we publish YANG models in RFCs we use the canonical order in
order to have a consistent format.  pyang checks this = when the flag
--ietf is used.
I = am trying to understand, and this is more for my education, what rule = within the grammar is determining the canonical order?
Also,= should pyang report this as an error, or maybe a warning might be = better? After all, this is being done for consistency reasons.


/martin







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

--------------------------------------------------= --------------------

=3D=3D COMMENTS =3D=3D

The related links on should be updated. E.g., the YANG = catalog entry
should be:
https://www.yangcatalog.org/yang-search/module_details.php?modu= le=3Dietf-babel@2021-05-12

-- Section = 2.2 --
I usually use the expanded tree view rather the = YANG module itself to
get a
global view. Is = there any reason why the full tree view is not
included?

Added this to the Appendix.


-- Section 5 --
Is there any reason why the doc = shepherd is not acknowledged ?

=3D=3D NITS = =3D=3D

-- Section 2.3 --
s/MAC = based security/MAC-based security/ ?

Fixed.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
Mahesh Jethanandani
mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_F268F033-6C27-4CFE-8A64-8B82B5AFC411-- From nobody Tue Jun 8 02:52:31 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921AF3A2A7B for ; Tue, 8 Jun 2021 02:52:30 -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 Wmj2A_Gk8-cr for ; Tue, 8 Jun 2021 02:52:23 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9692E3A2A6E for ; Tue, 8 Jun 2021 02:52:23 -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=1623145939; bh=Uic0XPfzmHhX82kySyX8gpc7ccRAUm4kveVZAOlFMcw=; h=From:To:Cc:Subject:Date:From; b=p1XOoLuAa88zuX82cmjcAhIYYD8PNz2mYyOXrSjrQiCIbuHsT9Kp8CnOjO/bONymH 0fQFPbQGfk0TggMLZ06vpCXLMetgwzzFf9seMx2EgYvvt7yFgY7XHQZynFNEaPasyI g2VYCtPqqCXrS2RF2wrJt4fWArut0u6e0LHiDViqH1e2UVkmrmuv2lFaRjhwXW4kU5 34z26NPfNAD/OqJxx5OWjoAzKlf21WE3iektbHu3vPsAKmWvgm8YOfYKhUu1495N/F u1bJb8n8GrkDvjFyteMN+fkB19+l2TuoO68qR+ucDkfSQbLXucKiY71tuqaH7jaBkj BTTxpZmvfoUSA== To: babel@ietf.org Cc: babel-users Date: Tue, 08 Jun 2021 11:52:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tum8u1il.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] Babel MAC support merged into Bird master 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, 08 Jun 2021 09:52:31 -0000 Hey everyone Following hot on the heels of the merge of MAC support into babeld[0], support has now also landed in Bird[1]. Juliusz re-confirmed interoperability before merging the babeld code, and I have also re-checked just now, with the code merged into Bird. -Toke [0] https://alioth-lists.debian.net/pipermail/babel-users/2021-May/003820.html [1] http://trubka.network.cz/pipermail/bird-users/2021-June/015529.html From nobody Tue Jun 8 05:14:35 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0450D3A2EBF for ; Tue, 8 Jun 2021 05:14:33 -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_DNSWL_BLOCKED=0.001, 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 1uqblVCIBHwJ for ; Tue, 8 Jun 2021 05:14: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 E0B613A2EC4 for ; Tue, 8 Jun 2021 05:14:27 -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 158CENDA003763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 8 Jun 2021 14:14:23 +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 158CELt0012442 for ; Tue, 8 Jun 2021 14:14:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 262C5DC171 for ; Tue, 8 Jun 2021 14:14:21 +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 pv0gAedeO_Hw for ; Tue, 8 Jun 2021 14:14:18 +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 CBCB6DC166 for ; Tue, 8 Jun 2021 14:14:12 +0200 (CEST) Date: Tue, 08 Jun 2021 14:14:12 +0200 Message-ID: <87eedcsgdn.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org References: <87fsxssgem.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: message/rfc822 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 08 Jun 2021 14:14:23 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 08 Jun 2021 14:14:23 +0200 (CEST) X-Miltered: at korolev with ID 60BF5F1F.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 60BF5F1D.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60BF5F1F.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 60BF5F1D.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 : 60BF5F1F.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 60BF5F1D.003 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Fwd: [Babel-users] HOWTO: MAC security for Babel 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, 08 Jun 2021 12:14:33 -0000 Delivered-To: jch@irif.fr Date: Tue, 08 Jun 2021 14:13:37 +0200 Message-ID: <87fsxssgem.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel-users@lists.alioth.debian.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Received-SPF: pass client-ip=2001:660:3301:8000::1:2; envelope-from=jch@irif.fr; helo=korolev.univ-paris7.fr X-Alioth-Lists-Spam-Score-Int: -18 Subject: [Babel-users] HOWTO: MAC security for Babel X-BeenThere: babel-users@alioth-lists.debian.net X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to the Babel Routing Daemon List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: babel-users-bounces+jch=irif.fr@alioth-lists.debian.net Sender: "Babel-users" RGVhciBhbGwsCgpBIHF1aWNrIHR1dG9yaWFsIG9uIHByb3RlY3RpbmcgeW91ciBCYWJlbCBuZXR3 b3JrIHdpdGggY3J5cHRvZ3JhcGhpYwpzaWduYXR1cmVzIHVzaW5nIHRoZSBCYWJlbC1NQUMgcHJv dG9jb2wgZXh0ZW5zaW9uLgoKCjAuIFdoYXQgZG9lcyBNQUMgc2VjdXJpdHkgZG8/Cj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09CgpJdCBwcm90ZWN0cyB5b3VyIEJhYmVsIGluZnJhc3RydWN0 dXJlIGJ5IHByZXZlbnRpbmcgYW4gYXR0YWNrZXIgZnJvbQppbXBlcnNvbmF0aW5nIGEgQmFiZWwg cm91dGVyIGJ5IGVpdGhlciBzcG9vZmluZyBCYWJlbCBwYWNrZXRzIG9yIHJlcGxheWluZwpvbGQg QmFiZWwgcGFja2V0cy4KCkl0IGRvZXMgbm90IGVuY3J5cHQgeW91ciBCYWJlbCB0cmFmZmljOiBC YWJlbCBwYWNrZXRzIGFyZSBzaWduZWQsIG5vdAplbmNyeXB0ZWQuICBUaGlzIG1lYW5zIHRoYXQg dGNwZHVtcCBhbmQgd2lyZXNoYXJrIGNhbiBzdGlsbCBiZSB1c2VkIGZvcgpkZWJ1Z2dpbmcuCgpJ dCBpcyBjaGVhcDogeW91IHNob3VsZCBub3Qgc2VlIGEgc2lnbmlmaWNhbnQgaW5jcmVhc2UgaW4g Q1BVIGxvYWQgZHVlIHRvCk1BQyBwcm90ZWN0aW9uLCBhbmQgdGhlIHBlci1wYWNrZXQgb3Zlcmhl YWQgaXMgbW9kZXJhdGUgKDUxIGJ5dGVzIGZvcgpTSEEtMjU2LCAzNSBieXRlcyBmb3IgQmxha2Uy cy0xMjgpLiAgSXQgYWxzbyBkb2VzIG5vdCBzaWduaWZpY2FudGx5IHNsb3cKZG93biBuZWlnaGJv dXIgYWNxdWlzaXRpb246IHRoZSBpbml0aWFsIGNyeXB0b2dyYXBoaWMgaGFuZHNoYWtlIGlzIGp1 c3QKb25lIHBhY2tldCBleGNoYW5nZS4KCkl0IGRvZXMgbm90IHByb3RlY3QgeW91ciBub24tQmFi ZWwgdHJhZmZpYzogZm9yIGV4YW1wbGUsIGl0IGRvZXNuJ3QKcHJldmVudCBhbiBhdHRhY2tlciBm cm9tIHNlbmRpbmcgZGF0YSBwYWNrZXRzIGZyb20gYSBzcG9vZmVkIElQIGFkZHJlc3M7CnlvdSBz dGlsbCBuZWVkIHRvIHJlbHkgb24gaGlnaGVyLWxldmVsIChIVFRQUywgU1NILCBldGMuKSBvciBs b3dlci1sYXllcgooV1BBMywgT3BlblZQTiwgV2lyZWd1YXJkKSBtZWNoYW5pc21zIGZvciB0aGF0 LiAgSG93ZXZlciwgc2luY2UgQmFiZWwtTUFDCndpbGwgcHJldmVudCBhbiBhdHRhY2tlciBmcm9t IHNwb29maW5nIHRoZWlyIGxvY2F0aW9uIGluIHRoZSBuZXR3b3JrCih3aGljaCByb3V0ZXIgdGhl eSdyZSB1c2luZyB0byBhY2Nlc3MgdGhlIG5ldHdvcmspLCBpdCB3aWxsIG1ha2UgaXQgZWFzaWVy CnRvIGZpbmQgdGhlIGF0dGFja2VyIGFuZCBraW5kbHkgZXhwbGFpbiB0byB0aGVtIHRoYXQgdGhl cmUncyBhIGJ1Zwpzb21ld2hlcmUuICAoSW4gbm8gY2FzZSBkbyB3ZSBjb25kb25lIHRoZSB1c2Ug b2YgcGh5c2ljYWwgdmlvbGVuY2UuKQoKTUFDIHNlY3VyaXR5IGlzIGltcGxlbWVudGVkIGluIGJh YmVsZCBtYXN0ZXIgc2luY2UgMjAyMS0wNS0zMSBhbmQgQklSRAptYXN0ZXIgc2luY2UgMjAyMS0w Ni0wNi4KCgoxLiBHZW5lcmF0ZSBhIGtleQo9PT09PT09PT09PT09PT09PQoKQmFiZWwtTUFDIGlz IHZ1bG5lcmFibGUgdG8gYnJ1dGUtZm9yY2UgYXR0YWNrcywgc28geW91IHNob3VsZCB1c2UgYSBz dHJvbmcKa2V5LiAgVGhlIGJlc3Qgd2F5IGlzIHRvIGdlbmVyYXRlIGEgcmFuZG9tIGtleToKCiAg ICBkZCBpZj0vZGV2L3JhbmRvbSBicz0zMiBjb3VudD0xIHwgeHhkIC1wcyAtYzMyCgpUaGUgc2Vj dXJpdHkgb2YgQmFiZWwtTUFDIHJlbGllcyBvbiB0aGlzIGtleSBvbmx5IGJlaW5nIHNoYXJlZCB3 aXRoIHBlb3BsZQphdXRob3Jpc2VkIHRvIGFubm91bmNlIEJhYmVsIHJvdXRlcy4KCgoyLiBJbnN0 YWxsIHRoZSBrZXkgb24geW91ciByb3V0ZXJzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KCkJhYmVsZAotLS0tLS0KCk9uIGVhY2ggcm91dGVyIHJ1bm5pbmcgYmFiZWxkLCBhZGQg dGhlIGZvbGxvd2luZyB0byB0aGUgY29uZmlndXJhdGlvbiBmaWxlOgoKICAgIGtleSBpZCBrMSB0 eXBlIGhtYWMtc2hhMjU2IHZhbHVlIGZlM2MuLi4KICAgIGRlZmF1bHQga2V5IGsxCgpyZXBsYWNp bmcgZmVjMy4uLiB3aXRoIHlvdXIgc2VjcmV0IGtleS4gIFRoaXMgd2lsbCBlbmFibGUgTUFDIHBy b3RlY3Rpb24Kb24gYWxsIGludGVyZmFjZXMgKHlvdSB3aWxsIHN0aWxsIG5lZWQgdG8gZW5hYmxl IHRoZSBpbnRlcmZhY2VzLCBlaXRoZXIKZnJvbSB0aGUgY29uZmlnIGZpbGUgb3IgZnJvbSB0aGUg Y29tbWFuZCBsaW5lKS4KCkFsdGVybmF0aXZlbHksIHlvdSBtYXkgZW5hYmxlIE1BQyBwcm90ZWN0 aW9uIG9uIGp1c3Qgc29tZSBpbnRlcmZhY2VzOgoKICAgIGtleSBpZCBrMSB0eXBlIGhtYWMtc2hh MjU2IHZhbHVlIGZlM2MuLi4KICAgIGludGVyZmFjZSBldGgwCiAgICBpbnRlcmZhY2Ugd2xhbjAg a2V5IGsxCgpOb3RlIHRoYXQgYmFiZWxkIHN1cHBvcnRzIHVzaW5nIG11bHRpcGxlIGNvbmZpZ3Vy YXRpb24gZmlsZXMgKHNwZWNpZnkgdGhlCictYycgb3B0aW9uIG11bHRpcGxlIHRpbWVzKSwgYnV0 IHdpbGwgbm90IHJlbG9hZCB0aGUgZmlsZXMgYXV0b21hdGljYWxseQooeW91J2xsIG5lZWQgdG8g cmVzdGFydCBiYWJlbGQgd2hlbmV2ZXIgeW91IGNoYW5nZSB0aGUga2V5cykuCgoKQklSRAotLS0t CgpPbiBlYWNoIHJvdXRlciBydW5uaW5nIEJpcmQsIGFkZCAiYXV0aGVudGljYXRpb24gbWFjIiBh bmQgImtleSIgb3B0aW9ucyB0bwp5b3VyIGludGVyZmFjZSBkZWZpbml0aW9uczoKCiAgICBwcm90 b2NvbCBiYWJlbCB7CiAgICAgICBpbnRlcmZhY2UgImV0aDAiIHsKICAgICAgICAgICBhdXRoZW50 aWNhdGlvbiBtYWM7CiAgICAgICAgICAga2V5IGZlM2MuLi4gewogICAgICAgICAgICAgICBhbGdv cml0aG0gaG1hYyBzaGEyNTY7CiAgICAgICAgICAgfTsKICAgICAgIH07CiAgICB9CgoKMy4gUmVz dGFydCB5b3VyIG5ldHdvcmsKPT09PT09PT09PT09PT09PT09PT09PT0KClJlc3RhcnQgYWxsIG9m IHlvdXIgQmFiZWwgcm91dGVycy4gIFlvdXIgcm91dGVycyBzaG91bGQgYXNzb2NpYXRlIGFzCnBy ZXZpb3VzbHkuICBJZiB5b3UgcnVuIHRjcGR1bXAsIHlvdSBzaG91bGQgbm93IHNlZSB0aGF0IGFs bCBCYWJlbCBwYWNrZXRzCmNhcnJ5IGEgUEMgYW5kIGEgTUFDOgoKICAgICAkIHN1ZG8gdGNwZHVt cCAtbiAtaSB3bGFuMCB1ZHAKICAgICBbLi4uXQogICAgIGJhYmVsIDIgKDg2KSBoZWxsbyByb3V0 ZXItaWQgdXBkYXRlL3ByZWZpeCBuaCB1cGRhdGUgcGMgfCBtYWMKCgo0LiBPcHRpb25hbDogSW5j cmVtZW50YWwgZGVwbG95bWVudAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoK SWYgeW91IG5lZWQgdG8ga2VlcCB5b3VyIG5ldHdvcmsgcnVubmluZywgeW91IG1heSBkZXBsb3kg TUFDIHByb3RlY3Rpb24KaW5jcmVtZW50YWxseSBieSB0ZW1wb3JhcmlseSBydW5uaW5nIHlvdXIg cm91dGVycyBpbiBhIG1vZGUgaW4gd2hpY2ggdGhleQpzaWduIHBhY2tldHMgYnV0IGRvbid0IHZl cmlmeSBzaWduYXR1cmVzLiAgSW4gYSBmaXJzdCBzdGVwLCBpbnN0YWxsIHlvdXIKa2V5cyBidXQg dGVsbCB5b3VyIHJvdXRlcnMgdG8gYWNjZXB0IHVuc2lnbmVkIHBhY2tldHMuICBJbiBiYWJlbGQs IHNheQoKICAgIGFjY2VwdC1iYWQtc2lnbmF0dXJlcyB0cnVlCgphbmQgaW4gQmlyZAoKICAgIGF1 dGhlbnRpY2F0aW9uIG1hYyBwZXJtaXNzaXZlOwoKQWZ0ZXIgeW91J3JlIHNhdGlzZmllZCB0aGF0 IGFsbCByb3V0ZXJzIGhhdmUgdGhlIGtleSBpbnN0YWxsZWQsIHlvdSBtYXkKaW5jcmVtZW50YWxs eSBzdGFydCByZXN0YXJ0aW5nIHlvdXIgcm91dGVycyB3aXRoIHRoZSBwZXJtaXNzaXZlIG9wdGlv bgpzd2l0Y2hlZCBvZmYuCgoKNS4gVW5pbXBsZW1lbnRlZDoga2V5IHJvdGF0aW9uCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQoKVGhlIHByb3RvY29sIHN1cHBvcnRzIGEgbW9kZSBvZiBv cGVyYXRpb24gd2hlcmUgdHdvIGtleXMgYXJlIHVzZWQgb24gZWFjaAppbnRlcmZhY2UsIGFuZCBw YWNrZXRzIGFyZSBzaWduZWQgYnkgYm90aC4gIFRoaXMgaXMgaW50ZW5kZWQgdG8gc3VwcG9ydApr ZXkgcm90YXRpb246IHRoZSBuZXcga2V5IGlzIGFkZGVkIHRvIGFsbCByb3V0ZXJzLCB0aGVuLCBv bmNlIHRoaXMgaXMKZG9uZSwgdGhlIG9sZCBrZXkgaXMgcmVtb3ZlZC4KClRoZSBjdXJyZW50IGNv ZGUgaW4gYmFiZWxkIGRvZXNuJ3Qgc3VwcG9ydCBrZXkgcm90YXRpb24sIHNpbmNlIHdlIGhhdmVu J3QKYmVlbiBhYmxlIHRvIGZpbmQgYSB1c2VyIGludGVyZmFjZSB0aGF0J3Mgc2ltcGxlIGFuZCBw b3dlcmZ1bCBlbm91Z2ggdG8KaGFuZGxlIGFsbCBjYXNlcyAoQW50b25pbidzIGNvZGUgZGlkIGhh dmUgc3VwcG9ydCwgYnV0IHRoZSB1c2VyIGludGVyZmFjZQp3YXMgY29uZnVzaW5nKS4gIFRoZSBj dXJyZW50IHBsYW4gaXMgdG8gZ2FpbiBtb3JlIGV4cGVyaWVuY2Ugd2l0aCBNQUMKcHJvdGVjdGlv biBiZWZvcmUgd2UgZGVzaWduIGEgdXNlciBpbnRlcmZhY2UgZm9yIGtleSByb3RhdGlvbi4KCgo2 LiBBY2tub3dsZWRnbWVudHMKPT09PT09PT09PT09PT09PT09CgpUaGUgZmlyc3QgTUFDIGFsZ29y aXRobSBmb3IgQmFiZWwgd2FzIGRlc2lnbmVkIGFuZCBpbXBsZW1lbnRlZCBieSBEZW5pcwpPdnNp ZW5rby4gIFRoZSBjdXJyZW50IGFsZ29yaXRobSB3YXMgZGVzaWduZWQgYW5kIGluaXRpYWxseSBp bXBsZW1lbnRlZCBieQpDbGFyYSBEw7QsIFdlcm9uaWthIEtvxYJvZHppZWphaywgYW5kIG15c2Vs Zi4gIFRoZSBjb2RlIHdhcyB0aGVuIGV4dGVuc2l2ZWx5Cm1hc3NhZ2VkIGJ5IEFudG9uaW4gRMOp Y2ltby4gIFRoZSBCaXJkIGltcGxlbWVudGF0aW9uIGlzIGR1ZSB0byBUb2tlCkjDuGlsYW5kLUrD uHJnZW5zZW4uICBBbHNvIHRoYW5rcyB0byDDiXRpZW5uZSBNYXJhaXMgYW5kIHRvIEp1bGllbiBN dWNoZW1ibGVkCih0aGUgbGF0dGVyIGVtcGxveWVkIGJ5IE5leGVkaSwgd2hvIGFyZSBnb29kIGd1 eXMpLgoKLS0gSnVsaXVzegoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KQmFiZWwtdXNlcnMgbWFpbGluZyBsaXN0CkJhYmVsLXVzZXJzQGFsaW90aC1saXN0 cy5kZWJpYW4ubmV0Cmh0dHBzOi8vYWxpb3RoLWxpc3RzLmRlYmlhbi5uZXQvY2dpLWJpbi9tYWls bWFuL2xpc3RpbmZvL2JhYmVsLXVzZXJzCg== From nobody Tue Jun 8 08:47:36 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2F33A3483; Tue, 8 Jun 2021 08:47:29 -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 7BN9LwOMRzSC; Tue, 8 Jun 2021 08:47:24 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 0219F3A3480; Tue, 8 Jun 2021 08:47:23 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 27so16847672pgy.3; Tue, 08 Jun 2021 08:47:23 -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=bIcQMaCCQmaC3ecDJfloru4V6OFFCX3JWcYjninRKFQ=; b=nOAwtladS75M6MbsSTDLFySkuGbY+VQ7TErDxsdT/7wyyqtjm+8RFEuJm0p58Wtcwd SIENmxHwcV2d0gsYdCQy8ZEc7uhI6eEbhK3cuTHTKEbxXBcNbPkLSBIPdc78xoJvjFqq 8QpDFW2ubMyKdUszBkqWEyk6BXEXxgiy4n0yomuAe2bcTRPgLzi4STURRu97qq6mwRDo VMCde7Uo36Mv4O/EgljzIcCecr82DCsPBOKku3as54gUO1OImhyXKrbzUdQA7DQlTQl/ MU+vxNn1A4WVOiGqMSUiUdPXYDb9tA18NnzK1u5VjVk3We9/mWgNT5FdeD06O/fe3QSh 7RjQ== 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=bIcQMaCCQmaC3ecDJfloru4V6OFFCX3JWcYjninRKFQ=; b=jhQyf2MO/PA41pAxGeeR2bElteOpEWzxH1ioHUr9JKRCWeyHJTF+k5IC/qgBLWWfrA 27J0Vo+Z+qoUd9dRjDgFUgw++nzu8eUQ4wY8J3whyYB2a9+YwsICyjlmUHTQT8liEccK 88SrqUemdFJHpZJceBfE+hN9j0GMZg2Vbhdt8LZ4pDRwwvYYreNNloDM8dkciN0dvKDW ZoyguwPrkIqyGrcLcZbx1jf0UDVk546mvaixDXer5Fji3sN2Edu3FzLcW3onW9Ko5Joj YafQEbd3PbfmofC8K6oa3SqP+3MVE16aXjMxk3ey3e7tjAcU1IB187SCjlh0kPdENS1x n82Q== X-Gm-Message-State: AOAM5326CxVUgp32YMM6K/h743q6h0aq8CB4ZVq1qjxUvz4apwVVQamA 9aA/k8Bx+sqc31AHQ6LIHA8= X-Google-Smtp-Source: ABdhPJzZPhy/3CL/QxKidxZNpEOdRLM0wxJr7zyra5NFeuCH+ASOmHn25/VgrB2RRexZCab9Vt360w== X-Received: by 2002:a65:670a:: with SMTP id u10mr20920192pgf.6.1623167242743; Tue, 08 Jun 2021 08:47:22 -0700 (PDT) Received: from [192.168.1.149] (c-73-93-49-153.hsd1.ca.comcast.net. [73.93.49.153]) by smtp.gmail.com with ESMTPSA id t13sm11495027pfh.97.2021.06.08.08.47.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jun 2021 08:47:21 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <99514803-6C88-40F8-B924-315945B052C1@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1DF966C7-785E-4F88-8A02-C7EA1750C29E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 8 Jun 2021 08:47:14 -0700 In-Reply-To: <162148379451.10850.9563671396439074857@ietfa.amsl.com> Cc: The IESG , draft-ietf-babel-yang-model@ietf.org, babel-chairs , Babel at IETF , Donald Eastlake To: Benjamin Kaduk References: <162148379451.10850.9563671396439074857@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 15:47:30 -0000 --Apple-Mail=_1DF966C7-785E-4F88-8A02-C7EA1750C29E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Benjamin, Thank you first of all for a detailed review. Some of the = comments/changes suggested here may impact the information model that = this draft depends on. The information model is in AUTH48 state at this = time. This response includes feedback from my co-author Barbara. > On May 19, 2021, at 9:09 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-babel-yang-model-10: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is kind of nitpicky, and I'm sorry to pull out the heavy hammer = of > DISCUSS for it, but for the "dtls-cached-info" leaf with description: >=20 > "Indicates whether the cached_info extension is included > in ClientHello and ServerHello packets. The extension > is included if the value is 'true'."; >=20 > It is factually false to just say that "the extension is included if = the > value is true", and it contradicts the DTLS specification to say so. = In > particular, the extension can only be included in the ServerHello > message if it was present in the ClientHello message being responded = to. > So maybe we can say "enabled for inclusion" or append "when permitted = by > the protocol", or something similar? How about this? OLD: "Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension is included if the value is 'true'."; NEW: "Indicates whether use of cached_info extension is enabled. The extension is enabled for inclusion if the value is = 'true'."; >=20 > There's also a few places where we didn't quite clean up all the = fallout > from switching from enumerations to identities (for MAC and > DTLS-adjacent algorithms), that really ought to get fixed before > publication. I try to note them in the COMMENT. >=20 > I also think we need to be a bit more specific about the structure of > the (binary) private-key leaf/values provided when a certificate entry > is created. Ideally this would just be by reference to some other = spec, > but the situation is unfortunately messy. (It doesn't help that we > allow DTLS 1.2, which allows certificates that are used for = key-exchange > as opposed to signing, and those are not terribly mainstream.) We may > need to pull in some other experts to figure out the right way to = write > about this. Ok. The way I am reading this is that we need to wait to hear more from = the experts that you cite before making any changes. Note, in WG discussion the ask was for the format of the private-key to = be binary. I am not an expert, but would it help if the description said = something about using PEM format for the private-key? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 2.2 >=20 > In addition to information like the version number implemented by > this device, the model contains subtrees on 'constants', > 'interfaces', 'routes' and 'security'. >=20 > I don't see a 'security' node, but rather separate 'mac-key-set' and > 'dtls' nodes, both of which contain subtrees. Fixed. >=20 > Section 2.3 >=20 > A router running Babel routing protocol can determine the parameters > it needs to use for an interface based on the interface name. [...] >=20 > Is this always true, or only sometimes? How about this? OLD: A router running Babel routing protocol can determine the parameters it needs to use for an interface based on the interface name. NEW: A router running Babel routing protocol can sometimes determine the = parameters it needs to use for an interface based on the interface name. >=20 > Transport Layer Security Version 1.2 [RFC6347], The Blake2 >=20 > (DTLS 1.3 is in the RFC Editor's queue, FWIW.) Replaced it with reference to draft-ietf-tls-dtls13. >=20 > leaf router-id { > type binary; > description > "router-id of the source router for which this route is > advertised."; >=20 > IIRC we can do length constraints in YANG, and in Babel router-ids are = 8 > octets. Should we enshrine that in the YANG? What would the constraint statement look like? For 'type uint32' I see=20= length =E2=80=9C1..4294967295=E2=80=9D; but I am not sure for 'type binary=E2=80=99 what it would look like. >=20 > leaf next-hop { > type inet:ip-address; > description > "The next-hop address of this route. This will be empty if > this route has no next-hop address."; >=20 > What does it mean for an inet:ip-address to be "empty"? That the node > is absent? Yes, that the node is absent. Would it help if it said the following? OLD: "The next-hop address of this route. This will be empty if this route has no next-hop address.=E2=80=9D; NEW: "The next-hop address of this route. This will be NULL if this route has no next-hop address.=E2=80=9D; >=20 > "List of supported certificate types, in order of > preference. The values MUST be among those listed in > dtls-cert-types. This list is used to populate the >=20 > Since the element is of type leafref to the actual list of certs, it > seems like this MUST is achieved by construction (and thus need not be > listed specifically). Though, "dtls-cert-types" appears in this > document only as the base identity for Babel DTLS certificate types, = so > this phrasing seems a bit odd...perhaps it is fallout from an > enumeration/identity conversion. You are right. There is nothing to say that the leaf-list = =E2=80=98dtls-cert-prefer=E2=80=99 could not be just=20 type identityref { base dtls-cert-types; } which would a list of certificate types this particular implementation = supports. The assumption is that the list of certificate types that the = implementation can support is not different from what it does support. = @Barbara, would it be ok for the data model to just keep one list of = certificate types? >=20 > server_certificate_type extension in a Client Hello. > Values that are present in at least one instance in the > certs object under dtls of a referenced dtls instance > and that have a non-empty private-key will be used to > populate the client_certificate_type extension in a > Client Hello."; >=20 > Since the DTLS server picks which certificate types are actually used, > it is conceivable that the preference order in this list could also be > used as input to the server's choice of type. That said, I don't = think > there is universal API support for DTLS servers accepting a preference > list directly, so we would not want to imply that this list would = always > be used in such a fashion. But it could be used in such a fashion. Based on what I understood of your comment, what do you think of this = change? Or did I completely misunderstand you?? OLD: This list is used to populate the server_certificate_type extension in a Client Hello. Values that are present in at least one instance in the certs object under dtls of a referenced dtls instance and that have a non-empty private-key will be used to populate the client_certificate_type extension in a Client Hello. NEW: This list could be used to populate the server_certificate_type extension in a Client Hello. Values that are present in at least one instance in the certs object under dtls of a referenced dtls instance and that have a non-empty private-key will be used to populate the client_certificate_type extension in a Client Hello. >=20 > container stats { > config false; > description > "Statistics collection object for this interface."; >=20 > Often, YANG models with such statistics containers will also include a > leaf to indicate the "discontinuity time" at which the counters were > last reset. Hmm. I wonder if that is not an implementation level detail. >=20 > leaf hello-mcast-history { > type string; > description > "The multicast Hello history of whether or not the > multicast Hello packets prior to exp-mcast- > hello-seqno were received, with a '1' for the most > recent Hello placed in the most significant bit and > prior Hellos shifted right (with '0' bits placed > between prior Hellos and most recent Hello for any > not-received Hellos); represented as a string using > utf-8 encoded hex digits where a '1' bit =3D Hello > received and a '0' bit =3D Hello not received."; >=20 > I'd consider adding a few more words to confirm that this is the hex > representation of a bitstring (so, all hex digits are possible), not a > string consisting of only '1' and '0' characters. > (Likewise for hello-ucast-history.) But doesn=E2=80=99t the model already say that in the last sentence? If = not, can you suggest text? >=20 > leaf exp-mcast-hello-seqno { > type uint16; > default "0"; > description > "Expected multicast Hello sequence number of next = Hello > to be received from this neighbor; if multicast Hello > packets are not expected, or processing of multicast > packets is not enabled, this MUST be NULL."; >=20 > It's not really clear to me that assigning semantics to a NULL leaf > makes sense when there is a default value for it (that has already > assigned semantics to an absent leaf). > (et seq) Ok. Will remove the default value. >=20 > leaf value { > type binary; > mandatory true; > description > "The value of the MAC key. An implementation MUST NOT > allow this parameter to be read. This can be done by >=20 > I believe that we can incorporate this restriction in the YANG itself > with something like "nacm:default-deny-all". Ok. Will add 'nacm:default-deny-all' and drop the text =E2=80=9CAn = implementation .. subsequently writeable=E2=80=9D. >=20 > description > "The name of the MAC algorithm used with this key. The > value MUST be the same as one of the enumerations > listed in the mac-algorithms parameter."; >=20 > It's now an identityref, not a name. Accordingly, there are also not > any enumerations listed in the mac-algorithms parameter. How about this? OLD: "The name of the MAC algorithm used with this key. The value MUST be the same as one of the enumerations listed in the mac-algorithms parameter.=E2=80=9D; NEW: "The MAC algorithm used with this key. The value MUST be one of the identities listed with the base of 'mac-algorithms'.=E2=80=9D; >=20 > description > "The name of the certificate type of this object > instance. The value MUST be the same as one of the > enumerations listed in the dtls-cert-types > parameter. This value can only be provided when this >=20 > Similarly, this is also identityref, and also has no enumerations = listed > in the dtls-cert-types parameter. How about this? OLD: "The name of the certificate type of this object instance. The value MUST be the same as one of the enumerations listed in the dtls-cert-types parameter.=20 NEW: "The certificate type of this object instance. The value MUST be the same as one of the identities listed with the base of 'dtls-cert-types'.=20 >=20 > leaf private-key { > type binary; > mandatory true; > description > "The value of the private key. If this is non-empty, > this certificate can be used by this implementation = to > provide a certificate during DTLS handshaking. An > implementation MUST NOT allow this parameter to be > read. This can be done by always providing an empty >=20 > (nacm:default-deny-all could be useful here as well) Ok. Will add it and drop the appropriate text around it. >=20 > string, or through permissions, or other means. This > value can only be provided when this instance is > created, and is not subsequently writable."; >=20 > It is perhaps a bit limiting to require the actual private key value = to > be supplied, since that would preclude the use of (e.g.) HSM-based > private keys. But since we are basically inheriting from the > information model here, I won't press it too hard. >=20 > Section 4 >=20 > It might be worth referencing the security considerations of > 8966/8967/8968 as being applicable. I understand that the Babel protocol itself is a insecure protocol. But = I am not clear on how that is applicable to the YANG model that is used = to configure or read the *state* of the protocol (over a secure = interface). How about we add this? Thanks to Barbara for providing the = text. "The security considerations outlined here are specific to the YANG data = model, and do not cover security considerations of the Babel protocol or = its security mechanisms [RFC8966][RFC8967][RFC8968]. Each of these have = their own Security Considerations section for considerations that are = specific to it." >=20 > The security (privacy, really) considerations of RFC 7924 are also > arguably relevant, relating to the use of the TLS "cached_info" > extension. Isn=E2=80=99t this something that is relevant to RFC8968? The YANG model = is merely allowing for the configuration of the capability specified in = RFC8968. Shouldn=E2=80=99t any security considerations for = =E2=80=9Ccached_info=E2=80=9D therefore be mentioned there? >=20 > Are there any security and/or privacy considerations relating to the > logging of babel packets? We say the following in the security considerations section. 'babel': Access to the information in the various nodes can disclose the network topology. Additionally, the routes used by a network device may be used to mount a subsequent attack on traffic traversing the network device. >=20 > There are a number of data nodes defined in the YANG module which = are > writable/created/deleted (i.e., config true, which is the default). >=20 > I don't think "writable/created/deleted" is part of the template. Thanks to Barbara for digging this out: https://datatracker.ietf.org/doc/html/rfc8407.html#section-3.7.1 = : There are a number of data nodes defined in this YANG module that are writable/creatable/deletable >=20 > 'babel/hmac' and 'babel/dtls': These contain security credentials > that influence whether packets are trusted. >=20 > I'd consider making two separate (but related) points about = controlling > whether incoming packets are trusted, and whether outgoing packets are > produced in a way such that the receiver will treat them as trusted. > (Changing just the use-send/use-verify values can allow for a valid = key > to be misused, without changing the actual keys being used, which = could > present an interesting attack in some scenarios.) Ok. How about this? Thanks again to Barbara for providing the text. =E2=80=9CThese contain security credentials that influence whether incoming packets are trusted, and whether = outgoing packets are produced in a way such that the receiver will treat them as = trusted.=E2=80=9D >=20 > Some of the readable data or config false nodes in this YANG module > may be considered sensitive or vulnerable in some network > [...] > 'babel/hmac' and 'babel/dtls': These contain security credentials, > include private credentials of the router. >=20 > We do require the actual secret keys to not be readable, so we might > consider phrasing this more as a reiteration of that requirement than = a > statement of risk if they are read out. How about this? Thanks Barbara. 'babel/hmac' and 'babel/dtls': These contain security credentials, including private credentials of the router; however it is required that these values not be readable. =20 >=20 > Some of the RPC operations in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control access to these operations. These are the > operations and their sensitivity/vulnerability from a RPC operation > perspective: >=20 > This model does not define any RPC operations. >=20 > We do define a couple of actions, though, which are like RPCs except > "[t]he difference between an action and an rpc is that an action is = tied > to a node in the datastore, whereas an rpc is not". This is perhaps = an > omission in the YANG security considerations template, but I don't = think > we should let that stop us from noting the actions we define are > carefully designed to have minimal security impact and minimal > side-channel leakage. (Well, I guess that's not hard for the > stats-reset one, but for the MAC key test one it's quite important.) How about this? OLD: This model does not define any RPC operations. NEW: This model defines two actions, one of which allows for MAC key and MAC algorithm to be tested.=20 It does not allows for them to be changed. >=20 > Section 6.1 >=20 > I don't have a great sense for why RFC 4868 needs to be normative. RFC 4868 is cited as a reference in the YANG model, which is normative. >=20 > RFC 8968 seems missing as a listed reference at all (which would of > course need to be normative as 8967 is). Agreed. >=20 > Section 6.2 >=20 > I think RFC 7693 should be normative, since you need it in order to do > the blake2 stuff. Ok. Will move it to normative section. >=20 > RFC 8341 might become normative if we add nacm:default-deny-all = stanzas. Agreed. >=20 > NITS >=20 > The tree diagram and the prose use different orders for the various > child elements, which is a little distracting. Ok. Will fix the order. >=20 > Section 1 >=20 > [RFC8966]. The data model is defined using YANG 1.1 [RFC7950] data > modeling language and is Network Management Datastore Architecture >=20 > "the YANG [data modeling language]" >=20 > Section 2.1 >=20 > Information Model and this data module. The information model > mandates the definition of some of the attributes, e.g. 'babel- >=20 > comma after "e.g." (as well as before). (I'll try to only note it = once, > though it appears many times.) Likewise for "i.e." >=20 > Section 2.2 >=20 > In addition to information like the version number implemented by > this device, the model contains subtrees on 'constants', >=20 > The actual data model (and the information model, for that matter) = show > that the 'version' leaf contains "the name and version of this > implementation of the Babel protocol". The text here suggests that it > contains the protocol version number implemented by the device, which = is > different. So I'd suggest "the implementation and version used by = this > device" instead. >=20 > The 'interfaces' subtree describes attributes such as 'interface' > object that is being referenced, the type of link, e.g. wired, >=20 > "the 'interface'" Ok to the above suggested changes. >=20 > wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- > horizon' and whether the interface is enabled or not. >=20 > I suggest using semicolons for the outer layer of grouping, to avoid > overloading commas for different hierarchies of separation. Something like this? OLD: The 'interfaces' subtree describes attributes such as 'interface' object that is being referenced, the type of link, e.g. wired, wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- horizon' and whether the interface is enabled or not. NEW: The 'interfaces' subtree describes attributes such as 'interface' object that is being referenced, the type of link, e.g., wired, wireless or tunnel; as enumerated by 'metric-algorithm' and 'split- horizon=E2=80=99; and whether the interface is enabled or not. >=20 > Finally, for security two subtree are defined to contain MAC keys = and > DTLS certificates. The 'mac-key-set' subtree contains keys used = with >=20 > "subtrees" >=20 > interfaces. The dtls subtree contains certificates used with DTLS >=20 > single quotes for 'dtls'. > "the DTLS" >=20 > Section 2.3 >=20 > Similarly, an interface that is a metered 3G link, and used for > fallback connectivity needs much higher default time constants, e.g. >=20 > Comma after "connectivity". >=20 > HMAC: Keyed-Hashing for Message Authentication [RFC2104], Using > HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4868], Datagram >=20 > The "with IPsec" part of RFC 4868's title seems to have been dropped. Ok to the above suggested changes. >=20 > "This implementation supports two-out-of-three metric > comp algorithm."; >=20 > "the two-out-of-three". > Also, do we really need to (silently) abbreviate "metric computation" > (multiple occurrences)? Should be: =E2=80=9Cthe =E2=80=99two-out-of-three=E2=80=99=E2=80=9D.=20 Will fix metric comp occurrences. >=20 > "This implementation supports Expected Transmission Count >=20 > "the Expected" Ok. >=20 > "This implementation supports hmac-sha256 MAC algorithm."; >=20 > "the hmac-sha256" >=20 > "This implementation supports x-509 certificate type."; >=20 > "the X.509" Ok to both. >=20 > "This implementation supports raw-public-key certificate > type."; >=20 > Missing article, per the theme, but I think it would also be more > conventional to spell the name as "RawPublicKey". Ok. That was done to be consistent with the IM. >=20 > base metric-comp-algorithms; > if-feature "etx-supported"; > description > "Expected Transmission Count."; >=20 > I'd put an "algorithm" in here somewhere How about: =E2=80=9CExpected Transmission Count (ETX) metric compilation = algorithm.=E2=80=9D >=20 > "BLAKE2s algorithms supported. Specifically, BLAKE2-128 is > supported."; >=20 > I'd just say "BLAKE2-128 algorithm supported." Then shouldn=E2=80=99t the feature say feature blake2-128-supported? >=20 > "Raw Public Key type."; >=20 > "certificate type" >=20 > leaf router-id { > type binary; >=20 > (If length constraint is applied earlier, it should apply here as = well.) >=20 > "Indicates whether statistics collection is enabled (true) > or disabled (false) on all interfaces. When enabled, > existing statistics values are not cleared and will be > incremented as new packets are counted."; >=20 > I suggest "on transition to enabled". > (Also, thank you for clearly spelling out which behaviors true/false = map > to!) >=20 > A value of true indicates split horizon optimization > is used."; > "the split" >=20 > "List of references to the mac entries that apply > to this interface. When an interface instance is > created, all mac instances with default-apply 'true' >=20 > s/mac/MAC/ (twice) >=20 > "Indicates whether the cached_info extension is included > in ClientHello and ServerHello packets. The extension >=20 > s/packets/messages/. Ok to the above suggested changes. > Also, it's conventional to refer to TLS extension names enclosed by > double quotes, but I guess in the context of a YANG leaf description > that's not really feasible. Correct. >=20 > dtls-cert-types. This list is used to populate the > server_certificate_type extension in a Client Hello. >=20 > s/Client Hello/ClientHello/. >=20 > list mac-key-set { > key "name"; >=20 > description > "A mac key set object. If this object is implemented, it > provides access to parameters related to the MAC security > mechanism."; >=20 > s/mac/MAC/ >=20 > "A string that uniquely identifies the mac object."; >=20 > s/mac/MAC key/ >=20 > If 'true', this instance is applied to new babel- > interfaces instances at the time they are created, > by including it in the mac-key-sets list under > interfaces. If 'false', this instance is not applied >=20 > s/under interfaces/under the interface/ >=20 > to new interfaces instances when they are created."; >=20 > s/interfaces/interface/ >=20 > If 'true', this instance is applied to new interfaces > instances at the time they are created, by including it > in the dtls-certs list under interfaces. If 'false', >=20 > s/under interfaces/under the interface/ >=20 > this instance is not applied to new interfaces > instances when they are created."; >=20 > s/interfaces/interface/ Ok to make the above suggested changes. Thanks again for a detailed review! Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1DF966C7-785E-4F88-8A02-C7EA1750C29E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Benjamin,
Thank you first of all for a detailed = review. Some of the comments/changes suggested here may impact the = information model that this draft depends on. The information model is = in AUTH48 state at this time.

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

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

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

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


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


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



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

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

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

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

How about = this?



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

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

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





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

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

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



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

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

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





=           container = stats {
=             co= nfig false;
=             de= scription
=             &n= bsp; "Statistics collection object for this interface.";

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

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


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

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

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


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

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

Ok. Will = remove the default value.





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

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





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

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

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


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

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

Section 4

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

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








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

  This = model does not define any RPC operations.

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











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

s/Client Hello/ClientHello/.

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

=           description =             "A= mac key set object. If this object is implemented, it
=             &n= bsp;provides access to parameters related to the MAC security
=             &n= bsp;mechanism.";

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

s/mac/MAC key/

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

s/under interfaces/under the interface/

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

s/interfaces/interface/

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

s/under interfaces/under the interface/

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

s/interfaces/interface/






= --Apple-Mail=_1DF966C7-785E-4F88-8A02-C7EA1750C29E-- From nobody Tue Jun 8 09:42:56 2021 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FD73A3628; Tue, 8 Jun 2021 09:42:53 -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.31.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <162317057361.23668.12262974339763065994@ietfa.amsl.com> Date: Tue, 08 Jun 2021 09:42:53 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-v4viav6-04.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, 08 Jun 2021 16:42:54 -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 Author : Juliusz Chroboczek Filename : draft-ietf-babel-v4viav6-04.txt Pages : 10 Date : 2021-06-08 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-v4viav6-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 8 09:47:39 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77C3A3656 for ; Tue, 8 Jun 2021 09:47: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 IIIrcCF-MjsQ for ; Tue, 8 Jun 2021 09:47: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 844A93A3655 for ; Tue, 8 Jun 2021 09:47:35 -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 158GlWPQ009339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 8 Jun 2021 18:47:32 +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 158GlWTj017055 for ; Tue, 8 Jun 2021 18:47:32 +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 51D30E2843 for ; Tue, 8 Jun 2021 18:47:32 +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 tN5zFwLuVYZu for ; Tue, 8 Jun 2021 18:47:30 +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 9DA75E2841 for ; Tue, 8 Jun 2021 18:47:30 +0200 (CEST) Date: Tue, 08 Jun 2021 18:47:30 +0200 Message-ID: <87im2os3q5.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <162317057361.23668.12262974339763065994@ietfa.amsl.com> References: <162317057361.23668.12262974339763065994@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 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]); Tue, 08 Jun 2021 18:47:32 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 08 Jun 2021 18:47:32 +0200 (CEST) X-Miltered: at korolev with ID 60BF9F24.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 60BF9F24.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60BF9F24.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 60BF9F24.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 : 60BF9F24.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 60BF9F24.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-04.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, 08 Jun 2021 16:47:37 -0000 > Filename : draft-ietf-babel-v4viav6-04.txt I've expanded the introduction, it is hopefully more legible now. I've added some text to clarify that retractions with AE 1 (IPv4) and 4 (v4-via-v6) are completely equivalent, and that it is therefore an arbitrary choice which AE to use for a retraction. I've also replaced "AE TBD" with "AE 4 (v4-via-v6) throughout the document. I've updated the IANA considerations to indicate that the AE has been allocated. Unless somebody has further comments, I suggest that this document should be moved forward. -- Juliusz From nobody Tue Jun 8 16:41:04 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEAA3A10A3 for ; Tue, 8 Jun 2021 16:41:02 -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 BYxJGig3zFhS for ; Tue, 8 Jun 2021 16:40:58 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 1D7923A109F for ; Tue, 8 Jun 2021 16:40:57 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id q25so16965122pfh.7 for ; Tue, 08 Jun 2021 16:40:57 -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=YPa5VuT/Mema3wOrcrXFQmM0y+1jHtUV+BT3Qgf7900=; b=WfREFO1fIwzry0H8ixyRiF3Jf1kdNOGLV284DLX4IQOG2Fjl8TqBhwDl3C6Yhcn/gk 4DjrHg3bWBIkxvZ91d/BGvVp4huYcU/959yPL2RbOdHAB45BmKZa95Bz9gYw/J5yUqll 0imc+nJvmwX7jagVv0CI6e8ymAJQm40sg7j9bGBx/3MRxDZOjlSQ8culeeP4OYlGdDHM Y2xTedDx91feeFFCRTMyK80/aHmrKjZjYfyQ/Lm+m+XvzJoT58z3sdqBKyiWIh/DYuYo rr37A8UmS2QzMEdiC4awwVXFM4yI9EcpIVK8Xvw167G25l/+FuFoGz3ieWSRtZ1QM1Tr C3sA== 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=YPa5VuT/Mema3wOrcrXFQmM0y+1jHtUV+BT3Qgf7900=; b=l6hs/XzVIgJpLCRT6wOTMNXzYbYRoYtQEx8XimqYUs1cZmlyAJSEIltXq1AwLSAtta Ue4zRxmJcNrGg9tj7jA/DDFJ1NY8+YjM84mkvtLJgwKsbUfLRLnmLoXFd/4gU+Gmgk6Z 75W65fdOO4cXFXJfmODsurRkAUt6MC4rB0bttb6lZ5/s3IwTm6SrCanwF9OlNtv0wj+T wkuq16Q9F+gvkGGU8ld7NsZy8thTqlJhC0M3htGQkyKCD2BxhhW1ntDkb77Y9YMOaFSp ZTTTfn0lTc6uZ+0Xp8KW8jRBuoUz8au9uAer0fVozQXxdwsglDikRvBZ534356+yl1H9 kPug== X-Gm-Message-State: AOAM53159rRzr+IvG7DnUB1IxrBaX7gZBCk9DMNsBY7sLOxM/jpcFqDu wD/YcnXIi0kirUkF78Q/wHdPVUpZd2Q/x+S9pYY= X-Google-Smtp-Source: ABdhPJw1HFWp6pfyoNjuwWF0aF0P7b8GtWLItYPvJSt3cUIyBPfcxDwGrdGYulOHYCLEX1DrhJRyoYvcZT3+rJjl9Wo= X-Received: by 2002:a63:5b21:: with SMTP id p33mr762924pgb.402.1623195656902; Tue, 08 Jun 2021 16:40:56 -0700 (PDT) MIME-Version: 1.0 References: <162317057361.23668.12262974339763065994@ietfa.amsl.com> <87im2os3q5.wl-jch@irif.fr> In-Reply-To: <87im2os3q5.wl-jch@irif.fr> From: David Schinazi Date: Tue, 8 Jun 2021 16:40:45 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: multipart/alternative; boundary="00000000000087dac505c449b0ca" Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-04.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, 08 Jun 2021 23:41:03 -0000 --00000000000087dac505c449b0ca Content-Type: text/plain; charset="UTF-8" I've read the diff. I find the new introduction much clearer, and I believe the document to be ready to be moved forward. David On Tue, Jun 8, 2021 at 9:47 AM Juliusz Chroboczek wrote: > > Filename : draft-ietf-babel-v4viav6-04.txt > > I've expanded the introduction, it is hopefully more legible now. I've > added some text to clarify that retractions with AE 1 (IPv4) and 4 > (v4-via-v6) > are completely equivalent, and that it is therefore an arbitrary choice > which AE to use for a retraction. I've also replaced "AE TBD" with "AE > 4 (v4-via-v6) throughout the document. I've updated the IANA > considerations > to indicate that the AE has been allocated. > > Unless somebody has further comments, I suggest that this document should > be moved forward. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --00000000000087dac505c449b0ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've read the diff. I find the new introduction much c= learer,
and I believe the document to be ready to be moved forward.

David

On Tue, Jun 8, 2021 at 9:47 AM Juliusz Chr= oboczek <jch@irif.fr> wrote:
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-babel-v4viav6-04= .txt

I've expanded the introduction, it is hopefully more legible now.=C2=A0= I've
added some text to clarify that retractions with AE 1 (IPv4) and 4 (v4-via-= v6)
are completely equivalent, and that it is therefore an arbitrary choice
which AE to use for a retraction.=C2=A0 I've also replaced "AE TBD= " with "AE
4 (v4-via-v6) throughout the document.=C2=A0 I've updated the IANA cons= iderations
to indicate that the AE has been allocated.

Unless somebody has further comments, I suggest that this document should be moved forward.

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--00000000000087dac505c449b0ca-- From nobody Wed Jun 9 05:42:51 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519093A1488; Wed, 9 Jun 2021 05:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Prurrlp6NNv; Wed, 9 Jun 2021 05:42:46 -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 8E1763A1487; Wed, 9 Jun 2021 05:42:46 -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 159CggBe027318; Wed, 9 Jun 2021 14:42:42 +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 4C3F8A86A9; Wed, 9 Jun 2021 14:42:42 +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 vB2R2KbDEeGz; Wed, 9 Jun 2021 14:42:40 +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 46076A86A6; Wed, 9 Jun 2021 14:42:40 +0200 (CEST) Date: Wed, 09 Jun 2021 14:42:40 +0200 Message-ID: <87v96nyzsv.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 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, 09 Jun 2021 14:42:42 +0200 (CEST) X-Miltered: at korolev with ID 60C0B742.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60C0B742.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 : 60C0B742.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] Shepherd review of draft-ietf-babel-v4viav6-03 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, 09 Jun 2021 12:42:50 -0000 > I've done a review of this draft as Shepherd. See below: Sorry, Donald, I'd missed your review. I've just submitted a -05 that takes it into account. > The introduction is generally quite good but, in the first paragraph, > some wording feels just the slightest bit off. For example, it appears > to assume that ND or ARP would always be used when the next-hop to link- > layer address mapping might be statically configured The introduction has been rewritten. While this section is non-normative, and therefore doesn't constrain implementations from doing what you suggest, I've added an instance of the word "typically" as a concession to implementations that migh do what you suggest. > Globally TDB -> 4 Done. > REFERENCES > > Update reference to RFC 5549 to RFC 8950. Most respectfully disagree. The reference is used in the following sentence: The extension described in this document is inspired by a previously defined extension to the BGP protocol . It is important to cite the older reference in order to give proper credit and be clear who got there first. > Section 2, 1st line: It is more common in IETF documents to say > "dual-stack" rather than "double-stack". Done. > anoncing -> announcing Done. > annoucements -> announcements Done. > administatoris -> administrators Done. > next hop -> next-hop (7 times) Thanks. I've checked that I consistently use "next hop" when it is a noun and "next-hop" when it is used as an adjective. This is consistent with RFC 8966. > eg. -> e.g. (twice) Done. > It would be preferable, within the Normative and the Informative > References, that RFCs be listed in numeric order. In the XML? The plain-text version is being sorted by xml2rfc, so if there's any issue, it's a bug in xml2rfc. > I notice this draft generally uses British spelling. I think that's OK > as long as it is consistent. This is consistent with RFC 8966. Thanks, -- Juliusz From nobody Wed Jun 9 05:47:59 2021 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7A33A14B9; Wed, 9 Jun 2021 05:47:57 -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.31.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <162324287757.2952.14118050110395796132@ietfa.amsl.com> Date: Wed, 09 Jun 2021 05:47:57 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-v4viav6-05.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 12:47:58 -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 Author : Juliusz Chroboczek Filename : draft-ietf-babel-v4viav6-05.txt Pages : 10 Date : 2021-06-09 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-v4viav6-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 9 07:09:29 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D50D3A1893; Wed, 9 Jun 2021 07:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=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 wMJb0sUxsck7; Wed, 9 Jun 2021 07:09:22 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632E63A1891; Wed, 9 Jun 2021 07:09:22 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id b5so26216797ilc.12; Wed, 09 Jun 2021 07:09:22 -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=Qb4QBACY40NcCDgkPDWYWDXTr3opJc6/3nDHA3/hWPo=; b=RHcbWDVNnJL04fq2lCAO6PevkjL7Jb0MO0qBUeAK5Vt8tIzgDNObqwBSqLudrhMbYM HcXGRjzwrRS2/YLPIPM2v5xlDFEtAcwwdBbUjcvVBwIYmMtgw7UsklLaT3rKr8Uy9WWO 6mCmg8s6k2+rnKHzOta4iXzgT1lLm8IQbB7FD9zXZBzQ7Ig/odmWIOx0hBl83Yt11FdI pkvfVPBycVN0E6SYG6/r+u6j8UXy3DaFXx+ZnUCVjV0w6/bWbT/DxNTvfEkmpCSD5O4i MK/w3BoafYoYrZt1lay+Wrlx6YnrpusdXsR1ZFOTt6KjlpopaoPrjLdwqtMH942uAWqy wj7g== 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=Qb4QBACY40NcCDgkPDWYWDXTr3opJc6/3nDHA3/hWPo=; b=b9HmAVSD5BBu5eeQx6ek9uUJCxoo5avIpAdZBhSay9wkT+SYp22CwQP95WOhoaFOMU DFoxoHjYS6qDuNIb7BcZStLMSmxOaPxL1J1rEqdjhMWZNMHZKh4t/gII+r9GUJSKRPOI UX6JAORxxq70LBZ6L2fmKBRIWJZnpyZ8u32ktOcxN2FM8kkffbdr5X9OuPITr6dIzKZa d6A/OcV9z68UAAGlP9T+KvJ8/p0M0+1NL/e3Qh1gfdEanToUN7JV+h5+uOiQnH6lCGnS 5OATVxmEuFHG7QduSe2ZW3z1d8mHZTnwwnfKW76GrrX3zFx7CUCrhKAtrwzxOwp3yieJ nb7Q== X-Gm-Message-State: AOAM530SetwRbXvsRFxiODAgUTMnuRd1iXQ4St4lNPvgTwJKnhxrMqEU BwjTeKaYQ8t1y6+BluoL5hf+PDGSysbpLjp/1Jw= X-Google-Smtp-Source: ABdhPJzsC0dCuN1Lj6DMVxCfo0kNzXu3oS13lkFpL++ZDX9du5akpIvsTgU9NaPkMKH3q2XPUHKPX7+ulHmz1wfnHEI= X-Received: by 2002:a05:6e02:1068:: with SMTP id q8mr18768550ilj.276.1623247760853; Wed, 09 Jun 2021 07:09:20 -0700 (PDT) MIME-Version: 1.0 References: <87v96nyzsv.wl-jch@irif.fr> In-Reply-To: <87v96nyzsv.wl-jch@irif.fr> From: Donald Eastlake Date: Wed, 9 Jun 2021 10:09:09 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Shepherd review of draft-ietf-babel-v4viav6-03 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, 09 Jun 2021 14:09:28 -0000 Hi Juliusz, Latest version looks good. See below: On Wed, Jun 9, 2021 at 8:42 AM Juliusz Chroboczek wrote: > > > I've done a review of this draft as Shepherd. See below: > > Sorry, Donald, I'd missed your review. I've just submitted a -05 that > takes it into account. > > > The introduction is generally quite good but, in the first paragraph, > > some wording feels just the slightest bit off. For example, it appears > > to assume that ND or ARP would always be used when the next-hop to link- > > layer address mapping might be statically configured > > The introduction has been rewritten. While this section is non-normative, > and therefore doesn't constrain implementations from doing what you > suggest, I've added an instance of the word "typically" as a concession to > implementations that might do what you suggest. > > > Globally TDB -> 4 > > Done. > > > REFERENCES > > > > Update reference to RFC 5549 to RFC 8950. > > Most respectfully disagree. The reference is used in the following > sentence: > > The extension described in this document is inspired by a previously > defined extension to the BGP protocol . > > It is important to cite the older reference in order to give proper credit > and be clear who got there first. That makes sense. But I suspect other reviewers may trip over the same thing. > > Section 2, 1st line: It is more common in IETF documents to say > > "dual-stack" rather than "double-stack". > > Done. > > > anoncing -> announcing > > Done. > > > annoucements -> announcements > > Done. > > > administatoris -> administrators > > Done. > > > next hop -> next-hop (7 times) > > Thanks. I've checked that I consistently use "next hop" when it is a noun > and "next-hop" when it is used as an adjective. This is consistent with > RFC 8966. OK > > eg. -> e.g. (twice) > > Done. > > > It would be preferable, within the Normative and the Informative > > References, that RFCs be listed in numeric order. > > In the XML? The plain-text version is being sorted by xml2rfc, so if > there's any issue, it's a bug in xml2rfc. Ahhh, I was too quick and didn't look closely enough! The informative references are in numeric order, including RFC 0826. But the normative references have an RFC 792 :-) which got sorted after RFC 2119. Obviously too minor to bother with now but I suggest that in some future revision you change that to RFC 0792. I'll go ahead and do the PROTO write-up and request RFC publication. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > > I notice this draft generally uses British spelling. I think that's OK > > as long as it is consistent. > > This is consistent with RFC 8966. > > Thanks, > > -- Juliusz From nobody Sat Jun 12 16:45:28 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577903A2605; Sat, 12 Jun 2021 16:45:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s27yHHK7v7O5; Sat, 12 Jun 2021 16:45:25 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02C33A2604; Sat, 12 Jun 2021 16:45:25 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id q7so35683739iob.4; Sat, 12 Jun 2021 16:45:25 -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=FZQhXYqJSgJEDSXn37c2xwV+LPacb7suF3Saaz+sRuE=; b=t5I1lbEFuIyRKInn6UWiu8sPf1rZ0nKMo7bSMHFdpIqYG9/kM9/Epwnq3io/15HDE7 DvPWw9yXYEKoIkEbW4GsPWtOJleH+RFugnjyIuH51V4gF7OZuNZMURvut9uKTlRXa3n6 3NlCLyZ7zSxkV/ZhK/SiZJ32IFRpN36pBZfAF2t8S4g3yy+lgCMAb7ZhmOjOI+LpR+tr IJQV4AS6RXaDW03QzOTO1rbw9+BHZDcUCYw+ra9glZF3gBnyK+uAVOK2/vif/AXk07UX JygD7IcT38gBaXlOTr+xMzIY97AXDK7mT8AWPSthCTECPGVA8Q27MOjvDuHmfHA7OD7r O4fQ== 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=FZQhXYqJSgJEDSXn37c2xwV+LPacb7suF3Saaz+sRuE=; b=g/GCb5pPio9OhzmdxfItmkkTsaRxUigNx/kJKxE3vaJ1dta/mOGRrDmfiAdk0QnQrA XxklXfiN04wO4ISDqRp5+Z//bHYLPBGdVpDP2Yrvg0ZKBLYpuniKsLCfvSgPWtam6Fyj 6OlMplm6Ln577c2Gq2ywI9IOVkEsrpmSSeBAEfOtI7HpbPwmqMO+uRLuAeekDalzLydQ E3Rwh+nxZGqFyc5J2yfW58UI6uKYATCUZKpJx0BEcqAhZNOQ6jF99TJXYVsfiOyGlvsc 6vK/oM3Q9vr1zEq/+TP7BKUcqcZmfx7jPFsEA4EouuaZY4iPQ/52R2E+Z/l24RR2rxgg CgdA== X-Gm-Message-State: AOAM5311kCud1eEAbQqJ3lBKDWUslB51s9kt1pT029Q4M4/BLlmURvTs +8iXkOKM7fHqEVKNLDU94Ghsz7ST9FPVxiYUyk+q9NDU X-Google-Smtp-Source: ABdhPJwDYBlTb6a5cqeTPnN+HedTtLqH7vUXZaykVmPEo2T7yqi6W9XmvdXuUyjEFjo15YVWc/XfSImbidBdP3Gkt54= X-Received: by 2002:a05:6638:1919:: with SMTP id p25mr10394703jal.115.1623541523971; Sat, 12 Jun 2021 16:45:23 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Sat, 12 Jun 2021 19:45:13 -0400 Message-ID: To: babel@ietf.org Cc: babel-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000d0857105c49a37fb" Archived-At: Subject: [babel] IPR Call for draft-ietf-babel-v4viav6 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, 12 Jun 2021 23:45:27 -0000 --000000000000d0857105c49a37fb Content-Type: text/plain; charset="UTF-8" It appears that I neglected to do an IPR call for this draft. Anyone aware of any IPR in the draft that has not been disclosed to the IETF should post to the list. The author must post indicating whether they are aware of any such IPR. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --000000000000d0857105c49a37fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It appears that I neglected to do an IPR call for this dra= ft. Anyone aware of any IPR in the draft that has not been disclosed to the= IETF should post to the list. The author must=C2=A0post indicating whether= they are aware of any such IPR.

Thanks,
Donald
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0= 2386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com
--000000000000d0857105c49a37fb-- From nobody Sat Jun 12 19:22:01 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BB83A2B3E; Sat, 12 Jun 2021 19:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2N5V6L5nw8s; Sat, 12 Jun 2021 19:21:54 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6829E3A2B3D; Sat, 12 Jun 2021 19:21:54 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id q3so12592789iop.11; Sat, 12 Jun 2021 19:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vnOgL7gRPCKA7bcYRlfR6wHLn2bFNPxhiXOBhTqObxI=; b=NquhPjLb8arGScLG0FHsVT7BsDMjbIgcQqlXw2wZR72LMbET1Iv8n8jYxJjcfAVPF/ nRkqrXLTJ3jTbmFwp5tsUgKbKWt26ik5WcxwJJVJjufvgSCf/r9o5S6wRiooRBzAZd96 KutL6Hc22YdVI+p720Kayq4zlXPm+jdZMxwaj5U81lPa34vCCdN9L+yNkPos9ys7K2rI BkRWl3xNSh9vw3SDr2Dk3bINps9vq7yOREX9W77itnAJ87loaY6NeWj83GEGf5dkUUAo MxlN/5dQldtulx178pZo2q/sQDJMQrnYtLxZi2VW27D+2imjl6OPM0g/0k7l2TAPhv/P scAw== 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=vnOgL7gRPCKA7bcYRlfR6wHLn2bFNPxhiXOBhTqObxI=; b=SlHvjHbXvhbTUqlR82qmenG8prKqchhUesg5FQkxflAhQAyUjiZgazeNbPqRCja9GH DVEL19vRJEKuGTniDSPD2YTy9ejqHBobXyaHtnGXzUDlxP1zq/Gxo3ZgJ0py7aHdgkQg r3N9ZSWdEFt8WUeRAwoWxsfCokQIwqpNhKSiRfX+zmCjCajnBzr9Td9Z1Kfvv8nIFjiZ oWfUUm1hQEQa58qYqr7BjNwcq9AEiGjSxNYr9LTQM+sjvvm3gIgu82BF49Kox7J4PIQ4 dyNis3M9lRAlvD3/SCDU1ta/pfEyvzCgDpPWocxrjTAEpW3OPJGKMPmfRS1/dFj2ggWO NYhA== X-Gm-Message-State: AOAM530sldyFBNiOu5mwzoCwtH61R/Gnz/euz7TIKphS9diOUfK6SOJx RRV4C3zINy7Ta0s+DoUqeT5aagU2cudf7YXhHR0= X-Google-Smtp-Source: ABdhPJwXOQQHpTzWUcWHY7SGwNjGBWaHpuXEYaV5nG9Sxjxx7UN3KLm2bODXpFuZHWF8wveN0sKzzPiNpPlwMnArNiI= X-Received: by 2002:a5d:8190:: with SMTP id u16mr9357486ion.158.1623550911972; Sat, 12 Jun 2021 19:21:51 -0700 (PDT) MIME-Version: 1.0 References: <87v96nyzsv.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Sat, 12 Jun 2021 22:21:41 -0400 Message-ID: To: Juliusz Chroboczek , Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="000000000000620a6405c49c6799" Archived-At: Subject: Re: [babel] Shepherd review of draft-ietf-babel-v4viav6-03 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, 13 Jun 2021 02:21:59 -0000 --000000000000620a6405c49c6799 Content-Type: text/plain; charset="UTF-8" Hi, One more thing I had overlooked: If a draft obsoletes or updates an RFC, this needs to be mentioned in the Abstract and Introduction. The header information on the title page says this document updates RFC 8966. But the Abstract and the body of the draft pretty consistently say that it "extends" the Babel protocol. Generally, the IESG has been getting stricter about the use of "updates" although it does not have unanimous agreement on whether or not "updates" can be used when a draft extends a protocol. I think the simplest thing would be to remove the "Updates: 8966" header from the first page. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Wed, Jun 9, 2021 at 10:09 AM Donald Eastlake wrote: > Hi Juliusz, > > Latest version looks good. See below: > > On Wed, Jun 9, 2021 at 8:42 AM Juliusz Chroboczek wrote: > > > > > I've done a review of this draft as Shepherd. See below: > > > > Sorry, Donald, I'd missed your review. I've just submitted a -05 that > > takes it into account. > > > > > The introduction is generally quite good but, in the first paragraph, > > > some wording feels just the slightest bit off. For example, it appears > > > to assume that ND or ARP would always be used when the next-hop to > link- > > > layer address mapping might be statically configured > > > > The introduction has been rewritten. While this section is > non-normative, > > and therefore doesn't constrain implementations from doing what you > > suggest, I've added an instance of the word "typically" as a concession > to > > implementations that might do what you suggest. > > > > > Globally TDB -> 4 > > > > Done. > > > > > REFERENCES > > > > > > Update reference to RFC 5549 to RFC 8950. > > > > Most respectfully disagree. The reference is used in the following > > sentence: > > > > The extension described in this document is inspired by a previously > > defined extension to the BGP protocol . > > > > It is important to cite the older reference in order to give proper > credit > > and be clear who got there first. > > That makes sense. But I suspect other reviewers may trip over the same > thing. > > > > Section 2, 1st line: It is more common in IETF documents to say > > > "dual-stack" rather than "double-stack". > > > > Done. > > > > > anoncing -> announcing > > > > Done. > > > > > annoucements -> announcements > > > > Done. > > > > > administatoris -> administrators > > > > Done. > > > > > next hop -> next-hop (7 times) > > > > Thanks. I've checked that I consistently use "next hop" when it is a > noun > > and "next-hop" when it is used as an adjective. This is consistent with > > RFC 8966. > > OK > > > > eg. -> e.g. (twice) > > > > Done. > > > > > It would be preferable, within the Normative and the Informative > > > References, that RFCs be listed in numeric order. > > > > In the XML? The plain-text version is being sorted by xml2rfc, so if > > there's any issue, it's a bug in xml2rfc. > > Ahhh, I was too quick and didn't look closely enough! The informative > references are in numeric order, including RFC 0826. But the normative > references have an RFC 792 :-) which got sorted after RFC 2119. > Obviously too minor to bother with now but I suggest that in some > future revision you change that to RFC 0792. > > I'll go ahead and do the PROTO write-up and request RFC publication. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > > I notice this draft generally uses British spelling. I think that's OK > > > as long as it is consistent. > > > > This is consistent with RFC 8966. > > > > Thanks, > > > > -- Juliusz > --000000000000620a6405c49c6799 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

One more thing I had overlooked: If= a draft obsoletes or updates an RFC, this needs to be mentioned in the Abs= tract and Introduction. The header information on the title page says this = document updates RFC 8966. But the Abstract and the body of the draft prett= y consistently say that it "extends" the Babel protocol. Generall= y, the IESG has been getting stricter about the use of "updates" = although it does not have unanimous agreement on whether or not "updat= es" can be used when a draft extends a protocol.

<= div>I think the simplest thing would be to remove the "Updates: 8966&q= uot; header from the first page.

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


On Wed, Jun 9, 2021 at 10:09 AM Donald East= lake <d3e3e3@gmail.com> wrote= :
Hi Juliusz,
Latest version looks good. See below:

On Wed, Jun 9, 2021 at 8:42 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> > I've done a review of this draft as Shepherd. See below:
>
> Sorry, Donald, I'd missed your review.=C2=A0 I've just submitt= ed a -05 that
> takes it into account.
>
> > The introduction is generally quite good but, in the first paragr= aph,
> > some wording feels just the slightest bit off.=C2=A0 For example,= it appears
> > to assume that ND or ARP would always be used when the next-hop t= o link-
> > layer address mapping might be statically configured
>
> The introduction has been rewritten.=C2=A0 While this section is non-n= ormative,
> and therefore doesn't constrain implementations from doing what yo= u
> suggest, I've added an instance of the word "typically" = as a concession to
> implementations that might do what you suggest.
>
> > Globally TDB -> 4
>
> Done.
>
> > REFERENCES
> >
> > Update reference to RFC 5549 to RFC 8950.
>
> Most respectfully disagree.=C2=A0 The reference is used in the followi= ng
> sentence:
>
>=C2=A0 =C2=A0 =C2=A0The extension described in this document is inspire= d by a previously
>=C2=A0 =C2=A0 =C2=A0defined extension to the BGP protocol <xref targ= et=3D"RFC5549"/>.
>
> It is important to cite the older reference in order to give proper cr= edit
> and be clear who got there first.

That makes sense. But I suspect other reviewers may trip over the same thin= g.

> > Section 2, 1st line: It is more common in IETF documents to say > > "dual-stack" rather than "double-stack".
>
> Done.
>
> > anoncing -> announcing
>
> Done.
>
> > annoucements -> announcements
>
> Done.
>
> > administatoris -> administrators
>
> Done.
>
> > next hop -> next-hop=C2=A0 =C2=A0(7 times)
>
> Thanks.=C2=A0 I've checked that I consistently use "next hop&= quot; when it is a noun
> and "next-hop" when it is used as an adjective.=C2=A0 This i= s consistent with
> RFC 8966.

OK

> > eg. -> e.g.=C2=A0 =C2=A0(twice)
>
> Done.
>
> > It would be preferable, within the Normative and the Informative<= br> > > References, that RFCs be listed in numeric order.
>
> In the XML?=C2=A0 The plain-text version is being sorted by xml2rfc, s= o if
> there's any issue, it's a bug in xml2rfc.

Ahhh, I was too quick and didn't look closely enough! The informative references are in numeric order, including RFC 0826. But the normative
references have an RFC 792 :-) which got sorted after RFC 2119.
Obviously too minor to bother with now but I suggest that in some
future revision you change that to RFC 0792.

I'll go ahead and do the PROTO write-up and request RFC publication.
Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.co= m

> > I notice this draft generally uses British spelling. I think that= 's OK
> > as long as it is consistent.
>
> This is consistent with RFC 8966.
>
> Thanks,
>
> -- Juliusz
--000000000000620a6405c49c6799-- From nobody Sun Jun 13 05:08:02 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D0F3A182F; Sun, 13 Jun 2021 05:08: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, 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 IVMQQBA2uCrf; Sun, 13 Jun 2021 05:07:59 -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 1600F3A182B; Sun, 13 Jun 2021 05:07:58 -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 15DC7suS032627; Sun, 13 Jun 2021 14:07:54 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A17C2D309C; Sun, 13 Jun 2021 14:07:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9lM_eZUBJMZy; Sun, 13 Jun 2021 14:07:53 +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 C7864D309A; Sun, 13 Jun 2021 14:07:52 +0200 (CEST) Date: Sun, 13 Jun 2021 14:07:52 +0200 Message-ID: <87v96idl2f.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: babel@ietf.org, babel-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 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]); Sun, 13 Jun 2021 14:07:54 +0200 (CEST) X-Miltered: at korolev with ID 60C5F51A.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60C5F51A.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 : 60C5F51A.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] IPR Call for draft-ietf-babel-v4viav6 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, 13 Jun 2021 12:08:02 -0000 > The author must post indicating whether they are aware of any such IPR. I am not aware of any IPR related to this draft. This draft is inspired by RFC 5549, so any IPR related to that RFC might apply. I am not aware of any IPR related to RFC 5549. From nobody Sun Jun 13 05:09:30 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFCD3A183A; Sun, 13 Jun 2021 05:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDGFc3FlLdLW; Sun, 13 Jun 2021 05:09:25 -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 6DA923A1834; Sun, 13 Jun 2021 05:09:25 -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 15DC9MUC000590; Sun, 13 Jun 2021 14:09: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 3DDD8D30BE; Sun, 13 Jun 2021 14:09: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 11drnbTg5mnk; Sun, 13 Jun 2021 14:09: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 B74EBD30BA; Sun, 13 Jun 2021 14:09:20 +0200 (CEST) Date: Sun, 13 Jun 2021 14:09:20 +0200 Message-ID: <87tum2dkzz.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs In-Reply-To: References: <87v96nyzsv.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 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]); Sun, 13 Jun 2021 14:09:22 +0200 (CEST) X-Miltered: at korolev with ID 60C5F572.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60C5F572.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 : 60C5F572.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] Shepherd review of draft-ietf-babel-v4viav6-03 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, 13 Jun 2021 12:09:28 -0000 > I think the simplest thing would be to remove the "Updates: 8966" header from > the first page. If that's okay with you, I'd rather add the mention. It's useful to be able to see related drafts on the datatracker. (IMHO, there should be a "Relates-to" relation for RFCs, to make the datatracker more useful.) From nobody Sun Jun 13 08:40:12 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3D23A1EAB; Sun, 13 Jun 2021 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=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 jK48TakZB3n6; Sun, 13 Jun 2021 08:40:04 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 2EBAD3A1EA2; Sun, 13 Jun 2021 08:38:57 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id i17so10031697ilj.11; Sun, 13 Jun 2021 08:38:57 -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=adoJdknondssdp5tNoAwGMUKd5VpW2GWkq6AXEnBHuw=; b=Ue8kyTgFtTtv6aGvFOsarR4VmaUkAI1odLbaAXgyDSOqIAN6mCiY1JQqLYJrjEeZzu t0PIAq/JU2jUcOyrn7p29Yz0eNPFoDur3HcZlqi6XsB71/ekgFW1oYJBLehODZis8/xR AoDq+H2ourAK/p23VPKLLLiNxUbsHngM8VOGCiQi77jvSjZznxsCE080IL+lAyibQqUd yKoFQas1k8TifmDeWcqIOUzCvUXD72Q+0KaQoYrlmbVV81pofyJsGXp9y22v39F9Angk lvppHxiAKc1G8x2EaVo6VWF82cOyuYwdPlPu8RokiLYOoLNIzFL77R7Y1YNM6ZCbbldY H4BA== 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=adoJdknondssdp5tNoAwGMUKd5VpW2GWkq6AXEnBHuw=; b=I6nn1RMotoyXJpINZDDez7a/tHxa8WxGbMqdXqm0BfR574l/mpE0yvB1C4IGkd3Omk zBCp8E+lerEsKa1nOvp9G+MeFCYE2u2ZbKfxU6lvvuo0HVkIXw38aeGCdos0op1jEDsU asovrscd/E2Hrp+GbGwoDo25VJDXnJjeEpVD6gBIhuXwhdSOxFgbaprQDM9KLnMAzreb e0AbwMiZRj1L5Md3bqO6prlz3M9Wk4T1ZhYj/pFfn3zgRS7G3VcMnn7g2dAhNGxJkeIg EeXZukWKUHjMX5xVw/VG4A9MQCQhVS9g8LwFtNa/0Eh1h7Vvo6NsaP0/6+9Z9Hxo4uK3 Ix2g== X-Gm-Message-State: AOAM533uEewIEVzk5+HLmw+1fB5XNAIcA8bPnenns9N/oJwMhPftN+AV XbVP052m0zABlpcGKUiYJoThn614YSRYx6VEn9s= X-Google-Smtp-Source: ABdhPJzDdeYHFWLlGYsZGzhwmUW9S/30on91JqF0i28whenxli6JdvsaY4SVe3fHhUlGAS9KkvAGwhEcLIgOWTYZsvc= X-Received: by 2002:a05:6e02:1068:: with SMTP id q8mr10999611ilj.276.1623598736448; Sun, 13 Jun 2021 08:38:56 -0700 (PDT) MIME-Version: 1.0 References: <87v96nyzsv.wl-jch@irif.fr> <87tum2dkzz.wl-jch@irif.fr> In-Reply-To: <87tum2dkzz.wl-jch@irif.fr> From: Donald Eastlake Date: Sun, 13 Jun 2021 11:38:45 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Shepherd review of draft-ietf-babel-v4viav6-03 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, 13 Jun 2021 15:40:10 -0000 Hi Juliusz, On Sun, Jun 13, 2021 at 8:09 AM Juliusz Chroboczek wrote: > > > I think the simplest thing would be to remove the "Updates: 8966" header from > > the first page. > > If that's okay with you, I'd rather add the mention. It's useful to be > able to see related drafts on the datatracker. OK, then you need to add something like "This document updates RFC 8966." to the Abstract, probably at the end, and "This document updates [RFC8966]." somewhere in the Introduction. > (IMHO, there should be a "Relates-to" relation for RFCs, to make the > datatracker more useful.) You are not alone in believing that the "Updates" header should be augmented by the availability of something like an "Extends" header. I think a "Relates-to" header is a bit too vague and judgemental. But this issue has been around for years now so I wouldn't expect a change any time soon. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com From nobody Tue Jun 15 05:04:41 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FDB3A2D2B for ; Tue, 15 Jun 2021 05:04:39 -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 sgyrtmvYCjhz for ; Tue, 15 Jun 2021 05:04:35 -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 DB4C33A2D28 for ; Tue, 15 Jun 2021 05:04:34 -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=1623758669; bh=xpGPlsb18ohsfg3NFhEVsTiE/9AZKy795vKaMuCL0Uk=; h=From:To:Subject:Date:From; b=YQUIBlNRmWpdZoaAl6UIkUyVYEoyWJaonPjXKuRkSyZf0ty/2Hwg6CI7fS/OckLDb iMv+l1hDgpFBjhvD/M9+n3wvtDf+0ljzonr+0s9i11XswsxVRvcy9sSOSoW/VdQYT2 0Pw0pm6zaBwbr3d/S+sGmrEZUh4qRVYw1m7u2CGwBm1UsIUDsUQqIuel3Rb8DyyBud MqwoRepF9lFz6790rkBnF8YAIkPPniQtACZDjx/Np6uLBxCP+5yZHdVPIKatzKCZwj 8ZjggkUivE3tpkgTaNuZ3ciGejNMvktNnGe60Uob8EyoBusKyf5DBPKMzC5PizxXt4 Sps4zyOsp3+IQ== To: babel@ietf.org Date: Tue, 15 Jun 2021 13:38:40 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a6nrs6gv.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] Investigating ICMP behaviour of the Linux kernel in IPv6-only mode 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, 15 Jun 2021 12:04:40 -0000 Hi everyone Juliusz poked me to take a closer look at the Linux kernel behaviour when sending ICMP messages in an IPv6-only environment, and figured I'd share the results here. This is relevant for draft-ietf-babel-v4viav6 when it's implemented on Linux-based hosts. What I found was that the kernel is perfectly happy to send out ICMP messages with an all-zero source address if no real address is configured on any interface. This can be demonstrated simply using network namespaces like so: # ip netns add ns0 # ip l add type veth peer netns ns0 # ip l set dev veth0 up # ip a add 10.0.0.1/24 dev veth0 # ip a add fc00:dead:cafe:42::1/64 dev veth0 # ip r add 10.1.0.0/24 via inet6 fc00:dead:cafe:42::2 # ip -n ns0 l set dev veth0 up # ip -n ns0 a add fc00:dead:cafe:42::2/64 dev veth0 # ip -n ns0 r add 10.0.0.0/24 via inet6 fc00:dead:cafe:42::1 # ip netns exec ns0 sysctl -w net.ipv4.icmp_ratelimit=0 # ip netns exec ns0 sysctl -w net.ipv4.ip_forward=1 # tcpdump -tpni veth0 -c 2 icmp & # ping -w 1 10.1.0.1 > /dev/null tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on veth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes IP 10.0.0.1 > 10.1.0.1: ICMP echo request, id 29, seq 1, length 64 IP 0.0.0.0 > 10.0.0.1: ICMP net 10.1.0.1 unreachable, length 92 2 packets captured 2 packets received by filter 0 packets dropped by kernel This is obviously not ideal for the behaviour we want in the v4viav6 draft. I've submitted a patch[0] to make the kernel fall back to the dummy address specified in RFC7600. In the meantime, this can also be achieved by adding the dummy address on the 'lo' interface of the Linux host (and if any other v4 address is configured on any interface, that will be used as the source instead of all-zeros). -Toke [0] https://lore.kernel.org/netdev/20210615110709.541499-1-toke@redhat.com/ From nobody Tue Jun 15 05:21:00 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238173A2DB0; Tue, 15 Jun 2021 05:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSOPzsnetJ62; Tue, 15 Jun 2021 05:20: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 4E0003A2DB5; Tue, 15 Jun 2021 05:20:55 -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 15FCKoDA019809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Jun 2021 14:20:50 +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 15FCKmou004885; Tue, 15 Jun 2021 14:20:50 +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 9DAB2EFC1F; Tue, 15 Jun 2021 14:20:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VsZXFCVVL_ah; Tue, 15 Jun 2021 14:20:46 +0200 (CEST) Received: from pirx.irif.fr (openroam-prg-sg-1-173-162.net.univ-paris-diderot.fr [172.28.173.162]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AAC7EEFC1D; Tue, 15 Jun 2021 14:20:46 +0200 (CEST) Date: Tue, 15 Jun 2021 14:20:46 +0200 Message-ID: <87mtrrwc81.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87a6nrs6gv.fsf@toke.dk> References: <87a6nrs6gv.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 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]); Tue, 15 Jun 2021 14:20:50 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 15 Jun 2021 14:20:50 +0200 (CEST) X-Miltered: at korolev with ID 60C89B22.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 60C89B20.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60C89B22.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 60C89B20.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 : 60C89B22.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 60C89B20.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] Investigating ICMP behaviour of the Linux kernel in IPv6-only mode 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, 15 Jun 2021 12:20:59 -0000 > I've submitted a patch[0] to make the kernel fall back to the dummy > address specified in RFC7600. > [0] https://lore.kernel.org/netdev/20210615110709.541499-1-toke@redhat.com/ Thanks a lot, Toke. After spending a few hours going through the maze that is the Linux ICMP code, I decided I needed help from somebody competent. > What I found was that the kernel is perfectly happy to send out ICMP > messages with an all-zero source address if no real address is > configured on any interface. The question is -- what is the behaviour of PMTUd implementations when they receive such an ICMP packet? Do they reduce the PMTU, or do they drop the ICMP as obviously incorrect? I'm going to merge the v4via6 code (I've reviewed it, and I think it needs a few fixes), and going to enable it automatically if there's at least one IPv4 address somewhere, including the loopback interface. Thanks a lot for the information above, that's very helpful. -- Juliusz From nobody Tue Jun 15 05:59:32 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF03A2F72 for ; Tue, 15 Jun 2021 05:59:30 -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, RCVD_IN_DNSWL_BLOCKED=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=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 wqAnI_PkJ6Gq for ; Tue, 15 Jun 2021 05:59:24 -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 7D95A3A2F6D for ; Tue, 15 Jun 2021 05:59:24 -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=1623761958; bh=ugnKrI2SkkuHa/rebJhVFvRllQlE+cppVcY8m+DBsx4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mzR6GFXHeH4MDw+vymvvMC2gpOw44Pj0wcKBiFTCYSAqB9qjr4u4iuugr3HPdaybp qffW476qsrQhbU1duB8zdMtQGrRfx2elLN37Wn9jojAqiPsIlUVBvqQVV9tcQ+WkhI xTjUDSAquzJYQOEid4WBfM6CqC0O8VcB5QwpZZ3J1inNLIENITClBTtqJ+HYyitQO9 2dqRqvX0HwmijNIyoBg+wGKGd7a3wQGJpTBxut29wY+kZbwlsKfyDlALTqzTuC6k4z heXDzoWQPvGkkXtVU92KbBPtYWb59bfH/IoLRcGjXjAURQxHlURTghGxHsPMIA0sNz BxIevGQyqh4yQ== To: Juliusz Chroboczek Cc: babel@ietf.org In-Reply-To: <87mtrrwc81.wl-jch@irif.fr> References: <87a6nrs6gv.fsf@toke.dk> <87mtrrwc81.wl-jch@irif.fr> Date: Tue, 15 Jun 2021 14:59:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874kdzs2qh.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Investigating ICMP behaviour of the Linux kernel in IPv6-only mode 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, 15 Jun 2021 12:59:30 -0000 Juliusz Chroboczek writes: >> I've submitted a patch[0] to make the kernel fall back to the dummy >> address specified in RFC7600. > >> [0] https://lore.kernel.org/netdev/20210615110709.541499-1-toke@redhat.com/ > > Thanks a lot, Toke. After spending a few hours going through the maze > that is the Linux ICMP code, I decided I needed help from somebody > competent. You're welcome! And yeah, that code does offer all the best in kernel-style indirection :) >> What I found was that the kernel is perfectly happy to send out ICMP >> messages with an all-zero source address if no real address is >> configured on any interface. > > The question is -- what is the behaviour of PMTUd implementations when > they receive such an ICMP packet? Do they reduce the PMTU, or do they > drop the ICMP as obviously incorrect? As far as I can tell by poking around in the code, the kernel will generally drop packets with an all-zero source; see for instance this check: https://elixir.bootlin.com/linux/latest/source/net/ipv4/route.c#L2139 I'll leave actually testing this as an exercise for the reader ;) > I'm going to merge the v4via6 code (I've reviewed it, and I think it > needs a few fixes), and going to enable it automatically if there's at > least one IPv4 address somewhere, including the loopback interface. > Thanks a lot for the information above, that's very helpful. Cool! You're welcome :) -Toke From nobody Wed Jun 16 15:04:56 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E24F3A003E for ; Wed, 16 Jun 2021 15:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsP_3Je1vP5Z for ; Wed, 16 Jun 2021 15:04:49 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C686D3A0035 for ; Wed, 16 Jun 2021 15:04:49 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 15GLrlH8001565 for ; Wed, 16 Jun 2021 18:04:49 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 397n81egev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 Jun 2021 18:04:48 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 15GM4lCb019716 for ; Wed, 16 Jun 2021 18:04:47 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 15GM4hfl019598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Jun 2021 18:04:43 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 8FB45400599B for ; Wed, 16 Jun 2021 22:04:43 +0000 (GMT) Received: from GAALPA1MSGEX1AC.ITServices.sbc.com (unknown [135.50.89.98]) by zlp30486.vci.att.com (Service) with ESMTP id 579F0400599A for ; Wed, 16 Jun 2021 22:04:43 +0000 (GMT) Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) by GAALPA1MSGEX1AC.ITServices.sbc.com (135.50.89.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 16 Jun 2021 18:04:42 -0400 Received: from GAALPA1MSGETA03.tmg.ad.att.com (144.160.249.125) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 16 Jun 2021 18:04:42 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.176) by edgeal3.exch.att.com (144.160.249.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Wed, 16 Jun 2021 18:04:35 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aNKFrNU5RajI6spPy/EUcAJFrTB0Tg7pS73rn9QfzecmYcyckgftV+30akM12EOZiAWeg6Zefxx3z6w3UmXrsWZsvAtR33ikYdBU3iuFKimY6cuyULHGHv8qIM5HsfE9S+jVB388HU6PMXZ+SnS+HLbFeDgHyTltHsVpi8gXS6+83ZDZl4EUrvq0f6C/hf3yAujN96E3IV2tcadja7YwqU1Q44Wyzz15R4O+et1OUNzTnz4D+qAdQ3j2QrjIlaf1nV6RSnk32/CwWmdCKX4+71EI+5rfiNcXOTnDe1g9Clc5PSSoFE56El3B1OSwkhHk1iR1+kf6YyO8+NBYrXAfrw== 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=EZBj+aZkYSG9OZI6ieFFZzSdAZ/RIINyXRN3mpBTFpU=; b=RC4boBxKjn0lIZeKSIrvwDYLvMeUiBEzC4RavV2lN2mhOTrE1wtDJ3h40Fx1HxA3oounNzOD6DQUvMQe/Z1Ek7xoqvAbqTjEBYTc/pIGQODK9WJcbeV3QdL0EFvQJrndzc9DnEzcfLPvOjDEFi36UTZpF6nP7ReYMxsA6tbJcn5FfqUOaVlj7HguISgcsPS9q7PWce7Vdd4OGW63eNdJ18kNqVWoXoJ6y++3eV2UhWPTtc4Fz7gfjSgUx1HBHoJGdDmnxQxNve0o7g3Uu2s7ME6KOxJEwksGe2SncEP/YDeXCNIf08BXL2aSXCsV+MIybx+579bHxAV30jrtOEDdNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EZBj+aZkYSG9OZI6ieFFZzSdAZ/RIINyXRN3mpBTFpU=; b=aNoEU1L98ZI3IRXvRmBnk/8STgt1Wpzkq/KLoyyh4q3cV4dHIn1MySpFTjso3mBh/GuG+27THEh0hicD+0gp+Fx7i3GVDoZOakSesKRJgG8coxOLpXhYR6KKSRAh/YZV5clqIgsEYU1P3WlAlZ8OqDRQs+I3CiYcQSEGLDr04Ho= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6478.namprd02.prod.outlook.com (2603:10b6:5:20b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.20; Wed, 16 Jun 2021 22:04:34 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::402e:8894:b968:f5a7]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::402e:8894:b968:f5a7%6]) with mapi id 15.20.4219.026; Wed, 16 Jun 2021 22:04:34 +0000 From: "STARK, BARBARA H" To: "'Babel at IETF'" Thread-Topic: DTLS Cached Info support in Babel Thread-Index: AddiviIkIceKTifmTW2xhiGnwBT1jg== Date: Wed, 16 Jun 2021 22:04:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=att.com; x-originating-ip: [45.18.123.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6bbacbb-bd72-4b20-8f57-08d93112b9ae x-ms-traffictypediagnostic: DM6PR02MB6478: 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: TKmu1sy9HjESylopDDfpFwCEA5ADE0nsp90Ups7vpq4pwxa0LIFLBybDgnFdDwX9vIIZ8CD1AKDqOm2r0sJvwl3hslC1x4j36zsS3pE56+jQRFO9bNSF2Py38Sk/BQDe2uKupst2HWQ9dOTZQFUSs2yoWq8vhegQp5E8ieJnqjvhJVzhMajcW5JgWlWHl2eTYNYrYUFbkgBDwnWI5Iexdmc2jcKOvT7ellzXyvgDHTZ5UCWCkWDqd6UEpsTn5+His+cebFytmUoW7mgmxSAoMMzOIO/BNe2XK3yhhD0YcjTTszwfrueFRMzWKwmmG/4pSpIr81SgFK/LrY0u0cyejRqOJis6V2A4Z7h/3B+kHBvUN8j1LJ13ExciF3BTdPPvzmzkMtPRmOStznqTEAGtX5wpoe4FkvJWGyxUTDlmNZ0bW3bya6/jzonPiN95SmVpPqQYTXQa3cmI9WQn7XKaQksXGUm/zx4B/BvYW47+2x4gmyZcHysb/J20ZVcuymwilsbTyN26ZoZbwoyXF7PF44oslHS4TjqfHy7vSzOTlWI1spfzL2f2b2hnAkImFnx1vzbSDhd5HLhzgTFe55JMQEFkI/9iXpVHowgmXAhQ7Lp8Ok23r+Me38LYlK7epC6eeJoo9x8tMYmFtJPO67xB1xaPVj9s2kRHpIq02xhPOC+/9ykuqBqgiFZqjtAGHuJ4VYKHXGrPzwby2jvqOb3g6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(136003)(376002)(39860400002)(122000001)(71200400001)(7696005)(83380400001)(6506007)(2906002)(52536014)(966005)(33656002)(316002)(38100700002)(478600001)(8936002)(26005)(5660300002)(55016002)(86362001)(9686003)(8676002)(186003)(6916009)(82202003)(66946007)(66476007)(64756008)(66556008)(66446008)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0E/kPJukKrwdeV1MMUtLJFhG7AHiVQxXrRF+F/yuklYhIDYUAAhkgZU0X6vh?= =?us-ascii?Q?M4tFS7eUPoT1ymfaOA730z0dRfsMPtDYhR1VHkcNVOfMax8K2ZkYQ71QZLDZ?= =?us-ascii?Q?dWtnpzts40ICFPGIf+3UK6mQhCzqJz/wwjPIIvgbx2jiZNfRZIHvFTMeiR+2?= =?us-ascii?Q?eDL564xToL/V/J4QjVC5LdEWLsFIIWsBkNCDNKMn9EJgE+P++FlQ5dPCLdAA?= =?us-ascii?Q?r84Zh+WPFiTsElTOnM71clTnlDlJvxTXFi4/9DYk3vX6wnFNxPKb1k1zIhYi?= =?us-ascii?Q?kOo7cwP7R6IoSFCXz2F4XuH2nv6MJOxUGG4ZzuJPN/lzdUYUmhalFDZQvlVC?= =?us-ascii?Q?PVhk5vmtib+MeqSjRiychAtBiqvv3yqeLw0F50GGGlsGXhjPfFuvmnDz6dI0?= =?us-ascii?Q?RnpepHFhzlVfkb9WNL47ZyHGDBo3b7cy9oQfFJcMlLO9uPAm1FeylFQ6rwvT?= =?us-ascii?Q?8lSqtMhGIJfD8HWTf39cCl9GBvRa5HUYOdelvOAdMsVwkyS3s1mbL7+lCquD?= =?us-ascii?Q?csLHVneJP2FJIcRoHrN901fI1zptelIfbmTKEleCFEWEDEgqerLcT8MzcOUO?= =?us-ascii?Q?43eOjNj7sIpVb9b+8DN4/Uwst0mYIfaq+mJj+vJ3eymUicagvNcocA6uUW7/?= =?us-ascii?Q?X59bVbuJEt0yPBphgSYzQg2cK3WO4qQvcrAv2SrjZIb1WQT3GIzc4rXkfcXZ?= =?us-ascii?Q?EPz15vOl87W1jo0BglR2uRJCPKQo0qSXB3t4VyOViQMne6d3cFSJJ8PnPm6o?= =?us-ascii?Q?mJ9FtxLTPBziNUAB30Mk7A6ciaVpdc0+UnO7eDP4PdEqdN1MQG9CviSFimD6?= =?us-ascii?Q?HXyDpcZI4v0QrCYSnyUiph6HE2/AKpzFh0IZjGFD8ADzlD6JbtiLYbfnp1RL?= =?us-ascii?Q?73/dKoo46m8my7c1qLGsoM3kZLAn7gifTkZ0Va0PdQgXC9aiwOyxA2dh4bE9?= =?us-ascii?Q?D9zXCc+H+l4jjBLSwF9J9fKUFDOHgpwv9VFfnWw28usLSo9JNmWC6SIOaNPR?= =?us-ascii?Q?WEoSQJJk5PR5guRKFXkSu+x0pwk9xXBJg3VkdGlbbL1+wcPdfCR0e/xTMkc+?= =?us-ascii?Q?tcZXyQe751qg4WyW4Cn+vmRnWHByWi1tPty3uFwwE1HFCtLULzASTYx/BKl6?= =?us-ascii?Q?vZsVU/m/TnAfrsHDopLKYPSGfnlXDA41v4XITV5FytagfU2Z1iFVNbvbzPVB?= =?us-ascii?Q?gZe6MZqpcySVpdHCeBxQRoLuJOHUBWDHuPZ63kqbYOE3aWTx57MWaIQk94yC?= =?us-ascii?Q?C/i4CVq/4p74+Nj5Ha8J9zGL7TjmqprS4vweA8WJFZf6tF5Hc4TZfIl1mQ4O?= =?us-ascii?Q?uY7d+RgMn6fsk+kTfYdKK7Ue?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6bbacbb-bd72-4b20-8f57-08d93112b9ae X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2021 22:04:34.2868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MMm+5aqD013kCfylKwfF9uweVoGxsnoOf0SVHlX3d4jWfHA6WYRUobC8M6Is6VD9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6478 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 54BC5520E15792B58D3096FAD3AC1691A7E97E82D5D319CDC690925BD52C43592 X-Proofpoint-ORIG-GUID: yzBqOZ40ABlmmjcwthaPXsXiXUFie2Ef X-Proofpoint-GUID: yzBqOZ40ABlmmjcwthaPXsXiXUFie2Ef X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-16_16:2021-06-15, 2021-06-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 adultscore=0 malwarescore=0 priorityscore=1501 spamscore=0 bulkscore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 lowpriorityscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106160124 Archived-At: Subject: [babel] DTLS Cached Info support in Babel 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, 16 Jun 2021 22:04:55 -0000 Hi Babel, On the YANG model, we're dealing with some questions around the parameters = included to support the Cached Information Extension and Raw Public Keys in= DTLS. This is briefly mentioned in=20 https://datatracker.ietf.org/doc/html/rfc8968#appendix-A Clearly (since they're only mentioned in an Appendix), they're highly optio= nal. But because it's there, we included the following items in the info model (= which is now in AUTH48, so I want to avoid impacts to that): - the ability to express support for raw public keys, and configure certs = that use raw public keys - a Boolean to indicate whether the extension should be "used" (per interf= ace)=20 - an ordered list of preferred certificate types that is (supposed to be? = can be?) used to populate the client_certificate_type and server_certificat= e_type extensions in the extended Client Hello message (per interface). Maybe this was all overkill for something mentioned in an Appendix. But, an= yway, here we are. I think we're ok on the first item (raw public key support). But for the other 2, there is some fuzziness. Do any of the DTLS implementations support the cached info extension? If ye= s, do they programmatically decide whether they enable/use this by default = on interfaces where DTLS is enabled? So whether this is enabled is just som= ehow decided by the implementation -- but we could allow that decision to b= e overridden by the user per interface? That would be consistent with the c= urrent Boolean. If none of the implementation support cached info are there= any thoughts on how this might be done? There's an IESG objection to sayin= g "Indicates whether the cached_info extension (see [RFC8968], Appendix A) = is included in ClientHello and ServerHello packets. The extension is includ= ed if the value is "true"." So I'm thinking maybe it could say "Indicates w= hether use of the cached_info extension (see [RFC8968], Appendix A; see [RF= C7924]) is enabled." Does this sound right? The ordered list of preferred certificate types (per interface) is more of = a problem It currently says: "List of supported certificate types, in order of preference. The values MU= ST be among those listed in the babel-dtls-cert-types parameter. This list = is used to populate the server_certificate_type extension (see [RFC8968], A= ppendix A) in a ClientHello. Values that are present in at least one instan= ce in the babel-dtls-certs object of a referenced babel-dtls instance and t= hat have a non-empty babel-cert-private-key will be used to populate the cl= ient_certificate_type extension in a ClientHello." Do any of the DTLS imple= mentations support multiple types of certs? Do they implement sending the s= erver_certificate_type and client_certificate_type in the ClientHello? If s= o, how do they populate these? If none implement this yet, any thoughts on = how they might do it? Should we allow the programmatic default to be overri= dden per interface (or is that just too much complexity for a very optional= feature)? Thoughts appreciated. Barbara =20 From nobody Fri Jun 18 11:34:54 2021 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB303A1DDB; Fri, 18 Jun 2021 11:34:49 -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.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <162404128945.21239.12883298645639166119@ietfa.amsl.com> Date: Fri, 18 Jun 2021 11:34:49 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-v4viav6-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: Fri, 18 Jun 2021 18:34:50 -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 Author : Juliusz Chroboczek Filename : draft-ietf-babel-v4viav6-06.txt Pages : 10 Date : 2021-06-18 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. This document updates RFC 8966. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-v4viav6-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 18 12:41:39 2021 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 075513A07C7; Fri, 18 Jun 2021 12:41:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Donald Eastlake via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Cc: babel-chairs@ietf.org, babel@ietf.org, d3e3e3@gmail.com, iesg-secretary@ietf.org Message-ID: <162404529701.7849.1107845222759769839@ietfa.amsl.com> Date: Fri, 18 Jun 2021 12:41:37 -0700 Archived-At: Subject: [babel] Publication has been requested for draft-ietf-babel-v4viav6-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: Fri, 18 Jun 2021 19:41:37 -0000 Donald Eastlake has requested publication of draft-ietf-babel-v4viav6-06 as Proposed Standard on behalf of the BABEL working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/ From nobody Fri Jun 18 16:37:33 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF83A155F for ; Fri, 18 Jun 2021 16:37:30 -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 qcU7W7nDTPeE for ; Fri, 18 Jun 2021 16:37:26 -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 2D0A63A155E for ; Fri, 18 Jun 2021 16:37:25 -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 15INbKWU003033; Sat, 19 Jun 2021 01:37:20 +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 13547110A52; Sat, 19 Jun 2021 01:37:20 +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 pER9GgiBxC9p; Sat, 19 Jun 2021 01:37:18 +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 E2314110A50; Sat, 19 Jun 2021 01:37:16 +0200 (CEST) Date: Sat, 19 Jun 2021 01:37:16 +0200 Message-ID: <87lf76zqvn.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Babel at IETF'" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 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, 19 Jun 2021 01:37:20 +0200 (CEST) X-Miltered: at korolev with ID 60CD2E30.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60CD2E30.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 : 60CD2E30.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] DTLS Cached Info support in Babel 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, 18 Jun 2021 23:37:31 -0000 > On the YANG model, we're dealing with some questions around the parameters included to support the Cached Information Extension and Raw Public Keys in DTLS. This is briefly mentioned in > https://datatracker.ietf.org/doc/html/rfc8968#appendix-A [...] > Do any of the DTLS implementations support the cached info extension? It's definitely not supported by OpenSSL. I haven't been able to find any mention of it in the gnutls docs. > Do any of the DTLS implementations support multiple types of certs? Raw public keys are supported by gnutls but not by OpenSSL. > Do they implement sending the server_certificate_type and > client_certificate_type in the ClientHello? If so, how do they populate > these? As far as I understand, you set a key on the session structure, and the behaviour will depend on the kind of key that you set. > Should we allow the programmatic default to be overridden per interface > (or is that just too much complexity for a very optional feature)? I'm a little confused -- isn't the cert type implied by the value of babel-dtls-cert-set-obj? -- Juliusz From nobody Mon Jun 21 07:19:36 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699E83A02F7 for ; Mon, 21 Jun 2021 07:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLGbfl7YwX4V for ; Mon, 21 Jun 2021 07:19:31 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0A23A02BE for ; Mon, 21 Jun 2021 07:19:31 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 15LEFE47040562; Mon, 21 Jun 2021 10:19:30 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 399wqeem4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Jun 2021 10:19:30 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 15LEJSWs010713; Mon, 21 Jun 2021 10:19:29 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 15LEJKMD010371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Jun 2021 10:19:21 -0400 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id C880140169C4; Mon, 21 Jun 2021 14:19:20 +0000 (GMT) Received: from MISOUT7MSGED1AA.ITServices.sbc.com (unknown [135.66.184.195]) by zlp27129.vci.att.com (Service) with ESMTP id B05A740169C3; Mon, 21 Jun 2021 14:19:20 +0000 (GMT) Received: from MISOUT7MSGEX2CE.ITServices.sbc.com (135.66.184.201) by MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 21 Jun 2021 10:19:19 -0400 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGEX2CE.ITServices.sbc.com (135.66.184.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Mon, 21 Jun 2021 10:19:19 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.42) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Mon, 21 Jun 2021 10:19:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zbu3zqVa7+k/yTrXKbKQwK8TpO7g86Q0ElyK6PdlH0FEZgPQoJXabeMvL5HWDeFcPBEkg0R+VNpLWGizIvNx8FgBKGHbzYtWYe3CWBZ6YDaf+eQC63AEKDlmsNUgOvRyfX0lg9NhmxVtjq1C7VMNliVHVgo7zZvI8sDJjGY+wbbAReqKDuK9jjwfHANo0kTMoGyQdobxGyqDJlu6gBHfiXOwF8e/izCj55M8c6GV9x/fP6d9UcTSMuDh9hQxHpP/ifF3ArHQdNrXPOe9GJUgOJkn9mEfqq7h7q3TKwECGztUFMo6MkcT2BbOKq9/UBMyaB1iZsxLHeiDUzI0V5kQHQ== 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=hhkKguXA5v1kghTP/rpkdtaL95UGzXYrDVesM0rpEPo=; b=oKMwOt1ZLKVHmL2bJ/GuoO23If6raeEiTt/9BjhAnvUjfml27s9kk+WdfI2rIw1eK2GoY0ks0cCsRJVBm0S6fqYJqiBr+jtqAbN+k2zzx7FpAB6OIr95QVElxvjHeA8QwHmsuuEQlTbE822+gefcu8OUZnWZLiQPP29JemUGMq7/rNBfM2C0Lp63V1U3FEAx8vKzmuK10RlRlgY2yyqyTiojCRW062/H4jZzLUOvicK2MG35KZj2y2Y8SgdUe+iIdwjmqndI2kCxjmiTYNybLxE7ezB0AAAqLAKodaXPLnnSppNxkuz0U0rDAW710SuER6jJ7eVwSBLzNRXVLB6bxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hhkKguXA5v1kghTP/rpkdtaL95UGzXYrDVesM0rpEPo=; b=UGFEU/5pa5/o3Z5AG6bHxt8CaBMhxW+FiBnfW87Ywy0pP0/LN9VxRiRNMFmNJbcSCoYkp+/u1rOrZOges+futY3wgXUQJ+GFHxch6kVhEWfJzcJ6DPJE2f6JpHOYiqtJeGqmAy+ITKpAtMxPVr/WbvjE/Kd1KRgMUvSZwpJO9lI= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB4604.namprd02.prod.outlook.com (2603:10b6:5:28::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Mon, 21 Jun 2021 14:19:07 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::402e:8894:b968:f5a7]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::402e:8894:b968:f5a7%5]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 14:19:07 +0000 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'Babel at IETF'" Thread-Topic: [babel] DTLS Cached Info support in Babel Thread-Index: AddiviIkIceKTifmTW2xhiGnwBT1jgB3LzcAAH8WMSA= Date: Mon, 21 Jun 2021 14:19:07 +0000 Message-ID: References: <87lf76zqvn.wl-jch@irif.fr> In-Reply-To: <87lf76zqvn.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: irif.fr; dkim=none (message not signed) header.d=none;irif.fr; dmarc=none action=none header.from=att.com; x-originating-ip: [45.18.123.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b0ee925a-8810-4dbd-529f-08d934bf87d0 x-ms-traffictypediagnostic: DM6PR02MB4604: 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: 074yXlTXQ9Cm9r5lN2BUCy7LiG1ka6Kn4cFx0vzlV39o/sMgB8MB0PtcM0Pl1HJ9WIucigNytfl6czmL3uiaybp8pNFR4KbAz4i0Kt0FtswlGrf5AQobpIYhJVnKVolBCc9yT5AO899jfypiWsCNvrWTn8Lento8Wwqk3N5TotJqmKuss8zHhrB0l9ZPRUDtGkbCHcdug3BluCbA82IJNA6hRBbd+fluIeHFmndLq+6Le8028YLTXsRP5wLFEa+8Rlv0X7cv8kuYRRPNcgXahGSnXW1/MkQNGYg23zeEnXjXwUprikbJzZjIaXDJtH7fZXeR10A3jELS+A9fnE0yXZXdo1gZoJy1EbH2AtgwiaNU40Vq4FuZIJlac/b9/Ka22NwYSltZzy/S0sRgL/YY48OTiz7P2/STyyBnFlB/dmbaT+baD8TafgjcexhBrknHLJ3hcmnxSIDvJdm3YX5omx4hmZb3qE+jqbxdtOWUuKbol4cRTRmlgrdsIBDRTF/GlGVtgDU/aCi++KyZobgbFbDIQBgm11C4nHjHmUb4qC4a+MT9bBRZXzP4O69yeXvW+m0niS68HiBTESgv0wRO1aKlNZnxFZmZAtCykk3Ljis= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(376002)(346002)(136003)(39860400002)(316002)(33656002)(9686003)(5660300002)(82202003)(83380400001)(186003)(64756008)(6506007)(6916009)(66946007)(8936002)(71200400001)(8676002)(122000001)(38100700002)(76116006)(66556008)(86362001)(66476007)(26005)(52536014)(7696005)(4326008)(2906002)(55016002)(478600001)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?zAdYb4WLzdP4b5+8Gg8JPjTClyjDkjOyIOEgf5DdnOooRgnXWsmQ3umM8WlK?= =?us-ascii?Q?wOIUArcxRR8bm+yNTyW3CYlYqCcQrxfGF3aaKuluLlZaaI3UDHYOsO7/OHhw?= =?us-ascii?Q?ASDvDnHK+nHwLt297X41oGCZvBQ30y06eIrvR+Yit2rMYrUNzcBNUnHU4lzY?= =?us-ascii?Q?BaxenWOS5UFoBH1m5ZW6vAZ69nI0hKxcIB0Z2LZonRNAvznDic3EZalf7Dru?= =?us-ascii?Q?fnWDBN0Dz/PMuyXKhfBooN3XdQVGH8PTGGGVUkiwVB+xE3x0EjQmUdLWGeNv?= =?us-ascii?Q?Z+iH4e+2ZVe6ANcRua9plAtK/h1zNGEphqacdMh1Q54/HbZ6ubkHWVzSziR6?= =?us-ascii?Q?k6DlGBlfB+2WeqfTx373NghzNf20AqPfD0E7mzFFhdZBVLMdMV2bYMa4dRno?= =?us-ascii?Q?zGaL1WApXnM6Az9XMWaqSb+sFbboJnzjt0dVTGEfn5GFb6R/7XIUyOzTsD/q?= =?us-ascii?Q?rLp2XdlXtMKzSp/q/HHYAh+AlosCUvt41U5+jn6qQdF7UMmIL+ewG9vq+fpu?= =?us-ascii?Q?Ej4sYvmQqZN/1uiszPZ7YFgPTo0ruJz27Y79WsdAVJBwrnmEWfJrUMLWuY22?= =?us-ascii?Q?fP39lESbH4GI5h/RVHopQwB4SxIkFIsiH5ekzZJilpCXF74m8kgWB2fDmPCQ?= =?us-ascii?Q?JXn5g8Q7leGA8mjvBRumUok6qjmS/1qG7CWv0xmQ85enig5BLpq9ShlZaEz2?= =?us-ascii?Q?7LUV1+9/K6IDll3IlA3L11Oh+a5CArZNbERUC3rgGptTiPr1I92wDVVrN7HC?= =?us-ascii?Q?/IEMJHIv8WKuIyYdss+3x1VmrRFeEd3wEmWgJwVvHyb5fjBWIOFy+ZBy+ElU?= =?us-ascii?Q?ZNkq2sza1YrHdjcA7+hGNdgTF8hTZBGwdSCPyXzhMgc65B3gY/XkWoifkAR0?= =?us-ascii?Q?CIaQXFNR6YRHieZWEbNY5Yl4MyICt7AmjZhCOlmeeAs3nlY8M4yXMXV2E0rp?= =?us-ascii?Q?rjquWy5oH/fNtOoahtiJiNiHXpeMEuTBQCJMEyQ8/WmbXeVS2EbyNv7L+the?= =?us-ascii?Q?aAQsbA6f8pWy4myl382BZ08l2XpT4wCOgORCxQr8KFAya+f89rQ/TMyqP8/a?= =?us-ascii?Q?rE1qoqf27SoEv1GNu7A+EyJAx9uEVL7+N/vPyCDs04hDt4R/GIdaBrzByCsn?= =?us-ascii?Q?UBCs362Izwc7gK4GspZDOeTHxucB1AnJCkBIQM5E/Li+6Hpod9JsGTbbkOLS?= =?us-ascii?Q?jUWAXsMbzplTffbBlPrvErvaXAI0md0fR2/TeLAXWpZyboLIIVoyRaeQRoE9?= =?us-ascii?Q?R2IgGLI2pM6npkIYAewkBvhsZXsnG1QXg+LBUfonh8pYrBrVSKD73jsjPV/9?= =?us-ascii?Q?Kgo=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0ee925a-8810-4dbd-529f-08d934bf87d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2021 14:19:07.0664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dkmujJbo1s5Snegs2ee3STbNg/crFwfAXnTTrVMTtMpw3bnhupY0bouuDay49Udu X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB4604 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 6EE71DF73D66260B33714DCE8E44BB898AE4038C72D4CAA3441A6E8E7C6A2D852 X-Proofpoint-ORIG-GUID: db7l19_aNpjgHTcvOxFKqnlRKEerhbIW X-Proofpoint-GUID: db7l19_aNpjgHTcvOxFKqnlRKEerhbIW X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-21_06:2021-06-21, 2021-06-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 lowpriorityscore=0 adultscore=0 suspectscore=0 clxscore=1011 mlxlogscore=999 malwarescore=0 mlxscore=0 bulkscore=0 priorityscore=1501 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106210085 Archived-At: Subject: Re: [babel] DTLS Cached Info support in Babel 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, 21 Jun 2021 14:19:34 -0000 Answering the last question... > > On the YANG model, we're dealing with some questions around the > parameters included to support the Cached Information Extension and Raw > Public Keys in DTLS. This is briefly mentioned in > > rfc8968 appendix-A >=20 > [...] >=20 > > Do any of the DTLS implementations support the cached info extension? >=20 > It's definitely not supported by OpenSSL. I haven't been able to find an= y > mention of it in the gnutls docs. >=20 > > Do any of the DTLS implementations support multiple types of certs? >=20 > Raw public keys are supported by gnutls but not by OpenSSL. >=20 > > Do they implement sending the server_certificate_type and > > client_certificate_type in the ClientHello? If so, how do they populate > > these? >=20 > As far as I understand, you set a key on the session structure, and the > behaviour will depend on the kind of key that you set. >=20 > > Should we allow the programmatic default to be overridden per interface > > (or is that just too much complexity for a very optional feature)? >=20 > I'm a little confused -- isn't the cert type implied by the value of > babel-dtls-cert-set-obj? The babel-dtls-cert-set-obj can contain multiple certs, and each cert has i= ts cert type (so it's possible to have certs of all types). In the abstract= TLS case, it's possible to envision a use case where the TLS client tells = the server it supports the server providing X.509 and raw public key certs = with X.509 preferred, and saying that it (the client) only has a raw public= key. So the TLS specs allow for this. But in the specific Babel DTLS case,= it would be rather illogical to configure the routers asymmetrically. None= theless, the flexibility exists in the info/data models. Which isn't necess= arily a bad thing. It just means (IMO) these parameters are highly optional= and we shouldn't put a lot of effort into perfecting them. Thx for the ans= wers. That confirms what I was suspecting. - Barbara =20 > -- Juliusz From nobody Fri Jun 25 10:58:42 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22C13A0DDC; Fri, 25 Jun 2021 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQwEOyeknt8P; Fri, 25 Jun 2021 10:58:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68923A0D7B; Fri, 25 Jun 2021 10:58:29 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 15PHsmqK011221; Fri, 25 Jun 2021 13:58:28 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 39d242259c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Jun 2021 13:58:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 15PHwPf9012289; Fri, 25 Jun 2021 13:58:25 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 15PHwMb3012215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jun 2021 13:58:22 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 2A6CE4005C1D; Fri, 25 Jun 2021 17:58:22 +0000 (GMT) Received: from GAALPA1MSGEX1BD.ITServices.sbc.com (unknown [135.50.89.105]) by zlp30486.vci.att.com (Service) with ESMTP id 8FEF54005C1C; Fri, 25 Jun 2021 17:58:21 +0000 (GMT) Received: from GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) by GAALPA1MSGEX1BD.ITServices.sbc.com (135.50.89.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 25 Jun 2021 13:58:15 -0400 Received: from GAALPA1MSGETA03.tmg.ad.att.com (144.160.249.125) by GAALPA1MSGEX1BB.ITServices.sbc.com (135.50.89.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Fri, 25 Jun 2021 13:58:15 -0400 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.45) by edgeal3.exch.att.com (144.160.249.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Fri, 25 Jun 2021 13:58:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gAOhyB/50OHAnDItQnyheGVIlfQcajVcVsIyyFspAnsBzpH6rorENBuOjzQkrav420t1lLNyy/H8mSw8EewmmwQ46FWGVBiE1fs4lZTtgcUJDDpiuzj+4A/0SHSUyx5AT2oPrma1tuUC0JgAu30Kabx7lMlGc/xKRSmlmOL8BOwMToRA8HnP3C6DgzvDBOsauqa+jFNd/koidY/mwBZGrLm4pv/kLy+zNLB4puj8diB1UjDoUI6YAxTTyNNJYrVU+0a0ffu5HSNlfr20x3U0cnQ81E1K7QMturYiAguoviZLxHkH001nZ2RK81M46yJyswBi2+wlyLeHEW0jKR94TA== 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=PtRzgHbzGsIws+E5GYbCF/axBm3Oj3uRn1ywUos1lj8=; b=L3bGkKMsieYpkGX1ZwGcica6Vd7GCj+WUU6E36E8+UHOlmW5ipEC4mJ/3EquBgwKCy0M2k9Wryqph6Q8B0pRuMMPu4iUkpYb8qM6SvOBnf+PjyCYSQZZ5/94tFcLHRfQzO+sRFdm9xTBTm5ElWUUd1Te0GWjYFw4VZwzHk+KB9DQFWp7k4A5G9BxDCF76ykEAZVXLAvJ+9pfvLCYSDOtfAYhWVTuBcWHLpxlzen00IVPKPXnOZUvLt1IVo5WQh5gT959OXL5M22wTUHwuE+6h3NhihP6KuTg9Q1AZ9W/laEFxdrGWsNt/xVq7rPHe/KQQuRodbP8aUjgsNPNj5oPkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PtRzgHbzGsIws+E5GYbCF/axBm3Oj3uRn1ywUos1lj8=; b=bnM9/QCbvGJVBXQ2SZhhU7yhiqTxcyL37DAJtU6PmDgO7Xb7JBwYuoRNaa49c7OhRsCq27J3X9cj83sza+GANwhs49cEp6FbbBcUUQKJBbWU6HIAliKxEVgytYZMKSg/o588bBx3+D3GzTnx22QCpgDIMydFGPuI2UFLGIBnztk= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM8PR02MB8007.namprd02.prod.outlook.com (2603:10b6:8:18::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Fri, 25 Jun 2021 17:57:59 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::402e:8894:b968:f5a7]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::402e:8894:b968:f5a7%7]) with mapi id 15.20.4264.023; Fri, 25 Jun 2021 17:57:59 +0000 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" , "'Benjamin Kaduk'" CC: "'babel-chairs'" , "'Donald Eastlake'" , "'draft-ietf-babel-yang-model@ietf.org'" , "'The IESG'" , "'Babel at IETF'" Thread-Topic: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT) Thread-Index: AQHXTS4CuDmmB38OPU+jsEJ9gN86I6sKYL4AgBrQXxA= Date: Fri, 25 Jun 2021 17:57:59 +0000 Message-ID: References: <162148379451.10850.9563671396439074857@ietfa.amsl.com> <99514803-6C88-40F8-B924-315945B052C1@gmail.com> In-Reply-To: <99514803-6C88-40F8-B924-315945B052C1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com; x-originating-ip: [45.18.123.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07155639-9395-472c-8968-08d93802c4ec x-ms-traffictypediagnostic: DM8PR02MB8007: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V4kTBbpAT1uyJ8eYH9HhrfhbeblcYxvKUTMZNmbSbJLqrHNUwecJjydF0IwaFp4PKX5dJQvU8wvDIsq4nqu0o2w194GCo1EtkjaHIpJkeYorVRbwP2lY+VuOECj4UVoele7qdA2iBfI1jsB+yEJ23yw2PZ9dGdafK8ypYiZcXd+mik2CnqktbE7lxtR1t6+5bJkB+sMGp5C/pY5/WW2EshjZGK5mzjRZvqS9hTrxSVw7B4KgjoftXO5+4vFiY2Gmxi3jBeUq5rDOWyVwIF2UEB7n30EyszrzflcKaUEuI5B0Ukc4XT0p2tMak+Iy40+3vgVN1TGylZVO1vVvkmARtHCBzzrC5MTKyPAk2CIVQs/eLTal6iWwbdVLMcLssq8uTGukWZpegEWGzrewruEYjy+GT1sfOntx6h8UH9VMv1aKOWX/mejBNp7uGb7W7ftyMU5YyjRWfKhqbwYLrBEmFi2fNG83BkLx3Shi7c7HfQ03q2TMElNg2VQaF+bMvMnx+/BS0q5r0VLcmHDl2MaEwEvbnPc++7TSmPVnFfG+PHj5x/gNZEdGYQxYSsteBgniRr1AF94WZYjBzCMAcNQ1Ze1NS7edodUUQkhAT4x4F9mCSSHeUmX6FIvYJfKjssfCUVHAQNnx2s2VWWlZszMIRS67topZVS0HLgJ+u+lXRvcsBwkXuO75J1efOqCPMR5bwFVxoxnfZqA0HpKPSPtJs6Vl22EhnYi2fWWU4fbNy6h+0ysYtUZKhqTCHGO9w29B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(9686003)(2906002)(82202003)(66446008)(7696005)(66556008)(64756008)(122000001)(4326008)(66476007)(966005)(478600001)(9326002)(71200400001)(5660300002)(30864003)(55016002)(38100700002)(8676002)(8936002)(166002)(110136005)(52536014)(186003)(33656002)(86362001)(316002)(76116006)(66946007)(54906003)(53546011)(6506007)(83380400001)(66574015)(26005)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?tgiG+nJUJNO0DAmT4TAmnqQl4p4nN9Ow0ZmtcF7K++un5UE8g6j5rdgo21sX?= =?us-ascii?Q?bQVSMKWREKZznKNzl29ZCajcpfpd0sOjOAtWhz5GJMKSzUjxu/yW8/tnrPU0?= =?us-ascii?Q?e8vwMU7TL4axsKgNRE0BKZbMt1yAMr+Ycye1v2pV+ER+Ki0drzz6GMdMU+mC?= =?us-ascii?Q?Bud1voRardZ4dinjRKNo5GVAeGCJ9x0GoH/PGuNgxiTj3e9JX/FTu7UpoFGs?= =?us-ascii?Q?ZIs2p9+i3D4OeHZEzPplc+7OD6njTmwxZE0gMoZOu/gjnw/OrWJyM/AKeGc9?= =?us-ascii?Q?6ib6YMNPg9jkvfnJ7+14WfRikmeDVQXpn2aUKEmWxrbrWFzSv/+XJxbnonDz?= =?us-ascii?Q?RPvT2ixQSWsbFoqsbDhNtSKdjXu/TSI+qK8W9VAM1TypZgZHudraNo2TdDLx?= =?us-ascii?Q?sHwz3E04FjC+oEEkSNh5lli7cfGcl/40STa+O3LMPBuUcLYOzgAbf+4p206e?= =?us-ascii?Q?zHbZ9koXW0teoQfURhEmRHWhpESMLficTWhf2K+kJiFdbpKzNbw1rI6BJSF3?= =?us-ascii?Q?0PAcC5ZAj2LRXqJCbalMVOkSzpckZNKGu1Qmr3252rlXLqIfjO1nd6HlkPYz?= =?us-ascii?Q?zgDlL3Za0mNRJD68Sb/9eGBib5a6C2/eXzm99KO7t9gJ+Wb4BO5I/iof464g?= =?us-ascii?Q?sl6ceA7oR0EFnXAx24lMDOoaiXOh5Ki+aIMf9KOj1+aplhhEJ7Bg+dBJyHm3?= =?us-ascii?Q?mxl4kii1Qn4uIwuLicgFZWuLKkGw3OeBjLHC5tbFEW06/dl0Tn/3D0pgs3r+?= =?us-ascii?Q?tEnh9q82RbrbtTkj/eywmamJky34k4dPc4anZ2tG68q29eT2G4rPRAajCrl6?= =?us-ascii?Q?fc6MjzR3hE5cNCNT9ndB3qZogJiN0XMsnHrrq4n2Ly0rCzuRmlNnNmEeOuYV?= =?us-ascii?Q?OmToOcpYMAtS90/yJcCt+4b66zM+WlzD+G12yMxNwIXyaXk0FIcpuFhHTRdi?= =?us-ascii?Q?ZQYcC9FHU9ficrX79ocyNw6wh75Yy/M/j21h4EJ4FcQwgGNmHxl75OkoVePV?= =?us-ascii?Q?xXjl2VRJwduoPBhKIvO3ecOphfIfUp6p8rnCFl5mTB/aMu3LQis91e90f7/j?= =?us-ascii?Q?i13NvmfHjYTFWX6T25I9nj1I9Q1JMAF1/+MqnNDQNl1uJjkyU725hSZZn9wH?= =?us-ascii?Q?/Xp2j3UTftX9Yb/VacAcH8yxFDyGxP3JXJskZb1jbhdNtHtRRw3Phdd4gcH2?= =?us-ascii?Q?Bds1VF91ACcYjIMSnpN2UysjyAXq1/pcXYgbU2ISpmdVAjXZic/m2lrBiZVK?= =?us-ascii?Q?69N5+F5nMNHlegs51WDvcIZz+IEHHPQeojbW6ZfI+owDvLkcjPe0CtAczrGr?= =?us-ascii?Q?fh8=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR02MB69247A7A36B0755C93B72789C3069DM6PR02MB6924namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07155639-9395-472c-8968-08d93802c4ec X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2021 17:57:59.3705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7NpHXp4khfSiJfZdT74Y2LFrxb9Q27NQsWgSODV2JAIRedGvTYpWAJBUziHB42Ef X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR02MB8007 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: FA325DAFD324A764CAB1D381A54E5F8EA0DBC49028992432D198893C46CA50792 X-Proofpoint-ORIG-GUID: _GB4OEibexiCDZFhcibebUCk3_TynLtD X-Proofpoint-GUID: _GB4OEibexiCDZFhcibebUCk3_TynLtD X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-25_06:2021-06-25, 2021-06-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 clxscore=1011 impostorscore=0 phishscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106250108 Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:58:35 -0000 --_000_DM6PR02MB69247A7A36B0755C93B72789C3069DM6PR02MB6924namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benjamin, We haven't seen any reply from you as to whether Mahesh's answers satisfy y= our DISCUSS and COMMENTs. For the first DISCUSS item, it would be really helpful to know if the propo= sed change would be satisfactory, though I would suggest an additional tweak to what Mahesh had, to make it clear wh= ere the enabled extension would be included. That is: OLD: "Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension is included if the value is 'true'."; NEW: "Indicates whether use of cached_info extension is enabled. The extension is enabled for inclusion in ClientHello and ServerHello packets if the value is 'true'."; If this is acceptable, I would like to mirror this change in the informatio= n model, so the two documents can be kept in synch. The information model is waiting final AUTH48 approval from me. Thx, Barbara From: babel On Behalf Of Mahesh Jethanandani Sent: Tuesday, June 08, 2021 10:47 AM To: Benjamin Kaduk Cc: babel-chairs ; Donald Eastlake ; draft-ietf-babel-yang-model@ietf.org; The IESG ; Babel at= IETF Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-mode= l-10: (with DISCUSS and COMMENT) Hi Benjamin, Thank you first of all for a detailed review. Some of the comments/changes = suggested here may impact the information model that this draft depends on.= The information model is in AUTH48 state at this time. This response includes feedback from my co-author Barbara. On May 19, 2021, at 9:09 PM, Benjamin Kaduk via Datatracker > wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-yang-model-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is kind of nitpicky, and I'm sorry to pull out the heavy hammer of DISCUSS for it, but for the "dtls-cached-info" leaf with description: "Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension is included if the value is 'true'."; It is factually false to just say that "the extension is included if the value is true", and it contradicts the DTLS specification to say so. In particular, the extension can only be included in the ServerHello message if it was present in the ClientHello message being responded to. So maybe we can say "enabled for inclusion" or append "when permitted by the protocol", or something similar? How about this? OLD: "Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension is included if the value is 'true'."; NEW: "Indicates whether use of cached_info extension is enabled. The extension is enabled for inclusion if the value is 'true'.= "; There's also a few places where we didn't quite clean up all the fallout from switching from enumerations to identities (for MAC and DTLS-adjacent algorithms), that really ought to get fixed before publication. I try to note them in the COMMENT. I also think we need to be a bit more specific about the structure of the (binary) private-key leaf/values provided when a certificate entry is created. Ideally this would just be by reference to some other spec, but the situation is unfortunately messy. (It doesn't help that we allow DTLS 1.2, which allows certificates that are used for key-exchange as opposed to signing, and those are not terribly mainstream.) We may need to pull in some other experts to figure out the right way to write about this. Ok. The way I am reading this is that we need to wait to hear more from the= experts that you cite before making any changes. Note, in WG discussion the ask was for the format of the private-key to be = binary. I am not an expert, but would it help if the description said somet= hing about using PEM format for the private-key? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.2 In addition to information like the version number implemented by this device, the model contains subtrees on 'constants', 'interfaces', 'routes' and 'security'. I don't see a 'security' node, but rather separate 'mac-key-set' and 'dtls' nodes, both of which contain subtrees. Fixed. Section 2.3 A router running Babel routing protocol can determine the parameters it needs to use for an interface based on the interface name. [...] Is this always true, or only sometimes? How about this? OLD: A router running Babel routing protocol can determine the parameters it needs to use for an interface based on the interface name. NEW: A router running Babel routing protocol can sometimes determine the para= meters it needs to use for an interface based on the interface name. Transport Layer Security Version 1.2 [RFC6347], The Blake2 (DTLS 1.3 is in the RFC Editor's queue, FWIW.) Replaced it with reference to draft-ietf-tls-dtls13. leaf router-id { type binary; description "router-id of the source router for which this route is advertised."; IIRC we can do length constraints in YANG, and in Babel router-ids are 8 octets. Should we enshrine that in the YANG? What would the constraint statement look like? For 'type uint32' I see length "1..4294967295"; but I am not sure for 'type binary' what it would look like. leaf next-hop { type inet:ip-address; description "The next-hop address of this route. This will be empty if this route has no next-hop address."; What does it mean for an inet:ip-address to be "empty"? That the node is absent? Yes, that the node is absent. Would it help if it said the following? OLD: "The next-hop address of this route. This will be empty if this route has no next-hop address."; NEW: "The next-hop address of this route. This will be NULL if this route has no next-hop address."; "List of supported certificate types, in order of preference. The values MUST be among those listed in dtls-cert-types. This list is used to populate the Since the element is of type leafref to the actual list of certs, it seems like this MUST is achieved by construction (and thus need not be listed specifically). Though, "dtls-cert-types" appears in this document only as the base identity for Babel DTLS certificate types, so this phrasing seems a bit odd...perhaps it is fallout from an enumeration/identity conversion. You are right. There is nothing to say that the leaf-list 'dtls-cert-prefer= ' could not be just type identityref { base dtls-cert-types; } which would a list of certificate types this particular implementation supp= orts. The assumption is that the list of certificate types that the impleme= ntation can support is not different from what it does support. @Barbara, w= ould it be ok for the data model to just keep one list of certificate types= ? server_certificate_type extension in a Client Hello. Values that are present in at least one instance in the certs object under dtls of a referenced dtls instance and that have a non-empty private-key will be used to populate the client_certificate_type extension in a Client Hello."; Since the DTLS server picks which certificate types are actually used, it is conceivable that the preference order in this list could also be used as input to the server's choice of type. That said, I don't think there is universal API support for DTLS servers accepting a preference list directly, so we would not want to imply that this list would always be used in such a fashion. But it could be used in such a fashion. Based on what I understood of your comment, what do you think of this chang= e? Or did I completely misunderstand you?? OLD: This list is used to populate the server_certificate_type extension in a Client Hello. Values that are present in at least one instance in the certs object under dtls of a referenced dtls instance and that have a non-empty private-key will be used to populate the client_certificate_type extension in a Client Hello. NEW: This list could be used to populate the server_certificate_type extension in a Client Hello. Values that are present in at least one instance in the certs object under dtls of a referenced dtls instance and that have a non-empty private-key will be used to populate the client_certificate_type extension in a Client Hello. container stats { config false; description "Statistics collection object for this interface."; Often, YANG models with such statistics containers will also include a leaf to indicate the "discontinuity time" at which the counters were last reset. Hmm. I wonder if that is not an implementation level detail. leaf hello-mcast-history { type string; description "The multicast Hello history of whether or not the multicast Hello packets prior to exp-mcast- hello-seqno were received, with a '1' for the most recent Hello placed in the most significant bit and prior Hellos shifted right (with '0' bits placed between prior Hellos and most recent Hello for any not-received Hellos); represented as a string using utf-8 encoded hex digits where a '1' bit =3D Hello received and a '0' bit =3D Hello not received."; I'd consider adding a few more words to confirm that this is the hex representation of a bitstring (so, all hex digits are possible), not a string consisting of only '1' and '0' characters. (Likewise for hello-ucast-history.) But doesn't the model already say that in the last sentence? If not, can yo= u suggest text? leaf exp-mcast-hello-seqno { type uint16; default "0"; description "Expected multicast Hello sequence number of next Hello to be received from this neighbor; if multicast Hello packets are not expected, or processing of multicast packets is not enabled, this MUST be NULL."; It's not really clear to me that assigning semantics to a NULL leaf makes sense when there is a default value for it (that has already assigned semantics to an absent leaf). (et seq) Ok. Will remove the default value. leaf value { type binary; mandatory true; description "The value of the MAC key. An implementation MUST NOT allow this parameter to be read. This can be done by I believe that we can incorporate this restriction in the YANG itself with something like "nacm:default-deny-all". Ok. Will add 'nacm:default-deny-all' and drop the text "An implementation .= . subsequently writeable". description "The name of the MAC algorithm used with this key. The value MUST be the same as one of the enumerations listed in the mac-algorithms parameter."; It's now an identityref, not a name. Accordingly, there are also not any enumerations listed in the mac-algorithms parameter. How about this? OLD: "The name of the MAC algorithm used with this key. The value MUST be the same as one of the enumerations listed in the mac-algorithms parameter."; NEW: "The MAC algorithm used with this key. The value MUST be one of the identities listed with the base of 'mac-algorithms'."; description "The name of the certificate type of this object instance. The value MUST be the same as one of the enumerations listed in the dtls-cert-types parameter. This value can only be provided when this Similarly, this is also identityref, and also has no enumerations listed in the dtls-cert-types parameter. How about this? OLD: "The name of the certificate type of this object instance. The value MUST be the same as one of the enumerations listed in the dtls-cert-types parameter. NEW: "The certificate type of this object instance. The value MUST be the same as one of the identities listed with the base of 'dtls-cert-types'. leaf private-key { type binary; mandatory true; description "The value of the private key. If this is non-empty, this certificate can be used by this implementation to provide a certificate during DTLS handshaking. An implementation MUST NOT allow this parameter to be read. This can be done by always providing an empty (nacm:default-deny-all could be useful here as well) Ok. Will add it and drop the appropriate text around it. string, or through permissions, or other means. This value can only be provided when this instance is created, and is not subsequently writable."; It is perhaps a bit limiting to require the actual private key value to be supplied, since that would preclude the use of (e.g.) HSM-based private keys. But since we are basically inheriting from the information model here, I won't press it too hard. Section 4 It might be worth referencing the security considerations of 8966/8967/8968 as being applicable. I understand that the Babel protocol itself is a insecure protocol. But I a= m not clear on how that is applicable to the YANG model that is used to con= figure or read the *state* of the protocol (over a secure interface). How a= bout we add this? Thanks to Barbara for providing the text. "The security considerations outlined here are specific to the YANG data mo= del, and do not cover security considerations of the Babel protocol or its = security mechanisms [RFC8966][RFC8967][RFC8968]. Each of these have their o= wn Security Considerations section for considerations that are specific to = it." The security (privacy, really) considerations of RFC 7924 are also arguably relevant, relating to the use of the TLS "cached_info" extension. Isn't this something that is relevant to RFC8968? The YANG model is merely = allowing for the configuration of the capability specified in RFC8968. Shou= ldn't any security considerations for "cached_info" therefore be mentioned = there? Are there any security and/or privacy considerations relating to the logging of babel packets? We say the following in the security considerations section. 'babel': Access to the information in the various nodes can disclose the network topology. Additionally, the routes used by a network device may be used to mount a subsequent attack on traffic traversing the network device. There are a number of data nodes defined in the YANG module which are writable/created/deleted (i.e., config true, which is the default). I don't think "writable/created/deleted" is part of the template. Thanks to Barbara for digging this out: https://datatracker.ietf.org/doc/html/rfc8407.html#section-3.7.1: There are a number of data nodes defined in this YANG module that are writable/creatable/deletable 'babel/hmac' and 'babel/dtls': These contain security credentials that influence whether packets are trusted. I'd consider making two separate (but related) points about controlling whether incoming packets are trusted, and whether outgoing packets are produced in a way such that the receiver will treat them as trusted. (Changing just the use-send/use-verify values can allow for a valid key to be misused, without changing the actual keys being used, which could present an interesting attack in some scenarios.) Ok. How about this? Thanks again to Barbara for providing the text. "These contain security credentials that influence whether incoming packets are trusted, and whether outgoing= packets are produced in a way such that the receiver will treat them as trusted." Some of the readable data or config false nodes in this YANG module may be considered sensitive or vulnerable in some network [...] 'babel/hmac' and 'babel/dtls': These contain security credentials, include private credentials of the router. We do require the actual secret keys to not be readable, so we might consider phrasing this more as a reiteration of that requirement than a statement of risk if they are read out. How about this? Thanks Barbara. 'babel/hmac' and 'babel/dtls': These contain security credentials, including private credentials of the router; however it is required that these values not be readable. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability from a RPC operation perspective: This model does not define any RPC operations. We do define a couple of actions, though, which are like RPCs except "[t]he difference between an action and an rpc is that an action is tied to a node in the datastore, whereas an rpc is not". This is perhaps an omission in the YANG security considerations template, but I don't think we should let that stop us from noting the actions we define are carefully designed to have minimal security impact and minimal side-channel leakage. (Well, I guess that's not hard for the stats-reset one, but for the MAC key test one it's quite important.) How about this? OLD: This model does not define any RPC operations. NEW: This model defines two actions, one of which allows for MAC key and MAC algorithm to be tested. It does not allows for them to be changed. Section 6.1 I don't have a great sense for why RFC 4868 needs to be normative. RFC 4868 is cited as a reference in the YANG model, which is normative. RFC 8968 seems missing as a listed reference at all (which would of course need to be normative as 8967 is). Agreed. Section 6.2 I think RFC 7693 should be normative, since you need it in order to do the blake2 stuff. Ok. Will move it to normative section. RFC 8341 might become normative if we add nacm:default-deny-all stanzas. Agreed. NITS The tree diagram and the prose use different orders for the various child elements, which is a little distracting. Ok. Will fix the order. Section 1 [RFC8966]. The data model is defined using YANG 1.1 [RFC7950] data modeling language and is Network Management Datastore Architecture "the YANG [data modeling language]" Section 2.1 Information Model and this data module. The information model mandates the definition of some of the attributes, e.g. 'babel- comma after "e.g." (as well as before). (I'll try to only note it once, though it appears many times.) Likewise for "i.e." Section 2.2 In addition to information like the version number implemented by this device, the model contains subtrees on 'constants', The actual data model (and the information model, for that matter) show that the 'version' leaf contains "the name and version of this implementation of the Babel protocol". The text here suggests that it contains the protocol version number implemented by the device, which is different. So I'd suggest "the implementation and version used by this device" instead. The 'interfaces' subtree describes attributes such as 'interface' object that is being referenced, the type of link, e.g. wired, "the 'interface'" Ok to the above suggested changes. wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- horizon' and whether the interface is enabled or not. I suggest using semicolons for the outer layer of grouping, to avoid overloading commas for different hierarchies of separation. Something like this? OLD: The 'interfaces' subtree describes attributes such as 'interface' object that is being referenced, the type of link, e.g. wired, wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- horizon' and whether the interface is enabled or not. NEW: The 'interfaces' subtree describes attributes such as 'interface' object that is being referenced, the type of link, e.g., wired, wireless or tunnel; as enumerated by 'metric-algorithm' and 'split- horizon'; and whether the interface is enabled or not. Finally, for security two subtree are defined to contain MAC keys and DTLS certificates. The 'mac-key-set' subtree contains keys used with "subtrees" interfaces. The dtls subtree contains certificates used with DTLS single quotes for 'dtls'. "the DTLS" Section 2.3 Similarly, an interface that is a metered 3G link, and used for fallback connectivity needs much higher default time constants, e.g. Comma after "connectivity". HMAC: Keyed-Hashing for Message Authentication [RFC2104], Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4868], Datagram The "with IPsec" part of RFC 4868's title seems to have been dropped. Ok to the above suggested changes. "This implementation supports two-out-of-three metric comp algorithm."; "the two-out-of-three". Also, do we really need to (silently) abbreviate "metric computation" (multiple occurrences)? Should be: "the 'two-out-of-three'". Will fix metric comp occurrences. "This implementation supports Expected Transmission Count "the Expected" Ok. "This implementation supports hmac-sha256 MAC algorithm."; "the hmac-sha256" "This implementation supports x-509 certificate type."; "the X.509" Ok to both. "This implementation supports raw-public-key certificate type."; Missing article, per the theme, but I think it would also be more conventional to spell the name as "RawPublicKey". Ok. That was done to be consistent with the IM. base metric-comp-algorithms; if-feature "etx-supported"; description "Expected Transmission Count."; I'd put an "algorithm" in here somewhere How about: "Expected Transmission Count (ETX) metric compilation algorithm." "BLAKE2s algorithms supported. Specifically, BLAKE2-128 is supported."; I'd just say "BLAKE2-128 algorithm supported." Then shouldn't the feature say feature blake2-128-supported? "Raw Public Key type."; "certificate type" leaf router-id { type binary; (If length constraint is applied earlier, it should apply here as well.) "Indicates whether statistics collection is enabled (true) or disabled (false) on all interfaces. When enabled, existing statistics values are not cleared and will be incremented as new packets are counted."; I suggest "on transition to enabled". (Also, thank you for clearly spelling out which behaviors true/false map to!) A value of true indicates split horizon optimization is used."; "the split" "List of references to the mac entries that apply to this interface. When an interface instance is created, all mac instances with default-apply 'true' s/mac/MAC/ (twice) "Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension s/packets/messages/. Ok to the above suggested changes. Also, it's conventional to refer to TLS extension names enclosed by double quotes, but I guess in the context of a YANG leaf description that's not really feasible. Correct. dtls-cert-types. This list is used to populate the server_certificate_type extension in a Client Hello. s/Client Hello/ClientHello/. list mac-key-set { key "name"; description "A mac key set object. If this object is implemented, it provides access to parameters related to the MAC security mechanism."; s/mac/MAC/ "A string that uniquely identifies the mac object."; s/mac/MAC key/ If 'true', this instance is applied to new babel- interfaces instances at the time they are created, by including it in the mac-key-sets list under interfaces. If 'false', this instance is not applied s/under interfaces/under the interface/ to new interfaces instances when they are created."; s/interfaces/interface/ If 'true', this instance is applied to new interfaces instances at the time they are created, by including it in the dtls-certs list under interfaces. If 'false', s/under interfaces/under the interface/ this instance is not applied to new interfaces instances when they are created."; s/interfaces/interface/ Ok to make the above suggested changes. Thanks again for a detailed review! Mahesh Jethanandani mjethanandani@gmail.com --_000_DM6PR02MB69247A7A36B0755C93B72789C3069DM6PR02MB6924namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benjamin,

We haven’t seen any = reply from you as to whether Mahesh’s answers satisfy your DISCUSS and COMMENTs.

 

For the first DISCUSS item= , it would be really helpful to know if the proposed change would be satisfactory, though

I would suggest an additio= nal tweak to what Mahesh had, to make it clear where the enabled extension would

be included. That is:

 

OLD:

  &= nbsp;         "Indicates whether the cached_info extension is included<= /span>

  &= nbsp;          in ClientHello and Server= Hello packets. The extension

  &= nbsp;          is included if the value is 'true'.= ";

&nb= sp;

NEW:

  &= nbsp;         "Indicates whether use of cached_info extension is enabled.<= /span>

  &= nbsp;          The extension is enabled for inclus= ion in ClientHello and

        &n= bsp;    ServerHello packets if the value is 't= rue'.";

 

If this is acceptable, I w= ould like to mirror this change in the information model, so the two documents can be kept in synch.=

The information model is w= aiting final AUTH48 approval from me.

Thx,

Barbara<= /font>

 

From: babel <babel-bounces@ietf.org> On Behalf Of Mahesh Jethanan= dani
Sent: Tuesday, June 08, 2021= 10:47 AM
To: Benjamin Kaduk <kaduk= @mit.edu>
Cc: babel-chairs <babel-c= hairs@ietf.org>; Donald Eastlake <d3e3e3@gmail.com>; draft-ietf-ba= bel-yang-model@ietf.org; The IESG <iesg@ietf.org>; Babel at IETF <= babel@ietf.org>
Subject: Re: [babel] Benjami= n Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMM= ENT)

 

Hi Benja= min,

&nb= sp;

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

&nb= sp;

This res= ponse includes feedback from my co-author Barbara.=



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

&nb= sp;

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

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


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


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

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

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

&nb= sp;

How abou= t this?

&nb= sp;

OLD:

  &= nbsp;         "Indicates whether the cached_info e= xtension is included

  &= nbsp;          in ClientHello and ServerHello pack= ets. The extension

  &= nbsp;          is included if the value is 'true'.= ";

&nb= sp;

NEW:

  &= nbsp;         "Indicates whether use of cached_inf= o extension is enabled.

  &= nbsp;          The extension is enabled for inclus= ion if the value is 'true'.";

&nb= sp;




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

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

&nb= sp;

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

&nb= sp;

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





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

Section 2.2

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

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

&nb= sp;

Fixed.




Section 2.3

  A router running Babel routing protocol can determine the param= eters
  it needs to use for an interface based on the interface name. &= nbsp;[...]

Is this always true, or only sometimes?

&nb= sp;

How abou= t this?

&nb= sp;

OLD:

=
   A router running Babel routing protocol can determine t=
he parameters
   it needs to use for a=
n interface based on the interface name.

&nb= sp;

NEW:

=
   A router running Babel routing protocol can sometimes d=
etermine the parameters
   it needs to use for a=
n interface based on the interface name.

&nb= sp;


  Transport Layer Security Version 1.2 [RFC6347], The Blake2

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

&nb= sp;

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




        leaf router-id {
          type binary;           description
            &qu= ot;router-id of the source router for which this route is
            &nb= sp;advertised.";


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

&nb= sp;

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

&nb= sp;

length &= #8220;1..4294967295”;

&nb= sp;

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

&nb= sp;


        leaf next-hop {
          type inet:ip-ad= dress;
          description
            &qu= ot;The next-hop address of this route. This will be empty if
            &nb= sp;this route has no next-hop address.";

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

&nb= sp;

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

&nb= sp;

OLD:

  &= nbsp;       "The next-hop address of this route. This w= ill be empty if

  &= nbsp;        this route has no next-hop address.”= ;

&nb= sp;

NEW:

  &= nbsp;       "The next-hop address of this route. This w= ill be NULL if

  &= nbsp;        this route has no next-hop address.”= ;

&nb= sp;


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

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

&nb= sp;

You are = right. There is nothing to say that the leaf-list ‘dtls-cert-prefer&#= 8217; could not be just 

&nb= sp;

  &= nbsp;         type identityref {

  &= nbsp;           base dtls-cert-types;

  &= nbsp;         }

&nb= sp;

which wo= uld a list of certificate types this particular implementation supports. Th= e assumption is that the list of certificate types that the implementation can support is not different from what it does sup= port. @Barbara, would it be ok for the data model to just keep one list of = certificate types?




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

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

&nb= sp;

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

&nb= sp;

OLD:

&nb= sp;

  &= nbsp;         This list is used to populate the

  &= nbsp;          server_certificate_type extension i= n a Client Hello.

  &= nbsp;          Values that are present in at least= one instance in the

  &= nbsp;          certs object under dtls of a refere= nced dtls instance

  &= nbsp;          and that have a non-empty private-k= ey will be used to

  &= nbsp;          populate the client_certificate_typ= e extension in a

  &= nbsp;          Client Hello.

&nb= sp;

NEW:

&nb= sp;

  &= nbsp;         This list could be used to populate the

  &= nbsp;          server_certificate_type extension i= n a Client Hello.

  &= nbsp;          Values that are present in at least= one instance in the

  &= nbsp;          certs object under dtls of a refere= nced dtls instance

  &= nbsp;          and that have a non-empty private-k= ey will be used to

  &= nbsp;          populate the client_certificate_typ= e extension in a

  &= nbsp;          Client Hello.

&nb= sp;


          container stats= {
            con= fig false;
            des= cription
            &nb= sp; "Statistics collection object for this interface.";

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

&nb= sp;

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




            lea= f hello-mcast-history {
            &nb= sp; type string;
            &nb= sp; description
            &nb= sp;   "The multicast Hello history of whether or not th= e
            &nb= sp;    multicast Hello packets prior to exp-mcast-
            &nb= sp;    hello-seqno were received, with a '1' for the mo= st
            &nb= sp;    recent Hello placed in the most significant bit = and
            &nb= sp;    prior Hellos shifted right (with '0' bits placed=
            &nb= sp;    between prior Hellos and most recent Hello for a= ny
            &nb= sp;    not-received Hellos); represented as a string us= ing
            &nb= sp;    utf-8 encoded hex digits where a '1' bit =3D Hel= lo
            &nb= sp;    received and a '0' bit =3D Hello not received.&q= uot;;

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

&nb= sp;

But does= n’t the model already say that in the last sentence? If not, can you = suggest text?




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

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

&nb= sp;

Ok. Will= remove the default value.




            lea= f value {
            &nb= sp; type binary;
            &nb= sp; mandatory true;
            &nb= sp; description
            &nb= sp;   "The value of the MAC key. An implementation MUST= NOT
            &nb= sp;    allow this parameter to be read. This can be don= e by

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

&nb= sp;

Ok. Will= add 'nacm:default-deny-all' and drop the text “An implementation .. = subsequently writeable”.




            &nb= sp; description
            &nb= sp;   "The name of the MAC algorithm used with this key= . The
            &nb= sp;    value MUST be the same as one of the enumeration= s
            &nb= sp;    listed in the mac-algorithms parameter.";
It's now an identityref, not a name.  Accordingly, there are also not<= br> any enumerations listed in the mac-algorithms parameter.<= /font>

&nb= sp;

How abou= t this?

&nb= sp;

OLD:

&nb= sp;

  &= nbsp;           "The name of the MAC algorith= m used with this key. The

  &= nbsp;            value MUST be the same as on= e of the enumerations

  &= nbsp;            listed in the mac-algorithms= parameter.”;

&nb= sp;

NEW:

&nb= sp;

  &= nbsp;           "The MAC algorithm used with = this key. The

  &= nbsp;            value MUST be one of the ide= ntities

  &= nbsp;            listed with the base of 'mac= -algorithms'.”;

&nb= sp;


            &nb= sp; description
            &nb= sp;   "The name of the certificate type of this object<= br>             &nb= sp;    instance. The value MUST be the same as one of t= he
            &nb= sp;    enumerations listed in the dtls-cert-types
            &nb= sp;    parameter. This value can only be provided when = this

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

&nb= sp;

How abou= t this?

&nb= sp;

OLD:

&nb= sp;

  &= nbsp;           "The name of the certificate = type of this object

  &= nbsp;            instance. The value MUST be = the same as one of the

  &= nbsp;            enumerations listed in the d= tls-cert-types

  &= nbsp;            parameter. <= /span>

&nb= sp;

NEW:

&nb= sp;

  &= nbsp;           "The certificate type of this= object

  &= nbsp;            instance. The value MUST be = the same as one of the

  &= nbsp;            identities listed with the b= ase of 'dtls-cert-types'. 

&nb= sp;


            lea= f private-key {
            &nb= sp; type binary;
            &nb= sp; mandatory true;
            &nb= sp; description
            &nb= sp;   "The value of the private key. If this is non-emp= ty,
            &nb= sp;    this certificate can be used by this implementat= ion to
            &nb= sp;    provide a certificate during DTLS handshaking. A= n
            &nb= sp;    implementation MUST NOT allow this parameter to = be
            &nb= sp;    read. This can be done by always providing an em= pty

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

&nb= sp;

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




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

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

Section 4

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

&nb= sp;

I unders= tand that the Babel protocol itself is a insecure protocol. But I am not cl= ear on how that is applicable to the YANG model that is used to configure or read the *state* of the protocol (over a secure in= terface). How about we add this? Thanks to Barbara for providing the text.<= o:p>

&nb= sp;

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




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

&nb= sp;

Isn̵= 7;t this something that is relevant to RFC8968? The YANG model is merely al= lowing for the configuration of the capability specified in RFC8968. Shouldn’t any security considerations for “cached_= info” therefore be mentioned there?




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

&nb= sp;

We say t= he following in the security considerations section.

&nb= sp;

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

   the network device.




&nb=
sp;












  There are a number of data nodes defined in the YANG module whi=
ch are

  writable/created/deleted (i.e., config true, which is the defau=
lt).



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











&nb=
sp;




Thanks t=
o Barbara for digging this out:

&nb= sp;

&nb= sp;

There are a number of data nodes defined in= this YANG module that are

writable/creatable/d= eletable

&nb= sp;


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

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

&nb= sp;

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

&nb= sp;

  &= #8220;These contain security credentials
  that influence whether incoming packets are trusted, and whether out= going packets are
  produced in a way such that the receiver will treat them as trusted.= ”




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

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

&nb= sp;

How abou= t this? Thanks Barbara.

&nb= sp;

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


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

  This model does not define any RPC operations.

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

&nb= sp;

How abou= t this?

&nb= sp;

OLD:

&nb= sp;

=
   This model does not define any RPC operations.

&nb= sp;

NEW:

&nb= sp;

=
   This model defines two actions, one of which=

=
   allows for MAC key and MAC algorithm to be tested. =
;
=
   It does not allows for them to be changed.

&nb= sp;


Section 6.1

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

&nb= sp;

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




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

&nb= sp;

Agreed.<= o:p>




Section 6.2

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

&nb= sp;

Ok. Will= move it to normative section.




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

&nb= sp;

Agreed.<= o:p>




NITS

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

&nb= sp;

Ok. Will= fix the order.




Section 1

  [RFC8966].  The data model is defined using YANG 1.1 [RFC7= 950] data
  modeling language and is Network Management Datastore Architect= ure

"the YANG [data modeling language]"


Section 2.1

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

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


Section 2.2

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

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


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

&nb= sp;

Ok to th= e above suggested changes.




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

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

&nb= sp;

Somethin= g like this?

&nb= sp;

OLD:

&nb= sp;

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

   horizon' and whether =
the interface is enabled or not.

&nb= sp;

NEW:

&nb= sp;

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

   horizon’; and whether the interface is enabled or =
not.




&nb=
sp;




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

"subtrees"


  interfaces.  The dtls subtree contains certificates used w= ith DTLS

single quotes for 'dtls'.
"the DTLS"


Section 2.3

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

Comma after "connectivity".


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

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

&nb= sp;

Ok to th= e above suggested changes.




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

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

&nb= sp;

Should b= e:

&nb= sp;

“t= he ’two-out-of-three’”. 

&nb= sp;

Will fix= metric comp occurrences.




        "This implementation s= upports Expected Transmission Count

"the Expected"

&nb= sp;

Ok.=




        "This implementation s= upports hmac-sha256 MAC algorithm.";

"the hmac-sha256"

        "This implementation s= upports x-509 certificate type.";

"the X.509"

&nb= sp;

Ok to bo= th.




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

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

&nb= sp;

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




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


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

&nb= sp;

&nb= sp;

How abou= t:

&nb= sp;

“E= xpected Transmission Count (ETX) metric compilation algorithm.”<= /o:p>




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

I'd just say "BLAKE2-128 algorithm supported."<= /font>

&nb= sp;

Then sho= uldn’t the feature say

&nb= sp;

feature = blake2-128-supported?




        "Raw Public Key type.&= quot;;

"certificate type"


        leaf router-id {
          type binary;
(If length constraint is applied earlier, it should apply here as well.)
            &qu= ot;Indicates whether statistics collection is enabled (true)
            &nb= sp;or disabled (false) on all interfaces. When enabled,
            &nb= sp;existing statistics values are not cleared and will be
            &nb= sp;incremented as new packets are counted.";

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


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

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

s/mac/MAC/ (twice)

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

s/packets/messages/.

&nb= sp;

Ok to th= e above suggested changes.



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

&nb= sp;

Correct.=




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

s/Client Hello/ClientHello/.

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

          description
            &qu= ot;A mac key set object. If this object is implemented, it
            &nb= sp;provides access to parameters related to the MAC security
            &nb= sp;mechanism.";

s/mac/MAC/

            &nb= sp; "A string that uniquely identifies the mac object.";

s/mac/MAC key/

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

s/under interfaces/under the interface/

            &nb= sp;  to new interfaces instances when they are created.";
s/interfaces/interface/

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

s/under interfaces/under the interface/

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

s/interfaces/interface/

&nb= sp;

Ok to ma= ke the above suggested changes.

&nb= sp;

Thanks a= gain for a detailed review!

&nb= sp;

Mahesh Jethanandani

 

 

 

&nb= sp;

--_000_DM6PR02MB69247A7A36B0755C93B72789C3069DM6PR02MB6924namp_-- From nobody Fri Jun 25 11:44:42 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193103A0763; Fri, 25 Jun 2021 11:44:37 -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 a-7ogl53b85D; Fri, 25 Jun 2021 11:44:31 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 6E2C63A0744; Fri, 25 Jun 2021 11:44:31 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id a2so8581901pgi.6; Fri, 25 Jun 2021 11:44:31 -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=9lNsbdaWnc++hjDv3WEQgYJRhLb0P9jhOdRICZLv1Oo=; b=AyysU45ZGLS1M9mA7ZkukHie7ZSwcvT0i+cdrZ6Z04IcG3Bw9C+WS9ix3niqUt0WMa 9xMBFxUA6UA7w7GoUPk5hafC4++2/Oak5x9C39xJXnxGcGxxDhhAhvTxBKcNGywJdwKu br08BCsLSmrUBdylRfC6ZgpnBgeHtOfnD6kolPMOypriJiJos9ESErrBIvBIhEY5A2Cc k/jpndsVWcx4oCA/oBNr3aetJCu7qa7/QGnI0x+8r+NHqF1ixGoPn+K5QqRl0pFLX/w0 9apS1tQQTq37f8BXnxC7CrmXmYpPfFvGhbgAOZ+NVCphTvZiXc5Z9uoHnqw0Apa5X8rZ c6Sg== 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=9lNsbdaWnc++hjDv3WEQgYJRhLb0P9jhOdRICZLv1Oo=; b=UNhGtls4sqB11GxB6HSrxAWt/c5tDoqfZsCMzSgYmGa9ffeLzgeb9mDAcck/UbSOND UOn+r1n6iAdfyPUEoUNacFd3MKgjli5gjjvwPYju8mBmTcJNAzXOBFTrOQmI1sq5V/DI qRUjmK3sgho9XcnwCgq5EKrr141WTJZIJAzaKZMzkoYil5pQgpdYI56XurNySH8DaSKo G6f4t47bGJIasQr6zBcbNzU2su/N57cEESfqT2pBW1Ov2jiKrztfx9IGLy0rhkKM7+b+ R+w7+HvI5iZDTqFKMrOYGE/KYyvwtdbKU3G0a+a+BfwE0Xgi8BKWbNRzTC8+tedippJO 3NqQ== X-Gm-Message-State: AOAM531YLiPcG6EZDG+wk9s+tPIvJ5kr5J/HuQsv/Ukwug4mIFMyG3dc pXtsTCPBeXkqjd6ILWeyt24= X-Google-Smtp-Source: ABdhPJysbrNZccPtJICl49II5CFeHKasfpVeIBWf6oOGo1+FzBnjckXkxPIMxK724PPTLAYLY/JXkQ== X-Received: by 2002:a62:7616:0:b029:305:f420:49cc with SMTP id r22-20020a6276160000b0290305f42049ccmr11931778pfc.51.1624646669882; Fri, 25 Jun 2021 11:44:29 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:317c:95dc:4f68:92b2? ([2601:647:5600:5020:317c:95dc:4f68:92b2]) by smtp.gmail.com with ESMTPSA id mj17sm11730273pjb.12.2021.06.25.11.44.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jun 2021 11:44:28 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0872F95C-C8C5-4051-B7C3-702AFE11FFA5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 25 Jun 2021 11:44:27 -0700 In-Reply-To: <99514803-6C88-40F8-B924-315945B052C1@gmail.com> Cc: The IESG , draft-ietf-babel-yang-model@ietf.org, babel-chairs , Babel at IETF , Donald Eastlake To: Benjamin Kaduk References: <162148379451.10850.9563671396439074857@ietfa.amsl.com> <99514803-6C88-40F8-B924-315945B052C1@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 18:44:37 -0000 --Apple-Mail=_0872F95C-C8C5-4051-B7C3-702AFE11FFA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, On re-reading one of your comments, I realized my response to that = comment was not quite right. See inline. > On Jun 8, 2021, at 8:47 AM, Mahesh Jethanandani = wrote: >=20 > Hi Benjamin, >=20 > Thank you first of all for a detailed review. Some of the = comments/changes suggested here may impact the information model that = this draft depends on. The information model is in AUTH48 state at this = time. >=20 > This response includes feedback from my co-author Barbara. >=20 >> On May 19, 2021, at 9:09 PM, Benjamin Kaduk via Datatracker = > wrote: >>=20 >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-babel-yang-model-10: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = >> for more information about DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ = >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> This is kind of nitpicky, and I'm sorry to pull out the heavy hammer = of >> DISCUSS for it, but for the "dtls-cached-info" leaf with description: >>=20 >> "Indicates whether the cached_info extension is = included >> in ClientHello and ServerHello packets. The extension >> is included if the value is 'true'."; >>=20 >> It is factually false to just say that "the extension is included if = the >> value is true", and it contradicts the DTLS specification to say so. = In >> particular, the extension can only be included in the ServerHello >> message if it was present in the ClientHello message being responded = to. >> So maybe we can say "enabled for inclusion" or append "when permitted = by >> the protocol", or something similar? >=20 > How about this? >=20 > OLD: > "Indicates whether the cached_info extension is included > in ClientHello and ServerHello packets. The extension > is included if the value is 'true'."; >=20 > NEW: > "Indicates whether use of cached_info extension is = enabled. > The extension is enabled for inclusion if the value is = 'true'."; >=20 >=20 >>=20 >> There's also a few places where we didn't quite clean up all the = fallout >> from switching from enumerations to identities (for MAC and >> DTLS-adjacent algorithms), that really ought to get fixed before >> publication. I try to note them in the COMMENT. >>=20 >> I also think we need to be a bit more specific about the structure of >> the (binary) private-key leaf/values provided when a certificate = entry >> is created. Ideally this would just be by reference to some other = spec, >> but the situation is unfortunately messy. (It doesn't help that we >> allow DTLS 1.2, which allows certificates that are used for = key-exchange >> as opposed to signing, and those are not terribly mainstream.) We = may >> need to pull in some other experts to figure out the right way to = write >> about this. >=20 > Ok. The way I am reading this is that we need to wait to hear more = from the experts that you cite before making any changes. >=20 > Note, in WG discussion the ask was for the format of the private-key = to be binary. I am not an expert, but would it help if the description = said something about using PEM format for the private-key? >=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 2.2 >>=20 >> In addition to information like the version number implemented by >> this device, the model contains subtrees on 'constants', >> 'interfaces', 'routes' and 'security'. >>=20 >> I don't see a 'security' node, but rather separate 'mac-key-set' and >> 'dtls' nodes, both of which contain subtrees. >=20 > Fixed. >=20 >>=20 >> Section 2.3 >>=20 >> A router running Babel routing protocol can determine the = parameters >> it needs to use for an interface based on the interface name. = [...] >>=20 >> Is this always true, or only sometimes? >=20 > How about this? >=20 > OLD: > A router running Babel routing protocol can determine the = parameters > it needs to use for an interface based on the interface name. >=20 > NEW: > A router running Babel routing protocol can sometimes determine the = parameters > it needs to use for an interface based on the interface name. >=20 >>=20 >> Transport Layer Security Version 1.2 [RFC6347], The Blake2 >>=20 >> (DTLS 1.3 is in the RFC Editor's queue, FWIW.) >=20 > Replaced it with reference to draft-ietf-tls-dtls13. >=20 >>=20 >> leaf router-id { >> type binary; >> description >> "router-id of the source router for which this route is >> advertised."; >=20 >>=20 >> IIRC we can do length constraints in YANG, and in Babel router-ids = are 8 >> octets. Should we enshrine that in the YANG? >=20 > What would the constraint statement look like? For 'type uint32' I see=20= >=20 > length =E2=80=9C1..4294967295=E2=80=9D; >=20 > but I am not sure for 'type binary=E2=80=99 what it would look like. >=20 >>=20 >> leaf next-hop { >> type inet:ip-address; >> description >> "The next-hop address of this route. This will be empty = if >> this route has no next-hop address."; >>=20 >> What does it mean for an inet:ip-address to be "empty"? That the = node >> is absent? >=20 > Yes, that the node is absent. Would it help if it said the following? >=20 > OLD: > "The next-hop address of this route. This will be empty if > this route has no next-hop address.=E2=80=9D; >=20 > NEW: > "The next-hop address of this route. This will be NULL if > this route has no next-hop address.=E2=80=9D; >=20 >>=20 >> "List of supported certificate types, in order of >> preference. The values MUST be among those listed in >> dtls-cert-types. This list is used to populate the >>=20 >> Since the element is of type leafref to the actual list of certs, it >> seems like this MUST is achieved by construction (and thus need not = be >> listed specifically). Though, "dtls-cert-types" appears in this >> document only as the base identity for Babel DTLS certificate types, = so >> this phrasing seems a bit odd...perhaps it is fallout from an >> enumeration/identity conversion. >=20 > You are right. There is nothing to say that the leaf-list = =E2=80=98dtls-cert-prefer=E2=80=99 could not be just=20 >=20 > type identityref { > base dtls-cert-types; > } >=20 > which would a list of certificate types this particular implementation = supports. The assumption is that the list of certificate types that the = implementation can support is not different from what it does support. = @Barbara, would it be ok for the data model to just keep one list of = certificate types? I think the confusion is stemming from the fact that = =E2=80=98dtls-cert-types=E2=80=99 is a base identity, and all the = identities, e.g. x-509, and raw-public-key are derived from that base = identity. However, =E2=80=98dtls-cert-prefer=E2=80=99 is not a leaf-list = of =E2=80=98dtls-cert-types=E2=80=99 (the base identity) but rather the = types listed in ../../dtls/certs/type. Rather than the change I = suggested earlier, we need to reword the description statement to say: OLD: "List of supported certificate types, in order of preference. The values MUST be among those listed in dtls-cert-types. NEW: "List of supported certificate types, in order of preference. The values MUST be the =E2=80=98type' attribute = in in the list =E2=80=98certs=E2=80=99 of the list =E2=80=98dlls= =E2=80=99 (../../dtls/certs/type). Does this help? Thanks. >=20 >>=20 >> server_certificate_type extension in a Client Hello. >> Values that are present in at least one instance in = the >> certs object under dtls of a referenced dtls instance >> and that have a non-empty private-key will be used to >> populate the client_certificate_type extension in a >> Client Hello."; >>=20 >> Since the DTLS server picks which certificate types are actually = used, >> it is conceivable that the preference order in this list could also = be >> used as input to the server's choice of type. That said, I don't = think >> there is universal API support for DTLS servers accepting a = preference >> list directly, so we would not want to imply that this list would = always >> be used in such a fashion. But it could be used in such a fashion. >=20 > Based on what I understood of your comment, what do you think of this = change? Or did I completely misunderstand you?? >=20 > OLD: >=20 > This list is used to populate the > server_certificate_type extension in a Client Hello. > Values that are present in at least one instance in the > certs object under dtls of a referenced dtls instance > and that have a non-empty private-key will be used to > populate the client_certificate_type extension in a > Client Hello. >=20 > NEW: >=20 > This list could be used to populate the > server_certificate_type extension in a Client Hello. > Values that are present in at least one instance in the > certs object under dtls of a referenced dtls instance > and that have a non-empty private-key will be used to > populate the client_certificate_type extension in a > Client Hello. >=20 >>=20 >> container stats { >> config false; >> description >> "Statistics collection object for this interface."; >>=20 >> Often, YANG models with such statistics containers will also include = a >> leaf to indicate the "discontinuity time" at which the counters were >> last reset. >=20 > Hmm. I wonder if that is not an implementation level detail. >=20 >>=20 >> leaf hello-mcast-history { >> type string; >> description >> "The multicast Hello history of whether or not the >> multicast Hello packets prior to exp-mcast- >> hello-seqno were received, with a '1' for the most >> recent Hello placed in the most significant bit and >> prior Hellos shifted right (with '0' bits placed >> between prior Hellos and most recent Hello for any >> not-received Hellos); represented as a string using >> utf-8 encoded hex digits where a '1' bit =3D Hello >> received and a '0' bit =3D Hello not received."; >>=20 >> I'd consider adding a few more words to confirm that this is the hex >> representation of a bitstring (so, all hex digits are possible), not = a >> string consisting of only '1' and '0' characters. >> (Likewise for hello-ucast-history.) >=20 > But doesn=E2=80=99t the model already say that in the last sentence? = If not, can you suggest text? >=20 >>=20 >> leaf exp-mcast-hello-seqno { >> type uint16; >> default "0"; >> description >> "Expected multicast Hello sequence number of next = Hello >> to be received from this neighbor; if multicast = Hello >> packets are not expected, or processing of multicast >> packets is not enabled, this MUST be NULL."; >>=20 >> It's not really clear to me that assigning semantics to a NULL leaf >> makes sense when there is a default value for it (that has already >> assigned semantics to an absent leaf). >> (et seq) >=20 > Ok. Will remove the default value. >=20 >>=20 >> leaf value { >> type binary; >> mandatory true; >> description >> "The value of the MAC key. An implementation MUST NOT >> allow this parameter to be read. This can be done by >>=20 >> I believe that we can incorporate this restriction in the YANG itself >> with something like "nacm:default-deny-all". >=20 > Ok. Will add 'nacm:default-deny-all' and drop the text =E2=80=9CAn = implementation .. subsequently writeable=E2=80=9D. >=20 >>=20 >> description >> "The name of the MAC algorithm used with this key. = The >> value MUST be the same as one of the enumerations >> listed in the mac-algorithms parameter."; >>=20 >> It's now an identityref, not a name. Accordingly, there are also not >> any enumerations listed in the mac-algorithms parameter. >=20 > How about this? >=20 > OLD: >=20 > "The name of the MAC algorithm used with this key. The > value MUST be the same as one of the enumerations > listed in the mac-algorithms parameter.=E2=80=9D; >=20 > NEW: >=20 > "The MAC algorithm used with this key. The > value MUST be one of the identities > listed with the base of 'mac-algorithms'.=E2=80=9D; >=20 >>=20 >> description >> "The name of the certificate type of this object >> instance. The value MUST be the same as one of the >> enumerations listed in the dtls-cert-types >> parameter. This value can only be provided when this >>=20 >> Similarly, this is also identityref, and also has no enumerations = listed >> in the dtls-cert-types parameter. >=20 > How about this? >=20 > OLD: >=20 > "The name of the certificate type of this object > instance. The value MUST be the same as one of the > enumerations listed in the dtls-cert-types > parameter.=20 >=20 > NEW: >=20 > "The certificate type of this object > instance. The value MUST be the same as one of the > identities listed with the base of 'dtls-cert-types'.=20= >=20 >>=20 >> leaf private-key { >> type binary; >> mandatory true; >> description >> "The value of the private key. If this is non-empty, >> this certificate can be used by this implementation = to >> provide a certificate during DTLS handshaking. An >> implementation MUST NOT allow this parameter to be >> read. This can be done by always providing an empty >>=20 >> (nacm:default-deny-all could be useful here as well) >=20 > Ok. Will add it and drop the appropriate text around it. >=20 >>=20 >> string, or through permissions, or other means. This >> value can only be provided when this instance is >> created, and is not subsequently writable."; >>=20 >> It is perhaps a bit limiting to require the actual private key value = to >> be supplied, since that would preclude the use of (e.g.) HSM-based >> private keys. But since we are basically inheriting from the >> information model here, I won't press it too hard. >>=20 >> Section 4 >>=20 >> It might be worth referencing the security considerations of >> 8966/8967/8968 as being applicable. >=20 > I understand that the Babel protocol itself is a insecure protocol. = But I am not clear on how that is applicable to the YANG model that is = used to configure or read the *state* of the protocol (over a secure = interface). How about we add this? Thanks to Barbara for providing the = text. >=20 > "The security considerations outlined here are specific to the YANG = data model, and do not cover security considerations of the Babel = protocol or its security mechanisms [RFC8966][RFC8967][RFC8968]. Each of = these have their own Security Considerations section for considerations = that are specific to it." >=20 >>=20 >> The security (privacy, really) considerations of RFC 7924 are also >> arguably relevant, relating to the use of the TLS "cached_info" >> extension. >=20 > Isn=E2=80=99t this something that is relevant to RFC8968? The YANG = model is merely allowing for the configuration of the capability = specified in RFC8968. Shouldn=E2=80=99t any security considerations for = =E2=80=9Ccached_info=E2=80=9D therefore be mentioned there? >=20 >>=20 >> Are there any security and/or privacy considerations relating to the >> logging of babel packets? >=20 > We say the following in the security considerations section. >=20 > 'babel': Access to the information in the various nodes can = disclose > the network topology. Additionally, the routes used by a network > device may be used to mount a subsequent attack on traffic = traversing > the network device. >=20 >>=20 >> There are a number of data nodes defined in the YANG module which = are >> writable/created/deleted (i.e., config true, which is the default). >>=20 >> I don't think "writable/created/deleted" is part of the template. >=20 > Thanks to Barbara for digging this out: >=20 > https://datatracker.ietf.org/doc/html/rfc8407.html#section-3.7.1 = : >=20 > There are a number of data nodes defined in this YANG module that are > writable/creatable/deletable >=20 >>=20 >> 'babel/hmac' and 'babel/dtls': These contain security credentials >> that influence whether packets are trusted. >>=20 >> I'd consider making two separate (but related) points about = controlling >> whether incoming packets are trusted, and whether outgoing packets = are >> produced in a way such that the receiver will treat them as trusted. >> (Changing just the use-send/use-verify values can allow for a valid = key >> to be misused, without changing the actual keys being used, which = could >> present an interesting attack in some scenarios.) >=20 > Ok. How about this? Thanks again to Barbara for providing the text. >=20 > =E2=80=9CThese contain security credentials > that influence whether incoming packets are trusted, and whether = outgoing packets are > produced in a way such that the receiver will treat them as = trusted.=E2=80=9D >=20 >>=20 >> Some of the readable data or config false nodes in this YANG module >> may be considered sensitive or vulnerable in some network >> [...] >> 'babel/hmac' and 'babel/dtls': These contain security credentials, >> include private credentials of the router. >>=20 >> We do require the actual secret keys to not be readable, so we might >> consider phrasing this more as a reiteration of that requirement than = a >> statement of risk if they are read out. >=20 > How about this? Thanks Barbara. >=20 > 'babel/hmac' and 'babel/dtls': These contain security credentials, > including private credentials of the router; however it is > required that these values not be readable. > =20 >>=20 >> Some of the RPC operations in this YANG module may be considered >> sensitive or vulnerable in some network environments. It is thus >> important to control access to these operations. These are the >> operations and their sensitivity/vulnerability from a RPC operation >> perspective: >>=20 >> This model does not define any RPC operations. >>=20 >> We do define a couple of actions, though, which are like RPCs except >> "[t]he difference between an action and an rpc is that an action is = tied >> to a node in the datastore, whereas an rpc is not". This is perhaps = an >> omission in the YANG security considerations template, but I don't = think >> we should let that stop us from noting the actions we define are >> carefully designed to have minimal security impact and minimal >> side-channel leakage. (Well, I guess that's not hard for the >> stats-reset one, but for the MAC key test one it's quite important.) >=20 > How about this? >=20 > OLD: >=20 > This model does not define any RPC operations. >=20 > NEW: >=20 > This model defines two actions, one of which > allows for MAC key and MAC algorithm to be tested.=20 > It does not allows for them to be changed. >=20 >>=20 >> Section 6.1 >>=20 >> I don't have a great sense for why RFC 4868 needs to be normative. >=20 > RFC 4868 is cited as a reference in the YANG model, which is = normative. >=20 >>=20 >> RFC 8968 seems missing as a listed reference at all (which would of >> course need to be normative as 8967 is). >=20 > Agreed. >=20 >>=20 >> Section 6.2 >>=20 >> I think RFC 7693 should be normative, since you need it in order to = do >> the blake2 stuff. >=20 > Ok. Will move it to normative section. >=20 >>=20 >> RFC 8341 might become normative if we add nacm:default-deny-all = stanzas. >=20 > Agreed. >=20 >>=20 >> NITS >>=20 >> The tree diagram and the prose use different orders for the various >> child elements, which is a little distracting. >=20 > Ok. Will fix the order. >=20 >>=20 >> Section 1 >>=20 >> [RFC8966]. The data model is defined using YANG 1.1 [RFC7950] data >> modeling language and is Network Management Datastore Architecture >>=20 >> "the YANG [data modeling language]" >=20 >>=20 >> Section 2.1 >>=20 >> Information Model and this data module. The information model >> mandates the definition of some of the attributes, e.g. 'babel- >>=20 >> comma after "e.g." (as well as before). (I'll try to only note it = once, >> though it appears many times.) Likewise for "i.e." >=20 >>=20 >> Section 2.2 >>=20 >> In addition to information like the version number implemented by >> this device, the model contains subtrees on 'constants', >>=20 >> The actual data model (and the information model, for that matter) = show >> that the 'version' leaf contains "the name and version of this >> implementation of the Babel protocol". The text here suggests that = it >> contains the protocol version number implemented by the device, which = is >> different. So I'd suggest "the implementation and version used by = this >> device" instead. >=20 >>=20 >> The 'interfaces' subtree describes attributes such as 'interface' >> object that is being referenced, the type of link, e.g. wired, >>=20 >> "the 'interface'" >=20 > Ok to the above suggested changes. >=20 >>=20 >> wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- >> horizon' and whether the interface is enabled or not. >>=20 >> I suggest using semicolons for the outer layer of grouping, to avoid >> overloading commas for different hierarchies of separation. >=20 > Something like this? >=20 > OLD: >=20 > The 'interfaces' subtree describes attributes such as 'interface' > object that is being referenced, the type of link, e.g. wired, > wireless or tunnel, as enumerated by 'metric-algorithm' and 'split- > horizon' and whether the interface is enabled or not. >=20 > NEW: >=20 > The 'interfaces' subtree describes attributes such as 'interface' > object that is being referenced, the type of link, e.g., wired, > wireless or tunnel; as enumerated by 'metric-algorithm' and 'split- > horizon=E2=80=99; and whether the interface is enabled or not. >=20 >=20 >>=20 >> Finally, for security two subtree are defined to contain MAC keys = and >> DTLS certificates. The 'mac-key-set' subtree contains keys used = with >>=20 >> "subtrees" >=20 >>=20 >> interfaces. The dtls subtree contains certificates used with DTLS >>=20 >> single quotes for 'dtls'. >> "the DTLS" >=20 >>=20 >> Section 2.3 >>=20 >> Similarly, an interface that is a metered 3G link, and used for >> fallback connectivity needs much higher default time constants, = e.g. >>=20 >> Comma after "connectivity". >=20 >>=20 >> HMAC: Keyed-Hashing for Message Authentication [RFC2104], Using >> HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4868], Datagram >>=20 >> The "with IPsec" part of RFC 4868's title seems to have been dropped. >=20 > Ok to the above suggested changes. >=20 >>=20 >> "This implementation supports two-out-of-three metric >> comp algorithm."; >>=20 >> "the two-out-of-three". >> Also, do we really need to (silently) abbreviate "metric computation" >> (multiple occurrences)? >=20 > Should be: >=20 > =E2=80=9Cthe =E2=80=99two-out-of-three=E2=80=99=E2=80=9D.=20 >=20 > Will fix metric comp occurrences. >=20 >>=20 >> "This implementation supports Expected Transmission Count >>=20 >> "the Expected" >=20 > Ok. >=20 >>=20 >> "This implementation supports hmac-sha256 MAC algorithm."; >>=20 >> "the hmac-sha256" >>=20 >> "This implementation supports x-509 certificate type."; >>=20 >> "the X.509" >=20 > Ok to both. >=20 >>=20 >> "This implementation supports raw-public-key certificate >> type."; >>=20 >> Missing article, per the theme, but I think it would also be more >> conventional to spell the name as "RawPublicKey". >=20 > Ok. That was done to be consistent with the IM. >=20 >>=20 >> base metric-comp-algorithms; >> if-feature "etx-supported"; >> description >> "Expected Transmission Count."; >=20 >>=20 >> I'd put an "algorithm" in here somewhere >=20 >=20 > How about: >=20 > =E2=80=9CExpected Transmission Count (ETX) metric compilation = algorithm.=E2=80=9D >=20 >>=20 >> "BLAKE2s algorithms supported. Specifically, BLAKE2-128 is >> supported."; >>=20 >> I'd just say "BLAKE2-128 algorithm supported." >=20 > Then shouldn=E2=80=99t the feature say >=20 > feature blake2-128-supported? >=20 >>=20 >> "Raw Public Key type."; >>=20 >> "certificate type" >=20 >>=20 >> leaf router-id { >> type binary; >>=20 >> (If length constraint is applied earlier, it should apply here as = well.) >>=20 >> "Indicates whether statistics collection is enabled = (true) >> or disabled (false) on all interfaces. When enabled, >> existing statistics values are not cleared and will be >> incremented as new packets are counted."; >>=20 >> I suggest "on transition to enabled". >> (Also, thank you for clearly spelling out which behaviors true/false = map >> to!) >=20 >>=20 >> A value of true indicates split horizon optimization >> is used."; >> "the split" >>=20 >> "List of references to the mac entries that apply >> to this interface. When an interface instance is >> created, all mac instances with default-apply 'true' >>=20 >> s/mac/MAC/ (twice) >>=20 >> "Indicates whether the cached_info extension is = included >> in ClientHello and ServerHello packets. The extension >>=20 >> s/packets/messages/. >=20 > Ok to the above suggested changes. >=20 >> Also, it's conventional to refer to TLS extension names enclosed by >> double quotes, but I guess in the context of a YANG leaf description >> that's not really feasible. >=20 > Correct. >=20 >>=20 >> dtls-cert-types. This list is used to populate the >> server_certificate_type extension in a Client Hello. >>=20 >> s/Client Hello/ClientHello/. >>=20 >> list mac-key-set { >> key "name"; >>=20 >> description >> "A mac key set object. If this object is implemented, it >> provides access to parameters related to the MAC = security >> mechanism."; >>=20 >> s/mac/MAC/ >>=20 >> "A string that uniquely identifies the mac object."; >>=20 >> s/mac/MAC key/ >>=20 >> If 'true', this instance is applied to new babel- >> interfaces instances at the time they are created, >> by including it in the mac-key-sets list under >> interfaces. If 'false', this instance is not applied >>=20 >> s/under interfaces/under the interface/ >>=20 >> to new interfaces instances when they are created."; >>=20 >> s/interfaces/interface/ >>=20 >> If 'true', this instance is applied to new interfaces >> instances at the time they are created, by including = it >> in the dtls-certs list under interfaces. If 'false', >>=20 >> s/under interfaces/under the interface/ >>=20 >> this instance is not applied to new interfaces >> instances when they are created."; >>=20 >> s/interfaces/interface/ >=20 > Ok to make the above suggested changes. >=20 > Thanks again for a detailed review! >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_0872F95C-C8C5-4051-B7C3-702AFE11FFA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben,

On re-reading = one of your comments, I realized my response to that comment was not = quite right. See inline.

On Jun 8, 2021, at 8:47 AM, = Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Hi Benjamin,

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

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

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

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

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


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


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



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

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

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

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

How about this?

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

NEW:
            = "Indicates whether use of cached_info extension is enabled.
             The extension = is enabled for inclusion if the value is 'true'.";



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

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

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

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



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

Section 2.2

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

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

Fixed.


Section 2.3

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

Is this always = true, or only sometimes?

How about this?

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

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


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

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

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


=         leaf router-id {
=           type = binary;
=           description =             "r= outer-id of the source router for which this route is
=             &n= bsp;advertised.";

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

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

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

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


=         leaf next-hop {
=           type = inet:ip-address;
=           description =             "T= he next-hop address of this route. This will be empty if
=             &n= bsp;this route has no next-hop address.";

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

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

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

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


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

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

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

            type identityref = {
              = base dtls-cert-types;
        =     }

which would a list of certificate types this particular = implementation supports. The assumption is that the list of certificate = types that the implementation can support is not different from what it = does support. @Barbara, would it be ok for the data model to just keep = one list of certificate = types?

I think the confusion is stemming from = the fact that =E2=80=98dtls-cert-types=E2=80=99 is a base identity, and = all the identities, e.g. x-509, and raw-public-key are derived from that = base identity. However, =E2=80=98dtls-cert-prefer=E2=80=99 is not a = leaf-list of =E2=80=98dtls-cert-types=E2=80=99 (the base identity) but = rather the types listed in ../../dtls/certs/type. Rather than the change = I suggested earlier, we need to reword the description statement to = say:

OLD:

            = "List of supported certificate types, in order of
             preference. = The values MUST be among those listed in
  =           =  dtls-cert-types.

NEW:

      =       "List of supported certificate types, in order = of
            =  preference. The values MUST be the =E2=80=98type' attribute = in
            =  in the list =E2=80=98certs=E2=80=99 of the list =E2=80=98dlls=E2=80=99= (../../dtls/certs/type).

Does this help? Thanks.



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

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

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

OLD:

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

NEW:

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


=           container = stats {
=             co= nfig false;
=             de= scription
=             &n= bsp; "Statistics collection object for this interface.";

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

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


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

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

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


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

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

Ok. Will remove the default value.


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

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

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


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

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

How about this?

OLD:

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

NEW:

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


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

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

How about this?

OLD:

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

NEW:

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


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

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

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


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

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

Section 4

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

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

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


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

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


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

We say the following in the security considerations = section.

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


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

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

Thanks to Barbara for digging this out:

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

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


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

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

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

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


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

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

How about this? Thanks Barbara.

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

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

  This = model does not define any RPC operations.

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

How about this?

OLD:

   This model does not define =
any RPC operations.

NEW:

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


Section 6.1

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

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


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

Agreed.


Section 6.2

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

Ok. Will move it to normative section.


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

Agreed.


NITS

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

Ok. Will fix the order.


Section 1

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

"the YANG [data modeling = language]"

Section 2.1

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

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

Section 2.2

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

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

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

"the 'interface'"

Ok to the above suggested changes.


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

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

Something like this?

OLD:

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

NEW:

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



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

"subtrees"

  interfaces.  The dtls = subtree contains certificates used with DTLS

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

Section 2.3

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

Comma after = "connectivity".

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

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

Ok to the above suggested changes.


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

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

Should be:

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

Will fix = metric comp occurrences.


=         "This implementation = supports Expected Transmission Count

"the = Expected"

Ok.


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

"the = hmac-sha256"

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

"the = X.509"

Ok to both.


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

Missing article, per the theme, but I think it = would also be more
conventional to spell the name as = "RawPublicKey".
Ok. That was done to be consistent with the = IM.


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

I'd put an "algorithm" in here somewhere


How = about:

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


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

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

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

feature = blake2-128-supported?


=         "Raw Public Key = type.";

"certificate = type"

=         leaf router-id {
=           type = binary;

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

=             "I= ndicates whether statistics collection is enabled (true)
=             &n= bsp;or disabled (false) on all interfaces. When enabled,
=             &n= bsp;existing statistics values are not cleared and will be
=             &n= bsp;incremented as new packets are counted.";

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

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

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

s/mac/MAC/ (twice)

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

s/packets/messages/.

Ok to the above suggested changes.

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

Correct.


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

s/Client Hello/ClientHello/.

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

=           description =             "A= mac key set object. If this object is implemented, it
=             &n= bsp;provides access to parameters related to the MAC security
=             &n= bsp;mechanism.";

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

s/mac/MAC key/

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

s/under interfaces/under the interface/

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

s/interfaces/interface/

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

s/under interfaces/under the interface/

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

s/interfaces/interface/

Ok to make the above suggested changes.

Thanks again for a = detailed review!

Mahesh = Jethanandani
mjethanandani@gmail.com






Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_0872F95C-C8C5-4051-B7C3-702AFE11FFA5-- From nobody Sun Jun 27 21:06:47 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321EE3A2966; Sun, 27 Jun 2021 21:06:46 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzU5fQM7c7BN; Sun, 27 Jun 2021 21:06:45 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 CCB453A2965; Sun, 27 Jun 2021 21:06:44 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id y76so9951025iof.6; Sun, 27 Jun 2021 21:06:44 -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=YYSxFCdrZ3YXm0ZB6m2IKrMa1xpA2GXbLki4updUQ9Y=; b=PHJthY+LpDSVBomMbIv/SbBvtK+7Pk0IDdFYX+U2wrUZ9eyX1XbtWdJZhxWs+MwTAh LBRzAhXsWWwVAkEVzMugOp95FexW9HsPlKqCOidEUgIJihYs+GuMuml2lqJlcysttAIQ jx8y3caLni1UZ0J0TVpnjs8IFkFvALd1tmzewURN3MZxqGF1PPmT0mYgOALPD3Jmf5eu i6irPYWunRF05XitJVveZMPDsxUanmSifvxuNVXkogkrlXhMWrNlxHi0BNirznTxDH52 J94OqJOz582tert90Xi+yiyaKIHErM5nhWBU1XuQvtReKR/h1rPPc4PiBwG2ZgV7IRf+ S0UA== 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=YYSxFCdrZ3YXm0ZB6m2IKrMa1xpA2GXbLki4updUQ9Y=; b=srnk+41qLEESg4kr1iEW5cfkoqjGp9TZsOy2ukVOPrgAv1i92jjYkArNQtjJQtCH2o L6jW0F/rTI5Pgcz7o/ZGk4W0x/jnU6RWfUXdqLdVedoV+6DL+vRn3fYjDU/+OGIk4agG pcPE5pA2F9N0AdjT5j0yYF6zNCR+s56tQ4ObFIgooFMPT2GCWKLbdGYRz1wat1RUEXF4 BbersCKioTFLiaEnvZ2zjcCXYDYYyZ9ycCZn6AA8UMggmh2r5TaXT+5ed8ARsyyal2ft ghQ6g/Uu2NXfav8eQz/KCvaNL8k0sUxnqW5JgMmGG6s+P8iVX+A3MNOGQXGgcsvxDSBQ /6kg== X-Gm-Message-State: AOAM53109JlZXqRFn7BvWC4XoNp/LOp/ZK/PtEdYJWsWUP/9g8LFbKo2 OE19uCz+w5luZ68XaGeDeRpYyISZZ2QDuOpBMovzqmFD91I= X-Google-Smtp-Source: ABdhPJwW2VDVpuMwTmu/xVOgBLneuS4XG1o5qSRyU0hLuMpBJGMGvCYfjDJBbHbTItKjpURf83xen5ByFy0xM1MsSZg= X-Received: by 2002:a02:2a07:: with SMTP id w7mr20998768jaw.96.1624853203330; Sun, 27 Jun 2021 21:06:43 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Mon, 28 Jun 2021 00:06:32 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="000000000000ff296505c5cb9daf" Archived-At: Subject: [babel] Tentative Babel WG meeting 26 July, Call for Presentations 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, 28 Jun 2021 04:06:46 -0000 --000000000000ff296505c5cb9daf Content-Type: text/plain; charset="UTF-8" Hi, For the July IETF meeting, a Babel WG meeting is tentatively scheduled for 21:30 - 22:30 UTC on Monday, 26 July. (That's 5:30pm to 6:30pm US Eastern time.) Anyone who would like to present should contact the chairs or post to this list. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com --000000000000ff296505c5cb9daf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

For the July IETF meeting, a Babel = WG meeting is tentatively scheduled for 21:30 - 22:30 UTC on Monday, 26 Jul= y. (That's 5:30pm to=C2=A06:30pm US Eastern time.)

=
Anyone who would like to present should contact the chairs or post to = this list.
=C2=A0
Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2= =A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panor= amic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com
--000000000000ff296505c5cb9daf-- From nobody Mon Jun 28 04:47:27 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6564A3A366B; Mon, 28 Jun 2021 04:47:26 -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 gWTRZLj2TC5c; Mon, 28 Jun 2021 04:47:24 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818E63A3668; Mon, 28 Jun 2021 04:47:23 -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 15SBlJiE005410; Mon, 28 Jun 2021 13:47:19 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B8B20C5175; Mon, 28 Jun 2021 13:47:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id FVIYdSJdzMn0; Mon, 28 Jun 2021 13:47:17 +0200 (CEST) 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 9829DC5166; Mon, 28 Jun 2021 13:47:16 +0200 (CEST) Date: Mon, 28 Jun 2021 13:47:16 +0200 Message-ID: <87czs6yzwb.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake CC: Babel at IETF , babel-chairs In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 28 Jun 2021 13:47:19 +0200 (CEST) X-Miltered: at korolev with ID 60D9B6C7.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 60D9B6C7.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 : 60D9B6C7.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] Tentative Babel WG meeting 26 July, Call for Presentations 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, 28 Jun 2021 11:47:26 -0000 I'd like to ask the WG whether to revive the RTT-based routing draft. It's deployed in production, works well, but we don't know how to do a theoretical analysis. Anywhere between 10 and 15 minutes, at your preference, I'll vary the amount of background depending on the time you give me. -- Juliusz From nobody Mon Jun 28 09:41:37 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8510B3A0E22; Mon, 28 Jun 2021 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=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 avD5vR4dmTqT; Mon, 28 Jun 2021 09:41:31 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60343A0E1D; Mon, 28 Jun 2021 09:41:30 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id k16so22920747ios.10; Mon, 28 Jun 2021 09:41:30 -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=dlAp8ZlRiK+j+txhSR5FovvLLZP8OAgyZW1iXpNHMIs=; b=kidtDd/JpkOwRu+xqHdSxc3aNNqLFAIqcHDG7zdA2YRfW7Mb8yEEFvW9oF53xYyb3E 7WSRccDYcnia1EnoxRcwris1JauBhrzOFrBf+K6NsQ0v82BmwkChRwo2hGKXxDRnSALb eP27aZU4Cbiph8g2NqMFpnvnRWSSgYABblUstx7Ck5FuaYsPI4sjIJ9g53TqLK+NT4Jy Hb5Pv4Jvdfs+PZ2HvF1a9f7gpnaEJy++HvdbEZ9WiucHwmeSbVGsVKCR2YACyusRqWme qdQu+9En97D3hb7+8neY8HdOkr2xA8KqoaOlgqBdGYdZDdFlXNY0/m2AObeSV10fr/LV 45bg== 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=dlAp8ZlRiK+j+txhSR5FovvLLZP8OAgyZW1iXpNHMIs=; b=HDX1qvP4P8R+9eNwSsK5VHXmPEd+XLiUFSbw+p9aaOaRUulZ11ovCLUannENdP/YfL TfrVP7HV/1JbAGvjDpPfjvZbilUoW43fsAdrUwOAQg0vloL5oKmKFrFBa63LclXMtG3T VabQ5JvY2e671HQbAXZX4npVtB63CgoJTYw+HJHQIioccciN0fIcIWNniKG9YvPEDDsj Q722p9b4KKD5xI/QAGSt0g7ZOheLfbDugGKp/olVVMGyMkgKo1s1c3DSLVofj1wamZgr 1IkxFC9V3g/tjCYdk13eqAUR89x7DIdiVCBUY+fpMj37CTr4AEEadHkUe2C3nfLA/aub eU8Q== X-Gm-Message-State: AOAM531ozY9TTiLuwwzVmuPewPfxkYCaa6cACEb3ngJpbKI36aI8suYz l0sBAHOzrXmQXNb3XIXNehS4GVMwSnH1Gd3T1fc= X-Google-Smtp-Source: ABdhPJzoe9Mjoail8niXkk0VgelYhcz7xJsGQWwLtRHegzM7ReKNWX2zJBTsZWm0VD+0QTbBJ0m7ktj9+jbzLKd8Z04= X-Received: by 2002:a02:3506:: with SMTP id k6mr431988jaa.39.1624898489725; Mon, 28 Jun 2021 09:41:29 -0700 (PDT) MIME-Version: 1.0 References: <87czs6yzwb.wl-jch@irif.fr> In-Reply-To: <87czs6yzwb.wl-jch@irif.fr> From: Donald Eastlake Date: Mon, 28 Jun 2021 12:41:18 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Tentative Babel WG meeting 26 July, Call for Presentations 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, 28 Jun 2021 16:41:36 -0000 Hi Juliusz, Sounds good. I'll allocate 15 minutes for RTT-based routing. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Jun 28, 2021 at 7:47 AM Juliusz Chroboczek wrote: > > I'd like to ask the WG whether to revive the RTT-based routing draft. > It's deployed in production, works well, but we don't know how to do > a theoretical analysis. > > Anywhere between 10 and 15 minutes, at your preference, I'll vary the > amount of background depending on the time you give me. > > -- Juliusz From nobody Wed Jun 30 17:10:11 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177CE3A3103; Wed, 30 Jun 2021 17:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bo9ZFhsyblQy; Wed, 30 Jun 2021 17:10:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B7D3A30F5; Wed, 30 Jun 2021 17:10:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 44FF9F40768; Wed, 30 Jun 2021 17:09:46 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, babel@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210701000946.44FF9F40768@rfc-editor.org> Date: Wed, 30 Jun 2021 17:09:46 -0700 (PDT) Archived-At: Subject: [babel] =?utf-8?q?RFC_9046_on_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: Thu, 01 Jul 2021 00:10:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9046 Title: Babel Information Model Author: B. Stark, M. Jethanandani Status: Informational Stream: IETF Date: June 2021 Mailbox: barbara.stark@att.com, mjethanandani@gmail.com Pages: 20 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-babel-information-model-14.txt URL: https://www.rfc-editor.org/info/rfc9046 DOI: 10.17487/RFC9046 The 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. This information model only includes parameters and parameter values useful for managing Babel over IPv6. This document is a product of the Babel routing protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC