Subject: [Sip] Comments on draft-koivusalo-sip-outbound-discovery-02

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 3 Jul 2006 20:12:11 +0100

Technical:
----------

1) I need to understand whether this updates RFC 3263 or just extends it. Part of this is what appears on the cover page and in the RFC index as and when it is finally approved, but the other part also relates to compatibility, see later comment.

2) I think you have already acknowledged this, but the document requires revision to align with the terminology in the latest version (-04) of draft-ietf-sip-outbound.

3) In section 5, as far as I understand, the NAPTR request is identical for a UA that supports RFC 3263 and for one that supports this extension. Therefore the difference is in the response. Therefore the paragraph of UA requirements:

   As per RFC 2915 [4], the client discards any NAPTR records whose
   services fields are not applicable.  A client resolving a SIPS URI
   MUST discard any services that do not contain "SIPS-O" as the
   protocol in the service field.  A client resolving a SIP URI MUST
   retain records with "SIP-O" and the transport protocols the client
   supports and SHOULD retain records with "SIPS-O", if the client
   supports TLS.

must work with a NAPTR response that has no knowledge of outbound. Is the above paragraph compatible with this? 

Additionally note that the words "if the client supports TLS" are superfluous. As RFC 3261 requires support of TLS, we are not documenting capabilities where TLS is not supported.

regards

Keith

Keith Drage
[email-masked]
tel: +44 1793 776249

_______________________________________________
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: Miguel Garcia <[email-masked]>
Date: Tue, 04 Jul 2006 09:39:17 +0300

Hi Keith, Erkki:

To answer your first question, I believe this draft updates RFC 3263.

And with respect your third question, I agree that the draft does not 
consider the case when Outbound is not deployed, so the text has to be 
updated to reflect the case.

I have also a couple of other non-nit comments.

1) I think the draft has to be a bit more strict on where this draft 
ends and when Outbound begins. At the moment I found this line quite 
fuzzy. Assuming this draft is about discovery, but not execution of the 
outbound procedures, I believe requirement REQ-OUTB-DISC-6 has not much 
to do with discovery, but with outbound. The same applies to several 
paragraphs in Section 5, when the draft describes actions taken upon a 
reception of a 200 response  for a REGISTER request.

2) The first paragraph in Section 2.4.4 suggests that a non-standardized 
autodiscovery mechanism will require the UA to insert a "Proxy-Require: 
outbound". Care must be taken to avoid that this becomes the de-facto 
behavior. It must noted that such Proxy-Require will require each of the 
proxies en route to the registrar to support outbound, which might not 
be the desired behavior. I would suggest to add some more text 
describing this case and highlighting the problem.

3) IANA: something is not clear to me. Is this draft creating a new 
registry (as it suggest Sections 4 and 7), named "Registry for the NAPTR 
Resource Record Services Fiedl", or is it updating the existing registry 
at http://www.iana.org/assignments/sip-table

I thought it would be the latter, but the fact that the existing 
registry refers to SRV records rather than NAPTR makes me doubt. Can 
someone clarify?

BR,

      Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: <[email-masked]>
Date: Thu, 6 Jul 2006 13:03:08 +0300

Hi,

>> 1) I need to understand whether this updates RFC 3263 or 
>just extends it. Part of this is what appears on the cover 
>page and in the RFC index as and when it is finally approved, 
>but the other part also relates to compatibility, see later comment.

>To answer your first question, I believe this draft updates RFC 3263.

Yesterday we discussed this question with Miguel and our
conclusion was that we are not sure if it extends or updates.
Depends on what these words actually mean. Can someone help
by providing definitions or examples of those ?

My opinion is that my draft only extends RFC 3263, so the
wording in the draft would have to be revised accordingly.
Reasoning behind my opinion is this:

- My draft at least does not make RFC 3263 obsolete.
  RFC 3263 would still be used when the UA tries to
  connect "legacy" SIP proxies without outbound support.

- The procedures in my draft suggest a different way
  for the UA to handle the DNS NAPTR and SRV responses
  like RFC 3263 does. However the UA uses these different
  procedures only when it specifically tries to find and
  contact 1-N proxies supporting outbound, instead of
  resolving SIP URIs for any other purpose.

- My draft is not independent of RFC 3263, it just highlights
  how the processing differs from what is described in 3263 
  but does not repeat those procedures of the RFC that still 
  apply.

>> 2) I think you have already acknowledged this, but the 
>document requires revision to align with the terminology in 
>the latest version (-04) of draft-ietf-sip-outbound.

I already tried to align the terminology, so please be
more specific on what kind of alignment is needed. If 
you simply mean usage of word "backup" in certain context,
that will be removed if the corresponding use case and
requirement REQ-PROXY-FARM-03 will be dropped (like I
suggested in another thread). On the other hand it might
still be that my draft would continue promoting the way
of the domain have a pool of idle backup servers. However
it would probably require the outbound draft itself to
be updated like Adam suggested today:
---
>In internal discussions, we came up with realistic scenarios 
>whereby a client may reasonably end up maintaining two 
>connections with very different characteristics (UDP versus 
>TLS would be an extreme example), and be willing to use both 
>of them, but *strongly* prefer one over the other.
>
>To handle this situation, it might make sense to put stuff in 
>6.2 that basically says that, for contacts with matching 
>instance-ids, the proxy MUST NOT try a contact until all 
>contacts at a higher q-value have been tried first.
---

>> 3) In section 5, as far as I understand, the NAPTR request 
>is identical for a UA that supports RFC 3263 and for one that 
>supports this extension. Therefore the difference is in the 
>response. 

Correct. What the draft currently says is this:

   The procedures here are invoked when a UA needs to send a REGISTER
   request via a proxy supporting SIP Outbound and set up a persistent
   flow towards that proxy.  The starting point is that the UA has a SIP
   or SIPS (secure SIP) URI of the proxy without port, transport or
   maddr parameters as the next hop.  According to RFC 3263 [2] the UA
   "SHOULD perform a NAPTR query for the domain in the URI."  This
   specification assumes the UA would proceed to perform the NAPTR query
   and related SRV queries as specified in RFC 3263, but with the
   exceptions defined below.

I would like to revise it slightly as follows:

   specification assumes the UA would proceed to perform the NAPTR query
   and related SRV queries as specified in RFC 3263, but processing the
   DNS NAPTR responses using the extensions as defined below.

>> Therefore the paragraph of UA requirements:
>> 
>> must work with a NAPTR response that has no knowledge of 
>outbound. Is the above paragraph compatible with this? 

>updated to reflect the case.

Right now in the draft there is later a paragraph descriging a 
fallback to use RFC 3263 procedures if the SIP-O records are 
not defined for the domain:

   When performing NAPTR queries as specified in this document, if the
   UA is not able to resolve the URI of the proxy successfully to any IP
   address or if connecting to each of the resolved addresses fails,
   then the UA MAY try resolving the URI using the procedures defined in
   RFC 3263 [2].  When doing this fallback UA MUST NOT assume the
   resolved target host to support SIP Outbound.

What I have to do is to integrate this paragraph describing the fallback
behaviour with the paragraph you highlighted. I hope that would make
the story consistent and easily understandable. Also changing the MAY 
to SHOULD or MUST is probably needed ?

>fuzzy. Assuming this draft is about discovery, but not 
>execution of the outbound procedures, I believe requirement 
>REQ-OUTB-DISC-6 has not much to do with discovery, but with outbound. 

I and Miguel did not reach an agreement about this, so Miguel
started a thread on a mailing list for the number of flows the
UA is expected to create. The resolution for my draft depends on
what happens to outbound draft. In my opinion it would still be
in the scope of the autodiscovery draft to define how many flows
the UA should set up if it discovers N proxies in the domain to
support outbound (and thus be able to derive outbound-proxy-set 
consisting of N proxies). N flows might not always be the optimal
answer.

>The same applies to several 
>paragraphs in Section 5, when the draft describes actions 
>taken upon a reception of a 200 response  for a REGISTER request.

I admit that some of the stuff from my draft would apparently
belong in the scope of the outbound draft and could eventually
be removed from the autodiscovery draft. More specifically all
normative text about how the UA uses the flows (and perhaps
assigns the q values for the related Contacts) could belong
to this category. What I am not sure is whether those pieces
of text (autodiscovery of flows and the usage of those flows) 
could be separated to two different drafts so that the story 
would still be understandable and the reader to be able to
map these pieces together. This needs further study and also
cooperation with authors of outbound.

>2) The first paragraph in Section 2.4.4 suggests that a 
>non-standardized autodiscovery mechanism will require the 
>UA to insert a "Proxy-Require: outbound". Care must be 
> taken to avoid that this becomes the de-facto 
>behavior. It must noted that such Proxy-Require will require 
>each of the proxies en route to the registrar to support 
>outbound, which might not be the desired behavior. I would 
>suggest to add some more text describing this case and 
>highlighting the problem.

I agree with Miguel that this problem must be added to
make sure that such a solution would not be used. However
the exact formulation depends on if outbound draft will
be revised for Proxy-Require usage or not. This is currently
under discussion.

>registry refers to SRV records rather than NAPTR makes me doubt. Can 

We agreed that my draft would update the existing registry.
Unfortunately the current register seems to incorrectly
refer to SRV RRs even if it is for NAPTR RRs. Miguel tries
to get the IANA registry fixed.

Regards,

Erkki