Last Call Review of draft-ietf-dhc-mac-assign-06
review-ietf-dhc-mac-assign-06-genart-lc-even-2020-05-11-00
| Request | Review of | draft-ietf-dhc-mac-assign |
|---|---|---|
| Requested revision | No specific revision (document currently at 09) | |
| Type | Last Call Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2020-05-19 | |
| Requested | 2020-05-05 | |
| Authors | Bernie Volz , Tomek Mrugalski , Carlos J. Bernardos | |
| Draft last updated | 2020-05-11 | |
| Completed reviews |
Intdir Last Call review of -06
by
Tatuya Jinmei
(diff)
Iotdir Last Call review of -06 by Jaime Jimenez (diff) Iotdir Last Call review of -06 by Samita Chakrabarti (diff) Secdir Last Call review of -07 by Sean Turner (diff) Genart Last Call review of -06 by Roni Even (diff) Opsdir Last Call review of -06 by Tianran Zhou (diff) |
|
| Assignment | Reviewer | Roni Even |
| State | Completed | |
| Review |
review-ietf-dhc-mac-assign-06-genart-lc-even-2020-05-11
|
|
| Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/qgxXlaKO5Z7cXcYoesC57JSli7c | |
| Reviewed revision | 06 (document currently at 09) | |
| Result | Ready with Nits | |
| Completed | 2020-05-11 |
review-ietf-dhc-mac-assign-06-genart-lc-even-2020-05-11-00
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.