Re: [Last-Call] Artart Last Call review of draft-ietf-dots-robust-blocks-04

[Paul Kyzivat <[e-mail]>]

On 9/14/22 1:42 AM, [e-mail] wrote:
> Hi Paul,
> 
> Thank you for the review.
> 
> All good points. You can track the changes to address your review at: https://tinyurl.com/dots-robust-latest

Looks good!

	Thanks,
	Paul

> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Paul Kyzivat <[e-mail]>
>> Envoyé : mardi 13 septembre 2022 19:46
>> À : [e-mail]
>> Cc : [e-mail]; last-
>> [e-mail]; [e-mail]
>> Objet : Artart Last Call review of draft-ietf-dots-robust-blocks-
>> 04
>>
>> 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.
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>