On Mon, Aug 29, 2022 at 09:32:24PM +0000, Warren Kumari wrote:

> > * For the rfc1123 section 2 topic, it may make sense to clarify the text
> >  to say "domain name" rather than "hostname":
> >    > An "alternative endpoint" is a hostname, port number, and other
> >    > associated instructions to the client on how to reach an instance
> >    > of service.
> >   Everywhere else in the normative sections such as 1.2 and 2.1 we
> >   say that the TargetName is a "domain name" (aligned with the
> > clarification in rfc8499
> >   on the difference between host and domain names).
> 
> I think that the current is clear enough. I agree that it would probably
> have been better as 'domain name' if we had caught that at WGLC / IETF LC,
> but I think it would be gratuitous / not rise to the level of 'futzing
> after approval'...

I still suspect that the document's multiple explicit suggestions that
IP addresses can be reliably associated with _leaf labels is a mistake.
As pointed out, these will run into various barriers, and changing the
text to make this clear is IMHO warranted.

* The initial $QNAME (with _leaf prefixes) should not be used as a
  potential "hostname" to connect to (this is an inadvertent error,
  the intent was to only use $QNAME after one or more AliasMode
  records).

* If the final AliasMode target is an _leaf name, then it is likely not
  a viable TCP endpoint, and can only be used for further chained SVCB
  lookups.

* The target names in non AliasMode records must be valid hostnames.

I don't correcting the above issues change the intent of the draft,
though they could be material enough to bring it back for a quick fix of
at least this issue.

Whether any clarifications of failover (without material changes) are
also warranted is not on my list of essential todos.  I'd have chosen
less fuzzy semantics, but clearly that's not the consensus, which is
just fine.  Thanks all for a very productive exploration of these
late to surface topics.

-- 
    Viktor.

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

Reply via email to