On 08. 07. 21 18:00, Viktor Dukhovni wrote:
On 8 Jul 2021, at 10:28 am, Petr Špaček <[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
