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

[Robert Sparks <[e-mail]>]

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