Re: [Add] [EXTERNAL] Re: Summary & Next Steps RE: DNR's SvcParams encoding

[Tommy Jensen <[e-mail]>]

+1. Thanks for bearing with us, Med.

Thanks,
Tommy

From: Add <[e-mail]> On Behalf Of Tommy Pauly
Sent: Tuesday, October 3, 2023 12:57 PM
To: [e-mail]
Cc: Chris Box <[e-mail]>; ADD Mailing list <[e-mail]>
Subject: [EXTERNAL] Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding

That new text looks good to me.

Thanks,
Tommy


On Oct 3, 2023, at 10:55 AM, [e-mail]<mailto:[e-mail]> wrote:

Re-,


A change we are currently discussing with my co-authors is to update Section 3.1.5 as follows:

OLD :
   These parameters are encoded following the same rules
   for encoding SvcParams as those specified in Section 2.1 of
   [RFC9460].

NEW:
   These parameters are encoded following the same rules
   for encoding SvcParams using the wire format specified
   in Section 2.2 of [RFC9460].

Do you think this is ambiguous?

Cheers,
Med

De : Chris Box <[e-mail]<mailto:[e-mail]>>
Envoyé : mardi 3 octobre 2023 19:23
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : ADD Mailing list <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding

On Tue, 3 Oct 2023 at 16:28, <[e-mail]<mailto:[e-mail]>> wrote:
Unless we hear an objection in the coming two days, we will make the following change (five occurrences in the I-D):


OLD: Section 2.1 of [RFC9460]

NEW: Section 2.2 of [RFC9460]

Med,

I think you are right, as I have heard more support expressed for wire format than presentation format. I personally agree with making the above change.

Note that implementers would then be directed here:
2.2. <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2> RDATA wire format<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#name-rdata-wire-format>

The RDATA for the SVCB RR consists of:¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-1>

  *   a 2-octet field for SvcPriority as an integer in network byte order.¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-2.1>
  *   the uncompressed, fully-qualified TargetName, represented as a sequence of length-prefixed labels as in Section 3.1<https://rfc-editor.org/rfc/rfc1035#section-3.1> of [RFC1035<https://www.rfc-editor.org/rfc/rfc1035>].¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-2.2>
  *   the SvcParams, consuming the remainder of the record (so smaller than 65535 octets and constrained by the RDATA and DNS message sizes).¶<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12#section-2.2-2.3>

We both know to ignore the first two bullets, but new implementers may not pick up on this. So we might also consider adding a sentence to DNR that makes it clear that SvcPriority and TargetName are not to be included in this field's encoding.

Chris

____________________________________________________________________________________________________________

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.
--
Add mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/add