Subject: [Sip] Comments on SIP SRV Draft

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 19 Feb 2002 01:18:09 -0000

Hi.

So a few things that I noticed.  Apologies for
re-reports.  I bet it's ever-so-slightly anoying.

 * Section 1; 2nd Paragraph:
   First use of "DNS" on the second line.  Dunno
   if this merits a pointer to any of the DNS
   RFCs or perhaps just the abbreviation broken
   out.

 * Section 2; 2nd Paragraph:
   First use of: "TCP, UDP, TLS, SCTP" and "IP".
   (Well, "IP" also occurs in the abstract, but.)
   Again, I don't know whether it's really
   necessary to spell these out (in particular,
   a reader not knowing all of { "IP", "UDP",
   "TCP" } I suspect is going to be the exception),
   but just in case, they're here.

 * Section 2; 2nd Paragraph; Sentence "All proxies
   must implement both UDP and TCP [...]":
   Is it worthwhile throwing "TLS" into the pot
   here now?

 * Section 2; 3rd Paragraph; Sentence "It is
   important to note [...]":
   s/processing/the processing/ ?

 * Section 4; 1st Paragraph:
   First use of "UAC".

 * Section 4; 2nd Paragraph:
   Well, Rohan's suggested new text, which I do
   find easier to parse.  However, being
   First-Use Boy, I detect this unknown "URI".

 * Section 4; 3rd Paragraph; Sentence "That
   is, once a server [...]":
   s/responses/INVITE responses/
   [This may be being a little keen.]

 * Section 4; 4th Paragraph; Sentence "Because
   the ACK request for [...]":
   s/responses/responses to INVITEs/
   [Again, this may be being a little keen.]

 * Section 4; 4th Paragraph; Sentence "Because
   the ACK request for [...]":
   Perhaps s/most definitely/probably/ ?
   "most definitely not" sounds like a wager to
   me. &:)

 * Section 4.1; 3rd Paragraph; Sentence "Otherwise,
   if no transport protocol [...]":
   Well, there may well be no bug here, or the
   bug may be in a different Section; however, I
   am wondering why there was particular need to
   explicitly rule out using these procedures
   when using an outbound proxy identified by
   an IP as opposed to a domain name?
   I possibly wrong, but I think that bis
   exclusively defers to this document for rules
   on how to determine the server to contact,
   so I would perceive this to be a hole.

 * Section 4.1; 4th Paragraph; Sentence "Otherwise,
   if no transport protocol [...]":
   s/target/TARGET/

 * Section 4.1; BINDish Zone File:
   I'm guessing that the last entry should have
   been "SIP+D2L"?
   Also, is there any reason why this entry does
   not look particular SRVish; i.e., has a
   distinct lack of "_"s?  I guess the whole
   TLS-isn't-a-transport thing is problematic
   here....

 * Section 4.1; 7th Paragraph; Sentence "If the
   client supports [...]":
   Personally, I would find it helpful to do
   something like:
   s/UDP and TLS/UDP and TLS only/
   I might also note that this is a non-conforming
   implementation. &;)

 * Section 4.1; Last Paragraph:
   Is the implication here that once a client
   has decided on a transport, then only results
   from a query of that SRV record should be used,
   and no other transports considered?  If so,
   especially if we're talking "MUST NOT", this
   could probably be a little clearer.

 * Section 4.2; Paragraph 4 (Indented):
   I am actually slightly confused, as a result
   of this paragraph, on how these steps fit
   together.  I would have thought that in
   some ways 4.1 was end-of-the-road; i.e.,
   because the NAPTR RFC specifies the "s"
   flag, the use of SRV, and then thus A, I
   guess, was sorta automatic.  Otherwise,
   may be 4.1 should specify that the result
   of the NAPTR lookup is applied to TARGET?
   In any case, thouls this paragraph be
   s/SRV/NAPTR/ ?

 * Section 4.3; Paragraph 2:
   Rohan's text is good here, I think.

 * Section 4.3; Paragraph 3:
   Doesn't it always come down to A/AAAA in
   the end?  [I might be exposing a blatant
   misunderstanding of SRV, here.]

 * Section 4.3:
   In general, don't these rules apply to
   multiple records of any type?
   In particular, I'm thinking multiple-A
   records.  The Section title would seem
   to preclude this?

 * Section 4.4: Paragraph 1: Sentence 2:
   I would suggest: "When a server is
   contacted successfully, all retransmissions
   for the transaction, as well as ACK/CANCEL
   requests for that transaction, MUST go
   to the same server."

 * Section 5; Paragraph 4: Sentence 1:
   s,A,A/AAAA, ?

 * Section 5; Last Paragraph:
   Ah, I guess this relates to my earlier
   comment.  Since we do "SIP/2.0/TLS" (or
   did I imagine this), then does this
   imply _sip._tls.this-domain-is-so.invalid
   ?  I'm trying to work out if this conflicts
   with 2782, but since it says (under the
   bit talking about the "Proto" component
   of the SRV RR): "though any name defined
   by Assigned Numbers or _locally_ may be
   used", I guess it's okay (though "locally"
   doesn't seem to be so well defined).
   And I suppose a name collision should be
   v. unlikely [thanks to Mr. Oberg?]....

 * Section 6:
   I feel that this section is too fond of
   "maddr", since we now know better.  It's
   potential role as "TARGET" is already
   explicit.  I doubt there is a need to
   dwell here.

Cheers,

 - Jo.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Feb 2002 00:28:35 -0500

Jo,

Thanks for your comments. Responses inline.

>    RFCs or perhaps just the abbreviation broken

No, its not needed.

>    but just in case, they're here.

Also not needed. Thats the opinion of our tech writer as well,
when this issue has come up in bis.

If you don't know what IP is, you shouldn't be reading this document ;)

>    Is it worthwhile throwing "TLS" into the pot

OK.

>    s/processing/the processing/ ?

Fixed.

>  * Section 4; 1st Paragraph:

I'll bite on this one. The reason is that this document will be
(and has been) read by people in other groups (HTTP, DIAMETER) who
are working on usage of DNS for their protocols. SO, I cannot assume
deep SIP knowledge, which is why there is so much tutorial material.

>    First-Use Boy, I detect this unknown "URI".

See my response to him, with the rewrite.

I'll pass on the URI expansion.

>    [This may be being a little keen.]

Fixed.

>    [Again, this may be being a little keen.]

Fixed.

>    "most definitely not" sounds like a wager to

I think just "not get the ACK" is OK.

>    so I would perceive this to be a hole.

Huh? I am lost. What "procedures" are ruled out by an
outbound proxy? If your output proxy is an IP address,
of course you won't look up anything in DNS.

>    if no transport protocol [...]":

Fixed.

>    TLS-isn't-a-transport thing is problematic

The example has changed due to SIPS. Basically, if you use TLS, you
would look for "SIPS+D2T". Thus, the record above is gone.

>    I might also note that this is a non-conforming

This was fixed as part of the change in the example. 
>    and no other transports considered? 

Yes. We used to have the client lookup SRV records for all transports it
supported, and merge the priority values across records. This turned out
to be a big no-no for various administrative problems. 

 If so,
>    could probably be a little clearer.

Changed to:

\motivation{This is a change from RFC 2543. It specified that a client
would
lookup SRV records for all transports it supported, and merge the
priority values across those records. Then, it would choose the most
preferred record.}

>    In any case, thouls this paragraph be

You are talking about this "weird case" paragraph?
That weird case is gone now. If there is an explicit
port, you do an A/AAAA, and you are done. 

>    Rohan's text is good here, I think.

See my response to him; its nuked.

>    misunderstanding of SRV, here.]

No, you are correct. However, this paragraph is not relevant
any longer. This whole section is much thinnger now. All
it really does is define "failure" as used in rfc2782.

>    records.  The Section title would seem

Great point. With the new text thats there, the section
title should say the same. What needs to change is that
the references from above that start with a list of A/AAAA
records, should simply say "try one, and if it fails, based on
the definition of failur ein Section XXX, try another".

>    requests for that transaction, MUST go

Reworded to:

The process of the previous sections is highly stateful. When a server
is contacted successfully, all retransmissions of the request for the
transaction, as well as {\ACK} for a non-2xx final response, and
{\CANCEL} requests for that transaction, {\MUST} go to the same
server.

>  * Section 5; Paragraph 4: Sentence 1:

Good catch. Thats an IESG hot-button....

>    ? 

Well, its _sips._tcp, but why would it be .invalid?

>  I'm trying to work out if this conflicts

You've totally lost me. If the Via is:

SIP/2.0/TLS proxyfarm.example.com

you'd look up: _sips._tcp.proxyfarm.example.com.

>    explicit.  I doubt there is a need to

GOod point. maddr examples removed.

Thanks for your comments,

Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com