Subject: Re: 2052bis miscellany

From: Robert Elz <[email-masked]>
Date: Tue, 01 Dec 1998 17:01:30 +1100

Date:        30 Nov 1998 21:16:21 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I imagine that the intent is to handle weights w[1], w[2], ..., w[n]
  | as follows:

I will leave it to the authors and WG to determine if that algorithm is
suitable for the draft.    I do agree that some basic algorithm ought
be provided though, to avoid different implementations using quite
different methods to determine this, leading to cases where the effect
of what is in the zone file depends upon which implementation the
resolver happens to be - not a well defined situation.

  | This algorithm naturally accepts, and ignores, records with weight 0.

That is not quite how I read the original.  It seemed to me that a "0"
was intended to indicate "use this RR" not "ignore this RR".  It was
only specifically mentioned in the case where there were no other RRs
available, but I didn't think to restrict it to that case really.  What
ought happen when there were both 0 and non-0 weights needs to be
specified (explicitly, not just as a side effect of the algorithm).

I would also suggest explicitly making it clear in the draft (in words,
not just in the algorithm) that the weights are ordered with bigger
numbers having preference (a better chance of being selected), which is
the inverse of how the priority is handled.

  | I don't see any reason for a more complicated procedure.

I think it needs to handle the case where the RR selected turns out to
lead to an unresponsive address.   That is, the procedure needs to allow
for a second choice RR to be selected without the possibility that the
first will be selected again (the algorithm must deterministically terminate
once N selections have been made, where N is the number of RRs with equal
priority).   The pseudo-code currently in the draft handles that OK, as
its effect is to build a sorted list, then simply scan the list.   Your
algorithm (just as it stood, without anything more) wouldn't.

Also, upon thinking about this just now, I believe that something needs
to be explicitly said about how to handle the case where the name from the
SRV record selected leads to multiple A records.   What is the behaviour
of the client to be in that case?    Try any one of them?   Try all of
them?   Any specific order?

  | Some people will (deliberately or accidentally) use 16-bit arithmetic
  | for s, so I suggest requiring that weights add up to at most 32767.

Operationally, I think this is unrealistic.    People won't do that kind of
mental arithmetic when building lists of SRV records - especially not when
adding a new one.   And with bigger weights having greater chance of
being selected, that is likely to lead to situations where ...

	"I just added this new fast server, and gave it the a much better
	chance of being selected than any of my older ones, which I left
	all alone, as I didn't want to alter the relative frequency with
	which they were chosen - and now things don't work at all, I set
	the new one's weight to 25000 to make it be the most preferred by
	a long way - none of the earlier ones was bigger than 5000".

I think it is much easier to simply get the implementations right, once
each, then to deal with that kind of operational nightmare foreevr after.
If it takes specific wording requiring (at least) 32 bit arithmetic in
the resolver to implement the algorithm to make sure implementors don't get
it wrong, then so be it.

Lastly, as WG chair, I would ask the author(s) to send the proposed new
wording of the relevant sections to the list ASAP, so we can agree (or
not) that what is proposed is satisfactory, without having to wait until
after the draft has appeared.

kre

---

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Dec 1998 13:07:17 -0500

In anticipation of bringing this document before the IESG, I've
reviewed it for the things that are likely to trip it up during its
journey.

1) I think this document needs an applicability section. Specifically,
who is supposed to implement SRV RR lookups on clients? For which
protocols? The document seems to suggest that all clients should do
this for all protocols.  Is that the intent? As a specific example,
web browsers is the first example. Is this document telling web
browser implementors they SHOULD implement SRV lookups? Seems like
whether it is or is not appropriate to use SRV RRs is
application-specific, especially for existing services that are
already widely deployed.

The remaining comments are nits, but I'll mention them on the list as
they apply to drafts in general. Folks working on other drafts please
take note!

2) The document should say somewhere near the beginning (i.e.,
introduction and/or abstract) that it that it is obsoleting RFC 2052,
since that is presumably what it does.

3) The document probably needs an IANA considerations section. Since
this document doesn't really ask anything new of IANA, it could be a
one liner, simply saying that this document relates to RR type 33,
which has already been assigned for the use described in the document.

4) The document needs to define the terms MUST/MAY/SHOULD, since the
document uses them. The standard language for doing so is in RFC 2119:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

5) Since this document replaces/obsoletes an existing RFC, it should
include a Changes section (e.g., in an appendix) that summarizes the
technical changes between the RFC version and the new version. If
there are no significant changes, stating so would be useful.

6) You should add the standard ISOC copyright (e.g., in an appendix),
per RFC 2026:

         "Copyright (C) The Internet Society (date). All Rights
         Reserved.

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
         copyright notice and this paragraph are included on all such
         copies and derivative works.  However, this document itself may
         not be modified in any way, such as by removing the copyright
         notice or references to the Internet Society or other Internet
         organizations, except as needed for the  purpose of developing
         Internet standards in which case the procedures for copyrights
         defined in the Internet Standards process must be followed, or
         as required to translate it into languages other than English.

         The limited permissions granted above are perpetual and will
         not be revoked by the Internet Society or its successors or
         assigns.

         This document and the information contained herein is provided
         on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
         ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
         IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
         OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
         IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
         PARTICULAR PURPOSE."

Thomas

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Dec 1998 23:56:23 -0000

Robert Elz writes:
> It seemed to me that a "0"
> was intended to indicate "use this RR" not "ignore this RR".

This complicates the specification, and---unless I've misunderstood the
intended meaning of ``weight''---it complicates client implementations.
What is the benefit supposed to be?

  [ want to guarantee that each record is used at most once ]
> Your algorithm (just as it stood, without anything more) wouldn't.

False. The algorithm, as stated, tries each record at most once.

>> Some people will (deliberately or accidentally) use 16-bit arithmetic
>> for s, so I suggest requiring that weights add up to at most 32767.
> mental arithmetic when building lists of SRV records -

Then how are they going to be prevented from using weights above 65535?

The server needs to check for mistakes anyway. Why not make life simpler
for clients? See http://pobox.com/~djb/proto/design.html.

> SRV record selected leads to multiple A records.

2052bis already says explicitly that the client should try each address.

> What ought happen when there were both 0 and non-0 weights needs to be
> specified

I raised this issue in my first message. I wish you would learn to read
more carefully.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Dec 1998 17:00:06 +1100

Date:        1 Dec 1998 23:56:23 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | This complicates the specification, and---unless I've misunderstood the
  | intended meaning of ``weight''---it complicates client implementations.
  | What is the benefit supposed to be?

That was just a query for the authors - it needs to be made explicit.

  | False. The algorithm, as stated, tries each record at most once.

Oh yes, missed step 5, sorry (once I got to "use record i" I mentally
assumed the procedure was finished).

  | Then how are they going to be prevented from using weights above 65535?

That's easy - the server will check that and can issue an error message.
What's more, every time the server sees such a RR, it will reject it.
The check you provided would sometimes cause the server to reject a SRV
record that in itself, is perfectly legitimate  - ie: copy a SRV from one
name to another, which already had one extra SRV, it was OK where it was,
but makes the SRV RRset illegal where it is going.   That's the kind of
thing that leads to operational problems.

  | The server needs to check for mistakes anyway. Why not make life simpler
  | for clients? See http://pobox.com/~djb/proto/design.html.

Why should clients get all of the benefit?  Assuming you even believe
there is any benefit to be gained here?   16 bit hosts are in dwindlingly
short supply I would have thought (there are still plenty of 8 bit
processors being used in embedded applications - they're going to have to
do extended arithmetic anyway, aside from those, almost everything around now
is 32 bits or bigger).

On the other hand, you're requiring the server to go check all SRV records
for something that there's no particularly rational reason to check for.
What makes you think that server implementors will bother?   Recall that
in the textual zone file, the records of an RRset aren't required to be
adjacent, they can be spread all over the place.   That means there can't
be a simple adder of the weights for the current SRV, instead it needs to
go extract the weights from the earlier SRV records each time one has been
seen, and verify them later - that or after loading the zone, it needs to
go back and re-scann looking for SRV records that total too much.   Since
none of this affects server operation any way at all, I'd tend to assume that
at least some server implementors would not bother (and as this requirement
has never existed before, and yet SRV handling servers do exist already, I
can pretty much guarantee that there are servers out there now which don't
check it...)

  | 2052bis already says explicitly that the client should try each address.

Oh, OK, again, apologies, must have missed that.

  | I raised this issue in my first message. I wish you would learn to read
  | more carefully.

I know.   I was just pointing it out to the authors as something that
ought be explicitly mentioned (in text).

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Dec 1998 17:12:41 +1100

Date:        Tue, 01 Dec 1998 13:07:17 -0500
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | 2) The document should say somewhere near the beginning (i.e.,
  | introduction and/or abstract) that it that it is obsoleting RFC 2052,
  | since that is presumably what it does.

Is that needed, really, given that the RFC format will add a "Obsoletes"
header up at the start, which isn't permitted in I-D's ?   Once it became
an RFC, that would be redundant info.   I guess that if there was any
question that readers might not understand its intent when reviewing the
draft it would be a good idea to say so .. but just calling it 2052bis kind
of makes that obvious, does it not?

  | 3) The document probably needs an IANA considerations section.

Does it?   Is that going to be required of all RFCs now, even ones that
have nothing whatever to do with IANA assignments?   Why?   More noise
in the docs to no purpose whatever?   I agree in the cases where some
request is being made of the IANA that such a section is needed, I don't
see the point where the IANA is not to do anything because of the doc.

  | 6) You should add the standard ISOC copyright (e.g., in an appendix),
  | per RFC 2026:

That's also for RFCs, and the RFC editor will add it.   In general I-D's
are not required to be copyright assigned to ISOC, and I would strongly
resist (in poised) any attempt to require that (or course, anyone is free
to do so if they desire).

What's more, it is only RFC editor published RFCs that necessarily contain
this section - if you look on munnari.oz.au for RFC2389 you will find no
obnoxious copyright notice, instead you'll find a statement that the doc
is in the public domain.   From other RFC archives, that have simply copied
the RFC editor's version, the copyright notice will appear.   The copy on
munnari is not one that was edited by the RFC editor.

kre

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 02 Dec 1998 07:53:18 -0500

From:  Robert Elz <[email-masked]>
To:  Thomas Narten <[email-masked]>
Cc:  [email-masked]
In-Reply-To:  Your message of "Tue, 01 Dec 1998 13:07:17 CDT."
	                  <[email-masked]> 
Date:  Wed, 02 Dec 1998 17:12:41 +1100
Message-Id:  <[email-masked]>

>of makes that obvious, does it not?

Why do you think an Obsoletes header in not permitted in I-Ds?  I've
had them in drafts and no one objected.  In fact, things are pretty
loose about headers in I-Ds.  They get fixed to the standard RFC
format by the RFC Editor.

>see the point where the IANA is not to do anything because of the doc.

If it is really IESG policy that all draft now must have an IANA
Considerations section even when they do not call on IANA facilities,
this should be promulgated officially.  The trend has certainly been
this way but I didn't know it had gone that far...

>to do so if they desire).

Ditto.  I've never put any sort of copyright notice onto any on my
I-Ds.  It was also my understanding that the ISOC copyright was a
copyright on the document with an RFC number.  Thus it is
inappropriate to put such a notice on an I-D.

>munnari is not one that was edited by the RFC editor.

Donald

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Dec 1998 06:55:49 -0500

> of makes that obvious, does it not?

The point is to be clear, and to be sure the "obsolete's line" gets
added correctly. It usually does, but not always. We're talking about
a one sentence addition...

> see the point where the IANA is not to do anything because of the

You can probably get by without one. However, IANA reviews all
documents during last call looking for action items on their part. So
having a section helps them. Again, we're talking about one sentence.

> That's also for RFCs, and the RFC editor will add it.

This document is heading for an RFC (and presumably soon), so saying
the draft doesn't need it is misses the point. Also, there is general
feeling that it would be preferable for authors to be adding the
notice, rather than the RFC editor (i.e., so authors are clearly in
the loop). Having said that, the rfc editor is adding the copyright,
so this isn't a "show stopper".

Thomas