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@xxxxxxxxx] > Sent: Wednesday, May 27, 2020 12:10 AM > To: Roni Even; gen-art@xxxxxxxx > Cc: draft-ietf-dhc-mac-assign.all@xxxxxxxx; last-call@xxxxxxxx; dhcwg@xxxxxxxx > 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@xxxxxxxx> > Sent: Tuesday, May 12, 2020 2:50 AM > To: gen-art@xxxxxxxx > Cc: draft-ietf-dhc-mac-assign.all@xxxxxxxx; last-call@xxxxxxxx; dhcwg@xxxxxxxx > 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. > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
