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

From: Carl Knutsson <[email-masked]>
Date: Wed, 11 Oct 2006 18:00:12 +0200

Hi L-E, Magnus and all,

As a CDR, I have reviewed draft-ietf-rohc-rtp-impl-guide-20.txt. I apologize for
sending it to the list after the last-call expired.

The draft is now in good shape, except for one issue. I find the use of
"INCOMPLETE", "INVALIDATED", "INCORRECT and INVALIDATED" and "CORRECTED" keywords
a bit inconsistent. Some sections use this syntax and some does not. I get the
impression from the fifth paragraph in the introduction that all additions and
corrections should use this syntax. 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

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. These sections are well
written but they do not use the ADDITION keyword. I believe this should be
reflected in the introduction. I suggest an small addition to the fifth paragraph
to explain that this terminology is not always used and that some
additions/clarifications does not use this INVALIDATED-CORRECTED syntax.

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?

regards,
Carl Knutsson

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Robust Header Compression Working Group of the IETF.
> 
> 	Title		: RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095
> 	Author(s)	: L. Jonsson, et al.
> 	Filename	: draft-ietf-rohc-rtp-impl-guide-20.txt
> 	Pages		: 29
> 	Date		: 2006-9-25
> 	
> RFC 3095 defines the RObust Header Compression (ROHC) framework and
> profiles for IP, UDP, RTP, and ESP. Some parts of the specification
> are unclear or contain errors that may lead to misinterpretations
> that may impair interoperability between different implementations.
> This document provides corrections, additions and clarifications to
> RFC 3095; this document thus updates RFC 3095. In addition, other
> clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP
> profile) and RFC 4109 (ROHC UPD-Lite profiles) are also provided.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-20.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-ietf-rohc-rtp-impl-guide-20.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-20.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Thu, 12 Oct 2006 09:49:36 +0200

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.

> 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. 

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.

> 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