Re: [dhcwg] Genart last call review of draft-ietf-dhc-mac-assign-06

Roni Even <ron.even.tlv@gmail.com> Wed, 27 May 2020 11:29 UTC

Return-Path: <ron.even.tlv@gmail.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 5C6D73A0DA8; Wed, 27 May 2020 04:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkEdM8c26oPc; Wed, 27 May 2020 04:29:48 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 8FE603A0DA7; Wed, 27 May 2020 04:29:48 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id u13so2724188wml.1; Wed, 27 May 2020 04:29:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=KaNRXbWtiZuTFg79rW3jBkDlXl5KnTXJkL1k3b3wE4o=; b=aj5PRTYGCLLpYnPI+b/zS2wo74GZK13zsmQEtT8auY45LovQGXTZOKZH99Xa5OOYNU buxtvMx2KiOyiB9mig3GXK2qkEXeq9JPriYnuihqAE3WPEJGarz99UyfWKVd9ANPL75B Ubka+5l1XfRbKWfLRI24nSVtuBpEZtQUztWwCdl2YHWfoXJU6iOIvke/UTqLcijgqC1S ZyiRISM3OjqJ3IQJNfyFTRGnubOXzSolCUleUMejDPxnS0b69x0BMA6D3DSpxxgzSS3g puV5ulBuVZJA0DquXXnft9NfzN8oVatLI9KMWca4Xn6w1J5d9vvoOl24DmHEnqBQWFmI R9Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=KaNRXbWtiZuTFg79rW3jBkDlXl5KnTXJkL1k3b3wE4o=; b=az6QaGx8eno2TAwd/5C8vuYrRa1FZMxYlieoUEJrk6xhg6i+BIgz5W8p1ExAYLzjmQ Q8/gO9ucKMDEr5qRbR0VaByEQQSCp8qMOc8LIlqC8t1OfZy01LQeP7Qzx8YHI4wAsjid MIVXyuJalJ2L8QoVWsTBi7/YXKxSgTXAyx0aHBrjsA87KdMQ7NyPNG+8VGsgGZryfgbX bGxQW86+QAApEi39uiBECgBavlFm3Xwd/7mR3f1s2xYkbVS9M23cShszFi3HNEMA8Fo0 phUjCF58NzoDN1z+M48WdC+FLxeKatK5rmuK1YSSLo9hO96OrrU0NSr44yTyxfnSS3iO XITQ==
X-Gm-Message-State: AOAM531EnOa9F7JxWY+JKk/HbUixA9bzGOicJAIrHcbSvkFFoGgbXb8E XNiPTNkSBHlwcFNKuKimCzyQ/8vx
X-Google-Smtp-Source: ABdhPJx+AW4axai/p5pwA7wjO8zXv1i6AeikdCiiFKQycMbeNhTSUNB+BB4rJo41EyjRyaii9pq2fw==
X-Received: by 2002:a1c:7f96:: with SMTP id a144mr3819972wmd.176.1590578986018; Wed, 27 May 2020 04:29:46 -0700 (PDT)
Received: from RoniPC (bzq-79-182-11-163.red.bezeqint.net. [79.182.11.163]) by smtp.gmail.com with ESMTPSA id 89sm2636315wrj.37.2020.05.27.04.29.44 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Wed, 27 May 2020 04:29:44 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Bernie Volz \(volz\)'" <volz@cisco.com>, <gen-art@ietf.org>
Cc: <draft-ietf-dhc-mac-assign.all@ietf.org>, <last-call@ietf.org>, <dhcwg@ietf.org>
References: <158926621972.24137.14737405711720351698@ietfa.amsl.com> <BN7PR11MB2547B6ACBA53E051C8C770F6CFB00@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB2547B6ACBA53E051C8C770F6CFB00@BN7PR11MB2547.namprd11.prod.outlook.com>
Date: Wed, 27 May 2020 14:29:42 +0300
Message-ID: <0f3c01d6341a$1e287410$5a795c30$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNIKXfxz1w4F5F6uSI5YiPyJ0yHzQFhzQ2apczShgA=
Content-Language: he
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/-W7x-D_nVcDbIzh1ItUVeQr7bsI>
Subject: Re: [dhcwg] Genart last call review of draft-ietf-dhc-mac-assign-06
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: Wed, 27 May 2020 11:29:51 -0000

Hi,
Thanks, I am OK with you responses.
On the second point I was looking at a way to avoid fragmentations but I am OK with your response
Roni

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Wednesday, May 27, 2020 12:10 AM
> To: Roni Even; gen-art@ietf.org
> Cc: draft-ietf-dhc-mac-assign.all@ietf.org; last-call@ietf.org; dhcwg@ietf.org
> Subject: RE: Genart last call review of draft-ietf-dhc-mac-assign-06
> 
> Hi Roni:
> 
> Sorry for the late response to this review. Thanks for doing it!
> 
> >1. In the terminology section I was wondering why the client is a device while
> the server is a software. Any reason for this distinction.
> 
> I can easily replace both with "node" as that matches RFC8415:
> 
> So:
>      client        A device that is interested in obtaining link-layer
> ...
>    server        Software that manages link-layer address allocation and
> 
> Replace with:
>    client        A node that is interested in obtaining link-layer
> ...
>    server       A node that manages link-layer address allocation and
> 
> >2. The server can allocate a smaller size chunk and not the requested size. The
> allocation policy is up to the server. Should it be required from the server to
> allocate the largest chunk that is closer to the requested size.
> 
> I'm not sure that this would necessarily be the best thing to "require"? It would
> seem like the most obvious policy, but in the end it really shouldn't matter (i.e.,
> whether the client gets 10% or 90% of what if requested shouldn't matter)? If it
> needs more, it can send additional requests to get the remaining (in one or more
> additional requests). And, we generally leave this issues up to the server as
> policy.
> 
> 
> There was another review that raised some issues (see
> https://datatracker.ietf.org/doc/review-ietf-dhc-mac-assign-06-iotdir-lc-
> chakrabarti-2020-05-11/) and I had some follow up questions related to it. So,
> once those get addressed I will likely do an update.
> 
> - Bernie
> 
> -----Original Message-----
> From: Roni Even via Datatracker <noreply@ietf.org>
> Sent: Tuesday, May 12, 2020 2:50 AM
> To: gen-art@ietf.org
> Cc: draft-ietf-dhc-mac-assign.all@ietf.org; last-call@ietf.org; dhcwg@ietf.org
> Subject: Genart last call review of draft-ietf-dhc-mac-assign-06
> 
> Reviewer: Roni Even
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the
> IETF Chair.  Please treat these comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-dhc-mac-assign-??
> Reviewer: Roni Even
> Review Date: 2020-05-11
> IETF LC End Date: 2020-05-19
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is ready for publication as a standard track RFC with nits Major
> issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 1. In the terminology section I was wondering why the client is a device while
> the server is a software. Any reason for this distinction.
> 
> 2. The server can allocate a smaller size chunk and not the requested size. The
> allocation policy is up to the server. Should it be required from the server to
> allocate the largest chunk that is closer to the requested size.
> 
>