Subject: [sipcore] comments on draft-ietf-sipcore-rfc3265bis-08.txt

From: "Nataraju A.B" <[email-masked]>
Date: Mon, 23 Apr 2012 10:28:37 +0530

All,

Some logical comments on the draft-ietf-sipcore-rfc3265bis-08.txt.

-----------------------------------------------------
5.3.2.  State Deltas

CurrentText:

   If a NOTIFY request arrives that has a version number that is
   incremented by more than one, the subscriber knows that a state delta
   has been missed; it ignores the NOTIFY request containing the state
   delta (except for the version number, which it retains to detect
   message loss), and re-sends a SUBSCRIBE request to force a NOTIFY
   request containing a complete state snapshot.

Comment:
   From this text, it infers that if any state delta lost, then subscriber
   sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE
request inturn lead
   to fetching the complete state information.

   It may be a good diea to differentiate the re-SUBSCRIBE triggered by
different scenarios.
   a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE duration.
In this
      case it is not necessary to fetch the complete state information
   b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2.
      VERSION number in received NOTIFY is increased by greater than ONE).
      In this case subscriber wants to fetch the complete state information.

   If we don't differentiate these two cases, then natural re-SUBSCRIBE
request
   unnecessarily fetch the complete state information, which may not be
necessary / expected.
   But uses higher network bandwidth to fetch the complete state
information.
-----------------------------------------------------
-----------------------------------------------------
4.4.1.  Dialog Creation and Termination

CurrentText:

      A subscriber may send a SUBSCRIBE request with an "Expires" header
      field of 0 in order to trigger the sending of such a NOTIFY
      request; however, for the purposes of subscription and dialog
      lifetime, the subscription is not considered terminated until the
      NOTIFY transaction with a "Subscription-State" of "terminated"
      completes.

Comment:
We may have to mention how long the dialog must be kept alive, before
being cleaned up. Should we delete the dialog immediately after 200-SUB
 or wait till NOTIFY with "Subscription-State"="terminated". If we always
wait till Last Notify for dialog termination, then 200-SUB don't have any
 impact on the dialog termination. Atleast some normative text is of
necessity, for better understanding of the topic.
-----------------------------------------------------
-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:

   SUBSCRIBE requests SHOULD contain an "Expires" header field (defined
   in [RFC3261]).  This expires value indicates the duration of the
   subscription.  In order to keep subscriptions effective beyond the
   duration communicated in the "Expires" header field, subscribers need
   to refresh subscriptions on a periodic basis using a new SUBSCRIBE
   request on the same dialog as defined in [RFC3261].

Comment:
We can add a normative text saying, the refresh time will be
 normally 50% to 75% of subscription duration.

-----------------------------------------------------
-----------------------------------------------------
4.1.2.1.  Requesting a Subscription

CurrentText:
   [RFC3261].  For the sake of clarity: if a SUBSCRIBE request contains
   an "Accept" header field, but that field does not indicate a media
   type that the notifier is capable of generating in its NOTIFY
   requests, then the proper error response is 406 (Not Acceptable).

COMMENT:
It is better to mention it as a normative text (indented).

-----------------------------------------------------
-----------------------------------------------------
4.1.2.  Creating and Maintaining Subscriptions

CurrentText:

   From the subscriber's perspective, a subscription proceeds according
   to the following state diagram:

Comment:
Here it is better to mention, what happens to FSM when 200-SUBSCRIBE
 received in notify_wait state (because very often this is possible).
If no change in state of FSM, then some normative text shall convey the
same.
        It may be no-operation, but better to mention the same.
-----------------------------------------------------
-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:
      In addition to being a request to unsubscribe, a SUBSCRIBE request
      with "Expires" of 0 also causes a fetch of state; see
      Section 4.4.3.

Comment:
     The above text has been mentioned to be normative text. But I feel
this
     shall be written as a regualr text in the draft/rfc. because this is
the
     expected behavior from the notifier.
-----------------------------------------------------
-----------------------------------------------------
3.2.1.

CurrentText:
   This body will contain either the state of the subscribed resource or
   a pointer to such state in the form of a URI (see Section 5.4.13).

ReplacementText/Comment:
   This body **SHALL** contain either the state of the subscribed resource
or
   a pointer to such state in the form of a **URL** (see Section 5.4.13).
-----------------------------------------------------
-----------------------------------------------------
4.2.1.  Subscription Establishment and Maintenance

CurrentText:
      inability to signal the success of a REFER request while signaling
      a problem with the subscription; and difficulty performing one
      action without the other.  Additionally, the proper exchange of

ReplacementText:
      inability to signal the success of a REFER request while signaling
      a problem with the subscription; and difficulty **in** performing one
      action without the other.  Additionally, the proper exchange of

-----------------------------------------------------

Thanks,
Nataraju A B

---------- Forwarded message ----------
From: Nataraju A.B <[email-masked]>
Date: Fri, Apr 13, 2012 at 10:53 PM
Subject: draft-ietf-sipcore-rfc3265bis-08.txt - Review comments (Nataraju A
B)
To: Adam Roach <[email-masked]>, [email-masked]

Adam,

Please find some editorial comments on the draft
"draft draft-ietf-sipcore-rfc3265bis-08.txt"

For simplicity, I have mentioned both the current text and proposed text.

The comments / corrective text can be found with prefix and suffix  --- **

-----------------------------------------------------
1.1.  Overview of Operation
CurrentText:
   The general concept is that entities in the network can subscribe to
   resource or call state for various resources or calls in the network,
   and those entities (or entities acting on their behalf) can send
   notifications when those states change.

ReplacementText:
   The general concept is that entities in the network can subscribe to
   resource or call state **at / of** various resources or calls in the
network,
   and those entities (or entities acting on their behalf) **who** can send
   notifications when those states change.
-----------------------------------------------------

1.1.  Overview of Operation

CurrentText:
   Subscriptions are expired and must be refreshed by subsequent
   SUBSCRIBE requests.

ReplacementText:
   Subscriptions are expired and must be refreshed by subsequent
   SUBSCRIBE requests **before expiration**.
-----------------------------------------------------

2.  Definitions

CurrentText:
   Subscriber:  A subscriber is a user agent which receives NOTIFY
      requests from notifiers; these NOTIFY requests contain information
      about the state of a resource in which the subscriber is
      interested.  Subscribers typically also generate SUBSCRIBE
      requests and send them to notifiers to create subscriptions.

Comment:
After this information, we can add a normative text which indicates
 when a SIP entity might get NOTIFY messages without actually
 sending SUBSCRIBE request. For example, REFER request might end up with
implicit subscription. Also mention any other requests which may lead to
 implicit subscriptions (other than REFER).
-----------------------------------------------------
2.  Definitions

CurrentText:
   Subscription:  A subscription is a set of application state
      associated with a dialog.  This application state includes a
      pointer to the associated dialog, the event package name, and
      possibly an identification token.  Event packages will define
      additional subscription state information.  By definition,
      subscriptions exist in both a subscriber and a notifier.

ReplacementText:
   Subscription:  A subscription is a set of application **states**
      associated with a dialog.  **The** application state includes a
      pointer to the associated dialog, the event package name, and
      possibly an identification token.  Event packages will define
      additional subscription state information.  By definition,
      subscriptions exist in both a subscriber and a notifier.
-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:

   subscription.  In order to keep subscriptions effective beyond the
   duration communicated in the "Expires" header field, subscribers need
   to refresh subscriptions on a periodic basis using a new SUBSCRIBE
   request on the same dialog as defined in [RFC3261].

ReplacementText
3.1.1.  Subscription Duration

   subscription.  In order to keep subscriptions effective beyond the
   duration communicated in the "Expires" header field, subscribers need
   to refresh subscriptions **before expiration** on a periodic basis using
a new SUBSCRIBE
   request on the same dialog as defined in [RFC3261].
-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:
      In addition to being a request to unsubscribe, a SUBSCRIBE request
      with "Expires" of 0 also causes a fetch of state; see
      Section 4.4.3.

Comment:
     The above text has been mentioned to be normative text. But I feel
this
     shall be written as a regualr text in the draft/rfc. because this is
the
     expected behavior from the notifier.
-----------------------------------------------------
3.1.2.  Identification of Subscribed Events and Event Classes

CurrentText:
   Subscribers MUST include exactly one "Event" header field in
   SUBSCRIBE requests, indicating to which event or class of events they
   are subscribing.  The "Event" header field will contain a token which
   indicates the type of state for which a subscription is being
   requested.  This token will be registered with the IANA and will
   correspond to an event package which further describes the semantics
   of the event or event class.

ReplacementText:
   Subscribers MUST include exactly one "Event" header field in
   SUBSCRIBE requests, indicating to which event or class of events they
   are subscribing.  The "Event" header field **MUST** contain a token which
   indicates the type of state for which a subscription is being
   requested.  This token will be registered with the IANA and will
   correspond to an event package which further describes the semantics
   of the event or event class.
-----------------------------------------------------
3.1.  SUBSCRIBE

CurrentText:
   The SUBSCRIBE method is used to request current state and state
   updates from a remote node.  SUBSCRIBE requests are target refresh

ReplacementText:
   The SUBSCRIBE method is used to request current state and **subsequent**
state
   updates from a remote node.  SUBSCRIBE requests are target refresh

-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:

   SUBSCRIBE requests SHOULD contain an "Expires" header field (defined
   in [RFC3261]).  This expires value indicates the duration of the
   subscription.  In order to keep subscriptions effective beyond the
   duration communicated in the "Expires" header field, subscribers need
   to refresh subscriptions on a periodic basis using a new SUBSCRIBE
   request on the same dialog as defined in [RFC3261].

Comment:
We can add a normative text saying, the refresh time will be
 normally 50% to 75% of subscription duration.

-----------------------------------------------------
3.2.1.

CurrentText:
   This body will contain either the state of the subscribed resource or
   a pointer to such state in the form of a URI (see Section 5.4.13).

ReplacementText/Comment:
   This body **SHALL** contain either the state of the subscribed resource
or
   a pointer to such state in the form of a **URL** (see Section 5.4.13).
-----------------------------------------------------
4.1.2.  Creating and Maintaining Subscriptions

CurrentText:

   From the subscriber's perspective, a subscription proceeds according
   to the following state diagram:

Comment:
Here it is better to mention, what happens to FSM when 200-SUBSCRIBE
 received in notify_wait state (because very often this is possible).
 If no change in state of FSM, then some normative text shall convey the
same.
        It may be no-operation, but better to mention the same.
-----------------------------------------------------
4.1.2.1.  Requesting a Subscription

CurrentText:
   When a subscriber wishes to subscribe to a particular state for a
   resource, it forms a SUBSCRIBE request.  If the initial SUBSCRIBE

ReplacementText:
   When a subscriber wishes to subscribe to a particular state **of** a
   resource, it forms a SUBSCRIBE request **according to sec 3.1 and send
it across to notifier**.  If the initial SUBSCRIBE

-----------------------------------------------------
4.1.2.1.  Requesting a Subscription

CurrentText:
   [RFC3261].  For the sake of clarity: if a SUBSCRIBE request contains
   an "Accept" header field, but that field does not indicate a media
   type that the notifier is capable of generating in its NOTIFY
   requests, then the proper error response is 406 (Not Acceptable).

COMMENT:
It is better to mention it as a normative text (indented).

-----------------------------------------------------
4.1.3.  Receiving and Processing State Information

CurrentText:

   If the "Subscription-State" value is "terminated", the subscriber
   MUST consider the subscription terminated.  The "expires" parameter
   has no semantics for "terminated" -- notifiers SHOULD NOT include an

ReplacementText:

   If the "Subscription-State" value is "terminated", the subscriber
   MUST consider the subscription terminated.  The "expires" parameter
   has no semantics for "terminated" **state**. Notifiers SHOULD NOT
include an
-----------------------------------------------------

CurrentText:
   deactivated:  The subscription has been terminated, but the
      subscriber SHOULD retry immediately with a new subscription.  One

ReplacementText:
   deactivated:  The subscription has been terminated, but the
      subscriber SHOULD retry with a new subscription.  One

   Is It mandatory to resubscribe immediately. if not remove the word
"immediately".
   If it is delayed, what are the consequences ????

-----------------------------------------------------
4.2.1.  Subscription Establishment and Maintenance

CurrentText:
      inability to signal the success of a REFER request while signaling
      a problem with the subscription; and difficulty performing one
      action without the other.  Additionally, the proper exchange of

ReplacementText:
      inability to signal the success of a REFER request while signaling
      a problem with the subscription; and difficulty **in** performing one
      action without the other.  Additionally, the proper exchange of

-----------------------------------------------------
4.2.1.4.  Refreshing of Subscriptions

CurrentText:
   If no refresh for a notification address is received before its
   expiration time, the subscription is removed.  When removing a

ReplacementText:
   If no refresh for a notification is received before its
   expiration time, the subscription is removed.  When removing a
 Comment: Word "address" needs to be removed.
-----------------------------------------------------
4.3.  Proxy Behavior

CurrentText:
   Proxies that did not add a Record-Route header field to the initial
   SUBSCRIBE request MUST NOT add a Record-Route header field to any of
   the associated NOTIFY requests.

ReplacementText:
   Proxies that did not add a Record-Route header field to the initial
   SUBSCRIBE request MUST NOT add a Record-Route header field to any of
   the associated NOTIFY requests **or any SUBSCRIBE refresh requests**.
-----------------------------------------------------
4.4.1.  Dialog Creation and Termination

CurrentText:

      A subscriber may send a SUBSCRIBE request with an "Expires" header
      field of 0 in order to trigger the sending of such a NOTIFY
      request; however, for the purposes of subscription and dialog
      lifetime, the subscription is not considered terminated until the
      NOTIFY transaction with a "Subscription-State" of "terminated"
      completes.

Comment:
We may have to mention how long the dialog must be kept alive, before
 being cleaned up. Do we delete the dialog immediately after 200-SUB
or wait till NOTIFY with "Subscription-State"="terminated". If we always
 wait till Last Notify for dialog termination, then 200-SUB don't have any
impact on the dialog termination. Atleast some normative text is of
 necessity, for better understanding of the topic.
-----------------------------------------------------
4.4.3.  Polling Resource State

CurrentText:

   Note that the NOTIFY requests triggered by SUBSCRIBE requests with
   "Expires" header fields of 0 will contain a "Subscription-State"
   value of "terminated", and a "reason" parameter of "timeout".

ReplacementText:
   Note that the NOTIFY requests triggered by SUBSCRIBE requests with
   "Expires" header fields of 0 **shall** contain a "Subscription-State"
   value of "terminated", and a "reason" parameter of "timeout".
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:
      for a dialog (e.g., route set handling).  In particular, multiple
      subscriptions within a dialog are expire independently, and
      require independent subscription refreshes.

ReplacementText:
      for a dialog (e.g., route set handling).  In particular, multiple
      subscriptions within a dialog **operates** independently, and
      require independent subscription refreshes.
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:
   o  Subscribers MAY include an "id" parameter in SUBSCRIBE request
      "Event" header field to allow differentiation between multiple

ReplacementText:
   o  Subscribers MAY include an "id" parameter in SUBSCRIBE **request's**
      "Event" header field to allow differentiation between multiple
OR
   o  Subscribers MAY include an "id" parameter in **"Event" header field
      of SUBSCRIBE request** to allow differentiation between multiple
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:
   o  When a subscriber refreshes a the subscription timer, the
      SUBSCRIBE request MUST contain the same "Event" header field "id"
      parameter as was present in the SUBSCRIBE request that created the
      subscription.  (Otherwise, the notifier will interpret the

ReplacementText:
   o  When a subscriber refreshes a the subscription timer, the
      SUBSCRIBE request MUST contain the same **"id" parameter in "Event"
      header field, which** was present in the SUBSCRIBE request that
created the
      subscription.  (Otherwise, the notifier will interpret the
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:

   o  When a subscription is created in the notifier, it stores any
      "Event" header field "id" parameter as part of the subscription
      information (along with the event package name).

ReplacementText:
   o  When a subscription is created in the notifier, it stores **the**
      **"id" parameter in "Event" header field** as part of the subscription
      information (along with the event package name).
-----------------------------------------------------
4.6.  CANCEL Requests for SUBSCRIBE and NOTIFY Transactions

CurrentText:

   Neither SUBSCRIBE nor NOTIFY requests can be canceled.  If a UAS
   receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY
   transaction, it MUST respond to the CANCEL request, but otherwise
   ignore it.  In particular, the CANCEL request MUST NOT affect
   processing of the SUBSCRIBE or NOTIFY request in any way.

ReplacementText/Comment:
What should be the response code for the CANCEL's reply ???
 Preferably 200-OK shall be used.
-----------------------------------------------------
4.6.  CANCEL Requests for SUBSCRIBE and NOTIFY Transactions

CurrentText:

   UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY
   transactions.

ReplacementText:
   UACs **MUST** NOT send CANCEL requests for SUBSCRIBE or NOTIFY
   transactions. **UASs SHOULD send 200OK for CANCEL within NOTIFY
   or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]**
-----------------------------------------------------
5.3.2.  State Deltas

CurrentText:

   In the case that the state information to be conveyed is large, the
   event package may choose to detail a scheme by which NOTIFY requests
   contain state deltas instead of complete state.

ReplacementText:
   In the case that the state information to be conveyed is large, the
   event package may choose a scheme by which NOTIFY requests
   contain state deltas instead of complete state.

comment: deleted words "to detail" in 2nd line.

-----------------------------------------------------
5.3.2.  State Deltas

CurrentText:

   If a NOTIFY request arrives that has a version number that is
   incremented by more than one, the subscriber knows that a state delta
   has been missed; it ignores the NOTIFY request containing the state
   delta (except for the version number, which it retains to detect
   message loss), and re-sends a SUBSCRIBE request to force a NOTIFY
   request containing a complete state snapshot.

Comment:
   From this text, it infers that if any state delta lost, then subscriber
   sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE
request inturn lead
   to fetching the complete state information.

   It may be a good diea to differentiate the re-SUBSCRIBE triggered by
different scenarios.
   a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE duration.
In this
      case it is *not *necessary to fetch the complete state information
   b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2.
      VERSION number in received NOTIFY is increased by greater than ONE).
      In this case subscriber wants to fetch the complete state information.

   If we don't differentiate these two cases, then natural re-SUBSCRIBE
request
   unnecessarily fetch the complete state information, which may not be
necessary / expected.
   But uses higher network bandwidth to fetch the complete state
information.
-----------------------------------------------------
5.4.7.  Notifier generation of NOTIFY requests

CurrentText:
   This section may optionally describe the behavior used to process the
   subsequent response.

Comment:
   In this section 5.4.7, the above statement is not clear, what is really
meant to be.

-----------------------------------------------------
5.4.13.  Use of URIs to Retrieve State

CurrentText:

ReplacementText:
   In this context, I feel Use of "URLs" is more appropriate than "URIs".
-----------------------------------------------------

Thanks,
Nataraju A.B.
E-ID : [email-masked] / [email-masked]
 +91-98455-95744

-- 
Thanks,
Nataraju A.B.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Apr 2012 10:02:20 -0400

Nataraju,

Your comments would have been much more helpful if received some months 
ago when the document went through WGLC. This document is now *very* far 
down the process to publication, having already gone through IESG last 
call, IANA review, etc. and is now in final IESG Evaluation. Changes at 
this point are very disruptive.

If you feel your suggestions are essential then you will have to go to 
extremes to pull this document back. I don't see anything below that 
convinces me to do that. AFAICT the comments below are all minor 
editorial except for the first, which suggests changing the mechanism.

	Thanks,
	Paul (as co-chair)

On 4/23/12 12:58 AM, Nataraju A.B wrote:
>     a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE
> duration. In this
>       shall be written as a regualr text in the draft/rfc. because this
> is the
>     This body **SHALL** contain either the state of the subscribed
> resource or
> From: *Nataraju A.B* <[email-masked]
> <mailto:[email-masked]>>
> Subject: draft-ietf-sipcore-rfc3265bis-08.txt - Review comments
> (Nataraju A B)
> To: Adam Roach <[email-masked] <mailto:[email-masked]>>,
> [email-masked] <mailto:[email-masked]>
>
>
> Adam,
>
>     to refresh subscriptions **before expiration** on a periodic basis
> using a new SUBSCRIBE
>       shall be written as a regualr text in the draft/rfc. because this
> is the
>     The SUBSCRIBE method is used to request current state and
> **subsequent** state
>     This body **SHALL** contain either the state of the subscribed
> resource or
>     resource, it forms a SUBSCRIBE request **according to sec 3.1 and
> send it across to notifier**.  If the initial SUBSCRIBE
>
> Comment:Word "address" needs to be removed.
> comment:deleted words "to detail" in 2nd line.
>
>     a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE
> duration. In this
>     In this section 5.4.7, the above statement is not clear, what is
> really meant to be.
>
> E-ID : [email-masked] <mailto:[email-masked]> /
> [email-masked] <mailto:[email-masked]>
> +91-98455-95744
>
>
>
> --
> Thanks,
> Nataraju A.B.
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Nataraju A.B" <[email-masked]>
Date: Mon, 23 Apr 2012 22:02:24 +0530

Paul,

I understand, I was late into the party... :(

The comment is more of an OPTIMIZATION issue. As a minimal change, can we
add a normative text which provide some pointers for implementers to
differentiate the re-SUBSCRIBE (to extend the subscription duration)
and re-SUBSCRIBE (to fetch the complete state, due to lost NOTIFY).

This might be of great concern for lossy networks (for example, wireless
networks, ...), where all the subsequent refresh SUBSCRIBE requests would
un-necessarily eats up more bandwidth for fetching the complete state which
is not necessary. For non-lossy network this is of minor issue...

Even if we decide to handle this optimization issue, we have to analyze
thoroughly how to differentiate differentiate these requests, through some
new header / header parameter / any other way. Need more analysis...

You can take a call, based on the feasibility. Even if dropped it is
fine....

Thanks,
Nataraju A B

On Mon, Apr 23, 2012 at 7:32 PM, Paul Kyzivat <[email-masked]> wrote:

> convinces me to do that. AFAICT the comments below are all minor editorial
> except for the first, which suggests changing the mechanism.
>
>        Thanks,
>        Paul (as co-chair)
>
>
>> Some logical comments on the draft-ietf-sipcore-rfc3265bis-**08.txt.
>>
>> ------------------------------**-----------------------
>> 5.3.2.  State Deltas
>>
>> CurrentText:
>>
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> or wait till NOTIFY with "Subscription-State"="**terminated". If we
>> always
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> 3.2.1.
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>>
>> Thanks,
>> Nataraju A B
>>
>> <mailto:[email-masked]**>>
>> Subject: draft-ietf-sipcore-rfc3265bis-**08.txt - Review comments
>> (Nataraju A B)
>> "draft draft-ietf-sipcore-rfc3265bis-**08.txt"
>>
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>>
>> ------------------------------**-----------------------
>>
>> 2.  Definitions
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> 2.  Definitions
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> 3.1.  SUBSCRIBE
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> 3.2.1.
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> 4.3.  Proxy Behavior
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> or wait till NOTIFY with "Subscription-State"="**terminated". If we
>> always
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> 4.5.2.  Sharing Dialogs
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> 4.5.2.  Sharing Dialogs
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> 4.5.2.  Sharing Dialogs
>>
>> CurrentText:
>> ------------------------------**-----------------------
>> 4.5.2.  Sharing Dialogs
>>
>> CurrentText:
>>
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> 5.3.2.  State Deltas
>>
>> CurrentText:
>>
>> ------------------------------**-----------------------
>> 5.3.2.  State Deltas
>>
>> CurrentText:
>>
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>> ------------------------------**-----------------------
>>
>>
>> Thanks,
>> Nataraju A.B.
>> [email-masked] <mailto:[email-masked]**>
>>
>> +91-98455-95744
>>
>>
>>
>> --
>> Thanks,
>> Nataraju A.B.
>>
>>
>>
>> ______________________________**_________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>>
>
> ______________________________**_________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sipcore<https://www.ietf.org/mailman/listinfo/sipcore>
>

-- 
Thanks,
Nataraju A.B.

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Apr 2012 14:23:42 -0500

On 4/23/12 11:32 AM, Nataraju A.B wrote:
>
> The comment is more of an OPTIMIZATION issue. As a minimal 
> change, can we add a normative text which provide some pointers for 
> implementers to differentiate the re-SUBSCRIBE (to extend the 
> subscription duration) and re-SUBSCRIBE (to fetch the complete state, 
> due to lost NOTIFY).

That's what RFC 5839 is for.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Apr 2012 15:41:59 -0400

Nataraju,

On 4/23/12 12:32 PM, Nataraju A.B wrote:
> networks, ...), where all the subsequent refresh SUBSCRIBE requests
> would un-necessarily eats up more bandwidth for fetching the complete
> state which is not necessary. For non-lossy network this is of minor
> issue...
>
> thoroughly how to differentiate differentiate these requests, through
> some new header / header parameter / any other way. Need more analysis...
>

Adam already responded that there exists a mechanism to optimize the 
redundant notifications away. We definitely won't embark on any 
functional changes to this draft at this late stage.

Regarding the editorial comments - its again very late, and I don't find 
any of them compelling.

In the future please try to get your reviews in no later than WGLC.

	Thanks,
	Paul

> On Mon, Apr 23, 2012 at 7:32 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Nataraju,
>
>     Your comments would have been much more helpful if received some
>     months ago when the document went through WGLC. This document is now
>     *very* far down the process to publication, having already gone
>     through IESG last call, IANA review, etc. and is now in final IESG
>     Evaluation. Changes at this point are very disruptive.
>
>     If you feel your suggestions are essential then you will have to go
>     to extremes to pull this document back. I don't see anything below
>     that convinces me to do that. AFAICT the comments below are all
>     minor editorial except for the first, which suggests changing the
>     mechanism.
>
>             Thanks,
>             Paul (as co-chair)
>
>
>         Some logical comments on the draft-ietf-sipcore-rfc3265bis-__08.txt.
>
>         ------------------------------__-----------------------
>         5.3.2.  State Deltas
>
>         CurrentText:
>
>             b) re-SUBSCRIBE triggered because of lost NOTIFY request
>         (ref sec
>         5.3.2.
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         or wait till NOTIFY with "Subscription-State"="__terminated". If
>         we always
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         3.2.1.
>
>         CurrentText:
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>
>         Thanks,
>         Nataraju A B
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>__>>
>         Subject: draft-ietf-sipcore-rfc3265bis-__08.txt - Review comments
>         (Nataraju A B)
>         To: Adam Roach <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>,
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>
>         Adam,
>
>         "draft draft-ietf-sipcore-rfc3265bis-__08.txt"
>
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>
>         ------------------------------__-----------------------
>
>         2.  Definitions
>
>         CurrentText:
>         ------------------------------__-----------------------
>         2.  Definitions
>
>         CurrentText:
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>             are subscribing.  The "Event" header field **MUST** contain
>         a token
>         which
>         ------------------------------__-----------------------
>         3.1.  SUBSCRIBE
>
>         CurrentText:
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         3.2.1.
>
>         CurrentText:
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>
>         CurrentText:
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         4.3.  Proxy Behavior
>
>         CurrentText:
>         ------------------------------__-----------------------
>         or wait till NOTIFY with "Subscription-State"="__terminated". If
>         we always
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         4.5.2.  Sharing Dialogs
>
>         CurrentText:
>         ------------------------------__-----------------------
>         4.5.2.  Sharing Dialogs
>
>         CurrentText:
>         ------------------------------__-----------------------
>         4.5.2.  Sharing Dialogs
>
>         CurrentText:
>         ------------------------------__-----------------------
>         4.5.2.  Sharing Dialogs
>
>         CurrentText:
>
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         5.3.2.  State Deltas
>
>         CurrentText:
>
>         ------------------------------__-----------------------
>         5.3.2.  State Deltas
>
>         CurrentText:
>
>             b) re-SUBSCRIBE triggered because of lost NOTIFY request
>         (ref sec
>         5.3.2.
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>         ------------------------------__-----------------------
>
>
>         Thanks,
>         Nataraju A.B.
>         E-ID : [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>> /
>         <mailto:[email-masked] <mailto:[email-masked]>__>
>
>         +91-98455-95744
>
>
>
>         --
>         Thanks,
>         Nataraju A.B.
>
>
>
>         _________________________________________________
>         sipcore mailing list
>         https://www.ietf.org/mailman/__listinfo/sipcore
>         <https://www.ietf.org/mailman/listinfo/sipcore>
>
>
>     _________________________________________________
>     sipcore mailing list
>     https://www.ietf.org/mailman/__listinfo/sipcore
>     <https://www.ietf.org/mailman/listinfo/sipcore>
>
>
>
>
> --
> Thanks,
> Nataraju A.B.
>