Subject: Re: [dispatch] Tiny update to RFC 3405

From: Timothy Mcsweeney <[email-masked]>
Date: Sat, 4 Jul 2020 05:21:28 -0400 (EDT)

Ted,

In your opening email to the 400 highly respectable people on this list you say:

"As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now."

How did you "catch it"?

Was there a pending registration?

Is there still a pending registration?

It would really be bad to try to change the rules while something was pending.

I can't speak for the others but some of them might want to know why after almost 20 years of there being zero problems with RFC3405 it suddenly needs to get "fixed".

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Jul 2020 09:15:32 -0700

Howdy,

> Is there still a pending registration?

Yes, this came up because of a proposed registration.  Since it was yours,
perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while something was
> pending.
The current rules cannot work because they reference a category that no
longer exists. To put this differently, if they don't change, there can be
no more registrations in URI.arpa.

Once DISPATCH decides where this ought to be discussed, we can discuss that
outcome or the update to BCP 35 to restore the category as alternatives.

regards,

Ted Hardie

> I can't speak for the others but some of them might want to know why after
> almost 20 years of there being zero problems with RFC3405 it suddenly needs
> to get "fixed".
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Mon, 6 Jul 2020 14:26:34 -0400 (EDT)

Ted,

>perhaps you would like to provide the link to the group?

There is already a mailing list for that.

>outcome or the update to BCP 35 to restore the category as alternatives.

There should not be a discussion at all.

1.  Section 5 of RFC3405 isn't broken.  Maybe you were confusing it with

Section 5 or RFC4395?

2. Regardless, any discussions should really wait until after upcoming

registrations or appeals of those registrations, or appeals of those appeals are

completed.

>no more registrations in URI.arpa.

The current rules are working just fine.

HTTP, among others, are still in the uri.arpa zone proving that the RFC3405

Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the current

spec and can be seen in totality in IANA's list of URIs.

On July 6, 2020 at 12:15 PM Ted Hardie <[email-masked]> wrote:

Howdy,

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney <
[email-masked]> wrote:

Ted,

How did you "catch it"?

Yes, this came up because of a proposed registration.  Since it was yours, perhaps you would like to provide the link to the group?

The current rules cannot work because they reference a category that no longer exists. To put this differently, if they don't change, there can be no more registrations in URI.arpa.

Once DISPATCH decides where this ought to be discussed, we can discuss that outcome or the update to BCP 35 to restore the category as alternatives.

regards,

Ted Hardie

dispatch mailing list

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Jul 2020 11:51:13 -0700

Howdy,

> 1.  Section 5 of RFC3405 isn't broken.  Maybe you were confusing it with

As I note in the extremely short document:

   The document requires that registrations be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.

If we leave things as they are, no registrations can be made, because the
category is gone.  We can change it to require permanent registrations
instead (as this document suggests) or you could propose something
different (e.g. updating BCP 35 to recreate the IETF tree for these
registrations).

> If I understand you correctly, you are arguing that because URI.arpa was
not depopulated when the IETF tree was dropped, registrations can still be
made according to the old rules as if there still were an IETF tree.

That's not how the IETF process treats obsoleting BCPs; see the IESG
statement at
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/
.

This situation has pointed out that there was a bug introduced by RFC 4395
that was carried forward into RFC 7595, because they did not address the
dependency on the removed IETF tree in BCP 65.  This document is one way to
address that bug.  If you wish to suggest others, that's fine, but we still
need DISPATCH to identify where the discussion should happen.

regards,

Ted

> On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < [email-masked]>
> wrote:
>
> Ted,
> Once DISPATCH decides where this ought to be discussed, we can discuss
> that outcome or the update to BCP 35 to restore the category as
> alternatives.
>
> regards,
>
> Ted Hardie
>
>
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Mon, 6 Jul 2020 15:09:27 -0400 (EDT)

Hi,

>If I understand you correctly, you are arguing that because URI.arpa was not >depopulated when the IETF tree was dropped, registrations can still be made >according to the old rules as if there still were an IETF tree.

I'm arguing that, as it sits right now, in order to insert a record into uri.arpa,

you have to have a scheme name registered.

On July 6, 2020 at 2:51 PM Ted Hardie <[email-masked]> wrote:

Howdy,

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney <
[email-masked]> wrote:

Ted,

Section 5 or RFC4395?

If we leave things as they are, no registrations can be made, because the category is gone.  We can change it to require permanent registrations instead (as this document suggests) or you could propose something different (e.g. updating BCP 35 to recreate the IETF tree for these registrations).

completed.

If I understand you correctly, you are arguing that because URI.arpa was not depopulated when the IETF tree was dropped, registrations can still be made according to the old rules as if there still were an IETF tree.

That's not how the IETF process treats obsoleting BCPs; see the IESG statement at
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/.

This situation has pointed out that there was a bug introduced by RFC 4395 that was carried forward into RFC 7595, because they did not address the dependency on the removed IETF tree in BCP 65.  This document is one way to address that bug.  If you wish to suggest others, that's fine, but we still need DISPATCH to identify where the discussion should happen.

regards,

Ted

On July 6, 2020 at 12:15 PM Ted Hardie <
[email-masked]> wrote:

Howdy,

Ted,

How did you "catch it"?

regards,

Ted Hardie

dispatch mailing list

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Jul 2020 13:19:16 -0700

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney <[email-masked]>
wrote:

> not >depopulated when the IETF tree was dropped, registrations can still be
> made >according to the old rules as if there still were an IETF tree.
>
>
RFC 3405 is pretty restrictive in its language:

3.1 URI.ARPA Registration
>
> 3.1.1 Only Schemes in the IETF Tree Allowed
>
>    In order to be inserted into the URI.ARPA zone, the subsequent URI
>    scheme MUST be registered under the IETF URI tree.  The requirements
>    for this tree are specified in [10].
>
> Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading of
the text supports the view that any URI registration is sufficient.
Section 3.1.2 also reinforces that the registration must be prior and then
the record insertion must pass IESG review; that section does not given the
IESG the right to waive the requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently or
          otherwise) network traffic for a given domain.

regards,

Ted Hardie

> On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < [email-masked]>
> wrote:
>
> Ted,
> >
> that
> On July 6, 2020 at 12:15 PM Ted Hardie < [email-masked]> wrote:
>
> Howdy,
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Mon, 6 Jul 2020 16:27:22 -0400 (EDT)

Ted,

Do you not want my scheme in the arpa zone?

On July 6, 2020 at 4:19 PM Ted Hardie <[email-masked]> wrote:

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney <
[email-masked]> wrote:

Hi,

Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading of the text supports the view that any URI registration is sufficient.   Section 3.1.2 also reinforces that the registration must be prior and then the record insertion must pass IESG review; that section does not given the IESG the right to waive the requirements:

regards,

Ted Hardie

On July 6, 2020 at 2:51 PM Ted Hardie <
[email-masked]> wrote:

Howdy,

Ted,

Section 5 or RFC4395?

completed.

regards,

Ted

Howdy,

Ted,

How did you "catch it"?

regards,

Ted Hardie

dispatch mailing list

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Jul 2020 15:13:50 -0700

Howdy,

> Do you not want my scheme in the arpa zone?
I'm just trying to avoid a silly state, where we say do X but don't let
anyone do X.  If this is published, then we'll have a clear rule that
matches the current system.  But if the consensus turns out to be that the
IETF tree should return for the sole purpose of registering schemes going
into .arpa, I would go along with that as well.

I don't support allowing provisionals in the zone because they are
first-come-first-served as of RFC 7595 and some of the registrations are
very vendor specific (for example, many of the ms- uri schemes in the
provisional category at
https://www.iana.org/assignments/uri-schemes/uri-schemes.xml are
Microsoft-only).  That's not in-line with the purpose of .arpa as an
infrastructure domain.

If you disagree, please write up your proposal.  I trust DISPATCH will
ensure that it gets discussed in the same place as this proposal.

regards,

Ted

> On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < [email-masked]>
> wrote:
>
> Hi,
> On July 6, 2020 at 2:51 PM Ted Hardie < [email-masked]> wrote:
>
> Howdy,
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Jul 2020 17:25:36 -0500

(As Co-Chair)

Hi All,

For the moment at least, please focus DISPATCH discussion on determining what the proper venue for discussion is.

Our choices are:
1) Recommend AD Sponsored
2) Adopt in DISPATCH as an “administrative document” as allowed by our charter
3) “Dispatch” to an existing WG, or recommend one be formed.
4) Recommend a BoF.

Thanks!

Ben.

> On Jul 6, 2020, at 5:13 PM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney <[email-masked] <mailto:[email-masked]>> wrote:
> Ted,
> I'm just trying to avoid a silly state, where we say do X but don't let anyone do X.  If this is published, then we'll have a clear rule that matches the current system.  But if the consensus turns out to be that the IETF tree should return for the sole purpose of registering schemes going into .arpa, I would go along with that as well.  
> 
> I don't support allowing provisionals in the zone because they are first-come-first-served as of RFC 7595 and some of the registrations are very vendor specific (for example, many of the ms- uri schemes in the provisional category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml <https://www.iana.org/assignments/uri-schemes/uri-schemes.xml> are Microsoft-only).  That's not in-line with the purpose of .arpa as an infrastructure domain.
> 
> If you disagree, please write up your proposal.  I trust DISPATCH will ensure that it gets discussed in the same place as this proposal.
> 
> regards,
> 
> Ted
> 
> 
> 
>> On July 6, 2020 at 4:19 PM Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote: 
>> 
>> On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumber..com <mailto:[email-masked]>> wrote: 
>> Hi,
>> >If I understand you correctly, you are arguing that because URI..arpa was not >depopulated when the IETF tree was dropped, registrations can still be made >according to the old rules as if there still were an IETF tree.
>> 
>> 
>>> On July 6, 2020 at 2:51 PM Ted Hardie < [email-masked] <mailto:[email-masked]>> wrote: 
>>> 
>>> Howdy, 
>>> 
>>> On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>> wrote: 
>>> Ted, 
>>> > 
>>> >Yes, this came up because of a proposed registration.. Since it was yours, 
>>> That's not how the IETF process treats obsoleting BCPs; see the IESG statement athttps://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ <https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/>.
>>> 
>>>> On July 6, 2020 at 12:15 PM Ted Hardie < [email-masked] <mailto:[email-masked]>> wrote: 
>>>> 
>>>> Howdy, 
>>>> 
>>>> On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>> wrote: 
>>>> Ted, 
>>>> [email-masked] <mailto:[email-masked]> 
>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch> 
>>> 
>>>  
>> 
>>  
> 
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Mon, 6 Jul 2020 21:08:31 -0400 (EDT)

I'll take that as a yes.

On July 6, 2020 at 6:13 PM Ted Hardie <[email-masked]> wrote:

Howdy,

On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney <
[email-masked]> wrote:

Ted,

I don't support allowing provisionals in the zone because they are first-come-first-served as of RFC 7595 and some of the registrations are very vendor specific (for example, many of the ms- uri schemes in the provisional category at
https://www.iana.org/assignments/uri-schemes/uri-schemes.xml are Microsoft-only).  That's not in-line with the purpose of .arpa as an infrastructure domain.

regards,

Ted

On July 6, 2020 at 4:19 PM Ted Hardie <
[email-masked]> wrote:

Hi,

regards,

Ted Hardie

Howdy,

Ted,

Section 5 or RFC4395?

completed.

regards,

Ted

Howdy,

Ted,

How did you "catch it"?

regards,

Ted Hardie

dispatch mailing list

[email-masked]

---

From: Timothy Mcsweeney <[email-masked]>
Date: Mon, 6 Jul 2020 21:08:33 -0400 (EDT)

Everyone,

In case I do not get a chance to re-iterate my opinion, I think discussion on this topic can wait for a while and the timing is suspect.  Ted's name is on RFC4395 as well as RFC7595 giving him more than 15 years to bring this up.

Tim

On July 6, 2020 at 6:25 PM Ben Campbell <[email-masked]> wrote:

(As Co-Chair)

Hi All,

Our choices are:

4) Recommend a BoF.

Thanks!

Ben.

On Jul 6, 2020, at 5:13 PM, Ted Hardie <
[email-masked]> wrote:

Howdy,

Ted,

regards,

Ted

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney <
tim@dropnumber..com> wrote:

Hi,

regards,

Ted Hardie

Howdy,

Ted,

Section 5 or RFC4395?

completed.

regards,

Ted

Howdy,

Ted,

How did you "catch it"?

regards,

Ted Hardie

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Jul 2020 20:37:37 -0500

Specific registration requests are off-topic. Please constrain discussion to the draft in question.

Thanks,

Ben.

> On Jul 6, 2020, at 8:08 PM, Timothy Mcsweeney <[email-masked]> wrote:
> 
> I'll take that as a yes.
> 
> 
> 
>> On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>> wrote: 
>> Ted,
>>> On July 6, 2020 at 4:19 PM Ted Hardie < [email-masked] <mailto:[email-masked]>> wrote: 
>>> 
>>> On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>> wrote: 
>>> Hi,