Re: [Dots] John Scudder's No Objection on draft-ietf-dots-robust-blocks-05: (with COMMENT)

[[e-mail]]

Hi John, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : John Scudder via Datatracker <[e-mail]>
> Envoyé : jeudi 29 septembre 2022 23:09
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : John Scudder's No Objection on draft-ietf-dots-robust-
> blocks-05: (with COMMENT)
> 
> John Scudder has entered the following ballot position for
> draft-ietf-dots-robust-blocks-05: No Objection
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-robust-blocks/
> 
> 
> 
> ------------------------------------------------------------------
> ----
> COMMENT:
> ------------------------------------------------------------------
> ----
> 
> Thanks for this spec. Also, thanks to Valery Smyslov for the
> carefully-
> written shepherd writeup.
> 
> I have just one comment, and one question, about this in Section
> 3:
> 
>    max-payloads:  This attribute echoes the MAX_PAYLOADS parameter
> in
>       [RFC9177].
> 
>       This is an optional attribute.  If the attribute is supplied
> in
>       both 'idle-config' and 'mitigating-config', then it MUST
> convey
>       the same value.  If the attribute is only provided as part
> of
>       'idle-config' or 'mitigating-config', then the other
> (missing)
>       definition MUST be updated to the same value.
> 
> I think what you're saying here is that if max-payloads is set for
> either idle-config or mitigating-config, then that parameter shall
> be
> deemed set for both configs, and to the same quantity. I found the
> way of saying it above to be quite confusing, especially the
> "(missing)"
> thing, since if it's optional it can hardly be said to be
> "missing" just
> because it isn't present.
> 

[Med] We didn't find something short + convey this subtlety. Made this change: 

If the attribute is only provided as part of ‘idle-config’ (or ‘mitigating-config’), then the other  definition (i.e., ‘mitigating-config’ (or ‘idle-config’)) MUST be updated to the same value.


> I also wonder if you need to supply some answer to the question of
> what should happen if the MUST is violated. E.g. one option might
> be
> to say that if two different values are supplied, the larger of
> the
> two shall be used for both.

[Med] We avoided to have redundant requirements vs Section 4.5 of RFC9132 we pointed to for the request handling. This request will be invalid and the following error will be returned as per the base spec:  

   *  If the request is missing a mandatory attribute, does not include
      a 'sid' Uri-Path, or contains one or more invalid or unknown
      parameters, 4.00 (Bad Request) MUST be returned in the response.

 


_________________________________________________________________________________________________________________________

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.