Subject: RE: 3rd party registration (was RE: [Sip] SIP MIB ietf-sip-mib comments)

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 9 May 2006 02:47:13 -0600

Hi Rohan,

   Thank you for your review and comment.

You wrote:
> Hi,
> 
> While I am fine with the proposed resolution, I think we are better
> off removing this object entirely.  
> I don't think the use case for
> setting or checking if one version of 3rd party registration is
> allowed using a MIB is well motivated.

This is a protocol MIB and the typical way folks build these management objects (be it with SMI or XML or any other notation syntax or language) is by walking through the protocol text and looking at the things that can be modeled for management, configured, monitored, etc.

What pops up from a walk-through of RFC 3261 section 10 seems to justify this object for a registrar (I think) and may motivate a *basic* use case for an on/off switch. 
If it is true that the 3rd party mechanism intended and defined by 3261 is used by some implementations as we read in the thread, even if the best current practices for allowing/disallowing 3rd party reg have evolved, this object could be set by the registrar.

- from 3261, section 10.2 and 10.3
         In architectures that support third-party registration, one
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         entity may be responsible for updating the registrations
         associated with multiple addresses-of-record.
-> This means some do, some don't.

- from section 26.1.1
   While these two fields are
   frequently the same, there are many valid deployments in which a
   third-party may register contacts on a user's behalf.
               ^^^^^^^^^^^^
So at a first level, one can view the origin of this object and the basis use case.
The question becomes:
	Is it a given that 3rd-party registration is supported by registrar implementations? 
 	If so, do implementers typically expose the controls for enabling/disabling 3rd-party reg to end-users or operators? 
If the answers are yes to both, this object has a valid case.
If not, I agree, it should be deleted.
 
Finally, looking at the current uses of 3rd-party reg, if folks believe it is better to just remove it, this is certainly fine with me.

Thoughts?
Jean-François
> thanks,
> -rohan

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 9 May 2006 14:07:39 -0500

On May 9, 2006, at 3:47 AM, Jean-Francois Mule wrote:

>
> If it is true that the 3rd party mechanism intended and defined by  
> 3261 is used by some implementations as we read in the thread, even  
> if the best current practices for allowing/disallowing 3rd party  
> reg have evolved, this object could be set by the registrar.
>

So does anybody out there have or envision a registrar that would  
distinguish third-party registrations from other registrations and  
track them differently?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 May 2006 15:23:26 -0400

I have missed all the earlier parts of this thread. (Because I have a 
rule that I always delete any mail that contains "mib" in its subject.)

So I don't understand the context for this. But...

Dean Willis wrote:
>> 3261 is used by some implementations as we read in the thread, even if 
>> the best current practices for allowing/disallowing 3rd party reg have 
>> evolved, this object could be set by the registrar.
>>
> 
> distinguish third-party registrations from other registrations and track 
> them differently?

Well, there are some clear examples of that. In particular, IMS doesn't 
support 3rd party registrations from real users. And it uses a 
bastardized version of 3rd party registration between the S-CSCF and 
Application Servers. These are entirely different.

And I *think* -outbound- deprecates 3rd party registrations, doesn't it?

IMO 3rd party registration is a very reasonable, and potentially useful, 
capability. It makes perfect sense if you have reasonable (and distinct) 
authentication and authorization capabilities.

I have heard of at least one implementation that supports 3rd party 
registration.

But making it work for IMS is probably out of the question.

	Paul

---

From: Venkatesh <[email-masked]>
Date: Tue, 9 May 2006 15:50:33 -0700

I think there was a discussion at length in the mailing list that talked
about outbound deprecating third party registrations and concluded that it
outbound allows third party registrations where From!=To.

http://www1.ietf.org/mail-archive/web/sip/current/msg13968.html

Like you mention, third party registrations are useful. It is currently used
in the current bridged line appearance draft (draft-anil-sipping-bla-02) and
there are a few implementations that support the same.

Venkatesh

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 May 2006 10:19:22 -0500

> I have heard of at least one implementation that supports 3rd party  

But do we have any need to track and report on 3rd party  
registrations at the MIB level differently than we do 1st party  
registrations?

Or is a registration just a registration from a peg-count perspective?

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 May 2006 16:02:13 +0200

At this point, the value of finishing this MIB far outweighs the  
value this discussion will add to the MIB. I will happily support  
whatever the author choose to do to close this issue.

Cullen

On May 10, 2006, at 5:19 PM, Dean Willis wrote:

>> I have heard of at least one implementation that supports 3rd  
>> party registration.
>