Subject: [rohc] Another SigComp document review

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 15 May 2002 14:34:00 +0200

Dear all,

I have also reviewed the SigComp documents, and have some minor
editorial comments.

"Signaling Compression Requirements & Assumptions"
<draft-ietf-rohc-signaling-req-assump-05.txt>

- Abstract 
  Should be expanded. "ROHC" should be removed to avoid confusion
  (might be interpreted as if the desired solution is at the
  link-layer, based on the ROHC framework). Further must the 
  mnemonics be expanded (e.g. SIP/SDP). For more details
  about abstracts, see draft-rfc-editor-rfc2223bis-02.txt.

- Section 1., second paragraph. Should be either one or two
  paragraphs, now it is one "broken" paragraph.

- Section 1.1. It could be clearer that these protocols are
  examples.

- Section 2.1. Should we move Figure 2.1 to appear earlier in the text?

- Section 2.1., second paragraph. First two sentences do not say
  what they were intended to say, I think. Proposed modified text:
  "It should be noted that the used figures represent a very narrow
  band link. E.g. a WCDMA system can provide maximum bit rates up
  to 2 Mbits/s in ideal conditions, but that means one single user
  would consume all radio resources in the cell."

- Section 4., "Unreliable transport". TCP is an example, so we 
  should say "e.g. [TCP]."

- Appendix A. I think the appendix should now be removed, since
  this was intended for testing, and is now covered by a separate
  draft defining a dictionary to use.

"Signaling Compression"
<draft-ietf-rohc-sigcomp-06.txt>

- Section 5. Usage of keywords should be consistent and clear. For
  requirement 1. I suggest:
  "1. For robustness, it is RECOMMENDED that the compressor..."

- Section 5.1. Usage of keywords should be correct and clear.
  For the second paragraph, I suggest:
    "...ratio the compressor should request..."
  For the third paragraph, I suggest:
    "...however, it MUST ensure that...", and
    "...however, the compressor MUST provide a..."
  For the fourth paragraph, I suggest:
    "The compressor MUST also ensure..."

- Section 7., 5th paragraph. The examples "...(e.g. one or more 
  previously received messages, a dictionary of common SIP
  phrases etc.)" are unclear and confusing. What does it mean
  to explicitly indicate these? Is it to send some amount of
  data, or is it to use references? Further, if one says 
  "previously received messages", what does it mean? Is it
  about received messages at the compressor or the decompressor?
  I would suggest to remove the examples, and keep the rest of
  the text, which, apart from this, is rather clear.
  
- Section 8., second paragraph. The text "...provide unlimited
  flexibility..." is in my opinion not correct, and if it was I
  think it had been really bad. We could just remove "unlimited".

- Section 8.4, last paragraph. We should separate the instructions
  listed with at least a comma, as done in other parts of the draft.

"SigComp - Extended Operations"
<draft-ietf-rohc-sigcomp-extended-03.txt"

- Abstract could be improved. It could clearer state that this is
  about how to implement certain mechanisms within SigComp. Further,
  overall it could be clearer and more complete in itself.

- Section 2., "Explicit acknowledgement" definition. Rewrite
  text. Now it is not clear whether it is the acknowledgement or
  the state that is explicitly sent.

- Section 5.6, second paragraph. End of page says "As input into
  to...", remove "into".

Cheers,
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research and Experiments
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 May 2002 21:09:58 +0200

It's nice to see that we are mainly discussing editorial items in this 
WGLC.  Even these must be fixed at some point, so let me make some 
editorial observations.

> - Section 5. Usage of keywords should be consistent and clear. 

Yes.  An important reason for having RFC2119 is that you have a way of 
using "must", "recommended" etc. in their English sense by not 
capitalizing them.  Now, did we do this right:

> For

I believe this is one case where an RFC 2119 "RECOMMENDED" would be 
overkill.  It's not like there are serious dangers to interoperability 
if you don't.  True, you will not detect interop problems as easily, so 
this is still a good recommendation.  I'm not sure it should be a SHOULD 
= RECOMMENDED in the sense of RFC 2119, though:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

SigComp is not so fragile that you have to take a careful analysis 
before not implementing the simple robustness scheme mentioned.
(One quote likely reason may be that the application already has a 
robustness scheme.  Or you may simply disable the checks after the 
debugging period is over.)

I suggest not taking this change.

>     "...ratio the compressor should request..."

needs to?
This was meant as a statement of fact, not a mandate.

>     "...however, it MUST ensure that...", and

Hmm, this rules out optimistic approaches (which may be OK if the right 
kind of sigcomp and/or application feedback is available).

I suggest no change, or possibly replacing the "must" by "needs to".

>     "...however, the compressor MUST provide a..."

Again, this is more of a statement of fact (and see above).

>     "The compressor MUST also ensure..."

See above.

>   the text, which, apart from this, is rather clear.

Sounds good to me.

>   think it had been really bad. We could just remove "unlimited".

"Unlimited" is a bit much.  "Substantial", "strong", "striking"?  Or 
just remove it, as you say.

>   listed with at least a comma, as done in other parts of the draft.

Sure.

Gruesse, Carsten