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

From: Martin J. Dürst <[email-masked]>
Date: Tue, 7 Jul 2020 16:34:36 +0900

On 23/06/2020 07:51, Ben Campbell wrote:
> Hi Everyone,
> 
> The ART ADs have reminded the chairs that our charter allows us to adopt “simple administrative” work such as IANA registration documents. This draft seems to fit squarely in that category. Does anyone see a reason we shouldn’t just adopt it, with the expectation of going immediately to WGLC? (The last-call timeline is the same either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted's draft and the 
mail up to today. To me, both AD sponsored and Dispatch WG look 
reasonable, with a slight preference for the former (if asked to express 
such a preference).

With respect to "pending registrations", I do not think these are 
relevant, in particular because the thing in question isn't actually a 
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of URI registrations 
for registrations in URI.ARPA.". I found this hard to read, and I guess 
it's because of the "registrations for registrations" piece. Unless one 
is very familiar with the matter at hand, it's easy to think that both 
occurrences of "registration" are referencing the same thing. While I'm 
at it, it would also be good if the abstract mentioned something 
positive. I think a less normative version of (the single sentence that 
is) Section 2 would serve well as the abstract.

Regards,   Martin.

> Thanks!
> 
> Ben (as co-chair)
> 
>> On Jun 3, 2020, at 6:13 PM, Ted Hardie <[email-masked]> wrote:
>>
>> Howdy,
>>
>> This is one the shortest drafts I've ever written:  https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/> ..   Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree".  That tree was deprecated after the document was published.  As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.
>>
>> This draft updates RFC 3405 to require "permanent" scheme registrations.  The salient bit is this:
>>
>> All registrations in URI.ARPA MUST be for schemes which are permanent
>>     registrations, as they are described in BCP 35.
>>
>> I'm hoping for a quick dispatch of this, but happy to discuss.
>>
>> regards,
>>
>> Ted Hardie
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Jul 2020 07:02:34 -0700

Hi Martin,

Suggested re-wording below.

On Tue, Jul 7, 2020 at 12:34 AM Martin J. Dürst <[email-masked]>
wrote:

> > The ART ADs have reminded the chairs that our charter allows us to adopt
> “simple administrative” work such as IANA registration documents. This
> draft seems to fit squarely in that category. Does anyone see a reason we
> shouldn’t just adopt it, with the expectation of going immediately to WGLC?
> (The last-call timeline is the same either way, either 2 weeks WGLC and 2
> weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD
> sponsored draft.)
>
> for registrations in URI.ARPA.".

Would "This document removes references to the IETF tree of URI
registrations from the procedures for requesting that a URI scheme be
inserted into the uri.arpa zone." work for you?

regards,

Ted

I found this hard to read, and I guess
> >> This is one the shortest drafts I've ever written:
> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <
> https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/>
> ..   Basically, RFC 3405 used to require that registrations in URI.ARPA be
> from the "IETF Tree".  That tree was deprecated after the document was
> published.  As it happens, there are very few registrations in URI.ARPA, so
> we did not catch it and fix it before now.
> >>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 7 Jul 2020 10:03:17 -0400 (EDT)

Hi All,

Updating RFC3405 will necessarily require changes to RFC3401 as stated in its

introduction.  "This document will be updated and or obsoleted when changes

are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits as a

"simple administrative".

But, I may have a work around that is simple and also solves the provisional registration problem as stated by Ted.  I could have ready in a day or so.

Tim

On July 7, 2020 at 3:34 AM "Martin J. Dürst" <
[email-masked]> wrote:

Hi Everyone,

such a preference).

Regards, Martin.

Thanks!

Ben (as co-chair)

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

Howdy,

This is one the shortest drafts I've ever written:
https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <
https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree". That tree was deprecated after the document was published. As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.

regards,

Ted Hardie

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

--

Aoyama Gakuin University

252-5258 Japan

dispatch mailing list

[email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Jul 2020 21:36:20 -0500

Hi Tim,

Do you plan to submit an internet-draft? If so, please be advised that the deadline for drafts prior to IETF108 is this coming Monday (7/13). If you submit a draft prior to the deadline, we can consider it along with Ted’s draft (either on the list or possibly in the IETF108 DISPATCH meeting).

Thanks,

Ben.

> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <[email-masked]> wrote:
> 
> Hi All,
> 
>> On July 7, 2020 at 3:34 AM "Martin J. Dürst" < [email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < [email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Howdy,
>>>> 
>>>> This is one the shortest drafts I've ever written: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/> <https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ <https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/>> .. Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree". That tree was deprecated after the document was published. As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
>>> 
>> 
>> --
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>_______________________________________________
> dispatch mailing list
> [email-masked]

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 9 Jul 2020 10:20:10 -0400 (EDT)

Hi Ben,

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this at all with pending

registrations and I obviously disagree with that.  But if there are more than 5 people besides Ted that think the current rules for provisionals in the zone are

too open and need to be further constrained then I will submit a draft that does

just that before the deadline.

On July 8, 2020 at 10:36 PM Ben Campbell <[email-masked]> wrote:

Hi Tim,

Thanks,

Ben.

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <
[email-masked]> wrote:

Hi All,

"simple administrative".

Tim

Hi Everyone,

such a preference).

Regards, Martin.

Thanks!

Ben (as co-chair)

Howdy,

This is one the shortest drafts I've ever written:
https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <
https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree". That tree was deprecated after the document was published. As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.

regards,

Ted Hardie

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

--

Aoyama Gakuin University

252-5258 Japan

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 9 Jul 2020 08:57:34 -0700

Howdy,

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <[email-masked]> wrote:

> registrations and I obviously disagree with that.  But if there are more
> than 5 people besides Ted that think the current rules for provisionals in
> the zone
>

I don't think I've seen anyone but you argue that the current rules permit
provisionals in the zone; if I have missed others reading the rules that
way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity on what the
rules should be after the elimination of the IETF tree.  Since you
obviously disagree with my proposal, having your alternative spelled in a
draft does seem like the best way forward.  Wherever dispatch sends the
question would then have two clear proposals to choose between.

regards,

Ted Hardie

> are
> Do you plan to submit an internet-draft? If so, please be advised that the
> deadline for drafts prior to IETF108 is this coming Monday (7/13). If you
> submit a draft prior to the deadline, we can consider it along with Ted’s
> draft (either on the list or possibly in the IETF108 DISPATCH meeting).
>
> Thanks,
>
> Ben.
>
> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < [email-masked]>
> wrote:
>
> Hi All,
>
> But, I may have a work around that is simple and also solves the
> provisional registration problem as stated by Ted.  I could have ready in a
> day or so.
>
> Tim
>
> On July 7, 2020 at 3:34 AM "Martin J. Dürst" < [email-masked]>
> wrote:
>
>
> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com
> <[email-masked]>> wrote:
>
> Howdy,
>
> https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/
> <https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/>>
> published.. As it happens, there are very few registrations in URI.ARPA, so

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 9 Jul 2020 13:28:57 -0400 (EDT)

Ted,

Section 2 (Updated Requirements) of your draft says:

"All registrations in URI.ARPA MUST be for schemes which are permanent registrations, as they are described in BCP 35."

I take that as:

We must update this because permanent registrations are not required.  Otherwise there is no reason for an update.

If you are going to argue both sides, my draft and I will just stay out of it.  Here is your pointer.
https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2

Tim

On July 9, 2020 at 11:57 AM Ted Hardie <[email-masked]> wrote:

Howdy,

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <
[email-masked]> wrote:

Hi Ben,

registrations and I obviously disagree with that.  But if there are more than 5 people besides Ted that think the current rules for provisionals in the zone

I don't think I've seen anyone but you argue that the current rules permit provisionals in the zone; if I have missed others reading the rules that way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity on what the rules should be after the elimination of the IETF tree.  Since you obviously disagree with my proposal, having your alternative spelled in a draft does seem like the best way forward.  Wherever dispatch sends the question would then have two clear proposals to choose between.

regards,

Ted Hardie

are

On July 8, 2020 at 10:36 PM Ben Campbell <
[email-masked]> wrote:

Hi Tim,

Thanks,

Ben.

Hi All,

"simple administrative".

Tim

Hi Everyone,

such a preference).

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <
ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever written:
https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <
https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree". That tree was deprecated after the document was published.. As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.

regards,

Ted Hardie

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

--

Aoyama Gakuin University

252-5258 Japan

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 9 Jul 2020 12:09:30 -0700

On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <[email-masked]>
wrote:

> "All registrations in URI.ARPA MUST be for schemes which are permanent
> registrations, as they are described in BCP 35."
>
> I take that as:
> We must update this because permanent registrations are not required.
> Otherwise there is no reason for an update.
>

The reason for the update is that IETF tree registrations *are* required.
That effectively closes the registry, without the community having made the
affirmative decision to do so.  I want to fix that bug.

I currently think that the closest replacement to the IETF tree would be
permanent registration and that we should fix this by requiring that.  But
I'm happy to see a clear draft espousing some other way of fixing the bug;
if you have an idea about that, please write the draft.

regards,

Ted

> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < [email-masked]>
> wrote:
>
> Hi Ben,
>
> On July 8, 2020 at 10:36 PM Ben Campbell < [email-masked]> wrote:
>
> Hi Tim,
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 9 Jul 2020 15:43:38 -0400 (EDT)

You're talking about the [
10] reference in section
3.1.1 in 3405 and when I click on the reference it sends me right to
BCP35.

>The reason for the update is that IETF tree registrations *are* required.

That is now, scheme registration is required, including provisionals.  See, no bug.

Tim

On July 9, 2020 at 3:09 PM Ted Hardie <[email-masked]> wrote:

On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <
[email-masked]> wrote:

Ted,

I take that as:

The reason for the update is that IETF tree registrations *are* required.  That effectively closes the registry, without the community having made the affirmative decision to do so.  I want to fix that bug.

I currently think that the closest replacement to the IETF tree would be permanent registration and that we should fix this by requiring that.  But I'm happy to see a clear draft espousing some other way of fixing the bug; if you have an idea about that, please write the draft.

regards,

Ted

Tim

On July 9, 2020 at 11:57 AM Ted Hardie <
[email-masked]> wrote:

Howdy,

Hi Ben,

regards,

Ted Hardie

are

Hi Tim,

Thanks,

Ben.

Hi All,

"simple administrative".

Tim

Hi Everyone,

such a preference).

Regards, Martin.

Thanks!

Ben (as co-chair)

Howdy,

regards,

Ted Hardie

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

--

Aoyama Gakuin University

252-5258 Japan

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 9 Jul 2020 13:03:52 -0700

On Thu, Jul 9, 2020 at 12:43 PM Timothy Mcsweeney <[email-masked]>
wrote:

> You're talking about the [ 10 <https://tools.ietf.org/html/rfc3405#ref-10>]
> reference in section 3.1.1 in 3405
> <https://tools.ietf.org/html/rfc3405#section-3.1.1> and when I click on
> the reference it sends me right to BCP35
> <https://tools.ietf.org/html/bcp35>.
>
Quite simply, that's not what the document says.  The previous effort to
simply re-interpret it (see https://www.rfc-editor.org/errata/eid2842) was
already rejected.

regards,

Ted

> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < [email-masked]>
> wrote:
>
> Ted,
>
> On July 9, 2020 at 11:57 AM Ted Hardie < [email-masked]> wrote:
>
> Howdy,
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 9 Jul 2020 16:31:00 -0400 (EDT)

Yeah I looked at that a month ago already but unfortunately it doesn't matter if you change the reference from [10] to [11] it still goes to BCP35.  Still no bug :-)

On July 9, 2020 at 3:43 PM Timothy Mcsweeney <[email-masked]> wrote:

Tim

Ted,

I take that as:

regards,

Ted

If you are going to argue both sides, my draft and I will just stay out of it.  Here is your pointer.
https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2

Tim

Howdy,

Hi Ben,

regards,

Ted Hardie

are

Hi Tim,

Thanks,

Ben.

Hi All,

"simple administrative".

Tim

Hi Everyone,

The ART ADs have reminded the chairs that our charter allows us to adopt “simple administrative” work such as IANA registration documents. This draft seems to fit squarely in that category.. Does anyone see a reason we shouldn’t just adopt it, with the expectation of going immediately to WGLC? (The last-call timeline is the same either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD sponsored draft.)

such a preference).

Regards, Martin.

Thanks!

Ben (as co-chair)

Howdy,

This is one the shortest drafts I've ever written:
https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <
https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree". That tree was deprecated after the document was published... As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.

regards,

Ted Hardie

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

--

Aoyama Gakuin University

252-5258 Japan

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

dispatch mailing list

[email-masked]

_______________________________________________ dispatch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ben Campbell <[email-masked]>
Date: Thu, 9 Jul 2020 15:49:27 -0500

(as individual)

I believe Ted refers to the sentence that says "In order to be inserted into the URI.ARPA zone, the subsequent URI scheme MUST be registered under the IETF URI tree.”  The fact that the following sentence makes a now incorrect statement about the content of  [BCP35] does not mitigate the problem, nor does it change the MUST in the previous sentence.

So IMO, Ted is correct, there is a bug.

Ben.

So I agree with Ted’s interpretation that there is in fact a bug.

> On Jul 9, 2020, at 3:31 PM, Timothy Mcsweeney <[email-masked]> wrote:
> 
>> You're talking about the [ 10] reference in section 3.1.1 in 3405 and when I click on the reference it sends me right to BCP35.
>> 
>>> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < [email-masked]> wrote: 
>>> Ted, 
>>> 
>>> If you are going to argue both sides, my draft and I will just stay out of it.  Here is your pointer.   https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2
>>> 
>>> Tim
>>> 
>>> 
>>>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < [email-masked]> wrote: 
>>>> Hi Ben, 
>>>> 
>>>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < [email-masked]> wrote:
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>>> On July 7, 2020 at 3:34 AM "Martin J. Dürst" < [email-masked]> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com> wrote:
>>>>>>>>> 
>>>>>>>>> Howdy,
>>>>>>>>> 
>>>>>>>>> This is one the shortest drafts I've ever written: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree". That tree was deprecated after the document was published... As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now.
>>>>>>>>>

---

From: Martin J. Dürst <[email-masked]>
Date: Sun, 12 Jul 2020 20:43:39 +0900

On 10/07/2020 04:43, Timothy Mcsweeney wrote:
> <https://tools.ietf.org/html/rfc3405#section-3.1.1> and when I click on the
> reference it sends me right to BCP35 <https://tools.ietf.org/html/bcp35>.

When I look at

    [10]  Petke, R. and I. King, "Registration Procedures for URL Scheme
          Names", BCP 35, RFC 2717, January 1999.
it has two links, one for BCP 35 (which now redirects to something else 
which doesn't actually match the reference data) and one for RFC 2717 
(which matches the original reference, including author and date of 
publication).

RFC 2717 then says:

2.2 The IETF Tree

    The IETF tree is intended for URL schemes of general interest to the
    Internet community.  The tree exists for URL schemes that require a
    substantive review and approval process.  It is expected that
    applicability statements for particular applications will be
    published from time to time that recommend implementation of, and
    support for, URL schemes that have proven particularly useful in
    those contexts.

>   >The reason for the update is that IETF tree registrations *are* required.

Yes, and the closest to that ("URL schemes of general interest to the
Internet community", "require a substantive review and approval 
process") we currently have is permanent registration, so that's where 
Ted's proposal (which I fully support) comes from.

> That is now, scheme registration is required, including provisionals.  See, no bug.

No. That there's a link somewhere doesn't mean you can interpret things 
any which way. The reference you follow (in one specific way) comes from

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

This means that the reference is for defining the requirements of the 
IETF URI tree. The current BCP 35 doesn't contain such requirements, and 
therefore doesn't make any sense. The old BCP 35 (RFC 2717) is clear, 
but is no longer in force. As a consequence, we have a dangling 
reference (IETF Tree is no longer defined in a valid IETF spec). We 
cannot just say "let's assume this means whatever suits me best" or "by 
chance there's a link (out of two) that leads to a spec that includes 
something that suits me", but we have to recognize that we have a 
problem with the spec (when updating BCP 35, its authors forgot to 
update RFC 3405), and have to fix that.

And the fix that Ted is proposing is the fix that is closest to the 
original intent, and takes into account the reason for the original 
restriction.

Regards,   Martin.

>> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < [email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     __
>>     Ted,
>>
>> permanent registration and that we should fix this by requiring that.  But I'm 
>> happy to see a clear draft espousing some other way of fixing the bug; if you 
>> have an idea about that, please write the draft.
>>
>> regards,
>>
>> Ted
>>
>>
>>
>>
>>
>>     <https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2>
>>
>>
>>     Tim
>>
>>
>>>     On July 9, 2020 at 11:57 AM Ted Hardie < [email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>     Howdy,
>>>
>>>     On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < [email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>         __
>>>         Hi Ben,
>>>
>>>         registrations and I obviously disagree with that.  But if there are
>>>         more than 5 people besides Ted that think the current rules for
>>>         provisionals in the zone
>>>
>>>
>>>     I don't think I've seen anyone but you argue that the current rules
>>>     permit provisionals in the zone; if I have missed others reading the
>>>     rules that way, I'd appreciate a pointer.
>>>
>>>>         On July 8, 2020 at 10:36 PM Ben Campbell < [email-masked]
>>>>         <mailto:[email-masked]>> wrote:
>>>>
>>>>         Hi Tim,
>>>>
>>>>         Do you plan to submit an internet-draft? If so, please be advised
>>>>         that the deadline for drafts prior to IETF108 is this coming Monday
>>>>         (7/13). If you submit a draft prior to the deadline, we can consider
>>>>         it along with Ted’s draft (either on the list or possibly in the
>>>>         IETF108 DISPATCH meeting).
>>>>
>>>>         Thanks,
>>>>
>>>>         Ben.
>>>>
>>>>>         On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < [email-masked]
>>>>>         <mailto:[email-masked]>> wrote:
>>>>>
>>>>>         Hi All,
>>>>>
>>>>>         provisional registration problem as stated by Ted.  I could have
>>>>>         ready in a day or so.
>>>>>
>>>>>         Tim
>>>>>>         [email-masked] <mailto:[email-masked]..jp>> wrote:
>>>>>>
>>>>>>
>>>>>>>         The ART ADs have reminded the chairs that our charter allows us
>>>>>>>         to adopt “simple administrative” work such as IANA registration
>>>>>>>         documents. This draft seems to fit squarely in that category..
>>>>>>>         Does anyone see a reason we shouldn’t just adopt it, with the
>>>>>>>         expectation of going immediately to WGLC? (The last-call timeline
>>>>>>>         is the same either way, either 2 weeks WGLC and 2 weeks IETF LC
>>>>>>>         for a working group draft, or 4 weeks IETF LC for an AD sponsored
>>>>>>>         draft.)
>>>>>>
>>>>>>>>         <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>         Howdy,
>>>>>>>>
>>>>>>>>         https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/
>>>>>>>>         <https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/>
>>>>>>>>         <
>>>>>>>>         https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/>
>>>>>>>>         .. Basically, RFC 3405 used to require that registrations in
>>>>>>>>         URI.ARPA be from the "IETF Tree". That tree was deprecated after
>>>>>>>>         the document was published... As it happens, there are very few
>>>>>>>>         registrations in URI.ARPA, so we did not catch it and fix it
>>>>>>>>         before now.
>>>>>>>>

---

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

Martin,

>The current BCP 35 doesn't contain such requirements, and

>therefore doesn't make any sense.

That's right, BCP doesn't contain such requirements.

Whether or not makes sense to you is immaterial.

Thank you for helping me state my case.

Tim

On July 12, 2020 at 7:43 AM "Martin J. Dürst" <
[email-masked]> wrote:

You're talking about the [ 10 <
]" rel="noopener" target="_blank" data-mce-href="https://tools.ietf.org/html/rfc3405#ref-10>]">https://tools.ietf.org/html/rfc3405#ref-10>]

<
https://tools.ietf.org/html/rfc3405#section-3.1.1> and when I click on the

reference it sends me right to BCP35 <
" rel="noopener" target="_blank" data-mce-href="https://tools.ietf.org/html/bcp35>">https://tools.ietf.org/html/bcp35>.

When I look at

publication).

RFC 2717 then says:

2.2 The IETF Tree

those contexts.

restriction.

Regards, Martin.

Tim

>> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <
[email-masked]

>> If you are going to argue both sides, my draft and I will just stay out of

>> it. Here is your pointer.

https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2>

>>> On July 9, 2020 at 11:57 AM Ted Hardie <
[email-masked]

>>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <
[email-masked]

>>> I am a little surprised that you are choosing to discuss this at all

>>> with pending

>>> too open and need to be further constrained then I will submit a

>>> draft that does

>>>> On July 8, 2020 at 10:36 PM Ben Campbell <
[email-masked]

>>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <
[email-masked]

>>>>> Updating RFC3405 will necessarily require changes to RFC3401 as

>>>>> stated in its

>>>>> introduction. "This document will be updated and or obsoleted when

>>>>> changes

[email-masked] <mailto:
[email-masked]..jp>> wrote:

>>>>>> Triggered by the recent discussion, I had a look at Ted's draft

>>>>>> and the

>>>>>> reasonable, with a slight preference for the former (if asked to

>>>>>> express

>>>>>> relevant, in particular because the thing in question isn't

>>>>>> actually a

>>>>>> "This document removes references to the IETF tree of URI

>>>>>> registrations

>>>>>> for registrations in URI.ARPA.". I found this hard to read, and I

>>>>>> guess

>>>>>> it's because of the "registrations for registrations" piece.

>>>>>> Unless one

>>>>>> is very familiar with the matter at hand, it's easy to think that

>>>>>> both

>>>>>> occurrences of "registration" are referencing the same thing.

>>>>>> While I'm

>>>>>> positive. I think a less normative version of (the single sentence

>>>>>> that

>>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie <
ted.ietf@gmail..com

>>>>>>>> This draft updates RFC 3405 to require "permanent" scheme

>>>>>>>> registrations. The salient bit is this:

>>>>>>>> All registrations in URI.ARPA MUST be for schemes which are

>>>>>>>> permanent

[email-masked] <mailto:
[email-masked]>

[email-masked] <mailto:
[email-masked]>

[email-masked] <mailto:
[email-masked]>

[email-masked] <mailto:
[email-masked]>

[email-masked] <mailto:
[email-masked]>

dispatch mailing list

[email-masked]

--

Aoyama Gakuin University

252-5258 Japan