On 11/1/2021 11:58 AM, Eric Orth wrote:
The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present"
part.
I don't understand what would be different if the record sender SHOULD
became a MUST. Recipients wouldn't be able to behave any differently
because they would still need to ignore rather than reject params in
order to preserve compatibility with future supported alias params.
Am I missing something?
If there's not a big difference either way that I'm missing, I would
lean towards preferring SHOULD because I don't think strong MUST-level
rules should be set when it isn't necessary for the protocol. The
reason to not set params in an alias record is that they'll be ignored
and thus just a waste of bandwidth, but nothing else bad would happen
and it wouldn't limit the capabilities of the protocol. Sounds like a
SHOULD situation to me.
On Mon, Nov 1, 2021 at 11:36 AM Ben Schwartz
<bemasc=40google....@dmarc.ietf.org> wrote:
This text is a "SHOULD NOT" because there has been some discussion
of potential future uses for SvcParams in AliasMode. If
implementations follow the current text, this kind of extension
can be backwards-compatible.
I agree that the resulting behavior creates a typo hazard for zone
administrators. Perhaps we could keep the "SHOULD NOT", but add a
line like "Zone file parsers MAY emit a warning"?
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Eric et al -
"SHOULD" and "should" are inherently dangerous as they lead to ambiguity
and different conclusions from the same data. Mark's note made me go
and take a look at this document and simply searching for "should" shows
a number of problems.
Section 2 - "their definition should specify..." - this is obviously a
must and is guidance to the IANA for interpreting registrations. E.g.
lack of this data has to result in a rejected registration request.
Section 2.1 - "Key names should contain..." - drop the should as it
introduces ambiguity. The BNF is clear this is a MUST and is normative.
Section 2.1 - "...formats for such keys SHOULD use a comma-separated
list". This is a semi-reasonable SHOULD, but begs the question of what
you do if you don't use a comma separated list and adds to the later
parser complexity if someone chooses something else in a later
definition. Guidance such as "Requests for registration of lists or
set SvcParamKeys that propose a different format must justify any
deviation and are subject to rejection." may be appropriate here.
2.4.1 - "all RRs SHOULD have the same mode" - this is satisfactory as
the next sentence describes what to do if this is not the case.
2.4.1 - " ... SHOULD be given preference..." and "SHOULD apply a random
shuffle" are not satisfactory as they lead to ambiguity between the
publisher and the client. There appears to be no good reason not to
make both of theses MUST.
2.4.2 - "SHOULD only have a single...." and "SHOULD pick one at
random". The first is satisfactory as it's covered by guidance on the
following sentence. The second is not as it leads to ambiguity and
there appears to be no good reason not to make it a MUST. Among other
things, you really don't want someone to come along later and decide
that because 75% of the clients pick the first one, they can game the
system by manipulating the RRSet.
2.4.2 "TargetName SHOULD NOT..." - this is unsatisfactory as it doesn't
explain what a client should do if it receives such a beast. This needs
client guidance and the client MUST ignore such a record. Also are
there other pathological cases where you might end up with loops
indirectly? If so, guidance for the client on how to detect such cases
needs to be given.
2.4.2. "...records SHOULD NOT..." is satisfactory as it describes how a
client resolves receiving such records.
2.4.2 "....zone owners SHOULD NOT ... " should be lower case as humans
are not protocol elements. This is operational guidance rather than
protocol guidance.
2.4.3 "...implementations SHOULD enforce..." - this one is iffy as I
don't think "zone file implementations" is a consistent term of art.
You could place the enforcement with the server - e.g. "SHOULD refuse to
serve inconsistent ServiceMode RRs"? Or perhaps with the DNSSEC signing
tool?
3 - "SVCB-optional clients SHOULD issue in parallel..." - is
satisfactory because it describes client behavior and refers to a
section the describes the reasoning. However, is "in parallel" here a
term of art? "in conjunction" may be a better phrasing.
3 - "Clients SHOULD try higher-priority..." is mostly satisfactory, but
needs to at least explain the implications of not going in strict
priority mode. However, there appears to be no good reason not to make
this a MUST - see back to the comment 2.4.1 - "SHOULD be given
preference" with respect to ambiguity.
3. "...client SHOULD attempt..." - is not satisfactory as it doesn't
describe why you should or shouldn't do this and leaves the implementer
guessing.
3.1 - "...client SHOULD abandon..." is not satisfactory as the text
really describes a MUST. E.g. security errors are either permanent
failure, or transient with a retry, they are never to be ignored.
Reading this suggests that ignoring is sufficient. If you leave
"SHOULD", then clarify what not abandoning the connection means - e.g.
retrying it for some amount of times, but never accepting falsified data.
3.1. "...it SHOULD apply..." - not satisfactory as the text describes a
MUST. There is no good reason and every reason not to treat the SVCB
validation differently than an A/AAAA response.
3.1. "....client SHOULD fall back..." - not satisfactory as the text
fails to describe what happens if you don't fall back. At the least
this needs a discussion of why falling back makes sense and its impact
on security.
3.2 "...proxies SHOULD arrange..." is not satisfactory because of the
"or" clause ambiguity and a lack of implementer guidance on which
choices make sense in which situations.
___________________ pausing here to do other work
________________________________
In general, the document substantially overuses SHOULD clauses. I'd
recommend the authors and participants take a harder look at each
SHOULD, and, if they want to leave a SHOULD in place, ensure they've
described the options sufficiently for an implementer to make an
informed decision.
Mike
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
