Subject: [Rfcplusplus] Comments on draft-thomson-rfcplusplus-label-00

From: S Moonesamy <[email-masked]>
Date: Tue, 03 Jul 2018 15:51:21 -0700

Hi Martin,

First of all, thank you for submitting [1] a draft about the proposed 
label experiment.

There is the following in Section 1: "The Internet Standards Process 
[RFC2026] describes a process that has consistently produced quality 
documents".   An old ETSI document states that "the quality of [IETF] 
RFCs is variable. Some are well-constructed and easy to understand, 
others are less so;"

There was an IAB report which mentioned that the discussions which 
led to the proposed BoF was also about "a long consideration of the 
role of that ISE-curated RFCs play in the ongoing confusion over RFCs 
as standards".  I have done a few reviews for the ISEB over the 
years.  I am somewhat surprised by the IAB's opinion about the 
Independent Submissions Stream as the previous discussion about that 
Stream was not related in any way to standards; it was about about an 
alternative publication option for authors of Internet-related 
material.  Your draft touches on that in Section 2 (commonly-accepted 
view). The point made in Section 2 in respect to deployment is that 
the "non-standard" RFC could cause interoperability issues.  Is the 
issue about the allocation of codepoints [3]?

There are IPR disclosures on the two RFCs which you cited in Section 
2.  Why is the publication of RFC 8216 viewed [2] as a "defiance of a 
standardized protocol"?  Section 2 of the draft also states that 
those two RFCs describe "in reality" standards.  If I am not 
mistaken, the line of argument in the IETF used to be that it is 
deployment which "makes" a standard.  There is an alternative to 
that, i.e. require an ITU-T A.5 justification.

The financial reward of being a "RFC author" likely contributes to 
the "nuance in interpretation" of the label.  About a week ago, I 
came across an 15-pages (IETF) draft which had 14 authors.  I don't 
recall seeing that many authors for drafts in the Independent 
Submissions Stream.

I doubt that the publication of a RFC is always about reaching an 
IETF audience (please see Section 3) as it should be obvious that the 
best place to reach that audience is within the IETF.

Regards,
S. Moonesamy

1. You might have read my comment about not finding much information 
about the RFC++ BoF.
2. The conflict review states that "this relationship does not 
prevent publishing".
3. From what I understand, that is usually requested through the IETF.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jul 2018 10:58:21 +1000

On Wed, Jul 4, 2018 at 8:56 AM S Moonesamy <[email-masked]> wrote:
> The point made in Section 2 in respect to deployment is that

Not so much.  I don't believe that allocating codepoints should be use
as a locus of control.  We've seen some pretty awful consequences from
that.  Recently: three-way squatting on the same codepoint in TLS, for
instance.

The concern is simpler: the creation of non-interoperable deployments.

> standardized protocol"?

Bad choice of words maybe, because that's just my opinion.  That is, I
believe that DASH is perfectly adequate for the use case and that the
publication of HLS as an RFC is entirely unnecessary.  That the
conflict review found no conflict is unsurprising, but that's a very
narrow determination.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 04 Jul 2018 01:02:37 -0700

Hi Martin,
>The concern is simpler: the creation of non-interoperable deployments.

There was a perception that codepoint allocation was a locus of 
control.  It is one of the underlying IETF debates which happen every 
now and then, e.g. when the allocation requirement is "RFC required".

>conflict review found no conflict is unsurprising, but that's a very

As a comment about "use case", it is sometimes used within the IETF 
to argue for some change or that a proposal is "inadequate".

I took a quick look at "usage" of the RFC and I found that it is 
referenced outside the IETF as a vendor specification.  One of the 
references is to tools.ietf.org.  Publication of other RFCs under the 
IETF domain name might have led to some confusion about IETF RFCs and 
other RFCs.

Regards,
S. Moonesamy

P.S.  I am okay with the choice of words for the draft.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 05:44:30 -0700

On Wed, Jul 4, 2018 at 1:02 AM, S Moonesamy <[email-masked]> wrote:

> There was a perception that codepoint allocation was a locus of control.

Yes, I agree with that.

What Martin is alluding to is that much of the security area has concluded
for its protocols that that was a mistake; the result has been code point
squatting, collisions, and unnecessary debate and effort about documents
which really only existed in the IETF because the authors needed code point
allocations. What we are instead moving towards is the strategy embodied in
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/:
make it easy to do code point registrations (i.e., with just an I-D or a
readily available external reference) but mark such registrations "Not
Recommended". Of course, people may have different opinions about whether
this is a good idea.

-Ekr

It is one of the underlying IETF debates which happen every now and then,
> e.g. when the allocation requirement is "RFC required".
>
> As a comment about "use case", it is sometimes used within the IETF to
> argue for some change or that a proposal is "inadequate".
>
> IETF domain name might have led to some confusion about IETF RFCs and other
> RFCs.
>
> Regards,
> S. Moonesamy
>
> _______________________________________________
> Rfcplusplus mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rfcplusplus
>