Subject: RE: [rohc] WG last-call for the IP-only profile

From: "West, Mark" <[email-masked]>
Date: Fri, 10 Oct 2003 12:07:16 +0100

Hi all,

Herewith my comments on draft-ietf-rohc-ip-only-04.txt...

(I have deliberately avoided reading Kristofer's comments, so apologies for
any duplicates!)

However, as the document looks good to me and there's not much to say, then
hopefully it shouldn't be much of a problem!

Cheers,

Mark.

3. ROHC IP Compresssion

The removal of UDP has *no* impact..?  You don't have to worry about whether
or not to include the UDP checksum..?!

3.2. Handling multiple levels of IP headers

Where the text says, "Specifically, the format defined for Extension 3
[RFC-3095, section 5.7.5.] can only carry the 'Outer' IP header," I assume
that this really means that Ext-3 can only carry a *single* 'outer' header
(since it clearly also encodes the 'inner' header...)

The wording seems to be a little confused in the two paragraphs starting,
'For the compression profiles defined in...'  Initially it states that, 'at
most two levels of IP headers can be compressed.'  Which is fine.  It then
states that additional headers, 'at best partially disables header
compression...' which is not a terribly clear statement.  However, the
following paragraph states that, '[f]or the compression of IP heades only,
the additional IP headers would however not have to cause header compression
to be disbaled...' except that it previously talks about 'partial'
disablement.  It's clear what is *meant*, but perhaps it could be phrased a
bit more cleanly..?

Are we happy that 'arbitrary' has been resolved..?!  I recall *much*
discussion on this point!  Clearly 'arbitrary' has an upper bound based on
the MTU, but is this generally agreed?  (Having now got further through the
document, I assume that S3.7. on the CONTEXT_MEMORY feedback option is
considered to address this issue?)

Nits:

1. Introduction

"defined to provide means" -> "defined to provide a means"

"often represent a major" -> "often represents a major"

3.1. Static chain termination

"(except for potential application header)" -> "(except for a potential
applicatipon header)"

3.3. Constant IP-ID

"Most IPv4 stacks assignes IP-ID" -> "Most IPv4 stacks assign IP-ID"

A.1.  Transition from Optimistic to Reliable mode

"keep the value D_MODE to O and it sets D_TRANS to P" -> "keep the value
D_MODE as O and set D_TRANS to P"

A.3.  Transition from Reliable to Optimistic mode

"keep the value D_MODE to R" -> "keep the value D_MODE as R"

General

Inconsistent references to [ROHC] (which isn't in the references) and
[RFC-3095] (which is!)...

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]]
> Sent: 26 September 2003 10:27
> To: [email-masked]'
> Subject: [rohc] WG last-call for the IP-only profile
> 
> 
> ROHCers,
> 
> In Vienna, it was agreed that the IP profile is ready for WG
> last-call, and committed document reviewers were appointed.
> The draft has been updated to address the few comments received.
> 
> Therefore, we are now issuing a WG last-call for:
> 
>   draft-ietf-rohc-ip-only-04.txt
>       (for publication as Proposed Standard)
> 
> This is a regular two-week WG last-call.
> 
> Please direct WG last-call comments to the ROHC mailing list
> [email-masked] before Fri, 2003-10-10, 18:00 UTC. The committed
> document reviewers are also expected to submit their reviews to
> the list prior to this deadline.
> 
> 
> /Lars-Erik
> 
> _______________________________________________
> 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: Fri, 10 Oct 2003 14:12:29 +0200

Thanks, responses below...

/L-E

> From: West, Mark [mailto:[email-masked]]
> Sent: den 10 oktober 2003 13:07
> To: Lars-Erik Jonsson (LU/EAB); [email-masked]'
> Subject: RE: [rohc] WG last-call for the IP-only profile
> 
> The removal of UDP has *no* impact..?  You don't have to 
> worry about whether or not to include the UDP checksum..?!

There is no impact in principle, but you are correct that
there are differences. I will adjust the text.

> [RFC-3095, section 5.7.5.] can only carry the 'Outer' IP header," I
> assume that this really means that Ext-3 can only carry a *single* 
> 'outer' header (since it clearly also encodes the 'inner' header...)

YES, I will fix that!

> The wording seems to be a little confused in the two paragraphs
> starting, 'For the compression profiles defined in...'  Initially
> it states that, 'at most two levels of IP headers can be compressed.'
> Which is fine.  It then states that additional headers, 'at best
> partially disables header compression...' which is not a terribly
> clear statement.  However, the following paragraph states that,
'[f]or the compression of IP  heades only, the additional IP headers
> would however not have to cause header compression to be disbaled...'
> except that it previously talks about 'partial' disablement.  It's
> clear what is *meant*, but perhaps it  could be phrased a bit more
> cleanly..?

Agree, let's be clearer with what we mean with "at best partially
disables", then the latter part should not be so confusing. I'll
replace the current sentence with:
  "In other words, the presence of additional IP headers at best
  partially disables header compression as the compressor will
  only be allowed to send IR and IR-DYN packets in such case."

> discussion on this point!  Clearly 'arbitrary' has an upper bound
> based on the MTU, but is this generally agreed?  (Having now got
> further through the document, I assume that S3.7. on the
> CONTEXT_MEMORY feedback option is considered to address this issue?)

Yes, that was what I proposed without hearing any disagreements.