Subject: [rohc] Comments on ROHC-GN...

From: "West, Mark (ITN)" <[email-masked]>
Date: Sun, 23 Jun 2002 09:50:15 +0100

Hi Hongbin, et al...

I just saw your draft.  It's... interesting!

(I should probably point out that we have been working on a notation 
draft, as agreed at Minneapolis.  [Yes, I'm behind schedule, but that's 
fairly normal for me!]  Since it's just about done, I hope you won't be 
too dismayed when we submit it?  There's a large degree of commonality, 
but also some issues that need to be discussed...)

Anyway, I have (you may be unsurprised to learn) a few comments.  So,
here goes:

Can you clarify the nature of the mathematics that underly ROHC-GN?

I'm not quite sure why there is an example of the description of an IPv6 
header in the 'original' EPIC-lite input language?

Shouldn't most of the references to EPIC-lite be to an arbitrary set of 
'encoding rules' (except as an example)?  My understanding is that the 
notation is supposed to be independent of the encoding rules...

I still don't believe that we've reached any consensus on the separate 
structure/encoding information, as (initially) described in section 4.7. 
  Personally, I find things like having VALUE in the structure and 
encodings section very confusing.

Section 5.1 seems to be entirely about the encoded structure of the 
header and, as such, I don't think belongs in a document about notation.

Regarding the encoding methods:

When you say that the OFFSET method encodes the difference (via the 3rd 
parameter), do you mean that this is treated as LSB encoding of the 
difference?  Could you clarify this?

The 'SCALE-FACTOR' and 'SCALE-REMAINDER' encodings take a scale-factor 
as a parameter.  Where does this parameter come from?

I don't really understand how you can just have an 'INFERRED' encoding; 
surely we would need to define what this actually meanes?

In the SUB-TREE-0 example, the example is a bit odd!  The TCP options 
are bounded by the 'data offset' field.  The options *may* have an end 
flag, but don't rely on it...

I notice that another old favourite of past discussions, FORMAT, has 
gone.  It's not immediately clear to me how you handle the sort of 
scenarios it was designed to cope with: e.g. UDP checksum?

Regarding the example TCP profile:

(I suspect that this needs a bit more tweaking, so I'll confine myself 
to a few of the more obvious points...)

There seems to be a signficant element of repetition in this.  Take for 
example the TCP sequence number.
Let me see if I follow this...
   1/ The seqno is specified as a number of bits in the header
   2/ All the encodings for seqno are listed and given probabilities
      (possibly in combination with other fields)
   3/ All the discrete encoding choices for seqno are listed
      (presumably this is basis on which the encoding choice is made?)
[I assume that the parameters for (2) and (3) have to agree?  i.e. 
LSB(tcp.seqno,20,16384) has to appear in both lists?]
Is that about right?

There seems to be some inconsistency about the position of the 
percentage in the P() method.  (And I'm afraid that I still don't think 
I understand the use of P(x%) on its own..!)

Shouldn't the encodings in the options (e.g. timestamp) have 
probabilities associated with them?  (Only the first bunch of fields in 
the header seem to have probabilities assigned...)

The earlier description of OFFSET gives it 3 parameters?

Personally, I don't believe that the security considerations are 
inherited from ROHC (or rather, ROHC has many more concerns than the 
notation).

Cheers,

Mark.

BTW - I think that it's only fair to add Richard Price's name to the 
acknowledgements at the very least, don't you..?

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I
didn't ask for it to be that way)