Subject: Re: I-D ACTION:draft-ietf-dnsind-rfc2052bis-00.txt

From: Robert Elz <[email-masked]>
Date: Sun, 01 Nov 1998 15:29:38 +1100

Date:        Sat, 31 Oct 1998 09:19:11 -0500
    From:        "Donald E. Eastlake 3rd" <[email-masked]>
    Message-ID:  <[email-masked]>

Consider this message to be a working group last call on

	draft-ietf-dnsind-rfc2052bis-00.txt

The working group last call will run until Nov 7, 1998.

One issue to consider is whether this doc is sufficiently established
to be considered for Proposed Standard status, or whether it should remain
as Experimental, as is 2052.   That's for the WG to decide of course.
The status quo (without conconsensus to the contrary) will be for it to remain
as experimental.   2052 is to be obsoleted.

  | (1) Although asdf.com, which is used for the examples, does not
  | currently exist, it could in the future.  I suggest globally replacing
  | it in the draft with example.com or asdf.example.

We will treat that as a last call comment.

  | (2) Probably the most serious thing is the wildcard question about
  | which there has been previous correspondence

I think this is out of scope for this document.   Changing the semantic of
wildcard labels would be a major change to the DNS, and involve many issues
which are likely to be missed if it is treated as just being a sub-issue of
SRV records.   If someone wants to draft a proposal for expanded handling
of wildcards, the WG can consider that later.   More flexibility in handling
of SRV records may then be an argument in favour of the change.

  | (3) The draft mentions A RRs but never AAAA RRs.  Seems like something
  | should be done about this even if it's only one sentence somewhere
  | that says references to A RRs include AAAA RRs.

Another last call comment.

  | (4) kre a while ago asked if this was applicable to DNS, ICMP, etc.
  | I.E., are you supposed to do an DNS retrieval to figure out where to
  | send DNS queries or pings to.  Presumably not and something could be
  | mentioned about this.

And another.

  | I support advancement of this draft on the standards track.

And that can be treated as initial support for PS over Exp.

kre

---

From: Thomas Narten <[email-masked]>
Date: Mon, 02 Nov 1998 09:04:18 -0500

> One issue to consider is whether this doc is sufficiently
> established to be considered for Proposed Standard status, or
> whether it should remain as Experimental, as is 2052.  That's for
> the WG to decide of course.  The status quo (without conconsensus to
> the contrary) will be for it to remain as experimental.  2052 is to
> be obsoleted.

It should be noted that there are other folks/WGs that would be
disappointed to see this document remain experimental. Specifically,
there are number of protocols coming out of the Applications Area that
use or would like to use SRV. From a process perspective, such
documents cannot be Standards Track if they depend on SRV.

If the WG decides to leave the document Experimental, it would be good
to also include a statement explaining why PS was not felt to be
appropriate at this time.

Thomas

---

From: "Michael A. Patton" <[email-masked]>
Date: Mon, 2 Nov 1998 22:25:28 EST

-----BEGIN PGP SIGNED MESSAGE-----

   From: Robert Elz <[email-masked]>
   Date: Sun, 01 Nov 1998 15:29:38 +1100

   One issue to consider is whether this doc is sufficiently
   established to be considered for Proposed Standard status, or
   whether it should remain as Experimental, as is 2052.

I support the draft and suggest that it go forward on the standards
track.  We have some experience with the experimental 2052 and that
supports the usefulness, and I think the discussion has shown that the
spec is stable enough to go onto standards track.

           ___
  /|  /|  /|  \  MAP Network Engineering, Inc.           [email-masked]
 / | / | /_|__/  Internet Engineering Consultant       +1 617 576 9246
/  |/  |/  |     Routing, DNS, more                 http://map-ne.com/

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 16 Nov 1998 01:26:02 -0800

> (1) Although asdf.com, which is used for the examples, does not
> currently exist, it could in the future.  I suggest globally replacing
> it in the draft with example.com or asdf.example.

someone else noticed this also.  i've changed it as you suggest.

> (2) Probably the most serious thing is the wildcard question about
> which there has been previous correspondence (see message from Andrew
> Draper and my reply appended below).  A wildcard is commonly used
> today in MX, for example, to cause mail for all names in the wildcard
> scope to go to a particular set of servers.  But wildcards in the
> current DNS are restricted to the leftmost label in the owner name
> wheras with SRV you would like to be able to put an asterisk after the
> service and protocol, such as _smtp._tcp.*.example.com.  The idea is
> that this would match queries such as
> _smtp._tcp.specific.name.example.com. I don't know how difficult it
> would be to extend wildcard processing although it seems to me that as
> long as you are claerly restricted to a single asterisk, it should not be too
> bad.  As per my message below, this causes complications for DNSSEC
> for which there are, it seems to me, three soltuions: (1) change the
> SIG RR to explicitly accomodate the embedded asterisk case, (2) have
> some logic based on the leading underscore in the SRV name prefix
> labels, and (3) don't expand the asertick in answers for non-leading
> asterisks. 

in my response to mr. draper i suggested that we just not recommend SRV
as a replacement for MX, specifically so that we don't have to ponder the
question at this time.  as this was one of the alternatives he himself
had mentioned in his mail to me, it seemed prudent to take the easy way out.

> (3) The draft mentions A RRs but never AAAA RRs.  Seems like something
> should be done about this even if it's only one sentence somewhere
> that says references to A RRs include AAAA RRs.

done.  i'm calling them "address records" now.  i'll define that loosely.
i don't want this to be the RFC where we have to agree on how we'll do
additional data for multiprotocol requestors -- that's an EDNS1 thing.

> (4) kre a while ago asked if this was applicable to DNS, ICMP, etc.
> I.E., are you supposed to do an DNS retrieval to figure out where to
> send DNS queries or pings to.  Presumably not and something could be
> mentioned about this.

no.  there is no applicability statement in the document at all, and the
place that mentioned revamping telnet has been removed.  SRV is about new
protocols or respecifications/extensions to older ones.

> I support advancement of this draft on the standards track. For most
> of the above I'd be happy to abide by the authors decisions on whether
> they want to diddle the draft.  After all, its only going for proposed
> and most of the sorts of changes suggested above could easily be made
> at the draft standard level.  However, I would like some clearer
> resolution of the wildcard issue.  It seems like a problem, some
> messages have been posted on it, and there has been no response.

the major thrust for 2052bis is indeed to get it onto the standards track.
the more we diddle with it the less likely that is to happen quickly.