Last Call Review of draft-ietf-dots-robust-blocks-04
review-ietf-dots-robust-blocks-04-artart-lc-kyzivat-2022-09-13-00
Request | Review of | draft-ietf-dots-robust-blocks |
---|---|---|
Requested revision | No specific revision (document currently at 06) | |
Type | IETF Last Call Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2022-09-16 | |
Requested | 2022-09-02 | |
Authors | Mohamed Boucadair , Jon Shallow | |
I-D last updated | 2023-02-28 (Latest revision 2022-10-06) | |
Completed reviews |
Yangdoctors Early review of -01
by Michal Vaško
(diff)
Artart IETF Last Call review of -04 by Paul Kyzivat (diff) Genart IETF Last Call review of -05 by Tim Evens (diff) Intdir Telechat review of -05 by Jean-Michel Combes (diff) |
|
Assignment | Reviewer | Paul Kyzivat |
State | Completed | |
Request | IETF Last Call review on draft-ietf-dots-robust-blocks by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/5oE2uv4A4pHIQyC_7gOWE8_P3wE | |
Reviewed revision | 04 (document currently at 06) | |
Result | Ready w/nits | |
Completed | 2022-09-13 |
review-ietf-dots-robust-blocks-04-artart-lc-kyzivat-2022-09-13-00
Reviewer: Paul Kyzivat Review result: Ready with Nits I am the assigned ARTART reviewer for this Internet-Draft. Document: draft-ietf-dots-robust-blocks-04 Reviewer: Paul Kyzivat Review Date: 2022-09-13 IETF LC End Date: 2022-09-16 IESG Telechat date: ? Summary: Ready with Nits Issues: Major: 0 Minor: 0 Nits: 2 1) NIT: "Parameter" vs. "Attribute" Throughout the document the terms "Parameter" and "Attribute" are used more or less interchangeably. The term "Parameter" seems to be derived from RFCs 7252 and 9177 (e.g., in Table 1) and IIUC refers to abstract values without regard to how they are represented or transferred. Parameters are denoted by names in CAPITAL_LETTERS. The term "Attribute" seems to come from the definition of a DOTS signal channel in RFC 9132. Attributes are denoted by lower-case-hyphenated-names. I suggest it would be clearer to consistently use Parameter when discussing the former and Attribute when discussing the latter. (However, in the IANA registry table the column containing these "attributes" is labeled "Parameter Name", and so the template for the registry will have to refer to it that way. Unfortunate!) 2) NIT: Relation of Parameters and Attributes The Introduction ends with: ... Nevertheless, the attributes listed in Table 1 are not supported in [RFC9132]. This document defines new DOTS signal channel attributes that are used to customize the configuration of robust block transmission in a DOTS context. This seems to be the prime purpose of this document. Yet it fails to explicitly state the connection between the parameters listed in Table 1 and the "new DOTS signal channel attributes". I see that there is a 1:1 correspondence between the two, with the exception of NON_TIMEOUT_RANDOM, which apparently need not transmitted because it is calculated. I think it would be helpful to state this explicitly here in the document. Perhaps: ... Nevertheless, the parameters listed in Table 1 are not supported in [RFC9132]. This document defines new DOTS signal channel attributes, corresponding to the parameters in Table 1, that are used to customize the configuration of robust block transmission in a DOTS context.