Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-20.txt

From: Carl Knutsson <[email-masked]>
Date: Thu, 12 Oct 2006 14:53:18 +0200

L-E, others,

Comments inline.

Lars-Erik Jonsson (LU/EAB) wrote:
> Carl,
> 
> Thanks for the review!!
> 
>> There are some corrections in the draft made without the
>> INVALIDATED-CORRECTED syntax that could benefit from using
>> it, 5.4, 5.5 and 5.6
> 
> This syntax is used "When a section of this document makes
> formal corrections, additions or invalidations to text in
> RFC 3095". When looking at the various sections of this
> document, it may not be obvious what are clarifications and
> what are invalidations/corrections/additions. The sections
> you refer to, 5.4, 5.5, and 5.6, are not really making any
> changes to the protocol, they only clarify different aspects
> that could not be interpreted differently, but which have
> generated questions on the list that we do not want to get
> again. Instead of forcing implementers to figure these things
> out themselves, we provide the clarifications and elaborations.

I see 5.4 as a formal correction to the rfc3095 text (removing the word include).
 It is probably a matter of opinion. It will not lead to any misinterpretations,
so I am ok with keeping it as it is.

> 
> 
>> Sometimes this syntax is not needed when making a
>> clarification or addition. The new enhanced mode transfer
>> procedure in section 3 and the context management in
>> section 7 are more or less new additions to rfc3095.
> 
> Regarding section 3, the enhanced mode transition procedures
> are clearly optional, nothing is invalidated or normatively
> added. The text says "These enhanced procedures should be
> considered only as a possible improvement to a decompressor
> implementation, since interoperability is not affected in
> any way." The INVALIDATES-CORRECTED-ADDED syntax thus do not
> apply here. 

I agree that the INVALIDATES-CORRECTED-ADDED syntax is not very suitable for
section 3 and if you stretch it a bit, you can see the enhanced mode transfer as a
clarification on how too use sparse feedback during a mode transition.

> 
> For section 7, the same answer as for 5.4-5.6 above applies.
> The content provided in these sections only make things clear
> that should be implicit from the protocol, but not necessarily
> easy to figure out.
> 

Agreed, section 7 can be seen as a clarification on context management. I believe
this document can be passed on to upper layers in IETF.

/Carl

> 
>> About the references to rfc3095. Any of four suggestions
>> will work, but why invent a new ways of making a reference?
>> Couldn't we just use "in rfc3095 section 5.6" instead?
> 
> Of course we could, I have no strong preference. The idea
> was to have a short form (one letter according to Magnus
> proposal, the RFC number, i.e. 4 digits according to my 
> initial proposal), but now it became the whole RFC3095, so
> maybe we do not gain anything from using it.
> Opinions anyone?
> 
> /L-E

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