Subject: Future progress of 2052bis

From: Robert Elz <[email-masked]>
Date: Sat, 27 Feb 1999 21:40:08 +1100

You should have seen by now the IESG response to DNSIND's request to
advance 2052bis as a PS.

There were 4 issues raised, we now need to decide what to do about
those.

Of the four, my estimation is that 3 of them are no-brainers, and that
we can (and perhaps should) make the changes requested (or at least,
changes to a similar effect).   That leaves just one that I think that
we really need to consider.   Of course, you are all free to disagree on
the other three as well...

This issue is now open for discussion on the list, and will be on the
agenda for the IETF meeting.

The four issues were...

1. the http example in the introduction.

I think I agree with the IESG there, someone reading that section will not
have seen the statement later in the draft that the examples are using
familiar protocols just to aid understanding, and that SRV records aren't
expected to apply to such protocols.

I think there are three changes we could make which would avoid this problem.

a. We could simply remove the example from the intro.   That would be a pity
as I think it provides some motivation for what follows (it enables the
reader to quickly get an idea of what the rest of the doc is attempting to
accomplish).

b. We could pick a protocol which is specifying SRV and use that in the
examples.   Unfortunately, that will be difficult.   It is hard to imagine
any finished spec which specifies SRV precisely as rfc2052bis does (even
very recent drafts, such as the NAPTR draft that Randy just forwarded the
announcement of to this list uses SRV without the underscores still) - 
especially it is hard to imagine a finished spec that meets the new 
requirements that the IESG is (just now) asking us to ask of docs that
specify use of SRV records....   If we were to select some future RR type
that is still in the process of being defined then we either have to hang
waiting for that doc to be ready to be published, or we run the risk that
they will decide to not use SRV after all, and we will be in the same position
as if we used the http example.

c. We can invent a new protocol just for the purpose of the example.
That is, for the example we simply postulate the existance of some
fictional protocol that uses SRV records, and demonstrate the use of that.
As all we care about for this example is that someone wants to go from a
name and a protocol to find a server for the protocol for that name, it doesn't
really matter what the protocol is, or anything about it at all, so I would
suggest that we move this direction.

2. citing 2119 as a reference.    This is sheer gibberish.   The reference
for BCP14 already indicates that it is rrc2119 (and if it didn't, the RFC
editor would fix it anyway).    About all we can rationally do here is to
make it clearer that the string "BCP 14" is jut just black magic, but
actually means the reference in the references section called "BCP 14"...
The traditional way to do this (which is done other places in the doc) is
to enclose the label in [ ] (so the text becomes
	"... as specified in [BCP 14]."

3. Provide info for authors specifying use of SRV for new protocols (or even
old ones).   That is, make it easier for them to write their docs without
forgetting anything...    This seems entirely reasonable to me, the IESG
have provided us with text which is pretty close to good enough, I'd suggest
just using their text.   All I would change is to remove the upper case MUST
where it is telling protocol authors what to do, that makes no sense at all
in the BCP14 usage of those terms which has been adopted here.   Their text
does presume that we do what they have requested in the last point - however
adapting that if the WG decides not to acceed to the IESG's request would be
easy.

4. Delete the definition of the "Weight" field, and instead make it an
optional hole into which protocol authors specifying use of SRV can plug
anything they like.   Keep the definition we have as a sample that others
can use by reference (for when the one created by dnsind is deemed good
enough).

This one is the one which is the only real change of substance requested
by the IESG.

Personally, I have no real opinion either way.   I guess the question really
is whether the added flexibility given to future protocols using the SRV
record can justify the increased burden on zone adminstrators attempting
to sort ough how to set the weight fields for several different protocols
which all use the weight in different ways.

It is also interesting to note that if this extra flexibility is added, and
there aren't two uses of it (two interoperable uses, whatever that means in
this context) when the doc is ready for DS status, then the feature would
have to be removed...

Anyway, your chairs need opinions expressed on these issues - on the list
in the next couple of weeks, and then during the IETF meeting.  After that
we will determine if some consensus appears to have evolved, and if so,
ask the editors to update the document to reflect the consensus, and then
send it back to the IESG and see what their opinion is this time.   Current
advice is that if only these changes are made no new IETF last call would be
needed (though if the change in 4 is made, my suspicion is that not doing a
new IETF last call would be a mistake).

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 01 Mar 1999 09:41:32 -0600

My penny-and-a-half's worth ...

Another option 1d would be to change the "Introductory example" to
read,

   HTTP is not now specified to use the SRV record.  But if it
   were, then when a SRV-aware web-browser wanted to retrieve

      http://www.example.com/

   it would do a lookup of

      _http._tcp.www.example.com

   and retrieve the document from one of the servers in the reply.  The
   example zone file near the end of this memo contains answering RRs
   for this query.

2. I agree with kre.

3. I agree with kre.

4. I think the handling of WEIGHT should be uniform for all SRV
users, but I'm not adamant.

Another thing which popped into my head: would it be wise to (once
again) call users' attention to the Bad Things that could happen if
all records in an RRSET don't have the same TTL?  Or is it all right
to expect them to know that already?

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 01 Mar 1999 07:55:33 -0500

From:  Robert Elz <[email-masked]>
To:  [email-masked]
Date:  Sat, 27 Feb 1999 21:40:08 +1100
Message-Id:  <[email-masked]>

>...

I think we should just use the EXAMPLE protocol in the example  :-)

>suggest that we move this direction.

I agree on points 2 and 3 with KRE.

>can use by reference (for when the one created by dnsind is deemed good

I think that the draft should retain weight for static weighting.  If
anything, I'd change the wording to much firmer and less apologetic.
The circumstance of having different servers of different inherent
speeds is very common and there is no reason not to take care of this
automatically.  For "dynamic" weighting, the draft should just say
something like "For weighting factogs which change more rapdily than
the SRV RRs can be updated, as is usually the case with dynamic run
time load, other mechanisms should be used." and leave it at that.

On the other hand, if it is thought that having an additional
unspecified field, beyond the canonical static weighting field, for
arbitrary protocol specific information would be good, I would have no
objection to that.

>new IETF last call would be a mistake).

Thanks,
Donald

---

From: Greg Hudson <[email-masked]>
Date: Mon, 01 Mar 1999 17:54:28 EST

> users, but I'm not adamant.

I will weigh in (sorry) on the side of uniform handling of the weight
field.  If different protocols can treat the weight field differently,
then it becomes impossible to write a single library routine to
translate from a SRV record to an ordered list of addresses to try.
And while there are certainly opportunities to do better
load-balancing than DNS allows for, treating the weight field
uniformly doesn't make that any harder.  You just set the weights to 0
in SRV records for protocols or situations where better load-balancing
is in use.

If someone could point out different legitimate ways of handling the
weight field (as opposed to ignoring it entirely), that might change
my mind.

---

From: Michael Mealling <[email-masked]>
Date: Mon, 1 Mar 1999 20:55:43 -0500 (EST)

Robert Elz said this:
> It is hard to imagine

Doh! I'll fix this...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Mon, 1 Mar 1999 23:46:35 -0500 (EST)

> You should have seen by now the IESG response to DNSIND's request to

My comments are simply to provide a point of view from someone who
is also trying to send a document as a PS that depends on this one...

> a. <delete it>
> b. <pick another one>
> c. <invent a fictitious one>

(c) is fine with me. The NAPTR document specifies that SRV is used 
with NAPTR to discover the actual servers to connect to. It doesn't
depend on a definition for how SRV would work with HTTP alone.

I do hope that someone out there is planning on working on a
short and simple document on using SRV and HTTP (as well as other
protocols). At least from my point of view the only real issue is
what to do when port numbers in a URL conflict with what the port
number in an SRV would be.

> 2. citing 2119

Sure...whatever....

> adapting that if the WG decides not to acceed to the IESG's request would be

I think all of these points are covered in the NAPTR draft. I'm somewhat
concerned about how the IESG is assuming that SRV is used in a protocol
specific way. I'm wondering if the NAPTR document will get some push
back on that issue....

> 4. The Weight issue

The NAPTR document uses the dnsind definition of Weight for all protocols.
Again, NAPTR specifies which protocol to use and which hosts to 
contact instead of, as the IESG seems to assume, the other way around.
I'm slightly concerned if this is going to cause NAPTR any problems in
its usage of SRV...

-MM