Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl

[Scott Kitterman <[e-mail]>]

On April 16, 2016 11:38:24 AM EDT, "Murray S. Kucherawy" <[e-mail]> wrote:
>[dropping the IANA address because it keeps creating tickets in their
>system]
>
>On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely <[e-mail]>
>wrote:
>
>> On Wed 13/Apr/2016 20:15:04 +0200 Murray S. Kucherawy wrote:
>> > On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely
><[e-mail]>
>> wrote:
>> >
>> >> I still don't think it is worth publishing the I-D, but maybe
>IETF's
>> list
>> >> archives can be considered permanent documents, which can be
>referenced
>> by
>> >> items added after Expert Review, no?
>> >
>> > That seems... unconventional at least.  I would rather see
>something
>> > published.  Going via the ISE, if you're worried about the slog
>through
>> the
>> > IETF Stream, seems like a perfectly viable option.
>>
>> I think that is called RFC Required, not Expert Review.
>>
>
>It would if I had asserted that you have to publish an RFC, but that's
>not
>what I said.  I was making a suggestion about one way to publish it,
>and
>since you already have a draft, you're part way there.
>
>Yes, I rejected your proposal to use policy.zone=lists.dnswl.example,
>> because
>> it disagrees with the only existing implementation.  When that was
>> discussed,
>> the syntax dns.zone=lists.dnswl.example was chosen because a DNSxL is
>a
>> zone in
>> the DNS, according to, say, RFC5782.  Nobody realized that "dns" is
>not a
>> valid
>> RFC7601 ptype (and I still don't understand why).
>>
>
>I've gone over the "why" with you at some length both at the Berlin
>meeting
>and now on a thread subsequent to your request to IANA.
>
>While I'm sympathetic to some degree with the "installed base"
>argument, I
>don't think it's reasonable to accept a registration that doesn't fit
>within the defining RFC merely because there's a single existing
>incorrect
>implementation.

While I normally give pragmatic arguments (like alignment to existing practice) a lot of weight, in this case I agree with Murray that it would be a mistake.

If you look at the discussion of iprev in http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact same ground as this proposal with regards to ptype selection.  I believe it's clear that policy is the correct choice.

In order to add the proposed new ptype, I think the ptype definition in http://tools.ietf.org/html/rfc7601#section-2.3 would have to be changed and that would require a standards track update to RFC 7601.  I don't think you want to go down that path.

Scott K