RE: [rohc] draft-ietf-rohc-sigcomp-04.txt

Hi Miguel,

Thanks for your comments. I've tried to provide you with some answers. 

> 1) Section 1, Introduction, 5th paragraph:
>    I would suggest to rephrase and split the sentences into different 
>    paragraphs, one describing the scenario that SigComp is trying to
>    solve (an endpoint - proxy scenario) and the other describing the
>    ability of SigComp to run over connectionless and c.o. transports.

Is it ok if we just split the sentence as:

"This document focuses on the signaling scenario where an endpoint 
 sends and receives data to/from an outbound/inbound proxy. However, SigComp
 may be applicable to other scenarios with multiple endpoints 
 compressing and decompressing data.

 SigComp is designed to run over both connectionless and connection-
 oriented transports."

> 2) Section 2, Terminology, definition of Application:
> 
>      "c) decides whether state information may be saved by SigComp "
> 
>    I believe that the application does not decided to save state
>    information, but the application "authorizes to save state 
>    information based on a request from the SigComp layer".

I guess we could make the change as you suggest.

"c) authorizes to save state information based on a request from the SigComp layer"

> 3) Section 3, SigComp architecture, 2nd paragraph:
> 
>    "SigComp is typically offered to applications as a "shim" layer 
>    between the application and the transport. Note however that for 
>    certain applications the compressed SigComp message may be passed 
>    back to the application itself for additional processing before 
>    transmission. For example, the application may wish to apply 
>    encryption to the compressed message before handing it to the 
>    transport. "
> 
>    I don't think this scenario is possible. To my understanding, 
>    there are two types of encryption: end-to-end and hop-by-hop.

This roles back to whether SigComp is applied IP end-to-end (Endpoint - first proxy ), or "SIP end-to-end" (SIP endpoint to SIP endpoint). 

>    I would like to hear comments on the above statements. And 
>    certainly clarify what is the relationship between the application
>    and SigComp. 

I think this comes back to which scenario we want to solve. If it is the SIP end-to-end scenario with encryption, this may probably make SIP/SigComp require an assigned port number and SigComp would not be regarded as a shim layer to SIP, but the implementation would have to be totally integrated. 

>    Particularly it needs to be clarified which layer
>    is responsible to forward the message: the SigComp layer or the
>    application layer.

With my current understanding of our work and if it is as you say then I think it does not make sense to pass up a compressed message to the application to forward the SigComp message.  

> 4) Section 3, SigComp architecture, Figure 1.
> 
>    The figure shows 2 different applications. In my mind, there 
>    should be one and only one application, together with a text 
>    that describes that there is one SigComp layer instance per
>    application.

This approach seems to have some good and valid arguments along with it. 

> 5) Section 3.2, first paragraph:

>    In order to avoid confusion with two applications running in the
>    same local host and making use of SigComp, I would suggest 
> to rephrase:
> 
>    "The local and remote applications that wish to communicate MUST 
>    initially agree on a common set of values for these parameters."

I think this is a good suggestion.

> 7) Section 4.1.1, first paragraph:
> 

>    As a minimum, the above sentence should be rephrased as:
> 
>    "An endpoint that wants to send compressed data to a 
> remote party must 
>    initialize a SigComp layer at the remote party prior to 
> its use,..."

This is good for clarification.

>     
> 8) Section 4.2, first paragraph:
> 
>    "The basic SigComp message consists of a block of UDVM 
> bytecode, the 
>    first n bytes of which are interpreted as a state identifier that 
>    accesses some previously stored state information. "
> 
>    I think this is inherited from the UDVM draft and it is not valid 
>    anymore. The basic SigComp message will NOT consist only of UDVM
>    bytecode. Whatever the basic SigComp message is made of, should be
>    reflected in the paragraph.

There is a note in the draft about solving the identification of different types of messages by reserving state identifiers. However, I now think that this is not possible for the following reason:

* SigComp do not know the length of the state identifier prior to the capability announcement.
- As SigComp does separate flows, SigComp needs to carry the hash length for each message. 

I think this make it valid to introduce some bits to identify the particular message type. Thus, the basic SigComp message format would change to something like this:

     0   1   2   3   4   5   6   7 
   +---+---+---+---+---+---+---+---+ 
   |  MT   |Reserv.|  hash length  | 
   +---+---+---+---+---+---+---+---+ 
   |                               | 
   :   state_identifier (n-bytes)  :  
   |                               | 
   +---+---+---+---+---+---+---+---+ 
   |                               | 
   :    Remaining UDVM bytecode    : 
   |                               | 
   +---+---+---+---+---+---+---+---+ 

The MT, Message Type, would indicate what type of message it is, e.g. SigComp request/announcement, "ordinary" SigComp compressed message.

> 9) Section 4.3, 7th paragraph:
> 
>    "Uncompressed data is also outputted by the UDVM using a specific 
>    instruction. Depending on the particular application, the 
> dispatcher 
>    decides whether to forward a partially decompressed message 
>    immediately to the application, or to buffer and wait for 
> a complete 
>    message to be successfully decompressed."
> 
>    I disagree with the above statement. The decompressor dispatcher I
>    have in my mind does not have any application knowledge. It is,
>    therefore, not able to distinguish whether the message is complete,
>    or partly received. The dispatcher should limit to pass 
> decompressed
>    data to the application. The application must be aware of 
> whether the
>    received message is complete or not.
> 
>    Therefore, I suggest to remove the mentioned paragraph.

I tend to agree with you on this. As a decompression failure/success check is done on the whole decompressed message this statement contradict this.

 > 10) Section 5.3., last paragraph

>    I think the last sentence should replace a "can" with a "MUST". 
>    In case there is a problem to compress a message, it is a MUST that
>    the application is informed. 

I think you're right on this.

> 11) Section 6.3 Capability announcement
> 
>     Question: is this section describing the "Capabilities 
> Announcement" 
>     already described in section 4.1.1 ??

Those sections are related, and we should synchronize the names.

> 12) Section 6.3., figure 5.
> 
>     The figure refers to a Capability announcement "block". 

Yes, we need to define the term "block". What do you think about the following:

"Capability announcement block"
formatted capability announcement information

> 13) Section 8.2, first paragraph.

See my comment to bullet 9).

BR
/Hans H

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc