From nobody Mon May 4 05:30:24 2020 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 703583A0855; Mon, 4 May 2020 05:30:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Bernardos via Datatracker To: Cc: draft-ietf-sfc-oam-framework.all@ietf.org, sfc@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158859542340.25402.14656553070841187802@ietfa.amsl.com> Reply-To: Carlos Bernardos Date: Mon, 04 May 2020 05:30:23 -0700 Archived-At: Subject: [Int-dir] Intdir telechat review of draft-ietf-sfc-oam-framework-13 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 12:30:24 -0000 Reviewer: Carlos Bernardos Review result: Ready with Nits Thanks a lot for this document. I liked reading it. I have a first generic comment, minor but that I still wanted to make. Section 2 is about SFC Layering Model, which to me seems like an introduction, but not really specifically related to the core topic of the draft. Do we need that section in this draft? Maybe it can be condensed and included as a first part of section 3. The document has a big component of requirements and gap analysis, which brings one question: should the document use normative RFC 2199 language when expressing the requirements? In Section 3.2.1 t is used, for example, but not in other parts. I think some work is needed to make this consistent. I think that the following sentence needs to be reworded: "In order to apply such OAM functions at the service layer, they need to be enhanced to operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs." I think the behaviour of SFC-aware nodes that do not support a given OAM operation should be better explained. For example, the sentence "When an SF supports OAM functionality, it is desirable to process the packet and provide an appropriate response to allow end-to-end verification." might be to vague. Table 4 has a small formatting issue in the Classifier row. I think some in-band vs out-band OAM discussion would be interesting to add to the document. From nobody Wed May 6 05:24:31 2020 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 791693A00C1; Wed, 6 May 2020 05:24:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-sfc-oam-framework@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, Tal Mizrahi , tal.mizrahi.phd@gmail.com, cjbc@it.uc3m.es, int-dir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158876786144.22272.6483455621584357748@ietfa.amsl.com> Date: Wed, 06 May 2020 05:24:21 -0700 Archived-At: Subject: [Int-dir] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sfc-oam-framework-13=3A_=28with_COMMENT=29?= X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:24:22 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-sfc-oam-framework-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is easy to read; BTW, I found that its content is more about the justifications / requirements for an OAM system and tools descriptions than about for a framework description. The core of the document appears to be section 6: this should probably be reflected in the abstract and introduction Please address the comments raised in the Internet directorate review by Carlos Bernardos: https://mailarchive.ietf.org/arch/msg/int-dir/TgQulH7hytGPNxdAPWcSgkTx1IM Please find below a couple on non-blocking COMMENTs. I would really appreciate a reply to all these COMMENTs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I would not refer to BCP 14 (RFC 8174) as this is an architectural/framework document (informational) and not a protocol specification. It seems that most of the described tools are about synthetic traffic. Is there any other means to do OAM in SFC (not that I have any suggestion...)?. -- Section 1 -- About "to be applied to packets and/or frames", for me packets are layer-3 PDUs and frames are layer-2 PDUs. While I am not familiar with SFC, I could envision SFC being applied to transport or application layers PDUs. So, why restricting the use of this document to layers 2 and 3 only ? -- Section 2 -- Is there a reason why all 'virtual links' are not mentioned in this section? I.e., SR-IOv network, tun/tap, ... Similar question about why limiting the example of VM and not including containers ? -- Section 3 -- The word "performance" is often used in the document but it is not described in depth though: is it about the SF CPU/memory or 'client traffic' latency & throughput ? Section 4 partially addresses my question but not completely; also, adding forward pointers to section 4 would be nice. -- Section 4.3 -- Please bear with my ignorance of SFC world... but, if a SF is doing proxying / rewriting the application message, how useful is an end-to-end PMTUd check? As there are two stitched TCP connections ? The overall assumption of this section is that all SF are pure layer-3, leaving the IP header intact so that ECMP & TTL checks can be done. Is it always the case ? Section 5.2 addresses the above points, but, I suggest that section 4.3 to be restricted to ' link-layer OAM' -- Section 6.4.1 -- "TTL field in NSH header to 63", not familiar with NSH, but, if there is a TTL field in NSH, then it could be useful to point to the RFC & section describing it. Esp in a section whose title is "ICMP" (referring obviously to the IP header). -- Section 8 -- In this security section, I wonder whether the trace tool deserves a paragraph or two as if trusted while being forgeable/spoofed, then operators could trust a SFC which is "owned" and not reliable (i.e., with a bypass of some security SF). Trusting the security AD to raise a DISCUSS if they think it is a DISCUSS. == NITS == -- section 6.3 -- Is it really required to re-specify the use of bit O in NSH ? -- Section 6.4.1 -- Sigh... using the IPv4 terminology of TTL... From nobody Wed May 6 05:36:18 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1BF3A0A04; Wed, 6 May 2020 05:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=T7Hkr4R7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QY9WQ+Ui 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 rakfiAlVaD0X; Wed, 6 May 2020 05:36:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5A83A09FB; Wed, 6 May 2020 05:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3400; q=dns/txt; s=iport; t=1588768555; x=1589978155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k+TCTjk/DobeN96hJ8BgTiEOb0DEJ6Syfw5giWaDzBg=; b=T7Hkr4R7U5NY+NlNmfX4FqRylXNrMRTBG+4K5I+NK6YIvRa7fKhCUjaJ a6h3n2tWIAuJVFqG8lpuGUe8UNevktKgZ3Byj0B/agQi0i84Fa1v9+55X OW9SnxxG6xZO/RUHlzoyhfSZeA1aEWL5MUC7haR/68jY7eArPC8GMn6Te Y=; IronPort-PHdr: =?us-ascii?q?9a23=3Ao/ZbVhZDy6h+ryU+o1Ex5eD/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD4THre9P0O+QvruzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZkGUv3bp6HgfAU?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCBQDSrrJe/4gNJK1mHAECAgEHARQ?= =?us-ascii?q?BBAQBQYFHgVRRBW5YLyqEI4NGA40hJZg1glIDVAsBAQEMAQEYCwoCBAEBhEQ?= =?us-ascii?q?CF4FqJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAQMBARAREQwBASwLAQs?= =?us-ascii?q?EAgEIDgMBAgECAwImAgICJQsUAQIGCAIEAQ0FIoMEAYJLAy4BDqhfAoE5iGF?= =?us-ascii?q?2gTKDAAEBBYUZGIIOAwaBDiqCY4lhGoFBP4ERJwwQgU9+PoJnAQGBZYMSM4I?= =?us-ascii?q?tjkiDAaAPBncKgkiOE4U9hEYCG50gkBedHAIEAgQFAg4BAQWBaSKBVnAVOyo?= =?us-ascii?q?Bgj5QGA2UNIUUhUJ0NwIGAQcBAQMJfJFKAQE?= X-IronPort-AV: E=Sophos;i="5.73,359,1583193600"; d="scan'208";a="755042670" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 12:35:49 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 046CZnAB003643 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 12:35:50 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 07:35:49 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 6 May 2020 07:35:49 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 6 May 2020 07:35:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=edmlah2p3WSAmQ5iAABcM3+eNfO1zb1sslPzWln0wU4saQrAKt/09yU0qCOUdiQ2EruG0YTnly+kTyUUIHg+MV5T1Ku5jKkCcq3UxrFUZhUmxoPwBC5mJRojCBciL1JgHXnI8y/BYLGJGxD3grLzGMnydYRMRQ0f5ibzCcNaZP1EiJ8CRoGNOmd4iqnSZFSv0I2/Dcx9/AZpsR8U8YBA38IKxv+PSUHrUE6nDtxG/BFOgZ/qxDVXhKWi+PoZM1V/Ts9kOIfXzNugBYfZUEjoIsu0OGj+TwxcXmHyXybDCqB5wAS2Oi/30nUHA54b37uXX0SoxAQbnpG3fi/XyD0dxw== 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=k+TCTjk/DobeN96hJ8BgTiEOb0DEJ6Syfw5giWaDzBg=; b=YyDIssesYh6rfXK/soZ//VsM1F/21DA1N+kXgostDnuOlIpJAzsuXsQvbuyKlONIlULVW5E0GPr/2oSNhcjCi7PC473b6ckqrSJKl3K9Lh30FWf5TxhyZpdLEjeBNGjw1hMGIBtZmMEHX4ad0WjZ8KyZMeV0ydMJbUl1gUhDX/hw3NqHLzVCDYGGn2xD1P4EIdYsZk9iEVnDNQ1rjhWZ5ezLssVSrzTxAtKd7QAAo6QYq79eQ/wzGXi60+wZmZaCQ4HVaUR5RL20sOu+p9GNbP7ahgxquyQAH5KLnkvtAZ/4rKrI9rIpoTBhPZjnQGehZ8Lwxz7BglIcaC+m2+CBWA== 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=k+TCTjk/DobeN96hJ8BgTiEOb0DEJ6Syfw5giWaDzBg=; b=QY9WQ+UiRSd1echUZSqbmNoVwrduJrd7njqBkP4QRldXxJp3X/d0m1ks9z6KZ0qLtkJTQePAqse6TEHEOJvaYti1XU3IXV2iH/bZLTvGTXxt98qey5UYmV00JegZVzbdRSPQIi2GR8E08WxgQgFE9FD6dr/L37cfL1SgY/GpnEc= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB2009.namprd11.prod.outlook.com (2603:10b6:3:15::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Wed, 6 May 2020 12:35:48 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c%9]) with mapi id 15.20.2979.028; Wed, 6 May 2020 12:35:48 +0000 From: "Eric Vyncke (evyncke)" To: Carlos Bernardos , "int-dir@ietf.org" CC: "last-call@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-oam-framework.all@ietf.org" Thread-Topic: [Int-dir] Intdir telechat review of draft-ietf-sfc-oam-framework-13 Thread-Index: AQHWIg/WNv1Qbew9+EKZeowhexS2GKibIyOA Date: Wed, 6 May 2020 12:35:47 +0000 Message-ID: <90935230-7120-4AE8-8681-1E7520B6A0EF@cisco.com> References: <158859542340.25402.14656553070841187802@ietfa.amsl.com> In-Reply-To: <158859542340.25402.14656553070841187802@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: it.uc3m.es; dkim=none (message not signed) header.d=none;it.uc3m.es; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:8c61:47ef:9ce5:3a3a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d13905d-f73b-416c-3bb7-08d7f1ba0120 x-ms-traffictypediagnostic: DM5PR11MB2009: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wjcwpGxJ6qc/wqBLxnyNf6YBS8yM74tttaWfuovmP3WFJip9kg0dwN39KFV7fCEDl4W7KUVqfadDkRELp01h8Os0Te15hxOb5k47U2Bf1Y8hMcO2l0F0qbkocWYG20lySi3lZ9Zca/0Azfgb/qKtvO0e8DYOdujmdNYwTKNL0T5AV1vSojRdnpeITSTqO6+vFWhZ+h866IrTCzcFF53n8bwF1fUSQEtUlMmcK3XtAJ3jvkp+xpWLuevOGtbgpqxZLhCl5J9PodZQ33btSd/OcDuHeGqq80rUVS4SITo8WbS7eGnth7j1l7svyvDmXkDp29WJDoPpYUAxn/kzu8qTOmV50Pm54OU7Ow3Gyj+d1+s65Kw78/S1wb0aeZJ/TgT4Tsfg8EREuN/qbK5eyihFZS8l0bFWJ9y+G1lA8sDPQQFxIRaEdNHhuQ+9b8xjW5K+90n6B0LWxxrAht8+DqQV6HzKHSeWYv8UX4StXG1p3JAccuNhjho3qPXUTzqfQ6WPPE8KqF7hTFbohcsBNdylBHRjOuQsafB/MnAfEiRFTT2qA0CqEb7ipKh5Es16BNcKTIWfIpuoDg0Oy7OGnFSRmG9GyH2GWoAE2zUHxgEc1Xo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(396003)(346002)(376002)(33430700001)(110136005)(478600001)(6486002)(316002)(76116006)(2616005)(71200400001)(86362001)(966005)(33440700001)(91956017)(186003)(33656002)(36756003)(6512007)(54906003)(2906002)(4326008)(8936002)(53546011)(66446008)(6506007)(66946007)(66556008)(64756008)(66476007)(8676002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Vq6W1vMhXrIXuTWbSFnWj7JzFI2aGJoqs7pn1WLB6PpsbaePEacJ5opRaXzFA2PzePV5oZ/vrku2LlNRCS/ps4vZZ0Uz8e1joRhp84kGx10fv8ERuHmuhHoUzNQOMw0Qs9O808tV76g4HUr3rcoNkBUOi7pbDZOCDg4YmlpGm+oDnIbzsqWCzWxt9qeqLQo8VAsTlWUHLJbjZVwFID4auX5tS9+E8F3CVJWgu1moW1aE+eJbuhY4we5Ntw9R3FRbrwDIQTZMeudiX4jffrahv2SaTMFGWuwyM8MNe4TgB5KWqVPRUJLdmmqvBtQZVJrZCvEt5PGkzgPTuEMeWW3uOnbxbJN4654iGjoi5Zt2wxd/Bs2Q+WgLRJX4g4vTcK6O5IyQJax+rjyiF16uvjuFYu6SCX3b2R1Yw3IlRUhLGAGVdwkKglJ9gf7dy+TLl1Y0q9WfuhmkqkwFor7ovTAo/58kOiUWCGuiwQtvBW7E4d6jbD7gq8a5jsVPJB5kWmmkTTaSwPuwwEsztV6d/yMv8chzfTJj46oHVWB6pAr7OxeVHBuAC9gAZ7TPyKAmR2dL61Cl13TzWsgQXXVVVy4UbRix+H75BLZmaNqF+O0GCJp0yz0oQVtsSUWQr9sSflPGac83S6P5+UaWXIJ7je4jwyoGTDx6Vb+Nl032cNlPIcKnn/WFwlxWUzGhBZSf1m31QbYMT+uky+Z79AbYx9sCAArygSuzTiG4vPthwYc6/3te3VxyyOiXS5+dQXhsLsmCn15/WS3T93oklvV9t7a03ajAUL06hVN+TGBwoSjfw3HzIQWlTU2WUk51C14eP9rz4WJiaulW7ZCZvbv5iCJ+t4AOMnEXJJZDc8YgOCA6qjg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4d13905d-f73b-416c-3bb7-08d7f1ba0120 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 12:35:47.9606 (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: J+57lPFa/Wl4g3CQ3XLmorBryls6T2CfD7YEPo5TfIcb4XDUld89ln5lV0L1lKR/XszYK4LXhmOdpLS/qEdydA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB2009 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-sfc-oam-framework-13 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:36:11 -0000 VGhhbmsgeW91IENhcmxvcyBmb3IgeW91ciByZXZpZXcuDQoNCkkgdXNlZCB5b3VyIHJldmlldyB0 byBiYWxsb3Qgb24gdGhlIGRvY3VtZW50IGZvciB0aGUgN3RoIG9mIE1heSBJRVNHIHRlbGVjaGF0 IGV4Y2VwdCBmb3IgdGhlIHJlZmVyZW5jZSB0byBCQ1AgMTQgaW4gYW4gaW5mb3JtYXRpb25hbCBk b2N1bWVudCAoYW5kIHVzdWFsbHkgYXJjaGl0ZWN0dXJlIGRvY3VtZW50cyBhcmUgaW5kZWVkIGlu Zm9ybWF0aW9uYWwpLg0KDQpCZXN0IHJlZ2FyZHMNCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJbnQtZGlyIDxpbnQtZGlyLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBDYXJsb3MgQmVybmFyZG9zIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBp ZXRmLm9yZz4NClJlcGx5LVRvOiBDYXJsb3MgQmVybmFyZG9zIDxjamJjQGl0LnVjM20uZXM+DQpE YXRlOiBNb25kYXksIDQgTWF5IDIwMjAgYXQgMTQ6MzANClRvOiAiaW50LWRpckBpZXRmLm9yZyIg PGludC1kaXJAaWV0Zi5vcmc+DQpDYzogImxhc3QtY2FsbEBpZXRmLm9yZyIgPGxhc3QtY2FsbEBp ZXRmLm9yZz4sICJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1zZmMt b2FtLWZyYW1ld29yay5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3Jr LmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IFtJbnQtZGlyXSBJbnRkaXIgdGVsZWNoYXQgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtc2ZjLW9hbS1mcmFtZXdvcmstMTMNCg0KICAgIFJldmlld2VyOiBDYXJs b3MgQmVybmFyZG9zDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQoNCiAgICBU aGFua3MgYSBsb3QgZm9yIHRoaXMgZG9jdW1lbnQuIEkgbGlrZWQgcmVhZGluZyBpdC4NCg0KICAg IEkgaGF2ZSBhIGZpcnN0IGdlbmVyaWMgY29tbWVudCwgbWlub3IgYnV0IHRoYXQgSSBzdGlsbCB3 YW50ZWQgdG8gbWFrZS4gU2VjdGlvbg0KICAgIDIgaXMgYWJvdXQgU0ZDIExheWVyaW5nIE1vZGVs LCB3aGljaCB0byBtZSBzZWVtcyBsaWtlIGFuIGludHJvZHVjdGlvbiwgYnV0IG5vdA0KICAgIHJl YWxseSBzcGVjaWZpY2FsbHkgcmVsYXRlZCB0byB0aGUgY29yZSB0b3BpYyBvZiB0aGUgZHJhZnQu IERvIHdlIG5lZWQgdGhhdA0KICAgIHNlY3Rpb24gaW4gdGhpcyBkcmFmdD8gTWF5YmUgaXQgY2Fu IGJlIGNvbmRlbnNlZCBhbmQgaW5jbHVkZWQgYXMgYSBmaXJzdCBwYXJ0DQogICAgb2Ygc2VjdGlv biAzLg0KDQogICAgVGhlIGRvY3VtZW50IGhhcyBhIGJpZyBjb21wb25lbnQgb2YgcmVxdWlyZW1l bnRzIGFuZCBnYXAgYW5hbHlzaXMsIHdoaWNoIGJyaW5ncw0KICAgIG9uZSBxdWVzdGlvbjogc2hv dWxkIHRoZSBkb2N1bWVudCB1c2Ugbm9ybWF0aXZlIFJGQyAyMTk5IGxhbmd1YWdlIHdoZW4NCiAg ICBleHByZXNzaW5nIHRoZSByZXF1aXJlbWVudHM/IEluIFNlY3Rpb24gMy4yLjEgdCBpcyB1c2Vk LCBmb3IgZXhhbXBsZSwgYnV0IG5vdA0KICAgIGluIG90aGVyIHBhcnRzLiBJIHRoaW5rIHNvbWUg d29yayBpcyBuZWVkZWQgdG8gbWFrZSB0aGlzIGNvbnNpc3RlbnQuDQoNCiAgICBJIHRoaW5rIHRo YXQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBuZWVkcyB0byBiZSByZXdvcmRlZDogIkluIG9yZGVy IHRvIGFwcGx5DQogICAgc3VjaCBPQU0gZnVuY3Rpb25zIGF0IHRoZSBzZXJ2aWNlIGxheWVyLCB0 aGV5IG5lZWQgdG8gYmUgZW5oYW5jZWQgdG8gb3BlcmF0ZSBhDQogICAgc2luZ2xlIFNGL1NGRiB0 byBtdWx0aXBsZSBTRnMvU0ZGcyBpbiBhbiBTRkMgYW5kIGFsc28gaW4gbXVsdGlwbGUgU0ZDcy4i DQoNCiAgICBJIHRoaW5rIHRoZSBiZWhhdmlvdXIgb2YgU0ZDLWF3YXJlIG5vZGVzIHRoYXQgZG8g bm90IHN1cHBvcnQgYSBnaXZlbiBPQU0NCiAgICBvcGVyYXRpb24gc2hvdWxkIGJlIGJldHRlciBl eHBsYWluZWQuIEZvciBleGFtcGxlLCB0aGUgc2VudGVuY2UgIldoZW4gYW4gU0YNCiAgICBzdXBw b3J0cyBPQU0gZnVuY3Rpb25hbGl0eSwgaXQgaXMgZGVzaXJhYmxlIHRvIHByb2Nlc3MgdGhlIHBh Y2tldCBhbmQgcHJvdmlkZQ0KICAgIGFuIGFwcHJvcHJpYXRlIHJlc3BvbnNlIHRvIGFsbG93IGVu ZC10by1lbmQgdmVyaWZpY2F0aW9uLiIgbWlnaHQgYmUgdG8gdmFndWUuDQoNCiAgICBUYWJsZSA0 IGhhcyBhIHNtYWxsIGZvcm1hdHRpbmcgaXNzdWUgaW4gdGhlIENsYXNzaWZpZXIgcm93Lg0KDQog ICAgSSB0aGluayBzb21lIGluLWJhbmQgdnMgb3V0LWJhbmQgT0FNIGRpc2N1c3Npb24gd291bGQg YmUgaW50ZXJlc3RpbmcgdG8gYWRkIHRvDQogICAgdGhlIGRvY3VtZW50Lg0KDQoNCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIEludC1kaXIg bWFpbGluZyBsaXN0DQogICAgSW50LWRpckBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaW50LWRpcg0KDQo= From nobody Wed May 13 12:59:59 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4583A08BE; Wed, 13 May 2020 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=FLe2kxAQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=afkOlP4M 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 1yTZs-sU14mr; Wed, 13 May 2020 12:59:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A843A08B9; Wed, 13 May 2020 12:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4406; q=dns/txt; s=iport; t=1589399995; x=1590609595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=no5BCu5M3JbNWTgHUFxMxBGLd4X8Rf0XmxrcFz+IHMA=; b=FLe2kxAQIkOeMO3qLVSfLPz3/12xBgq7K7W0AYm2oJYAMI7XcrxqpKxS oomENpbkLp1EehQ5hKGtBsbkZmuZrrwCCWiyjSTJQK55WFfX9u7kqpC/p cthOm1feiAuBhRv9RocdXiYfhmFKkncSefp3lzhGMCeAr/btcAnI6S6uZ Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AxoqBhBRB1iHhrua5lzeCSZytftpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ6u4CluGNtubtQj9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Tvjuv5mUXXB?= =?us-ascii?q?jkZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAQAcUbxe/5NdJa1mHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE2BQELAYFTUQeBRy8sCoQbg0YDjRiYXIJSA1QLAQEBDAEBLQIEAQG?= =?us-ascii?q?ERAIXgXckNwYOAgMBAQsBAQUBAQECAQUEbYVWDIVyAgEDEhERDAEBNwEPAgE?= =?us-ascii?q?IDgwCJgICAjAVEAIEAQ0FIoMEgkwDLgGnCQKBOYhhdoEygwEBAQWFJxiCDgm?= =?us-ascii?q?BDioBgmKJXxqCAIE4DBCBT34+hE46glozgi2OLSmDBKAqfQqCS44ehUSEUB2?= =?us-ascii?q?CXIhskgCQKJ00AgQCBAUCDgEBBYFoI4FWcBVlAYI+UBgNkECDcopWdDcCBgE?= =?us-ascii?q?HAQEDCXyNOAGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,388,1583193600"; d="scan'208";a="758283046" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 May 2020 19:59:54 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 04DJxrPX005363 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2020 19:59:54 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 14:59:53 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 14:59:52 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 13 May 2020 14:59:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e7jZtrZFMlM3sXyJN/tcCu28eVsJOS+klmHfHJozoAg10WAGAkYmazSlLsQmuGBs+li07bMwj8qlEI8yOeBPgDec6TQS9RsKYX4gas6aDjRlVJD+t29OVT/tMXiXgGhY/rayDisTEKXSFzzifvO6lr4ZH2yrEiFmfKPQfP6z80hXtV4piWmbO1uQXia7q79apOuDwWGSUW9l3Gg6jyG/0YSlisJ5f2sRK7BaGXV9I3vmK17ZpJGeRsjnEgDSMaUI/cU3ifKzumcSXAB24UKBMhgCRylQHnukU3gZ4ZRY7eTJ2y5F7gjuNDiAJO6GOvURwILqMgmkdjpGdaOYErtYUg== 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=no5BCu5M3JbNWTgHUFxMxBGLd4X8Rf0XmxrcFz+IHMA=; b=W0WLaQtanv6GbeO3QZwPFf3mmsBXYtqP5GTmU4G6iDMPhWV1QIWgfgTObt05Tno/dROGvaB69j4/aOVv//vuv5C2Y7AklRF80Rz5YC3ldNzoynPvsM/8549jcjb5V29q8hFdv9TePPBf3wsBh8hipAsz7x4PByH56dHFIiRmtM+Etpip139JLkpG+XNLvpMcJ6yqNuC0QVLNZjVpMrIxJOWoL+U11030Z7F0OZKZq3H8/52FrbrTiIVvety/zw2VAD79hOvzY2gE7kixXZfaAul9pt2m0t5MxSahWnfCmVBW3iAUaPCajPyNpIyl5F1uigv5osnZ16PNXCW5sumrxg== 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=no5BCu5M3JbNWTgHUFxMxBGLd4X8Rf0XmxrcFz+IHMA=; b=afkOlP4M/pAo/6BZ96uYTDwq6iqK08mK9f8EyhAOjeg2OLlBdQ68w787DVz//bxOuo2s/Duq9cCayAK95l1fvzalYvMjg+rQ6hxhgC7t/XoeJaG2N+ILsNTbOzZPsG2AwGwBYbBaXdaz3OoofGI30drsj11kIweS7gOsMD9JwJc= Received: from BN6PR11MB4068.namprd11.prod.outlook.com (2603:10b6:405:7c::31) by BN6PR11MB2049.namprd11.prod.outlook.com (2603:10b6:404:46::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Wed, 13 May 2020 19:59:50 +0000 Received: from BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::6d40:9e8a:252a:4f34]) by BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::6d40:9e8a:252a:4f34%3]) with mapi id 15.20.3000.016; Wed, 13 May 2020 19:59:50 +0000 From: "Nagendra Kumar Nainar (naikumar)" To: Carlos Bernardos , "int-dir@ietf.org" CC: "draft-ietf-sfc-oam-framework.all@ietf.org" , "sfc@ietf.org" , "last-call@ietf.org" Thread-Topic: Intdir telechat review of draft-ietf-sfc-oam-framework-13 Thread-Index: AQHWIg/U93nXrQCgKEu8i6q1eK3JXKimOvAA Date: Wed, 13 May 2020 19:59:50 +0000 Message-ID: <74D97DDB-2385-4868-AFFC-3DBD4B9A3A48@cisco.com> References: <158859542340.25402.14656553070841187802@ietfa.amsl.com> In-Reply-To: <158859542340.25402.14656553070841187802@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: it.uc3m.es; dkim=none (message not signed) header.d=none;it.uc3m.es; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 737d6902-a685-46a7-f1d2-08d7f778325f x-ms-traffictypediagnostic: BN6PR11MB2049: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0402872DA1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /aqBYhm5aWHsHuMauHhxd0fBf5yT81Iog3OxHLQG6QeKGCCV5q+BSU2Dt7gpVKmS3MlMMLQWPfr/1rBODnS397EU2Dc41XIy7sFt03R39D70eqXWSHmGcdTaqUQqAUlPCXm6asH7QGRbwPWqsiGyJ/+1lj6eUPg2YqAnKuCKx7ZarSePzi4ALoIcoT/9kjjmoKVJl93of4a+EprfFCFNFwoNRsC5xOR6VRPNbmRURzlRjmthSIy/Gi1q0l53oIsUbHbfGv9GV9LX3RYFqav0ZjMvSMqTU8eG3VwAmLUaPxxMPo44otejSqw9ShZC3DmCc8j1SVjtkB0tFbNknXphCZ8ufMW7N1ewiTEXI9hh5HL/oLrqHXstFsTgyRUfQrgiyV59UC5l6iYNWDgor2VQGMy6A7A2LGKzhweYaEgOouFS6iT+jvkl1CtveuDfkTNi0yCUiIJ8mQPlDzS5dc5HSacQpaG56YAZd6DjW3vseAHZ1MdHHG4q29If4BAYBtNIWgVNoHa0dsUoJOItbhfjPw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4068.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(33430700001)(36756003)(186003)(71200400001)(6506007)(54906003)(2906002)(26005)(110136005)(478600001)(76116006)(66476007)(8676002)(66946007)(5660300002)(66556008)(91956017)(6512007)(64756008)(8936002)(33656002)(2616005)(33440700001)(6486002)(316002)(86362001)(4326008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wlrljPWFANoI02hdwK5j3XDG/h60EMl9T/cTbLlPa+14lc9SFOHHNvZ5XhkdvRUD8LYno4kbRolzKS3Z8aXIh5B4iLXVhYt9oCCodkmTe6Ex6XPJq7sh9NFd1ASo30aGHUWE9ZKKqaX37hyXf/OLpzJXX44/Ts2e9Z3I7lpHHDay3t67anbKOeuZ8x95xpRjG7b2FhZ+ApGl70gQKxcH8Ht4+SKu2T7ERJjQ9eBRymhfE/ogIIT85el5XJO59IzovZfz5vWhnBVRKltm1C0k3aL4BBenoqfn10sYGAGt5RxqTSGE15D2YyyyTnEQM4vsuPdfzD4dH4FSE3mV4BfwdTlpweuV/UrbNyG+tSjPF9xDLLpe+bTmHF4sGtXRG8P8ZwhnqX50TsW1alt9DfNZYqX22XSOfoTLNDVigsHqJNfBQgHDhH7tijbxO6us9vOsBTxXz0Agf48YcnnZH2FhiAJhaOKwiOAa4Sg3ROzpSDZKPoW3txDtU5Kt81vpmwuN x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 737d6902-a685-46a7-f1d2-08d7f778325f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 19:59:50.6561 (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: HJl+KuNqJEM42kti73RThimoDSF5IctiZNf9xk32na4e0TE+WbtQoERoZzEVMJU9FkO/y5lDBVLpbWK7lz1CFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB2049 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-sfc-oam-framework-13 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 19:59:57 -0000 SGkgQ2FybG9zLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcgYW5kIHNoYXJpbmcgdGhlIGNv bW1lbnRzLiBQbGVhc2Ugc2VlIGlubGluZSBmb3IgdGhlIHJlc3BvbnNlczoNCg0K77u/T24gNS80 LzIwLCA4OjMwIEFNLCAiQ2FybG9zIEJlcm5hcmRvcyB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5 QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBDYXJsb3MgQmVybmFyZG9zDQogICAg UmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQogICAgDQogICAgVGhhbmtzIGEgbG90IGZv ciB0aGlzIGRvY3VtZW50LiBJIGxpa2VkIHJlYWRpbmcgaXQuDQogICAgDQogICAgSSBoYXZlIGEg Zmlyc3QgZ2VuZXJpYyBjb21tZW50LCBtaW5vciBidXQgdGhhdCBJIHN0aWxsIHdhbnRlZCB0byBt YWtlLiBTZWN0aW9uDQogICAgMiBpcyBhYm91dCBTRkMgTGF5ZXJpbmcgTW9kZWwsIHdoaWNoIHRv IG1lIHNlZW1zIGxpa2UgYW4gaW50cm9kdWN0aW9uLCBidXQgbm90DQogICAgcmVhbGx5IHNwZWNp ZmljYWxseSByZWxhdGVkIHRvIHRoZSBjb3JlIHRvcGljIG9mIHRoZSBkcmFmdC4gRG8gd2UgbmVl ZCB0aGF0DQogICAgc2VjdGlvbiBpbiB0aGlzIGRyYWZ0PyBNYXliZSBpdCBjYW4gYmUgY29uZGVu c2VkIGFuZCBpbmNsdWRlZCBhcyBhIGZpcnN0IHBhcnQNCiAgICBvZiBzZWN0aW9uIDMuDQogICAg DQo8TmFnZW5kcmE+IFNlY3Rpb24gMiBzcGxpdHMgdGhlIFNGQyBpbnRvIGxheWVycyB0aGF0IGhl bHBzIGFzc29jaWF0ZSBkaWZmZXJlbnQgU0ZDIE9BTSBjb21wb25lbnRzIGFuZCBpdHMgZGVwZW5k ZW5jeSBvbiBkaWZmZXJlbnQgbGF5ZXJzLiBGb3IgZWFzZSBvZiByZWFkaW5nLCBJIHRoaW5rIHdl IHdpbGwgbGVhdmUgaXQgaW4gdGhpcyBzZWN0aW9uLg0KDQogICAgVGhlIGRvY3VtZW50IGhhcyBh IGJpZyBjb21wb25lbnQgb2YgcmVxdWlyZW1lbnRzIGFuZCBnYXAgYW5hbHlzaXMsIHdoaWNoIGJy aW5ncw0KICAgIG9uZSBxdWVzdGlvbjogc2hvdWxkIHRoZSBkb2N1bWVudCB1c2Ugbm9ybWF0aXZl IFJGQyAyMTk5IGxhbmd1YWdlIHdoZW4NCiAgICBleHByZXNzaW5nIHRoZSByZXF1aXJlbWVudHM/ IEluIFNlY3Rpb24gMy4yLjEgdCBpcyB1c2VkLCBmb3IgZXhhbXBsZSwgYnV0IG5vdA0KICAgIGlu IG90aGVyIHBhcnRzLiBJIHRoaW5rIHNvbWUgd29yayBpcyBuZWVkZWQgdG8gbWFrZSB0aGlzIGNv bnNpc3RlbnQuDQogICANCjxOYWdlbmRyYT4gSSBob3BlIHlvdSBhcmUgcmVmZXJyaW5nIHRvIFJG QzIxMTkgKEJDUCAxNCkuIFdlIGdvdCBzaW1pbGFyIGNvbW1lbnRzIGZyb20gb3RoZXIgcmV2aWV3 ZXJzIGFuZCBhZ3JlZWQgdG8gcmVtb3ZlIHRoZSBzZWN0aW9uIGFuZCBhdm9pZCB1c2luZyBhbnkg bm9ybWF0aXZlIHN0YXRlbWVudHMuDQoNCiAgICBJIHRoaW5rIHRoYXQgdGhlIGZvbGxvd2luZyBz ZW50ZW5jZSBuZWVkcyB0byBiZSByZXdvcmRlZDogIkluIG9yZGVyIHRvIGFwcGx5DQogICAgc3Vj aCBPQU0gZnVuY3Rpb25zIGF0IHRoZSBzZXJ2aWNlIGxheWVyLCB0aGV5IG5lZWQgdG8gYmUgZW5o YW5jZWQgdG8gb3BlcmF0ZSBhDQogICAgc2luZ2xlIFNGL1NGRiB0byBtdWx0aXBsZSBTRnMvU0ZG cyBpbiBhbiBTRkMgYW5kIGFsc28gaW4gbXVsdGlwbGUgU0ZDcy4iDQogICAgDQo8TmFnZW5kcmE+ T2suIFdlIG1vZGlmaWVkIGl0IGFzIGJlbG93LiBIb3BlIHRoYXQgY2xhcmlmaWVzOg0KDQpPTEQ6 DQogDQpJbiBvcmRlciB0byBhcHBseQ0KICAgc3VjaCBPQU0gZnVuY3Rpb25zIGF0IHRoZSBzZXJ2 aWNlIGxheWVyLCB0aGV5IG5lZWQgdG8gYmUgZW5oYW5jZWQgdG8NCiAgIG9wZXJhdGUgYSBzaW5n bGUgU0YvU0ZGIHRvIG11bHRpcGxlIFNGcy9TRkZzIGluIGFuIFNGQyBhbmQgYWxzbyBpbg0KICAg bXVsdGlwbGUgU0ZDcy4NCiAgIA0KTkVXOg0KSW4gb3JkZXIgdG8gYXBwbHkNCiAgIHN1Y2ggT0FN IGZ1bmN0aW9ucyBhdCB0aGUgc2VydmljZSBsYXllciwgdGhleSBuZWVkIHRvIGJlIGVuaGFuY2Vk IHRvDQogICBhcHBseSB0aGUgT0FNIGZ1bmN0aW9uIG9uIGEgc2luZ2xlIFNGL1NGRiBvciBtdWx0 aXBsZSBTRnMvU0ZGcyANCiAgIHNwYW5uaW5nIGFjcm9zcyBvbmUgb3IgbW9yZSBTRkNzLg0KDQog ICAgSSB0aGluayB0aGUgYmVoYXZpb3VyIG9mIFNGQy1hd2FyZSBub2RlcyB0aGF0IGRvIG5vdCBz dXBwb3J0IGEgZ2l2ZW4gT0FNDQogICAgb3BlcmF0aW9uIHNob3VsZCBiZSBiZXR0ZXIgZXhwbGFp bmVkLiBGb3IgZXhhbXBsZSwgdGhlIHNlbnRlbmNlICJXaGVuIGFuIFNGDQogICAgc3VwcG9ydHMg T0FNIGZ1bmN0aW9uYWxpdHksIGl0IGlzIGRlc2lyYWJsZSB0byBwcm9jZXNzIHRoZSBwYWNrZXQg YW5kIHByb3ZpZGUNCiAgICBhbiBhcHByb3ByaWF0ZSByZXNwb25zZSB0byBhbGxvdyBlbmQtdG8t ZW5kIHZlcmlmaWNhdGlvbi4iIG1pZ2h0IGJlIHRvIHZhZ3VlLg0KICAgIA0KPE5hZ2VuZHJhPiBU aGlzIGlzIGV4cGxhaW5lZCBpbiB0aGUgcHJldmlvdXMgc2VudGVuY2UgYXMgYmVsb3c6DQoNCiIg VXBvbiByZWNlaXZpbmcgYW4gT0FNIHBhY2tldCwgU0ZDLWF3YXJlIFNGcyBtYXkgY2hvb3NlIHRv IGRpc2NhcmQgdGhlDQogICBwYWNrZXQgaWYgaXQgZG9lcyBub3Qgc3VwcG9ydCBPQU0gZnVuY3Rp b25hbGl0eSBvciBpZiB0aGUgbG9jYWwNCiAgIHBvbGljeSBwcmV2ZW50cyB0aGVtIGZyb20gcHJv Y2Vzc2luZyB0aGUgT0FNIHBhY2tldC4iDQoNCg0KICAgIFRhYmxlIDQgaGFzIGEgc21hbGwgZm9y bWF0dGluZyBpc3N1ZSBpbiB0aGUgQ2xhc3NpZmllciByb3cuDQogICAgDQo8TmFnZW5kcmE+IFRo YW5rIHlvdS4gRml4ZWQgaXQgYW5kIHdpbGwgYmUgcmVmbGVjdGVkIGluIHRoZSBuZXcgcmV2aXNp b24uIA0KDQogICAgSSB0aGluayBzb21lIGluLWJhbmQgdnMgb3V0LWJhbmQgT0FNIGRpc2N1c3Np b24gd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gYWRkIHRvDQogICAgdGhlIGRvY3VtZW50Lg0KICAg IA0KICAgPE5hZ2VuZHJhPiBXaGlsZSB0aGUgd2hvbGUgZG9jdW1lbnQgcHJpbWFyaWx5IGZvY3Vz ZWQgb24gb3V0LWJhbmQsIHNlY3Rpb24gNi40IGFscmVhZHkgdGFsa3MgYWJvdXQgdGhlIGFwcGxp Y2FiaWxpdHkgb2YgSW4tYmFuZCBPQU0gdG9vbCB0byBwZXJmb3JtIHRoZSBPQU0gZnVuY3Rpb25z Lg0KICAgIA0KT25jZSBhZ2FpbiwgdGhhbmtzIGEgbG90IGZvciB0aGUgZ3JlYXQgY29tbWVudHMu DQoNClRoYW5rcywNCk5hZ2VuZHJhDQoNCg== From nobody Wed May 13 14:01:20 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB823A091D; Wed, 13 May 2020 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=NAo9QbQt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lW55qTUD 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 of2jNynnplVV; Wed, 13 May 2020 14:01:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAD83A091A; Wed, 13 May 2020 14:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14476; q=dns/txt; s=iport; t=1589403673; x=1590613273; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EevsQtadJFLGQ2rKXSTGd40YqxbS4MBJkfTChTAakgo=; b=NAo9QbQtd+Uk8MkWA1aBTHrNQJkLis5nVKFI/BwWQHEyBiwMwgDktCw5 FRUfik6DkkAoJVyU1ZrxReTZZ4cnDBXqGG7AUXIj/o9MvZ/LT1rSJHcFi ljGtxM/T6G2iu83NEzQFDqmwzGCWSs54TJAsxppEW8vXottHfEBV8v5tk 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AdIqOMxz62rbX1fnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/5sl1TOG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKwMFNeH4D1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJCACwX7xe/4sNJK1mHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFHgVQkLQdvWC8sCoQbg0YDjRiYXIFCgRADVAsBAQEMAQElCAIEAQG?= =?us-ascii?q?ERAIXgXckOBMCAwEBCwEBBQEBAQIBBQRthVYMhXICAQMSEREMAQE3AQ8CAQg?= =?us-ascii?q?SCAImAgICMBUCAwsCBAENBRsHgwQBgksDLgEOA6ZpAoE5iGF2gTKDAQEBBYE?= =?us-ascii?q?yARNBgz8Ygg4DBoEOKoJjiV8aggCBEScMEIFPfj6CZwIBAgGBLAELBwEHITE?= =?us-ascii?q?Cglozgi2OPhIGgkcBPKEoCoJNiB2LR4RQHYJdiGyFAogIhHaDc4w5iV+TWQI?= =?us-ascii?q?EAgQFAg4BAQWBaSJmWBEHcBUaISoBgj5QGA2QQDiDOoUUhUJ0AjUCBgEHAQE?= =?us-ascii?q?DCQF7jAOBNQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,389,1583193600"; d="scan'208";a="770110186" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 May 2020 21:00:49 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 04DL0nFA025244 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 May 2020 21:00:49 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 16:00:49 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 16:00:48 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 13 May 2020 16:00:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=loVGzyS7X9nYw469zS4NHDfdBfx8Qi3nHh6/DY46Kztr7gGd9FZh0v5xZ7qv3FOETFkwpZKInXDcAy5JJk8GTuCj2u/2R+Pw4QrC4IEhDlmjUUIYktjb28FRxPrg6fVra2F5ZrwtQu8noPhIMAgkNFF04/VSB8XQ2FbmxgQgJ95sTLBdwNsa/dOxIVVUMLC0jDmexUEf84de0we8ke+N+bSTRYGL0HEPueUYk5Bkrw4xziP5gm8HHBAU9WDsvcfFDr2/hZk8jRsnWQaiU2/czbUeRTdbi50Zv6LNraJNG3hH8OtCboagBChigdPXzNc1Rk+MOw5nGweSVRuwsx1pEg== 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=EevsQtadJFLGQ2rKXSTGd40YqxbS4MBJkfTChTAakgo=; b=XnBzCfsI3hB296qa1sjLnw40KOOjBlyBOBmP3e75bs+mToB2/AVq8K3CWaDVU+eZ3ipKDGZOE56YVSnI80CZZBRSM4rWAHoptqLnqVtWa/n4JH22wY1ghWq6BuJCiVU7A/wf4FzR+C5SHG0R5Rdnt19eRS2qDKfvdFXaquW6jR2SaA+h0imCsx6n8BVy9cKOVsHnKpBpdUQ9rkUMrb1Wy2jeDU970ltiSr5GiRwi2lEzEDEVKF8rXAk6FGTCebP5whWhJV23RzlmkfX8dF+bqy24x8OIu5VqEZSngLXdpvyUDoWIQFXuXl5OEO/BMBlI74CygCobgJnPj3LTAgm+Sg== 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=EevsQtadJFLGQ2rKXSTGd40YqxbS4MBJkfTChTAakgo=; b=lW55qTUDERwCzSdnJxyYVSypkgtelKR/9jJ6b4PZibjrEQ3DhCpJGIrfeJY2DsYASoJRRN7chfoHwdI5PCGs+XGiVQjrrOsrYtzDt5teFygGhL8dwad/VHLDAMd7eEJVyfprksaBQDwvIq/iyM83LDgJv4xm/Fkwvwl+DLCCHY8= Received: from BN6PR11MB4068.namprd11.prod.outlook.com (2603:10b6:405:7c::31) by BN6PR11MB0034.namprd11.prod.outlook.com (2603:10b6:405:6b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.24; Wed, 13 May 2020 21:00:47 +0000 Received: from BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::6d40:9e8a:252a:4f34]) by BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::6d40:9e8a:252a:4f34%3]) with mapi id 15.20.3000.016; Wed, 13 May 2020 21:00:47 +0000 From: "Nagendra Kumar Nainar (naikumar)" To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-sfc-oam-framework@ietf.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , Tal Mizrahi , "cjbc@it.uc3m.es" , "int-dir@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc2Zj?= =?utf-8?Q?-oam-framework-13:_(with_COMMENT)?= Thread-Index: AQHWI6FJ9zTDA56WOkCEPXJ4twd//6imSNQA Date: Wed, 13 May 2020 21:00:47 +0000 Message-ID: References: <158876786144.22272.6483455621584357748@ietfa.amsl.com> In-Reply-To: <158876786144.22272.6483455621584357748@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7951c617-3d1d-4a45-cc78-08d7f780b5aa x-ms-traffictypediagnostic: BN6PR11MB0034: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0402872DA1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aPKLMdjuDJOUcvB1iQVoLpP+Fi1/Lov1yJpEkjFESC55b9IEjH5RziZez6SkFl8VLXVOTc25EjeCPXkxB39g0dGRVTmMgIcdVxwddvbhHzK4waB1KOZQFMAvSahNifHzdH/Gr4p1CQ7OA3/1/1ACuFFRe5R1b7YpPapNhn2hteDHxrhmgqGy+dhzKiwMukFOUfCyrCokdRg9YFUYFrmC21m0Yezt+ILlTnLfotuxVXXgopj9oJ0Ny/37213k2TMpUp5AMTjEesmDZD3ikVlo6v9FCiBoi2VtMa6BZhT4u9a/cdTSgqX2MMz9JXg69Y/f59Dvfo/0zmNyaWLL2Er11LHGd5cuRaawLNSSgOlFadOja5hk/1kPCYsLRxblVMzBliL3W/Cpo8j8lJdRpoXy9bcUN8HV+kCqE8WdQCI/PXFzSFjq65l3hKFnxRioDYdGkcnJ2enCrPrZ6gUj7/2S1FLDfpvB7GU8pDNxPZeqBo21HE09goQtLwFy2q9VAH+LccGwWkHQ7CHaBA2nJB0KHxbLoSR8udCHVP6qwt+KLluJNzHZopu8iEVHbrVbDvuyyB4eAbZ2vt+U7ttFSrSFGvFSR91wt7JDhTK+0RhQMaA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4068.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(346002)(366004)(376002)(33430700001)(2906002)(71200400001)(4326008)(316002)(66574014)(36756003)(33440700001)(110136005)(5660300002)(54906003)(966005)(66446008)(224303003)(6506007)(91956017)(33656002)(76116006)(6486002)(186003)(86362001)(64756008)(66556008)(478600001)(66476007)(8936002)(2616005)(6512007)(26005)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ukHjMuGVbgooQPvkqbPbwbvqc5rBiagWZPMM1Gg+7pjylk2P2GkDkbUi2jBvPTGQKJUD0jDwBNztFgowkAAPiKYvoEHvcVrR7mcAreWskk3Oz8tSd3G8VU0o5TFlLYzrURlqbAhhinEDRGYVZ3y2Xj8oGsZpzEcMWKIarj8oClRs8E0PY2wRwlVqJksGD9HjxHmvtcMkuRZQmo13qOgwRR1rB/oyHlkabYryCbR6Wntpr6PaYUuiXXBzPxgKL79XLSxr5WS3UQ/VFKhThxMbK2C0ohEN5oWtvDhAbGwiEEW9zVyrP4xxOOvJnoX1/tA6CBWuHMoR3DS+0j4OmouhPtdPNzCZNpXV9l+F6fP+U/cqQj9tGytju4D8iQfMOwkbpQQduaemziRmPJTyQ9OLigwiVhn4aVyOMlNHQIvQXrD0TXKYyZyCuWZsyTkCIC03EoaS4FLMknG96Jpptrcl2UPzYqsTn2RhoX3wTjk1wJHEPgLH9+i4c2cCsAdEG52N Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7951c617-3d1d-4a45-cc78-08d7f780b5aa X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 21:00:47.0799 (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: uYcAocxeOn1soHrR1tx99JjP4xa4cVImIwBlcdsfj6HjzYwnXKXXjZCwGUffGp/EUMXYbh7saVKb+Y6Z6i+fTA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB0034 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Int-dir] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sfc-oam-framework-13=3A_=28with_COMMENT=29?= X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 21:01:17 -0000 SGkgRXJpYywNCg0KVGhhbmsgeW91IGZvciB0aGUgZ3JlYXQgY29tbWVudHMuIFBsZWFzZSBzZWUg aW5saW5lLi4NCg0K77u/T24gNS82LzIwLCA4OjI0IEFNLCAiw4lyaWMgVnluY2tlIHZpYSBEYXRh dHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgw4lyaWMgVnluY2tlIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgIGRyYWZ0LWll dGYtc2ZjLW9hbS1mcmFtZXdvcmstMTM6IE5vIE9iamVjdGlvbg0KICAgIA0KICAgIFdoZW4gcmVz cG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRv IGFsbA0KICAgIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVz LiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQogICAgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93 ZXZlci4pDQogICAgDQogICAgDQogICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAg DQogICAgDQogICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc2ZjLW9hbS1mcmFtZXdvcmsvDQogICAgDQogICAgDQogICAgDQogICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAg IFRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1bWVudC4gVGhlIGRvY3Vt ZW50IGlzIGVhc3kgdG8gcmVhZDsNCiAgICBCVFcsIEkgZm91bmQgdGhhdCBpdHMgY29udGVudCBp cyBtb3JlIGFib3V0IHRoZSBqdXN0aWZpY2F0aW9ucyAvIHJlcXVpcmVtZW50cw0KICAgIGZvciBh biBPQU0gc3lzdGVtIGFuZCB0b29scyBkZXNjcmlwdGlvbnMgdGhhbiBhYm91dCBmb3IgYSBmcmFt ZXdvcmsgZGVzY3JpcHRpb24uDQogIA0KPE5hZ2VuZHJhPiBBcyB5b3UgbWlnaHQgaGF2ZSBub3Rp Y2VkLCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGF0dGVtcHQgdG8gbGlzdCBhIHNldCBvZiByZXF1 aXJlbWVudHMuIEluc3RlYWQsIGl0IHByb3Bvc2VzIGEgc3RydWN0dXJlZCBsYXllciBhbmQgcG9z aXRpb25zIGRpZmZlcmVudCBTRkMgT0FNIGNvbXBvbmVudHMgYW5kIGV4cGxhaW4gdGhlIE9BTSAg ZnVuY3Rpb25hbGl0aWVzIG9mIHN1Y2ggY29tcG9uZW50cyBhbmQgdGhlcmVieSBtYWtpbmcgaXQg ZWFzaWVyIGZvciB0aGUgc29sdXRpb24gZG9jdW1lbnRzIHRvIGFkZHJlc3MgdGhlIHNhbWUuIEFj Y29yZGluZ2x5LCB3ZSBiZWxpZXZlIHRoaXMgZml0IGFzIGEgZnJhbWV3b3JrIGRvY3VtZW50ICgu DQoNCiAgICBUaGUgY29yZSBvZiB0aGUgZG9jdW1lbnQgYXBwZWFycyB0byBiZSBzZWN0aW9uIDY6 IHRoaXMgc2hvdWxkIHByb2JhYmx5IGJlDQogICAgcmVmbGVjdGVkIGluIHRoZSBhYnN0cmFjdCBh bmQgaW50cm9kdWN0aW9uDQogICAgDQo8TmFnZW5kcmE+IFNlY3Rpb24gNiBpcyBhYm91dCB0aGUg Y2FuZGlkYXRlIFNGQyBPQU0gdG9vbHMuIEJ1dCB0aGUgb3RoZXIgc2VjdGlvbnMgYXJlIGVxdWFs bHkgaW1wb3J0YW50IHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBvdmVyYWxsIGNvbnRleHQsIGRp ZmZlcmVudCBjb21wb25lbnRzIGZvbGxvd2VkIGJ5IHRoZSB0b29sc2V0IGF2YWlsYWJpbGl0eSBh bmQgdGhlIGdhcHMuIFRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBleHBsYWlucyB0aGlzIGZvciBl YXNlIG9mIHJlYWRpbmcuIA0KDQogICAgUGxlYXNlIGFkZHJlc3MgdGhlIGNvbW1lbnRzIHJhaXNl ZCBpbiB0aGUgSW50ZXJuZXQgZGlyZWN0b3JhdGUgcmV2aWV3IGJ5IENhcmxvcw0KICAgIEJlcm5h cmRvczoNCiAgICBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2ludC1kaXIv VGdRdWxIN2h5dEdQTnhkQVBXY1Nna1R4MUlNDQogIA0KPE5hZ2VuZHJhPiBUaGFuayB5b3UgZm9y IGZvcndhcmRpbmcgdGhlIGNvbW1lbnRzIGZyb20gQ2FybG9zLiBXZSBhZGRyZXNzZWQgdGhlIHNh bWUgYW5kIGluY2x1ZGVkIHRoZSBtb2RpZmljYXRpb24gaW4gdGhlIGRvY3VtZW50Lg0KDQogICAg UGxlYXNlIGZpbmQgYmVsb3cgYSBjb3VwbGUgb24gbm9uLWJsb2NraW5nIENPTU1FTlRzLiBJIHdv dWxkIHJlYWxseSBhcHByZWNpYXRlDQogICAgYSByZXBseSB0byBhbGwgdGhlc2UgQ09NTUVOVHMu DQogICAgDQogICAgSSBob3BlIHRoYXQgdGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVu dCwNCiAgICANCiAgICBSZWdhcmRzLA0KICAgIA0KICAgIC3DqXJpYw0KICAgIA0KICAgID09IENP TU1FTlRTID09DQogICAgDQogICAgSSB3b3VsZCBub3QgcmVmZXIgdG8gQkNQIDE0IChSRkMgODE3 NCkgYXMgdGhpcyBpcyBhbiBhcmNoaXRlY3R1cmFsL2ZyYW1ld29yaw0KICAgIGRvY3VtZW50IChp bmZvcm1hdGlvbmFsKSBhbmQgbm90IGEgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbi4NCiAgIA0KPE5h Z2VuZHJhPiBXZSBnb3Qgc2ltaWxhciBjb21tZW50cyBmcm9tIG90aGVyIHJldmlld2VycyBhcyB3 ZWxsLiBXZSByZW1vdmVkIHRoaXMgc2VjdGlvbiBhbmQgdXBkYXRlZCBieSBhdm9pZGluZyB0aGUg dXNlIG9mIG5vcm1hdGl2ZSBzdGF0ZW1lbnRzLg0KDQogICAgSXQgc2VlbXMgdGhhdCBtb3N0IG9m IHRoZSBkZXNjcmliZWQgdG9vbHMgYXJlIGFib3V0IHN5bnRoZXRpYyB0cmFmZmljLiBJcyB0aGVy ZQ0KICAgIGFueSBvdGhlciBtZWFucyB0byBkbyBPQU0gaW4gU0ZDIChub3QgdGhhdCBJIGhhdmUg YW55IHN1Z2dlc3Rpb24uLi4pPy4NCiAgIA0KPE5hZ2VuZHJhPiBXZSBicmllZmx5IGV4cGxhaW5l ZCB0aGUgYXBwbGljYWJpbGl0eSBvZiBJbi1TaXR1IE9BTSBpbiBzZWN0aW9uIDYuNC4zLiBUaGUg b3ZlcmxheSBoZWFkZXIgKHN1Y2ggYXMgTlNIKSBjYW4gY2FycnkgaU9BTSBkYXRhIGZpZWxkcy4g VGhlIHNvbHV0aW9uIGRvY3VtZW50cyBjYW4gZGV0YWlsIHRoZSBzcGVjaWZpY3Mgb2Ygd2hhdCBk YXRhIHRvIGNvbGxlY3Qgb3IgaG93IHRvIHVzZSBpdC4NCg0KICAgIC0tIFNlY3Rpb24gMSAtLQ0K ICAgIEFib3V0ICJ0byBiZSBhcHBsaWVkIHRvIHBhY2tldHMgYW5kL29yIGZyYW1lcyIsIGZvciBt ZSBwYWNrZXRzIGFyZSBsYXllci0zIFBEVXMNCiAgICBhbmQgZnJhbWVzIGFyZSBsYXllci0yIFBE VXMuIFdoaWxlIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggU0ZDLCBJIGNvdWxkIGVudmlzaW9uDQog ICAgU0ZDIGJlaW5nIGFwcGxpZWQgdG8gdHJhbnNwb3J0IG9yIGFwcGxpY2F0aW9uIGxheWVycyBQ RFVzLiBTbywgd2h5IHJlc3RyaWN0aW5nDQogICAgdGhlIHVzZSBvZiB0aGlzIGRvY3VtZW50IHRv IGxheWVycyAyIGFuZCAzIG9ubHkgPw0KICAgIA0KPE5hZ2VuZHJhPiBHb29kIHBvaW50LiBJIHRo aW5rIHdlIGNhbiBtb2RpZnkgdGhlIHNhbWUgYXMgYmVsb3c6DQoNCk9MRDoNCmFwcGxpZWQgdG8g cGFja2V0cyBhbmQvb3IgZnJhbWVzIHNlbGVjdGVkIGFzIGEgcmVzdWx0DQoNCk5FVzoNCmFwcGxp ZWQgdG8gYW55IHRyYWZmaWMgc2VsZWN0ZWQgYXMgYSByZXN1bHQuLg0KDQogICAgLS0gU2VjdGlv biAyIC0tDQogICAgSXMgdGhlcmUgYSByZWFzb24gd2h5IGFsbCAndmlydHVhbCBsaW5rcycgYXJl IG5vdCBtZW50aW9uZWQgaW4gdGhpcyBzZWN0aW9uPw0KICAgIEkuZS4sIFNSLUlPdiBuZXR3b3Jr LCB0dW4vdGFwLCAuLi4NCiAgICANCjxOYWdlbmRyYT4gSSB0aGluayBpdCBpcyB2ZXJ5IG11Y2gg cG9zc2libGUuIERvZXMgdGhlIGJlbG93IHRleHQgbG9va3MgYmV0dGVyPw0KDQpPTEQ6DQpvICBU aGUgbGluayBsYXllciwgd2hpY2ggaXMgdGlnaHRseSBjb3VwbGVkIHdpdGggdGhlIHBoeXNpY2Fs DQogICAgICB0ZWNobm9sb2d5IHVzZWQuICBFdGhlcm5ldCBpcyBhIHBvcHVsYXIgY2hvaWNlIGZv ciB0aGlzIGxheWVyLCBidXQNCiAgICAgIG90aGVyIGFsdGVybmF0aXZlcyBhcmUgZGVwbG95ZWQg KGUuZy4gIFBPUywgRFdETSkuICBUaGUgc2FtZSBvcg0KICAgICAgZGlzdGluY3QgbGluayBsYXll ciB0ZWNobm9sb2dpZXMgbWF5IGJlIHVzZWQgaW4gZWFjaCBsZWcgc2hvd24gaW4NCiAgICAgIEZp Z3VyZSAxLg0KDQpORVc6DQpvICBUaGUgbGluayBsYXllciwgd2hpY2ggaXMgdGlnaHRseSBjb3Vw bGVkIHdpdGggdGhlIHBoeXNpY2FsIGxheWVyDQogICAgICB0ZWNobm9sb2d5IHVzZWQuICBFdGhl cm5ldCBpcyBhIHBvcHVsYXIgY2hvaWNlIGZvciB0aGlzIGxheWVyLCBidXQNCiAgICAgIG90aGVy IGFsdGVybmF0aXZlcyBhcmUgZGVwbG95ZWQgKGUuZy4gIFBPUywgRFdETSkuICBJbiBhIHZpcnR1 YWwgZW52aXJvbm1lbnQsIA0KICAgICAgdmlydHVhbGl6ZWQgSS9PIHRlY2hub2xvZ2llcyBzdWNo IGFzIFNSLUlPViBvciBzaW1pbGFyIGFyZSBhcHBsaWNhYmxlIGZvciB0aGlzIGxheWVyLg0KICAg ICAgVGhlIHNhbWUgb3IgZGlzdGluY3QgbGluayBsYXllciB0ZWNobm9sb2dpZXMgbWF5IGJlIHVz ZWQgaW4gZWFjaCBsZWcgc2hvd24gaW4NCiAgICAgIEZpZ3VyZSAxLg0KDQogICAgU2ltaWxhciBx dWVzdGlvbiBhYm91dCB3aHkgbGltaXRpbmcgdGhlIGV4YW1wbGUgb2YgVk0gYW5kIG5vdCBpbmNs dWRpbmcNCiAgICBjb250YWluZXJzID8NCiAgICANCjxOYWdlbmRyYT4gV2UgY2hhbmdlZCB2aXJ0 dWFsIG1hY2hpbmVzIGFzIHZpcnR1YWwgZW50aXRpZXMgc28gdGhhdCBpdCBpcyBub3QgbGltaXRl ZCB0byBWTXMuIEJlbG93IGlzIHRoZSBtb2RpZmllZCB0ZXh0Og0KDQpPTEQ6DQpJbiBGaWd1cmUg MSwgdGhlIHNlcnZpY2UgbGF5ZXIgZWxlbWVudCBzdWNoIGFzIGNsYXNzaWZpZXIgYW5kIFNGIGFy ZQ0KICAgZGVwaWN0ZWQgYXMgdmlydHVhbCBtYWNoaW5lcyB0aGF0IGFyZSBpbnRlcmNvbm5lY3Rl ZCB1c2luZyBhbiBvdmVybGF5DQogICBuZXR3b3JrLiAgVGhlIHVuZGVybGF5IG5ldHdvcmsgbWF5 IGNvbXByaXNlIG9mIG11bHRpcGxlIGludGVybWVkaWF0ZQ0KICAgbm9kZXMgYnV0IG5vdCBzaG93 biBpbiB0aGUgZmlndXJlIHRoYXQgcHJvdmlkZXMgdW5kZXJsYXkgY29ubmVjdGl2aXR5DQogICBi ZXR3ZWVuIHRoZSBzZXJ2aWNlIGxheWVyIGVsZW1lbnRzLg0KDQogICBXaGlsZSBGaWd1cmUgMSBk ZXBpY3RzIGFuIGV4YW1wbGUgd2hlcmUgU0ZzIGFyZSBlbmFibGVkIGFzIHZpcnR1YWwNCiAgIGVu dGl0aWVzLCB0aGUgU0ZDIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBtYWtlIGFueSBhc3N1bXB0aW9u cyBvbiBob3cNCiAgIHRoZSBTRkMgZGF0YSBwbGFuZSBlbGVtZW50cyBhcmUgZGVwbG95ZWQuICBU aGUgU0ZDIGFyY2hpdGVjdHVyZSBpcw0KICAgZmxleGlibGUgYW5kIGFjY29tbW9kYXRlcyBwaHlz aWNhbCBvciB2aXJ0dWFsIGVudGl0eSBkZXBsb3ltZW50LiAgU0ZDDQogICBPQU0gYWNjb3VudHMg Zm9yIHRoaXMgZmxleGliaWxpdHkgYW5kIGFjY29yZGluZ2x5IGl0IGlzIGFwcGxpY2FibGUNCiAg IHdoZXRoZXIgU0ZDIGRhdGEgcGxhbmUgZWxlbWVudHMgYXJlIGRlcGxveWVkIGRpcmVjdGx5IG9u IHBoeXNpY2FsDQogICBoYXJkd2FyZSwgYXMgb25lIG9yIG1vcmUgVmlydHVhbCBNYWNoaW5lcywg b3IgYW55IGNvbWJpbmF0aW9uDQogICB0aGVyZW9mLg0KDQpORVc6DQoNCkluIEZpZ3VyZSAxLCB0 aGUgc2VydmljZSBsYXllciBlbGVtZW50IHN1Y2ggYXMgY2xhc3NpZmllciBhbmQgU0YgYXJlDQog ICBkZXBpY3RlZCBhcyB2aXJ0dWFsIGVudGl0aWVzIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIHVz aW5nIGFuIG92ZXJsYXkNCiAgIG5ldHdvcmsuICBUaGUgdW5kZXJsYXkgbmV0d29yayBtYXkgY29t cHJpc2Ugb2YgbXVsdGlwbGUgaW50ZXJtZWRpYXRlDQogICBub2RlcyBidXQgbm90IHNob3duIGlu IHRoZSBmaWd1cmUgdGhhdCBwcm92aWRlcyB1bmRlcmxheSBjb25uZWN0aXZpdHkNCiAgIGJldHdl ZW4gdGhlIHNlcnZpY2UgbGF5ZXIgZWxlbWVudHMuDQoNCiAgIFdoaWxlIEZpZ3VyZSAxIGRlcGlj dHMgYW4gZXhhbXBsZSB3aGVyZSBTRnMgYXJlIGVuYWJsZWQgYXMgdmlydHVhbA0KICAgZW50aXRp ZXMsIHRoZSBTRkMgYXJjaGl0ZWN0dXJlIGRvZXMgbm90IG1ha2UgYW55IGFzc3VtcHRpb25zIG9u IGhvdw0KICAgdGhlIFNGQyBkYXRhIHBsYW5lIGVsZW1lbnRzIGFyZSBkZXBsb3llZC4gIFRoZSBT RkMgYXJjaGl0ZWN0dXJlIGlzDQogICBmbGV4aWJsZSBhbmQgYWNjb21tb2RhdGVzIHBoeXNpY2Fs IG9yIHZpcnR1YWwgZW50aXR5IGRlcGxveW1lbnQuICBTRkMNCiAgIE9BTSBhY2NvdW50cyBmb3Ig dGhpcyBmbGV4aWJpbGl0eSBhbmQgYWNjb3JkaW5nbHkgaXQgaXMgYXBwbGljYWJsZQ0KICAgd2hl dGhlciBTRkMgZGF0YSBwbGFuZSBlbGVtZW50cyBhcmUgZGVwbG95ZWQgZGlyZWN0bHkgb24gcGh5 c2ljYWwNCiAgIGhhcmR3YXJlLCBhcyBvbmUgb3IgbW9yZSBWaXJ0dWFsIGVudGl0aWVzLCBvciBh bnkgY29tYmluYXRpb24NCiAgIHRoZXJlb2YuDQoNCiAgICAtLSBTZWN0aW9uIDMgLS0NCiAgICBU aGUgd29yZCAicGVyZm9ybWFuY2UiIGlzIG9mdGVuIHVzZWQgaW4gdGhlIGRvY3VtZW50IGJ1dCBp dCBpcyBub3QgZGVzY3JpYmVkIGluDQogICAgZGVwdGggdGhvdWdoOiBpcyBpdCBhYm91dCB0aGUg U0YgQ1BVL21lbW9yeSBvciAnY2xpZW50IHRyYWZmaWMnIGxhdGVuY3kgJg0KICAgIHRocm91Z2hw dXQgPyBTZWN0aW9uIDQgcGFydGlhbGx5IGFkZHJlc3NlcyBteSBxdWVzdGlvbiBidXQgbm90IGNv bXBsZXRlbHk7DQogICAgYWxzbywgYWRkaW5nIGZvcndhcmQgcG9pbnRlcnMgdG8gc2VjdGlvbiA0 IHdvdWxkIGJlIG5pY2UuDQoNCjxOYWdlbmRyYT4gU0ZDIGJlaW5nIHVuaWRpcmVjdGlvbmFsLCBv bmUtd2F5IGRlbGF5IG1lYXN1cmVtZW50IGFuZCBwYWNrZXQgbG9zcyB3YXMgZW1waGFzaXplZCBp biBzZWN0aW9uIDQuNC4gV2UgYWRkZWQgdGhlIHBvaW50ZXIgYXMgYmVsb3c6DQoNCk9MRDoNClRo ZSBzZWNvbmQgU0ZDIE9BTSByZXF1aXJlbWVudCBmb3IgdGhlIFNGIGNvbXBvbmVudCBpcyB0byBh bGxvdyBhbg0KICAgU0ZDLWF3YXJlIG5ldHdvcmsgZGV2aWNlIHRvIGNoZWNrIHRoZSBwZXJmb3Jt YW5jZSBtZXRyaWNzIHN1Y2ggYXMNCiAgIGxvc3MgYW5kIGRlbGF5IGluZHVjZWQgYnkgYSBzcGVj aWZpYyBTRiBmb3IgcHJvY2Vzc2luZyBsZWdpdGltYXRlDQogICB0cmFmZmljLiAgVGhlIHBlcmZv cm1hbmNlIGNhbiBiZSBhIHBhc3NpdmUgbWVhc3VyZW1lbnQgYnkgdXNpbmcgbGl2ZQ0KICAgdHJh ZmZpYyBvciBjYW4gYmUgYWN0aXZlIG1lYXN1cmVtZW50IGJ5IHVzaW5nIHN5bnRoZXRpYyBwcm9i ZQ0KICAgcGFja2V0cy4NCg0KTkVXOg0KVGhlIHNlY29uZCBTRkMgT0FNIHJlcXVpcmVtZW50IGZv ciB0aGUgU0YgY29tcG9uZW50IGlzIHRvIGFsbG93IGFuDQogICBTRkMtYXdhcmUgbmV0d29yayBk ZXZpY2UgdG8gY2hlY2sgdGhlIHBlcmZvcm1hbmNlIG1ldHJpY3Mgc3VjaCBhcw0KICAgbG9zcyBh bmQgZGVsYXkgaW5kdWNlZCBieSBhIHNwZWNpZmljIFNGIGZvciBwcm9jZXNzaW5nIGxlZ2l0aW1h dGUNCiAgIHRyYWZmaWMuICBUaGUgcGVyZm9ybWFuY2UgY2FuIGJlIGEgcGFzc2l2ZSBtZWFzdXJl bWVudCBieSB1c2luZyBsaXZlDQogICB0cmFmZmljIG9yIGNhbiBiZSBhY3RpdmUgbWVhc3VyZW1l bnQgYnkgdXNpbmcgc3ludGhldGljIHByb2JlDQogICBwYWNrZXRzLiBNb3JlIGRldGFpbHMgYWJv dXQgdGhpcyBPQU0gZnVuY3Rpb24gaXMgZXhwbGFpbmVkIA0KaW4gU2VjdGlvbiA0LjQuDQogICAg DQogICAgLS0gU2VjdGlvbiA0LjMgLS0NCiAgICBQbGVhc2UgYmVhciB3aXRoIG15IGlnbm9yYW5j ZSBvZiBTRkMgd29ybGQuLi4gYnV0LCBpZiBhIFNGIGlzIGRvaW5nIHByb3h5aW5nIC8NCiAgICBy ZXdyaXRpbmcgdGhlIGFwcGxpY2F0aW9uIG1lc3NhZ2UsIGhvdyB1c2VmdWwgaXMgYW4gZW5kLXRv LWVuZCBQTVRVZCBjaGVjaz8gQXMNCiAgICB0aGVyZSBhcmUgdHdvIHN0aXRjaGVkIFRDUCBjb25u ZWN0aW9ucyA/DQoNCjxOYWdlbmRyYT4gUGF0aCBNVFUgZGlzY292ZXJ5IGlzIG9uZSBvZiB0aGUg Y29ubmVjdGl2aXR5IGZ1bmN0aW9ucyBhbmQgdGhlIGFib3ZlLW1lbnRpb25lZCBzY2VuYXJpbyBh cHBlYXJzIHRvIGJlIG9uZSBwb3NzaWJsZSBjYXNlLiBBY2NvcmRpbmdseSwgSSB0aGluayB0aGlz IHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gdGhlIHJlc3BlY3RpdmUgc29sdXRpb24gZG9jdW1lbnQu IA0KICAgIA0KICAgIFRoZSBvdmVyYWxsIGFzc3VtcHRpb24gb2YgdGhpcyBzZWN0aW9uIGlzIHRo YXQgYWxsIFNGIGFyZSBwdXJlIGxheWVyLTMsIGxlYXZpbmcNCiAgICB0aGUgSVAgaGVhZGVyIGlu dGFjdCBzbyB0aGF0IEVDTVAgJiBUVEwgY2hlY2tzIGNhbiBiZSBkb25lLiBJcyBpdCBhbHdheXMg dGhlDQogICAgY2FzZSA/DQogICANCjxOYWdlbmRyYT4gTm90IG5lY2Vzc2FyaWx5LiBUaGUgVFRM IGhhbmRsaW5nIG1lbnRpb25lZCBpbiB0aGlzIGRvY3VtZW50IGlzIGFib3V0IHRoZSBUVEwgaW4g dGhlIE5TSC9PdmVybGF5IGhlYWRlci4gVGhlIHRyYWZmaWMgZW5jYXBzdWxhdGVkIGJ5IHRoZSBv dmVybGF5IGhlYWRlciBjYW4gYmUgTDIgb3IgTDMuDQoNCiAgICBTZWN0aW9uIDUuMiBhZGRyZXNz ZXMgdGhlIGFib3ZlIHBvaW50cywgYnV0LCBJIHN1Z2dlc3QgdGhhdCBzZWN0aW9uIDQuMyB0byBi ZQ0KICAgIHJlc3RyaWN0ZWQgdG8gJyBsaW5rLWxheWVyIE9BTScNCiAgICANCjxOYWdlbmRyYT4g VGhlIE5TSCBUVEwgZmllbGQgY2FuIGJlIGNvbnRyb2xsZWQgdG8gdGVybWluYXRlIHRoZSBwcm9i ZSBvbiBhbnkgc2VydmljZSBsYXllciBlbGVtZW50LiBTbyBJIHRoaW5rIGl0IGlzIG5vdCBsaW1p dGVkIHRvIGxpbmstbGF5ZXIuIA0KDQogICAgLS0gU2VjdGlvbiA2LjQuMSAtLQ0KICAgICJUVEwg ZmllbGQgaW4gTlNIIGhlYWRlciB0byA2MyIsIG5vdCBmYW1pbGlhciB3aXRoIE5TSCwgYnV0LCBp ZiB0aGVyZSBpcyBhIFRUTA0KICAgIGZpZWxkIGluIE5TSCwgdGhlbiBpdCBjb3VsZCBiZSB1c2Vm dWwgdG8gcG9pbnQgdG8gdGhlIFJGQyAmIHNlY3Rpb24gZGVzY3JpYmluZw0KICAgIGl0LiBFc3Ag aW4gYSBzZWN0aW9uIHdob3NlIHRpdGxlIGlzICJJQ01QIiAocmVmZXJyaW5nIG9idmlvdXNseSB0 byB0aGUgSVANCiAgICBoZWFkZXIpLg0KICAgIA0KPE5hZ2VuZHJhPiBNYWtlIHNlbnNlLiBQbGVh c2Ugc2VlIGJlbG93IGZvciB0aGUgbW9kaWZpZWQgdGV4dDoNCg0KT0xEOg0KY2FuIHNldCB0aGUg VFRMIGZpZWxkIGluIE5TSCBoZWFkZXIgdG8gNjMuLi4NCk5FVzoNCmNhbiBzZXQgdGhlIFRUTCBm aWVsZCBpbiBOU0ggaGVhZGVyIFtSRkM4MzAwXSB0byA2My4uLg0KDQogICAgLS0gU2VjdGlvbiA4 IC0tDQogICAgSW4gdGhpcyBzZWN1cml0eSBzZWN0aW9uLCBJIHdvbmRlciB3aGV0aGVyIHRoZSB0 cmFjZSB0b29sIGRlc2VydmVzIGEgcGFyYWdyYXBoDQogICAgb3IgdHdvIGFzIGlmIHRydXN0ZWQg d2hpbGUgYmVpbmcgZm9yZ2VhYmxlL3Nwb29mZWQsIHRoZW4gb3BlcmF0b3JzIGNvdWxkIHRydXN0 DQogICAgYSBTRkMgd2hpY2ggaXMgIm93bmVkIiBhbmQgbm90IHJlbGlhYmxlIChpLmUuLCB3aXRo IGEgYnlwYXNzIG9mIHNvbWUgc2VjdXJpdHkNCiAgICBTRikuIFRydXN0aW5nIHRoZSBzZWN1cml0 eSBBRCB0byByYWlzZSBhIERJU0NVU1MgaWYgdGhleSB0aGluayBpdCBpcyBhIERJU0NVU1MuDQog ICAgDQo8TmFnZW5kcmE+IFRoZSBzZWN0aW9uIGluIHZlci0xMyB3YXMgdXBkYXRlZCBiYXNlZCBv biB0aGUgY29tbWVudHMgZnJvbSBTZWNEaXIgcmV2aWV3LiBQbGVhc2UgZmVlbCBmcmVlIHRvIHNo YXJlIGFueSB0ZXh0IHN1Z2dlc3Rpb25zIGlmIHlvdSB0aGluayB0aGUgY2FuIGJlIGltcHJvdmVk IGZ1cnRoZXIuDQoNCiAgICA9PSBOSVRTID09DQogICAgDQogICAgLS0gc2VjdGlvbiA2LjMgLS0N CiAgICBJcyBpdCByZWFsbHkgcmVxdWlyZWQgdG8gcmUtc3BlY2lmeSB0aGUgdXNlIG9mIGJpdCBP IGluIE5TSCA/DQogICAgDQo8TmFnZW5kcmE+IEkgdGhpbmsgd2UgY2FuIGxlYXZlIGl0IGFzIGl0 IGRvZXNu4oCZdCBhcHBlYXIgdG8gdml0aWF0ZSB0aGUgbWVhbmluZyBvZiB0aGUgc2VudGVuY2Ug KC4NCg0KICAgIC0tIFNlY3Rpb24gNi40LjEgLS0NCiAgICBTaWdoLi4uIHVzaW5nIHRoZSBJUHY0 IHRlcm1pbm9sb2d5IG9mIFRUTC4uLg0KDQo8TmFnZW5kcmE+IFRoZSBUVEwgZGlzY3Vzc2VkIGlu IHRoaXMgc2VjdGlvbiBpcyB0aGUgZmllbGQgaW4gdGhlIE5TSCBoZWFkZXIuIA0KDQpPbmNlIGFn YWluLCB0aGFua3MgYSBsb3QgZm9yIHRoZSBncmVhdCBjb21tZW50cy4NCg0KVGhhbmtzLA0KTmFn ZW5kcmENCiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Mon May 18 13:41:38 2020 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB1D3A08E0; Mon, 18 May 2020 13:41:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tatuya Jinmei via Datatracker To: Cc: draft-ietf-dhc-slap-quadrant.all@ietf.org, dhcwg@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.130.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158983448603.3400.6838657620034200956@ietfa.amsl.com> Reply-To: Tatuya Jinmei Date: Mon, 18 May 2020 13:41:26 -0700 Archived-At: Subject: [Int-dir] Intdir last call review of draft-ietf-dhc-slap-quadrant-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 20:41:27 -0000 Reviewer: Tatuya Jinmei Review result: Ready with Issues I am an assigned INT directorate reviewer for draft-ietf-dhc-slap-quadrant. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ This draft defines a new DHCPv6 option that is supposed to be used with draft-ietf-dhc-mac-assign. The new option makes it possible for a client to specify its preferred "type" (SLAP) of MAC addresses to be assigned and for the server to make the assignment decision based on the preference. The draft is generally well written. I think it's basically ready, but there are several points not very clear to me. I guess these are largely editorial glitches or simply due to my lack of understanding of the background rather than substantial technical issues. As a reader I'd feel happy if my questions are clarified, but I'd leave these to authors. Specific comments: - Section 4.1-3 [...] The client SHOULD NOT pick a server that does not advertise an address in the requested quadrant. Does this mean if a client follows this "SHOULD NOT" and receives Advertise messages from servers that don't understand the new QUAD option, then the client can't choose any server? If so, is it okay? - Section 4.1: 5. When the assigned addresses are about to expire, the client sends a Renew message. It includes the preferred SLAP quadrant(s) in the new QUAD IA_LL-option, so in case the server is unable to extend the lifetime on the existing address(es), the preferred quadrants are known for the allocation of any "new" addresses. It's not clear to me what 'the preferred quadrants are known for the allocation of any "new" addresses' means. Does this mean the server will assign a new address from the specified quadrant(s) in response to the Renew in this situation? - Section 4.2-3 The preference between client's supplied QUAD and relay supplied QUAD (or whether it matters) isn't clear to me. What if these are inconsistent? Perhaps this paragraph at the end of Section 4.2 answers the question? The server SHOULD implement a configuration parameter to deal with the case where the client's DHCP message contains an instance of OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- forward message. [...] If so, it might be more reader friendly if 4.2-3 gives a forward reference to this consideration. Also, this paragraph seems to suggest the server may (only) process the relay's instance of the QUAD option. If so, and it's incompatible with the client's option, then I guess the same question as Section 4.1-3 applies here. - Section 5.1 [...] Note that a quadrant - preference tuple is used in this option (instead of using a list of quadrants ordered by preference) to support the case whereby a client really has no preference between two or three quadrants, leaving the decision to the server. What does "a quadrant - preference tuple is used in this option" mean? >From the context I guess it tries to talk about using the same preference for multiple quadrants, but the actual text doesn't really read that way to me... - Section 5.1 [...] If the server can provide an assignment from one of the specified quadrants, it SHOULD proceed with the assignment. If the server cannot provide an assignment from one of the specified quadrant-n fields, it MUST NOT assign any addresses and return a status of NoQuadAvail (IANA-2) in the IA_LL Option. The first and second sentece seem to contradict each other. If, for example, two quadrants Q1 and Q2 are specified and the server can only provide an assignment for Q1, what should it do? The first sentence seems to say the server should proceed with the assignemtn for Q1; the second sentence seems to say the server MUST NOT assign any address and simply return NoQuadAvail. BTW, the second sentence also seems to contradict Section 4.1? 4.1-2 states: [...] If the client specified more than one SLAP quadrant, the server MUST only return a NoQuadAvail status code if no address pool(s) configured at the server match any of the specified SLAP quadrants. Nits Section 2: s/in in/in/ relay A node that acts as an intermediary to deliver DHCP [...] functionality as described in in [RFC8415]. Section 2: s/it can be/if it can be/ ? quadrant might be different. For example, it can be managed, this From nobody Tue May 19 07:33:24 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFEC3A0861 for ; Tue, 19 May 2020 07:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es 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 0bOZ6Q8KAfVV for ; Tue, 19 May 2020 07:33:14 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 A47953A087B for ; Tue, 19 May 2020 07:33:14 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id 17so13619009ilj.3 for ; Tue, 19 May 2020 07:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ai/2tmIwItD15yzJRDge/vUFRheUyjSyLM0x4TMrOaQ=; b=NpqWI7IGb8dlHSNzSrLTcOkxVHpZ0ODC6fkYx72HYzdnlYA+Nm48koXzCNLLo0TaU7 Q7zOEJt0UzM4+6ZyqpaMv4aRRGvmkLAlIMLsQfm33ME4/tqXm4rxi+UYnCOFc4eWYsb+ J32ukFxfcqga1oeEzE7jWtUNXnG4MStUkzOsLx3Zpi5IcXPJaTe/qQ0dyzUL77gKlfcr iyw0h7iIV33altOD6V0/+tBDWsudx5L3aQyLUR8GhKNaTz6GUP/zkJoDSeb1lOu2G9dL 3IMTNdEbc9BC5Hga9SfJLcrLeM3VsZIrFrWevFVNp7Yig12tPyJbVv0x73sZ7RPjrPVF 574A== 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=Ai/2tmIwItD15yzJRDge/vUFRheUyjSyLM0x4TMrOaQ=; b=GEk/bHrS9A7yAb/WasT8EzkrGPGBO3xapp1ej0JQ9tcfU5nlncs5E2jLl1U8zLp4ld +Yk/20pxC4/SHBxiwvSOQzgij4I2hEZVl1wENez+MRF5COdhAgeUXd+AqKZWJrQX1VKR exV0vTCs8VuVuIMLpJiHGyYogi6mKqJ9zMUu/ngD2QcvnlNMwptK8YyumCWQzO9qtwJh zwTvHAGYe1eKaTX/10Xy599AhPBWqBIbKVNboNqebBuSVud7oXTwMFEu06MGCOgUjAsP T5BbFOj/WVk0aL1iwhfCuNSEQmrrL4PXHSR60AHItPYakLShy1r8aW8viaDwQdZIRRJB J8JA== X-Gm-Message-State: AOAM531WCqgjmDM6LZ9G5J076NNlo4PWMoOdKnrquyHU5ZGEfApks/wx d6UcWLNDcKSjXHZE/mu7b9DNoZE+cF0/r1216lOPsQ== X-Google-Smtp-Source: ABdhPJzh90CXNJrv0AM+adkWVaD46X1SqSrCnQg1NOsg+P6RT6OuF7+Lxud/x917eTL+mvbPjTIaSVDnZWPi6vyUDJ8= X-Received: by 2002:a05:6e02:686:: with SMTP id o6mr10788595ils.280.1589898793270; Tue, 19 May 2020 07:33:13 -0700 (PDT) MIME-Version: 1.0 References: <158983448603.3400.6838657620034200956@ietfa.amsl.com> In-Reply-To: <158983448603.3400.6838657620034200956@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Tue, 19 May 2020 16:32:57 +0200 Message-ID: To: Tatuya Jinmei Cc: "" , draft-ietf-dhc-slap-quadrant.all@ietf.org, dhcwg , last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000cdab9505a60128d1" Archived-At: Subject: Re: [Int-dir] Intdir last call review of draft-ietf-dhc-slap-quadrant-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2020 14:33:17 -0000 --000000000000cdab9505a60128d1 Content-Type: text/plain; charset="UTF-8" Thanks a lot for your detailed comments. I'll go through them and provide our responses in the following days. Carlos On Mon, May 18, 2020 at 10:41 PM Tatuya Jinmei via Datatracker < noreply@ietf.org> wrote: > Reviewer: Tatuya Jinmei > Review result: Ready with Issues > > I am an assigned INT directorate reviewer for > draft-ietf-dhc-slap-quadrant. These comments were written primarily > for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along with > any other Last Call comments that have been received. For more details > on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/ > > This draft defines a new DHCPv6 option that is supposed to be used > with draft-ietf-dhc-mac-assign. The new option makes it possible for > a client to specify its preferred "type" (SLAP) of MAC addresses to be > assigned and for the server to make the assignment decision based on > the preference. > > The draft is generally well written. I think it's basically ready, > but there are several points not very clear to me. I guess these are > largely editorial glitches or simply due to my lack of understanding of > the background rather than substantial technical issues. As a reader > I'd feel happy if my questions are clarified, but I'd leave these to > authors. > > Specific comments: > > - Section 4.1-3 > [...] The client SHOULD NOT pick a server that does not > advertise an address in the requested quadrant. > > Does this mean if a client follows this "SHOULD NOT" and receives > Advertise messages from servers that don't understand the new QUAD > option, then the client can't choose any server? If so, is it okay? > > - Section 4.1: > 5. When the assigned addresses are about to expire, the client sends > a Renew message. It includes the preferred SLAP quadrant(s) in > the new QUAD IA_LL-option, so in case the server is unable to > extend the lifetime on the existing address(es), the preferred > quadrants are known for the allocation of any "new" addresses. > > It's not clear to me what 'the preferred quadrants are known for the > allocation of any "new" addresses' means. Does this mean the server > will assign a new address from the specified quadrant(s) in response > to the Renew in this situation? > > - Section 4.2-3 > The preference between client's supplied QUAD and relay supplied QUAD > (or whether it matters) isn't clear to me. What if these are > inconsistent? Perhaps this paragraph at the end of Section 4.2 > answers the question? > > The server SHOULD implement a configuration parameter to deal > with the case where the client's DHCP message contains an instance of > OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- > forward message. [...] > > If so, it might be more reader friendly if 4.2-3 gives a forward > reference to this consideration. Also, this paragraph seems to > suggest the server may (only) process the relay's instance of the QUAD > option. If so, and it's incompatible with the client's option, then I > guess the same question as Section 4.1-3 applies here. > > - Section 5.1 > > [...] Note that a quadrant - preference tuple is > used in this option (instead of using a list of quadrants ordered by > preference) to support the case whereby a client really has no > preference between two or three quadrants, leaving the decision to > the server. > > What does "a quadrant - preference tuple is used in this option" mean? > >From the context I guess it tries to talk about using the same > preference for multiple quadrants, but the actual text doesn't really > read that way to me... > > - Section 5.1 > > [...] If the server can provide an assignment from one of the > specified quadrants, it SHOULD proceed with the assignment. If the > server cannot provide an assignment from one of the specified > quadrant-n fields, it MUST NOT assign any addresses and return a > status of NoQuadAvail (IANA-2) in the IA_LL Option. > > The first and second sentece seem to contradict each other. If, for > example, two quadrants Q1 and Q2 are specified and the server can only > provide an assignment for Q1, what should it do? The first sentence > seems to say the server should proceed with the assignemtn for Q1; the > second sentence seems to say the server MUST NOT assign any address > and simply return NoQuadAvail. > > BTW, the second sentence also seems to contradict Section 4.1? 4.1-2 > states: > > [...] If > the client specified more than one SLAP quadrant, the server MUST > only return a NoQuadAvail status code if no address pool(s) > configured at the server match any of the specified SLAP > quadrants. > > Nits > Section 2: s/in in/in/ > relay A node that acts as an intermediary to deliver DHCP > [...] > functionality as described in in [RFC8415]. > > Section 2: s/it can be/if it can be/ ? > quadrant might be different. For example, it can be managed, this > > > > --000000000000cdab9505a60128d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for your detailed=C2=A0comments. I'll go = through them and provide our responses in the following days.

Carlos

On Mon, May 18, 2020 at 10:41 PM Tatuya Jinmei via Datatr= acker <noreply@ietf.org> wrot= e:
Reviewer: Tat= uya Jinmei
Review result: Ready with Issues

I am an assigned INT directorate reviewer for
draft-ietf-dhc-slap-quadrant. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with
any other Last Call comments that have been received. For more details
on the INT Directorate, see https://datatracker.ietf= .org/group/intdir/about/

This draft defines a new DHCPv6 option that is supposed to be used
with draft-ietf-dhc-mac-assign.=C2=A0 The new option makes it possible for<= br> a client to specify its preferred "type" (SLAP) of MAC addresses = to be
assigned and for the server to make the assignment decision based on
the preference.

The draft is generally well written.=C2=A0 I think it's basically ready= ,
but there are several points not very clear to me.=C2=A0 I guess these are<= br> largely editorial glitches or simply due to my lack of understanding of
the background rather than substantial technical issues.=C2=A0 As a reader<= br> I'd feel happy if my questions are clarified, but I'd leave these t= o
authors.

Specific comments:

- Section 4.1-3
=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]=C2=A0 The client SHOULD NOT pick a server = that does not
=C2=A0 =C2=A0 =C2=A0 =C2=A0advertise an address in the requested quadrant.<= br>
Does this mean if a client follows this "SHOULD NOT" and receives=
Advertise messages from servers that don't understand the new QUAD
option, then the client can't choose any server?=C2=A0 If so, is it oka= y?

- Section 4.1:
=C2=A0 =C2=A05.=C2=A0 When the assigned addresses are about to expire, the = client sends
=C2=A0 =C2=A0 =C2=A0 =C2=A0a Renew message.=C2=A0 It includes the preferred= SLAP quadrant(s) in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the new QUAD IA_LL-option, so in case the server= is unable to
=C2=A0 =C2=A0 =C2=A0 =C2=A0extend the lifetime on the existing address(es),= the preferred
=C2=A0 =C2=A0 =C2=A0 =C2=A0quadrants are known for the allocation of any &q= uot;new" addresses.

It's not clear to me what 'the preferred quadrants are known for th= e
allocation of any "new" addresses' means.=C2=A0 Does this mea= n the server
will assign a new address from the specified quadrant(s) in response
to the Renew in this situation?

- Section 4.2-3
The preference between client's supplied QUAD and relay supplied QUAD (or whether it matters) isn't clear to me.=C2=A0 =C2=A0What if these ar= e
inconsistent?=C2=A0 Perhaps this paragraph at the end of Section 4.2
answers the question?

=C2=A0 =C2=A0The server SHOULD implement a configuration parameter to deal<= br> =C2=A0 =C2=A0with the case where the client's DHCP message contains an = instance of
=C2=A0 =C2=A0OPTION_SLAP_QUAD, and the relay adds a second instance in its = relay-
=C2=A0 =C2=A0forward message.=C2=A0 [...]

If so, it might be more reader friendly if 4.2-3 gives a forward
reference to this consideration.=C2=A0 Also, this paragraph seems to
suggest the server may (only) process the relay's instance of the QUAD<= br> option.=C2=A0 If so, and it's incompatible with the client's option= , then I
guess the same question as Section 4.1-3 applies here.

- Section 5.1

=C2=A0 =C2=A0[...]=C2=A0 Note that a quadrant - preference tuple is
=C2=A0 =C2=A0used in this option (instead of using a list of quadrants orde= red by
=C2=A0 =C2=A0preference) to support the case whereby a client really has no=
=C2=A0 =C2=A0preference between two or three quadrants, leaving the decisio= n to
=C2=A0 =C2=A0the server.

What does "a quadrant - preference tuple is used in this option" = mean?
>From the context I guess it tries to talk about using the same
preference for multiple quadrants, but the actual text doesn't really read that way to me...

- Section 5.1

=C2=A0 =C2=A0[...]=C2=A0 If the server can provide an assignment from one o= f the
=C2=A0 =C2=A0specified quadrants, it SHOULD proceed with the assignment.=C2= =A0 If the
=C2=A0 =C2=A0server cannot provide an assignment from one of the specified<= br> =C2=A0 =C2=A0quadrant-n fields, it MUST NOT assign any addresses and return= a
=C2=A0 =C2=A0status of NoQuadAvail (IANA-2) in the IA_LL Option.

The first and second sentece seem to contradict each other.=C2=A0 If, for example, two quadrants Q1 and Q2 are specified and the server can only
provide an assignment for Q1, what should it do?=C2=A0 The first sentence seems to say the server should proceed with the assignemtn for Q1; the
second sentence seems to say the server MUST NOT assign any address
and simply return NoQuadAvail.

BTW, the second sentence also seems to contradict Section 4.1?=C2=A0 4.1-2 = states:

=C2=A0 =C2=A0 =C2=A0 =C2=A0[...] If
=C2=A0 =C2=A0 =C2=A0 =C2=A0the client specified more than one SLAP quadrant= , the server MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0only return a NoQuadAvail status code if no addr= ess pool(s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0configured at the server match any of the specif= ied SLAP
=C2=A0 =C2=A0 =C2=A0 =C2=A0quadrants.

Nits
Section 2: s/in in/in/
=C2=A0 =C2=A0relay=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A node that acts as an = intermediary to deliver DHCP
[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0functionality= as described in in [RFC8415].

Section 2: s/it can be/if it can be/ ?
=C2=A0 =C2=A0 =C2=A0 quadrant might be different.=C2=A0 For example, it can= be managed, this



--000000000000cdab9505a60128d1-- From nobody Wed May 27 09:56:24 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6493A0FDC for ; Wed, 27 May 2020 09:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es 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 0EaDHxxGQP-7 for ; Wed, 27 May 2020 09:56:16 -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 70CE33A0FDD for ; Wed, 27 May 2020 09:56:16 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k18so26850337ion.0 for ; Wed, 27 May 2020 09:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GFBQ1xdWo2r8Ts6hpbWjCt0qX3UWFdLWVDgAtC+d/SI=; b=E6/Og6xJ4m8uovL0OeTEmkfl585tlMwxGbVxyYTzbr61t1NBtAX5uxEWGGE9JLN+4h 1czIYHpctSo5J/19UDUvSTscT2pUNDsrz8lfDrQ0OZaE7lNbNPSEfW/3pTeweQh6fC4t K2bzWHALM8YbVCHeYgUPGJ9tZfM/H0+nIMlwJiwsbM5u8+6Uwy09EXZJGYkjeDXleFCm x4Kgu11N00IHV24E8YzS4TitR7vE+QJHzvxtCCQvdexfLkn3z06YmBe8vAKQk38eW96C nOhEvqiMgN1LmrhXbyCsm7CMyEpk+2VZtP5BZsWjLat8AAU/wI9Krol/szK9UKcLCetU 64/g== 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=GFBQ1xdWo2r8Ts6hpbWjCt0qX3UWFdLWVDgAtC+d/SI=; b=CQO7Ix1gydqa0jXqi7ViVzDeW1LChKlAtjTXZATKjMo6dGnwcHLhOyktu+iEO2ucFS EkROIyKyjsMhmj7iYfDIvsPIPupOyY6hCenuP68uLf0JLgUejj0qtiO9ThW1lL0j0Pxo 84D1vn29OAA9S+tCAIduJpTJ5lkB/H7ndyCNkVNxakmn1II7UoIKUD7xxyQeNQNfnLqA avAxKABvboOkMw9gtgN0eKr8l2VjJLci4V9niL/Tkx5kYWhAp8EOYLVI4f8KTouP//Mj 3sinGaKsqRcmNqPhYLW/YHMHviFjM0E9UlFgYBhAJdyQSKo2XdSC+38NHzDU/UGb/MXQ Rejg== X-Gm-Message-State: AOAM5331B/SA5F3gPtPoh3cCo76X984n8U/gY4xa0Sfz4AbqtnDPOnrr 1bsCIHC3k8O5BfC+0rb1iZXKDQmHDiYWP2edEFguNA== X-Google-Smtp-Source: ABdhPJxbNp09mBEcaXCMzehIvcUfTIA+U3vmRxTa9lEhvPU4Z7HdJytzG5t8hBWZK3aBGXhK4Gigh08+m9wq6YWxuqg= X-Received: by 2002:a02:1c83:: with SMTP id c125mr6504690jac.112.1590598574153; Wed, 27 May 2020 09:56:14 -0700 (PDT) MIME-Version: 1.0 References: <158983448603.3400.6838657620034200956@ietfa.amsl.com> In-Reply-To: <158983448603.3400.6838657620034200956@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Wed, 27 May 2020 18:55:57 +0200 Message-ID: To: Tatuya Jinmei Cc: "" , draft-ietf-dhc-slap-quadrant.all@ietf.org, dhcwg , last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000fe426c05a6a4163a" Archived-At: Subject: Re: [Int-dir] Intdir last call review of draft-ietf-dhc-slap-quadrant-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 16:56:19 -0000 --000000000000fe426c05a6a4163a Content-Type: text/plain; charset="UTF-8" Dear Tatuya, Thanks a lot again for your comments. Please see inline below some comments and responses from my side. On Mon, May 18, 2020 at 10:41 PM Tatuya Jinmei via Datatracker < noreply@ietf.org> wrote: > Reviewer: Tatuya Jinmei > Review result: Ready with Issues > > I am an assigned INT directorate reviewer for > draft-ietf-dhc-slap-quadrant. These comments were written primarily > for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along with > any other Last Call comments that have been received. For more details > on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/ > > This draft defines a new DHCPv6 option that is supposed to be used > with draft-ietf-dhc-mac-assign. The new option makes it possible for > a client to specify its preferred "type" (SLAP) of MAC addresses to be > assigned and for the server to make the assignment decision based on > the preference. > > The draft is generally well written. I think it's basically ready, > but there are several points not very clear to me. I guess these are > largely editorial glitches or simply due to my lack of understanding of > the background rather than substantial technical issues. As a reader > I'd feel happy if my questions are clarified, but I'd leave these to > authors. > > Specific comments: > > - Section 4.1-3 > [...] The client SHOULD NOT pick a server that does not > advertise an address in the requested quadrant. > > Does this mean if a client follows this "SHOULD NOT" and receives > Advertise messages from servers that don't understand the new QUAD > option, then the client can't choose any server? If so, is it okay? > [Carlos] Yes, in that case the expected behaviour would be that the client does not choose any server. This is basically the same that happens with other DHCP extensions. In any case, the text you referred to above was more to describe what the client should do if the server supports the QUAD option, but still does not have addresses available from the selected quadrant. > - Section 4.1: > 5. When the assigned addresses are about to expire, the client sends > a Renew message. It includes the preferred SLAP quadrant(s) in > the new QUAD IA_LL-option, so in case the server is unable to > extend the lifetime on the existing address(es), the preferred > quadrants are known for the allocation of any "new" addresses. > > It's not clear to me what 'the preferred quadrants are known for the > allocation of any "new" addresses' means. Does this mean the server > will assign a new address from the specified quadrant(s) in response > to the Renew in this situation? > [Carlos] Yes. If the currently assigned addresses cannot be renewed, then the server will try to allocate different (that's what "new" means) addresses from the same quadrant. We have added "different" to the text in version -09 to make this clearer. > - Section 4.2-3 > The preference between client's supplied QUAD and relay supplied QUAD > (or whether it matters) isn't clear to me. What if these are > inconsistent? Perhaps this paragraph at the end of Section 4.2 > answers the question? > > The server SHOULD implement a configuration parameter to deal > with the case where the client's DHCP message contains an instance of > OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- > forward message. [...] > > If so, it might be more reader friendly if 4.2-3 gives a forward > reference to this consideration. Also, this paragraph seems to > suggest the server may (only) process the relay's instance of the QUAD > option. If so, and it's incompatible with the client's option, then I > guess the same question as Section 4.1-3 applies here. > [Carlos] That's a good point. When we wrote this we thought that the sentence "Depending on the server's policy, the instance(s) of the option to process is selected." in 4.2-3 would be sufficient as a reference for what comes at the end of Section 4.2 (which is indeed the answer to your point). I think adding a more explicit reference would make the text unnecessary long. What do you think? > - Section 5.1 > > [...] Note that a quadrant - preference tuple is > used in this option (instead of using a list of quadrants ordered by > preference) to support the case whereby a client really has no > preference between two or three quadrants, leaving the decision to > the server. > > What does "a quadrant - preference tuple is used in this option" mean? > >From the context I guess it tries to talk about using the same > preference for multiple quadrants, but the actual text doesn't really > read that way to me... > [Carlos] It means that the option includes pairs (tuples) of quadrant-n & pref-n. Would it be clearer if we use "pair" instead of tuple? > - Section 5.1 > > [...] If the server can provide an assignment from one of the > specified quadrants, it SHOULD proceed with the assignment. If the > server cannot provide an assignment from one of the specified > quadrant-n fields, it MUST NOT assign any addresses and return a > status of NoQuadAvail (IANA-2) in the IA_LL Option. > > The first and second sentece seem to contradict each other. If, for > example, two quadrants Q1 and Q2 are specified and the server can only > provide an assignment for Q1, what should it do? The first sentence > seems to say the server should proceed with the assignemtn for Q1; the > second sentence seems to say the server MUST NOT assign any address > and simply return NoQuadAvail. > > BTW, the second sentence also seems to contradict Section 4.1? 4.1-2 > states: > > [...] If > the client specified more than one SLAP quadrant, the server MUST > only return a NoQuadAvail status code if no address pool(s) > configured at the server match any of the specified SLAP > quadrants. > > [Carlos] Maybe is an English issue here (note that I'm not a native speaker). What we mean is that if the server does not have at least addresses from one of the specified quadrants, it must not assign any. So if Q1 and Q2 are requested, and the server has only addresses from Q1, this is fine and it should proceed with the assignment for Q1. Only if the server does not have addresses from neither Q1 or Q2 it should return NoQuadAvail. > Nits > Section 2: s/in in/in/ > relay A node that acts as an intermediary to deliver DHCP > [...] > functionality as described in in [RFC8415]. > [Carlos] Thanks! Fixed in future version -09. > > Section 2: s/it can be/if it can be/ ? > quadrant might be different. For example, it can be managed, this > [Carlos] Thanks! Fixed in future version -09. Thanks a lot! Carlos --000000000000fe426c05a6a4163a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Tatuya,

Thanks a = lot again for your comments. Please see inline below some comments and resp= onses from my side.

On Mon, May 18, 2020 at 10:41 PM Tatuya Jinmei via= Datatracker <noreply@ietf.org&g= t; wrote:
Review= er: Tatuya Jinmei
Review result: Ready with Issues

I am an assigned INT directorate reviewer for
draft-ietf-dhc-slap-quadrant. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with
any other Last Call comments that have been received. For more details
on the INT Directorate, see https://datatracker.ietf= .org/group/intdir/about/

This draft defines a new DHCPv6 option that is supposed to be used
with draft-ietf-dhc-mac-assign.=C2=A0 The new option makes it possible for<= br> a client to specify its preferred "type" (SLAP) of MAC addresses = to be
assigned and for the server to make the assignment decision based on
the preference.

The draft is generally well written.=C2=A0 I think it's basically ready= ,
but there are several points not very clear to me.=C2=A0 I guess these are<= br> largely editorial glitches or simply due to my lack of understanding of
the background rather than substantial technical issues.=C2=A0 As a reader<= br> I'd feel happy if my questions are clarified, but I'd leave these t= o
authors.

Specific comments:

- Section 4.1-3
=C2=A0 =C2=A0 =C2=A0 =C2=A0[...]=C2=A0 The client SHOULD NOT pick a server = that does not
=C2=A0 =C2=A0 =C2=A0 =C2=A0advertise an address in the requested quadrant.<= br>
Does this mean if a client follows this "SHOULD NOT" and receives=
Advertise messages from servers that don't understand the new QUAD
option, then the client can't choose any server?=C2=A0 If so, is it oka= y?

[Carlos] Yes, in that case the expec= ted behaviour would be that the client does not choose any server. This is = basically the same that happens with other DHCP extensions. In any case, th= e text you referred to above was more to describe what the client should do= if the server supports the QUAD option, but still does not have addresses = available from the selected quadrant.


- Section 4.1:
=C2=A0 =C2=A05.=C2=A0 When the assigned addresses are about to expire, the = client sends
=C2=A0 =C2=A0 =C2=A0 =C2=A0a Renew message.=C2=A0 It includes the preferred= SLAP quadrant(s) in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the new QUAD IA_LL-option, so in case the server= is unable to
=C2=A0 =C2=A0 =C2=A0 =C2=A0extend the lifetime on the existing address(es),= the preferred
=C2=A0 =C2=A0 =C2=A0 =C2=A0quadrants are known for the allocation of any &q= uot;new" addresses.

It's not clear to me what 'the preferred quadrants are known for th= e
allocation of any "new" addresses' means.=C2=A0 Does this mea= n the server
will assign a new address from the specified quadrant(s) in response
to the Renew in this situation?

[Carlos= ] Yes. If the currently assigned addresses cannot be renewed, then the serv= er will try to allocate=C2=A0different (that's what "new" mea= ns) addresses from the same quadrant. We have added "different" t= o the text in version -09 to make this clearer.


- Section 4.2-3
The preference between client's supplied QUAD and relay supplied QUAD (or whether it matters) isn't clear to me.=C2=A0 =C2=A0What if these ar= e
inconsistent?=C2=A0 Perhaps this paragraph at the end of Section 4.2
answers the question?

=C2=A0 =C2=A0The server SHOULD implement a configuration parameter to deal<= br> =C2=A0 =C2=A0with the case where the client's DHCP message contains an = instance of
=C2=A0 =C2=A0OPTION_SLAP_QUAD, and the relay adds a second instance in its = relay-
=C2=A0 =C2=A0forward message.=C2=A0 [...]

If so, it might be more reader friendly if 4.2-3 gives a forward
reference to this consideration.=C2=A0 Also, this paragraph seems to
suggest the server may (only) process the relay's instance of the QUAD<= br> option.=C2=A0 If so, and it's incompatible with the client's option= , then I
guess the same question as Section 4.1-3 applies here.

[Carlos] That's a good point. When we wrote this we tho= ught that the sentence "Depending on the server's policy, the inst= ance(s) of the option to process is selected." in 4.2-3 would be suffi= cient as a reference for what comes at the end of Section 4.2 (which is ind= eed the answer to your point). I think adding a more explicit reference wou= ld make the text unnecessary long. What do you think?

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
- Section 5.1

=C2=A0 =C2=A0[...]=C2=A0 Note that a quadrant - preference tuple is
=C2=A0 =C2=A0used in this option (instead of using a list of quadrants orde= red by
=C2=A0 =C2=A0preference) to support the case whereby a client really has no=
=C2=A0 =C2=A0preference between two or three quadrants, leaving the decisio= n to
=C2=A0 =C2=A0the server.

What does "a quadrant - preference tuple is used in this option" = mean?
>From the context I guess it tries to talk about using the same
preference for multiple quadrants, but the actual text doesn't really read that way to me...

[Carlos] It mean= s that the option includes pairs (tuples) of quadrant-n & pref-n. Would= it be clearer if we use "pair" instead of tuple?

<= /div>

- Section 5.1

=C2=A0 =C2=A0[...]=C2=A0 If the server can provide an assignment from one o= f the
=C2=A0 =C2=A0specified quadrants, it SHOULD proceed with the assignment.=C2= =A0 If the
=C2=A0 =C2=A0server cannot provide an assignment from one of the specified<= br> =C2=A0 =C2=A0quadrant-n fields, it MUST NOT assign any addresses and return= a
=C2=A0 =C2=A0status of NoQuadAvail (IANA-2) in the IA_LL Option.

The first and second sentece seem to contradict each other.=C2=A0 If, for example, two quadrants Q1 and Q2 are specified and the server can only
provide an assignment for Q1, what should it do?=C2=A0 The first sentence seems to say the server should proceed with the assignemtn for Q1; the
second sentence seems to say the server MUST NOT assign any address
and simply return NoQuadAvail.

BTW, the second sentence also seems to contradict Section 4.1?=C2=A0 4.1-2 = states:

=C2=A0 =C2=A0 =C2=A0 =C2=A0[...] If
=C2=A0 =C2=A0 =C2=A0 =C2=A0the client specified more than one SLAP quadrant= , the server MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0only return a NoQuadAvail status code if no addr= ess pool(s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0configured at the server match any of the specif= ied SLAP
=C2=A0 =C2=A0 =C2=A0 =C2=A0quadrants.

[Carlos] Maybe is an English issue here (note that I&= #39;m not a native speaker). What we mean is that if the server does not ha= ve at least addresses from one of the specified quadrants, it must not assi= gn any. So if Q1 and Q2 are requested, and the server has only addresses fr= om Q1, this is fine and it should proceed with the assignment for Q1. Only = if the server does not have addresses from neither Q1 or Q2 it should retur= n NoQuadAvail.
=C2=A0
Nits
Section 2: s/in in/in/
=C2=A0 =C2=A0relay=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A node that acts as an = intermediary to deliver DHCP
[...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0functionality= as described in in [RFC8415].

[Carlos]= Thanks! Fixed in future version -09.

Section 2: s/it can be/if it can be/ ?
=C2=A0 =C2=A0 =C2=A0 quadrant might be different.=C2=A0 For example, it can= be managed, this

[Carlos] Thanks! Fixe= d in future version -09.=C2=A0

Thanks a lot!
=

Carlos
--000000000000fe426c05a6a4163a-- From nobody Fri May 29 09:49:42 2020 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B9B3A0DB6; Fri, 29 May 2020 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 4HYMaNZ5JfbC; Fri, 29 May 2020 09:49:34 -0700 (PDT) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 2652B3A0DB3; Fri, 29 May 2020 09:49:34 -0700 (PDT) Received: by mail-wm1-f54.google.com with SMTP id f5so4386618wmh.2; Fri, 29 May 2020 09:49:34 -0700 (PDT) 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=fhi05wWt9C7aA9RQd1HVdCws1DRfsT2f7Hw/25/thBQ=; b=IZs3QLXKivXVcDsO3FWqEUeWQA3C0yVSRN267dg9z0+U7Cx7VvwKDfvFwovC330tDS QPI6CgjM9UM7kF/7sg1AZkFhUsyfXgIJwQ5vgZNLVdoM+PjXaTg80kc8hgANIKadLIdP zhHT2RjqUO/Oufk+f/YSPp3Z5/4LZAtE9cVTqts+RNS3t0KfceqFxBigx4HAWrUEuH+A LWeB+j0EBArWbjxOiH2NwuzovLkC14N20ghvBolGmREd346NQt1zcSi1LpPZ07o1Sjca PgpeAKfiEagmb7SdpNyyVMmjM9EinEGe+HO9PRdg2QgvxN7eJKDxag5Woj3r3Qwm/yqU lFCA== X-Gm-Message-State: AOAM530WTUP8zU9TqqN8e3CAyQzq1QqPyIRAU+PmbRsuewbgNHDTOwor tVO0wKIZkNPHtBCYBqxlpFjf6NdsOGynGSplsY7D9WW2 X-Google-Smtp-Source: ABdhPJyr5xiMysMrilVP0kulHHpLtMohfHEc7Mz2uXKAak+YZFgiAjwXPuOguaDja3PzaMF+BA1XsppsGuh7bEtK0zU= X-Received: by 2002:a1c:65c2:: with SMTP id z185mr8996403wmb.125.1590770972363; Fri, 29 May 2020 09:49:32 -0700 (PDT) MIME-Version: 1.0 References: <158983448603.3400.6838657620034200956@ietfa.amsl.com> In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 29 May 2020 09:49:21 -0700 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: dhcwg , last-call@ietf.org, draft-ietf-dhc-slap-quadrant.all@ietf.org, "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-dir] [dhcwg] Intdir last call review of draft-ietf-dhc-slap-quadrant-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 16:49:37 -0000 At Wed, 27 May 2020 18:55:57 +0200, CARLOS JESUS BERNARDOS CANO wrote: > > Specific comments: > > > > - Section 4.1-3 > > [...] The client SHOULD NOT pick a server that does not > > advertise an address in the requested quadrant. > > > > Does this mean if a client follows this "SHOULD NOT" and receives > > Advertise messages from servers that don't understand the new QUAD > > option, then the client can't choose any server? If so, is it okay? > > [Carlos] Yes, in that case the expected behaviour would be that the client > does not choose any server. This is basically the same that happens with > other DHCP extensions. In any case, the text you referred to above was more > to describe what the client should do if the server supports the QUAD > option, but still does not have addresses available from the selected > quadrant. I understand that (what this text is about). My question was about the compatibility with legacy servers and newer clients. I don't know of other similar cases in DHCP(v6) extensions, but in any case if breaking the compatibility is the intent, I don't oppose that. I just wanted to make sure if it's intentional. > > - Section 4.1: > > 5. When the assigned addresses are about to expire, the client sends > > a Renew message. It includes the preferred SLAP quadrant(s) in > > the new QUAD IA_LL-option, so in case the server is unable to > > extend the lifetime on the existing address(es), the preferred > > quadrants are known for the allocation of any "new" addresses. > > > > It's not clear to me what 'the preferred quadrants are known for the > > allocation of any "new" addresses' means. Does this mean the server > > will assign a new address from the specified quadrant(s) in response > > to the Renew in this situation? > > [Carlos] Yes. If the currently assigned addresses cannot be renewed, then > the server will try to allocate different (that's what "new" means) > addresses from the same quadrant. We have added "different" to the text in > version -09 to make this clearer. Hmm, isn't it different from what the server would do with Renew for other types of IAs? (Assuming that's correct) being different itself isn't necessarily wrong, but in that case I'd like to see an explanation on why it differs. BTW, "what 'new' means" isn't an issue for me, so the change in 09 doesn't affect my point. > > - Section 4.2-3 > > The preference between client's supplied QUAD and relay supplied QUAD > > (or whether it matters) isn't clear to me. What if these are > > inconsistent? Perhaps this paragraph at the end of Section 4.2 > > answers the question? > > > > The server SHOULD implement a configuration parameter to deal > > with the case where the client's DHCP message contains an instance of > > OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- > > forward message. [...] > > > > If so, it might be more reader friendly if 4.2-3 gives a forward > > reference to this consideration. Also, this paragraph seems to > > suggest the server may (only) process the relay's instance of the QUAD > > option. If so, and it's incompatible with the client's option, then I > > guess the same question as Section 4.1-3 applies here. > > [Carlos] That's a good point. When we wrote this we thought that the > sentence "Depending on the server's policy, the instance(s) of the option > to process is selected." in 4.2-3 would be sufficient as a reference for > what comes at the end of Section 4.2 (which is indeed the answer to your > point). I think adding a more explicit reference would make the text > unnecessary long. What do you think? I don't think it "unnecessarily long" to add a short forward reference like "see also at the end of this section" after "Depending on ...is selected", but these are all about readability, which is generally subjective. If you believe the current text is the best I don't oppose. > > - Section 5.1 > > > > [...] Note that a quadrant - preference tuple is > > used in this option (instead of using a list of quadrants ordered by > > preference) to support the case whereby a client really has no > > preference between two or three quadrants, leaving the decision to > > the server. > > > > What does "a quadrant - preference tuple is used in this option" mean? > > From the context I guess it tries to talk about using the same > > preference for multiple quadrants, but the actual text doesn't really > > read that way to me... > > [Carlos] It means that the option includes pairs (tuples) of quadrant-n & > pref-n. Would it be clearer if we use "pair" instead of tuple? Ah, I now see where my confusion comes from. On my first read I misunderstood that this entire text talks about some actual protocol behavior, but now I see the text after "Note that..." explains your design choice (correct?). Now that I (hopefully) understand it's difficult to suggest how to prevent the same kind of confusion, but I'd perhaps say, e.g. If the same preference value is used for more than one quadrant, the server MAY select which quadrant should be preferred (if the server can assign addresses from all or some of the quadrants with the same assigned preference). Note that this is not a simple list of quadrants ordered by preference without no preference value but a list of quadrants with explicit preference values. This way it can support the case whereby a client really has no preference between two or three quadrants, leaving the decision to the server. > > - Section 5.1 > > > > [...] If the server can provide an assignment from one of the > > specified quadrants, it SHOULD proceed with the assignment. If the > > server cannot provide an assignment from one of the specified > > quadrant-n fields, it MUST NOT assign any addresses and return a > > status of NoQuadAvail (IANA-2) in the IA_LL Option. > > > > The first and second sentece seem to contradict each other. If, for > > example, two quadrants Q1 and Q2 are specified and the server can only > > provide an assignment for Q1, what should it do? The first sentence > > seems to say the server should proceed with the assignemtn for Q1; the > > second sentence seems to say the server MUST NOT assign any address > > and simply return NoQuadAvail. > > > > BTW, the second sentence also seems to contradict Section 4.1? 4.1-2 > > states: > > > > [...] If > > the client specified more than one SLAP quadrant, the server MUST > > only return a NoQuadAvail status code if no address pool(s) > > configured at the server match any of the specified SLAP > > quadrants. > > > > [Carlos] Maybe is an English issue here (note that I'm not a native > speaker). What we mean is that if the server does not have at least > addresses from one of the specified quadrants, it must not assign any. So > if Q1 and Q2 are requested, and the server has only addresses from Q1, this > is fine and it should proceed with the assignment for Q1. Only if the > server does not have addresses from neither Q1 or Q2 it should return > NoQuadAvail. Okay, in that case I'd change > > server cannot provide an assignment from one of the specified to > > server cannot provide an assignment from any of the specified i.e., "one" to "any". At least to me this will make the two sentences clearly consistent. BTW I'm not a native English speaker either, so it's quite possible that it's due to my poor reading of English text:-) -- JINMEI, Tatuya