Re: [dispatch] Tiny update to RFC 3405

[Timothy Mcsweeney <[e-mail]>]

text version:

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

> On 07/06/2020 2:26 PM 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? 
> 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. 
> 
> 
> 
> 
> > 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 
> 
>