Subject: Re: Appeal and IANA correspondence

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 28 Jul 2020 16:56:49 -0400 (EDT)

If you have a look at my appeal it very clearly states I am basing it on RFC 2026 Section 6.5.2 (Process Failures).  Now if you have not read all ten sentences of it you would have missed the one that says "

If the IESG Chair is unable to satisfy the complainant
then the IESG as a whole should re-examine the action taken, along
with input from the complainant, and determine whether any further
action is needed. "

Why is this important? Because if the whole IESG was supposed to re-examine things
and only three did then that opens the door for another appeal (what a waste)
In an email exchange this morning with Murray (below) he tells me that there isn't really any vote
and refused to tell me how many people total were involved in the final decision.

I am noticing a trend of "we make the rules but we don't really follow them"

****

I can tell you that in terms of process, the discussion was open to all members of the IESG.  However, the actual details of the IESG's deliberations about appeals are not public.

-MSK

On Tue, Jul 28, 2020 at 8:37 AM Timothy Mcsweeney <
[email-masked]> wrote:

Was it all the members of the IESG?

https://www.ietf.org/about/groups/iesg/members/

On July 28, 2020 at 11:34 AM "Murray S. Kucherawy" <
[email-masked]> wrote:

No, it was not just me and Barry.

-MSK

On Tue, Jul 28, 2020 at 8:30 AM Timothy Mcsweeney <
[email-masked]> wrote:

Ok,

So was it just you and Barry?

On July 28, 2020 at 11:23 AM "Murray S. Kucherawy" <
[email-masked]> wrote:

The process is about the same as is done in working groups to develop a document.  A member of the IESG proposed a response, and various members then contributed edits or commentary, which were discussed and the text modified until all input was addressed.  Consensus was finally declared, and the result was posted.

The IESG and its membership are described here:
https://www.ietf.org/about/groups/iesg/

-MSK

On Tue, Jul 28, 2020 at 8:19 AM Timothy Mcsweeney <
[email-masked]> wrote:

Forgive me Murray...

but what is a consensus output?

And how many total made that consensus output?

On July 28, 2020 at 11:13 AM "Murray S. Kucherawy" <
[email-masked]> wrote:

Timothy,

The appeal response posted this morning is the consensus output of the IESG.  There was no vote.

If you disagree with the outcome or how it was reached, you have the option to appeal further to the Internet Architecture Board.

-MSK

On Tue, Jul 28, 2020 at 7:58 AM Timothy Mcsweeney <
[email-masked]> wrote:

Murray,

Would you please send me a copy of the votes for and against.  Thank you.

Tim

On July 16, 2020 at 7:47 PM "Murray S. Kucherawy" <
[email-masked]> wrote:

Received, thank you. This is helpful.

-MSK

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

Hi Murray,

I have attached individual files for each claim you requested (14,15,18).

Thank you for being direct and informative.

Tim

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 28 Jul 2020 17:00:57 -0400

Hi Tim,

The whole IESG discussed your appeal and our response to it, and we all stand behind it. As a general matter, the IESG does not vote (on anything).

Best,
Alissa Cooper
IETF Chair

> On Jul 28, 2020, at 4:56 PM, Timothy Mcsweeney <[email-masked]> wrote:
> 
> On Tue, Jul 28, 2020 at 8:37 AM Timothy Mcsweeney <  [email-masked] <mailto:[email-masked]>> wrote: 
>    https://www.ietf.org/about/groups/iesg/members/ <https://www.ietf.org/about/groups/iesg/members/> 
> 
> On July 28, 2020 at 11:34 AM "Murray S. Kucherawy" <  [email-masked] <mailto:[email-masked]>> wrote: 
> 
> On Tue, Jul 28, 2020 at 8:30 AM Timothy Mcsweeney <  [email-masked] <mailto:[email-masked]>> wrote: 
> Ok, 
> 
> On July 28, 2020 at 11:23 AM "Murray S. Kucherawy" <  [email-masked] <mailto:[email-masked]>> wrote: 
> 
> The IESG and its membership are described here:  https://www.ietf.org/about/groups/iesg/ <https://www.ietf.org/about/groups/iesg/> 
> -MSK 
> 
> On Tue, Jul 28, 2020 at 8:19 AM Timothy Mcsweeney <  [email-masked] <mailto:[email-masked]>> wrote: 
> Forgive me Murray...
> 
> On July 28, 2020 at 11:13 AM "Murray S. Kucherawy" <  [email-masked] <mailto:[email-masked]>> wrote: 
> 
> Timothy,
> 
> On Tue, Jul 28, 2020 at 7:58 AM Timothy Mcsweeney <  [email-masked] <mailto:[email-masked]>> wrote: 
> Murray, 
> 
> On July 16, 2020 at 7:47 PM "Murray S. Kucherawy" < [email-masked] <mailto:[email-masked]>> wrote: 
> 
> On Thu, Jul 16, 2020 at 12:52 PM Timothy Mcsweeney < [email-masked] <mailto:[email-masked]>> wrote: 
> Hi Murray,
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Jul 2020 14:03:24 -0700

On Tue, Jul 28, 2020 at 1:57 PM Timothy Mcsweeney <[email-masked]>
wrote:

> If you have a look at my appeal it very clearly states I am basing it on
> RFC 2026 Section 6.5.2 (Process Failures).  Now if you have not read all
> ten sentences of it you would have missed the one that says "
>
> What Murray describes is the conventional practice for an appeal in my
experience. This is specifically permitted by 2026 S 6.5.4.

   At all stages of the appeals process, the individuals or bodies
   responsible for making the decisions have the discretion to define
   the specific procedures they will follow in the process of making
   their decision.

You're of course free to appeal the IESG's response to the IAB.

-Ekr

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 28 Jul 2020 17:09:25 -0400 (EDT)

Ok good to know, not sure why Murray didn't say that.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 28 Jul 2020 17:25:15 -0400 (EDT)

Alissa, remember when I sent you that email on the 7/3 (below).  I wanted to make sure the IESG members saw that last paragraph of RFC3405 section 5.

"The logical conclusion of this is that ANY

sanctioned URI scheme or URN namespace MUST be allowed to be

registered if it meets the requirements specified in this document as

regards times to live and general impact to the DNS."

But your detailed decision says

"Simply put, registration into URI.ARPA is not possible at present because of the oversight

described above, even if the URI scheme being registered is not provisional. This is not merely

because this particular application is ineligible, but rather because, at present, none are."

That to me sounds like a broken process....like it says in my appeal for a broken processes rfc2026#section-6.5.2

******

(begin email)

Alissa,

Because at this time I am unaware of what information the IESG will be using in its discussion, I would like to add the URI.ARPA Submission Procedures.

<
https://tools.ietf.org/html/rfc3405>

With particular attention to the last paragraph of Section 5:

<
https://tools.ietf.org/html/rfc3405#section-5>

5. Submission Procedure

Using the MIME Content-Type registration mechanism [8] as a model

for a successful registration mechanism, the 'URI.ARPA' and

'URN.ARPA' procedures consist of a request template submitted to an

open mailing list made up of interested parties. If no objections

are made within a two week period, a representative of the

registration authority considers the submission to be accepted and

enters that submission into the nameserver.

o Registrations for the 'URI.ARPA' zone are sent to

[email-masked]'.

o Registrations for the 'URN.ARPA' zone are sent to

[email-masked]'.

The registration authority is the Internet Assigned Numbers

Authority (IANA).

Objections are restricted to those that point out impacts on the zone

itself or to DNS in general. Objections to the URI scheme or to the

URN namespace-id are not allowed, as these should be raised in their

respective forums. The logical conclusion of this is that ANY

sanctioned URI scheme or URN namespace MUST be allowed to be

registered if it meets the requirements specified in this document as

regards times to live and general impact to the DNS.

Thank you,

Tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Jul 2020 14:42:08 -0700

I did say that, in my first reply to you at 8:13am today:

"If you disagree with the outcome or how it was reached, you have the
option to appeal further to the Internet Architecture Board."

-MSK

---

From: Timothy Mcsweeney <[email-masked]>
Date: Tue, 28 Jul 2020 17:55:26 -0400 (EDT)

Murray, you're confused.  I was speaking of the fact that when I asked you how many people were involved in the decision you would not tell me.  Then Alissa says the whole IESG discussed your appeal.  You could have easily told me the same thing but didn't.

(email below again)

-MSK

-MSK

Ok,

-MSK

Forgive me Murray...

Timothy,

-MSK

Murray,

Tim

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Jul 2020 12:41:51 +0100

Timothy Mcsweeney wrote on 28/07/2020 22:55:
> Murray, you're confused.  I was speaking of the fact that when I asked
> you how many people were involved in the decision you would not tell
> me.  Then Alissa says the whole IESG discussed your appeal.  You could
> have easily told me the same thing but didn't. 

Tim,

Did you try submitting a application which complied with the syntax
specified in rfc3986?

Would this not be a productive way forward?

Nick

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 29 Jul 2020 10:04:32 -0400 (EDT)

Hi Nick,

>specified in rfc3986?

I did!

My spec references section 2.2 of RFC3986.  Here is the first sentence from the third paragraph "

A subset of the reserved characters (gen-delims) is used as
delimiters of the generic URI components described in Section 3.

"

I mean, it just does not get any clearer than that!

On July 29, 2020 at 7:41 AM Nick Hilliard <
[email-masked]> wrote:

Tim,

specified in rfc3986?

Nick

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 29 Jul 2020 10:06:55 -0400 (EDT)

And here is another one.  The first sentence of the second paragraph says "

The purpose of reserved characters is to provide a set of delimiting
characters that are distinguishable from other data within a URI.

"

Simple right?!!

Tim,

specified in rfc3986?

Nick

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2020 14:19:29 +0000

I have tried to follow this, but am getting a bit lost.

Tim, do you want “drop#” or “drop:” ?

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Jul 2020 15:20:50 +0100

Luckily it gets much clearer!  The ABNF syntax is specified in section 3:

>    The generic URI syntax consists of a hierarchical sequence of
>    components referred to as the scheme, authority, path, query, and
>    fragment.
> 
>       URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

Where "scheme" is defined in section 3.1 as:

> scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

I.e. the scheme name is followed by ":".

The ABNF syntax is completely unambiguous on this point and there's no
scope to argue that the scheme name should be followed by a "#" token.

Did you try resubmitting the I-D with "drop:" instead of "drop#"?

Nick

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 29 Jul 2020 10:27:37 -0400 (EDT)

Hi Rich,

I want drop#

On July 29, 2020 at 10:19 AM "Salz, Rich" <[email-masked]> wrote:

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 30 Jul 2020 00:29:04 +1000

And I want a pony and some better alcohol than I have here with which to survive the plenary.

Bron.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2020 14:31:02 +0000

*   I want drop#

Okay.  Too bad, the syntax is clear that the colon is needed.

I am fine with the IESG decision, and disappointed all this effort is being spent.

Perhaps we can learn something: why do you think the colon separator is not required of you?

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 29 Jul 2020 10:37:12 -0400 (EDT)

>why do you think the colon separator is not required of you?

The delimiters are for EVERYONE

So the colon would not be required of you either Rich.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2020 14:59:09 +0000

Tim,

Why is “drop:” unacceptable to you?  Why do you think the syntax others have quoted does not apply?  I said “you” because, as far as I know, you are the first person to contest this, and certainly to contest it vehemently. I am trying to understand why the document is not clear so it can be improved.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Jul 2020 11:13:24 -0400

> I want drop#

A number of people have carefully explained why this is not possible and not compliant to the existing standards and implementations.

I read the appeal and the answer. I don’t think any further discussion will change the outcome. We can have many more discussions about whether the process was correctly followed or not, but in the end the technical arguments won’t change. 

I hope your ideas can find a way to adapt, cooperate and coexist with the infrastructure we have defined and implemented worldwide.

Paul

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 29 Jul 2020 11:40:41 -0400 (EDT)

Rich,

>Why is “drop:” unacceptable to you?

The RFC gave me a choice and I decided on the drop#.  I'm going to stick with it.

>Why do you think the syntax others have quoted does not apply?

I think ALL the syntax applies.  Why do you think others don't think mine applies?  because nobody has used it yet?  is that ossification?

>I said “you” because, as far as I know, you are the first person to contest this, >and certainly to contest it vehemently.

Somebody has to be first.

>I am trying to understand why the document is not clear so it can be improved.

The document is really very clear.

On July 29, 2020 at 10:59 AM "Salz, Rich" <[email-masked]> wrote:

Tim,

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2020 15:44:28 +0000

The document does not give you a choice.  Section 3 and section 3.1 say “scheme followed by colon”  The six occurences of the word separator have context that say it is not appropriate for scheme (except the one reference in section 4.1 which says “scheme followed by its colon separator”).

Can you point to which RFC’s you followed other than 3698?  Can you identify which sections in 3986 you feel gave you a choice?

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 29 Jul 2020 11:47:54 -0400 (EDT)

>Can you identify which sections in 3986 you feel gave you a choice?

Section 2.2

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2020 15:58:06 +0000

*   >Can you identify which sections in 3986 you feel gave you a choice?

  *   Section 2.2

Thanks.

So I am guessing that you took this sentence: “A subset of the reserved characters (gen-delims) is used as delimiters of the generic URI components described in Section 3” to mean that *ANY* of those characters may be used. That is wrong. The meaning is when a separator is used as a delimiter it must be chosen from that set.  I.e., no other character will be used. Just like “?” is used as the query indicator and “#” is used as the fragment identifier.  All three things – scheme, query, fragment – have semantics and use character from gen-delims (which must otherwise be percent-encoded) so that they can be marked off, stripped out, etc.

I am sure you are not convinced.  Oh well.

---

From: Timothy Mcsweeney <[email-masked]>
Date: Wed, 29 Jul 2020 12:08:46 -0400 (EDT)

>The meaning is when a separator is used as a delimiter it must be chosen from >that set.

I'm glad to see we both agree now.  Guess which separator I chose?

:-)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2020 16:16:04 +0000

>I'm glad to see we both agree now.  Guess which separator I chose?

Sorry for not being clear.

The RFC is reserving special semantics *to itself* from that set.  “:” separates scheme, “#” indicates start of fragment and “?” indicates query-part. The text indicates that if characters from that set are used within the generic parts, they must be percent-encoded.

You couldn’t chose. You don’t have that choice.  The RFC is promising to other consumers that *only* these characters have special meaning, that meaning is described in this document. This is so some level of generic processing may occur.  Trying to separate the scheme component using anything else, is cherry-picking two lines of text and ignoring the rest of the RFC.

I don’t have anything else to add.  Take care.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 29 Jul 2020 13:09:51 -0400

Hi Tim,

Thanks, I do remember your email. Per RFC 2026, at this point if you are not satisfied with the outcome of the IESG review, you may appeal it to the IAB.

Alissa

> On Jul 28, 2020, at 5:25 PM, Timothy Mcsweeney <[email-masked]> wrote:
> 
> < https://tools.ietf.org/html/rfc3405 <https://tools.ietf.org/html/rfc3405>> 
> 
> < https://tools.ietf.org/html/rfc3405#section-5 <https://tools.ietf.org/html/rfc3405#section-5>>  
> 
> 5. Submission Procedure 
> [email-masked] <mailto:[email-masked]>'.
> [email-masked] <mailto:[email-masked]>'.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 31 Jul 2020 09:47:18 +0100

Hi Tim,

> On 29 Jul 2020, at 16:40, Timothy Mcsweeney <[email-masked]> wrote:
> 
> Rich,
> 

I read draft-mcsweeney-drop-scheme-01 and section 2.1 states "The 'drop' scheme was created in a way to be able to reuse current infrastructure making it easy to use and quick to deploy.”

Let us assume for a moment that your proposal is accepted and registered as a URI. There is no widely deployed URI parser that I am aware of that will parse your proposal as you intend and correctly identify the scheme as being ‘drop’ (instead your proposal will be parsed as a relative path of ‘drop’ with a fragment of whatever comes after the ‘#’). 

Therefore, even if you are successful at registering your proposal as a URI you will have failed in your goal to be able to reuse current internet infrastructure because your proposal is not deployable with today’s already deployed internet infrastructure.

It seems to me that you have two choices:

1) Continue to “stick with it” while cutting off your nose to spite your face [1].

2) Take a step back, accept your interpretation of RFC3986 is different to the consensus interpretation of that document, swallow your pride, and adjust your proposal to use ‘:' instead of ‘#' and benefit from being able to leverage already deployed URI parsers to correctly identify your new ‘drop’ scheme.

Regards
Ben

[1] https://dictionary.cambridge.org/dictionary/english/cut-off-your-nose-to-spite-your-face <https://dictionary.cambridge.org/dictionary/english/cut-off-your-nose-to-spite-your-face>