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

On Wed, Jul 4, 2018 at 1:02 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hi Martin,
> At 05:58 PM 03-07-2018, Martin Thomson wrote:
>
>> 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.
>>
>
> 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".
>
> 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.
>>
>
> 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.
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@ietf.org
> https://www.ietf.org/mailman/listinfo/rfcplusplus
>