Re: [Add] Murray Kucherawy's Discuss on draft-ietf-add-resolver-info-12: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Murray, 

Thank you for the review.

Pease see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Murray Kucherawy via Datatracker <[e-mail]>
> Envoyé : jeudi 4 avril 2024 09:15
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Murray Kucherawy's Discuss on draft-ietf-add-resolver-info-12:
> (with DISCUSS and COMMENT)
> 

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> In Section 8.2, we're creating an IANA registry with Specification
> Required
> rules.  You correctly cite Section 4.6 of BCP 26, but that section
> also says:
> 
>    As with Expert Review (Section 4.5), clear guidance to the
> designated
>    expert should be provided when defining the registry, and thorough
>    understanding of Section 5 is important.
> 
> Such guidance appears to be absent here.  What do you have in mind?
> 

[Med] Mainly the security implications + usual checks (redundant, etc.). 

Please see the full change here: https://github.com/boucadair/add-resolver-information/pull/28/commits/5cd27d84ba47e3ff86507d277ee14eb145b3837a

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In Section 5:
> 
>   "Note that, as per the rules for the keys defined in Section 6.4 of
>   [RFC6763], if there is no '=' in a key, then it is a boolean
> attribute,
>   simply identified as being present, with no value."
> 
> I don't know what it means for a Boolean value to be "present".

[Med] The key is present. Already changed this per a comment from Gunter.

  Do
> you mean
> that its presence in the record indicates the value is "true"?
> 
> The last few sentences of the description of "infourl" seem awfully
> hand-wavy.
> You might want to simplify this by saying it's a URI referring to
> content that
> may be useful for debugging, and just leave it at that.  And I don't
> understand
> the SHOULD here; what's the alternative you're trying to discourage?
> 
> Once the list of registered RESINFO keywords is big enough, it's
> possible to
> pack enough of them into one of these records to cause truncation and
> a switch
> to TCP.  Should we be encouraging registration of shorter names
> wherever
> possible to forestall this?
> 

[Med] We are inheriting the same rule as in RFC6763:

   The key SHOULD be no more than nine characters long.  This is because
   it is beneficial to keep packet sizes small for the sake of network
   efficiency.

> 

____________________________________________________________________________________________________________
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.