As I have read no *strong objection* [1] for using the wire format for SvcParams, as the responsible AD for ADD, I am requesting the draft-ietf-add-dnr-16 authors to contact the RFC editor [2] with the updated text (i.e., using the wire format rather than the zone presentation format) and will shortly release the ‘IESG hold’ state in AUTH48.
While not required, and without any hat, I hope that draft-ietf-ipsecme-add-ike-14 will also be updated to use the same format (hence the cross posting). Thank you all for the detailed discussions, Regards -éric [1] But noted that this is not the favorite solution for everyone [2] Med has already acted ;) From: Eric Vyncke (evyncke) <evyn...@cisco.com> Date: Wednesday, 4 October 2023 at 16:51 To: Erik Nygren <erik+i...@nygren.org>, mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Cc: Chris Box <chris.box.i...@gmail.com>, ADD Mailing list <a...@ietf.org> Subject: Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding Happy to read that the ADD WG is reaching a consensus on this I-D. If I hear no strong opposition on Med’s proposal for using “wire format” by Thursday 5th of Octobre 2023 midnight UTC, then I will request the author to submit a revised I-D *AND* to send the modified text (OLD/NEW format) to the RFC editor in the AUTH48 email thread, I will then release the “IESG hold” state. Thanks to all for this last effort after the arrival line! But, we all shoot for perfection (if possible). Regards -éric PS: Erik, adding a test vector is a good idea but would need verification (OTOH an example of the DHCP option in binary format would be cool for sure and doable). For information, errata are *only* about errors in the text based on the IETF consensus at the time of publication, i.e., cannot add a test vector after ;-) From: Add <add-boun...@ietf.org> on behalf of Erik Nygren <erik+i...@nygren.org> Date: Tuesday, 3 October 2023 at 22:36 To: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Cc: Chris Box <chris.box.i...@gmail.com>, ADD Mailing list <a...@ietf.org> Subject: Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding This new text sounds good to me. It might be worth having a test vector as well, but I assume it's too late to add now. (Is there a way to add a test vector as an errata following publication?) Erik On Tue, Oct 3, 2023 at 1:56 PM <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 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 <chris.box.i...@gmail.com<mailto:chris.box.i...@gmail.com>> Envoyé : mardi 3 octobre 2023 19:23 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : ADD Mailing list <a...@ietf.org<mailto:a...@ietf.org>> Objet : Re: [Add] Summary & Next Steps RE: DNR's SvcParams encoding On Tue, 3 Oct 2023 at 16:28, <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> 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 a...@ietf.org<mailto:a...@ietf.org> https://www.ietf.org/mailman/listinfo/add
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
