Re: [dispatch] Tiny update to RFC 3405

[Ted Hardie <[e-mail]>]

Howdy,

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

> Ted,
> >
> >Yes, this came up because of a proposed registration. Since it was yours,
> >perhaps you would like to provide the link to the group?
>
> There is already a mailing list for that.
>
>
> >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.
>
>
> 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?
>

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).


> 2. Regardless, any discussions should really wait until after upcoming
> registrations or appeals of those registrations, or appeals of those
> appeals are
> completed.
>
>
> >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.
>
>
> 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.
>
>
> 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 <[e-mail]> wrote:
>
> Howdy,
>
> On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < [e-mail]>
> wrote:
>
> 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?
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>