Subject: [Last-Call] Genart last call review of draft-ietf-dhc-mac-assign-06

From: Roni Even via Datatracker <[email-masked]>
Date: Mon, 11 May 2020 23:50:19 -0700

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.

---

From: "Ms. Li HUANG" <[email-masked]>
Date: Sat, 16 May 2020 16:33:30 +0800

that is making sense to clients under isp,  DNS, mail, dhcpv6 and,     ...
dhcpv4 ranges domains crazily being used widely , none a little tendency to
stop at the may 2020 when ietf.org claimed THE IPV6 ONLY at the day, it is
may 15 2020.

would the IPv6.Only is auto, forced , willing way or else may please let
know ?

Sincerely
Li HUANG

On Tue, May 12, 2020, 14:50 Roni Even via Datatracker <[email-masked]>
wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 26 May 2020 21:09:59 +0000

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 <[email-masked]> 
Sent: Tuesday, May 12, 2020 2:50 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Genart last call review of draft-ietf-dhc-mac-assign-06

Reviewer: Roni Even

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.

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.

---

From: "Roni Even" <[email-masked]>
Date: Wed, 27 May 2020 14:29:42 +0300

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

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2020 12:10 AM
> To: Roni Even; [email-masked]
> Subject: RE: Genart last call review of draft-ietf-dhc-mac-assign-06
> 
> Hi Roni:
> 
> 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
> 
> 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.
>