Re: SigComp Requirements (was Re: [rohc] RE: Default decompression algorithms)

["Miguel A. Garcia" <[e-mail]>]

"Lars-Erik Jonsson (EPL)" wrote:
> 
> Miguel,
> 
> Here are some immediate comments on these requirements.
> 
[snip]

> 6.5.5 Default algorithm for SIP compression
> 
>    If SIP signaling compression is used, a default algorithm must be
>    supported by the UA and the network elements involved for compression.
> 
> -> LEJ: Why?? We are currently having a discussion about this on the list,
>    and we will see what the outcome will be. ROHC is not at all discussing
>    algorithms, and will therefore not define any default algorithm. What is
>    still under consideration is whether we should provide mechanisms to
>    announce decompressor-supported algorithms. However, the usefulness of
>    this is still not clearly proven, and if we want to support this we must
>    consider the security aspects of it and the added complexity of the
>    solution.

<miguel>
Yes, I fully agree with you. This is not a requirement. It is a solution to
a requirement that is not stated, and I don't know which one is that.

However, not all the authors of this I-D are able to differentiate a 
requirement from a solution. This is the reason why the text in there 
remains.

Just for your information, this is not the only place in the document where
we are mixing requirements with solutions. I have been trying to convince 
the others that requiring a solution without stating the requirement has
no sense... But I need to keep on trying.

As a short term solution, I would recommend the ROHC WG to answer to this
requirement: "In IETF we have taken the decision to not standardize a 
default algorithm. If other organizations, such as 3GPP want to standardize
a default algorithm in their networks, that's fine".
</miguel>

> 
> 
> 6.5.6 Compression Negotiation
> 
>    There must be a mechanism to negotiate between the UA and the first
>    SIP outbound proxy the compression algorithm to be used. The type of
>    negotiation mechanism that should be implemented is that the UAC
>    includes a list of compression algorithms and the first SIP outbound
>    proxy responds with the selected one. Subsequent SIP messages are
>    compressed based on the agreed algorithm.
> 
> -> LEJ: This is not a requirement, its is a proposed solution/mechanism.
>    Further, only the Proxy->UA traffic direction is addressed above.

<miguel>
The first sentence is a requirement. The rest is just additional information
or suggestions. I understand that "The type of negotiation mechanism that 
should be implemented is that the UAC includes a list of compression ..."
it is a solution, not a requirement.

I agree with you that this paragraph is considering only the case of the UA
to the Proxy, and not viceversa. Perhaps when these requriments were written
most people were thinking of a bidirectional case, so negotiation and compression
in one direction will imply the same results in the reverse direction.
</miguel>

/Miguel


> 
> >
> > A group of individuals collected the 3GPP requirements
> > related to SIP and
> > write them down in an Internet Draft,
> >
> > http://search.ietf.org/internet-drafts/draft-garcia-sipping-3g
> > pp-reqs-02.txt
> >
> > Version -03 is on its way and will be submitted before the
> > deadline to MN.
> >
> > I will encourage to read the actual section 6.5 in that
> > document. There are
> > several requirements affecting compression.
> >
> > I will also recommend to read requirements 6.1.1 and 6.1.2.
> > Although these
> > are general requirements, they are applicable to all the rest of the
> > requirements and possible solutions.
> >
> > /Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[e-mail]     Phone:  [phone]
mailto:[e-mail]        Mobile: [phone]

_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc