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

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:46:25 -0500 (EST)

text version:
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 07/07/2020 10:03 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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:
> > 
> > 
> > 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
> > 
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:47:04 -0500 (EST)

text version:
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 07/09/2020 10:20 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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,
> > 
> > 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,
> > > 
> > > > > > 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/)> .. 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: Wed, 11 Nov 2020 11:48:06 -0500 (EST)

text version:
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 07/09/2020 1:28 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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,
> > > > 
> > > > > > > > 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/ (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: Wed, 11 Nov 2020 11:49:35 -0500 (EST)

text version:
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 07/09/2020 3: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).
> 
> >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,
> > > 
> > 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 July 9, 2020 at 11:57 AM Ted Hardie < [email-masked]> wrote: 
> > > > 
> > > > 
> > > > Howdy, 
> > > > 
> > > >

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:50:18 -0500 (EST)

text version:
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 07/09/2020 4:31 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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: 
> > 
> > 
> > > > 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 (https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2)
> > > > 
> > > > Tim
> > > > 
> > > > 
> > > > > > > > > > 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.)
> > > > > > > > > 
> > > > > > > > > > > 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/> .. 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.
> > > > > > > > > > > 
> > _______________________________________________ dispatch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dispatch
> 
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 11:51:32 -0500 (EST)

text version:
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 07/13/2020 9:33 AM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> 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:
> > 
> > 
> > On 10/07/2020 04:43, Timothy Mcsweeney 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#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 < " rel="noopener" target="_blank" data-mce-href="https://tools.ietf.org/html/bcp35>">https://tools.ietf.org/html/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.
> > >>>>
> > 
> > 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.
> > 
> > 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.
> > 
> > 
> > > 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]
> > >> <mailto: [email-masked]>> wrote:
> > >>
> > >> __
> > >> Ted,
> > >>
> > >> "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.
> > >>
> > >>
> > >> 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
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 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
> > >> < 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.
> > >>>
> > >>> 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]
> > >>>> <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,
> > >>>>>
> > >>>>> 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] <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.)
> > >>>>>>
> > >>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com
> > >>>>>>>> <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/>
> > >>>>>>>> .. 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]>
> > >>>>>>> [email-masked] <mailto: [email-masked]>
> > >>>>>> [email-masked] <mailto: [email-masked]>
> > >>>>> [email-masked] <mailto: [email-masked]>
> > >>> [email-masked] <mailto: [email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Nov 2020 08:55:31 -0800

Timothy,

You have sent quite a few messages to this list on this topic in the past
hour. However, this draft has already been approved by the IESG and is in
the RFC Editor queue, so further discussion on this topic on dispatch is
not really productive. What are you trying to achieve?

-Ekr

On Wed, Nov 11, 2020 at 8:52 AM Timothy Mcsweeney <[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#ref-10)
> > > > 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> (https://tools.ietf.org/html/bcp35).
> > > When I look at
> > >
> > > >>>>
> > > >> https://www.ietf.
> .org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2
> > > >> <
> https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2
> >
> > > >>
> > > >>
> > > >> Tim
> > > >>
> > > >>
> > > >>> I am a little surprised that you are choosing to discuss this at
> all
> > > >>> with pending
> > > >>>>> introduction. "This document will be updated and or obsoleted
> when
> > > >>>>> changes
> > > >>>>>> for registrations in URI.ARPA.". I found this hard to read, and
> I
> > > >>>>>> guess
> > > >>>>>> is very familiar with the matter at hand, it's easy to think
> that
> > > >>>>>> both
> > > >>>>>> positive. I think a less normative version of (the single
> sentence
> > > >>>>>> that
> > > >>>>>>>> < https://datatracker.ietf.
> .org/doc/draft-hardie-dispatch-rfc3405-update/>
> > > >>>>>>>> <
> > > >>>>>>>> https://datatracker.ietf.
> ..org/doc/draft-hardie-dispatch-rfc3405-update/>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 11 Nov 2020 12:09:58 -0500 (EST)

> On 08/05/2020 4:41 PM Timothy Mcsweeney <[email-masked]> wrote:
> 
> 
> Hi Ted,
> 
> In the abstract of your most recent draft.....how about using "...from Sections 3 & 6..." instead of "...from the procedures..."? I wouldn't want anyone to confuse it with the sections that use the word procedures.
> 
> Tim
> 
> 
> 
> > On July 9, 2020 at 4:03 PM Ted Hardie <[email-masked]> wrote: 
> > 
> > 
> > On Thu, Jul 9, 2020 at 12:43 PM Timothy Mcsweeney < [email-masked]> wrote: 
> > 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 
> > 
> > 
> > 
> > > 
> > > 
> > >

---

From: Ben Campbell <[email-masked]>
Date: Wed, 11 Nov 2020 11:10:48 -0600

I’m not sure, but I think something just resent a big dump of old emails from Timothy.

> On Nov 11, 2020, at 10:55 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Timothy,
> 
> You have sent quite a few messages to this list on this topic in the past hour. However, this draft has already been approved by the IESG and is in the RFC Editor queue, so further discussion on this topic on dispatch is not really productive. What are you trying to achieve?
> 
> -Ekr
> 
> 
> On Wed, Nov 11, 2020 at 8:52 AM Timothy Mcsweeney <[email-masked] <mailto:[email-masked]>> wrote:
> text version:
> Martin, 
> 
> > On 07/13/2020 9:33 AM Timothy Mcsweeney <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> > Martin,
> > 
> > > On July 12, 2020 at 7:43 AM "Martin J. Dürst" < [email-masked] <mailto:[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#ref-10 <https://tools.ietf.org/html/rfc3405#ref-10>>] (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 <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>>">https://tools.ietf.org/html/bcp35 <https://tools.ietf.org/html/bcp35>> (https://tools.ietf.org/html/bcp35 <https://tools.ietf.org/html/bcp35>).
> > > When I look at
> > > 
> > > >>>>
> > > > > On July 9, 2020 at 3:09 PM Ted Hardie < [email-masked] <mailto:[email-masked]>> wrote:
> > > >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>
> > > >> <mailto: [email-masked] <mailto:[email-masked]>>> wrote:
> > > >>
> > > >> __
> > > >> Ted,
> > > >>
> > > >> https://www.ietf. <https://www.ietf./>.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2
> > > >> < https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2 <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]>
> > > >>> <mailto: [email-masked] <mailto:[email-masked]>>> wrote:
> > > >>>
> > > >>> Howdy,
> > > >>>
> > > >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>
> > > >>> <mailto: [email-masked] <mailto:[email-masked]>>> wrote:
> > > >>>
> > > >>> __
> > > >>> Hi Ben,
> > > >>>
> > > >>>> On July 8, 2020 at 10:36 PM Ben Campbell < [email-masked] <mailto:[email-masked]>
> > > >>>> <mailto: [email-masked] <mailto:[email-masked]>>> wrote:
> > > >>>>
> > > >>>> Hi Tim,
> > > >>>>
> > > >>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>
> > > >>>>> <mailto: [email-masked] <mailto:[email-masked]>>> wrote:
> > > >>>>>
> > > >>>>> Hi All,
> > > >>>>>
> > > >>>>>> [email-masked] <mailto:[email-masked]> <mailto: [email-masked]..jp>> wrote:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>> <mailto: [email-masked] <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. <https://datatracker.ietf./>.org/doc/draft-hardie-dispatch-rfc3405-update/>
> > > >>>>>>>> <
> > > >>>>>>>> https://datatracker.ietf. <https://datatracker.ietf./>..org/doc/draft-hardie-dispatch-rfc3405-update/>
> > > >>>>>>>> [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>>
> > > >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>>
> > > >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>>
> > > >>>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
> > > >>>>> [email-masked] <mailto:[email-masked]> <mailto: [email-masked] <mailto:[email-masked]>>
> > > >>>>> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>
> > > >>>>
> > > >>>
> > > >>> [email-masked] <mailto:[email-masked]> <mailto: [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>