[rohc] Re: Reveiw - draft-ietf-rohc-rfc3095bis-framework-02.txt

L-E,

Comments inline..

BR,
/Carl

Lars-Erik Jonsson (LU/EAB) wrote:
> Carl,
> 
> Thanks for reviewing the document, please see responses inline.
> 
> BR
> /L-E
> 
> 
> ----Original Message----
> From: Carl Knutsson [mailto:carl.knutsson@effnet.com]
> Sent: den 1 november 2006 14:08
> To: rohc@ietf.org
> Cc: Lars-Erik Jonsson (LU/EAB)
> Subject: Reveiw - draft-ietf-rohc-rfc3095bis-framework-02.txt
> 
>> Hi L-E, all,
>>
>> I been asked to review the framework draft.
>>
>> My comments:
>>
>> 1. Introduction
>>
>> "To improve and simplify the specification, the framework and
>> the profiles parts of RFC 3095 have been split into separate
>> documents."
>>
>> The sentence above could be rephrased without RFC 3095.
>>
>> "To improve and simplify the specification, the framework and
>> the profiles parts have been split into separate documents."
>>
>> We are splitting the new specification into two documents.
>> This is a new specification. The sentence above gives the impression
>> that we have only split the rfc 3095 into two new documents.
> 
> Agree!
> 
> 
>> 2.2. ROHC Terminology
>>
>> Some of the definitions in the Terminology section are not
>> used very frequently.
>>
>> Context Repair mechanism - only used only in history part. "Repair
>>                            mechanism" is used. Maybe it should be
>>                            added in terminology.
> 
> I think Context Repair Mechanism is the correct term to define, although
> the text sometimes use a shorter form. In section 6, I suggest we add
> "context" to the last sentence to make it "The profile defines context
> repair mechanisms, including feedback logic if used."
>
Agree

>  
>> CRC-8 validation - not used in document. (Could be used in
>> section 5.4.3)
>>
>> CRC verification - not used in document.
> 
> These are conceptual ROHC terms, which may be used by profile
> specifications. Maybe we can use these in 5.2.3 and 5.3, but not
> necessarily.
> 

Agree, its conceptual terminology to be used in the profile documents. I 
should have looked at the tcp-draft instead of v2-profile-draft. The 
tcp-draft uses the framework terminology and the v2-profiles-draft 
defines an almost identical terminology section. Let's change the 
v2-profile-draft to refer to (and maybe extend) the frameworks 
terminology section instead.

 >
 >
>  
>> Error propagation - not used in this document.
> 
> True, but it is a conceptual term (used before), and it may well be
> referred to by profiles.
> 
>  
>> Packet Flow - Not used in this document. "flow of packet" and "flow"
>> is used. Include "flow" in the terminology?
> 
> I think Packet Flow is the correct term to define, although the text
> sometimes use a shorter form. We should make sure the most important
> occurencies are changed to say "packet flow".
> 
> 
>> Header Compression Profile - not used in document. "ROHC profile" and
>> "profile" is frequently used in the draft.
> 
> I think the most accurate term for the terminology section would be
> "ROHC Profile", I'll change this.
> 
>  
>> 5.1.1. Contexts and Context Identifiers.
>>
>> "..or when the CID gets associated from the reception of an
>> IR (this does not apply to the IR-DYN) with a different profile
>> than the profile in the context."
>>
>> IR and IR-DYN mentioned the first time (except for Abbreviation and
>> Terminology section). I suggest adding a reference to section 5.2.2.
> 
> I looked at this and it easily gets messy. IR and IR-DYN are defined
> in the acronyms section, that should be enough in my opinion.
>  

Ok, if it gets to messy.. we shouldn't add it.

> 
>> 5.2.2. Initialisation and Refresh (IR) Packet Types
>>
>> last sentence last paragraph...
>>
>> ".., or unless the profile in the Profile field specifies otherwise"
>>
>> could be rephrase to
>>
>> ".., or unless the profile indicated in the Profile field specifies
>> otherwise"
> 
> Agree!
> 
> /L-E

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