On Tue, May 11, 2021 at 10:32 AM Joe Abley <jab...@hopcount.ca> wrote:
> On 11 May 2021, at 12:32, Ben Schwartz <bem...@google.com> wrote:
>
> > On Tue, May 11, 2021 at 9:20 AM Joe Abley <jab...@hopcount.ca> wrote:
> >> On 11 May 2021, at 12:08, Ben Schwartz <bemasc=
> 40google....@dmarc.ietf.org> wrote:
> >> ..
> >>> * It saves at least 11 bytes of overhead per parameter by avoiding
> repetition of
> >>> the name, type, class, TTL, and inter-pair binding ID.
> >
> > ... but it inflates response volume in the case where a separate
> SvcParams RRSet is able to be cached significantly longer than the SVCB
> RRSet.
> >
> > It sounds like you're proposing a design in which the information in one
> SVCB record is not just spread across multiple records in an RRSet, but
> actually across multiple RRSets.
>
> Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR
> becomes a pointer to a second RRSet with a different RRType. So the
> SvcParams information is spread across multiple records in a a different
> RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try
> again.
>
> Note that I'm not proposing a change to the spec, just illustrating that
> different design choices were possible that avoid the need for delimiters
> or escaping.
>
OK, thanks for helping me understand your thought process.
> While we're on the topic of RRSets and multiple RRTypes, the way that
> AliasMode and ServiceMode are distinguished is also a bit clunky; what are
> the implications of needing to remove all ServiceMode RRs in an RRSet in
> the event that one of them is found to be in AliasMode if we imagine that
> some consumers of these responses will get it wrong?
I think the recipient logic ("if there is an AliasMode record, just use
it") is simple, and not likely to be a source of confusion. Given that
publishers SHOULD NOT publish mixed-mode RRSets, both sides would have to
be misbehaving for such a bug to be triggered. If both sides are
noncompliant, presumably the recipient would attempt to connect using one
or more of the ServiceMode records, and succeed if they are usable. This
doesn't seem problematic to me. The purpose of this exclusion was mainly
to simplify analysis, avoid inefficient configurations, and maintain
parallelism with CNAME.
> Was there any thought given to an RR schema that prevented such
> ambiguities from being published?
>
This design choice, like many aspects of SVCB, was constrained by latency
and efficiency considerations. However, note that the ambiguity is
limited: SvcPriority zero sorts to the top, so clients will naturally see
it first.
> That is not just a variation on SVCB, but an entirely different proposal.
>
> I'm not sure how you think of those two things as different. Isn't every
> variation of something a new something?
>
I think the distinction might be useful as a matter of working group
process.
>>> * It provides a wire format whose structural nesting matches the
> logical scope
> >>> of each key=value pair, and avoids requiring cross-RR reconstruction
> of
> >>> bindings by the client.
> >>
> >> This seems like it is documenting a design choice rather than
> explaining it. The decision to include a list of key-value pairs in the
> SVCB RDATA is good because it avoids having to do something different?
> >
> > To restate this sentence, it is good because the concrete syntactical
> structure matches the abstract conceptual structure, and (relatedly)
> because it simplifies client implementation.
>
> What are the concrete syntactical structure and the abstract conceptual
> structures? If those are terms of art I apologise; I'm not familiar with
> them.
>
The concrete wire-format syntax is an octet sequence containing a
TargetName and some SvcParam key-value pairs.
The abstract structure is a "binding" comprising a TargetName and a
key-value map that is associated with that TargetName.
What are you comparing the client implementation to in your final comment?
> What other design option was found to be more complex to implement on the
> client side?
>
I was comparing it to designs where the TargetName and params are separated
into different RRs, or mixed into an RRSet with other bindings. In such
designs, the client must perform additional work to fetch, associate, or
reconstruct these different components that are encoded or delivered
separately but are only usable as a unit.
I'm sure it feels frustrating to get all these questions at the last
> minute, and I apologise (as I think I said before) that I did not follow
> this work more closely, earlier.
>
>
> Joe
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
