Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-09.txt
Internet-Drafts "expire" but they never go away. The IETF makes them publicly accessible on an "archival" basis. RFC 8447 is an example of an RFC that lists them specifically as a suitable specification form, without limitation. My impression is that the WG consensus was for this draft to do the same. I don't think this allowance serves a specific purpose beyond making it very easy to acquire registrations, which is something that several working group members voiced support for. It is not limited to experimental usage. I believe the underlying logic is that parameter registrations are harmless because unrecognized parameters can safely be ignored, and the codepoint space is not at risk of exhaustion. On Mon, May 9, 2022 at 6:25 PM Murray S. Kucherawy wrote: > On Mon, May 9, 2022 at 3:12 PM Ben Schwartz wrote: > >> Yes, that's covered in the description: >> >> The designated expert MUST ensure that the Format Reference is stable and >> publicly available, and that it specifies how to convert the >> SvcParamValue's presentation format to wire format. The Format Reference >> MAY be any individual's Internet-Draft, or a document from any other source >> with similar assurances of stability and availability. >> > > Yes, I saw that text, but that sentence doesn't make it clear to me why an > auto-expiring document is acceptable as a possibly-permanent format > reference, so I thought I'd double check. > > -MSK > smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-svcb-https-09: (with COMMENT)
Murray Kucherawy has entered the following ballot position for draft-ietf-dnsop-svcb-https-09: 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-dnsop-svcb-https/ -- COMMENT: -- I support Francesca's DISCUSS around use of SHOULDs. Thanks for the fixes to IANA Considerations. One minor issue remains, which is that we're allowing an automatically-expiring document (an I-D) to set the bar for what constitutes a valid Format Reference. Given such a registration might be permanent, a disappearing reference seems a curious choice. The discussion in the WG indicates that this is done to support experimental registrations and the like; it might be good for the text to say so. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-svcb-https-09: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-svcb-https-09: Yes 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-dnsop-svcb-https/ -- COMMENT: -- Thanks for the changes! (Referring to 4001 seems odd to me, and maybe unnecessary.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-09.txt
On Mon, May 9, 2022 at 3:12 PM Ben Schwartz wrote: > Yes, that's covered in the description: > > The designated expert MUST ensure that the Format Reference is stable and > publicly available, and that it specifies how to convert the > SvcParamValue's presentation format to wire format. The Format Reference > MAY be any individual's Internet-Draft, or a document from any other source > with similar assurances of stability and availability. > Yes, I saw that text, but that sentence doesn't make it clear to me why an auto-expiring document is acceptable as a possibly-permanent format reference, so I thought I'd double check. -MSK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Doodle poll for DNSOP WG interim on 24 or 25 May
Hi all, The following newly adopted DNSOP WG drafts are on the agenda for the interim meeting: - dnssec-automation, Ulrich Wisser and Shumon Huque - dnssec-bootstrapping, Peter Thomassen and Nils Wisiol We want to close the Doodle poll at the end of Wednesday, 11 May. Best regards, Suzanne, Tim and Benno On 29/04/2022 23:04, Benno Overeinder wrote: Dear DNSOP WG, We are planning our first DNSOP WG interim meeting for 2022 on May 24 or 25. The DNSOP WG chairs are contacting the authors of two drafts that can be put on the agenda. Details to follow. Please fill in the Doodle poll to settle on a day and time: - https://doodle.com/meeting/participate/id/e0RyVkXb The options for the time slots are CEST/EDT/PDT friendly. We will close the Doodle poll at the end of Thursday, 5 May. Best regards, Suzanne, Tim and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-09.txt
On Fri, May 6, 2022 at 12:09 PM wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : Service binding and parameter specification via > the DNS (DNS SVCB and HTTPS RRs) > Authors : Ben Schwartz > Mike Bishop > Erik Nygren > Filename: draft-ietf-dnsop-svcb-https-09.txt > Pages : 62 > Date: 2022-05-06 > > Abstract: >This document specifies the "SVCB" and "HTTPS" DNS resource record >(RR) types to facilitate the lookup of information needed to make >connections to network services, such as for HTTP origins. SVCB >records allow a service to be provided from multiple alternative >endpoints, each with associated parameters (such as transport >protocol configuration and keys for encrypting the TLS ClientHello). >They also enable aliasing of apex domains, which is not possible with >CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. >By providing more information to the client before it attempts to >establish a connection, these records offer potential benefits to >both performance and privacy. > I see the change to Expert Review, which looks good. Are we going with the idea of allowing an I-D to be a valid format reference, even though they expire, to enable things that are in development or experimental? -MSK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Robert Wilton via Datatracker writes: > One minor point, I found it slightly confusing in various places as to whether > "iterations" meant "total number of interactions" or the "iterations > parameter" > that refers to the number of extra interactions. Hence I would suggest > changing "iterations" to "iterations parameter" or "extra iterations" or > "total > iterations" in various places depending on the context to ensure that this it > is clear/obvious in all places. Thanks Rob, I can see where people less familiar with the NSEC3 protocol could easily get misled and will look at the wording throughout the document. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan
Hi, On 2022-4-29, at 13:54, Lars Eggert wrote: > the IESG is reviewing what has happened. the IESG discussed this issue. Below is my personal attempt to summarize the outcome of this discussion. We believe that it is permissible under the current rules to include sections of text that others have contributed to the IETF standards process - even extensive sections of text, as in this case - in a new IETF contribution. However, we also believe that it is customary to at least acknowledge the source of any such copied material, or better, to reach out to inquire whether the original authors would like to be involved in a planned derivative of their original contribution. We discussed whether any additional process or tooling was needed, and concluded that such instances are rare enough that the delays and overheads associated with new measures would be counterproductive overall. Thanks, Lars signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-dnsop-nsec3-guidance-08: 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-dnsop-nsec3-guidance/ -- COMMENT: -- Hi, Thanks for this document. I found it mostly to be easy to read. One minor point, I found it slightly confusing in various places as to whether "iterations" meant "total number of interactions" or the "iterations parameter" that refers to the number of extra interactions. Hence I would suggest changing "iterations" to "iterations parameter" or "extra iterations" or "total iterations" in various places depending on the context to ensure that this it is clear/obvious in all places. Regards, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
