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

From: Aki Niemi <[email-masked]>
Date: Mon, 25 Feb 2008 23:53:12 +0200

On ti, 2007-09-18 at 11:06 -0400, ext [email-masked]
wrote:
> 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.

Yes.

> 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.

The subscriber really need not know. It is the notifier's responsibility
to keep the entity-tags unique across all of the insanely difficult SIP
routing that it may deploy in front of it.

> 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.

Correct.

> 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.

This isn't the subscriber's problem. Moreover, I really doubt that it is
even feasible to build a system where a new subscription sent to the
same AoR will randomly reach a different notifier instance that is in no
way synchronized (as in state, entity-tag values, etc) with the other
instances.

> * 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?

Fixed in -02.

> * 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 4 defines the entity to include the Event header field, which
includes all of the parameters.

> * 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).

Fixed in -02. It now says 202 (or 200).

> * 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.

Yes it is. A PUBLISH request will succeed (with a 2xx) or fail (412)
based on the condition; whereas a SUBSCRIBE will always succeed (with a
2xx) regardless of whether the "suppress" condition is true or not. This
is because the condition only affects the NOTIFYs that follow.

> * 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.

Fixed in -02.

> * 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

Yes, this is also an option.

> * 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.

Fixed in -02.

Thanks for the review!

Cheers,
Aki

> Dale

_______________________________________________
Sip mailing list  http://www.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, 26 Feb 2008 16:31:07 -0500

From: Aki Niemi <[email-masked]>

   Yes.

The notifier cannot know what routing is in front of it, because it
cannot know what URIs might route to it.

   Correct.

There is no requirement that the SUBSCRIBE was sent to an "AoR" (even
if that term was well-defined).

It is trivial to build a system where a new subscription could go to a
place that is much different than a previous subscription:

sip:a.example.com forwards to sip:b.example.com - I think of this as
"my call center".  What I don't know is:

sip:b.example.com uses time-of-day-based routing to forward to either
sip:c1.example.com or sip:c2.example.com - My company has outsourced
the call center to two different companies in in two different places,
one for the day shift and one for the night shift.

sip:c1.example.com parallel-forks to sip:d1a.example.com and
sip:d1b.example.com - The day-shift call center workers are in several
locations.

sip:c2.example.com parallel-forks to sip:d2a.example.com and
sip:d2b.example.com - And so are the night-shift call center workers.

OK, now I send "SUBSCRIBE sip:a.example.com".  Unless I know the
details of the above routing, there's no way for me to know that the
routing changes with time.  Similarly, there's no way for the
notifiers at d1a.example.com, d1b.example.com, d2a.example.com, and
d2a.example.com to even know what notifiers they *might* have to
synchronize with.

Dale

---

From: Aki Niemi <[email-masked]>
Date: Wed, 27 Feb 2008 10:08:58 +0200

> cannot know what URIs might route to it.

Then that's bad. How does the notifier then know which PIDF to pick in
presence subscriptions?

<snip>
> d2a.example.com to even know what notifiers they *might* have to

I agree this kind of setup presents a problem. But I also think that
what we're dealing with here is not that different from the web world.
There are a lot of load balancing schemes that can be used with HTTP,
which result in a GET ending up in different data centers in different
parts of the world at different times.

What's important to note there is that if the service that is accessed
via this GET needs sessions and gives out cookies, then the backend
system needs to be synchronized. Otherwise, the servers will be unaware
of each others cookies, and the service won't work correctly.

Similarly, the backend to the SIP notifiers needs a synchronized
backend, otherwise, subnot-etags won't work.  Naturally, the etags just
like cookies can be constructed in such a way that they contain the
necessary state.

Cheers,
Aki

Sip mailing list  https://www.ietf.org/mailman/listinfo/sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 13:35:46 -0600

I see that Dale and Aki are discussing this draft.

Do we need agenda time in Philadelphia for further discussion, or are  
we really ready for publication?

--
Dean

---

From: Aki Niemi <[email-masked]>
Date: Fri, 29 Feb 2008 16:21:11 +0200

> we really ready for publication?

As far as I'm concerned, this is ready for publication. 

I think the issue that remains does not warrant WG time. I think in
principal me and Dale agree, but we just need to figure out what (if
anything) the draft should say on the issue. In any case, this text
would probably end up being non-normative, which means it's not critical
to flesh out in detail for a publication request.

Cheers,
Aki

---

From: [email-masked]
Date: Fri, 29 Feb 2008 22:08:42 -0500

I agree that the point we're discussing is largely a matter of
providing a "beware" statement, except with the exception of a
possible *solution* to the problem which I will mention at the bottom.
But in any case, I don't see the need for agenda time at the metting
to discuss this.

Especially if it's not a presence subscription.  But seriously, is
this proposal confined to presence events?  I see no such text.

In general, a SUBSCRIBE will fork, and the subscriber presumably knows
how it wants to integrate the events it will receive from the various
subscriptions, based on the semantics of its situation.

There's a hidden philosophical problem:  People think of SIP routing
as being like PSTN routing, where the caller sends the call to a
number which designates one destination, or at least, a single device
which has total knowledge of a small number of possible destinations.
The caller knows the globally-recongized *name* of the
destination-group, and every destination knows of and is coordinated
with *every other possible destination*.

Your HTTP model is similar; you assume the request will reach one of a
set of servers that are co-adminstered.

But the reality is that SIP routing can be like sending e-mail to a
mailing list -- the sender doesn't know what the possible destinations
are, and each destination doesn't know what all the destinations are
either, because some of the routing can be done by agents that are not
co-administered with either the sender or the destination.

Now I think the first case is more common, but if we are going to
design a general mechanism, it should not fail badly in practice in
the second case.

Getting back to possible solutions:

Looking at section 6.1, I see '[An entity-tag] can have any value,
except for "*".'  (Let's correct that to 'An entity-tag can be any
token, except for "*".')  We can dodge the problem of uncoordinated
notifiers by demanding that entity-tags have some minimum amount of
randomness.  E.g., if any group of coordinated notifiers picks a
64-bit random value, and the entity-tag is generated by making a
64-bit hash of that value with the event information, the chances of
an etag-value collision in any single instance is 2^-64.

One can easily encode a 64-bit value in 11 token characters using
(modified) base64.  Compare that to the 5-character values used as
examples in the I-D.  Though if we used 6 base64 characters, we would
still have a 36-bit hash, which is probably good enough.

Dale

---

From: [email-masked]
Date: Fri, 29 Feb 2008 22:11:30 -0500

In any case, this text would probably end up being non-normative,
   which means it's not critical to flesh out in detail for a
   publication request.

I originally expected any text to be non-normative (since it was a
warning about an unavoidable danger), but after the random hashes came
up, it seems that it would be conceivable to specify a minimum
randomness content for entity-tags.  (We already have a randomness
requirement for to/from-tags.)

Dale