Subject: [Sip] Comments on draft-ietf-sip-outbound-04

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 3 Jul 2006 19:27:38 +0100

Herewith my comments on the above document.

Technical
---------

1)	Section 2.1. The word "connection" gets used at various points in the document, including the introduction. I'd appreciate a definition.

2)	I thought that we agreed at the last WG meeting that for TCP, keepalives were perfectly appropriate if they worked. I guess this is primarily a UAC issue rather than a proxy issue. TCP keepalives seem underdocumented, and in some places it seems that STUN is the only mechanism. Should there not be additional information on TCP keepalives at the end of section 3.1. The note in 3.4 seems entirely too negative, implying that the use is deprecated altogether. Section 4.4.1 is also implying that the UAC must only support STUN keepalives - where is the TCP equivalent section. Section 7 applies to all implementations, but ignores the support of TCP keepalives.

3)	Section 3.2:

   The registrar challenges this registration to authenticate Bob. When
   the registrar adds an entry for this contact under the AOR for Bob,
   the registrar also keeps track of the connection over which it
   received this registration.

I am not sure of the relevance of the first sentence. Yes it may happen here, but the way it is written implies that outbound only works if it occurs.

4)	Section 3.4 (last paragraph) indicates:

   Regardless if they are in the same administrative domain, this
   specification requires that Registrars and Edge proxies support the
   Path header mechanism in RFC 3327 [RFC3327].

I found the requirement for UAC sort of in subclause 4.2. I found no requirement for the edge proxy to support the Path header extension in section 5. I did find a clear statement for the registrar in section 6.1.  

5)	Section 4.1:

   The UA SHOULD include a "sip.instance" media feature tag as a UA
   characteristic [RFC3840] in requests and responses.  As described in
   [RFC3840], this media feature tag will be encoded in the Contact
   header field as the "+sip.instance" Contact header field parameter.
   The value of this parameter MUST be a URN [RFC2141].  One case where
   a UA may not want to include the URN in the sip.instance media
   feature tag is when it is making an anonymous request or some other
   privacy concern requires that the UA not reveal its identity.

As currently written this seems to be a "MUST" followed by an instance where the "MUST" doesn't apply, and this is not allowed in RFC 2119. However it appears that this was not the intention, and that some rewording is required.

6)	Section 4.2:

   The UAC MUST indicate that it supports the Path header [RFC3327]
   mechanism, by including the 'path' option-tag in a Supported header
   field value in its REGISTER requests.  Other than optionally
   examining the Path vector in the response, this is all that is
   required of the UAC to support Path.

Either the UAC supports the Path header extension, or not. I am not sure that adding the second sentence helps.

7)	Section 4.2.1: I did not understand this subclause at all. Can you explain what you are trying to communicate?

8)	Section 4.4.2:

   When a flow to a particular URI in the outbound-proxy-set fails, the
   UA needs to form a new flow to replace the old flow and replace any
   registrations that were previously sent over this flow.  Each new
   registration MUST have the same reg-id as the registration it
   replaces.  This is done in much the same way as forming a brand new
   flow as described in Section 4.2; however, if there is a failure in
   forming this flow, the UA needs to wait a certain amount of time
   before retrying to form a flow to this particular next hop.

is almost a dupulication of the requirement in 4.2:

   These ordinary registration requests MUST also add a distinct reg-id
   parameter to the Contact header field.  Each one of these
   registrations will form a new flow from the UA to the proxy.  The
   reg-id sequence does not have to be sequential but MUST be exactly
   the same reg-id sequence each time the device power cycles or reboots
   so that the reg-id values will collide with the previously used
   reg-id values.  This is so the proxy can realize that the older
   registrations are probably not useful.

Can we make clearer that one relates to choosing a new reg-id on an initial registration, and the other relates to reusing the previous reg-id on a reboot and that these are therefore two distinct cases.

9)	Section 4.4.2. Should the default times vary for TCP? 4.4 specifies different times between keepalives for TCP and UDP.

10)	Section 6.2: Under what circumstances does the SHOULD not apply? And if the SHOULD is not followed, what does the registrar do instead?

11)	Not sure that reference RFC 3968 and reference RFC 3969 qualify as normative references. They are only explanation to the IANA on how the text is added to the registry.

12)	GRUU currently defined as an informative reference. Given that it defines the instance id which is needed for this protocol, I would have thought it needed to be normative.

NITS
----

13)	Section 3.3. This text starts out by using the term "administrative domain" and then starts shortening it to just "the domain". Given that "domain" is such an overused word I suggest we use "administrative domain" in full throughout, or find a completely new term.

14)	Section 3.4, 2nd paragraph has a "SHOULD". This is a general introduction, and I am surprised that RFC 2119 terminology appears at all. Suggest requirement is moved to a later clause (unless it is already there).

15)	I counted three different ways of representing notes throughout the text. I like the style of indentation, with a clear first word saying note, which you have used as one of these options. Can we align the remainder of the instances where the word "note" appears with this.

16)	Section 4.2 should probably do with some substructuring with inclusion of some header level 3 titles. The contents of 4.2 and 4.2.1 seem unrelated.

17)	Section 4.2, 3rd paragraph:

   These ordinary registration requests MUST also add a distinct reg-id
   parameter to the Contact header field.  Each one of these
   registrations will form a new flow from the UA to the proxy.  The
   reg-id sequence does not have to be sequential but MUST be exactly
   the same reg-id sequence each time the device power cycles or reboots
   so that the reg-id values will collide with the previously used
   reg-id values.  This is so the proxy can realize that the older
   registrations are probably not useful.

Not sure "collide" is the right word. Perhaps "match the previously..."

18)	Text seems to alternate between using "UAC" and "UA" and "User Agent". Where the UA is a UAC, can we use the correct term?

19)	Where response codes are identified can we include them in full RFC 3261 format in all cases, e.g. correct the following:

         For example, if a proxy forwarded a request to 4 locations, and
         received 503, 407, 501, and 404 responses, it may choose to
         forward the 407 (Proxy Authentication Required) response.

20)	Appendix A is followed by a Section 15.

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: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 4 Jul 2006 23:15:52 +0100

Of the comments that I made, comment 12) does not apply. I misremembered the relationship between these two documents - it changed before IETF #65.

It also means if you want GRUU, you've got to get outbound finished.

regards

Keith

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: 03 July 2006 19:28
> To: [email-masked]
> Cc: Cullen Jennings; Rohan Mahy
> Subject: [Sip] Comments on draft-ietf-sip-outbound-04
> 
> 
<snipped> 

> 12)	GRUU currently defined as an informative reference. 
> Given that it defines the instance id which is needed for 
> this protocol, I would have thought it needed to be normative.
> 
<snipped>