[rohc] Another SigComp document review

"Lars-Erik Jonsson (EPL)" <Lars-Erik.Jonsson@epl.ericsson.se> Wed, 15 May 2002 12:55 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01045 for <rohc-archive@odin.ietf.org>; Wed, 15 May 2002 08:55:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10224; Wed, 15 May 2002 08:34:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10195 for <rohc@ns.ietf.org>; Wed, 15 May 2002 08:34:06 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29694 for <rohc@ietf.org>; Wed, 15 May 2002 08:33:52 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4FCY4s7026187 for <rohc@ietf.org>; Wed, 15 May 2002 14:34:04 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 15 14:36:18 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4J29C>; Wed, 15 May 2002 14:34:03 +0200
Message-ID: <A943FD84BD9ED41193460008C791805003E32083@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (EPL)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Date: Wed, 15 May 2002 14:34:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA10196
Subject: [rohc] Another SigComp document review
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression <rohc.ietf.org>
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 8bit

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: lars-erik.jonsson@ericsson.com
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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc