Whoops, last message was blank; finger fail.

On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari <war...@kumari.net> wrote:
> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček <petr.spa...@nic.cz> wrote:
>>
>>
>> On 6.2.2018 17:13, Paul Hoffman wrote:
>>> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
>>>
>>>> On 6.2.2018 13:22, Tony Finch wrote:
>>>>> A. Schulze <s...@andreasschulze.de> wrote:
>>>>>>
>>>>>> Yes, "kskroll-sentinel-is-ta-NNNN" is more descriptive and specific.
>>>>>> I also prefer that longer variant.
>>>>>
>>>>> Yes, more friendly for web searches if someone is wondering about weird
>>>>> queries.
>>>>
>>>> Bonus points if we can get a number reserved by RFC editor, it would
>>>> allow us to use name like
>>>> test-rfc0000-is-ta-NNNN
>>>> test-rfc0000-not-ta-NNNN
>>>>
>>>> That would be super awesome.
>>>
>>> ...and super-unlikely, given the history of the RFC Series.
>>>
>>>> Is something like RFC number pre-allocation possible?
>>>
>>> Sometimes (rarely), after Working Group Last Call. That's why I
>>> suggested "kskroll-sentinel" since those words are in the WG draft name,
>>> and will probably appear in the IETF Datatracker forever.
>>
>> Fine. Now we need to have something actionable, e.g. set of names for
>> Geoff to test.
>>
>> Can we have couple proposals and test them in one go, so results are
>> comparable?
>>
>> I've gathered these:
>>
>> kskroll-sentinel-is-ta-NNNN
>> kskroll-sentinel-not-ta-NNNN
>> is-ta--NNNN
>> not-ta--NNNN
>>
>> I propose longer but more descriptive variant:
>> kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN
>> kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-no-NNNN

<no hats>

I personally like "kskroll-sentinel-is-ta-NNNN", or "is-ta--NNNN".

I really do not like
"kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN" as:
$echo "kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN" | wc -c
   62

(I note that you left off the last N in the "yes" version. While 62 is
within spec, it feels like we are getting really close; I cannot think
of any current issue that this might cause, but I *can* imagine
someone many years from now cursing us when Key IDs get expanded to
128bits to <insert unlikely but possible scenario here>)

I also think that we are getting into the beauty contest territory
here -- some of which may be caused by the fact that the authors
really owe the WG an update.

Whoever would have predicted that a discussion on naming things would
generate so much discussion?! :-)

W

I also note that you ignored my "I-heart-KennyG" suggestion. This
makes me sad. :-P
</no hats>

>>
>> (I imagine that real meaning of name "kskroll-sentinel" will be known by
>> dozen people but hunders or thousands people will encounter it in
>> tcpdump, so why not make life easier for them. It costs almost nothing...)
>>
>> Do we have other proposals?
>>
>> --
>> Petr Špaček  @  CZ.NIC
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to