Re: [Dots] Genart last call review of draft-ietf-dots-robust-blocks-05

["Tim Evens (tievens)" <[e-mail]>]

Looks good, thanks!

On 9/26/22, 10:44 PM, "[e-mail]" <[e-mail]> wrote:

Hi Tim,

Thank you for the review.

You can track the changes made to address your comments at: https://tinyurl.com/dots-robust-latest. FWIW, please see inline for more context.

Cheers,
Med

> -----Message d'origine-----
> De : Tim Evens via Datatracker <[e-mail]>
> Envoyé : mardi 27 septembre 2022 05:19
> À : [e-mail]
> Cc : [e-mail]; [e-mail];
> [e-mail]
> Objet : Genart last call review of draft-ietf-dots-robust-blocks-
> 05
>
> Reviewer: Tim Evens
> 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-dots-robust-blocks-??
> Reviewer: Tim Evens
> Review Date: 2022-09-26
> IETF LC End Date: 2022-09-16
> IESG Telechat date: 2022-10-06
>
> Summary: This document is ready with some minor comments.
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
> 1) +1 to Paul's Nits
>
> 2) Upon initial read, the abstract could suggest new parameters
> being introduced for configuration, yet that is not the case for
> this document. In Section 1 it is more clear by writing "This
> document augments the "ietf-dots-signal-channel" DOTS signal YANG
> module defined in Section 5.3 of [RFC9132]". It appears to me that
> this document adds the existing RFC9177 non-confirming parameters
> to DOTS. I'm not suggesting that the abstract needs to be changed,
> but IMO it is a bit misleading till you read the intro.
>

[Med] The abstract is correct, but added a new sentence to indicate that the new parameters are added by augmenting the DOTS signal channel model.

> 3) In section 1; "Nevertheless, the parameters listed in Table 1
> are not supported in [RFC9132]". While "not supported" is correct,
> I believe that it would be more clear as "not included"
> considering the parameters do exist.
>

[Med] Changed to "negotiating ... is not supported".

> 4) In section 3, the parameters are restated from RFC9177 and
> RFC9132.
>
> Each parameter looks to be a redefinition of what's documented in
> RFC9177 but with missing statements, truncated. I would prefer
> that if the parameter is unchanged to RFC9177, it should simply
> state that it's the same as defined in RFC9177.
>
> Restating/documenting the parameters leads the reader to have to
> compare if there is a change from the source RFC.
>

[Med] The current approach was adopted for the reader's convenience. We do point systematically to the authoritative RFCs and keep repeating "parameter XX echoes xxx in RFC9177". I prefer to keep the current structure. Thank you.


_________________________________________________________________________________________________________________________

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.