From nobody Mon Jul 19 03:54:17 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899583A2F1E; Mon, 19 Jul 2021 03:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 QBZVFVl6iSOn; Mon, 19 Jul 2021 03:54:06 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::70e]) (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 88BE43A2F15; Mon, 19 Jul 2021 03:54:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ekEr0RpadAa76ebzA/v1ZcpNLn/CjC/21/uboJxX9S0juRzud8I7C1TrKp5OjF8eKLRhJpWmTwTpBv69pg4dZHHSDv5exkJun4U8roKSubi2vZAJjTGDoUZiAhvZX6JgQuu1ofSNjjjMKqryNvqei43rn5NQWPq54OI7hE7oDoAyPLMdNmumI6xGG+v9g0Nua1mfgm7es5cizsXolyU4x7jWgBa0hKkhDjCLII/YNXSSPmVXiG+YJ2kFxReeWNiq6S14lwYdr4cpgAdJ17chVw/VQS841kyKRsN5aR7k3JWSLoMjATM97+MW9g5gMsPOkxGYqOVsOPWRjW/Wsz1Hyg== 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=0BSPejSFyuXGjU9xcLsCi+SuqWLuCfh5wiEB0wkSRBg=; b=J6pna8l6JK4PWBfkLFc2bFd+4UME2+gtERMJdPnAbmU9zpMxw7jZFyhkFoxNP8FvtoNzueGGtRUClrrGeEi7PKnFk8tfmWoSGZ/TA6c0NAc1iJhJWMySDcc5i69Am+eY9uuSTGB4thBEDoIrWLq9bN6ezaqDnhIxW4ZT7N/MUYaYiOHHK9Ptq+10wPPrPWTiVgO68avDYw7sIoBdod4gc5w843tOdx1cZP3w9pP8ceVBjiZs6xaS/3C9WL66qaMsVk/oN2xaivxdWF0Z/bytvyKB4JtAdNumQVM67aG2tyQsFiCZQ26o6f3p8thlYvfGbFoZjfhoRuDAe4bLJPXAXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0BSPejSFyuXGjU9xcLsCi+SuqWLuCfh5wiEB0wkSRBg=; b=DRwKZ7rgvSVzN0ArmK/wzgIYtZAz+FlAMJwxPrksgR2t9hPURkvdEliiZ+s7nQi9p3ECsU9La8t7666IliaxkxWc8zMedPWJ9Bpxlrcbhtej9RgMFvfg93iTzUFc/Jne71s1Xz6xiZsqrShLGHBExIsrhHgMesbBtaxZGScR9gk= Received: from AM7PR83MB0449.EURPRD83.prod.outlook.com (2603:10a6:20b:1b5::5) by AM5PR8303MB0068.EURPRD83.prod.outlook.com (2603:10a6:224:6::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.5; Mon, 19 Jul 2021 10:53:55 +0000 Received: from AM7PR83MB0449.EURPRD83.prod.outlook.com ([fe80::50db:87ce:253e:f127]) by AM7PR83MB0449.EURPRD83.prod.outlook.com ([fe80::50db:87ce:253e:f127%5]) with mapi id 15.20.4373.005; Mon, 19 Jul 2021 10:53:55 +0000 From: Jon Hardwick To: Yingzhen Qu CC: "rtg-ads@ietf.org" , "draft-ietf-rtgwg-policy-model.all@ietf.org" , "rtg-dir@ietf.org" , "rtgwg@ietf.org" Thread-Topic: [EXTERNAL] Re: Rtgdir Last Call review of draft-ietf-rtgwg-policy-model Thread-Index: AddqdlcatIWqYTSdSLCxvFlaoKpylgCspxEAA9eQ1rA= Date: Mon, 19 Jul 2021 10:53:55 +0000 Message-ID: References: <88D465F6-19F6-48C3-AA16-C25B49F89C28@gmail.com> In-Reply-To: <88D465F6-19F6-48C3-AA16-C25B49F89C28@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1d8aefbb-6fef-45ed-a7bc-7fa35daf3512; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-07-19T10:17:01Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2be2bb9-f930-4da8-39bf-08d94aa38100 x-ms-traffictypediagnostic: AM5PR8303MB0068: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aHfQPB0gj1ynIpTRMN0NXOm4NuqJhPIVfbPCRTmzUYgqyiNAKZzxNwD8qCCg7nnxw1tpi6MRvm+kGNPNz1DC7q+pujFslTCeouMEXjNJ+5m4nbOCBajzr/gVVdVyKW4+pqa+/fudjorZCoUSNiapBymmpil6xO4YNBnno5Wx4raKIBXTRC0YKAaf9jaJqw025fNMxSwBpXe7Vb1PAC1lzRHShUp1InhxSDKm5kafcgLiKdmWzYeFXM7+vpYXYKhRRkcc62FPT6/9rAIopLiZvnFMxbjaWRkhemWl09gPypgpwCIO6yxPEYB2xKpmWt+1urTnU1HZTxtBp9oHPhB6d6TX/D/twBeyCcvzAbbiWJ+3gRTxzw2BfLNGERKcdMG7l7AfibRMlX+/3tSR0VRt3rc1AH1c5Ww7GtxFYG355H2VhjC4sbUyAECU4cfrbpdD/m8DlllOtvyzghqhNR3Iy4tUzcy4+XE3dk3a0STDz9VDC6RiyjcRElombdC1BvWLlHMFRvRTFdfNYIDV9zMRLpCWLfZY2C4Lny0TG62n3PfOru7xg+HTV6ZYKLwNzSSNbQE99pEp/4vb5/69BmTCA6T7EuCB/9+hcbY+XsfYnDfFbqxvISqlO9CVFvaoxz6p7+yqNj+STCEPNU7hNBfnL+GXlLOCd5Zh7TgpNmtfpt0cUMphcqBHs9hEDPHZWUCa5Nge7Puej09vwjI99NA3VHsUbYYEoL3wbT79+x+WsaT+RyDAV/vOiQFTJNgQAkevyov3U34gClGxtlqfovDU1gcpvGEf9C97FgWuLPwf9xw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR83MB0449.EURPRD83.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(66446008)(66556008)(33656002)(64756008)(54906003)(66476007)(76116006)(66946007)(7696005)(10290500003)(508600001)(71200400001)(53546011)(5660300002)(6506007)(38100700002)(2906002)(122000001)(9686003)(55016002)(86362001)(6916009)(8990500004)(8936002)(166002)(26005)(52536014)(186003)(83380400001)(4326008)(82960400001)(8676002)(82950400001)(66574015)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?m4T32zu9ZEMq4Wa13uSDgoZjfqCTfFh8M7/dunC8B5N1Ez8SZpV5TjMIlrh1?= =?us-ascii?Q?xnqehpt/pS6lNtcRF5n16/6NbYaLi9qU9+VdNayWdEx//diMGadzcE00ekME?= =?us-ascii?Q?bjAtrD/lVesdaP2ezWX2jDdela3EN+YEvqgXaPqhuF6mXqJPLb0GWMBXWAAG?= =?us-ascii?Q?V18aMm/IzrgIzdZYW7ZpzIaN0KJvAnwxV3I20OYyhlhu84tZEjyhShZU9kcM?= =?us-ascii?Q?h5Z0vgXYm72MWqymN5qkizR9tmdSpuKHWt47fPES6wsyBn4UH3afnPyvkzzz?= =?us-ascii?Q?kF9GThArmeVFqfRZPO6ehnqCrNjKdJKj24PBrVn26Uihh/E8CS1CnReOatzH?= =?us-ascii?Q?Fguu2BM1hiUjeW9SDdOFzt5+az/64vceKpTDN6KbaIUyE5TDmg1mbF+7tdOs?= =?us-ascii?Q?ghCBx0RNrjzi1Kbr0ZU6NOO8K5ytbFQr6u5JPngigFEoXQBs1zbYVW/Csgkw?= =?us-ascii?Q?L96P1/kE6y5V/UG5QieOWjyL3TvBn7++AJzY10EI2Y+UlhGNe4RHohDBxE/N?= =?us-ascii?Q?XSz2J0cNo7dAVgBvoxSNwfn5IZQQCCnT3zifsN17qQ4Ze4L5omw1uOx5OtDr?= =?us-ascii?Q?zrMdk7AjXSfxF+UUMNLpUMDtBeGkDqG8j4yTLGy+0aOxQWHQNwMLGckxYRYO?= =?us-ascii?Q?HTVF9mOm4IjFr2/nfFuVYdfTKFev8OKTn8kLRCwlcL0ldxqGPl/nkxmAwhVX?= =?us-ascii?Q?yRvHZDyyihuivIGuweXLdj3bmoYtWHMlYcVQy9zCUINigqb/ga801EG3nbKY?= =?us-ascii?Q?71lcATaNmg5q+hTJT05BR5n5VXzwoDatmFbjDzdsozOvv0Jxp5wz41ECLT3W?= =?us-ascii?Q?MTZexbKRxedMmcg528MYm8YLjE3flLOSXSsxU+Tkys8l7xVEkhHt0ZL/UlZx?= =?us-ascii?Q?u5CahgGN+KSZDrEekReH5Z2Cn+ywI329vJhWYPQbzIEOFzoJXYFIBe9QbLBc?= =?us-ascii?Q?WRq9WzdFZZ4/NUJlUSQh+xOR6xHK1pFVtrVcSPeYxZEj4gGr7+6WCox1V7ng?= =?us-ascii?Q?UdQv/3umcc6aDhI06B+n+ZTFj2Lmw0VPjOgeQ8quNUquMdgjIbJRiFI7abhs?= =?us-ascii?Q?hAjjP0mP9Wwy9/Pgde7qAAQmoI7QNfzValPEsVeyHxNrC3OcY/VVptSkA1jK?= =?us-ascii?Q?Upg1hByVGkdKS0iK6EZLKiIy9Q8aL79fQy0h0fGI7PV1SjBDtpi6JavMQ+xs?= =?us-ascii?Q?2REIt4+HWpweepA5k2afbT/1tR5OkpRz1EJls0QPqC8Vz8vQPFJDcD1euhs?= =?us-ascii?Q?=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7PR83MB0449A29CF92619F0BE68A342A3E19AM7PR83MB0449EURP_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR83MB0449.EURPRD83.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2be2bb9-f930-4da8-39bf-08d94aa38100 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2021 10:53:55.2602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Zth9I4eCJkDkEF084WlkPbcVCWvQ8g4Tv2d461obRJK7nincTH/x3ypy782rgZ6+eDmKYPcwNHKs2mkdzaIjdTh0a2MFNw1CNc2RD+edB/k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR8303MB0068 Archived-At: Subject: Re: [RTG-DIR] [EXTERNAL] Re: Rtgdir Last Call review of draft-ietf-rtgwg-policy-model X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 10:54:12 -0000 --_000_AM7PR83MB0449A29CF92619F0BE68A342A3E19AM7PR83MB0449EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yingzhen Sorry for the delay in replying. I'd like to discuss a couple of points - p= lease see [Jon] below... Cheers Jon From: Yingzhen Qu Sent: 29 June 2021 21:54 To: Jon Hardwick Cc: rtg-ads@ietf.org; draft-ietf-rtgwg-policy-model.all@ietf.org; rtgdir@ie= tf.org; rtgwg@ietf.org Subject: [EXTERNAL] Re: Rtgdir Last Call review of draft-ietf-rtgwg-policy-= model Hi Jon, Thanks for the review. Please see my answers inline. Thanks, Yingzhen On Jun 26, 2021, at 3:32 AM, Jon Hardwick > wrote: I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please seehttp= ://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir. Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-rtgwg-policy-model-29 Reviewer: Jon Hardwick Review Date: Jun 26th, 2021 Intended Status: Standards Track Summary: This document provides a foundational framework for the definition of routi= ng protocol policies regarding the filtering in / out of routes when they a= re imported / exported between routing protocol neighbors and/or routing pr= otocols and the RIB. Its purpose is to provide a framework which can be aug= mented by routing protocols in their policy YANG modules. I think that the = document meets its goal very well. The document is in good shape. It's clear, well-defined in its scope and ea= sy to read. I have a few minor concerns that I would like to see addressed = before publication. Minor Comments: Section 4.2 Why no match-set-options for neighbor-set? Is there no application for dif= ferentiating between "any of these neighbors" and "none of these neighbors"= ? You can only match on a single interface. Why is that? Was there no use cas= e for any ANY / INVERT match on a set of interfaces? I am thinking of multi= homing use cases. [Yingzhen]: Typically you can apply a route-policy or route-map to an inter= face or a neighbor, plus you can configure multiple route policies. I didn'= t get your multihoming example, would you please elaborate? And why the cur= rent module doesn't work? [Jon]: I Am Not An Operator so I don't have a real use case, but this is mo= re of a question / thought experiment about how it will be used. It could b= e that I've misunderstood how this would be done in your model so please ex= plain if I've got this wrong. Say I am configuring an L3VPN for a customer= who will be multi-homed into my router over two interfaces (or more) and t= hat I want to apply the same policy to all those interfaces. In a "traditio= nal" CLI I might create a route map and then configure a reference to that = route map on each interface. In this YANG model it looks like I must config= ure two identical policy statements, one matching on interface A and the ot= her matching on interface B, because I have no ability to configure "match = on either interface A or interface B". The difference with the route map se= ems to be that I've had to configure the same policy statement twice. Perhaps this example might be solved by matching on a neighbor-set or on a = VRF instead. I was just surprised not to see an equivalent interface-set. "Comparison conditions may similarly use options..." - what do you mean by = a "comparison condition"? The term is not used elsewhere in the document. [Yingzhen]: This is not really a term. It simply meant how to compare or th= e conditions to compare. I'd suggest we leave this to RFC editor. [Jon] It's just that it sounds like it means something specific. The text s= ays "Match conditions may be further modified... Comparison conditions may= further use..." and this makes me wonder what the difference is between a = match condition and a comparison condition. If I had to take a guess, it so= unds like "match condition" refers to comparing against a set of values whe= reas "comparison condition" refers to comparing against a single scalar val= ue. The basic conditions defined in this base model appear to only use set = comparisons, but you are saying that other models can augment this with sin= gle scalar value comparisons, in which case those models can also define "l= ess than, greater than" etc. options to control the match, although those t= ypes of option are not defined here in the base model. Is that right? In wh= ich case, I wonder if it is even worth saying / explaining, or perhaps remo= ving this sentence and leaving it to the augmenting models to define what t= hey want? [Jon]: Actually I have spotted another comment I want to make. In "grouping= neighbor-set-condition" the description says "Match a referenced neighbor = set according to the logic defined in the match-set-options-leaf" but there= is no such leaf in this grouping. Should there be, or is the description w= rong? [Jon]: One more nit - the description for "grouping tag-set-condition" refe= rs to the "match-options-set leaf" - it should be "match-set-options leaf". Section 5 "If the conditions are not satisfied, then evaluation proceeds to the next policy statement" I think that evaluation also proceeds to the next policy statement if the c= onditions were satisfied, but the actions did not include either accept-rou= te or reject-route. Is that correct? I think it would be worth making that = explicit. [Yingzhen]: This is included in the first paragraph of section 5. Please le= t us know if you think it's not clear. [Jon] Yes, on re-reading it, I think it's fine as written. Section 7.2 p21: description "Mask length range lower bound. It MUST NOT be less than the prefix length defined in ip-prefix."; Why must it not be? And is there a situation in which it makes sense to al= low it to be greater than the prefix length defined in ip-prefix? Should t= here be a "must" clause to police this constraint? [Yingzhen]: Here are a couple of prefix-list config examples. The "MUST NOT= " might be a bit strong in the description, but I suppose most implementati= ons would reject it if you config it less than the prefix length. 1. Router(config)# ip prefix-list MYLIST 10.1.1.0/24 le 30 Router(config)# ip prefix-list MYLIST 10.1.1.0/24 ge 26 le 30 [Jon]: This is fine - I retract the comment (not sure what I was thinking n= ow!). p29: description "Policy statements group conditions and actions within a policy definition. They are evaluated in the order specified (see the description of policy evaluation at the top of this module."; Missing close-parenthesis in this description. [Yingzhen]: thank you for catching this. I've noted it down, will fix it in= the next version. Best regards Jon --_000_AM7PR83MB0449A29CF92619F0BE68A342A3E19AM7PR83MB0449EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yingzh= en

&nbs= p;

Sorry for= the delay in replying. I’d like to discuss a couple of points –= ; please see [Jon] below…

&nbs= p;

Cheers

Jon<= /o:p>

&nbs= p;

&nbs= p;

From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Sent: 29 June 2021 21:54
To: Jon Hardwick <jonhardwick@microsoft.com>
Cc: rtg-ads@ietf.org; draft-ietf-rtgwg-policy-model.all@ietf.org; rt= gdir@ietf.org; rtgwg@ietf.org
Subject: [EXTERNAL] Re: Rtgdir Last Call review of draft-ietf-rtgwg-= policy-model

 

Hi Jon,

 

Thanks for the review. Please see my answers inline.=

 

Thanks,

Yingzhen



On Jun 26, 2021, at 3:32 AM, Jon Hardwick <jonhardwick@microsoft.com> wr= ote:

 

I have been selected as the Routing Directorate re= viewer for this draft. The Routing Directorate seeks to review all routing = or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please seehttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir.

 

Although these comments are primarily for the use = of the Routing ADs, it would be helpful if you could consider them along wi= th any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the = draft.

 

Document: draft-ietf-rtgwg-policy-model-29

Reviewer: Jon Hardwick

Review Date: Jun 26th, 2021

Intended Status: Standards Track=

 

Summary:

This document provides a foundational framework fo= r the definition of routing protocol policies regarding the filtering in / = out of routes when they are imported / exported between routing protocol neighbors and/or routing protocols and the RIB. I= ts purpose is to provide a framework which can be augmented by routing prot= ocols in their policy YANG modules. I think that the document meets its goa= l very well.

 

The document is in good shape. It's clear, well-de= fined in its scope and easy to read. I have a few minor concerns that I wou= ld like to see addressed before publication.

 

Minor Comments:

 

Section 4.2

Why no match-set-options for neighbor-set?  I= s there no application for differentiating between "any of these neigh= bors" and "none of these neighbors"?

 

You can only match on a single interface. Why is t= hat? Was there no use case for any ANY / INVERT match on a set of interface= s? I am thinking of multihoming use cases.

 

[Yingzhen]: Typically you can apply a route-policy o= r route-map to an interface or a neighbor, plus you can configure multiple = route policies. I didn’t get your multihoming example, would you plea= se elaborate? And why the current module doesn’t work?

[Jon]: I Am Not An Operator so I don’t have a = real use case, but this is more of a question / thought experiment about ho= w it will be used. It could be that I’ve misunderstood how this would= be done in your model so please explain if I’ve got this wrong.  Say I am configuring an L3VPN for a customer who wil= l be multi-homed into my router over two interfaces (or more) and that I wa= nt to apply the same policy to all those interfaces. In a “traditiona= l” CLI I might create a route map and then configure a reference to that route map on each interface. In this YANG mo= del it looks like I must configure two identical policy statements, one mat= ching on interface A and the other matching on interface B, because I have = no ability to configure “match on either interface A or interface B”. The difference with the route ma= p seems to be that I’ve had to configure the same policy statement tw= ice.

Perhaps this example might be solved by matching on = a neighbor-set or on a VRF instead. I was just surprised not to see an equi= valent interface-set.

"Comparison conditions may similarly use opti= ons…" - what do you mean by a "comparison condition"? = The term is not used elsewhere in the document.

 

[Yingzhen]: This is not really a term. It simply mea= nt how to compare or the conditions to compare. I’d suggest we leave = this to RFC editor.

[Jon] It’s just that it sounds like it means s= omething specific. The text says “Match conditions may be further mod= ified…  Comparison conditions may further use…” and = this makes me wonder what the difference is between a match condition and a comparison condition. If I had to take a guess, it sounds like ̶= 0;match condition” refers to comparing against a set of values wherea= s “comparison condition” refers to comparing against a single s= calar value. The basic conditions defined in this base model appear to only use set comparisons, but you are saying that other models c= an augment this with single scalar value comparisons, in which case those m= odels can also define “less than, greater than” etc. options to= control the match, although those types of option are not defined here in the base model. Is that right? In which cas= e, I wonder if it is even worth saying / explaining, or perhaps removing th= is sentence and leaving it to the augmenting models to define what they wan= t?

[Jon]: Actually I have spotted another comment I wan= t to make. In “grouping neighbor-set-condition” the description= says “Match a referenced neighbor set according to the logic defined= in the match-set-options-leaf” but there is no such leaf in this grouping. Should there be, or is the description wrong?<= /o:p>

 

[Jon]: One more nit – the description for R= 20;grouping tag-set-condition” refers to the “match-options-set= leaf” – it should be “match-set-options leaf”.

 

Section 5

"If the conditions are not satisfied, then ev= aluation proceeds to the
   next policy statement"

 

I think that evaluation also proceeds to the next = policy statement if the conditions were satisfied, but the actions did not = include either accept-route or reject-route. Is that correct? I think it would be worth making that explicit.

 

[Yingzhen]: This is included in the first paragraph = of section 5. Please let us know if you think it’s not clear.

[Jon] Yes, on re-reading it, I think it’s fine= as written.

 

Section 7.2

p21:

   = ;   description
        "Mask length range lower bo= und. It MUST NOT be less than
         the prefix length defined = in ip-prefix.";

 

Why must it not be?  And is there a situation= in which it makes sense to allow it to be greater than the prefix length d= efined in ip-prefix?  Should there be a "must" clause to police this constraint?

 

[Yingzhen]: Here are a couple of prefix-list config = examples. The “MUST NOT” might be a bit strong in the descripti= on, but I suppose most implementations would reject it if you config it les= s than the prefix length.

  1. Rou= ter(config)# ip prefix-list MYLIST 10.1.1.0/24 le 30 

    2. Rou= ter(config)# ip prefix-list MYLIST 10.1.1.0/24 ge 26 le 30 <= /p>

 

[Jon]: This is fine – I retract the comment (n= ot sure what I was thinking now!).



p29:

   = ;         description
            &nb= sp; "Policy statements group conditions and actions
            &nb= sp;  within a policy definition.  They are evaluated in
            &nb= sp;  the order specified (see the description of policy
            &nb= sp;  evaluation at the top of this module.";<= /span>

 

Missing close-parenthesis in this description.


[Yingzhen]: thank you for catching this. I’ve noted it down, will fix= it in the next version.

 

Best regards

Jon

 

--_000_AM7PR83MB0449A29CF92619F0BE68A342A3E19AM7PR83MB0449EURP_-- From nobody Tue Jul 20 10:31:24 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00743A2BC3; Tue, 20 Jul 2021 10:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c--76cy3eBNA; Tue, 20 Jul 2021 10:31:17 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA7C3A2BC9; Tue, 20 Jul 2021 10:31:16 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id p186so24848996iod.13; Tue, 20 Jul 2021 10:31:16 -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=PZgRZfWRP0FC8a8R0g28lNfQJfDRlVtPP443y4qy330=; b=c7USF2W+yLiXaW+UQeFF5MM+TyDzo9Mcq3ioV1EsnVy3rF7XRtJnDkpm2nIGS52u/m xClG5kxJw4waHYVvYoa3QSiv+lJoCu6p+wIcpAz5UODixT5EfWCvDeuZH6YTLSXzH9vv lAkCXhXmsoSD+S8XmwFXpNTdWD9PpRfAaU9aIUyCAAaz8lAH0j4adSr810jBgHF8lrJh syieyj3kBym9yUMEu0mpTKAeYCmOoi8ltH1kF6mBpMRfqLc3EqFeuJEebem83Tw22a3C 98+j4QJigtxZdjdhEdB8ZmT6HBon6LfwC+mJ32quWOTkhwbug2XIHun9SAht3e/3ildH wSKg== 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=PZgRZfWRP0FC8a8R0g28lNfQJfDRlVtPP443y4qy330=; b=GJzpWeQGDvSJwsnRAL4MxNc85POOBCHVooC7Vp2pyVTMQFkS3K8wcJErWzYrsYYEW1 +bMWo2GjlaTucGjRJQdO3O91bZic1fzcPaop/Ogq3EWDuC6fnd/3Lfa5BlIoMKDndmM0 Psr5q0CfWxGi3raBBnSIhuEFzKjJD7An1YxjYyqWgFl1JqVGC4j5PoF8KU7UxQOljIv8 QIl9TNJdBphV+DmLb034+KqernHtWJyInxbsMd/Va4XBCH5Kn8Y6S1/roK8q4zsJ6Y1o skSboLh8WKUwt4IHyPBA4YT6eeoc/ZnKR/Oo91pL6Pa69sCjpmUWFxJKgr9IGYIZaXUA ujZQ== X-Gm-Message-State: AOAM532sMf4Cv690RrdpjvzQB7J+PrrTJ7UKG/fSD6yqj9bW66sbQA7W aVhp4VnquNIeOQYTkUwW6MskHWk3HZpGJamXKOUmYaV0+dU= X-Google-Smtp-Source: ABdhPJx2Jbynf2XkOiYBN7UVkmcY5oLkY1RelPRiy3hZ+Czj+MugHiT01NxJDUd/TE0Z4tI4mWlJTIsyLSRcLYy+B2Y= X-Received: by 2002:a05:6638:3a1:: with SMTP id z1mr26751143jap.77.1626802274400; Tue, 20 Jul 2021 10:31:14 -0700 (PDT) MIME-Version: 1.0 From: "Andrew G. Malis" Date: Tue, 20 Jul 2021 13:30:58 -0400 Message-ID: To: "" Cc: Routing Directorate , draft-ietf-opsawg-l3sm-l3nm.all@ietf.org, opsawg@ietf.org Content-Type: multipart/alternative; boundary="000000000000af7f1605c7916b6d" Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-opsawg-l3sm-l3nm-10 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 17:31:20 -0000 --000000000000af7f1605c7916b6d Content-Type: text/plain; charset="UTF-8" Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsawg-l3sm-l3nm-10 Reviewer: Andy Malis Review Date: 2021-07-20 IETF LC End Date: 2021-08-06 Intended Status: Proposed Standard Summary: No issues found. This document is ready for publication. Comments: This draft has been through 11 revisions and has been twice reviewed by the Yang Doctors. All of its normative references save one have already been published, and the one draft normative reference is also in IETF Last Call. In addition, the very useful Appendix B shows that there are at least four publicly-announced implementations in various stages of progress. This all indicates the maturity of this draft as it enters IETF Last Call. I found the commentary and model overview easy to read, and if I were writing an implementation, I would certainly appreciate the provisioning examples in Appendix A. I also appreciated the comparison to RFC 8299. Although I'm not a SECDIR reviewer, I found the Security Considerations section to be substantive. To conclude, I consider this draft ready for publication. Regards, Andy --000000000000af7f1605c7916b6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I have been selected as the Routing Director= ate reviewer for this draft. The Routing Directorate seeks to review all ro= uting or routing-related drafts as they pass through IETF last call and IES= G review, and sometimes on special request. The purpose of the review is to= provide assistance to the Routing ADs. For more information about the Rout= ing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<= br>
Although these comments are primarily for the use of the Routing ADs= , it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through dis= cussion or by updating the draft.

Document: draft-ietf-opsawg-l3sm-l= 3nm-10
Reviewer: Andy Malis
Review Date: 2021-07-20
IETF LC End = Date: 2021-08-06
Intended Status: Proposed Standard

Summary:
=
No issues found. This document is ready for publication.

Comment= s:

This draft has been through 11 revisions and has been twice revie= wed by the Yang Doctors. All of its normative references save one have alre= ady been published, and the one draft normative reference is also in IETF L= ast Call. In addition, the very useful Appendix B shows that there are at l= east four publicly-announced implementations in various stages of progress.= This all indicates the maturity of this draft as it enters IETF Last Call.=

I found the commentary and model overview easy to read, and if I we= re writing an implementation, I would certainly appreciate the provisioning= examples in Appendix A.

I also appreciated the comparison to RFC 82= 99.

Although I'm not a SECDIR reviewer, I found the Security Con= siderations section to be substantive.

To conclude, I consider this = draft ready for publication.

Regards,
Andy

--000000000000af7f1605c7916b6d-- From nobody Thu Jul 22 11:39:00 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8115F3A0D49; Thu, 22 Jul 2021 11:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 6eu9WRXBG1bh; Thu, 22 Jul 2021 11:38:57 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53563A0D4A; Thu, 22 Jul 2021 11:38:56 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id r18so7513033iot.4; Thu, 22 Jul 2021 11:38:56 -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; bh=uwLoxnndTNcV1sMYXqM5Ws/7DKzBYkBD2HP+H7W2pN4=; b=eZ0/Rg+L5HbUjcdofbWzvwC+EXIckkFYnUu5JyxfCacc3xql7otFLyjsh/C0X4XWgS rygSQkUZXSaqq3aRcssU+SbpOsCWXjdYs0cWJdTl9LExQ3y8bqRVeDMBjrPoEsE6mQTd OH4q6+9LMLGmVwprLdEZ8HYQqp8ypdQibj7ZXJNRncHqVFLZMNUhj6UFAAc7OzG81Obe 6NRhEG5hA9fsGCU4aeWQhrM1ghTctErTU3dKoV95TIZQ/Ww+4I5h70vH6V8pARUib7a0 VPVkQXYJLS+6rcI+8Qbj88JulU1bi6L9uJxkB8b7+SPIo5Z9332yHnvFH6t3W4OfbKlJ gonw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uwLoxnndTNcV1sMYXqM5Ws/7DKzBYkBD2HP+H7W2pN4=; b=DtjgRmJwm7bVxbr+dGDtrNSGlfESYcUc1pW/KVXN79nUcgJEwP0r1DOUKReK7gKvDh i0tW8wHycfEtoMF9n45+sQkderSp3PmXPcuoxF8eoISL0TUWsLrTZPEBSRI98imItAOH CXlXw0/Q9QAtmHkJveH91QbaflZQpBlThg+ZMS3OXHR80qsX3Sg12XCYJ0TNB7YoTzeA eUCVJlsk2zTbKk6vqPSmcinXACf2Iy8zDDNwIZV26AkYkaoggfMEAs/t/roYBoRioPCH BFTcZJjbpxtkfFZPGEl1jfbzkht3jLWYf30lmOn+us0p/e41e8sLPMUDGK1esiixRTQP ojiA== X-Gm-Message-State: AOAM533/vM1IaRSir2ulnXJs3WmVoR9nH9ZoWogYgmvNXzGYamUnIlGN pbbfIbGOrySy3po70NYcKDzRzELXfRpcHtOFaT98mtu6 X-Google-Smtp-Source: ABdhPJxQL21qrz+riDiSChnC+JcfuItck1433YTTMcCCe3Pb5ts3Lor/ZB3uxkvonLEXrC0ZgXDJkUjF9N3MYMI46qE= X-Received: by 2002:a5e:a818:: with SMTP id c24mr803113ioa.180.1626979135317; Thu, 22 Jul 2021 11:38:55 -0700 (PDT) MIME-Version: 1.0 From: "Andrew G. Malis" Date: Thu, 22 Jul 2021 14:38:38 -0400 Message-ID: To: "" , Routing Directorate Content-Type: multipart/alternative; boundary="0000000000006ae9f605c7ba99bc" Archived-At: Subject: [RTG-DIR] Adding Last Call list to the directorate template X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 18:38:59 -0000 --0000000000006ae9f605c7ba99bc Content-Type: text/plain; charset="UTF-8" I recently did a RTGDIR Last Call review, and I was just reminded by seeing a SECDIR last call review pop up on the Last Call list that we should include the Last Call list on our review template as well. I know that it's a wiki, and I COULD update it myself, but I don't think I have the creds ... :-) Cheers, Andy --0000000000006ae9f605c7ba99bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I recently did a RTGDIR Last Call review, and I was just r= eminded by seeing a SECDIR last call review pop up on the Last Call list th= at we should include the Last Call list on our review template as well.
I know that it's a wiki, and I COULD update it myself, = but I don't think I have the creds ... :-)

Che= ers,
Andy

--0000000000006ae9f605c7ba99bc-- From nobody Thu Jul 22 11:45:04 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027E73A0D85; Thu, 22 Jul 2021 11:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.895 X-Spam-Level: X-Spam-Status: No, score=-11.895 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iA3wyEkC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AN+TLAx5 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 BE6MKkCqux2F; Thu, 22 Jul 2021 11:44:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CDF3A0D7F; Thu, 22 Jul 2021 11:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6917; q=dns/txt; s=iport; t=1626979497; x=1628189097; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=8FEAOW4gq49DgzmFdFnYvFE6mOJfVOKNktwcc/fAdSQ=; b=iA3wyEkClqyOHdsYd9Vi91alTI1glGnUgVFv3hcO+ZFnTRvohiq+weaI Qrk9OiFeMzTrZ2bqqKApjJEie3Ixi2YN2/9wxhyeLYZYN94QxhBWQ0CFs GqeGFIne0GYe2oDswGXpESGWRcCbGHkJQbjMn0aJnNt/rQyoqS87/5kmS g=; X-IPAS-Result: =?us-ascii?q?A0BYAwDfu/lgl4QNJK1ahAUwIy5+WjcxAoRGg0gDhTmIY?= =?us-ascii?q?gOKV4pZhQCCUwNUCwEBAQ0BATcKBAEBhFcCF4JgAiU4EwIEAQEBAQMCAwEBA?= =?us-ascii?q?QEFAQEFAQEBAgEGBBQBAQEBAQEBAXKFaA2GRQEBAQQSER0BATgPAgEIEQMBA?= =?us-ascii?q?isCAgIfER0IAgQBEiKCTwGBflcDLwEOnRQBgToCih96gTKBAYIHAQEGBASBS?= =?us-ascii?q?kGDHA0LgjQDBoE6gnyEDAEBhmInHIINgTwcgjIwPoFYSEICA4F9DYJqNoIuh?= =?us-ascii?q?AZTe4EYAhcRK5UBiDqeODtcCoMmijaOJ4VhBSaDY6MAlgmCHIoXgzSQP4RnA?= =?us-ascii?q?gQCBAUCDgEBBoF3IoFbcBU7KgGCPlAZDo4rDQmDT4UUhUpzDSsCBgsBAQMJi?= =?us-ascii?q?2IBAQ?= IronPort-PHdr: A9a23:nePSWRUF8lIKaF5F1P+GTWau4+bV8K3gAWYlg6HPw5pBd62i+9LpO 0mMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAFnpnwcUblgAtGoiJXEv8KvO5YCkzH cAEX1hgrDm3NEFPE5P4YFvf6nS58T8VHED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaE Q== IronPort-HdrOrdr: A9a23:uIADpKOztm5jq8BcT9H255DYdb4zR+YMi2TDiHoedfUFSKOlfp 6V8MjzjSWE9Qr4WBkb6LW90dq7MA/hHP9OkMcs1NiZLXDbUQeTXeJfBM7Zskfd8k7Fh69gPM VbAtBD4bTLZDAQ56uagDVQUexQu+VvmJrY3ts2pE0dKT2CHpsQiTuRfTzrdXGeKjM2Z6bQyP Knl516T2XKQwVMUu2LQl0+G8TTrdzCk5zrJTQcAQQ81QWIhTS0rJbnDhmxxH4lInNy6IZn1V KAvx3y562lvf3+4ATbzXXv45Nfn8ak4sdfBfaLltMeJlzX+0WVjcVaKv+/VQIO0aWSAWUR4Z 7xStAbToJOAkbqDySISN3WqlDdOXgVmiffIBSj8ATeSITCNUwH4mB69N9km13imhYdleA57Y hwm1iUsJdaFnr77XDADxKhbWA0qqJ2yUBSz9L69RZkINsjgOQ6l/1NwKuReK1wTR4TLOgcYb tT5Aa13ocCTbrSVQGogoFirebcL0gbD1OIRFMPtdeS1CUTlHdlz1EAzMhahXsY8okhIqM0qt gsH54Y342mdPVmJ56Vxd1xNvefGyjIW1bBIWiSKVPoGOUOPG/MsYf+5PEw6PuxcJIFwZMukN CZOWko+lIaagbrE4mDzZdL+hfCTCG0Wins0NhX49x8tqfnTLTmPCWfQBQlktemof8YHsrHMs zDdK5+ErvmNy/jCIxJ1wrxV91bLmQfStQcvpIhV1eHsqvwW8XXXyzgAb/uzZ/WYEIZs0/Ecw k+tQnIVbN9BxqQKwzFaTDqKgbQRnA= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,261,1620691200"; d="scan'208,217";a="727669832" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2021 18:44:55 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 16MIitw7025072 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 22 Jul 2021 18:44:55 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 22 Jul 2021 13:44:55 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 22 Jul 2021 14:44:55 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 22 Jul 2021 13:44:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ej0MkzkvJ+tStSt73BLv6Av2z17dYD4SJezDbSF5ct9ngBFx1m7Ythi0EubrwrXwa+x9YCK20tQpQV+QR60jBd0SW1JJWFX2mLPrl1oY4uLVz3Gz8yCAMcvq6Zdoip1mfdsfbT2kVk7B7uqA5VF/cciOSS1CA6Aa5gGv2Jtmg8WJQH9QuL7ypjwyd2dVMLA5h6AZ2kMry4GfdGe8qXFq9Yjzi8eN7Qi5FwM3XY2Awj6Hjz6nr2oQrp+56AC7eDaiK8sh2nnEINyiFnjfHa78RhnlV1gb/N1jTnNUrVr5MnAGCfenAkXk8k/N4zbySVpY02XLtBNDoQSzRw5YyBsjUg== 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=8FEAOW4gq49DgzmFdFnYvFE6mOJfVOKNktwcc/fAdSQ=; b=D61aadlz+ORBQ3DQUvBuaoxPVgy5SrNz4xHhrrHz1JQ/v+f+b2BShMreMBl1bJArUaQgaNSLsDQhEy36wFv/Xut092DnHUA3ki8KKTY9P0yIqq1W2V/jHMLGkasURxbdKwtQ+ar9TNKjksHf0nYBx9FB9SBMx7qnmn0XkWioK2kmO9Al11GIeCt5UdbCa0sxP5FRtw671K3dwGWyy3OamYslL8nxobKZJSIyara4yKWlEPnc7DQF4byqO28DsJmjMsa1r1EPVlOXvPGxpQx90XP6djJ0OT6UGbtwDRhbFfyKAsDdjGFvjYS2duo2TDHkaKpUTfb/0SWdnXo1k337Sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8FEAOW4gq49DgzmFdFnYvFE6mOJfVOKNktwcc/fAdSQ=; b=AN+TLAx5yUOvjtejmz5QSvH8yJO5YIflpJPadNCmwDP8vXzvtlHclxNkP3bRt2za2EnERJSq63ALmXbITDZ9f/TOA3vH1nVwKJkbToc3sDhdexxaAlFBImCVXiqO7Is0nepchqE0jcPvgC7iT0yrbEAwXsuMG+4ULX62ExYaWOU= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3512.namprd11.prod.outlook.com (2603:10b6:a03:8f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.26; Thu, 22 Jul 2021 18:44:53 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::dc2e:765f:512c:b39e]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::dc2e:765f:512c:b39e%7]) with mapi id 15.20.4331.034; Thu, 22 Jul 2021 18:44:53 +0000 From: "Acee Lindem (acee)" To: "Andrew G. Malis" , "" , Routing Directorate Thread-Topic: [RTG-DIR] Adding Last Call list to the directorate template Thread-Index: AQHXfyjg8BQ8XIYqQEe0Mz2yJ4yJpKtPEe6A Date: Thu, 22 Jul 2021 18:44:53 +0000 Message-ID: <50EA06C0-BA21-4CBF-A061-CF70362EE66E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c8ea231-69e9-4383-18f8-08d94d40cba0 x-ms-traffictypediagnostic: BYAPR11MB3512: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0iOD5Ko0rzUGR4F2G1lTliYEU6VayH06e+YxqNx0gqinuzfC7YBllhkhzsUzgSO3GSaC2JZ/jNZOtfY8U/0R5vbEl2KEhztJj7aRoEorSrd4VVvkh2Msb/Kt1UoYXkIq8oXUgEoMFzXkzMFzzVgphW7ddQdhKu0k28fWGcQZgKd7qf0/wQf7HKmDVmrVkffbszP5qd4wP6WVK5un7Ab3l5Mdksu8kMTaQX9JuA+e+5V7sfF/F/U3HmT7VySWU0fRJ5cm/fQw81sHu7k1T9ItV1azdua/bCX7DED+8JFrTT+jQ+JskJXe4kPSqmn2XO+kfffDxSXMgUVngdBBZkTDvF3TpDeQ5OV1szCXEkHf/rov3qJvqudAu3mebak5cnv+6PN9XgOcJfUiabWrTTrS6lzkKeLyCbUdeVmz4fJuVo+YEjRXAYYXsZA+xxj4gUR1Gf0iJ9HYAOjxKqdbuARsfpC4ClLe5ukWMc0lDXLuhJBAnvoaPo7MyQ9xQv25ruaU+jNyE7fZBSOw7tswTsljh67VFtu+0o6YLx0kVabnrbbcAaO9edEfhXZJpwZu8ZWQ7O3zKxw7kGk3JAvYPYuXwboCNx+Wy4gd1OWGf3Vm41RZikQ3YtREfn1BqZh3T0WwiSBR4a8DMRrKTptzfkC9KjCzAdpm46t65gkKmwCL5HgrukYWL2XenGtSSbXFwTMxGrRdiJYrfPZuIkYlBqlgAZd5RbSCiuf6h6NJoXBYk0p33/PBHKaY7sAEFwxbOA4rmBTWl+/qiAeeZBly/L3VhkzVQ3o74yNNvCpsIIfsfWDsETOx+wlnLOORz4CEHNA+JVye8iIZ/8HYTljfUyyJnQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39860400002)(396003)(376002)(346002)(36756003)(166002)(2616005)(6506007)(66556008)(6486002)(83380400001)(86362001)(966005)(122000001)(110136005)(6512007)(316002)(33656002)(9326002)(5660300002)(71200400001)(76116006)(38100700002)(26005)(66476007)(8676002)(2906002)(478600001)(64756008)(66946007)(8936002)(53546011)(66446008)(186003)(491001)(38070700004)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?T3Q5TnJIUSt2S0tLS2JZeTdqYkpYTlBkOGVmdzRzR3BpeUFKT1BZRWpXOFgv?= =?utf-8?B?VHBNNnNQV2daYjgzRVRpUko0dWNXRlZoNE1QQ0hlWmhvVXhCRnJxdlhyZXI4?= =?utf-8?B?ZUhNODdDUnZWTTVvcUlrY3FaMmhpeFJCWEJBalhKTTA2Wjcvc0lDaGY2WEg1?= =?utf-8?B?VThzeG9mWFQ4TVBZVmFDc0FGVUxKYzh6b09QV1AyZFN2ZVJNY2x5cFNQNFhp?= =?utf-8?B?Wk1vU2hYbUg3L1FxZTRSMXV3cUE5Z3o5d1pMRzNpdkhHazlkQWRyMUhCN01J?= =?utf-8?B?ODFhczR2MENudkxRdVhyWWN4VVpDcGZOM085QU5lbnRaOGcwekYvVE1aTmZK?= =?utf-8?B?M0Z1Q2tOTlQwUTN2QUt2ajZCOVFUa09vNytRQWE5aHRSZ0dsRmphZTdSdmhw?= =?utf-8?B?UTF3am5iMkdaT05DQitrcEI1YXVwZzgvVm1VMUZkTXZsVlh2dkhJSmIybnZB?= =?utf-8?B?TGlZZmlKdUlpMGd3T09KVkpBMk5qWXZRUWhGdTAxYm0zQ0dRa09BU0M0QVl2?= =?utf-8?B?Z1VZQWpXdXEzZmZtQjRRbVlGcHFWN3FKZTB3ajh5SGlzbTNIWG8rT29tZEZq?= =?utf-8?B?Q2dncnBUVVBQeGltK29MenBWMXE4RzFGa2pmS3RDVEpjRG56ZGY3dTc5K2Vo?= =?utf-8?B?czQ4VWttang5V095L3hBYVZYdE5TUjdvUHpnSU93dEttc3ZDVlpDdEgwTTh0?= =?utf-8?B?Zmcra2RReG5Qci93MjNOcHBFaCt1L3FyZWhySmR6d3BKVmk2ZVhaZVNqWHZG?= =?utf-8?B?L3RWdk5TRHRsbW1aL2h2Q1lhQld6NnkyNlRra292ZDlMbklERndRWks2TlBj?= =?utf-8?B?M3dnUDE0bXNsU1hwT1RSSk1RaVBYdnh0cHdkU3JsaFQ5Z05HQVdZTWpXSGVJ?= =?utf-8?B?dnVzVjl4Umh6R3ZYUVdjSzFpRGRMeWQyTWNxU1ArcDZTQWRmdXVEcGVmdkNs?= =?utf-8?B?U0Fjb2ZlRk04ZC9va014cFZkVEM0Wjc0dGtSQzdOckJrVGZRdGpuOEE0VVJU?= =?utf-8?B?cVJQQTVhWXhPYUtFbktKMVhpSTJ2U1hadU95TElkenRkVkxWUlYrMjJxSmFV?= =?utf-8?B?Y0xkK2J5bWlKSUloaHdPSVQ2Q0hiK24yZGNhVExuQ1FhQWdqaXl2eStHSnZK?= =?utf-8?B?UXFvMkx3V0x4NWEwb2taaEVmUUFpSWlkc3FFTUtBRlF3cGk0aWFITys3Z0dy?= =?utf-8?B?Kzh3ZEhLMDUwOCs5WjU3MWpIZVNYWWlLWjl2ZUlxTnM0dGRTb2hES1lpWFJo?= =?utf-8?B?Zm5BVUpVZFhwaEZmaUszWkZNMm5oUVJIOFRYckFvQUlZb0VwK21ocExaUi9F?= =?utf-8?B?aE9XRUZPMVhhYml0dmVaM1BQOEQ2SCtZSlBhTlArcWk4RHVzcXhYVUJiL0Fn?= =?utf-8?B?akFKbkVLc2FrOC9ZWGJ4amVxRFBxcmUwKzhXQ2ZXakVWWUV2T2xTcjRoZ0tX?= =?utf-8?B?c1FpeVlTbTcxMTZwRFBBeTJ5RFNLWlhxWGgweTNrTlpwUkU3MDUzTU83MThT?= =?utf-8?B?dGJlMTE3b3FkbWVYendkWDdyL0F6UkdhREJMVkdPY2hEZW1lcElmalkxVVRY?= =?utf-8?B?SGVHK2N4VnliVEw1OXFrdWlRK1N5QXhieXZEODlpMFhkaHdFMlpJSnhzaDQv?= =?utf-8?B?cTh5djhaQ2NzT2hFd09qek1wTnpIM0NEYVZLN0RaSVhEUFNnZ01JNkQvRTIx?= =?utf-8?B?eXlZRmZQZFpTSFpuSHIzZWxSUFFWRjVBVWNKOW5JckkxN2VqQUM0TWl3YWFU?= =?utf-8?B?T0RvdmVIeXJkclFQblhmMk52Qm1EaVpwWThBbXhDMHY5VE85VHRHSWkxK2Z5?= =?utf-8?B?RHBjYTBYVmRqUVhuaUF0QT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_50EA06C0BA214CBFA061CF70362EE66Eciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c8ea231-69e9-4383-18f8-08d94d40cba0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2021 18:44:53.8279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GavZl7cIfeEilLTDY7AMvVm4H9oZP38Dewz699cnBHNoHVv1vTCbjWzMzavCkfwh X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3512 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [RTG-DIR] Adding Last Call list to the directorate template X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 18:45:03 -0000 --_000_50EA06C0BA214CBFA061CF70362EE66Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KSSBvbmx5IHJlcXVlc3QgYSBTRUNESVIgcmV2aWV3IGZvciBkcmFmdHMgdGhh dCBoYXZlIG9idmlvdXMgc2VjdXJpdHkgaW1wbGljYXRpb25zLiBGb3IgZXhhbXBsZSwgSSByZWNl bnRseSBkaWQgaXQgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtbHNyLXBjZS1kaXNjb3Zlcnktc2VjdXJpdHktc3VwcG9ydC8NCg0KVGhlIHJlYXNvbiBpcyB0 aGF0IG9uZSBpcyBsaWtlbHkgdG8gZ2V0IG11bHRpcGxlIFNFQ0RJUiByZXZpZXdzIGZyb20gZGlm ZmVyZW50IHJldmlld2VycyB3aG8gYXJlIGxpa2VseSB0byBuaXRwaWNrIG9uIGRpZmZlcmVudCBw b2ludHMuIE5vdywgSSByZWFsaXplIHRoYXQgc29tZSBjaGFpcnMgd291bGQgdmlldyB0aGlzIGFz IHBvc2l0aXZlIGJ1dCBzb21lIG9mIHVzIHdvdWxkIG5vdC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpG cm9tOiBydGctZGlyIDxydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiQW5k cmV3IEcuIE1hbGlzIiA8YWdtYWxpc0BnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgSnVseSAy MiwgMjAyMSBhdCAyOjM5IFBNDQpUbzogUm91dGluZyBBRHMgPHJ0Zy1hZHNAaWV0Zi5vcmc+LCBS b3V0aW5nIERpcmVjdG9yYXRlIDxydGctZGlyQGlldGYub3JnPg0KU3ViamVjdDogW1JURy1ESVJd IEFkZGluZyBMYXN0IENhbGwgbGlzdCB0byB0aGUgZGlyZWN0b3JhdGUgdGVtcGxhdGUNCg0KSSBy ZWNlbnRseSBkaWQgYSBSVEdESVIgTGFzdCBDYWxsIHJldmlldywgYW5kIEkgd2FzIGp1c3QgcmVt aW5kZWQgYnkgc2VlaW5nIGEgU0VDRElSIGxhc3QgY2FsbCByZXZpZXcgcG9wIHVwIG9uIHRoZSBM YXN0IENhbGwgbGlzdCB0aGF0IHdlIHNob3VsZCBpbmNsdWRlIHRoZSBMYXN0IENhbGwgbGlzdCBv biBvdXIgcmV2aWV3IHRlbXBsYXRlIGFzIHdlbGwuDQoNCkkga25vdyB0aGF0IGl0J3MgYSB3aWtp LCBhbmQgSSBDT1VMRCB1cGRhdGUgaXQgbXlzZWxmLCBidXQgSSBkb24ndCB0aGluayBJIGhhdmUg dGhlIGNyZWRzIC4uLiA6LSkNCg0KQ2hlZXJzLA0KQW5keQ0KDQo= --_000_50EA06C0BA214CBFA061CF70362EE66Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbmR5LCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBvbmx5IHJlcXVlc3QgYSBTRUNESVIgcmV2aWV3IGZvciBkcmFmdHMgdGhhdCBoYXZlIG9i dmlvdXMgc2VjdXJpdHkgaW1wbGljYXRpb25zLiBGb3IgZXhhbXBsZSwgSSByZWNlbnRseSBkaWQg aXQgZm9yDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWxzci1wY2UtZGlzY292ZXJ5LXNlY3VyaXR5LXN1cHBvcnQvIj4NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbHNyLXBjZS1kaXNjb3Zlcnktc2VjdXJpdHkt c3VwcG9ydC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWFzb24gaXMgdGhhdCBv bmUgaXMgbGlrZWx5IHRvIGdldCBtdWx0aXBsZSBTRUNESVIgcmV2aWV3cyBmcm9tIGRpZmZlcmVu dCByZXZpZXdlcnMgd2hvIGFyZSBsaWtlbHkgdG8gbml0cGljayBvbiBkaWZmZXJlbnQgcG9pbnRz LiBOb3csIEkgcmVhbGl6ZSB0aGF0IHNvbWUgY2hhaXJzIHdvdWxkIHZpZXcgdGhpcyBhcyBwb3Np dGl2ZSBidXQgc29tZSBvZiB1cyB3b3VsZCBub3QuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY2VlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPnJ0Zy1kaXIgJmx0O3J0Zy1kaXItYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVo YWxmIG9mICZxdW90O0FuZHJldyBHLiBNYWxpcyZxdW90OyAmbHQ7YWdtYWxpc0BnbWFpbC5jb20m Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBKdWx5IDIyLCAyMDIxIGF0IDI6MzkgUE08 YnI+DQo8Yj5UbzogPC9iPlJvdXRpbmcgQURzICZsdDtydGctYWRzQGlldGYub3JnJmd0OywgUm91 dGluZyBEaXJlY3RvcmF0ZSAmbHQ7cnRnLWRpckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+W1JURy1ESVJdIEFkZGluZyBMYXN0IENhbGwgbGlzdCB0byB0aGUgZGlyZWN0b3JhdGUg dGVtcGxhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+SSByZWNlbnRseSBkaWQgYSBSVEdESVIgTGFzdCBDYWxsIHJldmlldywgYW5kIEkgd2Fz IGp1c3QgcmVtaW5kZWQgYnkgc2VlaW5nIGEgU0VDRElSIGxhc3QgY2FsbCByZXZpZXcgcG9wIHVw IG9uIHRoZSBMYXN0IENhbGwgbGlzdCB0aGF0IHdlIHNob3VsZCBpbmNsdWRlIHRoZSBMYXN0IENh bGwgbGlzdCBvbiBvdXIgcmV2aWV3IHRlbXBsYXRlIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkkga25vdyB0aGF0IGl0J3MgYSB3aWtpLCBhbmQgSSBDT1VM RCB1cGRhdGUgaXQgbXlzZWxmLCBidXQgSSBkb24ndCB0aGluayBJIGhhdmUgdGhlIGNyZWRzIC4u LiA6LSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5DaGVl cnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_50EA06C0BA214CBFA061CF70362EE66Eciscocom_-- From nobody Thu Jul 22 14:31:35 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1C3A0C2B; Thu, 22 Jul 2021 14:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqOjhKUgYfFp; Thu, 22 Jul 2021 14:31:26 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 360623A0C28; Thu, 22 Jul 2021 14:31:21 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id hq13so664274ejc.7; Thu, 22 Jul 2021 14:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ErA6wh7ZlrseY0IqQVM7XpXb2O7UeZOhVq2wioF4soc=; b=IJbnyhXeCGS0skZnsgxq4w4+C9NL21QY5KZhZGTwMlHkHNKkUKFx4qy1Id7uey0z/f FGJh1QTfK+N0gLgJYefE+/O+HbBQNqxZ/Q+wQ/X/3Ey/OVr0n5RZn5968bKQW4ji1rEE kz1F8bPVgTYt3+So3L55HD34+UFRkNh2g+fJ66M/I0OwEoLzc0iXd53zpRlCvRiGNN96 q49tuGNX5kjaaehcuwPQYsDb4ORLXp0ZvZ3VZQtQFz/PGDOiOLtzS3FeDMAriAmYywRj mpwfD2wKTwa/jMa5kCT9C2AQGf91z2z90Cmk0acvQyaNbMd2QJ2a8MF95HytQkIKu0pa VVtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ErA6wh7ZlrseY0IqQVM7XpXb2O7UeZOhVq2wioF4soc=; b=IcgKRKFVV205/6tCxTCgc8dBY0LBgqv4B0BGkcS6sO2NGn6wlPuFuOmPdiPpXrDCuY tISrcTCxGFWfiznH6FBGNwv9OUbDdcOuzx6pIKE/jX17/qOpzdj/8KSi2WyHvv9hdyDW tjYBrHFxHpK3c/KUPXBoX/AL7XVeCvTxQ0CUdhljkk21pRqSuvS32d7NBNJ6bCvDo4Mj YEYij64HWUrxWOs0tZxHKe9y3IBh4shwQGKkbZJURCXlgO7/N5r3T6J1nzYPcQOdlipc XRgQnrb0DukdGflG0lIrFl4k22trNRTE3pmUkiaioJq91B/AJ4d5gkBI5WJp1Epbp21A Ilxw== X-Gm-Message-State: AOAM532A2mxGa0MKIsWfp8CsHyeK9lkIWq0ODY2kEnQITD+CYSLNxZP5 pQdZw8Mxni0Vu41vDhhNjDK0pwmnauzlwzDu510= X-Google-Smtp-Source: ABdhPJyv09Hh5z+Mz/rDdU3naTSNxearj0VBYzgB283SoHsyf0Wj1EvAcAVv7Udz2i9td4olPmq2QMt8Gn5R647gaQ8= X-Received: by 2002:a17:906:c29a:: with SMTP id r26mr1745724ejz.235.1626989474584; Thu, 22 Jul 2021 14:31:14 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 22 Jul 2021 14:31:13 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 22 Jul 2021 14:31:13 -0700 Message-ID: To: "Andrew G. Malis" Cc: Routing Directorate , "" Content-Type: multipart/alternative; boundary="000000000000af9d2a05c7bd0129" Archived-At: Subject: Re: [RTG-DIR] Adding Last Call list to the directorate template X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 21:31:33 -0000 --000000000000af9d2a05c7bd0129 Content-Type: text/plain; charset="UTF-8" Andy: Hi! Yes, you are correct: LC reviews should be also sent to the last-call list. I updated the wiki. Thanks! Alvaro. On July 22, 2021 at 2:38:59 PM, Andrew G. Malis (agmalis@gmail.com) wrote: I recently did a RTGDIR Last Call review, and I was just reminded by seeing a SECDIR last call review pop up on the Last Call list that we should include the Last Call list on our review template as well. I know that it's a wiki, and I COULD update it myself, but I don't think I have the creds ... :-) Cheers, Andy --000000000000af9d2a05c7bd0129 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Andy= :

=
Hi!

Yes, you are correct: LC reviews= should be also sent to the last-call list.

I updated the wiki.

Thanks!

Alvaro.

On July 22, 2021 a= t 2:38:59 PM, Andrew G. Malis (agmalis= @gmail.com) wrote:

I recently did a RTGDIR Last Call = review, and I was just reminded by seeing a SECDIR last call review pop up = on the Last Call list that we should include the Last Call list on our revi= ew template as well.

I know that it's a wiki, and I = COULD update it myself, but I don't think I have the creds ... :-)

Cheers,
Andy

--000000000000af9d2a05c7bd0129-- From nobody Thu Jul 22 14:44:46 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DCB3A0CA5; Thu, 22 Jul 2021 14:44:45 -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 rCTPl_QCktP2; Thu, 22 Jul 2021 14:44:40 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6DB3A0CA2; Thu, 22 Jul 2021 14:44:30 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id s5so6756362ild.5; Thu, 22 Jul 2021 14:44: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=CHb4jR5GIRuzPTumH6DFeFZ58G7AOIoWH0A1sWHHk/4=; b=KjI2Owpkr7DRbBY+o4FfKXcVwB9Fp1u14HUANIH5j6Ri5eHXNMaedtAJiJdIfKXbnN Blc2NmYnwjjvArUi1eQFdINQHKm2ieXSjrXRP9OOUJVunaAlGhtUT0cgSTCqRO6E/5AU gYeacjDr+nAlGRMuz2RasisChLt6pM80b8jfousVhnbbdEWWoKyimMtH5WxO5GHEirwd Gffhfg9SdgNcsU+kI8/7jMng0D/1b+xOS5afwgJ/B5WeqjwL2gH+BjeVNSHYZP6x421l qKnlzrDpC8WMoRawQZvw5GRYJgJhZa07Ut2zdHBiCxN9UuOgZ1vlP2ZbGiEHOB2EkMCs Z8cw== 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=CHb4jR5GIRuzPTumH6DFeFZ58G7AOIoWH0A1sWHHk/4=; b=QhYxGk4UU89Ecx/L2KHST74JFeAHyqUaJzTrZ88q3O8LWUDa2BMjSUYDrKj6Sr8RGg 4X2d2vVB3EYF9ktUKbnjjl7Upl5B1/Kp2LHC7MxfMhdT+WgAjLG9SgM1ei60PIT0A11i Yaxapo2i6SuntbdVpvb3csezLrmIfVmdSkRhUVY62WHJeIXetIzOCmf2nlNFjmQb7f/c mSk3fZxo980l7YhE0/TnXSVV6HmrYx+qeH+h8Ia87Ei6VmIHZHiBztRjU9Ox1+Wglt6u AFqsjOilYSyUhBt5QkTngvXFdeMi6SuVHTjUAjXO3hjUokcZv7kvZjspEicsoae1iEzH HtQg== X-Gm-Message-State: AOAM531OhVAzqUscUY8YZFQF7yZou7V4u9/u1qcYOHMTyt+8JUOng6M2 831iKcdnU6MpiI6kazlv/8BMUiWBUJIkXywi1fw= X-Google-Smtp-Source: ABdhPJzheehHCwmrQPFOynm9rr7R6hZgsEjMqOkVTKemJlPXJkuDDN/ysgOVlfPHamkftrw4jz+HQmEqlJqdyK7n+HA= X-Received: by 2002:a92:d943:: with SMTP id l3mr1278201ilq.37.1626990269114; Thu, 22 Jul 2021 14:44:29 -0700 (PDT) MIME-Version: 1.0 References: <50EA06C0-BA21-4CBF-A061-CF70362EE66E@cisco.com> In-Reply-To: <50EA06C0-BA21-4CBF-A061-CF70362EE66E@cisco.com> From: "Andrew G. Malis" Date: Thu, 22 Jul 2021 17:44:12 -0400 Message-ID: To: "Acee Lindem (acee)" Cc: "" , Routing Directorate Content-Type: multipart/alternative; boundary="0000000000000b329e05c7bd31b1" Archived-At: Subject: Re: [RTG-DIR] Adding Last Call list to the directorate template X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 21:44:45 -0000 --0000000000000b329e05c7bd31b1 Content-Type: text/plain; charset="UTF-8" Acee, I think you misunderstood my email, but Alvaro got it! :-) (see his reply) Cheers, Andy On Thu, Jul 22, 2021 at 2:44 PM Acee Lindem (acee) wrote: > Hi Andy, > > > > I only request a SECDIR review for drafts that have obvious security > implications. For example, I recently did it for > https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ > > > > The reason is that one is likely to get multiple SECDIR reviews from > different reviewers who are likely to nitpick on different points. Now, I > realize that some chairs would view this as positive but some of us would > not. > > > > Thanks, > > Acee > > > > *From: *rtg-dir on behalf of "Andrew G. Malis" > > *Date: *Thursday, July 22, 2021 at 2:39 PM > *To: *Routing ADs , Routing Directorate < > rtg-dir@ietf.org> > *Subject: *[RTG-DIR] Adding Last Call list to the directorate template > > > > I recently did a RTGDIR Last Call review, and I was just reminded by > seeing a SECDIR last call review pop up on the Last Call list that we > should include the Last Call list on our review template as well. > > > > I know that it's a wiki, and I COULD update it myself, but I don't think I > have the creds ... :-) > > > > Cheers, > > Andy > > > --0000000000000b329e05c7bd31b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Acee,

I think you=C2=A0misunderstood my= email, but Alvaro got it! :-) (see his reply)

Che= ers,
Andy


On Thu, Jul 22, 2021 at 2:44 PM Ace= e Lindem (acee) <acee@cisco.com>= ; wrote:

Hi Andy,

=C2=A0

I only request a SECDIR review for drafts that have = obvious security implications. For example, I recently did it for https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-supp= ort/

=C2=A0

The reason is that one is likely to get multiple SEC= DIR reviews from different reviewers who are likely to nitpick on different= points. Now, I realize that some chairs would view this as positive but so= me of us would not. =C2=A0

=C2=A0

Thanks,

Acee

=C2=A0

From: rtg-dir <rtg-dir-bounces@ietf= .org> on behalf of "Andrew G. Malis" <agmalis@gmail.com>
Date: Thursday, July 22, 2021 at 2:39 PM
To: Routing ADs <rtg-ads@ietf.org>, Routing Directorate <rtg-dir@ietf.org>
Subject: [RTG-DIR] Adding Last Call list to the directorate template=

=C2=A0

I recently did a RTGDIR = Last Call review, and I was just reminded by seeing a SECDIR last call revi= ew pop up on the Last Call list that we should include the Last Call list o= n our review template as well.

=C2=A0

I know that it's a w= iki, and I COULD update it myself, but I don't think I have the creds .= .. :-)

=C2=A0

Cheers,

Andy

=C2=A0

--0000000000000b329e05c7bd31b1-- From nobody Thu Jul 29 22:48:54 2021 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2019A3A1CDD; Thu, 29 Jul 2021 22:48:52 -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 7uTVMB2K1gfo; Thu, 29 Jul 2021 22:48:47 -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 032213A1CDB; Thu, 29 Jul 2021 22:48:46 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id mz5-20020a17090b3785b0290176ecf64922so19180383pjb.3; Thu, 29 Jul 2021 22:48:46 -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=WroXq1689o5cbO7lI48IVxlQOMy9KW6ArY9TAvGDBp8=; b=AM1/D/bEj4BjiTHJ8gD9URZ025xtbLZVMsMwZUmH2OseT6v4p+1e3bQMTfwpl2HyJ1 WLrhKq4JjTtrnbc4lJAe64Ocj31wiizex1tkuCBovoe9+yeQteAbV592sDtSIGqcOFRQ owtiqtFGWff+v8Zqk0pgZfYlBDTpwRo2+qv9CSLJog36AvOTUfzjmxQfaNVOSrX20uGp j7Feb03cA1/NTXuFKbtFV/lygI1ipxpK1WoyMTl5x1roB+rT0PNTYLcMXRwzcwBzcvD0 cKMEYtQCezOsFhSeJ0AsSdOjk4hIhNS4iSin7CdgnVBZ2mCYlE0VSqb8EwRTThy7SEvg RXbQ== 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=WroXq1689o5cbO7lI48IVxlQOMy9KW6ArY9TAvGDBp8=; b=RiT2CSAhxShXw9U0f/3eG4YcTSd9rTM1lCyi2MwXC1aJ1ibpBX0mBGqTA2qQ0z3OO/ mWYua8xN5Kc+ZhuyXJORcdoTN15PVifgBvIEeUu0vvMvhU3DJv+TbFTzjqmyVrnAL7hY 0q1ttXqzsPX5vf/P2S3jz/l44+izbziQQ1jZ0ncmBr52iLczq9WTJ6omuvVk99rrVa1V YH67JPdD9o9lwVhH3TvNUfbftCLkKxNdxsM/k6chmEFbv8wWqPQDOKPEM2jfCy9KR8az bytFAh3/8RcDxDUbcJJqG0pDkVy6En30kZ+P4c9q4r1kjaniAfDFEW9K1yZ3f9ND8C0J 0eug== X-Gm-Message-State: AOAM532UZ/RSB3BU2n6wOs8I1uDyr4n24MDkgClQPDc90XNLx2GkucMD lxn59zcuK+ss90Z8ZyR+uw== X-Google-Smtp-Source: ABdhPJy7QrWUy6O6dhqp703Uo4GbFP0ACnEBrg7neEMbH52Fp/KqqeBoNWvuyleKBbqhtkSG+aYw8g== X-Received: by 2002:a17:902:ecca:b029:12c:3c9:3d96 with SMTP id a10-20020a170902eccab029012c03c93d96mr1129088plh.13.1627624125417; Thu, 29 Jul 2021 22:48:45 -0700 (PDT) Received: from ?IPv6:2601:646:9702:c61:4005:25b2:7c99:54fc? ([2601:646:9702:c61:4005:25b2:7c99:54fc]) by smtp.gmail.com with ESMTPSA id j12sm707222pfj.208.2021.07.29.22.48.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jul 2021 22:48:45 -0700 (PDT) From: Yingzhen Qu Message-Id: <3DD26365-E0AB-4C97-A1EA-249DBE4FB713@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6E15A621-35F2-4015-9385-46DEF0058F9D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 29 Jul 2021 22:48:43 -0700 In-Reply-To: Cc: "rtg-ads@ietf.org" , "draft-ietf-rtgwg-policy-model.all@ietf.org" , "rtg-dir@ietf.org" , "rtgwg@ietf.org" To: Jon Hardwick References: <88D465F6-19F6-48C3-AA16-C25B49F89C28@gmail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [RTG-DIR] [EXTERNAL] Rtgdir Last Call review of draft-ietf-rtgwg-policy-model X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 05:48:52 -0000 --Apple-Mail=_6E15A621-35F2-4015-9385-46DEF0058F9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jon, Thanks for the comments. Please see my answers below. Thanks, Yingzhen > On Jul 19, 2021, at 3:53 AM, Jon Hardwick = wrote: >=20 > Hi Yingzhen > =20 > Sorry for the delay in replying. I=E2=80=99d like to discuss a couple = of points =E2=80=93 please see [Jon] below=E2=80=A6 > =20 > Cheers > Jon > =20 > =20 > From: Yingzhen Qu >=20 > Sent: 29 June 2021 21:54 > To: Jon Hardwick > > Cc: rtg-ads@ietf.org ; = draft-ietf-rtgwg-policy-model.all@ietf.org = ; rtgdir@ietf.org = ; rtgwg@ietf.org > Subject: [EXTERNAL] Re: Rtgdir Last Call review of = draft-ietf-rtgwg-policy-model > =20 > Hi Jon, > =20 > Thanks for the review. Please see my answers inline. > =20 > Thanks, > Yingzhen >=20 >=20 > On Jun 26, 2021, at 3:32 AM, Jon Hardwick > wrote: > =20 > I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please = seehttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir = . > =20 > Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. > =20 > Document: draft-ietf-rtgwg-policy-model-29 > Reviewer: Jon Hardwick > Review Date: Jun 26th, 2021 > Intended Status: Standards Track > =20 > Summary: > This document provides a foundational framework for the definition of = routing protocol policies regarding the filtering in / out of routes = when they are imported / exported between routing protocol neighbors = and/or routing protocols and the RIB. Its purpose is to provide a = framework which can be augmented by routing protocols in their policy = YANG modules. I think that the document meets its goal very well. > =20 > The document is in good shape. It's clear, well-defined in its scope = and easy to read. I have a few minor concerns that I would like to see = addressed before publication. > =20 > Minor Comments: > =20 > Section 4.2 > Why no match-set-options for neighbor-set? Is there no application = for differentiating between "any of these neighbors" and "none of these = neighbors"? > =20 > You can only match on a single interface. Why is that? Was there no = use case for any ANY / INVERT match on a set of interfaces? I am = thinking of multihoming use cases. > =20 > [Yingzhen]: Typically you can apply a route-policy or route-map to an = interface or a neighbor, plus you can configure multiple route policies. = I didn=E2=80=99t get your multihoming example, would you please = elaborate? And why the current module doesn=E2=80=99t work? > [Jon]: I Am Not An Operator so I don=E2=80=99t have a real use case, = but this is more of a question / thought experiment about how it will be = used. It could be that I=E2=80=99ve misunderstood how this would be done = in your model so please explain if I=E2=80=99ve got this wrong. Say I = am configuring an L3VPN for a customer who will be multi-homed into my = router over two interfaces (or more) and that I want to apply the same = policy to all those interfaces. In a =E2=80=9Ctraditional=E2=80=9D CLI I = might create a route map and then configure a reference to that route = map on each interface. In this YANG model it looks like I must configure = two identical policy statements, one matching on interface A and the = other matching on interface B, because I have no ability to configure = =E2=80=9Cmatch on either interface A or interface B=E2=80=9D. The = difference with the route map seems to be that I=E2=80=99ve had to = configure the same policy statement twice. > Perhaps this example might be solved by matching on a neighbor-set or = on a VRF instead. I was just surprised not to see an equivalent = interface-set. >=20 [Yingzhen]: For your example, you can config, for example one prefix-set = (route-map), then reference this prefix-set (route-map) in two policy = statements in the =E2=80=9Cstatement=E2=80=9D list (apply to two = interfaces). We didn=E2=80=99t have an option for interface matching = because we didn=E2=80=99t think it=E2=80=99s used as much as tag = matching, and it can be done using multiple policy statements in the = list. > "Comparison conditions may similarly use options=E2=80=A6" - what do = you mean by a "comparison condition"? The term is not used elsewhere in = the document. > =20 > [Yingzhen]: This is not really a term. It simply meant how to compare = or the conditions to compare. I=E2=80=99d suggest we leave this to RFC = editor. > [Jon] It=E2=80=99s just that it sounds like it means something = specific. The text says =E2=80=9CMatch conditions may be further = modified=E2=80=A6 Comparison conditions may further use=E2=80=A6=E2=80=9D= and this makes me wonder what the difference is between a match = condition and a comparison condition. If I had to take a guess, it = sounds like =E2=80=9Cmatch condition=E2=80=9D refers to comparing = against a set of values whereas =E2=80=9Ccomparison condition=E2=80=9D = refers to comparing against a single scalar value. The basic conditions = defined in this base model appear to only use set comparisons, but you = are saying that other models can augment this with single scalar value = comparisons, in which case those models can also define =E2=80=9Cless = than, greater than=E2=80=9D etc. options to control the match, although = those types of option are not defined here in the base model. Is that = right? In which case, I wonder if it is even worth saying / explaining, = or perhaps removing this sentence and leaving it to the augmenting = models to define what they want? [Yingzhen]: Currently there are =E2=80=9Cmatch-set-options-group=E2=80=9D = and =E2=80=9Cmatch-set-options-restricted-group=E2=80=9D defined in the = module. Models that augments this policy model can use either of these = or have their own definitions. If you think this is not clear, please = let me know.=20 >=20 > [Jon]: Actually I have spotted another comment I want to make. In = =E2=80=9Cgrouping neighbor-set-condition=E2=80=9D the description says = =E2=80=9CMatch a referenced neighbor set according to the logic defined = in the match-set-options-leaf=E2=80=9D but there is no such leaf in this = grouping. Should there be, or is the description wrong? [Yingzhen]: thanks for catching this. It was copy&paste error, now = fixed. > =20 > [Jon]: One more nit =E2=80=93 the description for =E2=80=9Cgrouping = tag-set-condition=E2=80=9D refers to the =E2=80=9Cmatch-options-set = leaf=E2=80=9D =E2=80=93 it should be =E2=80=9Cmatch-set-options leaf=E2=80= =9D. [Yingzhen]: fixed. > Section 5 > "If the conditions are not satisfied, then evaluation proceeds to the > next policy statement" > =20 > I think that evaluation also proceeds to the next policy statement if = the conditions were satisfied, but the actions did not include either = accept-route or reject-route. Is that correct? I think it would be worth = making that explicit. > =20 > [Yingzhen]: This is included in the first paragraph of section 5. = Please let us know if you think it=E2=80=99s not clear. > [Jon] Yes, on re-reading it, I think it=E2=80=99s fine as written. >=20 > =20 > Section 7.2 > p21: > description > "Mask length range lower bound. It MUST NOT be less than > the prefix length defined in ip-prefix."; > =20 > Why must it not be? And is there a situation in which it makes sense = to allow it to be greater than the prefix length defined in ip-prefix? = Should there be a "must" clause to police this constraint? > =20 > [Yingzhen]: Here are a couple of prefix-list config examples. The = =E2=80=9CMUST NOT=E2=80=9D might be a bit strong in the description, but = I suppose most implementations would reject it if you config it less = than the prefix length. > Router(config)# ip prefix-list MYLIST 10.1.1.0/24 le 30=20 > Router(config)# ip prefix-list MYLIST 10.1.1.0/24 ge 26 le 30=20 > =20 > [Jon]: This is fine =E2=80=93 I retract the comment (not sure what I = was thinking now!). >=20 >=20 > p29: > description > "Policy statements group conditions and actions > within a policy definition. They are evaluated in > the order specified (see the description of policy > evaluation at the top of this module."; > =20 > Missing close-parenthesis in this description. >=20 > [Yingzhen]: thank you for catching this. I=E2=80=99ve noted it down, = will fix it in the next version. >=20 > =20 > Best regards > Jon > =20 --Apple-Mail=_6E15A621-35F2-4015-9385-46DEF0058F9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jon,

Thanks for the = comments. Please see my answers below.

Thanks,
Yingzhen

On Jul 19, 2021, at 3:53 AM, Jon Hardwick <jonhardwick@microsoft.com> wrote:

Hi Yingzhen
 
Sorry for the delay in replying. I=E2=80=99d like to discuss = a couple of points =E2=80=93 please see [Jon] below=E2=80=A6
 
Cheers
Jon
 
 
From: Yingzhen Qu <yingzhen.ietf@gmail.com> 
Sent: 29 = June 2021 21:54
To: Jon Hardwick <jonhardwick@microsoft.com>
Cc: rtg-ads@ietf.org; draft-ietf-rtgwg-policy-model.all@ietf.org; rtgdir@ietf.org; rtgwg@ietf.org
Subject: [EXTERNAL] Re: Rtgdir Last = Call review of draft-ietf-rtgwg-policy-model
 
Hi Jon,
 
Thanks= for the review. Please see my answers inline.
 
Thanks,
Yingzhen


On = Jun 26, 2021, at 3:32 AM, Jon Hardwick <jonhardwick@microsoft.com> = wrote:
 
I have been selected as the Routing = Directorate reviewer for this draft. The Routing Directorate seeks to = review all routing or routing-related drafts as they pass through IETF = last call and IESG review, and sometimes on special request. The purpose = of the review is to provide assistance to the Routing ADs. For more = information about the Routing Directorate, please seehttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir= .
 
Although these comments are primarily for the use of the = Routing ADs, it would be helpful if you could consider them along with = any other IETF Last Call comments that you receive, and strive to = resolve them through discussion or by updating the draft.
 
Document: = draft-ietf-rtgwg-policy-model-29
Reviewer: Jon Hardwick
Review Date: Jun 26th, 2021
Intended Status: Standards Track
 
Summary:
This document provides a foundational framework for the = definition of routing protocol policies regarding the filtering in / out = of routes when they are imported / exported between routing protocol = neighbors and/or routing protocols and the RIB. Its purpose is to = provide a framework which can be augmented by routing protocols in their = policy YANG modules. I think that the document meets its goal very = well.
 
The document is in good shape. It's clear, well-defined in = its scope and easy to read. I have a few minor concerns that I would = like to see addressed before publication.
 
Minor Comments:
 
Section 4.2
Why no match-set-options for neighbor-set?  Is there no = application for differentiating between "any of these neighbors" and = "none of these neighbors"?
 
You can only match on a single interface. Why is that? Was = there no use case for any ANY / INVERT match on a set of interfaces? I = am thinking of multihoming use cases.
 
[Yingzhen]: = Typically you can apply a route-policy or route-map to an interface or a = neighbor, plus you can configure multiple route policies. I didn=E2=80=99t= get your multihoming example, would you please elaborate? And why the = current module doesn=E2=80=99t work?
[Jon]: I Am Not An Operator so I = don=E2=80=99t have a real use case, but this is more of a question / = thought experiment about how it will be used. It could be that I=E2=80=99v= e misunderstood how this would be done in your model so please explain = if I=E2=80=99ve got this wrong.  Say I am configuring an L3VPN for = a customer who will be multi-homed into my router over two interfaces = (or more) and that I want to apply the same policy to all those = interfaces. In a =E2=80=9Ctraditional=E2=80=9D CLI I might create a = route map and then configure a reference to that route map on each = interface. In this YANG model it looks like I must configure two = identical policy statements, one matching on interface A and the other = matching on interface B, because I have no ability to configure =E2=80=9Cm= atch on either interface A or interface B=E2=80=9D. The difference with = the route map seems to be that I=E2=80=99ve had to configure the same = policy statement twice.
Perhaps this example might be solved by matching on a = neighbor-set or on a VRF instead. I was just surprised not to see an = equivalent interface-set.

[Yingzhen]: For = your example, you can config, for example one prefix-set (route-map), = then reference this prefix-set (route-map) in two policy statements in = the =E2=80=9Cstatement=E2=80=9D list (apply to two interfaces). We = didn=E2=80=99t have an option for interface matching because we didn=E2=80= =99t think it=E2=80=99s used as much as tag matching, and it can be done = using multiple policy statements in the list.
"Comparison conditions may similarly = use options=E2=80=A6" - what do you mean by a "comparison condition"? = The term is not used elsewhere in the document.
 
[Yingzhen]: This is not really a term. It simply = meant how to compare or the conditions to compare. I=E2=80=99d suggest = we leave this to RFC editor.
[Jon] It=E2=80=99s just that it sounds = like it means something specific. The text says =E2=80=9CMatch = conditions may be further modified=E2=80=A6  Comparison conditions = may further use=E2=80=A6=E2=80=9D and this makes me wonder what the = difference is between a match condition and a comparison condition. If I = had to take a guess, it sounds like =E2=80=9Cmatch condition=E2=80=9D = refers to comparing against a set of values whereas =E2=80=9Ccomparison = condition=E2=80=9D refers to comparing against a single scalar value. = The basic conditions defined in this base model appear to only use set = comparisons, but you are saying that other models can augment this with = single scalar value comparisons, in which case those models can also = define =E2=80=9Cless than, greater than=E2=80=9D etc. options to control = the match, although those types of option are not defined here in the = base model. Is that right? In which case, I wonder if it is even worth = saying / explaining, or perhaps removing this sentence and leaving it to = the augmenting models to define what they want?
[Yingzhen]: = Currently there are =E2=80=9Cmatch-set-options-group=E2=80=9D and = =E2=80=9Cmatch-set-options-restricted-group=E2=80=9D defined in the = module. Models that augments this policy model can use either of these = or have their own definitions. If you think this is not clear, please = let me know. 

[Jon]: Actually I have = spotted another comment I want to make. In =E2=80=9Cgrouping = neighbor-set-condition=E2=80=9D the description says =E2=80=9CMatch a = referenced neighbor set according to the logic defined in the = match-set-options-leaf=E2=80=9D but there is no such leaf in this = grouping. Should there be, or is the description wrong?
[Yingzhen]: thanks = for catching this. It was copy&paste error, now fixed.
 
[Jon]: One more nit =E2=80=93 the description = for =E2=80=9Cgrouping tag-set-condition=E2=80=9D refers to the = =E2=80=9Cmatch-options-set leaf=E2=80=9D =E2=80=93 it should be = =E2=80=9Cmatch-set-options = leaf=E2=80=9D.
[Yingzhen]: = fixed.

Section 5
"If the conditions are not satisfied, then evaluation = proceeds to the
   next policy statement"
 
I think that evaluation = also proceeds to the next policy statement if the conditions were = satisfied, but the actions did not include either accept-route or = reject-route. Is that correct? I think it would be worth making that = explicit.
 
[Yingzhen]: This is included in the first paragraph of = section 5. Please let us know if you think it=E2=80=99s not clear.
[Jon] Yes, on re-reading = it, I think it=E2=80=99s fine as written.

 
Section 7.2
p21:
      description
        "Mask length range = lower bound. It MUST NOT be less than
         the prefix = length defined in ip-prefix.";
 
Why must it not = be?  And is there a situation in which it makes sense to allow it = to be greater than the prefix length defined in ip-prefix?  Should = there be a "must" clause to police this constraint?
 
[Yingzhen]: Here are = a couple of prefix-list config examples. The =E2=80=9CMUST NOT=E2=80=9D = might be a bit strong in the description, but I suppose most = implementations would reject it if you config it less than the prefix = length.
  1. Router(config)# ip prefix-list MYLIST 10.1.1.0/24 le 30 
Router(config)# ip prefix-list MYLIST 10.1.1.0/24 ge 26 le = 30 
 
[Jon]: This is fine =E2=80=93 I retract the = comment (not sure what I was thinking now!).


p29:
          &nb= sp; description
          &nb= sp;   "Policy statements group conditions and actions
          &nb= sp;    within a policy definition.  They are = evaluated in
          &nb= sp;    the order specified (see the description of = policy
          &nb= sp;    evaluation at the top of this = module.";
 
Missing close-parenthesis in this description.

[Yingzhen]: thank you for = catching this. I=E2=80=99ve noted it down, will fix it in the next = version.

 
Best regards
Jon
 

= --Apple-Mail=_6E15A621-35F2-4015-9385-46DEF0058F9D--