Subject: Re: [dispatch] Genart last call review of draft-hardie-dispatch-rfc3405-update-03

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 1 Sep 2020 07:04:46 -0400 (EDT)

Hello,

According to BCP26/RFC8126 section 5.3 Designated expert reviews, it says:"

When a designated expert is used, the documentation should give clear
guidance to the designated expert, laying out criteria for performing
an evaluation and reasons for rejecting a request.

I don't see the above in this document.  This is going to have to be added to have any kind of validity or the IESG should reject to publication of this document.  Especially because this entire document will updating the IANA considerations section of rfc3405.

Tim

On 08/31/2020 11:23 PM Brian Carpenter via Datatracker <[email-masked]> wrote:

Reviewer: Brian Carpenter

Review result: Ready

Gen-ART Last Call review of draft-hardie-dispatch-rfc3405-update-03

I am the assigned Gen-ART reviewer for this draft. The General Area

Review Team (Gen-ART) reviews all IETF documents being processed

by the IESG for the IETF Chair. Please treat these comments just

like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-hardie-dispatch-rfc3405-update-03

Reviewer: Brian Carpenter

Review Date: 2020-09-01

IETF LC End Date: 2020-09-24

IESG Telechat date:

Summary: Ready (with micro-nit)

--------

Nits:

-----

1. Introduction

Part five of the Dynamic Delegation Discovery System (DDDS), RFC 3405

[RFC3405], describes the registration procedures for assignments in

URI.ARPA. 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.

This is indeed a nit, but I'd prefer s/the requirement/the above requirement/.

The current text did make me briefly think "Which requirement?".

_______________________________________________

dispatch mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dispatch

---

From: Barry Leiba <[email-masked]>
Date: Tue, 1 Sep 2020 11:08:08 -0400

(Removed the GenART list, as this discussion doesn't apply to Brian's
GenART review.)

Tim, thanks for the comments.

> I don't see the above in this document.  This is going to have to be added to have any kind of
> validity or the IESG should reject to publication of this document.  Especially because this entire
> document will updating the IANA considerations section of rfc3405.

As the person who added that quoted text to BCP 26, I'm clearly in
favour of making sure that guidance to the DEs is available, and I
often push on this in my reviews as Area Director.  So I have a warm
spot for what you say here.  I this case, though, I disagree with the
conclusion that such guidance has to be explicitly added:

1. When my AD reviews push on this point, it is almost always
(possibly completely always) as a non-blocking comment, not a DISCUSS
position.  In other words, I strongly encourage the English sense of
the "should" in the quoted text, but don't insist on it.  It's not a
requirement for publication.

2. RFC 3405 pre-dates RFC 8126, and the version of BCP 26 that was in
effect at the time, RFC 2434 did not include the suggestion above.
While it's certainly possible to add such guidance now, this update is
very narrowly targeted to fix a serious problem, and I would not want
debate about additional text to get in the way of that.  There's
plenty of precedent for these sorts of laser-focused updates that do
not otherwise bring the original documents up to current standards.

3. I believe that 3405 is already clear enough in this regard in
Section 3.1.2 and doesn't require further clarification.  With this
proposed update to Section 3.1.1, we can get back to having a clear
way to register NAPTR records for URI schemes in the URI.ARPA zone.

Barry

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 1 Sep 2020 11:58:48 -0400 (EDT)

Hi Barry,

>While it's certainly possible to add such guidance now...

Possible?  It's the best current practice.  Shouldn't it be imposed?

>debate about additional text to get in the way of that.

And doesn't using this draft as an update of the entire IANA considerations section effectively remove any means of registration through the mailing lists provided in that same section??

Tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Sep 2020 22:49:09 -0700

On Tue, Sep 1, 2020 at 8:58 AM Timothy Mcsweeney <[email-masked]> wrote:

> And doesn't using this draft as an update of the entire IANA
> considerations section effectively remove any means of registration through
> the mailing lists provided in that same section??
>

This draft doesn't replace the entire IANA Considerations section of RFC
3405, but rather amends it.  That is, after this is published, to get the
full IANA Considerations for BCP 65, you would read RFC 3405 and then apply
this document as a sort of "patch".  That's what we mean when we say "RFC Y
updates RFC X", which will be the end result here.

The specific effect of this document when published is to amend Section
3.1.1 of RFC 3405 such that instead of saying "registered under the IETF
URI tree", it becomes "a registered permanent URI scheme", and then take
"tree" out of the next sentence, and rename the section to something more
appropriate.  This draft could spell out each of those edits precisely, or
just replace all of Section 3.1.1 with a new set of text, but it's such a
small change that what's here seems equivalent and unambiguous to me.

-MSK

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 2 Sep 2020 06:52:51 -0400 (EDT)

>>This draft doesn't replace the entire IANA Considerations section of RFC 3405, but rather amends it.

Oh, ok, because the draft literally says "This entire document is updated instructions to IANA."

>>This draft could spell out each of those edits precisely, or just replace all of Section 3.1.1 with a new set of text..

And it should.  There is no legitimate reason not to.

>>... seems equivalent and unambiguous to me.

No surprise here.  Maybe the IESG isn't a good fit for you.  As a matter of fact, if I were Barry I would drop sponsorship of this draft for all the reasons above.

On 09/02/2020 1:49 AM Murray S. Kucherawy <[email-masked]> wrote:

This draft doesn't replace the entire IANA Considerations section of RFC 3405, but rather amends it.  That is, after this is published, to get the full IANA Considerations for BCP 65, you would read RFC 3405 and then apply this document as a sort of "patch".  That's what we mean when we say "RFC Y updates RFC X", which will be the end result here.

The specific effect of this document when published is to amend Section 3.1.1 of RFC 3405 such that instead of saying "registered under the IETF URI tree", it becomes "a registered permanent URI scheme", and then take "tree" out of the next sentence, and rename the section to something more appropriate.  This draft could spell out each of those edits precisely, or just replace all of Section 3.1.1 with a new set of text, but it's such a small change that what's here seems equivalent and unambiguous to me.

-MSK

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

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 2 Sep 2020 09:33:53 -0700

I'm just a random bystander, but

On Wed, Sep 2, 2020 at 3:53 AM Timothy Mcsweeney <[email-masked]> wrote:

> No surprise here.  Maybe the IESG isn't a good fit for you.  As a matter
> of fact, if I were Barry I would drop sponsorship of this draft for all the
> reasons above.
>

breaks the rules in https://tools.ietf.org/html/rfc7154#section-2 for how
to discuss issues. Please don't make personal attacks.

Thanks,
Jeffrey

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Sep 2020 10:41:50 -0700

To reply to the text change in particular:

On Wed, Sep 2, 2020 at 3:52 AM Timothy Mcsweeney <[email-masked]> wrote:

>
> >>This draft could spell out each of those edits precisely, or just
> replace all of Section 3.1.1 with a new set of text..
>

You would prefer changing this:

2.  Updated Requirements

   This document removes the normative requirement from RFC 3405 for
   registrations in URI.ARPA to be from the IETF URI Tree.

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

to something like this:

2. Updated section 3.1.1 for RFC 3405

The following text replaces section 3.1.1 of RFC 3405:

   3.1.1 Only permanent URI registrations allowed.

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

Is that right?

regards,

Ted Hardie

> -- last-call mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 2 Sep 2020 13:44:23 -0400 (EDT)

Jeffrey, I sent you a DM.  I would have rather posted my reply to the modeartors email here on this list but I'm not sure if that would have broken the same rule several more times.

Tim

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 2 Sep 2020 15:55:54 -0400 (EDT)

>Is that right?

The first thing I would change in your draft is from this:

3. IANA Considerations

This entire document is updated instructions to IANA.

To this:
3. IANA Considerations

This update does not change the IANA Considerations in RFC 3405

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Sep 2020 08:34:34 +1200

On 03-Sep-20 05:41, Ted Hardie wrote:
> On Wed, Sep 2, 2020 at 3:52 AM Timothy Mcsweeney <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     __
> 

Re-assuming my hat as a Gen-ART reviewer for this draft, I think that this
change would be a mistake, as it no longer explicitly  informs the reader
what has been changed in RFC 3405.

If we really want to be precise, I suggest:

2.  Updated Requirements
 
   This document removes the normative requirement from section 3.1.1
   of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree.

Regards
   Brian

>>     On 09/02/2020 1:49 AM Murray S. Kucherawy <[email-masked] <mailto:[email-masked]>> wrote:
>>      
>>      
>>     On Tue, Sep 1, 2020 at 8:58 AM Timothy Mcsweeney <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     -- last-call mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/last-call 
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Sep 2020 13:47:57 -0700

Hi Timothy,

That change would not match the rest of the document, because it does
change the IANA considerations.  Given our previous conversations, I assume
you mean by this that you oppose the changes.  I think the clearest way to
register that opposition is simply to oppose publication. Barry and the
IESG will have to determine which is the consensus position.

If I have misunderstood you, I would be happy to hear how to reconcile the
proposed text below with the rest of the text in RFC 3405 and this document.

regards,

Ted HArdie

On Wed, Sep 2, 2020 at 12:55 PM Timothy Mcsweeney <[email-masked]>
wrote:

>  <https://tools.ietf.org/html/draft-hardie-dispatch-rfc3405-update-03#section-3>
>
>
>

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 2 Sep 2020 17:55:16 -0400 (EDT)

Ted,

> I think the clearest way to register that opposition is simply to oppose publication.

I want to help you improve this document.

Tim

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 06:00:47 -0400 (EDT)

Hi Brian,

>permanent registrations, as they are described in BCP 35.

In the interest of brevity, we probably don't really need that second sentence.  And it might help to open things up a bit.

Tim

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 06:14:34 -0400 (EDT)

Hi Brian,

>permanent registrations, as they are described in BCP 35.

Sorry, I want to make my last comment more clear.

In the interest of brevity, we probably don't really need that second sentence.  And its removal might help to open things up a bit.  So section two would now look like:

2. Updated Requirements

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Sep 2020 13:50:25 +0000

*   In the interest of brevity, we probably don't really need that second sentence.  And it might help to open things up a bit.

Strongly disagree.  We don’t want to open things up a bit.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 3 Sep 2020 09:14:05 -0500

> On Sep 3, 2020, at 5:14 AM, Timothy Mcsweeney <[email-masked]> wrote:
> 
> Hi Brian,
>  

I disagree with that change. 

The sentence you propose to remove is one of the main points of the document. Dropping that requirement would, for all material purposes, give us an IANA registration policy of FCFS. I don’t think it’s appropriate to add schemes to the URI.ARPA zone without substantive review.

Ben.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 10:41:31 -0400 (EDT)

>Strongly disagree.  We don’t want to open things up a bit.

Who is we?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Sep 2020 15:10:24 +0000

*   >Strongly disagree.  We don’t want to open things up a bit.
  *   Who is we?
 Tim, I don’t think you are participating in good faith.  Please stop.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 11:26:15 -0400 (EDT)

>I don’t think you are participating in good faith. Please stop

Rich, you have to attack the ball and not the player.

But to your point, I am acting in good faith.

>We don’t want to open things up a bit.

I am trying to open up an standard that is closed so tight that nobody has used in almost twenty years.  As best I can tell, all those who are opposing me have never, and will most likely never have any interest in presenting a new uri for that registry.  That fact should give my opinion at least equal weight in this debate.

Tim

---

From: Ben Campbell <[email-masked]>
Date: Thu, 3 Sep 2020 10:49:50 -0500

> On Sep 3, 2020, at 10:26 AM, Timothy Mcsweeney <[email-masked]> wrote:
> 

There have been new permanent registrations as recently as 2018. That’s demonstrably more open that the original “IETF Tree” requirement, which was impossible to meet.

Ben.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 12:00:56 -0400 (EDT)

We are talking about URI.ARPA Ben

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 12:01:36 -0400 (EDT)

Hi Ben,

>I don’t think it’s appropriate to add schemes to the URI.ARPA zone without substantive review.

Why do you say that?  If all the DDDS rules are followed the records entered into the zone should not have any technical problems.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 12:02:49 -0400 (EDT)

>The sentence you propose to remove is one of the main points of the document.

Not really.  Its a sub-point of a sub-point of a main point....just like 3.1.2.  Come to think of it, I'm working on some language for 3.1.2 also.  So for now the document would look like this:

2. Updated Requirements

This document removes the normative requirements from section 3.1.1

of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree

and 3.2.1

3. IANA Considerations

This update does not change the IANA updates in RFC 3405

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2020 20:31:00 +0200

Am 03.09.2020 um 12:00 schrieb Timothy Mcsweeney:
> In the interest of brevity, we probably don't really need that second
> sentence.  And it might help to open things up a bit.
> Tim

So even if that sentence was gone, you still wouldn't be able to
register something that has not been registered as a URI scheme, because
of <https://tools.ietf.org/html/rfc3405#section-3> saying "The creation
of a given URI scheme or URN namespace id (NID) follows the appropriate
registration documents for those spaces."   (Or am I missing something?).

How would that help you for your use case?

Best regards, Julian

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 14:49:18 -0400 (EDT)

Hi Julian,

>registration documents for those spaces." (Or am I missing something?).

That is clarified with the procedures from next sentence in that paragraph.  (URI schemes

follow "Registration Procedures for URL Scheme Names" (RFC 2717) [10].)

>How would that help you for your use case?

I already have a registered scheme name.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 14:53:17 -0400 (EDT)

>How would that help you for your use case?

Maybe 'URI scheme'  in that first sentence should be changed to 'URI scheme name.  Does that sound good to you Julian?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 3 Sep 2020 21:06:39 +0200

Am 03.09.2020 um 20:53 schrieb Timothy Mcsweeney:
>  >of <https://tools.ietf.org/html/rfc3405#section-3
> <https://tools.ietf.org/html/rfc3405#section-3>> saying "The creation
> Maybe 'URI scheme'  in that first sentence should be changed to 'URI
> scheme name.  Does that sound good to you Julian?

I actually believe that we shouldn't register things as URIs which are
not URIs. But maybe I'm in the rough here.

Best regards, Julian

---

From: Timothy Mcsweeney <[email-masked]>
Date: Thu, 3 Sep 2020 15:13:44 -0400 (EDT)

>not URIs. But maybe I'm in the rough here.

So do you think we should add that clarification for future generations or just leave how it is?

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 8 Sep 2020 11:49:52 -0400 (EDT)

How about:

2. Updated Requirements

This document removes and replaces the normative requirements from sections 3.1.1

and section 3.1.2 of RFC3405 with:

The registration of a NAPTR record for a URI scheme MUST NOT precede registration of that scheme.  IANA will review the request against for

1. correctness and technical soundness (eg. valid databases, service parameters etc.) and

2. consistency with the published URI resolution application specification, and

3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain.

3. IANA Considerations

This update does not change the IANA submission procedure in Section 5 of RFC 3405.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Sep 2020 17:15:31 +0000

Does anyone else feel this way? I am opposed.

It *appears* that this change removes the requirement for proper URI’s, or at least moves the responsibility to IANA, which is hired staff.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Sep 2020 12:37:25 -0500

> On Sep 8, 2020, at 12:15 PM, Salz, Rich <[email-masked]> wrote:
> 

I continue to oppose any approach that removes the requirement that the URI scheme itself go through an expert review. It seems appropriate that such review happen at the time of scheme registration (as opposed to the time of requesting inclusion in uri.arpa).  The requirement for permanent registration of the scheme gives us that.

There may be other ways to achieve the same thing, but they would almost certain require more complicated specification changes than simply saying “The scheme MUST be permanently registered”.

Ben.

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 09 Sep 2020 09:10:58 +1000

On Wed, Sep 9, 2020, at 03:37, Ben Campbell wrote:
>> It **appears** that this change removes the requirement for proper URI’s, or at least moves the responsibility to IANA, which is hired staff.
> 

I agree with Rich and Ben here  - the IETF takes responsibility for uri.arpa, and hence has an interest in the quality of what is registered there.  This means that expert review is appropriate to ensure that everything that we take responsibility for works well together.

We do not have a responsibility to allow arbitrary registration that goes against the technical judgement of our designated experts just because those registrants want it.

For these reasons I support the publication of draft-hardie-dispatch-rfc3405-update-03 with its current wording.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 9 Sep 2020 05:44:27 -0400 (EDT)

I'm not sure what was meant by Rich's comment about IANA being hired staff but, when it comes to the DDDS,

you really can't get any more expert in an review without them.  They already:

1. manage the zone

2. manage the name registration

3. manage the submission procedure

4. manage the list for vetting registrations in the zone

5. have an engineering team to report any technical problems

On 09/08/2020 1:37 PM Ben Campbell <[email-masked]> wrote:

Ben.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Sep 2020 14:52:14 +0000

*   I'm not sure what was meant by Rich's comment about IANA being hired staff

They are not experts.  They are hired to do administrative stuff. The things you list do not require technical expertise, but rather operational expertise.  That’s not to denigrate ops, of course.

I am a member of the TLS designated experts, so I know first-hand how expert review works.

So far you are the only one trying to remove it.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 9 Sep 2020 11:29:07 -0400 (EDT)

>They are not experts.  They are hired to do administrative stuff. The things you list do not require technical expertise, but rather >operational expertise.  That’s not to denigrate ops, of course.

Of course.

>I am a member of the TLS designated experts, so I know first-hand how expert review works.

I have very limited experience with expert reviews, which part of the naptr record worries you most?  Beyond that I'm not sure what needs a review.

>So far you are the only one trying to remove it.

Well, at the moment, there is no designated expert for for uri.arpa so anything incoming would have to be reviewed by the IESG.  That seems like a waste of resources for them to look at some regex.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 Sep 2020 16:13:48 +0000

*   I have very limited experience with expert reviews, which part of the naptr record worries you most?  Beyond that I'm not sure what needs a review.
 Not having an expert review bothers me.

  *   Well, at the moment, there is no designated expert for for uri.arpa so anything incoming would have to be reviewed by the IESG.  That seems like a waste of resources for them to look at some regex.

They seem okay with it.

I think this conversation thread has run its course unless you can find someone else who agrees with you.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Sep 2020 12:58:49 +1200

> They are not experts.  They are hired to do administrative stuff. The things you list do not require technical expertise, but rather operational expertise.  That’s not to denigrate ops, of course.

In fairness to our friends and colleagues at IANA, what they do is not just
administrative. Yes, the end product is clerical if you like - updating a very
large set of on-line registries. Yes, they take instructions from the IESG and
the designated experts. No, they don't claim to be protocol designers. But
their work is non-trivial, involves understanding and often debugging quite
complex documents, and relies on years of experience. Without them the Internet
would be an incoherent technical failure. (OK, I freely admit that it's an
incoherent technical success. :-)

    Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Sep 2020 12:12:40 +0200

> Does anyone else feel this way? I am opposed.

So am I.

> It **appears** that this change removes the requirement for proper
> URI’s, or at least moves the responsibility to IANA, which is hired staff.

I personally feel that we shouldn't have allowed non-URIs in the
provisional URI registry in the first place, but it seems that boat has
sailed.

Best regards, Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Sep 2020 18:22:23 -0700

> provisional URI registry in the first place, but it seems that boat has

RFC 7595 Section 4 is the filter for provisional registrations.  Does it
need updating?

-MSK

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Sep 2020 12:21:29 +0200

Am 13.09.2020 um 03:22 schrieb Murray S. Kucherawy:
> On Fri, Sep 11, 2020 at 3:13 AM Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>

To answer this, it would be good to know what actual information was
submitted with the provisional scheme registration request. Is that on
record anywhere?

(I'm aware of the thread at
<https://mailarchive.ietf.org/arch/msg/uri-review/Zm_spdzPvzlf7uXMdLKQ4xMSXlU/>
but is there something else?)

Best regards, Julian