Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Petr Špaček <[e-mail]>]

On 08. 07. 21 18:00, Viktor Dukhovni wrote:
>> On 8 Jul 2021, at 10:28 am, Petr Špaček <[e-mail]> wrote:
>>
>> With my implementer hat on, I say "no", I don't see a compelling reason to "mandate" it. Keep it at MAY/optional level and leave it to implementers to decide what's best for their implementation and use-cases.
> 
> Just wanted to check what you mean by *mandate*, I don't quite see
> RECOMMENDED as a mandate, my understanding is that SHOULD/RECOMMENDED
> means "do this unless you have good reason to do otherwise".  So there
> is certainly enough rope to ignore the advice.
> 
> How would you strongly suggest that stopping qname minimisation at the
> first special-use label is probably a good idea, more strongly than just
> mentioning as a possible optional optimisation?

When I look at RFC 2119 ...

--------
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there 
may exist valid reasons in particular circumstances to ignore a 
particular item, but the full implications must be understood and 
carefully weighed before choosing a different course.

...

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is 
truly optional.  One vendor may choose to include the item because a 
particular marketplace requires it or because the vendor feels that it 
enhances the product while another vendor may omit the same item. An 
implementation which does not include a particular option MUST be 
prepared to interoperate with another implementation which does include 
the option, though perhaps with reduced functionality. In the same vein 
an implementation which does include a particular option MUST be 
prepared to interoperate with another implementation which does not 
include the option (except, of course, for the feature the option provides.)
--------

I think MAY describes exactly what workarounds are:
A completely optional hack which _nobody_ can rely on.

When I read definitions SHOULD and MAY together, I believe the text 
implies problems caused by ignoring SHOULD lie on the party which choose 
to ignore that particular instance of SHOULD:
IMHO this is very wrong when describing workarounds.
Workarounds are temporary "crutches for broken implementations", and 
anything stronger than MAY is just wrong.

As a resolver implementer, I do not want to get into a position when a 
broken auth vendor uses the SHOULD requirement in RFC as an argument to 
keep their auth-brokenness because "resolvers SHOULD implement the 
workaround!"

-- 
Petr Špaček