Re: [dhcwg] Updates on draft-ietf-dhc-slap-quadrant

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Fri, 09 October 2020 20:45 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE813A1558 for <dhcwg@ietfa.amsl.com>; Fri, 9 Oct 2020 13:45:19 -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, HTML_MESSAGE=0.001, 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=bkxDC56O; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xsno+Pcw
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 ePdj25xHgXLT for <dhcwg@ietfa.amsl.com>; Fri, 9 Oct 2020 13:45:15 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E77F3A1551 for <dhcwg@ietf.org>; Fri, 9 Oct 2020 13:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39735; q=dns/txt; s=iport; t=1602276315; x=1603485915; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dz7D11EP91tNREDGzKtDLQMMTnebfdVl0WyBQPzUm2o=; b=bkxDC56OypB/bE52vu7sWhCn2cAV1YwZ/9lI5THEWwgjI9SdLqA0m5mv NppR/eXn0TjvOuAD9u6RmRzeKirqPWMxs6rq8fKljGeq8lLNFWVZ7PG+r BBYLNZR9C/ZYKcX7MtHA1+YDIzmSKLnaY8srhToHq5LqzhMb4T5Yz3KwE c=;
IronPort-PHdr: =?us-ascii?q?9a23=3A7M/ODxPI0ZnyDUX5FkIl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwz3lLVXYza8bRChvaF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGFdr+blzI5Hu/8W1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrBQC5yoBf/51dJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BIwEuKSgHcFkvLAqHeQONUZh7gUKBEQNVCwEBAQ0BASM?= =?us-ascii?q?KAgQBAYRKAoITAiU4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDEggmAQE?= =?us-ascii?q?3AQ8CAQgRAwEBASEBBgcyFAkIAgQBDQUIGoMFgX5NAy4BAwueNQKBOYhhdIE?= =?us-ascii?q?0gwEBAQWBNwKDZBiCEAMGgTiCcopDG4FBP4EQAUOBT34+glwBAQOBQgIaBRk?= =?us-ascii?q?GBwmDFIItkwmHQYwAkRQKgmiJAIZaQYpugxOKCJQbkxyBeoh2lTECBAIEBQI?= =?us-ascii?q?OAQEFgWsjgVdwFTuCaVAXAg2OHwwXgQIBCAGCQoUUhUJ0NwIGAQkBAQMJfIw?= =?us-ascii?q?7AYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.77,356,1596499200"; d="scan'208,217";a="571979583"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2020 20:45:14 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 099KjDFR028553 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2020 20:45:14 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 15:45:13 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 16:45:12 -0400
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 9 Oct 2020 16:45:12 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MtIzvzuiK4XdMee8qDZOzvgKUFvfdK3tkJjWRGf5lfWvrtiwwFLy4s6wNzJi2tj8wj6/9XVNXknPEJlsZf1EChjAMFfUUpWxE5OvuWAgAol137704RTb++Cz+AQ5a6bu99w/0yvRay+ID8+OLQWNJyOmDe5xCdpXcRmvIDMdlGgGNXAOKSCDxSN61ynXtCR4KClZgHhAwQSpCiP3s0PY1Z64NLO/lyMR1WqR4qx/PxKvE/JCf1SbGvjspAI1DWWdPFc/A/9kxZtcg8vWJSLhVaoQAJE5ey/fRQVAPaFq2vVDsaBWLtn9KF18SsveXBer2zCC0qZLOGSxPiZoprMJuA==
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=w5nl452m7/icIjtYbyNqN5tR7oY3ojSrAk89I8rNYaI=; b=WlLTxh0Mj/CHvkVSposGb6IBooXvIQEzygww2+sFWCdD9JW+YV/LjX6YsdKmb3GUrdNpGkdy6yaYFtaSNNiTdQGzEJbU785f3UGA6S7dCq/gD7fFAIsQjrVcPmb4BdNVH4ANjlMXyyXlqrCSk8i+GMxnBkL0Amic8CgtO77gJbA62w4vtSz8ZzIAeDkdsEwz1XpQAIy80FmsZzWhNQUjvhskiJ5fzVP8mlGNwxrWwMyIWVmlOWj+yTE0fX8fTHWdSM4PaVf6cL9hcpRbMMfM2oTdFTr5yrClimsoNUzMt+cLk8CgMt4x2LEOmLg9q3Bw5rrPNv0RiyU6cZkJmpRNSg==
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=w5nl452m7/icIjtYbyNqN5tR7oY3ojSrAk89I8rNYaI=; b=xsno+PcwXvo7bqOQMJMU+PeBBZuPVrTMvqScwZHz2PcffkElMJEwn1xCElfDEfUaU/oFeyQ5v/vMX472kalpJMAQv0N+jmFt6mu0suRJJKy7zPQo7SFZWWps9vpjAdIiM8IkcEunb5Uc019J+uhzoCY5no7ze8VCMnFR4X4flpY=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4981.namprd11.prod.outlook.com (2603:10b6:510:39::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Fri, 9 Oct 2020 20:45:09 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d%7]) with mapi id 15.20.3455.023; Fri, 9 Oct 2020 20:45:09 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Roger Marks <roger@ethair.net>, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
CC: ROBERT GROW <bobgrow@cox.net>, Glenn Parsons <glenn.parsons@ericsson.com>, "Stanley, Dorothy" <dorothy.stanley@hpe.com>, "Bernie Volz (volz)" <volz@cisco.com>, ANTONIO DE LA OLIVA DELGADO <aoliva@it.uc3m.es>, dhcwg <dhcwg@ietf.org>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, Timothy Winters <tim@qacafe.com>, "Mourad, Alain" <Alain.Mourad@interdigital.com>
Thread-Topic: Updates on draft-ietf-dhc-slap-quadrant
Thread-Index: AQHWnlKOT7lj4fhKK0SwnLGfmQy5zamPqpsAgAAOMQCAAARaqw==
Date: Fri, 9 Oct 2020 20:45:09 +0000
Message-ID: <PH0PR11MB496645C2767E02ACCDB02E84A9080@PH0PR11MB4966.namprd11.prod.outlook.com>
References: <CALypLp8TdmF2kuQdRpGnVOzAT78E4ZOXp4_yB5zUCGePKeHU2Q@mail.gmail.com> <8487530A-73F6-46E9-A34F-D78497A39942@cisco.com> <dbca04d3-468a-4d37-8864-d8daaadce89e@Spark> <CALypLp9v4WN+ge30hZWvDnxVDkYs7nG=cRM5u1OnRUVMdPmuuQ@mail.gmail.com> <065A9F41-1BF3-45E2-A572-95491D308BD9@cisco.com> <50889a45-d627-4304-98d6-9d98424b7e39@Spark>, <CALypLp_foQj-vq_tKmaTrQHK5c4L82ctWCTQ=r+LsEMw0uNcnQ@mail.gmail.com>
In-Reply-To: <CALypLp_foQj-vq_tKmaTrQHK5c4L82ctWCTQ=r+LsEMw0uNcnQ@mail.gmail.com>
Accept-Language: fr-BE, en-US
Content-Language: fr-BE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ethair.net; dkim=none (message not signed) header.d=none;ethair.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [85.234.200.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3a38980a-385b-4a00-2cb5-08d86c943653
x-ms-traffictypediagnostic: PH0PR11MB4981:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <PH0PR11MB4981C375821C1193B707FD78A9080@PH0PR11MB4981.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: r4D+qPnCBWScpqcDPNWGniFB5cOfOHN5l6Gk+6DCww1xfYf2DijSI6jy0ac/A6GypIHyrVb4Jif7Izu8VKYy0xrUxRXf8DjmrYlC0PNqr6SpUNgNkbFz9wQX07+lTRMV0HeA9pyo5nKAEIRffoZIo5wsVkyMmwAMtqtVEEF2xYOYlrYvd4whliHvWaPvAP1YZdzvoqUzXvBopCoOh+wgsVnzYkAGKVtKofipR+B5bAch+Rk08R1LZqOeHR+5nhiWvx+aadAQc8KLzTv6Ha4fhrkwFXl/Th1tiDxXCFK2R5VLTIxCbZhcE0PAKCJRZn4GD+hPqdATzzs/VSz+7n4oAeywvTim4Lny8b1oRPtuu6TW3AIXZCXm3qTm+ERT1i5pbAnaTK7LYo1qIP0hQldqUg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(39860400002)(376002)(366004)(346002)(166002)(966005)(83380400001)(76116006)(55016002)(6506007)(66556008)(71200400001)(30864003)(53546011)(91956017)(52536014)(26005)(186003)(2906002)(5660300002)(9686003)(64756008)(33656002)(54906003)(66946007)(66574015)(316002)(66476007)(4326008)(478600001)(83080400001)(7696005)(15650500001)(8676002)(66446008)(110136005)(8936002)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: yGFc8nypaLXQYJgNSZxNl5nnfet5uJrY2P/auvXkjU3lA+EvRzn1VNkzi77dgHh826bJ/w9JGqigvG4gIS6Xbjg803ZpVE4PwJZcJ5cFNLGojo377+rjnNZo82Yb2W0r8cu5FZ++EWSmX0gSqLJe+ADA7LJ2SuYdE3BX2upQZTiAK81++j8X7B2QkYvMBFMYwjBmTKVmgKoT2qelbn5JFi0bUhlEkI+P3YimzAjXa+Tbe/hgD6wkOC2GgfVuKpg/zinEJAibhSV+XgImUL2F8U4fisyW1T9m+DmQEJjdYqY8iQGQ437Zb6fPAXNmJeZ6P+j8PNJEsJkEQvruQhYuBN6nsGhElWvHYqYYtRVYC0rR5C470Z+Cqu4IDv0fallrkEPvshz2Kg7+Gi4pUrUhvYIE20xsuTIyLq31inikcyKme3+hY5C35mx+h+20uzY6xVTsH6muq//i/P38XV+owV7IJxLtyCHRd6gTUzbbIKUYMsvZtK0WxWNCMk6/4t6x+fU+Snf0kNinCzaOmN0KlT7n+pCbtM3gclE7n4CfRlcomWG4CPw1EhdVTLEYbfFkHUobxgM7yNUG+pSXyt8K76hBF/z2bAii8pMHm6vSCVSxfvMt4+QBGoR+/hU/Xoqj17cP599Cg+IGT12a8S5DkQ==
Content-Type: multipart/alternative; boundary="_000_PH0PR11MB496645C2767E02ACCDB02E84A9080PH0PR11MB4966namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a38980a-385b-4a00-2cb5-08d86c943653
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 20:45:09.4001 (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: kdnU1Y0l0sYzCgpVTVMgInJYthAZfr9pW/x+IeVu5uF43W5gNn7NfpwG+ilrXxexNVIkgMLsgAnNLVhQGhEHVg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4981
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/vodipWO6Gky1VPBJOeIPj7fNpLs>
X-Mailman-Approved-At: Fri, 09 Oct 2020 13:46:37 -0700
Subject: Re: [dhcwg] Updates on draft-ietf-dhc-slap-quadrant
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2020 20:45:20 -0000

Indeed, thank you Roger for the first quick first review and this reply

Eric
________________________________
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Sent: Friday, October 9, 2020 10:28:18 PM
To: Roger Marks <roger@ethair.net>
Cc: Eric Vyncke (evyncke) <evyncke@cisco.com>om>; ROBERT GROW <bobgrow@cox.net>et>; Glenn Parsons <glenn.parsons@ericsson.com>om>; Stanley, Dorothy <dorothy.stanley@hpe.com>om>; Bernie Volz (volz) <volz@cisco.com>om>; ANTONIO DE LA OLIVA DELGADO <aoliva@it.uc3m.es>es>; dhcwg <dhcwg@ietf.org>rg>; Rob Wilton (rwilton) <rwilton@cisco.com>om>; Timothy Winters <tim@qacafe.com>om>; Mourad, Alain <Alain.Mourad@interdigital.com>
Subject: Re: Updates on draft-ietf-dhc-slap-quadrant

Thanks a lot Roger for all the help.

Kind regards,

Carlos

On Fri, Oct 9, 2020 at 9:38 PM Roger Marks <roger@ethair.net<mailto:roger@ethair.net>> wrote:
Carlos,

Thanks for the response.

Personally, I believe that the changes you indicated (from OLD to NEW, and the clause suggested by Bernie), would address the concerns I raised.

Thanks for taking the time to consider my concerns.

Cheers,

Roger
On Oct 9, 2020, 9:41 AM -0600, "Eric Vyncke (evyncke)" <evyncke@cisco.com<mailto:evyncke@cisco.com>>, wrote:

Roger, Robert, Glenn, Dorothy,



Sorry for being pushy again but what do you think about Carlos’ proposed text ? (and thank you again for spotting an ambiguity in the IETF draft)



I would really like to get a reply from you before approving this IETF document



Regards



-éric





From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es<mailto:cjbc@it.uc3m.es>>
Date: Tuesday, 6 October 2020 at 22:07
To: Roger Marks <roger@ethair.net<mailto:roger@ethair.net>>
Cc: ROBERT GROW <bobgrow@cox.net<mailto:bobgrow@cox.net>>, Glenn Parsons <glenn.parsons@ericsson.com<mailto:glenn.parsons@ericsson.com>>, "Stanley, Dorothy" <dorothy.stanley@hpe.com<mailto:dorothy.stanley@hpe.com>>, Eric Vyncke <evyncke@cisco.com<mailto:evyncke@cisco.com>>, "Bernie Volz (volz)" <volz@cisco.com<mailto:volz@cisco.com>>, ANTONIO DE LA OLIVA DELGADO <aoliva@it.uc3m.es<mailto:aoliva@it.uc3m.es>>, dhcwg <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>, "Rob Wilton (rwilton)" <rwilton@cisco.com<mailto:rwilton@cisco.com>>, Timothy Winters <tim@qacafe.com<mailto:tim@qacafe.com>>, "Mourad, Alain" <Alain.Mourad@interdigital.com<mailto:Alain.Mourad@interdigital.com>>
Subject: Re: Updates on draft-ietf-dhc-slap-quadrant



Hi Roger,



Thanks again for your feedback. Please see inline below.



On Fri, Oct 2, 2020 at 11:37 PM Roger Marks <roger@ethair.net<mailto:roger@ethair.net>> wrote:

Carlos and éric,

Since many of the core technical comments were not implemented, I personally still think that the draft is still not effective.  I'll just reiterate that the following remain puzzling to me:

(1) Why a client needs to request a specific quadrant of the local MAC address space, via Solicit (i.e., I don't understand the problem statement).



 [Carlos] The mechanism is intended to allow a client (or relay) indicate a preference for obtaining addresses from a specific quadrant. There are some examples of scenarios where this might be relevant described in the document, but there might be others that appear in the future as well.



(2) Why a server is prohibited from offering, in the Advertise, an address outside the requested quadrant.



[Carlos] This part of the DHCP dialogue (Solicit-Advertise) is meant for the client to select the best DHCP server to meet its needs (i.e., indicated preference). What do you think about the following modification to address your suggestion?

OLD:
   2.  The server, upon receiving an IA_LL option in Solicit, inspects
       its contents.  For each of the entries in OPTION_SLAP_QUAD, in
       order of the preference field (highest to lowest), the server
       checks if it has a configured MAC address pool matching the
       requested quadrant identifier, and an available range of
       addresses of the requested size.  If suitable addresses are
       found, the server sends back an Advertise message with an IA_LL
       option containing an LLADDR option that specifies the addresses
       being offered.  If the server supports the new QUAD IA_LL-option,
       and manages a block of addresses belonging to a requested
       quadrant, the addresses being offered MUST belong to a requested
       quadrant.  If the server does not have a configured address pool
       matching the client's request, it MUST return the IA_LL option
       containing a Status Code option with status set to NoQuadAvail
       (IANA-2).  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.  If the server has a configured address
       pool of the correct quadrant, but no available addresses, it MUST
       return the IA_LL option containing a Status Code option with
       status set to NoAddrsAvail.

NEW:
   2.  The server, upon receiving an IA_LL option in Solicit, inspects
       its contents.  For each of the entries in OPTION_SLAP_QUAD, in
       order of the preference field (highest to lowest), the server
       checks if it has a configured MAC address pool matching the
       requested quadrant identifier, and an available range of
       addresses of the requested size.  If suitable addresses are
       found, the server sends back an Advertise message with an IA_LL
       option containing an LLADDR option that specifies the addresses
       being offered.  If the server manages a block of addresses belonging
       to a requested quadrant, the addresses being offered MUST belong
       to a requested quadrant.  If the server does not have a configured
       address pool matching the client's request, it SHOULD return the
       IA_LL option with the addresses being offered belonging to a
       quadrant managed by the server (following a local policy to select
       from which of the available quadrants). If the server has a configured
       address pool of the correct quadrant, but no available addresses, it
       MUST return the IA_LL option containing a Status Code option with
       status set to NoAddrsAvail.

The client-relay-server part of the spec would also be changed to reflect the same update. Besides, the following clause suggested by Bernie (thanks a lot!) would be added, with some minor modifications to ensure the wording matches the rest of the text in the section:

      For cases where a server may not be configured to have pools for the
      client or relay QUAD preferences, clients and relays SHOULD specify
      all quadrants in the preferences to assure the client gets an address
      (or addresses) -- if any are available. Specifying all quadrants also
      results in a quad option supporting server responding like a non-quad
      option supporting server, i.e., an address (or addresses) from any
      available quadrant can be returned.



(3) Given (2), why the server that cannot meet the demand does not provide, in the Advertise, the list of quadrants in which it does have available addresses.



[Carlos] If we go for the proposed change above, this would not apply.

In any case, I want to provide an explanation why this was not possible with the current text (if we do not add the change proposed above). This is because the way DHCP address allocation works (as described in draft-ietf-dhc-mac-assign for MAC addresses). The server includes in the Advertise the actual address(es) being offered, not the list of quadrants that it has available. This is due to the way DHCP works, and therefore cannot be changed. In any case, the client may send a different Solicit with more SLAP quadrants, to see/learn which ones are supported by available servers.



(4) Given (2), why the client can nevertheless (though it SHOULD NOT) Request an address in a quadrant that was not Advertised, and,



[Carlos] Again, this might not apply if we adopt the proposed change. But, let me provide an explanation of why the spec was originally written as it is, below.

IETF protocols make use of normative capitalized words (like "SHOULD NOT") in very specific ways, described in RFCs 2119 and 8174. According to RFCs 2119 and 8174, "SHOULD NOT" indicates that "there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label". Therefore, there might be scenarios, carefully weighed, where a client requesting a quadrant that was not advertised, might make sense, and we leave the specification so this can be supported, instead of using "MUST NOT" which would totally prohibit that.



(5) Given (4), why the server can nevertheless grant that request, though it was prohibited [per (2)] from admitting that it could do so.



[Carlos] Note that the server would not have addresses from the indicated quadrant in this case (otherwise it would have indicated that in the Advertise message), and therefore it will never allocate addresses from this quadrant. But the server is allowed to allocate address(es) from a different quadrant (based on local server policies). And then the client may decide to use it anyway.

But in any case, this would not apply either.



Thanks one more time.



Carlos



I understand that the editors decided not to make changes in response to the relevant prior comments because the content had already been "extensively reviewed and approved by the DHC WG and the IETF and represent therefore the IETF consensus." However, that explanation doesn't provide me with an understanding of the technical rationale, so I remain puzzled.

Please understand that these comments are from me only, not from IEEE.



Cheers,



Roger

On Oct 1, 2020, 1:11 AM -0600, "Eric Vyncke (evyncke)" <evyncke@cisco.com<mailto:evyncke@cisco.com>>, wrote:


Roger, Robert, Glenn, and Dorothy,



As the IETF would like to move forward with the publication of this document, may I kindly ask you to quickly review the changes ?



My intent, as responsible Area Director for the DHC WG, is to approve and publish it in a week, Thursday 8th of October, if there is no blocking issues from the IEEE.



Thank you in advance,



Regards



-éric



From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es<mailto:cjbc@it.uc3m.es>>
Date: Thursday, 1 October 2020 at 08:51
To: Roger Marks <roger@ethair.net<mailto:roger@ethair.net>>
Cc: ROBERT GROW <bobgrow@cox.net<mailto:bobgrow@cox.net>>, Glenn Parsons <glenn.parsons@ericsson.com<mailto:glenn.parsons@ericsson.com>>, "Bernie Volz (volz)" <volz@cisco.com<mailto:volz@cisco.com>>, ANTONIO DE LA OLIVA DELGADO <aoliva@it.uc3m.es<mailto:aoliva@it.uc3m.es>>, Eric Vyncke <evyncke@cisco.com<mailto:evyncke@cisco.com>>, "Stanley, Dorothy" <dorothy.stanley@hpe.com<mailto:dorothy.stanley@hpe.com>>, dhcwg <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>, "Rob Wilton (rwilton)" <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Subject: Updates on draft-ietf-dhc-slap-quadrant



Hi Roger, all,



Thanks again for the comments on the draft. I did try to incorporate most of your comments. For the sake of completeness, I'm just summarizing below the changes I made on the draft:



- I applied basically all the suggested edits (on abstract, introduction and terminology sections).

- I made some minor changes to improve the motivation of the problem statement, but note that this was extensively reviewed by the DHC WG. I've modified the text regarding the IoT scenario to better explain the motivation (section 1.1.1). I've also reformulated the text in section 1.1.2 to better explain the rationale behind the recommendations for SLAP quadrant preferences in datacenter scenarios.

- As suggested, I removed the section on Quadrant Selection Mechanisms examples (and put it in an annex).

- I did check all your comments regarding the DHCPv6 extensions section (old section 4, now section 3). This part has been extensively reviewed and approved by the DHC WG and the IETF and represent therefore the IETF consensus. Since it refers to points related to the way the DHCPv6 protocol works, we, the editors of the DHC WG document, do not intend to apply some of your comments.

- I added all the suggested references and made the suggested corrections.



Note that most of the comments were addressed in draft-ietf-dhc-slap-quadrant-10 (posted early August), but I've just posted draft-ietf-dhc-slap-quadrant-11 [1] with some additional changes and small corrections.



Thanks much for providing the comments and feedback on the draft.



Kind regards,



Carlos



[1] https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-11