From exim@www1.ietf.org  Wed Oct  1 04:14:27 2003
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 EAA02444
	for <rohc-archive@odin.ietf.org>; Wed, 1 Oct 2003 04:14:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4c7X-0008Lz-QK
	for rohc-archive@odin.ietf.org; Wed, 01 Oct 2003 04:14:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h918E3gc032099
	for rohc-archive@odin.ietf.org; Wed, 1 Oct 2003 04:14:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4c7X-0008Le-Bl
	for rohc-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 04:14:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02437
	for <rohc-web-archive@ietf.org>; Wed, 1 Oct 2003 04:13:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4c7U-0003nG-00
	for rohc-web-archive@ietf.org; Wed, 01 Oct 2003 04:14:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4c7U-0003nD-00
	for rohc-web-archive@ietf.org; Wed, 01 Oct 2003 04:14:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4c7V-0008LG-Ol; Wed, 01 Oct 2003 04:14:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A4c5S-0008Eo-UY
	for rohc@optimus.ietf.org; Wed, 01 Oct 2003 04:11:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02389
	for <rohc@ietf.org>; Wed, 1 Oct 2003 04:11:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4c5Q-0003ll-00
	for rohc@ietf.org; Wed, 01 Oct 2003 04:11:52 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A4c5P-0003li-00
	for rohc@ietf.org; Wed, 01 Oct 2003 04:11:51 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h918BoN1005055;
	Wed, 1 Oct 2003 10:11:50 +0200 (MEST)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <T6YNDSVY>; Wed, 1 Oct 2003 10:14:42 +0200
Message-ID: <A943FD84BD9ED41193460008C791805006FC41AA@ESEALNT419.al.sw.ericsson.se>
From: "Jan Christoffersson (LU/EAB)" <jan.christoffersson@ericsson.com>
To: "'Robert.Sugar@nokia.com'" <Robert.Sugar@nokia.com>, rohc@ietf.org
Cc: attila.czira@nokia.com
Subject: RE: [rohc] Question on state retention priority
Date: Wed, 1 Oct 2003 10:11:43 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Robert,

see comments inline.

BR,
Jan

-----Original Message-----
From: Robert.Sugar@nokia.com [mailto:Robert.Sugar@nokia.com]
Sent: den 30 september 2003 12:45
To: rohc@ietf.org
Cc: attila.czira@nokia.com
Subject: [rohc] Question on state retention priority


Hi ROHCers,

 During implementation we bumped into the following problem:

 If the user wants to save an already saved state with a different state retention priority, what should the state handler do?

According to the RFC:

      If the state creation request contains a state_identifier that
      already exists then the state handler checks whether the requested
      state item is identical to the established state item and counts
      the state creation request as successful if this is the case.  If
      not then the state creation request is unsuccessful (although the
      probability that this will occur is vanishingly small). 

IMHO, possible options are:

1. State save successful with the new retention priority
2. State save successful leaving the old retention priority
3. State save unsuccessful

What do you think?
[JC] I clearly think that (1) is the right thing to do. Leaving the old retention priority (as in (2)) seems strange as changing the priority is probably the reason for the state save. To count the state creation request as unsuccessful (3) definitely is against the RFC since the state item is identical!
I think that the RFC3320 is not really clear enough on this issue. To me it seems to leave room for different interpretations which is not a good thing. Once this question is settled I think it should be documented in the Implementers guide.

 Another question: What if a user saves a state that already exist as a locally available state? Should this count against the SMS?
[JC] Since the state is saved in the state memory, it should count against the SMS.


BR,
Robert



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

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



From exim@www1.ietf.org  Fri Oct  3 15:35:33 2003
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 PAA23266
	for <rohc-archive@odin.ietf.org>; Fri, 3 Oct 2003 15:35:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Vhm-0007Yh-Mv
	for rohc-archive@odin.ietf.org; Fri, 03 Oct 2003 15:35:11 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h93JZAVv029051
	for rohc-archive@odin.ietf.org; Fri, 3 Oct 2003 15:35:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Vhm-0007YU-EJ
	for rohc-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 15:35:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23222
	for <rohc-web-archive@ietf.org>; Fri, 3 Oct 2003 15:35:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5Vhj-0005PV-00
	for rohc-web-archive@ietf.org; Fri, 03 Oct 2003 15:35:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5Vhj-0005PR-00
	for rohc-web-archive@ietf.org; Fri, 03 Oct 2003 15:35:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5Vhe-0007Y3-DT; Fri, 03 Oct 2003 15:35:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A5VhX-0007Xg-Ro
	for rohc@optimus.ietf.org; Fri, 03 Oct 2003 15:34:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23209
	for <rohc@ietf.org>; Fri, 3 Oct 2003 15:34:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5VhW-0005PH-00
	for rohc@ietf.org; Fri, 03 Oct 2003 15:34:54 -0400
Received: from ns1.research.bell-labs.com ([204.178.16.6] helo=dirty.research.bell-labs.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A5VhV-0005PE-00
	for rohc@ietf.org; Fri, 03 Oct 2003 15:34:53 -0400
Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9])
	by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id h93JYrkE029754
	for <rohc@ietf.org>; Fri, 3 Oct 2003 15:34:53 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h93JYkJl087322
	for <rohc@ietf.org>; Fri, 3 Oct 2003 15:34:46 -0400 (EDT)
Received: from lucent.com (norden-1 [135.180.240.187])
	by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h93JYjFU024701
	for <rohc@ietf.org>; Fri, 3 Oct 2003 15:34:45 -0400 (EDT)
Message-ID: <3F7DCF55.23D98085@lucent.com>
Date: Fri, 03 Oct 2003 15:34:45 -0400
From: Samphel Norden <norden@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD NSCPCD476  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rohc@ietf.org
Content-Type: multipart/mixed;
 boundary="------------C360151B685073CF90566954"
Subject: [rohc] ROHC over tunnels with security
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.
--------------C360151B685073CF90566954
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,
    This is regarding a topic that may have been discussed earlier.
Basically, I want to know if there is any on-going work that seeks to
adapt ROHC to be used over IPSec. Since an IPSec tunnel can be
considered as a virtual link, it is possible to consider using ROHC over
it.

However, there are problems using ROHC with IPSec, namely the inability
to compress the AH+ESP headers since compression of the inner header is
done before encryption.Another problem being the reordering that is not
tolerated by ROHC but is a possible by-product of using a tunnel. There
are a few other combinations apart from ROHC over IPSec:

- IPComp over IPSec
- SRTP with ROHC (specifically for Voice-over-IP)

To summarize, there seem to be the following issues:
1. Performance if ROHC is used over IPSec (due to header expansion)
2. Reordering if ROHC is used over tunnels (can also lead to potential
DoS attacks if malicious intermediate routers drop or delay packets to
cause reordering).
3. Also, is there any relevant benefit of using either of the
aforementioned alternative combinations (IPComp, SRTP) in practice?

I wanted to know if these issues have been looked at in a draft(s) and
whether they matter at all in current implementations?

-Samphel



--------------C360151B685073CF90566954
Content-Type: text/x-vcard; charset=us-ascii;
 name="norden.vcf"
Content-Description: Card for Samphel Norden
Content-Disposition: attachment;
 filename="norden.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Norden;Samphel
tel;cell:(314)-662-1792
tel;home:(732)-935-3598
tel;work:(732)-332-6744
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:norden@dnrc.bell-labs.com
fn:Samphel Norden
end:vcard

--------------C360151B685073CF90566954--


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



From exim@www1.ietf.org  Mon Oct  6 03:38:31 2003
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 DAA20714
	for <rohc-archive@odin.ietf.org>; Mon, 6 Oct 2003 03:38:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6PwX-0001Vp-7K
	for rohc-archive@odin.ietf.org; Mon, 06 Oct 2003 03:38:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h967c8nP005809
	for rohc-archive@odin.ietf.org; Mon, 6 Oct 2003 03:38:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6PwT-0001VU-Bh
	for rohc-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 03:38:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20702
	for <rohc-web-archive@ietf.org>; Mon, 6 Oct 2003 03:37:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6PwQ-0001wB-00
	for rohc-web-archive@ietf.org; Mon, 06 Oct 2003 03:38:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6PwQ-0001w6-00
	for rohc-web-archive@ietf.org; Mon, 06 Oct 2003 03:38:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6PwP-0001Uq-Vw; Mon, 06 Oct 2003 03:38:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6Pvw-0001P2-0l
	for rohc@optimus.ietf.org; Mon, 06 Oct 2003 03:37:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20662
	for <rohc@ietf.org>; Mon, 6 Oct 2003 03:37:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6Pvt-0001vY-00
	for rohc@ietf.org; Mon, 06 Oct 2003 03:37:29 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6Pvs-0001vP-00
	for rohc@ietf.org; Mon, 06 Oct 2003 03:37:28 -0400
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h967bGN1025902;
	Mon, 6 Oct 2003 09:37:16 +0200 (MEST)
Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id T6Y3LA8B; Mon, 6 Oct 2003 09:38:24 +0200
Message-ID: <3F811BA3.2040002@ericsson.com>
Date: Mon, 06 Oct 2003 09:37:07 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: rohc@ietf.org
CC: Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [rohc] [Fwd: [AVT] RE: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt]
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,

I would like to inform you in the ROHC WG about the requirements work 
being done in the AVT WG regarding header compression for multi-hop 
paths. Example of such multi-hop path is to do HC between MPLS network 
ingress to egress.

Please note that this work is in its requirements phase and no technical 
solution is yet selected.

Please direct any discussion on this topic to the AVT WG's mailing list 
(avt@ietf.org).

Best Regards

Magnus Westerlund
AVT co-chair

-------- Original Message --------
Subject: [AVT] RE: I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
Date: Tue, 30 Sep 2003 17:11:50 -0500
From: Ash, Gerald R (Jerry), ALABS <gash@att.com>
To: <avt@ietf.org>
CC: Ash, Gerald R (Jerry), ALABS <gash@att.com>,        GOODE, B (Bur), 
ALABS <bgoode@att.com>,        Hand, James C, ALABS <jameshand@att.com>, 
        Jim Hand <hand17@earthlink.net>, raymond zhang 
<zhangr@info.net>,        George Swallow <swallow@cisco.com>

All,

Please review the updated 01 version of the 'Requirements for VoIP 
Header Compression over Multiple-Hop Paths' 
http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt. 


The update is in response to the AVT proposed charter items, where these 
milestones have been tentatively added to the charter:

Nov 2003 Initial draft requirements for ECRTP over MPLS; discuss with 
MPLS WG
Mar 2004 Finish requirements for ECRTP over MPLS; re-charter for 
subsequent work

These are the main changes/updates from the 00 version:

1. Changed the terminology of 'end-to-end VoIP header compression' to 
'VoIP header compression from compressor to decompressor over 
multiple-hop paths'.  The 'end-to-end' terminology caused some confusion 
at IETF-57.
2. Expanded the introduction to be more descriptive of the problem and 
background.
3. Added Section 2 on 'scenarios'.
4. Added 'goals' to Section 3, and made the requirements more specific 
(e.g., added tentative performance requirements for delay, jitter and 
packet loss).
5. Put a brief summary of 'proposed solutions' in Appendix A (for 
convenience of the reader).

Please let us know your comments and suggestions.

Thanks,
Jerry Ash

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, September 30, 2003 3:38 PM
Cc: avt@ietf.org
Subject: [AVT] I-D ACTION:draft-ash-e2e-voip-hdr-comp-rqmts-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Requirements for VoIP Header Compression over
                           Multiple-Hop Paths
	Author(s)	: J. Ash et al.
	Filename	: draft-ash-e2e-voip-hdr-comp-rqmts-01.txt
	Pages		: 0
	Date		: 2003-9-30
	
VoIP typically uses the encapsulation voice/RTP/UDP/IP/.  When MPLS
labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels.  For an
MPLS VPN, the packet header is at least 48 bytes, while the voice
payload is often no more than 30 bytes.  VoIP header compression can
significantly reduce the VoIP overhead through various compression
mechanisms.  This is important on access links where bandwidth is
scarce, and can be important on backbone facilities, especially where
costs are high (e.g., some global cross-sections).  Providing VoIP
header compression over multiple hop paths avoids multiple
compression/decompression cycles at each router, and thereby increases
the processing scalability of the maximum number of simultaneous VoIP
flows which use header compression at each router.  This draft gives a
problem statement, example scenarios, goals, and requirements for VoIP
header compression from compressor to decompressor over multiple-hop
paths, possibly over MPLS.  It also discusses work items and issues for
consideration, and highlights various solution alternatives that have
been proposed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-01.txt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt



-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


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



From exim@www1.ietf.org  Mon Oct  6 05:52:22 2003
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 FAA23423
	for <rohc-archive@odin.ietf.org>; Mon, 6 Oct 2003 05:52:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6S26-00064h-KM
	for rohc-archive@odin.ietf.org; Mon, 06 Oct 2003 05:52:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h969q2Rt023352
	for rohc-archive@odin.ietf.org; Mon, 6 Oct 2003 05:52:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6S26-00064Z-Cl
	for rohc-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 05:52:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23417
	for <rohc-web-archive@ietf.org>; Mon, 6 Oct 2003 05:51:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6S22-00031H-00
	for rohc-web-archive@ietf.org; Mon, 06 Oct 2003 05:51:58 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6S22-00031E-00
	for rohc-web-archive@ietf.org; Mon, 06 Oct 2003 05:51:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6S24-00064F-PA; Mon, 06 Oct 2003 05:52:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A6S1G-00063d-23
	for rohc@optimus.ietf.org; Mon, 06 Oct 2003 05:51:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23414
	for <rohc@ietf.org>; Mon, 6 Oct 2003 05:50:59 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6S1C-000313-00
	for rohc@ietf.org; Mon, 06 Oct 2003 05:51:06 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A6S1B-00030h-00
	for rohc@ietf.org; Mon, 06 Oct 2003 05:51:05 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TNNBSCR2>; Mon, 6 Oct 2003 10:50:36 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A708B2F8F@rsys004a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'Jan Christoffersson (LU/EAB)'" <jan.christoffersson@ericsson.com>,
        "'Robert.Sugar@nokia.com'" <Robert.Sugar@nokia.com>, rohc@ietf.org
Cc: attila.czira@nokia.com
Subject: RE: [rohc] Question on state retention priority
Date: Mon, 6 Oct 2003 10:50:41 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Robert, Jan,

See comments inline.
> 
>  During implementation we bumped into the following problem:
> 
>  If the user wants to save an already saved state with a different state
> retention priority, what should the state handler do?
> 
> According to the RFC:
> 
>       If the state creation request contains a state_identifier that
>       already exists then the state handler checks whether the requested
>       state item is identical to the established state item and counts
>       the state creation request as successful if this is the case.  If
>       not then the state creation request is unsuccessful (although the
>       probability that this will occur is vanishingly small).
> 
> IMHO, possible options are:
> 
> 1. State save successful with the new retention priority
> 2. State save successful leaving the old retention priority
> 3. State save unsuccessful
> 
> What do you think?
> [JC] I clearly think that (1) is the right thing to do. Leaving the old
> retention priority (as in (2)) seems strange as changing the priority is
> probably the reason for the state save. To count the state creation
> request as unsuccessful (3) definitely is against the RFC since the state
> item is identical!

[AS] I agree with Jan that the retention priority should be the new one.  

There are two issues to clarify with regard to this issue: 

1) 	That the retention priority should be associated with the compartment.  I.E. if endpoint A creates a piece of state with retention priority 1 and endpoint B creates exactly the same state with retention priority 2, there should be one copy of the actual state but each compartment should keep its record of this piece of state with its own priority.  (If this did not happen then the state may be kept for longer than A anticipated or less time than B anticipated depending on which priority was used.)

2)	If the same piece of state is created within a compartment with a different priority, then one copy of it should be stored (with the new priority) and it should count only once against SMS.  (I believe this was the conclusion of a discussion a while ago, but was never documented.)

> I think that the RFC3320 is not really clear enough on this issue. To me
> it seems to leave room for different interpretations which is not a good
> thing. Once this question is settled I think it should be documented in
> the Implementers guide.
> 

Good idea.  Once we have agreement I will add a section to the implementers guide.

>  Another question: What if a user saves a state that already exist as a
> locally available state? Should this count against the SMS?
> [JC] Since the state is saved in the state memory, it should count against
> the SMS.
> 
[AS] Agreed.  Any request for state creation made by the compressor should count against SMS because the compressor will be expecting it to do so.  Otherwise compressor and decompressor could get out of sync.

Best regards,

Abbie
> 
> BR,
> Robert
> 
> 

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



From exim@www1.ietf.org  Wed Oct  8 05:26:29 2003
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 FAA07502
	for <rohc-archive@odin.ietf.org>; Wed, 8 Oct 2003 05:26:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Aa9-0001tY-6C
	for rohc-archive@odin.ietf.org; Wed, 08 Oct 2003 05:26:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h989Q9Ne007278
	for rohc-archive@odin.ietf.org; Wed, 8 Oct 2003 05:26:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Aa9-0001tJ-1M
	for rohc-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 05:26:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07468
	for <rohc-web-archive@ietf.org>; Wed, 8 Oct 2003 05:25:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Aa5-0002cM-00
	for rohc-web-archive@ietf.org; Wed, 08 Oct 2003 05:26:05 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Aa5-0002cI-00
	for rohc-web-archive@ietf.org; Wed, 08 Oct 2003 05:26:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Aa2-0001sn-EW; Wed, 08 Oct 2003 05:26:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7AZi-0001p8-4B
	for rohc@optimus.ietf.org; Wed, 08 Oct 2003 05:25:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07417
	for <rohc@ietf.org>; Wed, 8 Oct 2003 05:25:31 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7AZe-0002bq-00
	for rohc@ietf.org; Wed, 08 Oct 2003 05:25:38 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7AZd-0002bn-00
	for rohc@ietf.org; Wed, 08 Oct 2003 05:25:37 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h989Pcit012168
	for <rohc@ietf.org>; Wed, 8 Oct 2003 11:25:38 +0200 (MEST)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <43DLG5MX>; Wed, 8 Oct 2003 11:29:00 +0200
Message-ID: <A943FD84BD9ED41193460008C7918050072E92F2@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Date: Wed, 8 Oct 2003 11:25:29 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] ROHC @ IETF 58 ??
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

ROHCers,

It's time to decide whether we want to request agenda time
for ROHC at the Minneapolis meeting. If YOU think there are
questions that motivates a ROHC session in Minneapolis, 
please let us know as soon as possible (this week).

Thanks!
/L-E & Carsten


--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
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



From exim@www1.ietf.org  Thu Oct  9 07:19:29 2003
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 HAA15830
	for <rohc-archive@odin.ietf.org>; Thu, 9 Oct 2003 07:19:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Yoz-0005UQ-Gj
	for rohc-archive@odin.ietf.org; Thu, 09 Oct 2003 07:19:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99BJ5tq021077
	for rohc-archive@odin.ietf.org; Thu, 9 Oct 2003 07:19:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Yoz-0005Ta-8Z
	for rohc-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 07:19:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15815
	for <rohc-web-archive@ietf.org>; Thu, 9 Oct 2003 07:18:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Yoy-0005BM-00
	for rohc-web-archive@ietf.org; Thu, 09 Oct 2003 07:19:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Yoy-0005BI-00
	for rohc-web-archive@ietf.org; Thu, 09 Oct 2003 07:19:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7You-0005S9-Ot; Thu, 09 Oct 2003 07:19:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7Yo5-0005QQ-HG
	for rohc@optimus.ietf.org; Thu, 09 Oct 2003 07:18:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15778
	for <rohc@ietf.org>; Thu, 9 Oct 2003 07:18:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Yo4-0005AN-00
	for rohc@ietf.org; Thu, 09 Oct 2003 07:18:08 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7Yo4-0005AH-00
	for rohc@ietf.org; Thu, 09 Oct 2003 07:18:08 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h99BI6lN025669;
	Thu, 9 Oct 2003 13:18:06 +0200 (MEST)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <43DLR0SA>; Thu, 9 Oct 2003 13:21:32 +0200
Message-ID: <A943FD84BD9ED41193460008C7918050072E92FD@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: "'Remi Pelland'" <remi.pelland@octasic.com>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>
Subject: RE: [rohc] Questions on compressed lists.
Date: Thu, 9 Oct 2003 13:17:54 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Some answers inline...

> -----Original Message-----
> From: Remi Pelland [mailto:remi.pelland@octasic.com]
> Sent: den 26 september 2003 22:54
> To: 'rohc@ietf.org'
> Subject: [rohc] Questions on compressed lists.
> 
> 
> Hi,
> 
> RFC-3095, section 5.8.6 says that: "... In CSRC lists, the 
> items are CSRC identifiers; in header lists, they are
> uncompressed or compressed headers, as described in 5.8.4.2-4".
> 
> I'm not clear on the "uncompressed or compressed headers" for 
> IP extension headers.  Does this mean that for a given extension
> header type, the associated list "item" may have two different
> formats: compressed or uncompressed?  If this is the case, how
> does a decompressor know when the received items are compressed
> or not?

If it is present (X=1), it is included in its uncompressed form,
otherwise it is not present or in some cases compressed (only SN
and/or AH-data/GRE-chksum).


> The implementer's guide, section 5.4 says that the translation
> table should be updated when a UO-1-ID packet carrying a list
> with "Encoding Type 0" is received.  Shouldn't this also apply
> when new items are received in lists using encoding types 1 and 3?

Impl-guide 5.4 says:
    This section describes the situation when a UO-1-ID packet
    carries a compressed list.  Compressed lists are encoded using
    Encoding Type 0 (section 5.7.5 and 5.8.6.1) and every list may
    have a unique identifier (gen_id).

I.e., the case you mention should not happen.

/L-E

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



From exim@www1.ietf.org  Thu Oct  9 10:11:29 2003
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 KAA21251
	for <rohc-archive@odin.ietf.org>; Thu, 9 Oct 2003 10:11:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7bVP-00062B-Ji
	for rohc-archive@odin.ietf.org; Thu, 09 Oct 2003 10:11:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99EB3KT023189
	for rohc-archive@odin.ietf.org; Thu, 9 Oct 2003 10:11:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7bVP-00061w-G2
	for rohc-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 10:11:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21150
	for <rohc-web-archive@ietf.org>; Thu, 9 Oct 2003 10:10:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7bVN-0006nw-00
	for rohc-web-archive@ietf.org; Thu, 09 Oct 2003 10:11:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7bVM-0006nt-00
	for rohc-web-archive@ietf.org; Thu, 09 Oct 2003 10:11:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7bVL-00061Q-Pd; Thu, 09 Oct 2003 10:10:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7bUt-0005vu-Ur
	for rohc@optimus.ietf.org; Thu, 09 Oct 2003 10:10:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21086
	for <rohc@ietf.org>; Thu, 9 Oct 2003 10:10:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7bUp-0006nB-00
	for rohc@ietf.org; Thu, 09 Oct 2003 10:10:27 -0400
Received: from exchsvr.octasic.com ([216.208.79.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7bUj-0006my-00
	for rohc@ietf.org; Thu, 09 Oct 2003 10:10:21 -0400
Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19)
	id <TFX4YMW1>; Thu, 9 Oct 2003 10:05:39 -0400
Message-ID: <F54085DA4E90D511B80B00B0D0D007D26BA812@exchsvr.octasic.com>
From: Remi Pelland <remi.pelland@octasic.com>
To: "'Lars-Erik Jonsson (LU/EAB)'" <lars-erik.jonsson@ericsson.com>
Cc: "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] Questions on compressed lists.
Date: Thu, 9 Oct 2003 10:05:39 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


Lars-Erik,

Thanks for your answers.  Please see [RP] inline, I still have some
questions about this.

Thanks,
R=E9mi.

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) =
[mailto:lars-erik.jonsson@ericsson.com]
Sent: Thursday, October 09, 2003 7:18 AM
To: 'Remi Pelland'; 'rohc@ietf.org'
Subject: RE: [rohc] Questions on compressed lists.


Some answers inline...

> -----Original Message-----
> From: Remi Pelland [mailto:remi.pelland@octasic.com]
> Sent: den 26 september 2003 22:54
> To: 'rohc@ietf.org'
> Subject: [rohc] Questions on compressed lists.
>=20
>=20
> Hi,
>=20
> RFC-3095, section 5.8.6 says that: "... In CSRC lists, the=20
> items are CSRC identifiers; in header lists, they are
> uncompressed or compressed headers, as described in 5.8.4.2-4".
>=20
> I'm not clear on the "uncompressed or compressed headers" for=20
> IP extension headers.  Does this mean that for a given extension
> header type, the associated list "item" may have two different
> formats: compressed or uncompressed?  If this is the case, how
> does a decompressor know when the received items are compressed
> or not?

If it is present (X=3D1), it is included in its uncompressed form,
otherwise it is not present or in some cases compressed (only SN
and/or AH-data/GRE-chksum).

[RP] In the case where X=3D0 and the items are sent compressed, these
compressed values are not part of the "item 1, ..., item n" described =
in
sections 5.8.6.1-4. Right?  (My confusion originates from the fact that
section 5.8.6 gives the details of the compressed list formats and what =
they
each can include.  The sentence above seemed to imply that "item x"
associated with one of the XIs in the list may be compressed or
uncompressed.)

> The implementer's guide, section 5.4 says that the translation
> table should be updated when a UO-1-ID packet carrying a list
> with "Encoding Type 0" is received.  Shouldn't this also apply
> when new items are received in lists using encoding types 1 and 3?

Impl-guide 5.4 says:
    This section describes the situation when a UO-1-ID packet
    carries a compressed list.  Compressed lists are encoded using
    Encoding Type 0 (section 5.7.5 and 5.8.6.1) and every list may
    have a unique identifier (gen_id).

I.e., the case you mention should not happen.

[RP] I must have missed something, because I don't understand why this
situation could not happen.  Could you please elaborate?  Thanks.

/L-E

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



From exim@www1.ietf.org  Thu Oct  9 10:21:24 2003
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 KAA22201
	for <rohc-archive@odin.ietf.org>; Thu, 9 Oct 2003 10:21:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7bf5-0006Ub-84
	for rohc-archive@odin.ietf.org; Thu, 09 Oct 2003 10:21:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h99EL3DS024953
	for rohc-archive@odin.ietf.org; Thu, 9 Oct 2003 10:21:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7bf5-0006UO-1a
	for rohc-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 10:21:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22194
	for <rohc-web-archive@ietf.org>; Thu, 9 Oct 2003 10:20:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7bf2-0006w0-00
	for rohc-web-archive@ietf.org; Thu, 09 Oct 2003 10:21:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7bf2-0006vx-00
	for rohc-web-archive@ietf.org; Thu, 09 Oct 2003 10:21:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7bf2-0006U5-Ku; Thu, 09 Oct 2003 10:21:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7aPb-0001gT-LT
	for rohc@optimus.ietf.org; Thu, 09 Oct 2003 09:00:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18125
	for <rohc@ietf.org>; Thu, 9 Oct 2003 09:00:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7aPa-00060v-00
	for rohc@ietf.org; Thu, 09 Oct 2003 09:00:58 -0400
Received: from dukas.upc.es ([147.83.2.62])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7aPY-00060s-00
	for rohc@ietf.org; Thu, 09 Oct 2003 09:00:57 -0400
Received: from mat.upc.es (mat.upc.es [147.83.39.3])
	by dukas.upc.es (8.12.1-20030925/8.12.1) with ESMTP id h99D0fvE000235
	for <rohc@ietf.org>; Thu, 9 Oct 2003 15:00:41 +0200 (MET DST)
Received: from localhost (localhost [127.0.0.1])
	by mat.upc.es (Postfix) with ESMTP id 9F80DDE8B
	for <rohc@ietf.org>; Thu,  9 Oct 2003 14:59:35 +0200 (MET DST)
Received: from BRUCE75 (bruce75.upc.es [147.83.113.141])
	by mat.upc.es (Postfix) with SMTP id 7E883DE84
	for <rohc@ietf.org>; Thu,  9 Oct 2003 14:59:31 +0200 (MET DST)
From: "David Viamonte" <viamonte@mat.upc.es>
To: <rohc@ietf.org>
Date: Thu, 9 Oct 2003 14:56:58 +0200
Message-ID: <KOELLPEJDMAOCIINGABBGEHLCCAA.viamonte@entel.upc.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 7bit
Subject: [rohc] SigComp Implementation availabilty
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi,
I've been following ROHC and SigComp efforts for some time now, but just
recently joined the mailing list. I say so because I don't really know if
this is an already answered or recursive question. In any case:

Is there any available SigComp implementation for research/academic
purposes? If someone can bring a little bit of light on this, it would be
great.

Thanks in advance,

David Viamonte

Associate Professor
Telematics Department
Technical University of Catalonia (UPC)


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



From exim@www1.ietf.org  Fri Oct 10 03:16:59 2003
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 DAA12083
	for <rohc-archive@odin.ietf.org>; Fri, 10 Oct 2003 03:16:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7rVq-0003B0-0r
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 03:16:36 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A7GXIp012203
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 03:16:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7rVp-0003AZ-Ie
	for rohc-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 03:16:33 -0400
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 DAA12021
	for <rohc-web-archive@ietf.org>; Fri, 10 Oct 2003 03:16:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7rVJ-00031T-4F; Fri, 10 Oct 2003 03:16:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7rV8-00030p-Ny
	for rohc@optimus.ietf.org; Fri, 10 Oct 2003 03:15:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11886
	for <rohc@ietf.org>; Fri, 10 Oct 2003 03:15:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7rV6-00037Z-00
	for rohc@ietf.org; Fri, 10 Oct 2003 03:15:48 -0400
Received: from [194.237.235.30] (helo=effnet.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7rV5-00035h-00
	for rohc@ietf.org; Fri, 10 Oct 2003 03:15:47 -0400
Received: from effnet.com (c-377871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.55])
	(authenticated bits=0)
	by effnet.com (8.12.3/8.12.3) with ESMTP id h9A6F6av022781
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 10 Oct 2003 08:15:07 +0200
Message-ID: <3F865C85.3000500@effnet.com>
Date: Fri, 10 Oct 2003 09:15:17 +0200
From: Kristofer Sandlund <kristofer.sandlund@effnet.com>
Organization: Effnet
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030821
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Remi Pelland <remi.pelland@octasic.com>
CC: "'Lars-Erik Jonsson (LU/EAB)'" <lars-erik.jonsson@ericsson.com>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Subject: Re: [rohc] Questions on compressed lists.
References: <F54085DA4E90D511B80B00B0D0D007D26BA812@exchsvr.octasic.com>
In-Reply-To: <F54085DA4E90D511B80B00B0D0D007D26BA812@exchsvr.octasic.com>
X-Enigmail-Version: 0.76.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by effnet.com id h9A6F6av022781
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi Remi,

answers inlined.

/Kristofer Sandlund, Effnet AB

Remi Pelland wrote:
> Lars-Erik,
>=20
> Thanks for your answers.  Please see [RP] inline, I still have some
> questions about this.
>=20
> Thanks,
> R=E9mi.
>=20
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com=
]
> Sent: Thursday, October 09, 2003 7:18 AM
> To: 'Remi Pelland'; 'rohc@ietf.org'
> Subject: RE: [rohc] Questions on compressed lists.
>=20
>=20
> Some answers inline...
>=20
>=20
>>-----Original Message-----
>>From: Remi Pelland [mailto:remi.pelland@octasic.com]
>>Sent: den 26 september 2003 22:54
>>To: 'rohc@ietf.org'
>>Subject: [rohc] Questions on compressed lists.
>>
>>
>>Hi,
>>
>>RFC-3095, section 5.8.6 says that: "... In CSRC lists, the=20
>>items are CSRC identifiers; in header lists, they are
>>uncompressed or compressed headers, as described in 5.8.4.2-4".
>>
>>I'm not clear on the "uncompressed or compressed headers" for=20
>>IP extension headers.  Does this mean that for a given extension
>>header type, the associated list "item" may have two different
>>formats: compressed or uncompressed?  If this is the case, how
>>does a decompressor know when the received items are compressed
>>or not?
>=20
>=20
> If it is present (X=3D1), it is included in its uncompressed form,
> otherwise it is not present or in some cases compressed (only SN
> and/or AH-data/GRE-chksum).
>=20
> [RP] In the case where X=3D0 and the items are sent compressed, these
> compressed values are not part of the "item 1, ..., item n" described i=
n
> sections 5.8.6.1-4. Right?  (My confusion originates from the fact that
> section 5.8.6 gives the details of the compressed list formats and what=
 they
> each can include.  The sentence above seemed to imply that "item x"
> associated with one of the XIs in the list may be compressed or
> uncompressed.)
>=20

The quote you give from 5.8.6, says that the compressed/uncompressed item=
s are=20
described in 5.8.4.2-4.
Here's an example from 3095 describing uncompressed/compressed item for t=
he ESP=20
NULL header (section 5.8.4.3).

 >   The information which is part of an uncompressed item of a compresse=
d
 >   list is the Next Header field, followed by the SPI and the Sequence
 >   Number.  Padding, Pad Length, Next Header, and Authentication Data
 >   are sent as-is at the end of the packet.  This means that the Next
 >   Header occurs in two places.

<snip>

 >   A compressed item consists of a compressed sequence number.  When an
 >   item is compressed, Padding (if it follows the 1, 2, ..., k pattern)
 >   and Next Header are removed near the end of the packet.
 >   Authentication Data and Pad Length remain as-is near the end of the
 >   packet.

The sequence number is naturally inside the extension 3 sequence number f=
ields=20
(5.8.5.1). So, therefore no fields are inside the compressed list. Simila=
r can=20
be read in the other sections mentioned above.

I can agree that there could be a "better" explanation of this that cover=
s all=20
headers, but I think there's only one possible interpretation of the curr=
ent=20
text. L-E could possibly add an explanation to the implementer's guide?


>=20
>>The implementer's guide, section 5.4 says that the translation
>>table should be updated when a UO-1-ID packet carrying a list
>>with "Encoding Type 0" is received.  Shouldn't this also apply
>>when new items are received in lists using encoding types 1 and 3?
>=20
>=20
> Impl-guide 5.4 says:
>     This section describes the situation when a UO-1-ID packet
>     carries a compressed list.  Compressed lists are encoded using
>     Encoding Type 0 (section 5.7.5 and 5.8.6.1) and every list may
>     have a unique identifier (gen_id).
>=20
> I.e., the case you mention should not happen.
>=20
> [RP] I must have missed something, because I don't understand why this
> situation could not happen.  Could you please elaborate?  Thanks.
>=20

The text above from the implementer's guide says that "Compressed lists a=
re=20
encoded using Encoding Type 0", i.e. you must use the Generic scheme. The=
refore=20
it is not legal for the compressor to send type 1,2,3 lists inside a=20
UO-1-ID-packet. So if your decompressor sees a UO-1-ID with types 1 or 3,=
 it is=20
a bad packet and should not update your translation table.

Hope this helps.

> /L-E
>=20
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc


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



From exim@www1.ietf.org  Fri Oct 10 07:08:29 2003
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 HAA19699
	for <rohc-archive@odin.ietf.org>; Fri, 10 Oct 2003 07:08:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7v7w-0001h9-Jy
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 07:08:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AB887s006509
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 07:08:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7v7w-0001gu-5C
	for rohc-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 07:08:08 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19645
	for <rohc-web-archive@ietf.org>; Fri, 10 Oct 2003 07:07:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7v7r-0007kJ-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 07:08:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7v7r-0007kF-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 07:08:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7v7u-0001g6-Ii; Fri, 10 Oct 2003 07:08:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7v7f-0001bp-Ie
	for rohc@optimus.ietf.org; Fri, 10 Oct 2003 07:07:51 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19636
	for <rohc@ietf.org>; Fri, 10 Oct 2003 07:07:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7v7b-0007jP-00
	for rohc@ietf.org; Fri, 10 Oct 2003 07:07:47 -0400
Received: from rsys001a.roke.co.uk ([193.118.192.110])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7v7a-0007hd-00
	for rohc@ietf.org; Fri, 10 Oct 2003 07:07:46 -0400
Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TVH1T4GZ>; Fri, 10 Oct 2003 12:07:14 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A70A1AC39@rsys004a.roke.co.uk>
From: "West, Mark" <mark.a.west@roke.co.uk>
To: "'Lars-Erik Jonsson (LU/EAB)'" <lars-erik.jonsson@ericsson.com>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] WG last-call for the IP-only profile
Date: Fri, 10 Oct 2003 12:07:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>


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:lars-erik.jonsson@ericsson.com]
> Sent: 26 September 2003 10:27
> To: 'rohc@ietf.org'
> 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
> rohc@ietf.org 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
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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



From exim@www1.ietf.org  Fri Oct 10 08:13:32 2003
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 IAA23341
	for <rohc-archive@odin.ietf.org>; Fri, 10 Oct 2003 08:13:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7w8n-0006G3-OK
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 08:13:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ACD5HC024049
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 08:13:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7w8n-0006Fo-KA
	for rohc-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 08:13:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23301
	for <rohc-web-archive@ietf.org>; Fri, 10 Oct 2003 08:12:58 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7w8m-00020W-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 08:13:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7w8m-00020S-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 08:13:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7w8j-0006FS-7D; Fri, 10 Oct 2003 08:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7w8T-0006F1-T3
	for rohc@optimus.ietf.org; Fri, 10 Oct 2003 08:12:45 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23290
	for <rohc@ietf.org>; Fri, 10 Oct 2003 08:12:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7w8S-00020G-00
	for rohc@ietf.org; Fri, 10 Oct 2003 08:12:44 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7w8R-000207-00
	for rohc@ietf.org; Fri, 10 Oct 2003 08:12:44 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9ACCflN012895;
	Fri, 10 Oct 2003 14:12:42 +0200 (MEST)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <43DL7GYK>; Fri, 10 Oct 2003 14:16:13 +0200
Message-ID: <A943FD84BD9ED41193460008C7918050072E9306@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: "'West, Mark'" <mark.a.west@roke.co.uk>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>
Subject: RE: [rohc] WG last-call for the IP-only profile
Date: Fri, 10 Oct 2003 14:12:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Thanks, responses below...

/L-E


> -----Original Message-----
> From: West, Mark [mailto:mark.a.west@roke.co.uk]
> Sent: den 10 oktober 2003 13:07
> To: Lars-Erik Jonsson (LU/EAB); 'rohc@ietf.org'
> Subject: RE: [rohc] WG last-call for the IP-only profile
> 
> Herewith my comments on draft-ietf-rohc-ip-only-04.txt...
> 
> 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..?!

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


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

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


> 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?)

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

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



From exim@www1.ietf.org  Fri Oct 10 09:42:27 2003
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 JAA27863
	for <rohc-archive@odin.ietf.org>; Fri, 10 Oct 2003 09:42:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7xWu-0003c3-0f
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 09:42:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ADg3aQ013881
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 09:42:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7xWt-0003bo-TI
	for rohc-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 09:42:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27834
	for <rohc-web-archive@ietf.org>; Fri, 10 Oct 2003 09:41:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7xWq-0003bn-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 09:42:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7xWq-0003bk-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 09:42:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7xWr-0003bM-1d; Fri, 10 Oct 2003 09:42:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7xVv-0003Vm-1i
	for rohc@optimus.ietf.org; Fri, 10 Oct 2003 09:41:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27786
	for <rohc@ietf.org>; Fri, 10 Oct 2003 09:40:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7xVs-0003ag-00
	for rohc@ietf.org; Fri, 10 Oct 2003 09:41:00 -0400
Received: from exchsvr.octasic.com ([216.208.79.4])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7xVs-0003aY-00
	for rohc@ietf.org; Fri, 10 Oct 2003 09:41:00 -0400
Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19)
	id <TFX4YNNL>; Fri, 10 Oct 2003 09:36:53 -0400
Message-ID: <F54085DA4E90D511B80B00B0D0D007D26BA817@exchsvr.octasic.com>
From: Remi Pelland <remi.pelland@octasic.com>
To: "'Kristofer Sandlund'" <kristofer.sandlund@effnet.com>
Cc: "'Lars-Erik Jonsson (LU/EAB)'" <lars-erik.jonsson@ericsson.com>,
        "'rohc@ietf.org'" <rohc@ietf.org>
Subject: RE: [rohc] Questions on compressed lists.
Date: Fri, 10 Oct 2003 09:36:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable


Hi Kristofer,

Thanks for your answers, they did help.

For the "compressed/uncompressed" items in 5.8.6, like you I believe =
that
this is the only interpretation, but if you take the sentence litteraly
(like I did), it does raise some interrogations.  No more concerns on =
that.

As for IG section 5.4, I'm a little embarrassed to admit that I didn't
realize it was actually making a point of enforcing encoding type 0 for
lists included in UO-1-ID packets.  I know, it's clearly written down, =
but I
thought the first paragraph was simply providing a background for what =
is
following (i.e. translation table updates).  Sorry, my mistake.  I was =
only
focusing on the translation table updates explanation. =20

So now I get it finally, UO-1-ID packets can only carry generic lists.
Fine.  What's the motivation behind this?  Is there something in the
compressed list mechanism or in the UO-mode scheme that prevents from =
using
types 1, 2 and 3 with UO-1-ID? (For my own understanding, I'm not =
trying to
change anything at this point.)

Thanks again,
R=E9mi.


-----Original Message-----
From: Kristofer Sandlund [mailto:kristofer.sandlund@effnet.com]
Sent: Friday, October 10, 2003 3:15 AM
To: Remi Pelland
Cc: 'Lars-Erik Jonsson (LU/EAB)'; 'rohc@ietf.org'
Subject: Re: [rohc] Questions on compressed lists.


Hi Remi,

answers inlined.

/Kristofer Sandlund, Effnet AB

Remi Pelland wrote:
> Lars-Erik,
>=20
> Thanks for your answers.  Please see [RP] inline, I still have some
> questions about this.
>=20
> Thanks,
> R=E9mi.
>=20
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) =
[mailto:lars-erik.jonsson@ericsson.com]
> Sent: Thursday, October 09, 2003 7:18 AM
> To: 'Remi Pelland'; 'rohc@ietf.org'
> Subject: RE: [rohc] Questions on compressed lists.
>=20
>=20
> Some answers inline...
>=20
>=20
>>-----Original Message-----
>>From: Remi Pelland [mailto:remi.pelland@octasic.com]
>>Sent: den 26 september 2003 22:54
>>To: 'rohc@ietf.org'
>>Subject: [rohc] Questions on compressed lists.
>>
>>
>>Hi,
>>
>>RFC-3095, section 5.8.6 says that: "... In CSRC lists, the=20
>>items are CSRC identifiers; in header lists, they are
>>uncompressed or compressed headers, as described in 5.8.4.2-4".
>>
>>I'm not clear on the "uncompressed or compressed headers" for=20
>>IP extension headers.  Does this mean that for a given extension
>>header type, the associated list "item" may have two different
>>formats: compressed or uncompressed?  If this is the case, how
>>does a decompressor know when the received items are compressed
>>or not?
>=20
>=20
> If it is present (X=3D1), it is included in its uncompressed form,
> otherwise it is not present or in some cases compressed (only SN
> and/or AH-data/GRE-chksum).
>=20
> [RP] In the case where X=3D0 and the items are sent compressed, these
> compressed values are not part of the "item 1, ..., item n" described =
in
> sections 5.8.6.1-4. Right?  (My confusion originates from the fact =
that
> section 5.8.6 gives the details of the compressed list formats and =
what
they
> each can include.  The sentence above seemed to imply that "item x"
> associated with one of the XIs in the list may be compressed or
> uncompressed.)
>=20

The quote you give from 5.8.6, says that the compressed/uncompressed =
items
are=20
described in 5.8.4.2-4.
Here's an example from 3095 describing uncompressed/compressed item for =
the
ESP=20
NULL header (section 5.8.4.3).

 >   The information which is part of an uncompressed item of a =
compressed
 >   list is the Next Header field, followed by the SPI and the =
Sequence
 >   Number.  Padding, Pad Length, Next Header, and Authentication Data
 >   are sent as-is at the end of the packet.  This means that the Next
 >   Header occurs in two places.

<snip>

 >   A compressed item consists of a compressed sequence number.  When =
an
 >   item is compressed, Padding (if it follows the 1, 2, ..., k =
pattern)
 >   and Next Header are removed near the end of the packet.
 >   Authentication Data and Pad Length remain as-is near the end of =
the
 >   packet.

The sequence number is naturally inside the extension 3 sequence number
fields=20
(5.8.5.1). So, therefore no fields are inside the compressed list. =
Similar
can=20
be read in the other sections mentioned above.

I can agree that there could be a "better" explanation of this that =
covers
all=20
headers, but I think there's only one possible interpretation of the =
current

text. L-E could possibly add an explanation to the implementer's guide?


>=20
>>The implementer's guide, section 5.4 says that the translation
>>table should be updated when a UO-1-ID packet carrying a list
>>with "Encoding Type 0" is received.  Shouldn't this also apply
>>when new items are received in lists using encoding types 1 and 3?
>=20
>=20
> Impl-guide 5.4 says:
>     This section describes the situation when a UO-1-ID packet
>     carries a compressed list.  Compressed lists are encoded using
>     Encoding Type 0 (section 5.7.5 and 5.8.6.1) and every list may
>     have a unique identifier (gen_id).
>=20
> I.e., the case you mention should not happen.
>=20
> [RP] I must have missed something, because I don't understand why =
this
> situation could not happen.  Could you please elaborate?  Thanks.
>=20

The text above from the implementer's guide says that "Compressed lists =
are=20
encoded using Encoding Type 0", i.e. you must use the Generic scheme.
Therefore=20
it is not legal for the compressor to send type 1,2,3 lists inside a=20
UO-1-ID-packet. So if your decompressor sees a UO-1-ID with types 1 or =
3, it
is=20
a bad packet and should not update your translation table.

Hope this helps.

> /L-E
>=20
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc

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



From exim@www1.ietf.org  Fri Oct 10 10:36:23 2003
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 KAA00693
	for <rohc-archive@odin.ietf.org>; Fri, 10 Oct 2003 10:36:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7yN7-0006hP-Od
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 10:36:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AEa1b5025748
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 10:36:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7yN7-0006hD-Kv
	for rohc-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 10:36:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00663
	for <rohc-web-archive@ietf.org>; Fri, 10 Oct 2003 10:35:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7yN5-0004AO-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 10:35:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7yN5-0004AL-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 10:35:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7yN6-0006gv-7s; Fri, 10 Oct 2003 10:36:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A7yMM-0006c7-SG
	for rohc@optimus.ietf.org; Fri, 10 Oct 2003 10:35:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00611
	for <rohc@ietf.org>; Fri, 10 Oct 2003 10:35:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7yMK-00049b-00
	for rohc@ietf.org; Fri, 10 Oct 2003 10:35:12 -0400
Received: from rsys001a.roke.co.uk ([193.118.192.110])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A7yMJ-00048q-00
	for rohc@ietf.org; Fri, 10 Oct 2003 10:35:12 -0400
Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TVH1TVT4>; Fri, 10 Oct 2003 15:34:39 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A708B2FDE@rsys004a.roke.co.uk>
From: "Surtees, Abigail" <abigail.surtees@roke.co.uk>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Date: Fri, 10 Oct 2003 15:34:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Folks,

Here is the requested review of draft-ietf-rohc-sigcomp-sip-00.txt.  Some
comments are minor nits, others are larger issues that may require further
discussion.  

Issues for discussion:

Page 3: 
		Section 2.1

My gut feeling is that 8k seems rather large for DMS.  For TCP the size of
the message sent has no impact.  For UDP, following the SIP instruction that
a SIP message should not be within 200 bytes of the MTU the maximum size of
a SigComp message is 1272 (assuming a 1500 byte MTU).  The worst case is
that where C is really small and B and S are large.  So we have C + B + S <=
1272 with a worst case of B + S = 1272 and C = 0 because B and S count twice
(cannot quite be achieved but is useful to make the point).  So C + 2B + 2S
+ 128 = 2672 which with a DMS of 4k still leaves 1328 bytes for R. 

The other thing to take into consideration is whether there is any point in
mandating an 8K DMS but only a 2K SMS?  8K allows R to be large but then the
whole history cannot be stored because SMS is not big enough?

Your thoughts?

		Section 2.2

Mandating an SMS of 2k would prevent the use of SigComp with a stateless
proxy.  Is this necessary?  A SigComp endpoint may not assume that state
will be stored until it has had an advertisement of SMS.  However, it can
request it and ensure that it waits for an acknowledgement before using the
state.  Presence of an SMS of 2k does not ensure that the state will be
created, it just ensures that there is potential for creating state.
Consequently is there any need to mandate it?

An alternative may be to say that if SMS is going to be advertised, it
should be at least, for example, 4k.
This would then not preclude stateless SIP proxies from running with
SigComp.

Page 5:
		Section 3 cont.
Paragraph 1:	I agree with the editor's note.  The definition of
compartments and description of how long state can persist is complicated
and needs discussion and further work on the mailing list.


Minor nits:

Page 1:	
		Abstract:
I felt that this was not particularly clear, in particular, the use of the
word 'specifics' and the fact that there were references that were not
explained.

Suggested text:

"This document describes default parameters and definitions for use when
Signaling Compression (SigComp) is applied to the Session Initiation
Protocol (SIP).  Any implementation of SigComp for use with SIP must conform
to this document, in addition to SigComp and use of the SIP static
dictionary."

Page 2:
		Introduction:

Similar phraseology not clear in paragraph 2 and references aren't clear.  

Suggested text:

"This document binds ... SigComp).  Any SigComp implementation that is used
for the compression of SIP messages must conform to this document, as well
as to SigComp [RFC 3320] and must use the SIP static dictionary as specified
in [RFC 3485].

Note:  The mechanism for discovery of SigComp support at the SIP layer is
specified in [RFC 3486]."

		Section 2:
Paragraph 1, 3rd line "when receiving Sigcomp messages" - confuses rather
than clarifies.  IMHO the sentence makes sense without it.

Paragraph 1, last sentence "Scalability is ..." should be "Scalability was
..."

Page 3:
		Section 2.2
Paragraph 3, line 3 - "of whether it can" should be "of whether or not it
can"

Page 4:	
		Section 2.5
"Minimum value" doesn't make sense for the static dictionary.  Should be
"For ..." as in 2.4

		Section 3
Paragraph 4, line 3 - "However, the actual presentation", should be
"However, the actual representation".

Page 6:
		Section 4 cont.

Paragraph 2 - suggested addition to the end of the last sentence "and be
delimited by the use of 0xFFFF as described in [RFC 3320]."


Abbie Surtees
Engineer
Networks
Roke Manor Research Ltd
Old Salisbury Lane
Romsey, SO51 0ZN
Tel:   +44 (0) 1794 833131



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



From exim@www1.ietf.org  Fri Oct 10 12:28:25 2003
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 MAA05878
	for <rohc-archive@odin.ietf.org>; Fri, 10 Oct 2003 12:28:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A807X-0007Ss-Cs
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 12:28:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AGS3si028688
	for rohc-archive@odin.ietf.org; Fri, 10 Oct 2003 12:28:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A807X-0007Sd-7s
	for rohc-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 12:28:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05852
	for <rohc-web-archive@ietf.org>; Fri, 10 Oct 2003 12:27:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A807V-0005sI-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 12:28:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A807U-0005sF-00
	for rohc-web-archive@ietf.org; Fri, 10 Oct 2003 12:28:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A807V-0007Rn-8g; Fri, 10 Oct 2003 12:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A806f-0007Qt-Jm
	for rohc@optimus.ietf.org; Fri, 10 Oct 2003 12:27:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05833
	for <rohc@ietf.org>; Fri, 10 Oct 2003 12:27:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A806d-0005rn-00
	for rohc@ietf.org; Fri, 10 Oct 2003 12:27:07 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A806d-0005rj-00
	for rohc@ietf.org; Fri, 10 Oct 2003 12:27:07 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9AGR642011182
	for <rohc@ietf.org>; Fri, 10 Oct 2003 18:27:06 +0200 (MEST)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <43DL94T4>; Fri, 10 Oct 2003 18:30:37 +0200
Message-ID: <A943FD84BD9ED41193460008C7918050072E9308@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: "'rohc@ietf.org'" <rohc@ietf.org>
Date: Fri, 10 Oct 2003 18:26:51 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] CLOSED: WG last-call for the IP-only profile
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

The WG last-call has ended, and an updated draft has just been
submitted to address the minor issues identified. Many thanks
to Mark and Kristofer who, as committed document reviewers,
carefully checked the document.

BR
/L-E


> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> Sent: den 26 september 2003 11:27
> To: 'rohc@ietf.org'
> 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
> rohc@ietf.org 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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc



From exim@www1.ietf.org  Tue Oct 14 03:06:26 2003
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 DAA28280
	for <rohc-archive@odin.ietf.org>; Tue, 14 Oct 2003 03:06:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9JFt-0002Td-1M
	for rohc-archive@odin.ietf.org; Tue, 14 Oct 2003 03:06:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E765qT009518
	for rohc-archive@odin.ietf.org; Tue, 14 Oct 2003 03:06:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9JFs-0002TR-Pt
	for rohc-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 03:06:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28260
	for <rohc-web-archive@ietf.org>; Tue, 14 Oct 2003 03:05:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9JFo-0006iO-00
	for rohc-web-archive@ietf.org; Tue, 14 Oct 2003 03:06:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9JFo-0006iK-00
	for rohc-web-archive@ietf.org; Tue, 14 Oct 2003 03:06:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9JFp-0002T3-5X; Tue, 14 Oct 2003 03:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A9JFh-0002SQ-Bi
	for rohc@optimus.ietf.org; Tue, 14 Oct 2003 03:05:54 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28211
	for <rohc@ietf.org>; Tue, 14 Oct 2003 03:05:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9JFd-0006i3-00
	for rohc@ietf.org; Tue, 14 Oct 2003 03:05:49 -0400
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A9JFc-0006i0-00
	for rohc@ietf.org; Tue, 14 Oct 2003 03:05:48 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9E75llN028915;
	Tue, 14 Oct 2003 09:05:47 +0200 (MEST)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <43DM7FQ2>; Tue, 14 Oct 2003 09:09:34 +0200
Message-ID: <A943FD84BD9ED41193460008C791805006FC41C8@ESEALNT419.al.sw.ericsson.se>
From: "Jan Christoffersson (LU/EAB)" <jan.christoffersson@ericsson.com>
To: "'Surtees, Abigail'" <abigail.surtees@roke.co.uk>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>
Subject: RE: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
Date: Tue, 14 Oct 2003 09:05:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Abbie,

I agree with you that a mandatory DMS of 8K seems to be unnecessarily large, 4K seems to be more suitable as mandatory requirement. We should not forget that it's always possible for an endpoint to offer more.

BR
Jan

-----Original Message-----
From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]
Sent: den 10 oktober 2003 16:35
To: 'rohc@ietf.org'
Subject: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt


Hi Folks,

Here is the requested review of draft-ietf-rohc-sigcomp-sip-00.txt.  Some
comments are minor nits, others are larger issues that may require further
discussion.  

Issues for discussion:

Page 3: 
		Section 2.1

My gut feeling is that 8k seems rather large for DMS.  For TCP the size of
the message sent has no impact.  For UDP, following the SIP instruction that
a SIP message should not be within 200 bytes of the MTU the maximum size of
a SigComp message is 1272 (assuming a 1500 byte MTU).  The worst case is
that where C is really small and B and S are large.  So we have C + B + S <=
1272 with a worst case of B + S = 1272 and C = 0 because B and S count twice
(cannot quite be achieved but is useful to make the point).  So C + 2B + 2S
+ 128 = 2672 which with a DMS of 4k still leaves 1328 bytes for R. 

The other thing to take into consideration is whether there is any point in
mandating an 8K DMS but only a 2K SMS?  8K allows R to be large but then the
whole history cannot be stored because SMS is not big enough?

Your thoughts?

		Section 2.2

Mandating an SMS of 2k would prevent the use of SigComp with a stateless
proxy.  Is this necessary?  A SigComp endpoint may not assume that state
will be stored until it has had an advertisement of SMS.  However, it can
request it and ensure that it waits for an acknowledgement before using the
state.  Presence of an SMS of 2k does not ensure that the state will be
created, it just ensures that there is potential for creating state.
Consequently is there any need to mandate it?

An alternative may be to say that if SMS is going to be advertised, it
should be at least, for example, 4k.
This would then not preclude stateless SIP proxies from running with
SigComp.

Page 5:
		Section 3 cont.
Paragraph 1:	I agree with the editor's note.  The definition of
compartments and description of how long state can persist is complicated
and needs discussion and further work on the mailing list.


Minor nits:

Page 1:	
		Abstract:
I felt that this was not particularly clear, in particular, the use of the
word 'specifics' and the fact that there were references that were not
explained.

Suggested text:

"This document describes default parameters and definitions for use when
Signaling Compression (SigComp) is applied to the Session Initiation
Protocol (SIP).  Any implementation of SigComp for use with SIP must conform
to this document, in addition to SigComp and use of the SIP static
dictionary."

Page 2:
		Introduction:

Similar phraseology not clear in paragraph 2 and references aren't clear.  

Suggested text:

"This document binds ... SigComp).  Any SigComp implementation that is used
for the compression of SIP messages must conform to this document, as well
as to SigComp [RFC 3320] and must use the SIP static dictionary as specified
in [RFC 3485].

Note:  The mechanism for discovery of SigComp support at the SIP layer is
specified in [RFC 3486]."

		Section 2:
Paragraph 1, 3rd line "when receiving Sigcomp messages" - confuses rather
than clarifies.  IMHO the sentence makes sense without it.

Paragraph 1, last sentence "Scalability is ..." should be "Scalability was
..."

Page 3:
		Section 2.2
Paragraph 3, line 3 - "of whether it can" should be "of whether or not it
can"

Page 4:	
		Section 2.5
"Minimum value" doesn't make sense for the static dictionary.  Should be
"For ..." as in 2.4

		Section 3
Paragraph 4, line 3 - "However, the actual presentation", should be
"However, the actual representation".

Page 6:
		Section 4 cont.

Paragraph 2 - suggested addition to the end of the last sentence "and be
delimited by the use of 0xFFFF as described in [RFC 3320]."


Abbie Surtees
Engineer
Networks
Roke Manor Research Ltd
Old Salisbury Lane
Romsey, SO51 0ZN
Tel:   +44 (0) 1794 833131



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

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



From exim@www1.ietf.org  Fri Oct 17 18:10:27 2003
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 SAA26891
	for <rohc-archive@odin.ietf.org>; Fri, 17 Oct 2003 18:10:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAcnP-0005zu-DC
	for rohc-archive@odin.ietf.org; Fri, 17 Oct 2003 18:10:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HMA7mY023050
	for rohc-archive@odin.ietf.org; Fri, 17 Oct 2003 18:10:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAcnP-0005zh-8r
	for rohc-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 18:10:07 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26858
	for <rohc-web-archive@ietf.org>; Fri, 17 Oct 2003 18:09:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAcnM-00029j-00
	for rohc-web-archive@ietf.org; Fri, 17 Oct 2003 18:10:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAcnL-00029f-00
	for rohc-web-archive@ietf.org; Fri, 17 Oct 2003 18:10:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAcnL-0005z1-Bn; Fri, 17 Oct 2003 18:10:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAcmx-0005yN-32
	for rohc@optimus.ietf.org; Fri, 17 Oct 2003 18:09:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26804
	for <rohc@ietf.org>; Fri, 17 Oct 2003 18:09:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAcmu-00029D-00
	for rohc@ietf.org; Fri, 17 Oct 2003 18:09:36 -0400
Received: from posti.netsonic.fi ([194.29.192.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAcmt-00028t-00
	for rohc@ietf.org; Fri, 17 Oct 2003 18:09:35 -0400
Received: from localhost.localdomain (jumbo133.adsl.netsonic.fi [81.17.197.133])
	by posti.netsonic.fi (Postfix) with ESMTP
	id 231B453D91; Sat, 18 Oct 2003 01:09:59 +0300 (EEST)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9HM9Rgt021254;
	Sat, 18 Oct 2003 01:09:27 +0300
Received: (from ppessi@localhost)
	by localhost.localdomain (8.12.8/8.12.5/Submit) id h9HM9OJr021253;
	Sat, 18 Oct 2003 01:09:24 +0300
X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f
To: rohc@ietf.org, adam@dynamicsoft.com
Cc: Pekka.Pessi@nokia.com
X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}<xZn_2^0)V{jqdc4y}@2b]ffd}SY#
 :9||1pew85O,WjiYA"6C7bW^zt^+.{b#B{lEE+4$9lrXL(55g}dU>uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
From: Pekka Pessi <Pekka.Pessi@nokia.com>
Message-ID: <pvu167g619.fsf@nokia.com>
Date: Sat, 18 Oct 2003 01:09:23 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [rohc] Comments to draft-roach-sigcomp-nack-01
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

I finally managed to do the review of draft-roach-sigcomp-nack-01.txt. 
I've divided my comments in technical issues, featuritis, nits and
spelling.

--Pekka

Technical issues:

	In the 2.2 last paragraph talks about destination address of
	NACK:

>>>For a connectionless transport, such as UDP, the NACK message is sent
>>>back to the originator of the failed message at the port and IP
>>>address from which the message was sent.  Note that this may or may
>>>not be the same port to which the appliation would typically receive
>>>messages.

	I'd also like to state that the NACK should be sent from the
	port and IP to which the original message was sent. This because
	the sender has most probably connect()ed the sending socket in
	order to catch ICMPs. So, when the original UDP message has

	(ip_p=UDP, ip_src=x, ip_dst=y, uh_sport=v, uh_dport=w)

	then the NACK should have

	(ip_p=UDP, ip_src=y, ip_dst=x, uh_sport=w, uh_dport=v)

	This also means that the socket used to receive SIGCOMP messages
	should not be bound to INADDR_ANY. Not to mention in6addr_any.

Comment to 3.2 Reason Codes:

	The set of reason codes seems to be rather complete. However,
	selecting reason code is not straightforward if the STATE-ACCESS
	has zero state-length but nonzero state-begin. INVALID_STATE_PROBE?

	What about errors mentioned by RFC 3320 section 8.7 item 7
	(RETURN_WITHOUT_CALL? POP_WITHOUT_PUSH? Or are these errors just
	ignored by current wisdom?)?

	When the initial bytecode state item exceeds the UDVM memory, it
	would be more informative get BYTECODES_TOO_LARGE instead of
	SEGFAULT. Also, if the initial bytecode state item has
	state_instruction outside UDVM memory INVALID_CODE_LOCATION
	would be more informative than SEGFAULT.

	Also, there is a security problem with ID_TOO_SHORT. If an
	attacker can guess the initial 6 bytes of a state identifier, he
	can quickly obtain the rest of the state ID with the help of
	ID_TOO_SHORT. With a message including the state contents in,
	for instance, a branch parameter of a SIP Via header, the
	attacker can then obtain the state contents from UDVM host. So,
	I'd recommend leaving out ID_TOO_SHORT. Instead of it,
	STATE_NOT_FOUND should be returned. Alternatively, mention
	ID_TOO_SHORT in "Security Considerations".

Featuritis:

	What about including PC and the byte code of the failed
	instruction in the NACK, like:

             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | 1   1   1   1   1 | T |   0   |
           +---+---+---+---+---+---+---+---+
           |                               |
           :    returned feedback item     :
           |                               |
           +---+---+---+---+---+---+---+---+
           |         code_len = 0          |
           +---+---+---+---+---+---+---+---+
           | code_len = 0  |  version = 1  |
           +---+---+---+---+---+---+---+---+
           |          Reason Code          |
           +---+---+---+---+---+---+---+---+
           |  OPCODE of failed instruction |
           +---+---+---+---+---+---+---+---+
           |  PC-HI of failed instruction  |
           +---+---+---+---+---+---+---+---+
           |  PC-LO of failed instruction  |
           +---+---+---+---+---+---+---+---+
           |                               |
           : SHA-1 Hash of failed message  :
           |                               |
           +---+---+---+---+---+---+---+---+
           |                               |
           :         Error Details         :
           |                               |
           +---+---+---+---+---+---+---+---+

                 Figure 1: SigComp NACK Message Format

Featuritis 2: INTERNAL_ERROR

"""
INTERNAL_ERROR

	UDVM encountered an unexpected condition that prevented it from
	decompressing the message.
"""

Featuritis 3: FRAMING_ERROR

"""
FRAMING_ERROR

	UDVM encountered a framing error (unquoted 0xFF 80 .. 0xFF FE in
	input stream.)
"""

Nits:

	The description of BAD_BITORDER is a bit misleading -
	input_bit_order is a 16-bit register, so I'd expect BAD_BITORDER
	if any one of the upper 13 is set. I'd also write it
	BAD_INPUT_BIT_ORDER.

	Spell out instructions in TOO_MANY_BITS_REQUESTED:

"""
        An INPUT-BITS or INPUT-HUFFMAN instruction was encountered that
	attempted to input more than 16 bits.
"""

Spelling:

	s/appliation/application/
	s/applcation/application/
	s/applicaition/application/
	s/reciever/receiver/
	s/beleives/believes/
	s/occured/occurred/
	s/retreive/retrieve/
	s/receipient/recipient/
	s/decompresson/decompression/
	s/futher/further/

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



From exim@www1.ietf.org  Fri Oct 17 18:58:21 2003
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 SAA28780
	for <rohc-archive@odin.ietf.org>; Fri, 17 Oct 2003 18:58:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAdXm-0007tZ-Mg
	for rohc-archive@odin.ietf.org; Fri, 17 Oct 2003 18:58:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HMw2De030343
	for rohc-archive@odin.ietf.org; Fri, 17 Oct 2003 18:58:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAdXm-0007tK-I1
	for rohc-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 18:58:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28765
	for <rohc-web-archive@ietf.org>; Fri, 17 Oct 2003 18:57:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAdXj-0002dW-00
	for rohc-web-archive@ietf.org; Fri, 17 Oct 2003 18:57:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAdXi-0002dT-00
	for rohc-web-archive@ietf.org; Fri, 17 Oct 2003 18:57:58 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAdXl-0007t2-5n; Fri, 17 Oct 2003 18:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AAdXF-0007oh-7N
	for rohc@optimus.ietf.org; Fri, 17 Oct 2003 18:57:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28755
	for <rohc@ietf.org>; Fri, 17 Oct 2003 18:57:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAdXB-0002dI-00
	for rohc@ietf.org; Fri, 17 Oct 2003 18:57:25 -0400
Received: from posti.netsonic.fi ([194.29.192.15])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AAdXB-0002dF-00
	for rohc@ietf.org; Fri, 17 Oct 2003 18:57:25 -0400
Received: from localhost.localdomain (jumbo133.adsl.netsonic.fi [81.17.197.133])
	by posti.netsonic.fi (Postfix) with ESMTP
	id 0887F53D7E; Sat, 18 Oct 2003 01:57:56 +0300 (EEST)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9HMvOgt021284;
	Sat, 18 Oct 2003 01:57:24 +0300
Received: (from ppessi@localhost)
	by localhost.localdomain (8.12.8/8.12.5/Submit) id h9HMvOQn021283;
	Sat, 18 Oct 2003 01:57:24 +0300
X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f
To: "'rohc@ietf.org'" <rohc@ietf.org>
Cc: Abigail Surtees <abigail.surtees@roke.co.uk>
Subject: Re: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}<xZn_2^0)V{jqdc4y}@2b]ffd}SY#
 :9||1pew85O,WjiYA"6C7bW^zt^+.{b#B{lEE+4$9lrXL(55g}dU>uZ\JfD\"IG#G{j`hZI;=DmT\H
 pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
From: Pekka Pessi <Pekka.Pessi@nokia.com>
In-Reply-To: <EA943CD30BCB104E9D38F5B5DC2D9A708B2FDE@rsys004a.roke.co.uk> (Surtees,
 Abigail's message of "Fri, 10 Oct 2003 15:34:39 +0100")
References: <EA943CD30BCB104E9D38F5B5DC2D9A708B2FDE@rsys004a.roke.co.uk>
Date: Sat, 18 Oct 2003 01:57:24 +0300
Message-ID: <pvllrjfp63.fsf@nokia.com>
User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter,
 i386-redhat-linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Surtees, Abigail <abigail.surtees@roke.co.uk> writes:
>My gut feeling is that 8k seems rather large for DMS.  For TCP the size of
>the message sent has no impact.  For UDP, following the SIP instruction that
>a SIP message should not be within 200 bytes of the MTU the maximum size of
>a SigComp message is 1272 (assuming a 1500 byte MTU).  

	The limitation is true for requests. However, responses can
	easily be greater than that, or even bigger than MTU.

>The worst case is that where C is really small and B and S are large. 
>So we have C + B + S <= 1272 with a worst case of B + S = 1272 and C =
>0 because B and S count twice (cannot quite be achieved but is useful
>to make the point). So C + 2B + 2S + 128 = 2672 which with a DMS of 4k
>still leaves 1328 bytes for R.

	Don't forget SIP dictionary (D), which can be 4832 bytes.

	If B + S = 1500, then C + 2B + R + 2S + 128 + D < DMS leaves us
	with R < DMS - 2B - 2S - C - D - 128 or R < 2932 bytes in case
	of DMS=8192. I can't agree that 4096 is plenty.

	But in any case I think DMS is cheap, as it's active only during
	decompression for UDP, and nothing compared to the socket
	buffers required by TCP.

>		Section 2.2

>Mandating an SMS of 2k would prevent the use of SigComp with a stateless
>proxy.  Is this necessary?  

	I don't see any reason why a stateless proxy cannot create
	state. It just don't keep transaction state.

>A SigComp endpoint may not assume that state
>will be stored until it has had an advertisement of SMS.  However, it can
>request it and ensure that it waits for an acknowledgement before using the
>state.  Presence of an SMS of 2k does not ensure that the state will be
>created, it just ensures that there is potential for creating state.
>Consequently is there any need to mandate it?

	I agree, 2k can be rather crowded.

....
>Paragraph 1:	I agree with the editor's note.  The definition of
>compartments and description of how long state can persist is complicated
>and needs discussion and further work on the mailing list.

	Definitely.
	
					Pekka

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



From exim@www1.ietf.org  Mon Oct 20 04:19:27 2003
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 EAA17249
	for <rohc-archive@odin.ietf.org>; Mon, 20 Oct 2003 04:19:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABVFp-0006Nd-PJ
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 04:19:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K8J58b024523
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 04:19:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABVFo-0006NS-T4
	for rohc-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 04:19:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17244
	for <rohc-web-archive@ietf.org>; Mon, 20 Oct 2003 04:18:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABVFl-0005bc-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 04:19:01 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABVFl-0005bY-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 04:19:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABVFl-0006Lr-9Z; Mon, 20 Oct 2003 04:19:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABVEw-0006EB-8Q
	for rohc@optimus.ietf.org; Mon, 20 Oct 2003 04:18:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17235
	for <rohc@ietf.org>; Mon, 20 Oct 2003 04:18:00 -0400 (EDT)
From: Robert.Sugar@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABVEt-0005bT-00
	for rohc@ietf.org; Mon, 20 Oct 2003 04:18:07 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABVEo-0005bK-00
	for rohc@ietf.org; Mon, 20 Oct 2003 04:18:02 -0400
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9K8HnX03128
	for <rohc@ietf.org>; Mon, 20 Oct 2003 11:17:49 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T65659fcf39ac158f24076@esvir04nok.ntc.nokia.com> for <rohc@ietf.org>;
 Mon, 20 Oct 2003 11:17:48 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Mon, 20 Oct 2003 11:17:48 +0300
Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Mon, 20 Oct 2003 11:17:47 +0300
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Mon, 20 Oct 2003 10:17:46 +0200
Message-ID: <21B200DF0688CC45ACF38F49D2279832013396C2@buebe002.europe.nokia.com>
Thread-Topic: Old issue (draft-ietf-rohc-sigcomp-sip-00.txt)
Thread-Index: AcOBzOJhSdl2dOv7QJWAuIgOKfShnQA/oQ3AABa7wnAASTGuYAItqSqgAFVg9lABlPPNwA==
To: <rohc@ietf.org>
X-OriginalArrivalTime: 20 Oct 2003 08:17:47.0929 (UTC) FILETIME=[A5768890:01C396E2]
Content-Transfer-Encoding: quoted-printable
Subject: [rohc] Old issue - multiplexing compressed and uncompressed messages in the same TCP connection -  long
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi all,

 You probably remember that discussion over $subject. As far as I can =
remember, conclusion was that although it could be implemented with a =
common transport layer, there is really no need to add the extra =
complexity.=20

RFC3486 has the following, reflecting that:
"If a SIP client sends a compressed request and the client transaction =
times out without having received any response, the client SHOULD retry =
the same request without using compression.  If the compressed request =
was sent over a TCP connection, the client SHOULD close that connection =
and open a new one to send the uncompressed request. Otherwise the =
server would not be able to detect the beginning of the new message."

So, why do we need compressed and uncompressed messages multiplexed in =
the first place?

1. Fallback to uncompressed mode (also suggested in RFC3486)
2. Large messages: OUTPUT instruction stops after 64Kbytes of data, so =
SIP messages larger than 64K are to be sent uncomperssed. This is not an =
impossible case, since SIP messages may carry arbitrary MIME =
attachments, such as XML (->presence info), WAV (->ringing tone), JPG =
(-> caller's photo), etc.
3. If there is no comp=3Dsigcomp URI to the proxy (proxy discovery =
usually yields only the IP address), initial messages are to be sent =
uncompressed, but subsequent messages could be sent compressed if =
comp=3Dsigcomp is inserted into the Record-Route by the proxy. If no =
comp=3Dsigcomp contact is given later, all initial requests will be sent =
uncompressed.
4. RFC3486 allows inserting comp=3Dsigcomp into SIP headers anytime. =
Preference for insertion might be for example the load of the proxy. If =
there are parallel sessions in the same compartment, at least one =
compressed and one uncompressed, TCP connections should be closed and =
re-opened anytime messages interleave. This would cause unnecessary =
extra delays and roundtrips due to the TCP handshake.

Why is it hard to close and re-open the TCP connections?

 Problem is that if we use lower-layer security, such as IPSec (as in =
3GPP for one example), we cannot open and close ports at will, because =
security associations have fixed selectors (source IP, source port, =
destination IP, destination port, protocol). The only way we could open =
a new TCP connection is to use exactly the same 5 selectors as the =
original one.
According to TCP: "Another effect of this 2MSL wait is that while the =
TCP connection is in the 2MSL wait, the socket pair defining the =
connection (client IP address, client port number, server IP address, =
server port number) cannot be reused.  That connection can only be =
reused when the 2MSl wait is over."
MSL is the maximum segment lifetime, which is by RFC recommendation 2 =
minutes, but many implementations use 30 seconds. Effectively, it means =
that the connection cannot be reused for 1-4 minutes after closure.

How it could be implemented?

A possible implementation could be:
-	Transport looks at the first byte of the message, and cheks whether it =
starts with 11111.
-	If yes, the stream is passed to SigComp that reads it till 0xFFFF and =
returns
-	If no, the stream is passed to SIP that reads it as long as indicated =
by Content-Length
-	Rinse, Repeat

 Of course if the Content-Length is improperly filled, missing or =
SigComp messages contain additional 0xFFFF or do not end with 0xFFFF, it =
might happen that a parser receives messages that are erroneous, partial =
or belong to the other protocol. In that case the next message or all =
messages inside that stream could be lost. But similar problems also =
arise in a stream containing SIP or SigComp messages only.

What do you think?

BR,
Robert

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



From exim@www1.ietf.org  Mon Oct 20 19:01:23 2003
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 TAA12940
	for <rohc-archive@odin.ietf.org>; Mon, 20 Oct 2003 19:01:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj1L-0003aG-Nw
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 19:01:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KN1371013773
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 19:01:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj1L-0003a4-Ii
	for rohc-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 19:01:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12918
	for <rohc-web-archive@ietf.org>; Mon, 20 Oct 2003 19:00:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj1I-0002zx-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 19:01:00 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj1H-0002zu-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 19:00:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj1K-0003Ze-2E; Mon, 20 Oct 2003 19:01:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj1E-0003XU-8r
	for rohc@optimus.ietf.org; Mon, 20 Oct 2003 19:00:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12910
	for <rohc@ietf.org>; Mon, 20 Oct 2003 19:00:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj1A-0002zl-00
	for rohc@ietf.org; Mon, 20 Oct 2003 19:00:52 -0400
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj19-0002zV-00
	for rohc@ietf.org; Mon, 20 Oct 2003 19:00:52 -0400
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9KN0J2s019487
	for <rohc@ietf.org>; Tue, 21 Oct 2003 01:00:21 +0200 (CEST)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9KN0Iaq019486
	for <rohc@ietf.org>; Tue, 21 Oct 2003 01:00:18 +0200 (CEST)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9KN0H2o019483; Tue, 21 Oct 2003 01:00:18 +0200 (CEST)
Received: from [10.1.1.33] (dial09.office [10.1.1.33])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id EF1E1D7A03; Tue, 21 Oct 2003 00:26:01 +0200 (CEST)
Date: Tue, 21 Oct 2003 01:01:15 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "C. M. Heard" <heard@pobox.com>, ROHC mailing list <rohc@ietf.org>
Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt
Message-ID: <2147483647.1066698075@[10.1.1.33]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Hi Mike,

There was a long idle from my last messages on the ROHC MIB to this one.
Now I want to finish processing issues the issue list by addressing the
two issues that are still left open:


--On 08.08.2003 11:51 h +0200 Juergen Quittek wrote:
> Hi Mike,
>
> Unfortunately, it took some time until we could check all your comments.
> Again thank you very much for this really helpful work. The document
> improved a lot!
>
> Below please find the detailed responses on all of your comments
> with two exceptions:
>
>   - 4.) IPR Notices
>         We are still checking the patent issues.
>         We will post the results on the mailing list
>         (with CC to you and Bert).

Together with Lars-Erik, we checked the IPR issues.
They do not apply to the MIB or to MIB implementations.

>   - 11.) (e) ordering of the index components
>         This is discussed in a separate email thread on the list.

We had long discussions on this issue.  So far indexing has looked like:

  rohcChannelTable:       ifIndex, rohcChannelID
  rohcInstanceTable:      ifIndex, rohcInstanceType, rohcChannelID
  rohcProfileTable:       ifIndex, rohcChannelID, rohcProfile
  rohcContextTable:       ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID
  rohcUncmprContextTable: ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID
  rohcRtpContextTable:    ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID
  rohcRtpPacketSizeTable: ifIndex, rohcInstanceType, rohcChannelID, rohcContextCID, rohcRtpPacketSize

We want to change this such that the rohcChannelID becomes unique
for a ROHC MIB implementation independent of the interface or
instance to which the channel belongs.

This simplifies the profile table, all context tables and the
RTP packet size table:

  rohcProfileTable:       rohcChannelID, rohcProfile
  rohcContextTable:       rohcChannelID, rohcContextCID
  rohcUncmprContextTable: rohcChannelID, rohcContextCID
  rohcRtpContextTable:    rohcChannelID, rohcContextCID
  rohcRtpPacketSizeTable: rohcChannelID, rohcContextCID, rohcRtpPacketSize

For the rohc channel table we still want to keep the old indexing
scheme, because we believe it is useful to be able to access channels
per interface and to access Instances by the rohc InstanceType:

  rohcChannelTable:       ifIndex, rohcChannelID
  rohcInstanceTable:      ifIndex, rohcInstanceType, rohcChannelID

Addressing a good suggestion from Abbie

>>>>> On Tue, 8 Jul 2003, Surtees, Abigail wrote:
Abbie> However, looking at it from a MIB point of view I think
Abbie> it is confusing to have a seemingly redundant index.
Abbie>
Abbie> Hence, I suggest that rohcInstanceType continues to be
Abbie> an index but that there is some text added to the draft
Abbie> explaining why it is there and that if you want to
Abbie> uniquely identify one rohc instance (whether compressor
Abbie> or decompressor) then ifIndex and rohcChannelID are
Abbie> sufficient to do this.

we suggest to modify the DESCRIPTION clauses of rohcChannelEntry to

    DESCRIPTION
        "An entry describing a particular script.  Every script that
         is stored in non-volatile memory is required to appear in
         this script table.

         Note, that the rohcChannelID identifies the channel
         uniquely.  The ifIndex is part of the index of this table
         just in order to allow addressing channels per interface."

and of rochChannelID in the rohcChannelTable to

    DESCRIPTION
        "The locally arbitrary, but unique identifier associated
         with this channel.  The value is REQUIRED to be unique
         per ROHC MIB implementation independent of the associated
         interface.

         The value is REQUIRED to remain constant at least from one
         re-initialization of the entity's network management system
         to the next re-initialization.  It is RECOMMENDED that the
         value persist across such re-initializations."

and of the rohcInstanceTable to

    DESCRIPTION
        "This table lists properties of running instances
         of robust header compressors and decompressors
         at IP interfaces. It is indexed by interface number,
         the type of instance (compressor or decompressor),
         and and the ID of the channel used by the instance as
         ROHC channel.

         Note that the rohcChannelID uniquely identifies an
         instance.  The ifIndex and rohcInstanceType are part
         of the index, because it simplifies accessing instances
         per interface and for addressing either compressors or
         decompressors only."

A consequence of these changes would be that modules
ROHC-UNCMPRESSED-MIB and ROHC-RTP-MIB do not use anymore the object
ifIndex (or other objects from the IF-MIB and the IF-MIB can be
removed from the IMPORT clause and the DESCRIPTION clause of the
compliance statements.

Thanks,

    Juergen
-- 
Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de




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



From exim@www1.ietf.org  Mon Oct 20 19:06:22 2003
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 TAA13081
	for <rohc-archive@odin.ietf.org>; Mon, 20 Oct 2003 19:06:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj6B-0005ZN-Fb
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 19:06:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KN63tG021403
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 19:06:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj6B-0005Z8-Br
	for rohc-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 19:06:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13050
	for <rohc-web-archive@ietf.org>; Mon, 20 Oct 2003 19:05:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj67-00033E-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 19:05:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj67-000336-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 19:05:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj69-0005WY-UJ; Mon, 20 Oct 2003 19:06:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABj67-0005Vj-BE
	for rohc@optimus.ietf.org; Mon, 20 Oct 2003 19:05:59 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13038
	for <rohc@ietf.org>; Mon, 20 Oct 2003 19:05:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj63-00032t-00
	for rohc@ietf.org; Mon, 20 Oct 2003 19:05:56 -0400
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABj63-00031w-00
	for rohc@ietf.org; Mon, 20 Oct 2003 19:05:55 -0400
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9KN5M2s019533
	for <rohc@ietf.org>; Tue, 21 Oct 2003 01:05:24 +0200 (CEST)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9KN17Xh019500
	for <rohc@ietf.org>; Tue, 21 Oct 2003 01:01:07 +0200 (CEST)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9KN172o019497; Tue, 21 Oct 2003 01:01:07 +0200 (CEST)
Received: from [10.1.1.33] (dial09.office [10.1.1.33])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 891D9D7A44; Tue, 21 Oct 2003 00:26:51 +0200 (CEST)
Date: Tue, 21 Oct 2003 01:02:07 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "C. M. Heard" <heard@pobox.com>, ROHC mailing list <rohc@ietf.org>
Subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt
Message-ID: <2147483647.1066698127@[10.1.1.33]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Bert,

--On 08.08.2003 15:11 h +0200 Wijnen, Bert (Bert) wrote:

> When I see things like:
>
>    added to description:
>         "Note that compliance with this compliance
>          statement requires compliance with the
>          rohcCompliance MODULE-COMPLIANCE statement of the
>          ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE
>          statement of the IF-MIB [RFC2863]."
>
> I'd say that instead of [RFC2863], it would probably be better
> to use (RFC 2863).
> The reason is that when the MIB module gets extracted from the
> RFC, then the citation is lost, and besides, (RFC 2863) seems
> to me to be a clearly enoug ptr to the document.

Thanks for this hint.

I'll commit this modification to all three MIB modules.

    Juergen
-- 
Juergen Quittek        quittek@ccrle.nec.de        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


> Thanks,
> Bert









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



From exim@www1.ietf.org  Mon Oct 20 19:12:22 2003
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 TAA13221
	for <rohc-archive@odin.ietf.org>; Mon, 20 Oct 2003 19:12:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABjBx-0007yc-8N
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 19:12:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KNC1lT030656
	for rohc-archive@odin.ietf.org; Mon, 20 Oct 2003 19:12:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABjBx-0007yN-4y
	for rohc-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 19:12:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13217
	for <rohc-web-archive@ietf.org>; Mon, 20 Oct 2003 19:11:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABjBv-00035l-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 19:11:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABjBv-00035i-00
	for rohc-web-archive@ietf.org; Mon, 20 Oct 2003 19:11:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABjBx-0007xo-4T; Mon, 20 Oct 2003 19:12:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABjB4-0007fw-JN
	for rohc@optimus.ietf.org; Mon, 20 Oct 2003 19:11:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13210
	for <rohc@ietf.org>; Mon, 20 Oct 2003 19:10:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABjB1-00035Z-00
	for rohc@ietf.org; Mon, 20 Oct 2003 19:11:03 -0400
Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABjB0-00035H-00
	for rohc@ietf.org; Mon, 20 Oct 2003 19:11:02 -0400
Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1])
	by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.9) with ESMTP id h9KNAP2s019571
	for <rohc@ietf.org>; Tue, 21 Oct 2003 01:10:32 +0200 (CEST)
Received: (from defang@localhost)
	by tokyo.ccrle.nec.de (8.12.9-20030927/8.12.8/Submit) id h9KN5Qs8019544
	for <rohc@ietf.org>; Tue, 21 Oct 2003 01:05:26 +0200 (CEST)
X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to <quittek@ccrle.nec.de> using -f
Received: from venus.office (venus.office [10.1.1.11])
	by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id h9KN5P2o019539; Tue, 21 Oct 2003 01:05:26 +0200 (CEST)
Received: from [10.1.1.33] (dial10.office [10.1.1.34])
	by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP
	id 43076D7A6D; Tue, 21 Oct 2003 00:31:10 +0200 (CEST)
Date: Tue, 21 Oct 2003 01:06:24 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "C. M. Heard" <heard@pobox.com>
Cc: ROHC mailing list <rohc@ietf.org>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt
Message-ID: <2147483647.1066698384@[10.1.1.33]>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; FORMAT=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Scanned-By: MIMEDefang 2.35
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Mike,

--On 08.08.2003 10:26 Uhr -0700 C. M. Heard wrote:

> On Fri, 8 Aug 2003, J=FCrgen Quittek wrote:
>
>> Unfortunately, it took some time until we could check all your
>> comments. Again thank you very much for this really helpful
>> work. The document improved a lot!
>
> Thanks for the detailed point-by-point responses.  You no doubt have
> already seen Bert's suggestion for how to avoid citations in the MIB
> module, so I only have a couple of points to add.

Yes.

>> > (c) [RFC3095] has an incorrect title and an author list that's
>> > not in the standard form.
>>
>> I replaced "et al." by the complete list of authors, but I do not
>> know what is wrong with the title?
>
> The title is listed as "An RObust Header Compression [...]";  the
> word "An" is extraneous.  Here is how the it looks in RFC 3241:
>
> [RFC3095]   Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
>             Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
>             Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
>             T., Yoshimura, T. and H. Zheng, "RObust Header Compression
>             (ROHC): Framework and four profiles: RTP, UDP, ESP, and
>             uncompressed", RFC 3095, July 2001.
>
> The one in RFC 3242 is similar.


Fixed it.

>> > 9.) MIB compilation -- the following problems are reported by
>> > smilint:
>>
>> I was surprised to see these error messages.
>> Looks like i used an older, buggy version of smilint :-(
>
> Actually, that's true.  It turns out that previous versions of
> smilint didn't check for failure to import the base types that were
> "inherited" from SMIv1.  I was bitten by this when I wrote the WIS
> MIB ... ironically, I had checked SMICng 2.2.07, which did not
> require any SMIv2 base types to be imported.  The problem is fixed
> in current versions of smilint and SMICng.
>
> Regarding 11(e):
>> > the authors may wish to consider changing the order of the leading
>> > components in the tables that have rohcInstanceType as an index
>> > component from:
>> >
>> >     INDEX { ifIndex, rohcInstanceType, rohcChannelID, ... }
>> >
>> > to:
>> >
>> >     INDEX { ifIndex, rohcChannelID, rohcInstanceType, ... }
>> >
>> > The affected row objects are rohcInstanceEntry and rohcContextTable
>> > in the ROHC-MIB module, rohcUncmprContextEntry in the
>> > ROHC-UNCOMPRESSED-MIB module, and rohcRtpContextTable and
>> > rohcRtpPacketSizeEntry in the ROHC-RTP-MIB module.
>>
>> See separate email thread on this issue.
>
> Actually, I think that you have already provided a good rationale
> for the existing indexing scheme.  Back on 8 Jul 2003, I wrote:
>
> % >>>>> On Mon, 7 Jul 2003, Juergen Quittek wrote:
> % Juergen> Initially, rohcInstanceType was no index. Probably this
> % Juergen> is the reason why we forgot to make it non-accessible.
> % Juergen> But after some discussions with rohc people, partiularly
> % Juergen> including with Lars-Erik, we found that when accessing
> % Juergen> the MIB a management station would typically look either
> % Juergen> for compressors or for decompressors, but not for
> % Juergen> particular channels.
> %
> % That makes sense.
> %
> % Juergen> Without the rohcInstanceType being part of the index, a
> % Juergen> management station looking for a particular compressor
> % Juergen> or looking for all compressors would need to browse
> % Juergen> through all compressor and decompressor contexts, read
> % Juergen> the type and ignore them if they are decompressors.
> % Juergen>
> % Juergen> But with the rohcInstanceType as n index before the
> % Juergen> channel ID, you can first select whether you ant to
> % Juergen> browse compressors or decompressors and then go through
> % Juergen> the (shorter) list of specific contexts.
> % Juergen>
> % Juergen> I think this is helpful and matches requirements of rohc
> % Juergen> management stations.
> %
> % This explanation also provides a response to review comment 11(e),
> % as it provides a good reason why rohcInstanceType should precede
> % rohcChannelID in the INDEX clauses where it appears.
>
> Abigail Surtees did ask for some explanatory text explaining why
> rohcInstanceType is present as an index, which you agreed to
> provide;  and if, when you add that text, you would also note (as
> is done above) the reason why is appears before rohcChannelID,
> then as far as I'm concerned the issue is closed.

As explained in an earlier mail, we suggest to change the indexing
but still follow Abigail's recommendation to explain the indexing
scheme better than we did so far.

> Thanks,
>
> Mike
>

Thanks,

    Juergen







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



From exim@www1.ietf.org  Wed Oct 22 08:24:53 2003
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 IAA05168
	for <rohc-archive@odin.ietf.org>; Wed, 22 Oct 2003 08:24:53 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACI2R-0008JA-OE
	for rohc-archive@odin.ietf.org; Wed, 22 Oct 2003 08:24:33 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MCOV3L031905
	for rohc-archive@odin.ietf.org; Wed, 22 Oct 2003 08:24:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACI2R-0008IQ-BI
	for rohc-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 08:24:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05108
	for <rohc-web-archive@ietf.org>; Wed, 22 Oct 2003 08:24:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACI2P-0004FV-00
	for rohc-web-archive@ietf.org; Wed, 22 Oct 2003 08:24:29 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACI2O-0004FI-00
	for rohc-web-archive@ietf.org; Wed, 22 Oct 2003 08:24:28 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACI2I-0008EN-0t; Wed, 22 Oct 2003 08:24:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ABwut-0000A1-UQ
	for rohc@optimus.ietf.org; Tue, 21 Oct 2003 09:51:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17571
	for <rohc@ietf.org>; Tue, 21 Oct 2003 09:51:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABwur-0003d1-00
	for rohc@ietf.org; Tue, 21 Oct 2003 09:51:18 -0400
Received: from [192.116.176.1] (helo=rad-w2ksrv11.radcom.co.il)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ABwur-0003cg-00
	for rohc@ietf.org; Tue, 21 Oct 2003 09:51:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C397DA.133CEB10"
Date: Tue, 21 Oct 2003 15:48:57 +0200
Message-ID: <93E3C7B04652BC47934B2DE74DC607AC10E340@rad-w2ksrv11.radcom.co.il>
Thread-Topic: SigComp states
Thread-Index: AcOX2hNCmaxuor3EQuyuK846VNyKOw==
From: "Gilad Shaham" <GiladS@radcom.com>
To: <rohc@ietf.org>
Subject: [rohc] SigComp states
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C397DA.133CEB10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

I am looking for some information regarding SigComp states. I did not
quite understand how they work or to be precise, how the compression and
decompression algorithm use them (since they could be anything).
Furthermore, I think that if someone can illustrate a detailed example
of a state preservation between two messages, it would significantly
help me in understanding the state role and its use.

=20

Thanks.


------_=_NextPart_001_01C397DA.133CEB10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0mm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoHeader, li.MsoHeader, div.MsoHeader
	{margin:0mm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.MsoFooter, li.MsoFooter, div.MsoFooter
	{margin:0mm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello,</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I am looking for some information regarding SigComp =
states.
I did not quite understand how they work or to be precise, how the =
compression
and decompression algorithm use them (since they could be anything).
Furthermore, I think that if someone can illustrate a detailed example =
of a state
preservation between two messages, it would significantly help me in
understanding the state role and its use.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks.</span></font></p>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C397DA.133CEB10--

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



From exim@www1.ietf.org  Wed Oct 22 18:48:20 2003
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 SAA03053
	for <rohc-archive@odin.ietf.org>; Wed, 22 Oct 2003 18:48:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRlr-0004Zd-78
	for rohc-archive@odin.ietf.org; Wed, 22 Oct 2003 18:48:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MMm3HE017577
	for rohc-archive@odin.ietf.org; Wed, 22 Oct 2003 18:48:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRlr-0004ZQ-3o
	for rohc-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 18:48:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03024
	for <rohc-web-archive@ietf.org>; Wed, 22 Oct 2003 18:47:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACRln-0003iz-00
	for rohc-web-archive@ietf.org; Wed, 22 Oct 2003 18:47:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACRln-0003iw-00
	for rohc-web-archive@ietf.org; Wed, 22 Oct 2003 18:47:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRlp-0004Z2-N5; Wed, 22 Oct 2003 18:48:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACRlA-0004PL-DV
	for rohc@optimus.ietf.org; Wed, 22 Oct 2003 18:47:20 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02987;
	Wed, 22 Oct 2003 18:47:07 -0400 (EDT)
Message-Id: <200310222247.SAA02987@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rohc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 22 Oct 2003 18:47:07 -0400
Subject: [rohc] I-D ACTION:draft-price-rohc-formal-notation-00.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Formal Notation for Robust Header Compression (ROHC-FN)
	Author(s)	: R. Price, et. al.
	Filename	: draft-price-rohc-formal-notation-00.txt
	Pages		: 40
	Date		: 2003-10-22
	
This document defines a proposal for the ROHC-FN: a formal notation 
for specifying how to compress and decompress fields from an 
arbitrary protocol stack.  ROHC-FN is proposed with the intention of 
simplifing the creation of new compression profiles to fit within the 
ROHC [RFC-3095] framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-price-rohc-formal-notation-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-price-rohc-formal-notation-00.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-price-rohc-formal-notation-00.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-22182848.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-price-rohc-formal-notation-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-price-rohc-formal-notation-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-22182848.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Thu Oct 23 05:44:21 2003
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 FAA10433
	for <rohc-archive@odin.ietf.org>; Thu, 23 Oct 2003 05:44:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACc0g-0005IG-9L
	for rohc-archive@odin.ietf.org; Thu, 23 Oct 2003 05:44:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N9i2YN020344
	for rohc-archive@odin.ietf.org; Thu, 23 Oct 2003 05:44:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACc0g-0005I3-4l
	for rohc-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 05:44:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10425
	for <rohc-web-archive@ietf.org>; Thu, 23 Oct 2003 05:43:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACc0c-0004Pt-00
	for rohc-web-archive@ietf.org; Thu, 23 Oct 2003 05:43:58 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACc0b-0004Pq-00
	for rohc-web-archive@ietf.org; Thu, 23 Oct 2003 05:43:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACc0e-0005HB-E9; Thu, 23 Oct 2003 05:44:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACbzh-00052t-AF
	for rohc@optimus.ietf.org; Thu, 23 Oct 2003 05:43:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10388
	for <rohc@ietf.org>; Thu, 23 Oct 2003 05:42:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACbzd-0004Or-00
	for rohc@ietf.org; Thu, 23 Oct 2003 05:42:57 -0400
Received: from eagle.ericsson.se ([193.180.251.53])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACbzY-0004OB-00
	for rohc@ietf.org; Thu, 23 Oct 2003 05:42:57 -0400
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9N9gmoq019636;
	Thu, 23 Oct 2003 11:42:48 +0200
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <43DPTW5X>; Thu, 23 Oct 2003 11:42:48 +0200
Message-ID: <A943FD84BD9ED41193460008C791805006FC41DB@ESEALNT419.al.sw.ericsson.se>
From: "Jan Christoffersson (LU/EAB)" <jan.christoffersson@ericsson.com>
To: "'Pekka Pessi'" <Pekka.Pessi@nokia.com>,
        "'rohc@ietf.org'"
	 <rohc@ietf.org>,
        Abigail Surtees <abigail.surtees@roke.co.uk>
Subject: RE: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
Date: Thu, 23 Oct 2003 11:42:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Pekka,
In general, I don't think that anyone can argue against that the more DMS and SMS you have available the better. However, the point with this draft is what the MANDATORY minimum DMS and SMS parameters for SIP compression should be! I think that the mandatory requirements should not be the "optimal" parameter values but instead values that give a reasonable performance. If an entity has the ability to give a larger DMS size than the mandatory value, it is free to do so.

more comments inline.

BR
Jan

-----Original Message-----
From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
Sent: den 18 oktober 2003 00:57
To: 'rohc@ietf.org'
Cc: Abigail Surtees
Subject: Re: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt


Surtees, Abigail <abigail.surtees@roke.co.uk> writes:
>My gut feeling is that 8k seems rather large for DMS.  For TCP the size of
>the message sent has no impact.  For UDP, following the SIP instruction that
>a SIP message should not be within 200 bytes of the MTU the maximum size of
>a SigComp message is 1272 (assuming a 1500 byte MTU).  

	The limitation is true for requests. However, responses can
	easily be greater than that, or even bigger than MTU.

>The worst case is that where C is really small and B and S are large. 
>So we have C + B + S <= 1272 with a worst case of B + S = 1272 and C =
>0 because B and S count twice (cannot quite be achieved but is useful
>to make the point). So C + 2B + 2S + 128 = 2672 which with a DMS of 4k
>still leaves 1328 bytes for R.

	Don't forget SIP dictionary (D), which can be 4832 bytes.

	If B + S = 1500, then C + 2B + R + 2S + 128 + D < DMS leaves us
	with R < DMS - 2B - 2S - C - D - 128 or R < 2932 bytes in case
	of DMS=8192. I can't agree that 4096 is plenty.

[JC] In case the SIP dictionary is used, I think this should be contained in S. Even if this dictionary is 4.8 K, it is not necessary to use all of it. In fact, after a couple of message exchanges it will not contribute very much to the compression performance. To use the static dictionary for dimensioning the DMS does not seem to be a good idea.

	But in any case I think DMS is cheap, as it's active only during
	decompression for UDP, and nothing compared to the socket
	buffers required by TCP.

>		Section 2.2

>Mandating an SMS of 2k would prevent the use of SigComp with a stateless
>proxy.  Is this necessary?  

	I don't see any reason why a stateless proxy cannot create
	state. It just don't keep transaction state.

>A SigComp endpoint may not assume that state
>will be stored until it has had an advertisement of SMS.  However, it can
>request it and ensure that it waits for an acknowledgement before using the
>state.  Presence of an SMS of 2k does not ensure that the state will be
>created, it just ensures that there is potential for creating state.
>Consequently is there any need to mandate it?

	I agree, 2k can be rather crowded.

....
>Paragraph 1:	I agree with the editor's note.  The definition of
>compartments and description of how long state can persist is complicated
>and needs discussion and further work on the mailing list.

	Definitely.
	
					Pekka

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

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



From exim@www1.ietf.org  Thu Oct 23 16:24:24 2003
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 QAA17405
	for <rohc-archive@odin.ietf.org>; Thu, 23 Oct 2003 16:24:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACm04-000760-CY
	for rohc-archive@odin.ietf.org; Thu, 23 Oct 2003 16:24:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NKO4Xa027277
	for rohc-archive@odin.ietf.org; Thu, 23 Oct 2003 16:24:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACm04-00075s-5c
	for rohc-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 16:24:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17392
	for <rohc-web-archive@ietf.org>; Thu, 23 Oct 2003 16:23:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACm02-00003K-00
	for rohc-web-archive@ietf.org; Thu, 23 Oct 2003 16:24:02 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACm01-00003G-00
	for rohc-web-archive@ietf.org; Thu, 23 Oct 2003 16:24:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACm00-000740-S5; Thu, 23 Oct 2003 16:24:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AClzT-0006nd-SO
	for rohc@optimus.ietf.org; Thu, 23 Oct 2003 16:23:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17371
	for <rohc@ietf.org>; Thu, 23 Oct 2003 16:23:17 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AClzS-00002r-00
	for rohc@ietf.org; Thu, 23 Oct 2003 16:23:26 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AClzR-00002o-00
	for rohc@ietf.org; Thu, 23 Oct 2003 16:23:25 -0400
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9NKNOI11952
	for <rohc@ietf.org>; Thu, 23 Oct 2003 23:23:24 +0300 (EET DST)
Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6577ab3077ac158f21082@esvir01nok.ntc.nokia.com>;
 Thu, 23 Oct 2003 23:23:24 +0300
Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 23 Oct 2003 13:23:23 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Thu, 23 Oct 2003 16:23:21 -0400
Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E87C@ajebe001.americas.nokia.com>
Thread-Topic: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
Thread-Index: AcOPO98BFKLMV0mFSueKpqSOMmQMHgKYfYsQ
To: <abigail.surtees@roke.co.uk>, <rohc@ietf.org>
X-OriginalArrivalTime: 23 Oct 2003 20:23:23.0357 (UTC) FILETIME=[81D6E8D0:01C399A3]
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi Abbie,

Thanks for your comments, especially after such a long silent
period on the subject in this mailing list.

To make the reply shorter, I'll comment below only on the easy ones=20
(i.e. nits). I'll address your comments on SMS and DMS in a separate =
email.

BR,
Zhigang

> Minor nits:
>=20
> Page 1:=09
> 		Abstract:
> I felt that this was not particularly clear, in particular,=20
> the use of the
> word 'specifics' and the fact that there were references that were not
> explained.
>=20
> Suggested text:
>=20
> "This document describes default parameters and definitions=20
> for use when
> Signaling Compression (SigComp) is applied to the Session Initiation
> Protocol (SIP).  Any implementation of SigComp for use with=20
> SIP must conform
> to this document, in addition to SigComp and use of the SIP static
> dictionary."

I agree the current text is not particularly clear. However, the text=20
above does not cover section 3, 4, and 5. I'll expand above text to
make it broader enough.=20
=20
> Page 2:
> 		Introduction:
>=20
> Similar phraseology not clear in paragraph 2 and references=20
> aren't clear. =20
>=20
> Suggested text:
>=20
> "This document binds ... SigComp).  Any SigComp=20
> implementation that is used
> for the compression of SIP messages must conform to this=20
> document, as well
> as to SigComp [RFC 3320] and must use the SIP static=20
> dictionary as specified
> in [RFC 3485].

OK. To be more accurate, I'll change it to "SIP/SDP-specific
static dictionary.

> 		Section 2:
> Paragraph 1, 3rd line "when receiving Sigcomp messages" -=20
> confuses rather
> than clarifies.  IMHO the sentence makes sense without it.

OK for me.
=20
> Paragraph 1, last sentence "Scalability is ..." should be=20
> "Scalability was
> ..."

Right.=20

> Page 3:
> 		Section 2.2
> Paragraph 3, line 3 - "of whether it can" should be "of=20
> whether or not it
> can"

OK.

> Page 4:=09
> 		Section 2.5
> "Minimum value" doesn't make sense for the static dictionary.=20
>  Should be
> "For ..." as in 2.4

It is the "minimum value" of locally available state. I used
the term in the broader sense, i.e., minimal data or minimal set=20
of data. But I can change the text as above if it is confusing.

> 		Section 3
> Paragraph 4, line 3 - "However, the actual presentation", should be
> "However, the actual representation".

Yes!

> Page 6:
> 		Section 4 cont.
>=20
> Paragraph 2 - suggested addition to the end of the last=20
> sentence "and be
> delimited by the use of 0xFFFF as described in [RFC 3320]."

OK.

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



From exim@www1.ietf.org  Thu Oct 23 17:59:23 2003
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 RAA20787
	for <rohc-archive@odin.ietf.org>; Thu, 23 Oct 2003 17:59:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACnTz-0006dG-Qd
	for rohc-archive@odin.ietf.org; Thu, 23 Oct 2003 17:59:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NLx3eO025491
	for rohc-archive@odin.ietf.org; Thu, 23 Oct 2003 17:59:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACnTz-0006d4-Gm
	for rohc-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 17:59:03 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20769
	for <rohc-web-archive@ietf.org>; Thu, 23 Oct 2003 17:58:50 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACnTv-0001Bo-00
	for rohc-web-archive@ietf.org; Thu, 23 Oct 2003 17:58:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACnTv-0001Bl-00
	for rohc-web-archive@ietf.org; Thu, 23 Oct 2003 17:58:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACnTw-0006cK-KT; Thu, 23 Oct 2003 17:59:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ACnTs-0006ba-8M
	for rohc@optimus.ietf.org; Thu, 23 Oct 2003 17:58:56 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20766
	for <rohc@ietf.org>; Thu, 23 Oct 2003 17:58:44 -0400 (EDT)
From: zhigang.c.liu@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACnTp-0001Bi-00
	for rohc@ietf.org; Thu, 23 Oct 2003 17:58:53 -0400
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ACnTo-0001Bf-00
	for rohc@ietf.org; Thu, 23 Oct 2003 17:58:53 -0400
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9NLwqI14778
	for <rohc@ietf.org>; Fri, 24 Oct 2003 00:58:52 +0300 (EET DST)
Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6578028e2cac158f23077@esvir03nok.nokia.com>;
 Fri, 24 Oct 2003 00:58:50 +0300
Received: from ajebe001.NOE.Nokia.com ([172.18.151.16]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 23 Oct 2003 14:58:51 -0700
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Date: Thu, 23 Oct 2003 17:58:49 -0400
Message-ID: <7B5AF06E216CB74DA8A5960A3181B5B808E87D@ajebe001.americas.nokia.com>
Thread-Topic: [rohc] FW: Comments on draft-ietf-rohc-sigcomp-sip-00.txt
Thread-Index: AcOPO98BFKLMV0mFSueKpqSOMmQMHgKabhFw
To: <abigail.surtees@roke.co.uk>, <rohc@ietf.org>
X-OriginalArrivalTime: 23 Oct 2003 21:58:51.0175 (UTC) FILETIME=[D7E29370:01C399B0]
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Hi Abbie,

> My gut feeling is that 8k seems rather large for DMS.  For=20
> TCP the size of the message sent has no impact.=20

Actually, a small DMS is even a bigger problem for TCP. RFC 3320
specifies that only half of the DMS can be used as UDVM memory.=20
Namely, 4KB DMS means 2KB UDVM memory. It is quite limiting
considering all the stuff that has to be stored in UDVM memory:
bytecode, partial SIP/SDP static dictionary (obviously we cannot
use the entire dictionary), other uploaded dictionaries, and=20
decompressed data (which is useful to compress/decompress
remaining data in the same message).

> For UDP, following the SIP instruction that
> a SIP message should not be within 200 bytes of the MTU the=20
> maximum size of a SigComp message is 1272 (assuming a 1500 byte MTU).=20
> The worst case is that where C is really small and B and S are large.  =

> So we have C + B + S <=3D 1272=20

Hmm ... this is the upper bound for SIP message over UDP. Did we ever=20
specify the same limit for SigComp messages over UDP? If that
is the case, we are in real trouble.

> The other thing to take into consideration is whether there=20
> is any point in mandating an 8K DMS but only a 2K SMS? =20
> 8K allows R to be large but then the whole history cannot=20
> be stored because SMS is not big enough?

See above for the "half" factor in case of TCP. So, it's not
8K UDVM memory vs 2K SMS, but rather 4K UDVM memory vs 2K SMS.
And R (ring buffer size) is even smaller than 4K: R =3D 4K -=20
128 - B (bytecode size). In addition, you probably don't
want to put everything in the ring buffer in a state.

Of course, I don't mind to specify SMS =3D 4KB, which allows us
to create multiple states from multiple SIP messages. However,
I'm more conservative on SMS than DMS since states stay after UDVM
(i.e. for the whole lifetime of a compartment), while DMS is only
per UDVM alive.=20

From my perspective, 2K SMS allows a compressor to create states in=20
the first message without guessing if the states will make it at all
on the decompressor side. This is good enough. Like you said, the other
end can always announce larger SMS. And it can do so right in the reply
to the first message ...

BR,
Zhigang

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



From exim@www1.ietf.org  Mon Oct 27 17:15:53 2003
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 RAA20671
	for <rohc-archive@odin.ietf.org>; Mon, 27 Oct 2003 17:15:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEFeB-0000TY-I9
	for rohc-archive@odin.ietf.org; Mon, 27 Oct 2003 17:15:35 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMFZT6001827
	for rohc-archive@odin.ietf.org; Mon, 27 Oct 2003 17:15:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEFeB-0000TK-Ef
	for rohc-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 17:15:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20409
	for <rohc-web-archive@ietf.org>; Mon, 27 Oct 2003 17:15:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEFe8-0007Mp-00
	for rohc-web-archive@ietf.org; Mon, 27 Oct 2003 17:15:32 -0500
Received: from sausage.foretec.com ([4.17.168.5] helo=manatick)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEFe7-0007Kd-00
	for rohc-web-archive@ietf.org; Mon, 27 Oct 2003 17:15:31 -0500
Received: from [132.151.6.22] (helo=optimus.ietf.org)
	by manatick with esmtp (Exim 4.24)
	id 1AEFbL-0002Hb-Ja
	for rohc-web-archive@ietf.org; Mon, 27 Oct 2003 17:12:47 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEFan-00084e-VG; Mon, 27 Oct 2003 17:12:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEFZw-0007lN-M6
	for rohc@optimus.ietf.org; Mon, 27 Oct 2003 17:11:12 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19527;
	Mon, 27 Oct 2003 17:10:59 -0500 (EST)
Message-Id: <200310272210.RAA19527@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rohc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 27 Oct 2003 17:10:59 -0500
Subject: [rohc] I-D ACTION:draft-ietf-rohc-mib-rtp-07.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--NextPart

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		: Definitions of Managed Objects for Robus Header Compression
	Author(s)	: J. Quittek
	Filename	: draft-ietf-rohc-mib-rtp-07.txt
	Pages		: 50
	Date		: 2003-10-24
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that allow
monitoring of running instances of robust header compression.  The
managed objects defined in this memo are grouped into three MIB
modules.  The ROHC-MIB module defines managed objects shared by all
ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed
objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB
module defines managed objects specific to the ROHC RTP profile, the
ROHC UDP profile, and the ROHC ESP profile.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-mib-rtp-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-mib-rtp-07.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-mib-rtp-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-27171504.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rohc-mib-rtp-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rohc-mib-rtp-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-27171504.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 15:45:31 2003
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 PAA25674
	for <rohc-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:45:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaiG-0001Kj-H2
	for rohc-archive@odin.ietf.org; Tue, 28 Oct 2003 15:45:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKjCje005124
	for rohc-archive@odin.ietf.org; Tue, 28 Oct 2003 15:45:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaiG-0001KZ-Bz
	for rohc-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:45:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25533
	for <rohc-web-archive@ietf.org>; Tue, 28 Oct 2003 15:45:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEaiE-0006kG-00
	for rohc-web-archive@ietf.org; Tue, 28 Oct 2003 15:45:10 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEaiE-0006kA-00
	for rohc-web-archive@ietf.org; Tue, 28 Oct 2003 15:45:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEai8-0001Ho-Bv; Tue, 28 Oct 2003 15:45:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEai1-0001Ag-Ps
	for rohc@optimus.ietf.org; Tue, 28 Oct 2003 15:44:57 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25425;
	Tue, 28 Oct 2003 15:44:46 -0500 (EST)
Message-Id: <200310282044.PAA25425@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rohc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:44:46 -0500
Subject: [rohc] I-D ACTION:draft-ietf-rohc-tcp-05.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--NextPart

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): TCP/IP Profile (ROHC-TCP)
	Author(s)	: G. Pelletier, Q. Zhang, L. Jonsson, H. Liao, M. West
	Filename	: draft-ietf-rohc-tcp-05.txt
	Pages		: 61
	Date		: 2003-10-28
	
This document specifies a ROHC (Robust Header Compression) profile
for compression of TCP/IP packets. The profile, called ROHC-TCP, is a
robust header compression scheme for TCP/IP that provides improved
compression efficiency and enhanced capabilities for compression of
various header fields including TCP options.

Existing TCP/IP header compression schemes do not work well when used
over links with significant error rates and long round-trip times.
For many bandwidth limited links where header compression is
essential, such characteristics are common. In addition, existing
schemes [RFC-1144, RFC-2507] have not addressed how to compress TCP
options such as SACK (Selective Acknowledgements) [RFC-2018, RFC-2883] and Timestamps [RFC-1323].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-tcp-05.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-tcp-05.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28155854.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rohc-tcp-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rohc-tcp-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28155854.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 15:45:34 2003
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 PAA25690
	for <rohc-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:45:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaiJ-0001N1-CC
	for rohc-archive@odin.ietf.org; Tue, 28 Oct 2003 15:45:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKjFpk005261
	for rohc-archive@odin.ietf.org; Tue, 28 Oct 2003 15:45:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaiJ-0001Mm-8f
	for rohc-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:45:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25531
	for <rohc-web-archive@ietf.org>; Tue, 28 Oct 2003 15:45:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEaiE-0006kD-00
	for rohc-web-archive@ietf.org; Tue, 28 Oct 2003 15:45:10 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEaiE-0006k9-00
	for rohc-web-archive@ietf.org; Tue, 28 Oct 2003 15:45:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEai7-0001Hc-Vn; Tue, 28 Oct 2003 15:45:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEahs-00019I-Tb
	for rohc@optimus.ietf.org; Tue, 28 Oct 2003 15:44:48 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25404;
	Tue, 28 Oct 2003 15:44:37 -0500 (EST)
Message-Id: <200310282044.PAA25404@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rohc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:44:37 -0500
Subject: [rohc] I-D ACTION:draft-ietf-rohc-formal-notation-02.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--NextPart

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		: Formal Notation for Robust Header Compression (ROHC-FN)
	Author(s)	: R. Price
	Filename	: draft-ietf-rohc-formal-notation-02.txt
	Pages		: 72
	Date		: 2003-10-28
	
This document defines ROHC-FN: a formal notation for specifying how 
to compress and decompress fields from an arbitrary protocol stack.  
ROHC-FN is intended to simplify the creation of new compression 
profiles to fit within the ROHC [RFC-3095] framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-formal-notation-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-formal-notation-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-formal-notation-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28155840.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rohc-formal-notation-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rohc-formal-notation-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28155840.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Oct 28 15:46:22 2003
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 PAA25799
	for <rohc-archive@odin.ietf.org>; Tue, 28 Oct 2003 15:46:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaj5-0001ax-22
	for rohc-archive@odin.ietf.org; Tue, 28 Oct 2003 15:46:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKk27o006119
	for rohc-archive@odin.ietf.org; Tue, 28 Oct 2003 15:46:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaj4-0001aQ-Ly
	for rohc-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:46:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25748
	for <rohc-web-archive@ietf.org>; Tue, 28 Oct 2003 15:45:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEaj3-0006mD-00
	for rohc-web-archive@ietf.org; Tue, 28 Oct 2003 15:46:01 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEaj2-0006mA-00
	for rohc-web-archive@ietf.org; Tue, 28 Oct 2003 15:46:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaj3-0001Xt-He; Tue, 28 Oct 2003 15:46:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEaiC-0001Ig-N1
	for rohc@optimus.ietf.org; Tue, 28 Oct 2003 15:45:08 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25454;
	Tue, 28 Oct 2003 15:44:57 -0500 (EST)
Message-Id: <200310282044.PAA25454@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rohc@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 28 Oct 2003 15:44:56 -0500
Subject: [rohc] I-D ACTION:draft-ietf-rohc-context-replication-01.txt
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

--NextPart

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):Context Replication for ROHC Profiles
	Author(s)	: G. Pelletier
	Filename	: draft-ietf-rohc-context-replication-01.txt
	Pages		: 17
	Date		: 2003-10-28
	
This document defines context replication, a complement to the
context initialization procedure found in ROHC (Robust Header
Compression) [RFC-3095]. Profiles defining support for context
replication may use the mechanism described herein to establish a new
context based on another already existing context.
Context replication is introduced to reduce the overhead of the
context establishment procedure, and may be especially useful for the
compression of multiple short-lived flows that may be occurring
simultaneously or near-simultaneously, such as for example short-
lived TCP flows.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-context-replication-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-context-replication-01.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rohc-context-replication-01.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-28155909.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rohc-context-replication-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rohc-context-replication-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-28155909.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Wed Oct 29 04:10:27 2003
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 EAA29267
	for <rohc-archive@odin.ietf.org>; Wed, 29 Oct 2003 04:10:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmL9-0005GC-9y
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 04:10:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T9A7vk020216
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 04:10:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmL7-0005Fu-VH
	for rohc-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 04:10:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29246
	for <rohc-web-archive@ietf.org>; Wed, 29 Oct 2003 04:09:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmL4-0004hx-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 04:10:03 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmL4-0004ht-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 04:10:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmL4-0005En-QG; Wed, 29 Oct 2003 04:10:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEmKa-0005Bk-EW
	for rohc@optimus.ietf.org; Wed, 29 Oct 2003 04:09:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29230
	for <rohc@ietf.org>; Wed, 29 Oct 2003 04:09:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmKL-0004h8-00
	for rohc@ietf.org; Wed, 29 Oct 2003 04:09:17 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEmKK-0004h5-00
	for rohc@ietf.org; Wed, 29 Oct 2003 04:09:16 -0500
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9T99HSs024796
	for <rohc@ietf.org>; Wed, 29 Oct 2003 10:09:17 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <VXB82S5J>; Wed, 29 Oct 2003 10:09:17 +0100
Message-ID: <A943FD84BD9ED41193460008C7918050072E9332@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: "Rohc (E-mail)" <rohc@ietf.org>
Date: Wed, 29 Oct 2003 10:09:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [rohc] No ROHC session in Minneapolis
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

ROHCers,

As you might have noticed on the draft agenda, there is no
ROHC session planned for Minneapolis. The reason for this
is twofold. First of all, we do not believe there is need
for a meeting, considering the few open work items we 
currently have, and the status of these. Secondly, both me
and Carsten have been rather inactive due to personal 
reasons, and instead of having an official ROHC session we
hope to get time to talk to folks in the corridors, and get
updated on the work ongoing.

A WG status report will soon be sent to the list, and we
hereby ask all document editors to also send status reports
to the list. 

CU in MPLS,
/L-E

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
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



From exim@www1.ietf.org  Wed Oct 29 10:05:22 2003
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 KAA10466
	for <rohc-archive@odin.ietf.org>; Wed, 29 Oct 2003 10:05:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AErsd-00015Z-S1
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 10:05:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TF53OU004184
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 10:05:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AErsd-00015P-OW
	for rohc-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 10:05:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10417
	for <rohc-web-archive@ietf.org>; Wed, 29 Oct 2003 10:04:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AErsb-00024b-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 10:05:01 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AErsb-00024Y-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 10:05:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AErsc-00014w-Ew; Wed, 29 Oct 2003 10:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AErsX-00014S-8Y
	for rohc@optimus.ietf.org; Wed, 29 Oct 2003 10:04:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10404
	for <rohc@ietf.org>; Wed, 29 Oct 2003 10:04:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AErsV-00024U-00
	for rohc@ietf.org; Wed, 29 Oct 2003 10:04:55 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AErsQ-00024R-00
	for rohc@ietf.org; Wed, 29 Oct 2003 10:04:50 -0500
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9TF4nSs000431
	for <rohc@ietf.org>; Wed, 29 Oct 2003 16:04:49 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <V6NK0DXT>; Wed, 29 Oct 2003 16:04:47 +0100
Message-ID: <A943FD84BD9ED41193460008C7918050072E9333@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: "Rohc (E-mail)" <rohc@ietf.org>
Date: Wed, 29 Oct 2003 16:03:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [rohc] ROHC WG status update
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Document status:

  Published:
     RFC 3095: Framework and four profiles
                      (was: draft-ietf-rohc-rtp-09.txt)
     RFC 3096: RTP requirements
                      (was: draft-ietf-rohc-rtp-requirements-05.txt)
     RFC 3241: ROHC over PPP
                      (was: draft-ietf-rohc-over-ppp-04.txt)
     RFC 3242: LLA RTP
                      (was: draft-ietf-rohc-rtp-lla-03.txt)
     RFC 3243: 0-byte RTP requirements
                      (was: draft-ietf-rohc-rtp-0-byte-requirements-02.txt)
     RFC 3320: SigComp
                      (was: draft-ietf-rohc-sigcomp-07.txt)
     RFC 3321: SigComp extended operations
                      (was: draft-ietf-rohc-sigcomp-extended-04.txt)
     RFC 3322: SigComp Requirements and assumptions
                      (was: draft-ietf-rohc-signaling-req-assump-06.txt)
     RFC 3408: LLA R-mode extension
                      (was: draft-ietf-rohc-rtp-lla-r-mode-03.txt)
     RFC 3409: ROHC RTP Lower layer guidelines
                      (was: draft-ietf-rohc-rtp-lower-guidelines-03.txt)

  In RFC editor queue:
     None!

  Passed IETF last-call:
     None!

  In IETF last-call:
     None!

  Submitted to IESG:
     draft-ietf-rohc-mib-rtp-06.txt (Proposed Standard)
                ** Has passed MIB doctor review and been updated
     draft-ietf-rohc-terminology-and-examples-02.txt (Informational)
                ** Has been waiting for MIB
     draft-ietf-rohc-ip-only-05.txt (Proposed Standard)
                ** Was just submitted to the IESG

  In WG last-call:
     None!

  Current WG documents:
     ROHC RTP/Framework/Draft Standard:
           * draft-ietf-rohc-rtp-impl-guide-04.txt
           * draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt
           * draft-ietf-rohc-udp-lite-01.txt

     ROHC TCP:
           * draft-ietf-rohc-tcp-requirements-06.txt
           * draft-ietf-rohc-tcp-05.txt
           * draft-ietf-rohc-formal-notation-02.txt
           * draft-ietf-rohc-context-replication-01.txt
           * draft-ietf-rohc-tcp-field-behavior-02.txt

     SigComp:
           * draft-ietf-rohc-sigcomp-impl-guide-01.txt
           * draft-ietf-rohc-sigcomp-user-guide-00.txt
           * draft-ietf-rohc-sigcomp-sip-00.txt


WG status:

  TCP: This work item is finally converging and we can now see the
       light in the end of the tunnel. The formal notation is now
       rather stable and complete, and the TCP profile itself is
       synchronized with both the notation and the replication
       drafts.

  RTP/Framework/DS (3095bis): The IP profile is finalized, and
       the UDP-Lite profile is on hold, waiting for UDP-Lite
       itself to get published. The Draft Standard work has been
       delayed, but there is still good hope to get this going
       rather soon. There have been significant discussions of
       various details in 3095, which will make 3095bis much
       clearer and better.

  SigComp: Not much discussions on the list, and the documents
       have not evolved much. Here we should try to get better
       progress. The SigComp feedback draft is not even published
       as a WG draft, maybe it will never be.


WG administrative issues:

  The "committed reviewers" concept was successfully tested on the
  IP profile. We will continue in the same way with the rest of
  our documents.

  Updated milestones have been proposed, and we are currently 
  waiting for AD approval.


  
--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
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



From exim@www1.ietf.org  Wed Oct 29 17:56:22 2003
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 RAA12347
	for <rohc-archive@odin.ietf.org>; Wed, 29 Oct 2003 17:56:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzES-0005rc-7R
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 17:56:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TMu4Jr022534
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 17:56:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzES-0005rN-3r
	for rohc-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 17:56:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12329
	for <rohc-web-archive@ietf.org>; Wed, 29 Oct 2003 17:55:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzEP-00068t-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 17:56:01 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzEP-00068q-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 17:56:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzEP-0005ql-N4; Wed, 29 Oct 2003 17:56:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzDh-0005o9-0r
	for rohc@optimus.ietf.org; Wed, 29 Oct 2003 17:55:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12267
	for <rohc@ietf.org>; Wed, 29 Oct 2003 17:55:04 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzDe-00067F-00
	for rohc@ietf.org; Wed, 29 Oct 2003 17:55:14 -0500
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzDd-00067B-00
	for rohc@ietf.org; Wed, 29 Oct 2003 17:55:13 -0500
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9TMtBVY015028
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <rohc@ietf.org>; Wed, 29 Oct 2003 14:55:11 -0800 (PST)
Received: from HAIPENGJ.qualcomm.com (haipengj.qualcomm.com [129.46.74.180])
	by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9TMt9FB027027
	for <rohc@ietf.org>; Wed, 29 Oct 2003 14:55:09 -0800 (PST)
Message-Id: <5.2.0.9.2.20031029144441.040b4db8@E2k.qualcomm.com>
X-Sender: haipengj@E2k.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 29 Oct 2003 14:55:09 -0800
To: "Rohc (E-mail)" <rohc@ietf.org>
From: Haipeng Jin <haipengj@qualcomm.com>
In-Reply-To: <A943FD84BD9ED41193460008C7918050072E9333@ESEALNT419.al.sw.
 ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [rohc] Question about ROHC Type 1 packet in UO mode
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi,

I am reading the RFC3095, and encountered the following problem:

In 5.7.3, the packet format for UO-1-TS is shown as

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   0 |T=1|        TS         |
    +===+===+===+===+===+===+===+===+
    | M |      SN       |    CRC    |
    +---+---+---+---+---+---+---+---+


However, comparing with UO-1-ID, it seems that the M bit here should be X, 
is this a typo? If no, why is it different from the UO-1-ID packet?
This also makes me think about the packet format for UO-1, which is shown as:

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   0 |          TS           |
    +===+===+===+===+===+===+===+===+
    | M |      SN       |    CRC    |
    +---+---+---+---+---+---+---+---+

Again, does M here really mean M or does it mean X?

Could anyone please clarify the above problems?

BTW, I have seen the mention of 3095bis on this mailing list several times, 
is this an existing document? If yes, could you please tell me where to get 
it? I can not find it on IETF website.

Thanks.

Haipeng




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



From exim@www1.ietf.org  Wed Oct 29 18:29:20 2003
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 SAA14768
	for <rohc-archive@odin.ietf.org>; Wed, 29 Oct 2003 18:29:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzkM-0000jh-LG
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 18:29:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TNT2sY002830
	for rohc-archive@odin.ietf.org; Wed, 29 Oct 2003 18:29:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzkM-0000jZ-Es
	for rohc-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 18:29:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14720
	for <rohc-web-archive@ietf.org>; Wed, 29 Oct 2003 18:28:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzkJ-00071s-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 18:28:59 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzkJ-00071p-00
	for rohc-web-archive@ietf.org; Wed, 29 Oct 2003 18:28:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzkL-0000jD-2z; Wed, 29 Oct 2003 18:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AEzjb-0000fz-39
	for rohc@optimus.ietf.org; Wed, 29 Oct 2003 18:28:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14716
	for <rohc@ietf.org>; Wed, 29 Oct 2003 18:28:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzjX-000711-00
	for rohc@ietf.org; Wed, 29 Oct 2003 18:28:12 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AEzjX-00070w-00
	for rohc@ietf.org; Wed, 29 Oct 2003 18:28:11 -0500
Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9TNSAI2023081;
	Thu, 30 Oct 2003 00:28:10 +0100 (MET)
Received: from arael27m8.eu.ericsson.se ([153.88.95.9]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id V6MFD7FJ; Thu, 30 Oct 2003 00:28:03 +0100
Date: Thu, 30 Oct 2003 00:28:06 +0100 (CET)
From: Vicknesan Ayadurai <vicknesan.ayadurai@ericsson.com>
X-X-Sender: vick@caffreys.ericsson.se
To: Haipeng Jin <haipengj@qualcomm.com>
cc: "Rohc (E-mail)" <rohc@ietf.org>
Subject: Re: [rohc] Question about ROHC Type 1 packet in UO mode
In-Reply-To: <5.2.0.9.2.20031029144441.040b4db8@E2k.qualcomm.com>
Message-ID: <20031030001842.R1445-100000@caffreys.ericsson.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

Hi Haipeng,

No, there is no typo with the M/X-bits you mentioned.

UO-1 packets carrying RTP timestamp bits are meant to be used during
talkspurts/jumps in the RTP timestamp. These timestamp jumps also
usually affect the RTP Marker-bit, and hence, these ROHC packets also
carry the Marker-bit info.

UO-1 ID does not carry timestamp bits in the base header and hence, no
Marker-bit either. Instead, extensions are made possible as indicated
by the presence of an X-bit in place of the Marker-bit.

As to your final question, I have no knowledge of a 3095bis document.

Regards,
vick

On Wed, 29 Oct 2003, Haipeng Jin wrote:

> Hi,
>
> I am reading the RFC3095, and encountered the following problem:
>
> In 5.7.3, the packet format for UO-1-TS is shown as
>
>       0   1   2   3   4   5   6   7
>     +---+---+---+---+---+---+---+---+
>     | 1   0 |T=1|        TS         |
>     +===+===+===+===+===+===+===+===+
>     | M |      SN       |    CRC    |
>     +---+---+---+---+---+---+---+---+
>
>
> However, comparing with UO-1-ID, it seems that the M bit here should be X,
> is this a typo? If no, why is it different from the UO-1-ID packet?
> This also makes me think about the packet format for UO-1, which is shown as:
>
>       0   1   2   3   4   5   6   7
>     +---+---+---+---+---+---+---+---+
>     | 1   0 |          TS           |
>     +===+===+===+===+===+===+===+===+
>     | M |      SN       |    CRC    |
>     +---+---+---+---+---+---+---+---+
>
> Again, does M here really mean M or does it mean X?
>
> Could anyone please clarify the above problems?
>
> BTW, I have seen the mention of 3095bis on this mailing list several times,
> is this an existing document? If yes, could you please tell me where to get
> it? I can not find it on IETF website.
>
> Thanks.
>
> Haipeng
>
>
>
>
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>


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



From exim@www1.ietf.org  Thu Oct 30 05:23:22 2003
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 FAA16232
	for <rohc-archive@odin.ietf.org>; Thu, 30 Oct 2003 05:23:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9xG-0001ak-M3
	for rohc-archive@odin.ietf.org; Thu, 30 Oct 2003 05:23:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UAN2fq006104
	for rohc-archive@odin.ietf.org; Thu, 30 Oct 2003 05:23:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9xG-0001aK-8k
	for rohc-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 05:23:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16189
	for <rohc-web-archive@ietf.org>; Thu, 30 Oct 2003 05:22:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9xC-0000pQ-00
	for rohc-web-archive@ietf.org; Thu, 30 Oct 2003 05:22:58 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9xC-0000pL-00
	for rohc-web-archive@ietf.org; Thu, 30 Oct 2003 05:22:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9xE-0001Yn-Ms; Thu, 30 Oct 2003 05:23:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AF9wM-0001Ls-0x
	for rohc@optimus.ietf.org; Thu, 30 Oct 2003 05:22:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16136
	for <rohc@ietf.org>; Thu, 30 Oct 2003 05:21:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9wI-0000nh-00
	for rohc@ietf.org; Thu, 30 Oct 2003 05:22:02 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AF9wH-0000nc-00
	for rohc@ietf.org; Thu, 30 Oct 2003 05:22:01 -0500
Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9UAM2I2002043;
	Thu, 30 Oct 2003 11:22:02 +0100 (MET)
Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <V6NLHN0G>; Thu, 30 Oct 2003 11:22:01 +0100
Message-ID: <A943FD84BD9ED41193460008C7918050072E9336@ESEALNT419.al.sw.ericsson.se>
From: "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
To: "Vicknesan Ayadurai (KI/EAB)" <vicknesan.ayadurai@ericsson.com>,
        Haipeng Jin <haipengj@qualcomm.com>
Cc: "Rohc (E-mail)" <rohc@ietf.org>
Subject: RE: [rohc] Question about ROHC Type 1 packet in UO mode
Date: Thu, 30 Oct 2003 11:21:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

You are both correct, 3095bis is not yet an existing document, but it
is work for ROHC to do. For the time being, 3095bis would technically
mean [3095+the implementer's guide]

/L-E

> As to your final question, I have no knowledge of a 3095bis document.
>
> > BTW, I have seen the mention of 3095bis on this mailing 
> > list several times, is this an existing document? If yes,
> > could you please tell me where to get it? I can not find it
> > on IETF website.

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



From exim@www1.ietf.org  Thu Oct 30 05:47:22 2003
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 FAA16943
	for <rohc-archive@odin.ietf.org>; Thu, 30 Oct 2003 05:47:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAKV-00043y-6h
	for rohc-archive@odin.ietf.org; Thu, 30 Oct 2003 05:47:03 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UAl37S015612
	for rohc-archive@odin.ietf.org; Thu, 30 Oct 2003 05:47:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAKV-00043j-2t
	for rohc-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 05:47:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16918
	for <rohc-web-archive@ietf.org>; Thu, 30 Oct 2003 05:46:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAKR-0001AK-00
	for rohc-web-archive@ietf.org; Thu, 30 Oct 2003 05:46:59 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAKQ-0001AH-00
	for rohc-web-archive@ietf.org; Thu, 30 Oct 2003 05:46:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAKT-00043Q-MX; Thu, 30 Oct 2003 05:47:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAKC-00042o-JC
	for rohc@optimus.ietf.org; Thu, 30 Oct 2003 05:46:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16898
	for <rohc@ietf.org>; Thu, 30 Oct 2003 05:46:32 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAK8-00019y-00
	for rohc@ietf.org; Thu, 30 Oct 2003 05:46:40 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAK7-00019p-00
	for rohc@ietf.org; Thu, 30 Oct 2003 05:46:39 -0500
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9UAkeI2010815
	for <rohc@ietf.org>; Thu, 30 Oct 2003 11:46:40 +0100 (MET)
Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id V63AZA7S; Thu, 30 Oct 2003 11:46:43 +0100
Received: by lms001.lu.erisoft.se id LAA05602; Thu, 30 Oct 2003 11:46:39 +0100 (MET)
Message-ID: <3FA0ECA9.339A2DB3@ericsson.com>
Date: Thu, 30 Oct 2003 11:49:13 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Ghyslain Pelletier <Ghyslain.Pelletier@ericsson.com>
Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rohc@ietf.org
Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-context-replication-01.txt
References: <200310282044.PAA25454@ietf.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id LAA05602
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

ROHCers,

An updated version of the draft describing context replication for ROHC
profiles, <draft-ietf-rohc-context-replication-01.txt>, has been
submitted. There has been lots of changes based on previous discussions.
In particular, the following has been updated:

- New CR state added
- IR-REPLICATE has been renamed to IR-CR (after the new state)
- The coverage of the 8-bit CRC in IR-CR now always cover the entire
  IR-CR packet, except the payload
- Operational assumptions regarding the modes of operation with context
  replication have been clarified.
- A section on reconstruction and verification has been added=20
- A discussion on requirements to support inter-profile replication
  has been added. Inter-profile replication is still however an open
  issue (please comment).
- Appendix suggesting replication chains has been removed.

Please comment on these changes and the updated version in general.

Regards,

/Ghyslain

Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegr=E4nd 11
Box 920, S-97128 Lule=E5, SWEDEN
Phone : +46 (0) 920 20 24 32=20
Mobile: +46 (0) 70 609 27 73
Ghyslain.Pelletier@epl.ericsson.se
http://www.ericsson.com


Internet-Drafts@ietf.org wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> This draft is a work item of the Robust Header Compression Working Grou=
p of the IETF.
>=20
>         Title           : RObust Header Compression (ROHC):Context Repl=
ication for ROHC Profiles
>         Author(s)       : G. Pelletier
>         Filename        : draft-ietf-rohc-context-replication-01.txt
>         Pages           : 17
>         Date            : 2003-10-28
>=20
> This document defines context replication, a complement to the
> context initialization procedure found in ROHC (Robust Header
> Compression) [RFC-3095]. Profiles defining support for context
> replication may use the mechanism described herein to establish a new
> context based on another already existing context.
> Context replication is introduced to reduce the overhead of the
> context establishment procedure, and may be especially useful for the
> compression of multiple short-lived flows that may be occurring
> simultaneously or near-simultaneously, such as for example short-
> lived TCP flows.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rohc-context-replication=
-01.txt
>=20
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the mess=
age.
>=20
> Internet-Drafts are also available by anonymous FTP. Login with the use=
rname
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-rohc-context-replication-01.txt".
>=20
> 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
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-ietf-rohc-context-replication-01.t=
xt".
>=20
> 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 re=
aders
>         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 o=
n
>         how to manipulate these messages.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20
>   ---------------------------------------------------------------------=
---

--=20
Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegr=E4nd 11
Box 920, S-97128 Lule=E5, SWEDEN
Phone : +46 (0) 920 20 24 32=20
Mobile: +46 (0) 706 09 27 73
Ghyslain.Pelletier@ericsson.com
http://www.ericsson.com

I have a new mail address: Ghyslain.Pelletier@ericsson.com
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

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



From exim@www1.ietf.org  Thu Oct 30 05:49:23 2003
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 FAA17067
	for <rohc-archive@odin.ietf.org>; Thu, 30 Oct 2003 05:49:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAMS-0004G8-2g
	for rohc-archive@odin.ietf.org; Thu, 30 Oct 2003 05:49:04 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UAn4TZ016366
	for rohc-archive@odin.ietf.org; Thu, 30 Oct 2003 05:49:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAMR-0004Ft-UD
	for rohc-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 05:49:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17027
	for <rohc-web-archive@ietf.org>; Thu, 30 Oct 2003 05:48:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAMO-0001CA-00
	for rohc-web-archive@ietf.org; Thu, 30 Oct 2003 05:49:00 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAMN-0001C4-00
	for rohc-web-archive@ietf.org; Thu, 30 Oct 2003 05:48:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAMQ-0004DM-1K; Thu, 30 Oct 2003 05:49:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFAMC-0004C6-BW
	for rohc@optimus.ietf.org; Thu, 30 Oct 2003 05:48:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16990
	for <rohc@ietf.org>; Thu, 30 Oct 2003 05:48:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAM8-0001BR-00
	for rohc@ietf.org; Thu, 30 Oct 2003 05:48:44 -0500
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFAM7-0001BO-00
	for rohc@ietf.org; Thu, 30 Oct 2003 05:48:44 -0500
Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121])
	by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9UAmhSs005901
	for <rohc@ietf.org>; Thu, 30 Oct 2003 11:48:44 +0100 (MET)
Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id V63AZB5P; Thu, 30 Oct 2003 11:48:46 +0100
Received: by lms001.lu.erisoft.se id LAA05691; Thu, 30 Oct 2003 11:48:43 +0100 (MET)
Message-ID: <3FA0ED25.BF3454C7@ericsson.com>
Date: Thu, 30 Oct 2003 11:51:17 +0100
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Ghyslain Pelletier <Ghyslain.Pelletier@ericsson.com>
Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rohc@ietf.org
Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-tcp-05.txt
References: <200310282044.PAA25425@ietf.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id LAA05691
Content-Transfer-Encoding: quoted-printable
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

ROHCers,

An updated version of the draft describing the ROHC profile of TCP,
<draft-ietf-rohc-tcp-05.txt>, has been submitted. There has been lots of
changes based on previous discussions. In particular, the following has
been updated:

- Packet formats using the formal notation have been added
- The state machine (compressor and decompressor) for this profile now
  has its own section.
- MSN initializes to zero and is LSB coded when sent

Please comment on these changes and the updated version in general.

Regards,

/Ghyslain

Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegr=E4nd 11
Box 920, S-97128 Lule=E5, SWEDEN
Phone : +46 (0) 920 20 24 32=20
Mobile: +46 (0) 70 609 27 73
Ghyslain.Pelletier@epl.ericsson.se
http://www.ericsson.com



Internet-Drafts@ietf.org wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> This draft is a work item of the Robust Header Compression Working Grou=
p of the IETF.
>=20
>         Title           : RObust Header Compression (ROHC): TCP/IP Prof=
ile (ROHC-TCP)
>         Author(s)       : G. Pelletier, Q. Zhang, L. Jonsson, H. Liao, =
M. West
>         Filename        : draft-ietf-rohc-tcp-05.txt
>         Pages           : 61
>         Date            : 2003-10-28
>=20
> This document specifies a ROHC (Robust Header Compression) profile
> for compression of TCP/IP packets. The profile, called ROHC-TCP, is a
> robust header compression scheme for TCP/IP that provides improved
> compression efficiency and enhanced capabilities for compression of
> various header fields including TCP options.
>=20
> Existing TCP/IP header compression schemes do not work well when used
> over links with significant error rates and long round-trip times.
> For many bandwidth limited links where header compression is
> essential, such characteristics are common. In addition, existing
> schemes [RFC-1144, RFC-2507] have not addressed how to compress TCP
> options such as SACK (Selective Acknowledgements) [RFC-2018, RFC-2883] =
and Timestamps [RFC-1323].
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt
>=20
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the mess=
age.
>=20
> Internet-Drafts are also available by anonymous FTP. Login with the use=
rname
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-rohc-tcp-05.txt".
>=20
> 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
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-ietf-rohc-tcp-05.txt".
>=20
> 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 re=
aders
>         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 o=
n
>         how to manipulate these messages.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20
>   ---------------------------------------------------------------------=
---

--=20
Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegr=E4nd 11
Box 920, S-97128 Lule=E5, SWEDEN
Phone : +46 (0) 920 20 24 32=20
Mobile: +46 (0) 706 09 27 73
Ghyslain.Pelletier@ericsson.com
http://www.ericsson.com

I have a new mail address: Ghyslain.Pelletier@ericsson.com
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

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



From exim@www1.ietf.org  Fri Oct 31 03:17:28 2003
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 DAA17428
	for <rohc-archive@odin.ietf.org>; Fri, 31 Oct 2003 03:17:28 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFUSy-0004Fx-Nk
	for rohc-archive@odin.ietf.org; Fri, 31 Oct 2003 03:17:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h9V8H8I7016355
	for rohc-archive@odin.ietf.org; Fri, 31 Oct 2003 03:17:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFUSy-0004Fi-Dl
	for rohc-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 03:17:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17420
	for <rohc-web-archive@ietf.org>; Fri, 31 Oct 2003 03:16:56 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFUSw-0003iX-00
	for rohc-web-archive@ietf.org; Fri, 31 Oct 2003 03:17:06 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFUSv-0003iU-00
	for rohc-web-archive@ietf.org; Fri, 31 Oct 2003 03:17:05 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFUSr-0004F5-Lx; Fri, 31 Oct 2003 03:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AFUSO-0004DY-VH
	for rohc@optimus.ietf.org; Fri, 31 Oct 2003 03:16:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17406
	for <rohc@ietf.org>; Fri, 31 Oct 2003 03:16:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFUSM-0003iB-00
	for rohc@ietf.org; Fri, 31 Oct 2003 03:16:30 -0500
Received: from shell4.bayarea.net ([209.128.82.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AFUSL-0003hw-00
	for rohc@ietf.org; Fri, 31 Oct 2003 03:16:29 -0500
Received: from localhost (heard@localhost)
	by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h9V8Fnq12737;
	Fri, 31 Oct 2003 00:15:52 -0800
X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
Date: Fri, 31 Oct 2003 00:15:47 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-Sender: heard@shell4.bayarea.net
To: Juergen Quittek <quittek@ccrle.nec.de>
cc: ROHC mailing list <rohc@ietf.org>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt
In-Reply-To: <2147483647.1066698075@[10.1.1.33]>
Message-ID: <Pine.LNX.4.10.10310310003050.9519-100000@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>,
	<mailto:rohc-request@ietf.org?subject=subscribe>

On Tue, 21 Oct 2003, Juergen Quittek wrote:
> > Below please find the detailed responses on all of your comments
> > with two exceptions:
> >
> >   - 4.) IPR Notices
> >         We are still checking the patent issues.
> >         We will post the results on the mailing list
> >         (with CC to you and Bert).
> 
> Together with Lars-Erik, we checked the IPR issues.
> They do not apply to the MIB or to MIB implementations.

OK

> >   - 11.) (e) ordering of the index components
> >         This is discussed in a separate email thread on the list.
> 
> We had long discussions on this issue.  So far indexing has looked like:
[ ... details snipped, but each table used ifIndex ... ]
> We want to change this such that the rohcChannelID becomes unique
> for a ROHC MIB implementation independent of the interface or
> instance to which the channel belongs.
> 
> This simplifies the profile table, all context tables and the
> RTP packet size table:
> 
>   rohcProfileTable:       rohcChannelID, rohcProfile
>   rohcContextTable:       rohcChannelID, rohcContextCID
>   rohcUncmprContextTable: rohcChannelID, rohcContextCID
>   rohcRtpContextTable:    rohcChannelID, rohcContextCID
>   rohcRtpPacketSizeTable: rohcChannelID, rohcContextCID, rohcRtpPacketSize
> 
> For the rohc channel table we still want to keep the old indexing
> scheme, because we believe it is useful to be able to access channels
> per interface and to access Instances by the rohc InstanceType:
> 
>   rohcChannelTable:       ifIndex, rohcChannelID
>   rohcInstanceTable:      ifIndex, rohcInstanceType, rohcChannelID
> 
> Addressing a good suggestion from Abbie
> 
> >>>>> On Tue, 8 Jul 2003, Surtees, Abigail wrote:
> Abbie> However, looking at it from a MIB point of view I think
> Abbie> it is confusing to have a seemingly redundant index.
> Abbie>
> Abbie> Hence, I suggest that rohcInstanceType continues to be
> Abbie> an index but that there is some text added to the draft
> Abbie> explaining why it is there and that if you want to
> Abbie> uniquely identify one rohc instance (whether compressor
> Abbie> or decompressor) then ifIndex and rohcChannelID are
> Abbie> sufficient to do this.
> 
> we suggest to modify the DESCRIPTION clauses [ ... details snipped ... ]
> 
> A consequence of these changes would be that modules
> ROHC-UNCMPRESSED-MIB and ROHC-RTP-MIB do not use anymore the object
> ifIndex (or other objects from the IF-MIB and the IF-MIB can be
> removed from the IMPORT clause and the DESCRIPTION clause of the
> compliance statements.

Allow me to point out that all three MIB modules have counters
and that each counter points to ifCounterDiscontinuityTime as
its discontinuity indicator.  So it seems to me that there are
two problems here:

- there is still a dependence on the IF-MIB

- the absence of ifIndex from the index list makes it hard for
a management application to find out which counters have
sufferred a discontinuity when an instance if ifConcerDiscontinuityTime
changes.

So, I think you would be better off to re-instate ifIndex to the
INDEX clauses and mention of IF-MIB in the compliance statements.

Another point that I noticed is that the OID assignments for the
columnar objects are not contiguous, doubtless as a result of
removing columns from the tables.  Here is the result of a quick
grep:
       ::= { rohcChannelEntry 2 }
       ::= { rohcChannelEntry 3 }
       ::= { rohcChannelEntry 4 }
       ::= { rohcChannelEntry 5 }
       ::= { rohcChannelEntry 13 }
       ::= { rohcInstanceEntry 2 }
       ::= { rohcInstanceEntry 4 }
       ::= { rohcInstanceEntry 5 }
       ::= { rohcInstanceEntry 6 }
       ::= { rohcInstanceEntry 7 }
       ::= { rohcInstanceEntry 8 }
       ::= { rohcInstanceEntry 9 }
       ::= { rohcInstanceEntry 10 }
       ::= { rohcInstanceEntry 11 }
       ::= { rohcInstanceEntry 12 }
       ::= { rohcInstanceEntry 13 }
       ::= { rohcInstanceEntry 14 }
       ::= { rohcInstanceEntry 15 }
       ::= { rohcInstanceEntry 16 }
       ::= { rohcInstanceEntry 17 }
       ::= { rohcInstanceEntry 18 }
       ::= { rohcInstanceEntry 19 }
       ::= { rohcInstanceEntry 20 }
       ::= { rohcProfileEntry 2 }
       ::= { rohcProfileEntry 3 }
       ::= { rohcProfileEntry 4 }
       ::= { rohcProfileEntry 5 }
       ::= { rohcProfileEntry 6 }
       ::= { rohcContextEntry 2 }
       ::= { rohcContextEntry 3 }
       ::= { rohcContextEntry 4 }
       ::= { rohcContextEntry 5 }
       ::= { rohcContextEntry 6 }
       ::= { rohcContextEntry 7 }
       ::= { rohcContextEntry 8 }
       ::= { rohcContextEntry 9 }
       ::= { rohcContextEntry 10 }
       ::= { rohcContextEntry 11 }
       ::= { rohcContextEntry 12 }
       ::= { rohcContextEntry 13 }
       ::= { rohcContextEntry 14 }
       ::= { rohcContextEntry 15 }
       ::= { rohcContextEntry 16 }
       ::= { rohcContextEntry 17 }
       ::= { rohcContextEntry 18 }
       ::= { rohcContextEntry 19 }
       ::= { rohcContextEntry 20 }
       ::= { rohcContextEntry 21 }
       ::= { rohcContextEntry 22 }
       ::= { rohcRtpContextEntry 3 }
       ::= { rohcRtpContextEntry 4 }
       ::= { rohcRtpContextEntry 5 }
       ::= { rohcRtpContextEntry 6 }
       ::= { rohcRtpContextEntry 7 }
       ::= { rohcRtpContextEntry 8 }
       ::= { rohcRtpContextEntry 9 }
       ::= { rohcRtpContextEntry 10 }
       ::= { rohcRtpContextEntry 11 }
       ::= { rohcRtpContextEntry 12 }
       ::= { rohcRtpContextEntry 13 }
       ::= { rohcRtpContextEntry 14 }
       ::= { rohcRtpContextEntry 15 }
       ::= { rohcRtpContextEntry 16 }
       ::= { rohcRtpContextEntry 17 }
       ::= { rohcRtpPacketSizeEntry 3 }
       ::= { rohcRtpPacketSizeEntry 4 }
       ::= { rohcRtpPacketSizeEntry 5 }
       ::= { rohcRtpPacketSizeEntry 6 }
       ::= { rohcUncmprContextEntry 3 }
       ::= { rohcUncmprContextEntry 4 }
       ::= { rohcUncmprContextEntry 5 }

You may want to consider fixing this if you decide to
re-spin the MIB before publication.

Regards,

Mike


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