Subject: Re: [sipcore] Proxy-Feature: Requirement changes based on Robert's comments (IETF#81)

From: Robert Sparks <[email-masked]>
Date: Thu, 1 Dec 2011 16:47:50 -0600

On Nov 26, 2011, at 8:52 AM, Christer Holmberg wrote:

>  
> Hi,
>  
> Based on Robert's comments on the proxy feature requirements in Taipei, this e-mail describes suggested modifications.
>  
> If people are ok with the suggested modifications I will submit a new version of the requirements draft.
>  
> Regards,
>  
> Christer
>  
> ------------
>  
> - Comment that REQ-10 should talk about having access to the information, rather than talking specifically about making routing decisions:
>  
> I suggest a modification of REQ-10:
>  
>  
> OLD:
>  
>         REQ-10: Other SIP entities MUST be able to make routing
>         decisions based on received feature/capability support
>          indications.
>  
> NEW:
>  
>          REQ-10: Other SIP entities MUST be able to retrieve the
>         feature/capability support indications received in a SIP
>         message.

How about:

SIP entities on the path of the SIP message MUST be
able to inspect the feature/capability support indicators
introduced by other entities.

>  
>  
> ------------
>  
>  
> - Comment regarding the fact that requirements REQ-8 and REQ-9 seem to be identical:
>  
> Actually, they are not identical. REQ-8 talks about the case when an entity receives an indication that it doesn't support, while REQ-9 talks about the case where an entity that doesn't even support the mechanism receives an indication.
>  
> So, my suggestion is that we keep both requirements.
>  
> But, If you think it helps, I could modify REQ-8 in the following way:
>  
>          "REQ-8: If a SIP entity <new> that supports the proxy feature/
>          capability indication mechanism </new> receives a feature support
>         indication that it does not understand, it MUST act as if it hadn't
>         received the indication."
Better.
>  
>  
> ------------
>  
>  
> - Comment regarding the fact that we don't have a requirement saying that a proxy indicating support of a feature/capability associated with a dialog must be part of the signaling path of that dialog.
>  
> I suggest the following new requirement:
>  
> REQ-XX: A SIP proxy that indicates support of a feature/capability associated with a dialog MUST
take the necessary steps to ensure it is
> part of the signaling path of
the remainder
> that dialog.

Maybe that should be further refined to make it obvious that, as a consequence, a proxy can only indicate such
support as part of a dialog forming transaction.

> ------------

I also suggested that Req-13 be stated as a requirement (the solution must provide a way to avoid collision of indicators).

It would also be good to get some list discussion continuing the discussion we had in the meeting about the potential
semantics of an indications are.

We talked about whether these would be allowed or would make sense:

* An indication that was basically the brand of the element.
* An indication that an element was made from trendy parts or met some certification criteria (such as around energy use)
* An indication that the element is capable of dropping logs in SIPCLF format

I suspect there are others that folks here could brainstorm...

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Dec 2011 09:01:35 +0100

Hi Robert, 

------------
		 
> - Comment that REQ-10 should talk about having access to the information, 
> rather than talking specifically about making routing decisions:
>		 

Sounds good.

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

> Actually, they are not identical. REQ-8 talks about the case when an entity receives 
> an indication that it doesn't support, while REQ-9 talks about the case where an entity 
> that doesn't even support the mechanism receives an indication.
>		 

Good.

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

> - Comment regarding the fact that we don't have a requirement saying that a proxy indicating 
> support of a feature/capability associated with a dialog must be part of the signaling path 
> of that dialog.
>		 
>		take the necessary steps to ensure it is part of the signaling path of the remainder that dialog.
>		 
>				
> Maybe that should be further refined to make it obvious that, as a consequence, a 
> proxy can only indicate such support as part of a dialog forming transaction.

Yes. But, as we have discussed on the list, a proxy would also have to re-indicate support as part of a target refresh dialog, so indicate that it still supports the feature.

So, I suggest:

		REQ-XX: A SIP proxy that indicates support of a feature/capability associated with a dialog MUST 
		take the necessary steps to ensure it is part of the signaling path of the remainder that dialog, 
		by indicating the support of the feature/capability as part of a dialog forming transaction, or 
		as part of a target refresh request within a dialog.

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

> I also suggested that Req-13 be stated as a requirement (the solution must provide a way to avoid collision of indicators). 

I suggest to modify the requirement (Req-13 will become Req-14, btw) in the following way:

		REQ-14:	A procedure for registering feature/capability indication values, which prevents name collisions
				of indicators, with IANA MUST be defined.

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

>	I suspect there are others that folks here could brainstorm...

I have been working on some text, similar to what we have for Info Packages, about indication specifications, and what information they need to contain, and one part is of course a description/reference of the semantics. You will see it in the next version of draft-holmberg-sipcore-proxy-feature, suggesting a mechanism (using the Feature-Caps header field).

So, if a brand has some defined feature semantics associated with it, I think it should be allowed.

I also think that indicating that an element is capable of dropping logs is a good use-case.

I don't think the mechanism is to be used for pure information purpose, if there is no defined and registered semantics associated with it.

We can have that discussion when we start looking at the text I mentioned above, but I hope that it won't stop us from beginning the work on the actual protocol mechanism.

Thanks!

Regards,

Christer