Re: [dispatch] Tiny update to RFC 3405

Howdy,

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <tim@dropnumber.com> 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
>

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
> 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 <ben@nostrum.com> 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 < tim@dropnumber.com>
> 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" < duerst@it.aoyama.ac.jp>
> 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 < ted.ietf@gmail..com
> <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.
>
> 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
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> 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
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>