Subject: [Sip] comments on srv draft

From: Rohan Mahy <[email-masked]>
Date: Mon, 18 Feb 2002 10:20:54 -0800 (Pacific Standard Time)

Hi,

below are some comments on the SRV draft.  apologies in advance for any
dups:

thanks,
-rohan

comments on SRV draft:

page 5 3rd para:  proposed rewrite:

The procedures here are invoked when a client need to send a request to a
server identified by a SIP URI (frequently the Request-URI); or when a
client wishes to send a request to a specifically configured outbound
proxy server, which is identified by a domain name instead of a numeric IP
address.  The procedures defined here, in no way affect any URI processing
(i.e. the client will never rewrite the Request-URI or other SIP URIs with
the result of the DNS lookups); they only provide a list of IP address,
port, and transport protocol tuples to which the request can be sent.

page 6 after 2nd para:  insert:

If the no transport is specified, but the resulting UDP would exceed the
MTU-related size limitations described in Section 19.1.1 of [1], the
client MUST use TCP.

page 8 4th para:  proposed rewrite:

The client SHOULD maintain a table indicating the status of a particular
host (that is, whether attempts to contact it resulted in success or
failure).  The table is indexed with the IP address, port, and transport
for a particular host.  If a request fails to a particular host, the
client updates the table to reflect that this host should not be contacted
for some protocol-determined or policy-determined period of time.  A
client SHOULD honor the time proposed in any Retry-After header in a 503
response.  A RECOMMENDED default period of time is one hour.

page 10 1st full para:  should insert a brief reminder of the procedure
used before a failure.  for example:

Recall that when a server first attempts to send a response, it checks
......

page 11 1st para:  remind the reader that low values are "better" than
high values.

NITS:
page 3 3rd para:  s/Transport Protocol/The choice of transport protocol/

page 4 2nd para:  the following text is redundant duplication of the
previous sentence:

        "The request would fail, and that would be detected by proxy 1.
         Proxy 1 would then try proxy 2.2"

page 4 4th line from bottom: "a SIP response"  -> "some SIP responses"  or
                                                  "responses to INVITE
requests"
top of page 5:  SHALLNOT

page 5 para 6: s/domain/domain name/

page 6 para 5 ("The NAPTR records"):  s/domain to/domain, to/

page 7 near bottom:  s/where, where/where/

page 9 last para: s/RFC 2543bis/SIP/

page 10 3rd para: s/tred/tried/

_______________________________________________
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: Wed, 20 Feb 2002 23:33:00 -0500

Rohan,

Thanks for your comments. Responses inline.

> port, and transport protocol tuples to which the request can be sent.

This paragraph had to be rewritten already to reflect the loose route
stuff and the SIPS URI. It now reads:

The procedures here are invoked when a client needs to send a request
to a resource identified by a SIP or SIPS (secure SIP) URI. This URI
can identify the desired resource to which the request is targeted (in
which case, the URI is found in the \header{Request-URI}, or it can
identify an intermediate hop towards that resource (in which case, the
URI is found in the \header{Route} header). The procedures defined
here in no way affect this URI (i.e., the URI is not rewritten with
the result of the DNS lookup), they only result in an IP address, port
and transport protocol where the request can be sent. SIP
\cite{draft-ietf-sip-rfc2543bis} provides guidelines on determining
which URI needs to be resolved in DNS to determine the host that the
request needs to be sent to. In some cases, also documented in
\cite{draft-ietf-sip-rfc2543bis}, the request can be sent to a specific
intermediate proxy not identified by a SIP URI, but rather, by a
hostname or numeric IP address. In that case, a temporary
URI, used for purposes of this specification, is constructed. That URI
is of the form sip:<proxy>, where <proxy> is the domain or numeric IP
address of the next-hop proxy. As a result, in all cases, the problem
boils down to resolution of a SIP or SIPS URI in DNS to determine the
IP address, port, and transport of the host to which the request is to
be sent.

> MTU-related size limitations described in Section 19.1.1 of [1], the

Excellent catch. You are correct. This little exception needed some
words both here and in the transport section of bis (it is already there
in the pre-release). The text here now reads:

Otherwise, if no transport protocol is specified, but the TARGET is a
numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP
for a SIPS URI. Similarly, if no target is specified, and the TARGET
is not numeric, but an explicit port is provided, the client SHOULD
use UDP for a SIP URI, and TCP for a SIPS URI. This is because UDP is
the only mandatory transport in RFC 2543 \cite{rfc2543}, and thus the
only one guaranteed to be interoperable for a SIP URI. It was also
specified as the default transport in RFC 2543 when no transport was
present in the SIP URI. However, another transport, such as TCP,
{\MAY} be used if the guidelines of SIP mandate it for this particular
request. That is the case, for example, for requests that exceed the
path MTU.

It is better to point to bis for the proper guidelines on strengths for
using TCP, than repeating them in sip-srv. 

> response.  A RECOMMENDED default period of time is one hour.

Actually, this entire bit is gone. This reflects private comments
received from two independent readers.

Here are the reasons:

1. its an implementation choice. There is actually no need to specify
this behavior at all.

2. It is really easy to get this wrong. Henning found all kinds of odd
failure cases that arise. For example, if ad administrator updates a
cluster by taking each element down, one at a time, over a period of an
hour, a client might end up seeing the entire cluster as failed, even
though no more than one element has been down at once! Generally,
negative caching is hard if not done properly. Rather than try to work
through all of the details, since it is an implementation choice, it has
been removed.

> Recall that when a server first attempts to send a response, it checks

Text now reads:

A server, according to RFC BBBB \cite{draft-ietf-sip-rfc2543bis}, will
send a response on the connection it arrived on (in the case of
reliable transport protocols), and for unreliable transport protocols,
to the source address of the request, and port in the \header{Via}
header field. The procedures here are invoked when a server attempts to
send
to that location and that response fails (the specific conditions
are detailed in RFC BBBB).  "Fails" is defined as any closure of the
transport connection the request came in on before the response can be
sent, or communication of a fatal error from the transport layer.

> page 11 1st para:  remind the reader that low values are "better" than

Done.

> page 3 3rd para:  s/Transport Protocol/The choice of transport protocol/

Fixed.

>          Proxy 1 would then try proxy 2.2"

Already fixed.

> page 4 4th line from bottom: "a SIP response"  -> "some SIP responses"

Changed to "some SIP responses".

> top of page 5:  SHALLNOT

Fixed.

> page 5 para 6: s/domain/domain name/

FQDN is even better.

> page 6 para 5 ("The NAPTR records"):  s/domain to/domain, to/

Fixed.

> page 7 near bottom:  s/where, where/where/

This whole paragraph is gone, since the weird case is also gone (based
on feedback from DNS folks). Basically, if you have an explicit port,
you don't do NAPTR to figure out the transport, you use A records with
the default transport.

> page 9 last para: s/RFC 2543bis/SIP/

Fixed.

> page 10 3rd para: s/tred/tried/

Fixed.

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