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

[[e-mail]]

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.

   From: Aki Niemi <[e-mail]>

   > The notifier cannot know what routing is in front of it, because it
   > 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?

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.

   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.

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
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip