Subject: Re: [rohc] Review of SigComp NACK draft

From: Adam Roach <[email-masked]>
Date: Wed, 20 Oct 2004 18:40:04 -0500

Richard Price wrote:

> Open issue in Section 2.4: In general it would be a good idea to 
> explicitly signal support for NACKs, rather than attempting to probe 
> the remote endpoint by sending dodgy SigComp messages, as the latter 
> approach could lead to all sorts of problems. However, why not 
> indicate support for NACKs by assigning a new SigComp version number 
> (i.e. SigComp Version 0x02 = SigComp Version 0x01 + NACKs)? Seems more 
> straightforward than relying on the decompressor bytecode to detect 
> NACK support and then signal this to the remote endpoint as requested 
> feedback.

Thanks for spotting the open issue! I had completely forgotten this was 
in here. I really like the simplicity and speed of detection that your 
suggestion provides. I've incorporated it into the draft.

> Section 2: Typo - "The actual format and values are described in 
> section Section 3."

Fixed.

> Section 2.1: It might be worth noting that the information used to 
> determine which SigComp message belongs to which compartment is not 
> always carried in the SigComp message itself. In "continuous mode" for 
> example, we make the assumption that the lower layer provides enough 
> security to map SigComp messages to their correct compartment. The 
> contents of the SigComp message are irrelevant to finding the correct 
> compartment in this case. In fact, there is not always enough 
> information in the SigComp message itself to determine the compartment 
> to which it belongs.

I understand and agree with everything you just said. I'm not entirely 
sure how it relates to section 2.1.

All section 2.1 says is (paraphrased), "store the SHA1 hash such that, 
if someone hands it back to you, you can find the correct compartment to 
apply it to." It doesn't assume that the message itself contains 
information about the compartment -- only that the SigComp compressor 
has some idea which compartment it's currently working with (which 
always must be true).

Obviously, there's something unclear about this section. I've added the 
following clarifying text:

    In other words, if someone hands the SHA-1 hash back to
    the compressor, it needs to be able to find the compartment
    with which it was working when it sent the message with
    that hash. This only requires that the compressor knows
    with which compartment it is working when it sends
    a message (which is always the case), and that the SHA-1
    hash, when stored, points to that compartment in some
    way.

>
> Section 2.2: Typo - "See section Section 3 for more information about 
> formatting the NACK message and its fields."
>

Fixed.

> Section 3.1: The phrase "it is useful to demonstrate the specific 
> fields as they appear inside the "returned feedback item" field" might 
> be left over from a previous version of the draft.
>

Thanks. I've fixed this.

> Section 3.1: Typo - "The specific codes are given in section Section 3.2"
>

Fixed.

> Section 3.1: Might be worth pointing out that the term "program 
> counter" is using the standard hardware definition of a program 
> counter, and thus is the UDVM memory address of the failed UDVM 
> instruction.
>

Ah, yes. I didn't realize that 3320 never talks about the program 
counter. I've clarified:

    "PC of failed instruction" is a two-byte field
    containing the value of the program counter when failure
    occurred (i.e. the memory address of the failed
    UDVM instruction).

> Section 3.1: Typo - "See section Section 3.2 for specific information 
> on what appears in this field."
>

Fixed.

> Section 3.2: Typo - "A state that was referenced (either using 
> STATE-ACCESS instruction or in the actual SigComp message itself)"

I'm not certain what you believe the typo here is. Is it just that the 
phrase is a bit awkward? I've attempted to make it clearer:

 1.   STATE_NOT_FOUND
      A state that was referenced cannot be found.  The state may have
      been referenced by the UDVM executing a STATE-ACCESS
      instruction; it also may have been referenced by the "partial
      state identifier" field in a SigComp message.  The "details"
      field contains the state identifier for the state that could not
      be found.  This is also the proper error to return in the case
      that a unique state item was matched but fewer bytes of state ID
      were sent than required by the minimum_access_length.

Thanks again for your comments. I'll be dropping a -02 version of the 
document shortly.

/a

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