Subject: [Sip] WGLC for draft-ietf-sip-subnot-etags-01

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 4 Sep 2007 11:27:32 +0200

(As WG chair)

This is to announce a Working Group Last Call for 

http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-01.txt

This is a two week last call. Please provide comments and review of this
document by Tuesday 18th September 2007. 

Ideally please try to identify for each comment 

-	the precise point in the text where the comment applies (copying
the text and quoting the section number may help here), 

-	the nature of the comment (NIT, minor technical, major
technical),

-	if possible a proposed solution to the comment.

Please send comments to the SIP WG list, and also to the editor listed
in the document.

Regards

Keith

_______________________________________________
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: [email-masked]
Date: Tue, 18 Sep 2007 11:06:11 -0400

From: "DRAGE, Keith \(Keith\)" <[email-masked]>

Comments on draft-ietf-sip-subnot-etags-01.

Overall, a very well-written document!

I have one technical issue (which is probably insoluble and can only
be documented) and a number of nits.

* Section 4 specifies that a resource is identified by one or more
URIs.  It seems to be implicit that one URI always identifies the same
resource.  Without that, it would be difficult to use ETags
effectively, since ETags are only unique for a single resource.

In the general case, the mapping from URIs to resources involves the
full complexity of SIP routing.  This means that without additional
information, the subscriber does not know that request-URI that it
uses always maps into the same resource URI, and so has no absolute
guarantee that the space of ETags it is working with does not change
over time.

One assumes that all SUBSCRIBEs within a subscription are routed to
the same destination URI because the refresh SUBSCRIBEs are sent using
the route-set and contact.  But a "resumed" subscription does not have
this protection.

It is not clear that there is any solution to these problems, and we
may only be able to document that the subscriber is responsible for
assuring that successive subscription requests are delivered to the
same resource.

* Section 3 contains the line:

   notification, and attaches includes it in a SIP-ETag header field of

The words "attaches includes" seem to be incorrect.  Perhaps only
"includes" was intended?

* In section 3, it is emphasized that ETags are only unique "for a
resource and event package".  Checking RFC 3265, "event-package"
explicitly excludes any parameters attached to the event package name
in the "Event" header.

* Section 3 and other sections contain examples of SUBSCRIBE requests
which receive a 202 response.  It may be worth mentioning that 200
responses are also possible (if the notifier can determine without
delay that the request is authorized).

* Section 5.2 contains the statement:

   Unlike the condition introduced for the SIP PUBLISH [1] method, these
   conditions do not apply to the SUBSCRIBE request itself, but to the
   resulting NOTIFY request.

This is not strictly true, as success of the Suppress-Notify-If-Match
condition causes the SUBSCRIBE to receive a 204 response.
  
* Section 5.3 states:

   When a subscriber receives a NOTIFY request that contains a SIP-ETag
   header field, it MUST store the entity-tag.

This seems to be an awkward description.  The subscriber only needs to
store the entity-tag if it wishes to avail itself of the subnot-etags
mechanism later.  I think it would be clearer to say something like:

   In order for a subscriber to use this mechanism, when it receives a
   NOTIFY request that contains a SIP-ETag header field, it must store
   the entity-tag for later use.

* Section 5.7 shows a subscription being terminated:

          Subscriber                               Notifier
          ----------                               --------

          (1) SUBSCRIBE       -------->
              Suppress-Notify-If-Match: ega23
              Expires: 0

But it seems to me that most subscribers will only terminate a
subscription when they are no longer interested in the state of the
resource, and so it would be more straightforward to use "*" to ensure
that they do not receive a NOTIFY that they are not interested in:

          (1) SUBSCRIBE       -------->
              Suppress-Notify-If-Match: *
              Expires: 0

* In sections 7.2 and 7.3, "it's" is used where "its" should be used.
(That is one of the irregularities of English -- "it's" is reserved as
the contraction of "it is".)

   This header field is allowed to appear in any request, but [its]
   behavior is only defined for the SUBSCRIBE request.

Dale

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 19 Sep 2007 15:47:32 +0200

(As WG chair)

This was a response to say that there had been no comments at all on
this WGLC - however Dale Worley successfully precluded me saying that
(thanks Dale).

Just to make sure, I would like to extend the WGLC by a week to
Wednesday September 26th just in case it is still sitting in your pile
of documents to read. Instructions for response as below.

Now I know that we had some comments from people that indicated that
they were pretty happy with previous versions. Just in case the document
is now so perfect that there are no WGLC comments to make, please send
the SIP WG chairs if you have read the document and believe this to be
the case!

Otherwise get out there and read it.

Regards

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Tuesday, September 04, 2007 10:28 AM
> To: [email-masked]
> Subject: [Sip] WGLC for draft-ietf-sip-subnot-etags-01
> 
> (As WG chair)
> 
> This is a two week last call. Please provide comments and 
> review of this document by Tuesday 18th September 2007. 
> 
> Please send comments to the SIP WG list, and also to the 
> editor listed in the document.
> 
> Regards
> 
> Keith
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Jerry Yin <[email-masked]>
Date: Wed, 19 Sep 2007 13:40:59 -0700 (PDT)

Hi Cullen and Rohan,
   
  In the draft, it requires the UA configure the next hop route header with "keep-stun", "keep-crlf", or "timed-keepalive" tags. This would cause some problems.
   
  1. As an example, the route-set contains this route header as indicated in section 9 example: 
  Route: <sip:pri.example.com;lr;keep-stun>
  If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or TLS, the keep-stun will be useless. Vice versa, if the pri.example.com is resolved as UDP, and if "keep-crlf" was manually configured, it is not working either.
   
  2. Before sending the REGISTER request, the admin/or user does not know what keep-alive mechanism the proxy (or edge proxy) supports. Blindly configure the keep-stun, or keep-crlf would cause the problem that the draft indicated itself in section 8: "the node could be blacklisted for UDP traffic".
  The better approach is to let the UA and the proxy to negotiate, not manually configure from UA side. 
  a. UA sends REGISTER to the proxy with a "outbound" tag in the Supported header.
  b. Proxy insert the "outbound" tag in the 200 OK, if the UA indicated that it supports the outbound.
  c. If the "outbound" tag is present in the 200 OK, and if the transport is UDP, using the STUN keep alive, other connection based transport using crlf keep alive.
  There would be no way to mass up by configurations with this approach. Let me know if I missed something.
   
  Regards,
  Jerry Yin

---------------------------------
Yahoo! oneSearch: Finally,  mobile search that gives answers, not web links.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Sep 2007 14:34:14 +0200

My efforts, independently of the WGLC, to find reviewers of this
document have met with insufficient support.

Are there a couple of people out there in the SIP community, who are
familiar with the requirements of RFC 3265, who are prepared to look at
this draft with a new pair of eyes (figuratively speaking), and
essentially pull the document apart from one end to the other.

Please send me a mail directly if you consider you can do this within a
reasonable short timescale (2 or 3 weeks).

Regards

Keith

> From: DRAGE, Keith (Keith) 
> Sent: Wednesday, September 19, 2007 2:48 PM
> To: [email-masked]
> Subject: RE: [Sip] WGLC for draft-ietf-sip-subnot-etags-01
> 
> (As WG chair)
> 
> This was a response to say that there had been no comments at 
> all on this WGLC - however Dale Worley successfully precluded 
> me saying that (thanks Dale).
> 
> Just to make sure, I would like to extend the WGLC by a week 
> to Wednesday September 26th just in case it is still sitting 
> in your pile of documents to read. Instructions for response as below.
> 
> Now I know that we had some comments from people that 
> indicated that they were pretty happy with previous versions. 
> Just in case the document is now so perfect that there are no 
> WGLC comments to make, please send the SIP WG chairs if you 
> have read the document and believe this to be the case!
> 
> > This is a two week last call. Please provide comments and review of 
> > this document by Tuesday 18th September 2007.
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> >

---

From: [email-masked]
Date: Thu, 20 Sep 2007 11:06:16 -0400

I agree with Jerry here, and believe this has come up before (?).  It is 
pointless for the originating UA to try to impose, or infer, the keepalive 
mechanism before it can know what is applicable. 

An additional comment along these lines. 
> a. UA sends REGISTER to the proxy with a "outbound" tag in the Supported 
header.
...
> c. If the "outbound" tag is present in the 200 OK, and if the transport 
is UDP, using the STUN keep alive, other connection based transport using 
crlf keep alive.

Step a) would really imply the originating UA MUST support both keepalive 
mechanisms, and c) implies it MUST begin using the appropriate one after 
200 OK.  The usage is implied, not explicit, which I believe is sufficient 
in this case.  Alternatively, the usage could be made more explicit by 
listing the supported k-a mechanisms in Supported exchange, or some such. 
This should be spelled out either way. 

-- Peter Blatherwick

Jerry Yin <[email-masked]>
19.09.07 16:40
 
        To:     [email-masked], [email-masked], [email-masked]
        cc: 
        Subject:        [Sip] Outbound-10 comments

Hi Cullen and Rohan,
 
In the draft, it requires the UA configure the next hop route header with 
"keep-stun", "keep-crlf", or "timed-keepalive" tags. This would cause some 
problems.
 
1. As an example, the route-set contains this route header as indicated in 
section 9 example: 
Route: <sip:pri.example.com;lr;keep-stun>
If the DNS NAPTR resolution for pri.example.com is TCP, SCTP or TLS, the 
keep-stun will be useless. Vice versa, if the pri.example.com is resolved 
as UDP, and if "keep-crlf" was manually configured, it is not working 
either.
 
2. Before sending the REGISTER request, the admin/or user does not know 
what keep-alive mechanism the proxy (or edge proxy) supports. Blindly 
configure the keep-stun, or keep-crlf would cause the problem that the 
draft indicated itself in section 8: "the node could be blacklisted for 
UDP traffic".
The better approach is to let the UA and the proxy to negotiate, not 
manually configure from UA side. 
a. UA sends REGISTER to the proxy with a "outbound" tag in the Supported 
header.
b. Proxy insert the "outbound" tag in the 200 OK, if the UA indicated that 
it supports the outbound.
c. If the "outbound" tag is present in the 200 OK, and if the transport is 
UDP, using the STUN keep alive, other connection based transport using 
crlf keep alive.
There would be no way to mass up by configurations with this approach. Let 
me know if I missed something.
 
Regards,
Jerry Yin
 
 Yahoo! oneSearch: Finally, mobile search that gives answers, not web 
links. _______________________________________________
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
_______________________________________________
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: [email-masked]
Date: Fri, 21 Sep 2007 01:22:59 +0300

Hi,

  I composed the email below a month ago related to this thread and  
thought that I was missing something so I did not posted it, but it  
seems that there are some issues pending with the keepalive label and  
processing.

  Sorry to introduce more questions:

--

  My comments are about the keep-stun label.

  It is not very clear how the UA discovers that the Edge Proxy supports STUN.

In section 8 (keepalive processing). I read

"   When a URI is created that refers to a SIP node that supports STUN as
    described in this section, the 'keep-stun' URI parameter, as defined
    in Section 12 MUST be added to the URI.  This allows a UA to inspect
    the URI to decide if it should attempt to send STUN requests to this
    location.  For example, an edge proxy could insert this parameter
    into its Path URI so that the registering UA can discover the edge
    proxy supports STUN keepalives."

Q1. Why "an edge proxy COULD insert this parameter into its Path URI"  
and not MUST ? (considering that the UA supports STUN)

Q2. In what other header can I also add the keep-stun, so that it will  
be still present when I get back a response?

Note that in the example of section 9 the responses 200-OK haven't any  
keep-stun

(Also mentioned in  
http://www1.ietf.org/mail-archive/web/sip/current/msg20295.html)

Q3. For the case in this example, How will the Callee know that it is  
allowed to send STUN keepalives? (no keep-stun present)

For the case in the example, and considering:

       "Typically, a SIP node first sends a SIP request and waits to
       receive a final response (other than a 408 response) over a flow
       to a new target destination, before sending any STUN messages."

The callee will never send the keepalives...

--
Part II

  In my opinion, the edge proxy MUST add a list of the supported  
mechanisms for keepalive in the 200-OK response to REGISTER. The list  
MUST include ALL the supported mechanisms (so the UA can for example  
know that if some mechanism is not available for the transport it used  
to register there are other mechanisms for other protocols. In this  
case the UA will form a new flow by registering using another protocol.)

Example 1:

UA sends REGISTER over UDP.
It gets back a 200 OK with only keep-crlf.
UA recognizes that STUN is not available, so a UDP flow can not  
succeed. Then it sends a REGISTER over TCP.

Example 2:

UA sends REGISTER over UDP.
It gets back a 200 OK with keep-crlf and keep-stun.
UA recognizes that keep-crlf is present so (its logic) can judge that  
TCP is a better choice.
Then the UA forgets using UDP and switches to TCP: sends a REGISTER over TCP.

Q: Should not be handy to have something like keep-Scrlf so the UA can  
knows that TLS is also supported? The same for DTLS.

Sergio

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 21 Sep 2007 10:56:30 +0200

I now have some volunteers to do reviews:

Avshalom Houri
Tolga Asveren
Brian Stucker

Thanks in aniticipation.

While we don't need additional formal reviews, this does not preclude
comments under the WGLC, so if you think there is a problem in the text
there somewhere, please get your comments on the list.

Regards

Keith 

> Sent: Thursday, September 20, 2007 1:34 PM
> To: [email-masked]'
> My efforts, independently of the WGLC, to find reviewers of 
> this document have met with insufficient support.
> 
> Are there a couple of people out there in the SIP community, 
> who are familiar with the requirements of RFC 3265, who are 
> prepared to look at this draft with a new pair of eyes 
> (figuratively speaking), and essentially pull the document 
> apart from one end to the other.
> 
> Please send me a mail directly if you consider you can do 
> this within a reasonable short timescale (2 or 3 weeks).
> 
> Regards
> 
> Keith
> 
> indicated that 
> > they were pretty happy with previous versions.
> > Just in case the document is now so perfect that there are no WGLC 
> > comments to make, please send the SIP WG chairs if you have 
> read the 
> > document and believe this to be the case!
> > 
> review of

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 21 Sep 2007 12:07:58 -0400

Yeah, seems like the best way forward.  Glad to see we have a real plan.

Brian

> Sent: Wednesday, September 19, 2007 9:48 AM
> To: [email-masked]