Subject: [DNSOP] IANA Policy for SVCB

From: Ben Schwartz <[email-masked]>
Date: Mon, 21 Mar 2022 05:19:48 -0400

Hi DNSOP,

The latest draft of the SVCB specification says [1]

>   Entries in this registry are subject to a First Come First Served
>   registration policy ([RFC8126], Section 4.4).  The Format Reference
>   MUST specify how to convert the SvcParamValue's presentation format
>   to wire format and MAY detail its intended meaning and use.

IANA initially approved this text, but after it was highlighted during IESG
review [2], IANA determined that this text is not compatible with IANA
policy [3] because it requires too much technical judgement during
registration processing.

This leaves us with several possible options:
1. Change the MUST to SHOULD, or otherwise indicate that IANA is not
expected to enforce anything about the contents of the format reference.
Registrations might appear without a suitable format reference, resulting
in keys that are difficult to parse and serialize interoperably (e.g. same
zone file produces different results in different authoritative server
implementations).
2. Change the registration policy to Expert Review, relying on the
designated expert to enforce this rule.  Registrations might be processed
more slowly.
3. Change the registration policy to Specification Required.  This is
similar to #2 but incorporates formal guidance about what kinds of
documents qualify as a "specification" (e.g. must be "permanent and readily
available").  Note that this is not "RFC Required": any individual I-D is
considered a qualified specification as soon as it is uploaded to the
Datatracker.

Personally, I favor #3.  What do you think?

--Ben Schwartz

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-15.3.1
[2] https://mailarchive.ietf.org/arch/msg/dnsop/73Pa2Dipc5uW2gdqzIvObcLRn9k/
[3] https://mailarchive.ietf.org/arch/msg/dnsop/Z62e6s0-Tmh0CC9XcS7FHRneJt8/

---

From: Jim Reid <[email-masked]>
Date: Mon, 21 Mar 2022 09:37:52 +0000

> On 21 Mar 2022, at 09:19, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
 
Ben, I think 2 (Expert Review) is the right approach. This would hopefully ensure any specifications are complete/valid and raise the threshold to discourage bad or frivolous SrvParamValues "registrations".

An Expert Review seems right to me. It's culturally compatible with how we handle the allocation of new RRtypes.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 21 Mar 2022 20:45:13 +1100

I favour #3 over #2 on the basis that you can't reasonably put the "how to convert" text into a registry.

On Mon, Mar 21, 2022, at 20:19, Ben Schwartz wrote:
> IANA initially approved this text, but after it was highlighted during 
> IESG review [2], IANA determined that this text is not compatible with 
> IANA policy [3] because it requires too much technical judgement during 
> registration processing.
>
> expected to enforce anything about the contents of the format 
> reference.  Registrations might appear without a suitable format 
> reference, resulting in keys that are difficult to parse and serialize 
> interoperably (e.g. same zone file produces different results in 
> different authoritative server implementations).
> designated expert to enforce this rule.  Registrations might be 
> processed more slowly.
> documents qualify as a "specification" (e.g. must be "permanent and 
> readily available").  Note that this is not "RFC Required": any 
> individual I-D is considered a qualified specification as soon as it is 
> uploaded to the Datatracker.
>
> [2] 
> https://mailarchive.ietf.org/arch/msg/dnsop/73Pa2Dipc5uW2gdqzIvObcLRn9k/
> [3] 
> https://mailarchive.ietf.org/arch/msg/dnsop/Z62e6s0-Tmh0CC9XcS7FHRneJt8/
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
> Attachments:
> * smime.p7s

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2022 06:32:54 -0400 (EDT)

On Mon, 21 Mar 2022, Ben Schwartz wrote:

> 1. Change the MUST to SHOULD, or otherwise indicate that IANA is not expected to enforce anything about the contents of the format
> reference.  Registrations might appear without a suitable format reference, resulting in keys that are difficult to parse and
> serialize interoperably (e.g. same zone file produces different results in different authoritative server implementations).
> 2. Change the registration policy to Expert Review, relying on the designated expert to enforce this rule.  Registrations might be
> processed more slowly.
> 3. Change the registration policy to Specification Required.  This is similar to #2 but incorporates formal guidance about what kinds
> of documents qualify as a "specification" (e.g. must be "permanent and readily available").  Note that this is not "RFC Required":
> any individual I-D is considered a qualified specification as soon as it is uploaded to the Datatracker.

I favour #2, especially as this intersects the DNS protocol with other
protocols, and those requesting SVCB might not be DNS experts. Having
a DNS expert to verify things make sense seems good. Although I would
hope the Expert would also want a Specification Required as their
input.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 21 Mar 2022 06:37:25 -0400

On Mon, Mar 21, 2022 at 6:33 AM Paul Wouters <[email-masked]> wrote:

> reference, resulting in keys that are difficult to parse and
> > serialize interoperably (e.g. same zone file produces different results
> in different authoritative server implementations).
> similar to #2 but incorporates formal guidance about what kinds
> > of documents qualify as a "specification" (e.g. must be "permanent and
> readily available").  Note that this is not "RFC Required":

Note that Specification Required is a superset of Expert Review: "This
policy is the same as Expert Review, with the additional requirement of a
formal public specification." (
https://datatracker.ietf.org/doc/html/rfc8126#section-4.6)

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 21 Mar 2022 06:24:17 -0700

I agree with Paul that #2 seems to be best, with the expert being able to enforce a certain level of specification depending on the parameter being allocated.

Tommy

> On Mar 21, 2022, at 3:32 AM, Paul Wouters <[email-masked]> wrote:
>

---

From: Petr Špaček <[email-masked]>
Date: Tue, 22 Mar 2022 10:20:51 +0100

> An Expert Review seems right to me. It's culturally compatible with how we handle the allocation of new RRtypes.

+1 for Expert Review for reasons stated by Jim. I don't see #3 as really 
needed.

-- 
Petr Špaček

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Mar 2022 08:45:23 -0700

On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
>

Do you have a reference that asserts this?  An I-D that isn't published
will expire, which would appear to contradict "permanent and readily
available".

-MSK

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Mar 2022 02:47:34 +1100

On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz 
> <bemasc=[email-masked]> wrote:
>> [...] any individual I-D is considered a qualified specification as soon as it is uploaded to the Datatracker.
>

There is precedent (TLS docs), but I don't know if there is a reference.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Mar 2022 09:01:14 -0700

> There is precedent (TLS docs), but I don't know if there is a reference.

Interesting.

In my role as a media type reviewer, for example, it's unlikely I'd accept
an I-D as a stable reference in a registration request except maybe for a
provisional registration.  I could be wrong, but my understanding of the
intent of "Specification Required" is roughly "permanently published,
though not necessarily by the IETF", so I think the bar is a little higher
than just the existence of an I-D.

As to the options proposed, I agree that Expert Review can introduce delay,
but given the above, so too can Specification Required (maybe worse, in
aggregate).  So I recommend Expert Review.

Finally, I just realized my DISCUSS on this document about the IANA
Considerations is redundant to Ben's, so I'm going to go clear it and just
support Ben's.

-MSK

---

From: Ray Bellis <[email-masked]>
Date: Tue, 22 Mar 2022 16:09:46 +0000

On 22/03/2022 16:01, Murray S. Kucherawy wrote:

> As to the options proposed, I agree that Expert Review can introduce 
> delay, but given the above, so too can Specification Required (maybe 
> worse, in aggregate).  So I recommend Expert Review.

I am concerned that the set of Expert Reviewers necessary to handle SVCB 
needs to have both expert DNS experience *and* detailed knowledge of the 
SVCB model for this to work.

I am not sure there's anybody who fits that criteria.

Ray [RRTYPE expert reviewer]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Mar 2022 09:24:39 -0700

> I am not sure there's anybody who fits that criteria.

Specification Required also assumes a community that can produce them,
which presumably contains the right experts.

Are we actually moving toward IETF Review here?

-MSK

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 22 Mar 2022 11:29:44 -0700

If this space is not extensible from non-IETF RFCs, we’ll have missed the mark. The space is designed to be large (65K) to allow new work to easily use this extensibility. We don’t need to be too conservative with this space.

I disagree that there wouldn’t be good experts — we have authors of the document who have seen it through, and we have more people using this RR and gaining expertise.

Expert review is the right balance here.

Tommy

> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis <[email-masked] <mailto:[email-masked]>> wrote:
> Specification Required also assumes a community that can produce them, which presumably contains the right experts.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Mar 2022 11:33:17 +1100

I agree with Tommy.

Selecting an expert who is able to recognize when wider review might help is a far lower bar than the one Ray suggests might be necessary.

On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we’ll have missed 
> the mark. The space is designed to be large (65K) to allow new work to 
> easily use this extensibility. We don’t need to be too conservative 
> with this space.
>
> I disagree that there wouldn’t be good experts — we have authors of the 
> document who have seen it through, and we have more people using this 
> RR and gaining expertise.
>