Re: [martini] draft-ietf-martini-gin-05

[Paul Kyzivat <[e-mail]>]

[resend - I erroneously sent to sipcore previously]
(Still catching up on my reading)

This draft is hanging together very well now. I have a few comments:

Section 7.1.2.2:

According to RFC5627 (gruu) section 3.2, every registration refresh
generates a new temp gruu, with special rules for expiration. Does that
apply here too? Or is that changed for bnc registrations? Either way, I
think the implications need to be discussed.

Section 7.2.1:

I think there may be an issue here. Normally RFC5628 (gruu reg event)
would apply here, reporting the gruus assigned. (The most recent for the
temp gruu.) That could work for the pub-gruu of each implicitly
registered number. But it won't work for the temp gruus - the SSP
doesn't even know what those are. If there was a record for the "base"
AOR, that could contain the temp-gruu template. But that is currently
forbidden.

Again, I think something needs to be said about this, whatever way it
should work.

One thing to keep in mind is that management of temp gruus can be touchy
relative to registration refreshes. If the registration ever expires,
even momentarily, then the previously assigned temp gruus become
invalid. Only new ones obtained after reregistration are then valid. In
the case of the pbx with devices registered to it, that have have been
issued "derived" temp gruus, those also become invalid.

The only way to be certain this hasn't happened is to subscribe to the
reg event package and get gruu reg event info about the temp gruu. But
that will only work if the pbx can get temp gruu info from a reg event
subscription to the SSP.

Sorry to be so tardy in getting this info out. I think I alluded to it
earlier, but I don't think I ever provided specifics.

	Thanks,
	Paul

7.2.2

There is an out for the SSP to handle the subscriptions if it can keep a
complete, accurate and up to date copy of the data, e.g. through a
backend subscription.) Its even harder than that, since the pbx could
apply an authorization policy to each of those AORs, restricting who can
see the info, and how much of it. The SSP couldn't learn that through
backend subscriptions unless it maintains a distinct backend
subscription for each potential subscriber.

In this section gruus again rear their ugly heads. If the pbx supports
gruu, then it probably SHOULD support the gruu reg event package and
return the appropriate information.