Hi Robert, Many thanks for the review. All good points, unsurprisingly. Please see inline. Cheers, Med > -----Message d'origine----- > De : Robert Sparks via Datatracker <noreply@xxxxxxxx> > Envoyé : vendredi 8 juillet 2022 17:39 > À : art@xxxxxxxx > Cc : add@xxxxxxxx; draft-ietf-add-dnr.all@xxxxxxxx; last- > call@xxxxxxxx > Objet : Artart last call review of draft-ietf-add-dnr-10 > > Reviewer: Robert Sparks > Review result: Ready with Issues > > Summary: Has issues to address before publication as a Proposed > Standard RFC > > Issues: > > The document claims that Section 2.4.1 of I-D.ietf.dnsop-svcb- > https defines the encoding for the Service Priority field. It does > not - it only discusses the semantics. More clarity is needed. In > _this_ document I suggest explicitly saying you are encoding the > Service Priority as a 16bit unsigned integer. [Med] Updated to: "This 16-bit unsigned integer is interpreted following the rules specified in Section 2.4.1 of I-D.ietf.dnsop-svcb-https". > > Nits: > > You define Do53 and use it exactly once. It is unnecessary. Just > say unencrypted DNS the one place you use Do53. > [Med] Fair. We used to have this entry since early days of the draft when it was used many time. Removed that entry but made this change: s/Do53/unencrypted DNS (a.k.a., Do53) > Consider removing, or significantly expanding on, the last > paragraph of 7.4. > The notion of unique pre-shared keys here seems under-described, [Med] This refers to what is mentioned in the first sentences of that same paragraph. Will leave it for now. Thanks. > and feels out of place to me in a Proposed Standard document. > > Micro-nit: > > Consider changing the title of section 3.4 to "Multihoming is out > of scope" > since you don't present any actual multihoming considerations. > > [Med] Deal! _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
