From exim@www1.ietf.org Tue Jul 1 07:24:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07613 for ; Tue, 1 Jul 2003 07:24:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h61BODj28945 for rohc-archive@odin.ietf.org; Tue, 1 Jul 2003 07:24:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJF7-0007Wm-HS for rohc-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 07:24:13 -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 HAA07482 for ; Tue, 1 Jul 2003 07:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XJF6-0002Kj-00 for rohc-web-archive@ietf.org; Tue, 01 Jul 2003 07:24:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XJF1-0002KG-00 for rohc-web-archive@ietf.org; Tue, 01 Jul 2003 07:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJEv-0007QR-Kd; Tue, 01 Jul 2003 07:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XJEb-0007Ot-R3 for rohc@optimus.ietf.org; Tue, 01 Jul 2003 07:23:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07302; Tue, 1 Jul 2003 07:23:38 -0400 (EDT) Message-Id: <200307011123.HAA07302@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, 01 Jul 2003 07:23:38 -0400 Subject: [rohc] I-D ACTION:draft-ietf-rohc-ip-only-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: , List-Id: Robust Header Compression List-Post: List-Help: List-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): A Compression Profile for IP Author(s) : L. Jonsson, G. Pelletier Filename : draft-ietf-rohc-ip-only-02.txt Pages : 14 Date : 2003-6-30 The original RObust Header Compression (ROHC) RFC, RFC 3095, defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP, IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-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-ip-only-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-ip-only-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-6-30151534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-ip-only-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-ip-only-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151534.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 Jul 1 13:48:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08275 for ; Tue, 1 Jul 2003 13:48:05 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIdue18342 for rohc-archive@odin.ietf.org; Fri, 27 Jun 2003 14:39:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy8a-0004li-6i for rohc-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:39:56 -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 OAA11880 for ; Fri, 27 Jun 2003 14:39:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy7p-00048g-Ql; Fri, 27 Jun 2003 14:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VwPc-00015c-P2 for rohc@optimus.ietf.org; Fri, 27 Jun 2003 12:49:24 -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 MAA07167 for ; Fri, 27 Jun 2003 12:49:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VwPb-0004cE-00 for rohc@ietf.org; Fri, 27 Jun 2003 12:49:23 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19VwPP-0004bf-00 for rohc@ietf.org; Fri, 27 Jun 2003 12:49:12 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 8B44489333; Sat, 28 Jun 2003 02:18:07 +0930 (CST) Date: Sat, 28 Jun 2003 02:18:07 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030628021807.A19571@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] question: interpretation of double Marker bits 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Question about RFC 3095. What do you do if you receive two Marker bits in an ROHC header with an extension? These packets have both an X bit and an M (Marker) bit in the main header: R-1, R-1-ID, R-1-TS, UOR-2, UOR-2-ID, UOR-2-TS. If header extension format 3 has an RTP section, then it has a Marker bit in the RTP flags byte. Is it intentional that there are often two Marker bits? I assume they should always be the same. But if they are different, should the packet be rejected? Or should one or the other be used by the decompressor? In the case of the double 4-bit CC field, the ROHC implementer's guide says that the second copy should be used if they are different, although it would be more logical to reject the packet because the difference should indicate a packet header error. So what is the interpretation for the double Marker bit? Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 1 13:48:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08837 for ; Tue, 1 Jul 2003 13:48:48 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIP5U23825 for rohc-archive@odin.ietf.org; Fri, 27 Jun 2003 14:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxuA-0006AZ-Qe for rohc-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:25:02 -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 OAA09582 for ; Fri, 27 Jun 2003 14:23: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 19VxsP-0005f5-J2; Fri, 27 Jun 2003 14:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuSS-0002NW-Gt for rohc@optimus.ietf.org; Fri, 27 Jun 2003 10:45:17 -0400 Received: from effnet.com ([194.237.235.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22148 for ; Fri, 27 Jun 2003 07:27:51 -0400 (EDT) Received: from effnet.com (c-617871d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.120.97]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id h5R8facG012613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2003 10:41:37 +0200 Message-ID: <3EFC11EF.DADAA0F7@effnet.com> Date: Fri, 27 Jun 2003 11:44:15 +0200 From: Kristofer Sandlund Organization: Effnet X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] ROHC IP profile comments 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi! Here are some (late) comments on the IP-only profile. The draft is a bit vague about the presense of compressed lists and extension headers. It only says: the static chain is terminated if the "Next Header / Protocol" field of a static IP header part indicates anything but IP (IPinIP or IPv6). Which of course is correct, but would be more clear if it ALSO said that "each additional IP header can contain one extension header chain" or something along those lines. Problem: ---------------------- When adding support for compressing an arbitrary number of IP headers (which leads to an arbitrary number of extension header lists), I feel that there will likely be memory issues for many implementations. This is because there is no way for the decompressor to tell the compressor that this specific context has grown too large and the decompressor cannot handle this. The likely situations where the decompressor context size grows are: I) A CID is re-used for a completely new flow. With an arbitrarily long header chain, there _could_ be bizarrely long, even if those won't occur very often in reality. II) When changing profile. This case is indirectly handled by the negotiation, as a decompressor should not negotiate a profile that it does not have enough space to decompress. So we don't really have to worry about this one. III) When there are frequent changes in the list compression (the translation tables for extension headers uses many indexes). Solutions with the current spec: If implementing a decompressor where I want to limit the per-context memory usage, I can only do the following with the current spec: a) Send a REJECT option in the feedback. This says that the decompressor is out of memory for ALL contexts, and the compressor should stop compressing this flow altogether. This has a side-effect that the compressor should not be initiating any new contexts for an unspecified amount of time. _Can_ solve both I) and III) but we stop compressing this flow altogether and can have side-effects on other flows. b) Send a NACK (or STATIC-NACK) so the compressor flushes the entire list compressor translation table(s) and has to re-establish everything. For case I), this does not automatically solve anything, since we do not know the reason for the NACK. For case III), if the flow changes a lot, then this will only solve the situation temporarily and the compressor can again compress out of the decompressor's table range causing a 'thrashing' situation. With an arbitrary number of IP headers, we will also have to re-establish all the extension header lists if one of them is out of range. Note: This is an issue that (to a lesser extent, though) also applies to the RFC3095 profiles. I suggest two different solutions for this issue, where one of them does not rule out the use of the other, so either one or both can be used. Proposed 'solution' 1: Add a new feedback option, LIMIT-CONTEXT, where the decompressor can send back information about how much context that it can safely handle. Upon reception of this, the compressor can decide to not use more context than the decompressor should handle. So what limit should LIMIT-CONTEXT convey, then? a) Size in bytes of base header chain (all IP headers in this profile) plus the sum of all extension header sizes in all the translation tables? b) The maximum number of IP headers that the compressor should compress in a flow? c) A limit in number of indexes in each translation table? d) A limit in total number of indexes in all translation tables? There are a number of other limits that could be used, so is there anything else that would fit even better? Some of these only partially help, but a) seems to be able to work for both I) and III). Proposed 'solution' 2: Start using the MAX_HEADER parameter of RFC3241 (ROHC-over-PPP) to negotiate a limit on copmressible header chain. This seems a bit inadequate, since I can still be forced to store 128 extension headers per extension header list. If the parameter could be interpreted as the sum of all base header sizes plus the sum of all extension header sizes in all translation tables then we're a bit closer. This would of course impact on all profiles. This solves case I) and depending on interpretation can help III) as well. Regards, Kristofer Sandlund, Effnet AB _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 1 13:48:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08850 for ; Tue, 1 Jul 2003 13:48:50 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIOGZ23062 for rohc-archive@odin.ietf.org; Fri, 27 Jun 2003 14:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxtO-0005zI-Tg for rohc-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:24: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 OAA09432 for ; Fri, 27 Jun 2003 14:23:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vxs9-00055o-00 for rohc-web-archive@ietf.org; Fri, 27 Jun 2003 14:22:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Vxrg-00053v-00 for rohc-web-archive@ietf.org; Fri, 27 Jun 2003 14:22:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxrO-0004nK-P4; Fri, 27 Jun 2003 14:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuNU-0002OB-GV for rohc@optimus.ietf.org; Fri, 27 Jun 2003 10:39:04 -0400 Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01768 for ; Fri, 27 Jun 2003 10:38:40 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5REcfG5018859; Fri, 27 Jun 2003 16:38:41 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 27 Jun 2003 16:38:47 +0200 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'rohc@ietf.org'" Cc: "'Surtees, Abigail'" Subject: RE: [rohc] Sigcomp Implementer's Guide Date: Fri, 27 Jun 2003 16:38:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, What happens, if the end of the message buffer was reached without an = END-MESSAGE instruction? RFC 3320 8.6 says: The UDVM stops executing instructions when it = encounters an END-MESSAGE instruction or if decompression failure = occurs (see Section 8.7 for further details). Section 8.7 however does = not mention this situation. I can see that a dummy END-MESSAGE is present in each torture test = case, but there is no test for this special situation. I dare say this is an uncovered issue. Even though the intention of the = authors might be to always have this instruction at the end of the = bytecode, my opinion is that in this case the execution should be = considered successful, passing the output to the dispatcher. This is a = need for compact stateless bytecodes that do not want to use feedback, = advertise parameters or save states. Regardless of the outcome, the result should be a part of the = implementor's guide. Looking forward to your comments! BR/Zacco -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: 2003. j=FAnius 23. 12:16 To: 'rohc@ietf.org' Subject: RE: [rohc] Sigcomp Implementer's Guide Hi All, As I've not received any comments about the proposed additions to the SigComp Implementer's Guide (see below, posted 17/6) then I assume = there are no objections. =20 If anyone has any comments (positive or negative) please send them to = the list by 12pm GMT tomorrow, after which time I will submit the draft. Cheers, Abbie > >Hi All, > >There have been some suggestions for additions to the=20 >implementer's guide so here's the proposed text. Any comments=20 >and other additions gratefully received. I'm planning to=20 >resubmit the draft before the -0n deadline so would appreciate=20 >comments before the end of this week please - this gives time=20 >to make changes and agree them on the list before the deadline. > >Clarification that STATE-FREE is compartment specific: >2nd paragraph added to section 3.2: > >"The STATE-FREE instruction can only free state in the compartment > that corresponds to the message being decompressed. Attempting to > free state either from another compartment or that is locally > available has no effect." > >Summary of the outcome of discussion about dynamic DMS and SMS = updates: > >"8. Dynamic Update of Resources > > Decompressor resources such as SMS and DMS can be=20 >dynamically updated > at the compressor by use of the SMS and DMS bits in returned > parameters feedback (section 9.4.9). Changing resources = dynamically > (apart from initial advertisements for each compartment) is not > expected to happen very often. > > If additional resources are advertised to a compressor then it is = up > to the implementation at the compressor whether or not to=20 >make use of > these resources. For example, if the decompressor advertises 8k = SMS > but the compressor only has 4k SMS then the compressor may=20 >choose not > to use the extra 4k (e.g. in order to monitor state saved at the > decompressor). In this case, there is no synchronisation problem. > The compressor must not use more than the most recently advertised > resources. Note that the compressor SMS is unofficial (enables > compressor to monitor decompressor state) and is separate from the > SMS advertised by the decompressor. > > Reducing the resources has potential synchronisation issues and so > should not be done unless absolutely necessary. If this is the = case > then the memory should not be reclaimed until the remote=20 >endpoint has > acknowledged the message sent with the advertisement. If state = must > be deleted to accommodate a reduction in SMS then both endpoints > should delete it according to the state retention priority (section > 6.2). The compressor should use up to the amount of resources most > recently advertised." > >There was also a suggestion about clarification that state too=20 >large for the available SMS in shared mode should be truncated=20 >(and the hash computed appropriately). =20 >IMHO this is no different from any other state that is too=20 >large and is clear in RFC 3320. Does anyone think this is a=20 >useful clarification to include? > >Best regards, > >Abbie > >Abbie Surtees >Engineer >Internet Applications and Mobility >Roke Manor Research Ltd >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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 2 09:38: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 JAA17718 for ; Wed, 2 Jul 2003 09:38:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhoD-0001Zi-Nn for rohc-archive@odin.ietf.org; Wed, 02 Jul 2003 09:38:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62Dc5ql006047 for rohc-archive@odin.ietf.org; Wed, 2 Jul 2003 09:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhoD-0001ZQ-IP for rohc-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 09: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 JAA17694 for ; Wed, 2 Jul 2003 09:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhoB-0006UF-00 for rohc-web-archive@ietf.org; Wed, 02 Jul 2003 09:38:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XhoB-0006UB-00 for rohc-web-archive@ietf.org; Wed, 02 Jul 2003 09:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xho8-0001Uj-E9; Wed, 02 Jul 2003 09:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhnD-0001HE-1D for rohc@optimus.ietf.org; Wed, 02 Jul 2003 09:37: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 JAA17627 for ; Wed, 2 Jul 2003 09:36:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhnB-0006SU-00 for rohc@ietf.org; Wed, 02 Jul 2003 09:37:01 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19XhnA-0006RG-00 for rohc@ietf.org; Wed, 02 Jul 2003 09:37:00 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 14:36:27 +0100 Message-ID: From: "Surtees, Abigail" To: "'Lajos Zaccomer (ETH)'" , "'rohc@ietf.org'" Subject: RE: [rohc] SigComp Implementer's Guide Date: Wed, 2 Jul 2003 14:36:29 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zacco, 8.7 says decompression failure occurs if the udvm attempts to read from or right to a position beyond the end of the buffer. I think that reading an instruction is included in this. Certainly if it is not clear, it was the intention of the authors that instructions going over the end of the buffer should result in decompression failure. I think that it is clear that if the end of the bytecode is not at the end of the buffer then an END-MESSAGE instruction is needed, otherwise the UDVM will go on and attempt to process the next byte as an instruction. This may or may not be a valid instruction but if it is, is unlikely to have valid parameters and decompression failure will occur. e.g. if you remove the END-MESSAGE instruction from the arithmetic torture test, you get decompression failure because the next byte in the buffer is 0. If you remove it from the sha-1 torture test you get decompression failure because the next byte is 97 which is not a valid instruction. Both however, have actually decompressed correctly up to that point. To actually have bytecode finishing at the end of the buffer would be rather hard, as the end of the buffer changes according to the length of the compressed message (assuming UDP). Consequently to work out where to put code that would finish at the end of the buffer you'd have to read the buffer length from the first two bytes of the buffer, then copy the relevant bytecode. Surely that takes more bytecode than just including the END-MESSAGE instruction? (This can be done with one byte if there is nothing to follow it, as in the torture tests, because the parameters can be assumed to be zero. If there is something following it, then that would run off the end of the buffer anyway!) Overall, I think that if the UDVM runs off the end of the buffer then there should be decompression failure. I think this is relatively clear in section 8.7 but could be clarified in the implementer's guide if people really feel that there is a need for it. Is there such a need? Best regards, Abbie >What happens, if the end of the message buffer was reached >without an END-MESSAGE instruction? > >RFC 3320 8.6 says: The UDVM stops executing instructions when >it encounters an END-MESSAGE instruction or if decompression >failure occurs (see Section 8.7 for further details). Section >8.7 however does not mention this situation. >I can see that a dummy END-MESSAGE is present in each torture >test case, but there is no test for this special situation. > >I dare say this is an uncovered issue. Even though the >intention of the authors might be to always have this >instruction at the end of the bytecode, my opinion is that in >this case the execution should be considered successful, >passing the output to the dispatcher. This is a need for >compact stateless bytecodes that do not want to use feedback, >advertise parameters or save states. > >Regardless of the outcome, the result should be a part of the >implementor's guide. > >Looking forward to your comments! > >BR/Zacco > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 2 17:27: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 RAA20132 for ; Wed, 2 Jul 2003 17:27: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 19Xp84-0007R5-9L for rohc-archive@odin.ietf.org; Wed, 02 Jul 2003 17:27:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62LR4vr028583 for rohc-archive@odin.ietf.org; Wed, 2 Jul 2003 17:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xp84-0007Qw-6G for rohc-web-archive@optimus.ietf.org; Wed, 02 Jul 2003 17:27: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 RAA20074 for ; Wed, 2 Jul 2003 17:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xp80-0001TA-00 for rohc-web-archive@ietf.org; Wed, 02 Jul 2003 17:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Xp7z-0001T6-00 for rohc-web-archive@ietf.org; Wed, 02 Jul 2003 17:26:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xp81-0007Qc-2H; Wed, 02 Jul 2003 17:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xp7Z-0007QJ-8r for rohc@optimus.ietf.org; Wed, 02 Jul 2003 17:26:33 -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 RAA20030 for ; Wed, 2 Jul 2003 17:26:27 -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 19Xp7U-0001Rx-00 for rohc@ietf.org; Wed, 02 Jul 2003 17:26:29 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19Xp7U-0001Ru-00 for rohc@ietf.org; Wed, 02 Jul 2003 17:26:28 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h62LQM108353 for ; Wed, 2 Jul 2003 16:26:22 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Jul 2003 16:26:21 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 2 Jul 2003 14:25:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 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] List Compression Date: Wed, 2 Jul 2003 16:25:47 -0500 Message-ID: Thread-Topic: [rohc] List Compression Thread-Index: AcM7oAuk6Nibqml9RjKzJmy8HaXdwgFOEhjQ To: , X-OriginalArrivalTime: 02 Jul 2003 21:25:48.0057 (UTC) FILETIME=[812D0890:01C340E0] 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Vishal, > Considering a scenario where we have an IP stream - IP/AH/UDP/RTP. > (snip) > In static list the next header field in IP header will point to UDP , > And therefore there is no way to determine which extension header is > present > in "Generic extension header list". See following text from Section 5.8.4.1 of RFC 3095 (I know we could have done a better job to make the document more readable...) All communicated uncompressed extension header items indicate their own type in their Next Header field. > Another question is considering the scenario where we have multiple IP > headers - eg. IP/IP/IP/AH/UDP/RTP then how these headers will be > organised/arranged in compressed header ? One way could be we can use = the > "Generic extension header list" to do so > OR is there some other way to do so ?? > For example in case of IR it could be - > static chain - (First IP header static info ) + (Second IP header = static > info ) + UDP static info + RTP static info > dynamic chain - (First IP header dynamic info ) + (Second dynamic IP > header dynamic info ) + UDP dynamic info + RTP dynamic info Do you mean two or three IP headers (you showed three on top and then two in the chains at bottom)? Assuming you meant 3 IP headers, here are the rules/answers: 1) "IPv6 base headers and IPv4 headers cannot be part of an extension header chain" (section 5.8). So, whether to use "generic extension = header list" depends on IP version. 2) For IR packet, you can certainly "chain" the IP headers as in your example. However, for compressed packets, ROHC does not provide efficient handling other than the first two IP headers. ROHC is pretty flexible and efficient for most common cases. But it is not designed to handle (not even mentioning efficiency) arbitrary header structures. I hope the above is a rare case which can be avoided in practice. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 3 03:41: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 DAA01207 for ; Thu, 3 Jul 2003 03:41:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyiG-0002nT-Ds for rohc-archive@odin.ietf.org; Thu, 03 Jul 2003 03:41:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h637f4U9010748 for rohc-archive@odin.ietf.org; Thu, 3 Jul 2003 03:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyiG-0002nH-6X for rohc-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 03:41: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 DAA01194 for ; Thu, 3 Jul 2003 03:41:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XyiD-0003xr-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 03:41:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XyiC-0003xo-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 03:41:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XyiD-0002mx-W4; Thu, 03 Jul 2003 03:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xyhc-0002mD-NE for rohc@optimus.ietf.org; Thu, 03 Jul 2003 03:40:24 -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 DAA01181 for ; Thu, 3 Jul 2003 03:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xyha-0003xh-00 for rohc@ietf.org; Thu, 03 Jul 2003 03:40:22 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19XyhY-0003xe-00 for rohc@ietf.org; Thu, 03 Jul 2003 03:40:21 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 08:40:16 +0100 Message-ID: From: "Surtees, Abigail" To: "'C. M. Heard'" , ROHC mailing list Cc: "Wijnen, Bert (Bert)" Subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Date: Thu, 3 Jul 2003 08:40:10 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi All, Having had a look at the MIB I have a question about it. One problem mentioned below is that rohcInstanceType should have MAX-ACCESS value of not-accessible. The fix proposed by the MIB doctor is the following. >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible >(c) remove rohcInstanceType from rohcInstanceGroup The reason it should be not-accessible is because it is used as an index into the rohcInstanceTable and the rohcContextTable. Why does it need to be an index into these tables? In my understanding (please correct me if I'm wrong) from reading the terminology draft, each instance will have its own channel ID which can uniquely identify it on an interface. A single instance can only be a compressor or a decompressor and is already identified by ifIndex and rohcChannelID, so using the rohcInstanceType as an index doesn't actually identify anything further. If it doesn't need to be an index, then a MAX-ACCESS value of read-only is acceptable. Am I missing something? Best regards, Abbie Abbie Surtees Engineer Internet Applications and Mobility Roke Manor Research Ltd Tel: +44 (0) 1794 833131 >-----Original Message----- >From: C. M. Heard [mailto:heard@pobox.com] >Sent: 25 June 2003 07:04 >To: ROHC mailing list >Cc: Wijnen, Bert (Bert) >Subject: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt > > >>>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote: >Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt >Bert> in the next week or two? > >>>>>> On Fri, 13 Jun 2003, C. M. Heard replied: >CMH> I will volunteer to do this. Based on a quick look I think >CMH> I should be able to turn around the review before June 26th. > >As noted above, I've volunteered to do a MIB Doctor review of >. For the most part, I have been >pleased with the quality of that document. However, there are a >number of things that do need to be corrected, or at least looked >at, before the document goes to the IESG. The detailed review >comments below follow the checklist from Appendix A of the draft >guidelines document . >Those who wish to respond to these review comments should do so on >the ROHC mailing list, with copies to Bert Wijnen and myself. > >0.) Title -- s/Robus/Robust/ > >1.) I-D Boilerplate -- OK > >2.) Abstract -- acronyms used in the abstract must be expanded on >first use, except for those acronyms that everyone in the IETF can >reasonably be expected to know (see Sections 4.5 and 2.9 of > or its successor document). >Certainly ROHC and LLA will need to be expanded; I'm not sure about >ESP and RTP -- please check with the RFC Editor. Here is a partial >fix: > > 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 (ROHC). > [ ... ] > >The remainder is left to the authors to sort out. > >3.) MIB Boilerplate -- OK > >4.) IPR Notices -- the required notices from RFC 2026 Sections >10.4(A) and 10.4(B) are present and no claims are noted; this >is OK if indeed there are no relevant IPR disclosures. Note, >however, that a search of the IPR statements on the IETF web site >does reveal some claims that seem like they _might_ be relevant: > > Search Results for query = '(robust or robustness or robustly) > and (header or head or headed or heading or headings or heads > or headers) and (compression or compressions)' > _________________________________________________________________ > > Match: [All....] Format: [Long.] Sort by: [Title........] > Refine search: ______________________________ Search > _________________________________________________________________ > > Documents 1 - 4 of 11 matches. More * 's indicate a better match. > _________________________________________________________________ > > [ERICSSON-ROCCO] * > ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE > UNDERTAKING In the AVT Working Group in the Internet > Engineering Task Force, a proposal "RObust Checksum-based > header COmpression (ROCCO)" dated June 22, 1999 has been > made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at > Lulea University ... > http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557 > bytes > > [ERICSSON-SIGCOMP.txt] * * * * > ... that might possibly have technical relations to the > Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt. > This draft is part of the Signaling Compression work > taking place in the Robust Header Compression (ROHC) WG. > See further Ericsson's general IPR statement: > http://www.ietf.org/ietf/IPR/ERICSSON ... > http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02, > 466 bytes > > [NOKIA-RFC3095.txt] * > ... : 1) "CID field handling in ROHC": FI 20002100, US > 09/954562, PCT/FI01/00819 2) "Variable length context > identifier for real time header compression": FI 20002307, > US 09/978479, PCT/FI01/00902 3) "Variable length encoding of > compressed data": US 09/536638, US 60/164330, ... > http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02, > 1373 bytes > > [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] * > ... This is to advise the IETF that Telefonaktiebolaget LM > Ericsson believes it owns patents and patent applications > which may relate to RFC 3095, "RObust Header Compression > (ROHC): Framework and four profiles: RTP, UDP, ESP, and > uncompressed". See further Ericsson's general IPR > statement: http://www.ietf.org/ietf/IPR/ERICSSON ... > http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST- > HEADER-COMPRESSION.txt 09/27/02, 439 bytes > > Return to the Seach Page > _________________________________________________________________ > > ht://Dig 3.1.6 > >The document authors and the WG should examine these IPR disclosures >and either determine for sure that none are required in order to >implement the MIB module or else add the notice from RFC 2026 >Section 10.4(D). (The reviewer will be satisfied if the authors >reply that the IPR section in the document is OK as it stands. All >that's being requested is an assurance that you have done your >homework.) > >5.) References -- there are some missing normative references and >some of the existing references contain minor errors or don't >exactly follow the current RFC style. The style issues are listed >only for completeness; RFC Editor will fix that in any case. > >(a) RFC 3411 needs to be added as a normative reference since >SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB >(c.f. Section 3.5). > >(b) RFC 2863 needs to be added as a normative reference since >IF-MIB appears in the IMPORTS statement of all three MIB >modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB. > >(c) [RFC3095] has an incorrect title and an author list that's not >in the standard form. > >(d) [RFC3242] has an author list that's not in the standard form. > >(e) [RFCXXXX] has an author list that's not in the standard form, >and it might be helpful to readers to indicate the I-D that will >eventually turn into this RFC-to-be. > >6.) Security Considerations Section -- there are two read/write >objects but only one is mentioned. A possible fix would be to >revise the first paragraph to read as follows: > > The managed objects defined by the ROHC-MIB module, the > ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not > have a MAX-ACCESS value of read-write and/or read-create except > rohcInstanceContextStorageTime and rohcContextStorageTime, both of > which have a MAX-ACCESS value of read-write. These objects > determine how long context information is stored after its > termination. Unauthorized access to these objects can have one of > two negative effects. If they are set to a value lower than > required, e.g. to zero, then context information about past contexts > might get lost. If they are set to a very high value, then context > information will not be deleted and memory consumption of the agent > implementation might become very high. However, unauthorized access > to these objects cannot cause harm to existing ROHC connections nor > can it allow manipulation of running instances of ROHC in a > malicious way. > >The fourth paragraph says "[a]lthough the security risks arising >from the ROHC-MIB module are not considered to be high", but the >second paragraph says "[it is] important to control even GET and/or >NOTIFY access to these objects and possibly to even encrypt the >values of these objects when sending them over the network via >SNMP." That seems contradictory. It is therefore suggest to >modify the fourth paragraph so that it reads as originally written >in the standard security considerations template: > > It is RECOMMENDED that implementers consider the security features > as provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > >7.) IANA Considerations Section -- OK (none present and none >required). > >8.) Copyright notices -- the abbreviated copyright notices that are >supposed to appear on the front page and in the DESCRIPTION clause >of each MODULE-IDENTITY invocation are missing and need to be added. >See http://www.ietf.org/ID-nits.html section 1.2, > section 4.3, and > section 3.8. > >9.) MIB compilation -- the following problems are reported by smilint: > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) >has been processed to get the following results: >smilint -m -s -l 6 -i namelength-32 ROHC-MIB > >ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-MIB:184: [5] {index-element-accessible} warning: index element >`rohcInstanceType' of row `rohcInstanceEntry' should be >not-accessible in SMIv2 MIB > >FIXES: >(a) add Counter32 to the list of things imported from SNMPv2-SMI >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible >(c) remove rohcInstanceType from rohcInstanceGroup > > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) >has been processed to get the following results: >smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB > >ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base >type `Counter32' must be imported from SNMPv2-SMI >ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base >type `Counter32' must be imported from SNMPv2-SMI > >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) >has been processed to get the following results: >smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB > >ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI >ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type >`Counter32' must be imported from SNMPv2-SMI > >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > >10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html >that is not covered above: > >(a) there are several places in the MIB modules where the lines >extend beyond column 72. Most (but not all) of these could be fixed >by eliminating the three-space indentation. Althought the RFC >Editor can probably do this, it will save time and reduce the >proabability of formatting errors in the final RFC if the authors >would fix it themselves. See ID-nits section 1.1. > >(b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to >the list of imperatives (although the standard boilerplate in RFC >2119 does not include it, it is used in the Security Considerations >section and it is defined in RFC 2119). > >(c) in Section 3, "Overview", 3rd paragraph: s/means/a means/ > >(d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/ > >(e) in Section 4, "Structure of the MIB modules", 1st paragraph: >s/Section 6/Section 5/ > >(f) in Section 4, "Structure of the MIB modules", 2nd and 4th >paragraphs: most acronyms must be expanded upon first use, >except for those that everyone in the IETF can reasonably be >expected to know. Note that this rule applies separately for >the body of the memo and the abstract; see Sections 4.7 and 2.9 >of or its successor document >and review comment (2) above. > >(g) in Section 4.1, "The ROHC-MIB module", first paragraph: the >tables are mentioned in a different order than they appear in the >MIB module, which has rohcChannelTable before rohcInstanceTable. >Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with >the order in this paragraph but are "swapped" relative to the MIB >module. It might be better if the order in the text matched that >of the MIB module. > >(h) in Section 4.1, "The ROHC-MIB module", last paragraph: >unexpanded acronym CID. > >(i) in Section 4.1.1, "rohcInstanceTable", 4th bullet: >s/storagetime/storage time/ > >(j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed >text from: > > o the state of the CID ('unused', 'active', 'expired', or > >to: > > o the state of the CID ('unused', 'active', 'expired', or > 'terminated'. > >Note: a common cause of missing text in an I-D is a line in the >nroff source that starts with a single quote as the first character >of the line. > >11.) Technical content -- the following comments pertain to the >material in Sections 3, 4, and 5. Please note that I am not an >ROHC subject matter expert and so I do not have the knowledge to >attempt a detailed verification that the MIB objects are indeed >fit for the intended purposes. I'm presuming that the WG has >already done that, so I've concentrated on MIB design issues. >Issues already covered under (9) above won't be repeated here. > >(a) in Section 3, "Overview", next to last paragraph, it is stated >that "the compressor context can be reinitialized." I didn't see >any read-write or read-create objects in the MIB module that would >support such a capability. If indeed there is no support for such >a capability then the claim should be removed. > >(b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3, >"rohcProfileTable", and also in the corresponding definitions in >the ROHC-MIB module in Section 5: it is not clear why one needs a >vendor, version number, and implementation description in both of >these tables. Indeed, except for the descriptors and OIDs that >are assigned, the definitions of rohcInstanceVendor, >rohcInstanceVersion, and rohcInstanceDescr are identical with those >for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr >(respectively). It seems to me that the objects rohcProfileVendor, >rohcProfileVersion, and rohcProfileDescr could be eliminated without >loss of capability. The designers may also wish to consider moving >rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into >the rohcChannelTable or perhaps even turning them into scalars. > >(c) in Section 4.1.3, "rohcProfileTable", there is no mention of >the per-profile Boolean flag that indicates whether the profile >has been negotiated to be used at the instance. > >(d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations >need to be changed in the following ways: > > - WG mailing list info (and optionally, charter page URL) needs to > be present in the CONTACT-INFO clause; > > - there needs to be a REVISION/DESCRIPTION clause pair with a date > identical to that in the LAST-UPDATED clause and a description > indicating that the module is the initial published version; > > - the DESCRIPTION clause needs to include an abbreviated copyright > notice (per (8) above). > >See sections 3.8 and >4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY >invocation could be changed from: > >rohcMIB MODULE-IDENTITY > LAST-UPDATED "200209251358Z" > ORGANIZATION "IETF Robust Header Compression Working Group" > CONTACT-INFO > "Juergen Quittek > NEC Europe Ltd. > Network Laboratories > Kurfuersten-Anlage 34 > 69221 Heidelberg > Germany > Tel: +49 6221 90511-15 > E-mail: quittek@ccrle.nec.de" > DESCRIPTION > "This MIB module defines a set of basic objects for > monitoring and configuring robust header compression. > The module covers information about running instances > of ROHC (compressors or decompressors) at IP interfaces. > > Information about compressor contexts and decompressor > contexts has different structure for different profiles. > Therefore it is not provided by this MIB module, but by > individual modules for dofferent profiles." > ::= { mib-2 XXX } >-- XXX to be assigned by IANA. > >to something along the lines of: > >rohcMIB MODULE-IDENTITY > LAST-UPDATED "200306250000Z" -- June 25, 2003 > ORGANIZATION "IETF Robust Header Compression Working Group" > CONTACT-INFO > "WG charter: > http://www.ietf.org/html.charters/rohc-charter.html > > Mailing Lists: > General Discussion: rohc@ietf.org > To Subscribe: rohc-request@ietf.org > In Body: subscribe your_email_address > > Editor: > Juergen Quittek > NEC Europe Ltd. > Network Laboratories > Kurfuersten-Anlage 34 > 69221 Heidelberg > Germany > Tel: +49 6221 90511-15 > E-mail: quittek@ccrle.nec.de" > DESCRIPTION > "This MIB module defines a set of basic objects for > monitoring and configuring robust header compression. > The module covers information about running instances > of ROHC (compressors or decompressors) at IP interfaces. > > Information about compressor contexts and decompressor > contexts has different structure for different profiles. > Therefore it is not provided by this MIB module, but by > individual modules for different profiles. > > Copyright (C) The Internet Society (2003). This version > of this MIB module is part of RFC yyyy; see the RFC > itself for full legal notices." >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > REVISION "200306250000Z" -- June 25, 2003 > DESCRIPTION "Initial version, published as RFC yyyy." >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > ::= { mib-2 XXX } >-- XXX to be assigned by IANA. > >with the dates changed as appropriate. [Note also a typo fix: >s/dofferent/different/.] Similar changes apply to the other >MIB modules. > >(e) in Section 5, all MIB modules: the ordering of the index >components is not consistent throughout. Specifically, although >all tables are indexed by ifIndex and rohcChannelID, the tables >without rohcInstanceType as an index component all have >{ ifIndex, rohcChannelID, ... } as a common prefix, while those >with rohcInstanceType do not: their common prefix is >{ ifIndex, rohcInstanceType, rohcChannelID, ... }. While this >will certainly work, and may be legitimate if one wishes to have a >different sort order in different tables, the MIB designers should >be aware that it tends to make the implementation harder than it >otherwise would be, because there is less indexing code that can >be shared between different tables. Unless there was a specific >reason for choosing the specific index order that is in the draft, >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. > >(f) in Section 5, all MIB modules: none of the Counter32 objects >has a discontinuity time indicator. Such an indicator is required >if events other than a reboot may result in a discontinuity (i.e., >non-monotonic counting behaviour); see the first bullet of Section >4.6.1.2 of . Since >each counter is associated with a specific interface, a good >solution in this case is to use IF-MIB's ifCounterDiscontinuityTime >for this purpose, as is done in the EtherLike-MIB (RFC 2665), >the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That >would mean adding the following or similar text > > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of ifCounterDiscontinuityTime. > >to the DESCRIPTION clause of each of the Counter32 objects. > >(g) in Section 5, all MIB modules: it is observed that many objects >are defined with SYNTAX values of of Integer32 (0..2147483647), >Integer32 (1..2147483647), and Integer32 (0..1000). While this is >certainly acceptable, it is brought to the authors' attention that >Unsigned32 is preferred when the range of values is non-negative; >see Section 4.6.1.1. >Changes, if any, are left to the authors' discretion. (Note: >current usage is consistent for all objects; if a change is made, >please be sure to do so everywhere; but see 11(m) first.) > >/********** The following comments apply to the ROHC-MIB **********/ > >(h) In the DESCRIPTION clause of rohcChannelID it says: > > The value is expected to remain constant at least from one > re-initialization of the entity's network management system > to the next re-initialization. > >I know that this same language is used in the IF-MIB, but it turns >out that indices that don't remain fixed across reboots can lead >to problems. See the thread "Referential integrity across reboots" >at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140 >Suggested remedy: change the above text to: > > 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. > >(i) In the DESCRIPTION clause of rohcChannelFeedbackFor: >s/feddback/feedback/ > >(j) In the following object definition it is not specified what >value the object should assume if there is no feedback channel: > >rohcInstanceFBChannelID OBJECT-TYPE > SYNTAX RohcChannelIdentifier > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Identifier of the channel used for feedback." > ::= { rohcInstanceEntry 4 } > >Shouldn't the DESCRIPTION clause state that the value 0 is used in >that case? It would seem to be consistent with the instructions in >the RohcChannelIdentifier DESCRIPTION clause to do this. > >(k) In the following object definition: > > rohcInstanceMRRU OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Maximum reconstructed reception unit. This is the > size of the largest reconstructed unit in octets that > the decompressor is expected to reassemble from > segments (see RFC 3095, Section 5.2.5). Note that this > size includes the CRC. If MRRU is negotiated to be 0, > no segment headers are allowed on the channel." > REFERENCE > "RFC 3095, Section 5.1.1" > ::= { rohcInstanceEntry 11 } > >the SYNTAX value and the DESCRIPTION clause are at odds. > >FIX: change the SYNTAX value to Integer32 (0..2147483647) > >(l) In the following object definition: > >rohcInstanceContextsCurrent OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Number of currently active contexts created by this instance." > ::= { rohcInstanceEntry 15 } > >a more appropriate SYNTAX value would be Integer32 (0..2147483647) >since the number of contexts cannot possibly be negative. > >(m) In the following object definition: > >rohcInstanceCompressionRatio OBJECT-TYPE > SYNTAX Integer32 (0..1000) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the compression ratio so far over all > packets on the channel served by this instance. The value is > defined as 1000 * bytes(compressed) / bytes(original) rounded > to the next integer value. The number of bytes corresponds > to all bytes of all IP packets including the IP header but > excluding all lower layer headers." > ::= { rohcInstanceEntry 20 } > >Is it theoretically possible for the compression ratio to exceed unity >in certain unfavorable cases? If so, then the range needs to be >changed to allow for that, or the DESCRIPTION clause needs to state >that the value is set to 1000 if the actual compression ratio exceeds >unity. In the latter case a more appropriate SYNTAX value would be >Gauge32 (0..1000) (see >Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION >RATIO OBJECTS. > >(n) I'm not sure if I properly understood the DESCRIPTION clause of >the following object: > >rohcProfileNegotiated OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "When retrieved, this boolean object returns true > if the profile has been negotiated to be used at > the instance, i.e. is supported also by the > corresponding compressor/decompressor." > ::= { rohcProfileEntry 7 } > >My understanding is that an instance of this object corresponding to >a particular triple should >have the value true(1) if and only if at least one context with the >same values is using that profile -- in >other words, if and only if some instance of rohcContextProfile for >the same values is equal to the rohcProfile >value. If this understanding is _not_ correct, then clarification >of the DESCRIPTION clause would be in order. > >(o) Several DESCRIPTION clauses in the ROHC-MIB refer to the >non-existent object rohcContextType. They should refer instead to >rohcInstanceType. The objects in question are: > >rohcContextDecompressorDepth >rohcContextDecompressorFailures >rohcContextDecompressorRepairs > >(p) In the following object definition [n.b. the above correction >has been assumed to be applied]: > >rohcContextDecompressorDepth OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates whether reverse decompression, for > example as described in RFC 3095, Section 6.1, is used > on this channel or not, and if used, to what extent. > > Its value is only valid for decompressor contexts, i.e. > if rohcInstanceType has the value decompressor(2). > > The value of the reverse decompression depth indicates > the maximum number of packets that are buffered, and thus > possibly be reverse decompressed by the decompressor. > A zero (0) value means that reverse decompression is not > used." > ::= { rohcContextEntry 7 } > >it is not clear whether this object should have the value 0 for >compressor contexts, or whether it should not be instantiated at >all for such contexts. > >(q) The rohcCompliance DESCRIPTION clause should mention that the >ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of >, last paragraph >before end note. Examples may be found in the dot3Compliance2 >statement in , the >mauModIfCompl3 statement in , >or the etherWisCompliance in >(although it is requested that the embedded citations be avoided). > >/*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/ > >(r) The rohcUncmprCompliance DESCRIPTION clause should mention that >the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as >prerequisites. See 11(q) above for examples. > >/******** The following comments apply to the ROHC-RTP-MIB ********/ > >(s) The DESCRIPTION clauses of several columnar objects in the >rohcRtpContextTable state that those objects are valid only for >certain profiles or for certain contexts. The objects in question >are: > >rohcRtpContextAlwaysPad >rohcRtpContextLargePktsAllowed >rohcRtpContextVerifyPeriod >rohcRtpContextSizesAllowed >rohcRtpContextSizesUsed > >If the intent is that those objects are to be instantiated only for >the profiles or contexts to which they apply, then that fact should >be made explicit in the DESCRIPTION clauses. > >(t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and >rohcRtpContextSizesUsed both appear to have the same three >typographical errors: > > rohcRtpContextSizesAllowed OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is only valid for decompressor > contexts, i.e. if rohcContextType of the cooresponding > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > rohcContextEntry has the value compressor(2). > ^^^^^^^^^^^^^ > > This object contains the number of different packet sizes > that may be used in the context." > REFERENCE > "RFC 3095, Section 6.3.1" > ::= { rohcRtpContextEntry 10 } > > rohcRtpContextSizesUsed OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is only valid for decompressor > contexts, i.e. if rohcContextType of the cooresponding > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > rohcContextEntry has the value compressor(2). > ^^^^^^^^^^^^^ > > This object contains the number of different packet sizes > that are used in the context." > REFERENCE > "RFC 3095, Section 6.3.1" > ::= { rohcRtpContextEntry 11 } > >Suggested fixes: s/rohcContextType/rohcInstanceType/ > s/cooresponding/corresponding/ > s/compressor(2)/decompressor(2)/ > >(u) There are some design issues with the rohcRtpPacketSizeTable: > >- the index column rohcRtpPacketSize with has values in the range >0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that >PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive >integers, i.e., the value 0 is excluded as it does not make sense. >FIX: change the range to 1..2147483647. (This also avoids >running afoul of the SMIv2 rule that index values of zero should >be avoided, except in special cases.) > >- the TruthValue column rohcRtpPacketSizeAllowed seems to be >unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that >"packet sizes not in the set of values for [PACKET_SIZES_ALLOWED] >MUST NOT be used", it seems that an agent would never need to >instantiate any of the other columns if rohcRtpPacketSizeAllowed >had the value false(2). In other words, any row for which this >objects is false should simply be absent from the table. > >(v) The rohcRtpCompliance DESCRIPTION clause should mention that >the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as >prerequisites. See 11(q) above for examples. > >This concludes the review of . > >Regards, > >Mike Heard > > >_______________________________________________ >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 Jul 3 11:54: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 LAA19557 for ; Thu, 3 Jul 2003 11:54:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PM-0004N5-9G for rohc-archive@odin.ietf.org; Thu, 03 Jul 2003 11:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Fs4V0016793 for rohc-archive@odin.ietf.org; Thu, 3 Jul 2003 11:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PM-0004Mc-4G for rohc-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:54: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 LAA19518 for ; Thu, 3 Jul 2003 11:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6PK-00019S-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 11:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y6PI-00019H-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 11:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PI-0004LP-Cy; Thu, 03 Jul 2003 11:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xi8h-00031m-NI for rohc@optimus.ietf.org; Wed, 02 Jul 2003 09:59:15 -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 JAA20011 for ; Wed, 2 Jul 2003 09:59:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xi8e-0007Ox-00 for rohc@ietf.org; Wed, 02 Jul 2003 09:59:12 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Xi8b-0007Ot-00 for rohc@ietf.org; Wed, 02 Jul 2003 09:59:09 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120] (may be forged)) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h62DwtK8016711; Wed, 2 Jul 2003 15:59:06 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 2 Jul 2003 15:59:21 +0200 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'Surtees, Abigail'" , "'rohc@ietf.org'" Subject: RE: [rohc] SigComp Implementer's Guide Date: Wed, 2 Jul 2003 15:58:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I agree. I forgot that section, sorry. Anyway, with a bootstrap bytecode one could upload bytecode anywhere, = and then the area of the bootstrap code might be used in the circular = buffer that might be a little larger this way. The cost of reading the = UMS is out of question here. But, regarding 8.7, it's only theory. Thanx a lot for the comments! BR/Zacco -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: 2003. j=FAlius 2. 15:36 To: Lajos Zaccomer (ET/ETH); 'rohc@ietf.org' Subject: RE: [rohc] SigComp Implementer's Guide Hi Zacco, 8.7 says decompression failure occurs if the udvm attempts to read from = or right to a position beyond the end of the buffer. I think that = reading an instruction is included in this. Certainly if it is not clear, it was the intention of the authors that = instructions going over the end of the buffer should result in = decompression failure. I think that it is clear that if the end of the bytecode is not at the = end of the buffer then an END-MESSAGE instruction is needed, otherwise = the UDVM will go on and attempt to process the next byte as an = instruction. This may or may not be a valid instruction but if it is, = is unlikely to have valid parameters and decompression failure will = occur. e.g. if you remove the END-MESSAGE instruction from the arithmetic = torture test, you get decompression failure because the next byte in = the buffer is 0. If you remove it from the sha-1 torture test you get = decompression failure because the next byte is 97 which is not a valid = instruction. Both however, have actually decompressed correctly up to = that point. To actually have bytecode finishing at the end of the buffer would be = rather hard, as the end of the buffer changes according to the length = of the compressed message (assuming UDP). Consequently to work out = where to put code that would finish at the end of the buffer you'd have = to read the buffer length from the first two bytes of the buffer, then = copy the relevant bytecode. Surely that takes more bytecode than just = including the END-MESSAGE instruction? (This can be done with one byte = if there is nothing to follow it, as in the torture tests, because the = parameters can be assumed to be zero. If there is something following = it, then that would run off the end of the buffer anyway!) Overall, I think that if the UDVM runs off the end of the buffer then = there should be decompression failure. I think this is relatively = clear in section 8.7 but could be clarified in the implementer's guide = if people really feel that there is a need for it. Is there such a need? Best regards, Abbie >What happens, if the end of the message buffer was reached=20 >without an END-MESSAGE instruction? > >RFC 3320 8.6 says: The UDVM stops executing instructions when=20 >it encounters an END-MESSAGE instruction or if decompression=20 >failure occurs (see Section 8.7 for further details). Section=20 >8.7 however does not mention this situation. >I can see that a dummy END-MESSAGE is present in each torture=20 >test case, but there is no test for this special situation. > >I dare say this is an uncovered issue. Even though the=20 >intention of the authors might be to always have this=20 >instruction at the end of the bytecode, my opinion is that in=20 >this case the execution should be considered successful,=20 >passing the output to the dispatcher. This is a need for=20 >compact stateless bytecodes that do not want to use feedback,=20 >advertise parameters or save states. > >Regardless of the outcome, the result should be a part of the=20 >implementor's guide. > >Looking forward to your comments! > >BR/Zacco > -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, = Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is = confidential to Roke Manor Research Ltd and must not be passed to any third party = without permission. This communication is for information only and shall not = create or change any contractual relationship. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 3 11:54:35 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 LAA19577 for ; Thu, 3 Jul 2003 11:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PM-0004NE-A3 for rohc-archive@odin.ietf.org; Thu, 03 Jul 2003 11:54:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Fs4JE016799 for rohc-archive@odin.ietf.org; Thu, 3 Jul 2003 11:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PM-0004Md-4x for rohc-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:54: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 LAA19512 for ; Thu, 3 Jul 2003 11:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6PK-00019K-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 11:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y6PI-00019D-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 11:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PI-0004Lc-Lx; Thu, 03 Jul 2003 11:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xjwp-0001Sf-PH for rohc@optimus.ietf.org; Wed, 02 Jul 2003 11:55: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 LAA28308 for ; Wed, 2 Jul 2003 11:55:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xjwo-0002or-00 for rohc@ietf.org; Wed, 02 Jul 2003 11:55:06 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Xjwn-0002o3-00 for rohc@ietf.org; Wed, 02 Jul 2003 11:55:05 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h62FsUt10175 for ; Wed, 2 Jul 2003 10:54:30 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 17:54:28 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501ED5E87@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "C. M. Heard" , ROHC mailing list Cc: "Wijnen, Bert (Bert)" Date: Wed, 2 Jul 2003 17:54:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rohc] RE: MIB Doctor review of draft-ietf-rohc-mib-rtp-06.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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Thanks for your thourough review Mike! So I guess we'll see answers from the authors/wg and most probably a new revision sometime in the future (soon I hope, cause it helps for a MIB doctor to quickly re-check while the data is still kind of fresh in his/her mind). Thanks, Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: woensdag 25 juni 2003 8:04 > To: ROHC mailing list > Cc: Wijnen, Bert (Bert) > Subject: MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt > > > >>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote: > Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt > Bert> in the next week or two? > > >>>>> On Fri, 13 Jun 2003, C. M. Heard replied: > CMH> I will volunteer to do this. Based on a quick look I think > CMH> I should be able to turn around the review before June 26th. > > As noted above, I've volunteered to do a MIB Doctor review of > . For the most part, I have been > pleased with the quality of that document. However, there are a > number of things that do need to be corrected, or at least looked > at, before the document goes to the IESG. The detailed review > comments below follow the checklist from Appendix A of the draft > guidelines document . > Those who wish to respond to these review comments should do so on > the ROHC mailing list, with copies to Bert Wijnen and myself. > > 0.) Title -- s/Robus/Robust/ > > 1.) I-D Boilerplate -- OK > > 2.) Abstract -- acronyms used in the abstract must be expanded on > first use, except for those acronyms that everyone in the IETF can > reasonably be expected to know (see Sections 4.5 and 2.9 of > or its successor document). > Certainly ROHC and LLA will need to be expanded; I'm not sure about > ESP and RTP -- please check with the RFC Editor. Here is a partial > fix: > > 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 (ROHC). > [ ... ] > > The remainder is left to the authors to sort out. > > 3.) MIB Boilerplate -- OK > > 4.) IPR Notices -- the required notices from RFC 2026 Sections > 10.4(A) and 10.4(B) are present and no claims are noted; this > is OK if indeed there are no relevant IPR disclosures. Note, > however, that a search of the IPR statements on the IETF web site > does reveal some claims that seem like they _might_ be relevant: > > Search Results for query = '(robust or robustness or robustly) > and (header or head or headed or heading or headings or heads > or headers) and (compression or compressions)' > _________________________________________________________________ > > Match: [All....] Format: [Long.] Sort by: [Title........] > Refine search: ______________________________ Search > _________________________________________________________________ > > Documents 1 - 4 of 11 matches. More * 's indicate a better match. > _________________________________________________________________ > > [ERICSSON-ROCCO] * > ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE > UNDERTAKING In the AVT Working Group in the Internet > Engineering Task Force, a proposal "RObust Checksum-based > header COmpression (ROCCO)" dated June 22, 1999 has been > made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at > Lulea University ... > http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557 > bytes > > [ERICSSON-SIGCOMP.txt] * * * * > ... that might possibly have technical relations to the > Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt. > This draft is part of the Signaling Compression work > taking place in the Robust Header Compression (ROHC) WG. > See further Ericsson's general IPR statement: > http://www.ietf.org/ietf/IPR/ERICSSON ... > http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02, > 466 bytes > > [NOKIA-RFC3095.txt] * > ... : 1) "CID field handling in ROHC": FI 20002100, US > 09/954562, PCT/FI01/00819 2) "Variable length context > identifier for real time header compression": FI 20002307, > US 09/978479, PCT/FI01/00902 3) "Variable length encoding of > compressed data": US 09/536638, US 60/164330, ... > http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02, > 1373 bytes > > [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] * > ... This is to advise the IETF that Telefonaktiebolaget LM > Ericsson believes it owns patents and patent applications > which may relate to RFC 3095, "RObust Header Compression > (ROHC): Framework and four profiles: RTP, UDP, ESP, and > uncompressed". See further Ericsson's general IPR > statement: http://www.ietf.org/ietf/IPR/ERICSSON ... > http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST- > HEADER-COMPRESSION.txt 09/27/02, 439 bytes > > Return to the Seach Page > _________________________________________________________________ > > ht://Dig 3.1.6 > > The document authors and the WG should examine these IPR disclosures > and either determine for sure that none are required in order to > implement the MIB module or else add the notice from RFC 2026 > Section 10.4(D). (The reviewer will be satisfied if the authors > reply that the IPR section in the document is OK as it stands. All > that's being requested is an assurance that you have done your > homework.) > > 5.) References -- there are some missing normative references and > some of the existing references contain minor errors or don't > exactly follow the current RFC style. The style issues are listed > only for completeness; RFC Editor will fix that in any case. > > (a) RFC 3411 needs to be added as a normative reference since > SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB > (c.f. Section 3.5). > > (b) RFC 2863 needs to be added as a normative reference since > IF-MIB appears in the IMPORTS statement of all three MIB > modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB. > > (c) [RFC3095] has an incorrect title and an author list that's not > in the standard form. > > (d) [RFC3242] has an author list that's not in the standard form. > > (e) [RFCXXXX] has an author list that's not in the standard form, > and it might be helpful to readers to indicate the I-D that will > eventually turn into this RFC-to-be. > > 6.) Security Considerations Section -- there are two read/write > objects but only one is mentioned. A possible fix would be to > revise the first paragraph to read as follows: > > The managed objects defined by the ROHC-MIB module, the > ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not > have a MAX-ACCESS value of read-write and/or read-create except > rohcInstanceContextStorageTime and rohcContextStorageTime, both of > which have a MAX-ACCESS value of read-write. These objects > determine how long context information is stored after its > termination. Unauthorized access to these objects can have one of > two negative effects. If they are set to a value lower than > required, e.g. to zero, then context information about past contexts > might get lost. If they are set to a very high value, then context > information will not be deleted and memory consumption of the agent > implementation might become very high. However, unauthorized access > to these objects cannot cause harm to existing ROHC connections nor > can it allow manipulation of running instances of ROHC in a > malicious way. > > The fourth paragraph says "[a]lthough the security risks arising > from the ROHC-MIB module are not considered to be high", but the > second paragraph says "[it is] important to control even GET and/or > NOTIFY access to these objects and possibly to even encrypt the > values of these objects when sending them over the network via > SNMP." That seems contradictory. It is therefore suggest to > modify the fourth paragraph so that it reads as originally written > in the standard security considerations template: > > It is RECOMMENDED that implementers consider the security features > as provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > > 7.) IANA Considerations Section -- OK (none present and none > required). > > 8.) Copyright notices -- the abbreviated copyright notices that are > supposed to appear on the front page and in the DESCRIPTION clause > of each MODULE-IDENTITY invocation are missing and need to be added. > See http://www.ietf.org/ID-nits.html section 1.2, > section 4.3, and > section 3.8. > > 9.) MIB compilation -- the following problems are reported by smilint: > > This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > has been processed to get the following results: > smilint -m -s -l 6 -i namelength-32 ROHC-MIB > > ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-MIB:184: [5] {index-element-accessible} warning: index element > `rohcInstanceType' of row `rohcInstanceEntry' should be > not-accessible in SMIv2 MIB > > FIXES: > (a) add Counter32 to the list of things imported from SNMPv2-SMI > (b) change MAX-ACCESS value of rohcInstanceType to not-accessible > (c) remove rohcInstanceType from rohcInstanceGroup > > > This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > has been processed to get the following results: > smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB > > ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base > type `Counter32' must be imported from SNMPv2-SMI > ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base > type `Counter32' must be imported from SNMPv2-SMI > > FIX: add Counter32 to the list of things imported from SNMPv2-SMI > > > This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > has been processed to get the following results: > smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB > > ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type > `Counter32' must be imported from SNMPv2-SMI > > FIX: add Counter32 to the list of things imported from SNMPv2-SMI > > 10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html > that is not covered above: > > (a) there are several places in the MIB modules where the lines > extend beyond column 72. Most (but not all) of these could be fixed > by eliminating the three-space indentation. Althought the RFC > Editor can probably do this, it will save time and reduce the > proabability of formatting errors in the final RFC if the authors > would fix it themselves. See ID-nits section 1.1. > > (b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to > the list of imperatives (although the standard boilerplate in RFC > 2119 does not include it, it is used in the Security Considerations > section and it is defined in RFC 2119). > > (c) in Section 3, "Overview", 3rd paragraph: s/means/a means/ > > (d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/ > > (e) in Section 4, "Structure of the MIB modules", 1st paragraph: > s/Section 6/Section 5/ > > (f) in Section 4, "Structure of the MIB modules", 2nd and 4th > paragraphs: most acronyms must be expanded upon first use, > except for those that everyone in the IETF can reasonably be > expected to know. Note that this rule applies separately for > the body of the memo and the abstract; see Sections 4.7 and 2.9 > of or its successor document > and review comment (2) above. > > (g) in Section 4.1, "The ROHC-MIB module", first paragraph: the > tables are mentioned in a different order than they appear in the > MIB module, which has rohcChannelTable before rohcInstanceTable. > Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with > the order in this paragraph but are "swapped" relative to the MIB > module. It might be better if the order in the text matched that > of the MIB module. > > (h) in Section 4.1, "The ROHC-MIB module", last paragraph: > unexpanded acronym CID. > > (i) in Section 4.1.1, "rohcInstanceTable", 4th bullet: > s/storagetime/storage time/ > > (j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed > text from: > > o the state of the CID ('unused', 'active', 'expired', or > > to: > > o the state of the CID ('unused', 'active', 'expired', or > 'terminated'. > > Note: a common cause of missing text in an I-D is a line in the > nroff source that starts with a single quote as the first character > of the line. > > 11.) Technical content -- the following comments pertain to the > material in Sections 3, 4, and 5. Please note that I am not an > ROHC subject matter expert and so I do not have the knowledge to > attempt a detailed verification that the MIB objects are indeed > fit for the intended purposes. I'm presuming that the WG has > already done that, so I've concentrated on MIB design issues. > Issues already covered under (9) above won't be repeated here. > > (a) in Section 3, "Overview", next to last paragraph, it is stated > that "the compressor context can be reinitialized." I didn't see > any read-write or read-create objects in the MIB module that would > support such a capability. If indeed there is no support for such > a capability then the claim should be removed. > > (b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3, > "rohcProfileTable", and also in the corresponding definitions in > the ROHC-MIB module in Section 5: it is not clear why one needs a > vendor, version number, and implementation description in both of > these tables. Indeed, except for the descriptors and OIDs that > are assigned, the definitions of rohcInstanceVendor, > rohcInstanceVersion, and rohcInstanceDescr are identical with those > for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr > (respectively). It seems to me that the objects rohcProfileVendor, > rohcProfileVersion, and rohcProfileDescr could be eliminated without > loss of capability. The designers may also wish to consider moving > rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into > the rohcChannelTable or perhaps even turning them into scalars. > > (c) in Section 4.1.3, "rohcProfileTable", there is no mention of > the per-profile Boolean flag that indicates whether the profile > has been negotiated to be used at the instance. > > (d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations > need to be changed in the following ways: > > - WG mailing list info (and optionally, charter page URL) needs to > be present in the CONTACT-INFO clause; > > - there needs to be a REVISION/DESCRIPTION clause pair with a date > identical to that in the LAST-UPDATED clause and a description > indicating that the module is the initial published version; > > - the DESCRIPTION clause needs to include an abbreviated copyright > notice (per (8) above). > > See sections 3.8 and > 4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY > invocation could be changed from: > > rohcMIB MODULE-IDENTITY > LAST-UPDATED "200209251358Z" > ORGANIZATION "IETF Robust Header Compression Working Group" > CONTACT-INFO > "Juergen Quittek > NEC Europe Ltd. > Network Laboratories > Kurfuersten-Anlage 34 > 69221 Heidelberg > Germany > Tel: +49 6221 90511-15 > E-mail: quittek@ccrle.nec.de" > DESCRIPTION > "This MIB module defines a set of basic objects for > monitoring and configuring robust header compression. > The module covers information about running instances > of ROHC (compressors or decompressors) at IP interfaces. > > Information about compressor contexts and decompressor > contexts has different structure for different profiles. > Therefore it is not provided by this MIB module, but by > individual modules for dofferent profiles." > ::= { mib-2 XXX } > -- XXX to be assigned by IANA. > > to something along the lines of: > > rohcMIB MODULE-IDENTITY > LAST-UPDATED "200306250000Z" -- June 25, 2003 > ORGANIZATION "IETF Robust Header Compression Working Group" > CONTACT-INFO > "WG charter: > http://www.ietf.org/html.charters/rohc-charter.html > > Mailing Lists: > General Discussion: rohc@ietf.org > To Subscribe: rohc-request@ietf.org > In Body: subscribe your_email_address > > Editor: > Juergen Quittek > NEC Europe Ltd. > Network Laboratories > Kurfuersten-Anlage 34 > 69221 Heidelberg > Germany > Tel: +49 6221 90511-15 > E-mail: quittek@ccrle.nec.de" > DESCRIPTION > "This MIB module defines a set of basic objects for > monitoring and configuring robust header compression. > The module covers information about running instances > of ROHC (compressors or decompressors) at IP interfaces. > > Information about compressor contexts and decompressor > contexts has different structure for different profiles. > Therefore it is not provided by this MIB module, but by > individual modules for different profiles. > > Copyright (C) The Internet Society (2003). This version > of this MIB module is part of RFC yyyy; see the RFC > itself for full legal notices." > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > REVISION "200306250000Z" -- June 25, 2003 > DESCRIPTION "Initial version, published as RFC yyyy." > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > ::= { mib-2 XXX } > -- XXX to be assigned by IANA. > > with the dates changed as appropriate. [Note also a typo fix: > s/dofferent/different/.] Similar changes apply to the other > MIB modules. > > (e) in Section 5, all MIB modules: the ordering of the index > components is not consistent throughout. Specifically, although > all tables are indexed by ifIndex and rohcChannelID, the tables > without rohcInstanceType as an index component all have > { ifIndex, rohcChannelID, ... } as a common prefix, while those > with rohcInstanceType do not: their common prefix is > { ifIndex, rohcInstanceType, rohcChannelID, ... }. While this > will certainly work, and may be legitimate if one wishes to have a > different sort order in different tables, the MIB designers should > be aware that it tends to make the implementation harder than it > otherwise would be, because there is less indexing code that can > be shared between different tables. Unless there was a specific > reason for choosing the specific index order that is in the draft, > 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. > > (f) in Section 5, all MIB modules: none of the Counter32 objects > has a discontinuity time indicator. Such an indicator is required > if events other than a reboot may result in a discontinuity (i.e., > non-monotonic counting behaviour); see the first bullet of Section > 4.6.1.2 of . Since > each counter is associated with a specific interface, a good > solution in this case is to use IF-MIB's ifCounterDiscontinuityTime > for this purpose, as is done in the EtherLike-MIB (RFC 2665), > the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That > would mean adding the following or similar text > > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of ifCounterDiscontinuityTime. > > to the DESCRIPTION clause of each of the Counter32 objects. > > (g) in Section 5, all MIB modules: it is observed that many objects > are defined with SYNTAX values of of Integer32 (0..2147483647), > Integer32 (1..2147483647), and Integer32 (0..1000). While this is > certainly acceptable, it is brought to the authors' attention that > Unsigned32 is preferred when the range of values is non-negative; > see Section 4.6.1.1. > Changes, if any, are left to the authors' discretion. (Note: > current usage is consistent for all objects; if a change is made, > please be sure to do so everywhere; but see 11(m) first.) > > /********** The following comments apply to the ROHC-MIB **********/ > > (h) In the DESCRIPTION clause of rohcChannelID it says: > > The value is expected to remain constant at least from one > re-initialization of the entity's network management system > to the next re-initialization. > > I know that this same language is used in the IF-MIB, but it turns > out that indices that don't remain fixed across reboots can lead > to problems. See the thread "Referential integrity across reboots" > at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140 > Suggested remedy: change the above text to: > > 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. > > (i) In the DESCRIPTION clause of rohcChannelFeedbackFor: > s/feddback/feedback/ > > (j) In the following object definition it is not specified what > value the object should assume if there is no feedback channel: > > rohcInstanceFBChannelID OBJECT-TYPE > SYNTAX RohcChannelIdentifier > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Identifier of the channel used for feedback." > ::= { rohcInstanceEntry 4 } > > Shouldn't the DESCRIPTION clause state that the value 0 is used in > that case? It would seem to be consistent with the instructions in > the RohcChannelIdentifier DESCRIPTION clause to do this. > > (k) In the following object definition: > > rohcInstanceMRRU OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Maximum reconstructed reception unit. This is the > size of the largest reconstructed unit in octets that > the decompressor is expected to reassemble from > segments (see RFC 3095, Section 5.2.5). Note that this > size includes the CRC. If MRRU is negotiated to be 0, > no segment headers are allowed on the channel." > REFERENCE > "RFC 3095, Section 5.1.1" > ::= { rohcInstanceEntry 11 } > > the SYNTAX value and the DESCRIPTION clause are at odds. > > FIX: change the SYNTAX value to Integer32 (0..2147483647) > > (l) In the following object definition: > > rohcInstanceContextsCurrent OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Number of currently active contexts created by this > instance." > ::= { rohcInstanceEntry 15 } > > a more appropriate SYNTAX value would be Integer32 (0..2147483647) > since the number of contexts cannot possibly be negative. > > (m) In the following object definition: > > rohcInstanceCompressionRatio OBJECT-TYPE > SYNTAX Integer32 (0..1000) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the compression ratio so far over all > packets on the channel served by this instance. The value is > defined as 1000 * bytes(compressed) / bytes(original) rounded > to the next integer value. The number of bytes corresponds > to all bytes of all IP packets including the IP header but > excluding all lower layer headers." > ::= { rohcInstanceEntry 20 } > > Is it theoretically possible for the compression ratio to exceed unity > in certain unfavorable cases? If so, then the range needs to be > changed to allow for that, or the DESCRIPTION clause needs to state > that the value is set to 1000 if the actual compression ratio exceeds > unity. In the latter case a more appropriate SYNTAX value would be > Gauge32 (0..1000) (see > Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION > RATIO OBJECTS. > > (n) I'm not sure if I properly understood the DESCRIPTION clause of > the following object: > > rohcProfileNegotiated OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "When retrieved, this boolean object returns true > if the profile has been negotiated to be used at > the instance, i.e. is supported also by the > corresponding compressor/decompressor." > ::= { rohcProfileEntry 7 } > > My understanding is that an instance of this object corresponding to > a particular triple should > have the value true(1) if and only if at least one context with the > same values is using that profile -- in > other words, if and only if some instance of rohcContextProfile for > the same values is equal to the rohcProfile > value. If this understanding is _not_ correct, then clarification > of the DESCRIPTION clause would be in order. > > (o) Several DESCRIPTION clauses in the ROHC-MIB refer to the > non-existent object rohcContextType. They should refer instead to > rohcInstanceType. The objects in question are: > > rohcContextDecompressorDepth > rohcContextDecompressorFailures > rohcContextDecompressorRepairs > > (p) In the following object definition [n.b. the above correction > has been assumed to be applied]: > > rohcContextDecompressorDepth OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates whether reverse decompression, for > example as described in RFC 3095, Section 6.1, is used > on this channel or not, and if used, to what extent. > > Its value is only valid for decompressor contexts, i.e. > if rohcInstanceType has the value decompressor(2). > > The value of the reverse decompression depth indicates > the maximum number of packets that are buffered, and thus > possibly be reverse decompressed by the decompressor. > A zero (0) value means that reverse decompression is not > used." > ::= { rohcContextEntry 7 } > > it is not clear whether this object should have the value 0 for > compressor contexts, or whether it should not be instantiated at > all for such contexts. > > (q) The rohcCompliance DESCRIPTION clause should mention that the > ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of > , last paragraph > before end note. Examples may be found in the dot3Compliance2 > statement in , the > mauModIfCompl3 statement in , > or the etherWisCompliance in > (although it is requested that the embedded citations be avoided). > > /*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/ > > (r) The rohcUncmprCompliance DESCRIPTION clause should mention that > the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as > prerequisites. See 11(q) above for examples. > > /******** The following comments apply to the ROHC-RTP-MIB ********/ > > (s) The DESCRIPTION clauses of several columnar objects in the > rohcRtpContextTable state that those objects are valid only for > certain profiles or for certain contexts. The objects in question > are: > > rohcRtpContextAlwaysPad > rohcRtpContextLargePktsAllowed > rohcRtpContextVerifyPeriod > rohcRtpContextSizesAllowed > rohcRtpContextSizesUsed > > If the intent is that those objects are to be instantiated only for > the profiles or contexts to which they apply, then that fact should > be made explicit in the DESCRIPTION clauses. > > (t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and > rohcRtpContextSizesUsed both appear to have the same three > typographical errors: > > rohcRtpContextSizesAllowed OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is only valid for decompressor > contexts, i.e. if rohcContextType of the cooresponding > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > rohcContextEntry has the value compressor(2). > ^^^^^^^^^^^^^ > > This object contains the number of different packet sizes > that may be used in the context." > REFERENCE > "RFC 3095, Section 6.3.1" > ::= { rohcRtpContextEntry 10 } > > rohcRtpContextSizesUsed OBJECT-TYPE > SYNTAX Integer32 (1..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is only valid for decompressor > contexts, i.e. if rohcContextType of the cooresponding > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > rohcContextEntry has the value compressor(2). > ^^^^^^^^^^^^^ > > This object contains the number of different packet sizes > that are used in the context." > REFERENCE > "RFC 3095, Section 6.3.1" > ::= { rohcRtpContextEntry 11 } > > Suggested fixes: s/rohcContextType/rohcInstanceType/ > s/cooresponding/corresponding/ > s/compressor(2)/decompressor(2)/ > > (u) There are some design issues with the rohcRtpPacketSizeTable: > > - the index column rohcRtpPacketSize with has values in the range > 0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that > PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive > integers, i.e., the value 0 is excluded as it does not make sense. > FIX: change the range to 1..2147483647. (This also avoids > running afoul of the SMIv2 rule that index values of zero should > be avoided, except in special cases.) > > - the TruthValue column rohcRtpPacketSizeAllowed seems to be > unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that > "packet sizes not in the set of values for [PACKET_SIZES_ALLOWED] > MUST NOT be used", it seems that an agent would never need to > instantiate any of the other columns if rohcRtpPacketSizeAllowed > had the value false(2). In other words, any row for which this > objects is false should simply be absent from the table. > > (v) The rohcRtpCompliance DESCRIPTION clause should mention that > the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as > prerequisites. See 11(q) above for examples. > > This concludes the review of . > > Regards, > > Mike Heard > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 3 12:44:56 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 LAA19576 for ; Thu, 3 Jul 2003 11:54:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PM-0004Mk-5f for rohc-archive@odin.ietf.org; Thu, 03 Jul 2003 11:54:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Fs4Y4016776 for rohc-archive@odin.ietf.org; Thu, 3 Jul 2003 11:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PL-0004MV-UX for rohc-web-archive@optimus.ietf.org; Thu, 03 Jul 2003 11:54: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 LAA19514 for ; Thu, 3 Jul 2003 11:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6PK-00019Q-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 11:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Y6PJ-00019F-00 for rohc-web-archive@ietf.org; Thu, 03 Jul 2003 11:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6PJ-0004Lp-0e; Thu, 03 Jul 2003 11:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xzed-0004QY-CY for rohc@optimus.ietf.org; Thu, 03 Jul 2003 04:41:23 -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 EAA02524 for ; Thu, 3 Jul 2003 04:41:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xzea-0004He-00 for rohc@ietf.org; Thu, 03 Jul 2003 04:41:20 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19XzeZ-0004H8-00 for rohc@ietf.org; Thu, 03 Jul 2003 04:41:19 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h638ekR02525 for ; Thu, 3 Jul 2003 03:40:47 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 10:40:45 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501ED5F03@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Surtees, Abigail" , "'C. M. Heard'" , ROHC mailing list Cc: "Wijnen, Bert (Bert)" Subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Date: Thu, 3 Jul 2003 10:40:43 +0200 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , So this is something the WG needs to discuss. If rohcInstanceType is not needed to uniquely identify an instance in the tables, then it is probably better to NOT use it as an index. And if not used as index, then indeed read-only access is fine. Thanks, Bert > -----Original Message----- > From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] > Sent: donderdag 3 juli 2003 9:40 > To: 'C. M. Heard'; ROHC mailing list > Cc: Wijnen, Bert (Bert) > Subject: RE: [rohc] MIB Doctor review of > draft-ietf-rohc-mib-rtp-06.txt > > > Hi All, > > Having had a look at the MIB I have a question about it. One problem > mentioned below is that rohcInstanceType should have > MAX-ACCESS value of > not-accessible. > > The fix proposed by the MIB doctor is the following. > > >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible > >(c) remove rohcInstanceType from rohcInstanceGroup > > The reason it should be not-accessible is because it is used > as an index > into the rohcInstanceTable and the rohcContextTable. > > Why does it need to be an index into these tables? > > In my understanding (please correct me if I'm wrong) from reading the > terminology draft, each instance will have its own channel ID > which can > uniquely identify it on an interface. A single instance can only be a > compressor or a decompressor and is already identified by ifIndex and > rohcChannelID, so using the rohcInstanceType as an index > doesn't actually > identify anything further. > If it doesn't need to be an index, then a MAX-ACCESS value of > read-only is > acceptable. > > Am I missing something? > > Best regards, > > Abbie > Abbie Surtees > Engineer > Internet Applications and Mobility > Roke Manor Research Ltd > Tel: +44 (0) 1794 833131 > > >-----Original Message----- > >From: C. M. Heard [mailto:heard@pobox.com] > >Sent: 25 June 2003 07:04 > >To: ROHC mailing list > >Cc: Wijnen, Bert (Bert) > >Subject: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt > > > > > >>>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote: > >Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt > >Bert> in the next week or two? > > > >>>>>> On Fri, 13 Jun 2003, C. M. Heard replied: > >CMH> I will volunteer to do this. Based on a quick look I think > >CMH> I should be able to turn around the review before June 26th. > > > >As noted above, I've volunteered to do a MIB Doctor review of > >. For the most part, I have been > >pleased with the quality of that document. However, there are a > >number of things that do need to be corrected, or at least looked > >at, before the document goes to the IESG. The detailed review > >comments below follow the checklist from Appendix A of the draft > >guidelines document . > >Those who wish to respond to these review comments should do so on > >the ROHC mailing list, with copies to Bert Wijnen and myself. > > > >0.) Title -- s/Robus/Robust/ > > > >1.) I-D Boilerplate -- OK > > > >2.) Abstract -- acronyms used in the abstract must be expanded on > >first use, except for those acronyms that everyone in the IETF can > >reasonably be expected to know (see Sections 4.5 and 2.9 of > > or its successor document). > >Certainly ROHC and LLA will need to be expanded; I'm not sure about > >ESP and RTP -- please check with the RFC Editor. Here is a partial > >fix: > > > > 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 (ROHC). > > [ ... ] > > > >The remainder is left to the authors to sort out. > > > >3.) MIB Boilerplate -- OK > > > >4.) IPR Notices -- the required notices from RFC 2026 Sections > >10.4(A) and 10.4(B) are present and no claims are noted; this > >is OK if indeed there are no relevant IPR disclosures. Note, > >however, that a search of the IPR statements on the IETF web site > >does reveal some claims that seem like they _might_ be relevant: > > > > Search Results for query = '(robust or robustness or robustly) > > and (header or head or headed or heading or headings or heads > > or headers) and (compression or compressions)' > > _________________________________________________________________ > > > > Match: [All....] Format: [Long.] Sort by: [Title........] > > Refine search: ______________________________ Search > > _________________________________________________________________ > > > > Documents 1 - 4 of 11 matches. More * 's indicate a better match. > > _________________________________________________________________ > > > > [ERICSSON-ROCCO] * > > ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE > > UNDERTAKING In the AVT Working Group in the Internet > > Engineering Task Force, a proposal "RObust Checksum-based > > header COmpression (ROCCO)" dated June 22, 1999 has been > > made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at > > Lulea University ... > > http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557 > > bytes > > > > [ERICSSON-SIGCOMP.txt] * * * * > > ... that might possibly have technical relations to the > > Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt. > > This draft is part of the Signaling Compression work > > taking place in the Robust Header Compression (ROHC) WG. > > See further Ericsson's general IPR statement: > > http://www.ietf.org/ietf/IPR/ERICSSON ... > > http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02, > > 466 bytes > > > > [NOKIA-RFC3095.txt] * > > ... : 1) "CID field handling in ROHC": FI 20002100, US > > 09/954562, PCT/FI01/00819 2) "Variable length context > > identifier for real time header compression": FI 20002307, > > US 09/978479, PCT/FI01/00902 3) "Variable length encoding of > > compressed data": US 09/536638, US 60/164330, ... > > http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02, > > 1373 bytes > > > > [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] * > > ... This is to advise the IETF that Telefonaktiebolaget LM > > Ericsson believes it owns patents and patent applications > > which may relate to RFC 3095, "RObust Header Compression > > (ROHC): Framework and four profiles: RTP, UDP, ESP, and > > uncompressed". See further Ericsson's general IPR > > statement: http://www.ietf.org/ietf/IPR/ERICSSON ... > > http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST- > > HEADER-COMPRESSION.txt 09/27/02, 439 bytes > > > > Return to the Seach Page > > _________________________________________________________________ > > > > ht://Dig 3.1.6 > > > >The document authors and the WG should examine these IPR disclosures > >and either determine for sure that none are required in order to > >implement the MIB module or else add the notice from RFC 2026 > >Section 10.4(D). (The reviewer will be satisfied if the authors > >reply that the IPR section in the document is OK as it stands. All > >that's being requested is an assurance that you have done your > >homework.) > > > >5.) References -- there are some missing normative references and > >some of the existing references contain minor errors or don't > >exactly follow the current RFC style. The style issues are listed > >only for completeness; RFC Editor will fix that in any case. > > > >(a) RFC 3411 needs to be added as a normative reference since > >SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB > >(c.f. Section 3.5). > > > >(b) RFC 2863 needs to be added as a normative reference since > >IF-MIB appears in the IMPORTS statement of all three MIB > >modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB. > > > >(c) [RFC3095] has an incorrect title and an author list that's not > >in the standard form. > > > >(d) [RFC3242] has an author list that's not in the standard form. > > > >(e) [RFCXXXX] has an author list that's not in the standard form, > >and it might be helpful to readers to indicate the I-D that will > >eventually turn into this RFC-to-be. > > > >6.) Security Considerations Section -- there are two read/write > >objects but only one is mentioned. A possible fix would be to > >revise the first paragraph to read as follows: > > > > The managed objects defined by the ROHC-MIB module, the > > ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not > > have a MAX-ACCESS value of read-write and/or read-create except > > rohcInstanceContextStorageTime and rohcContextStorageTime, both of > > which have a MAX-ACCESS value of read-write. These objects > > determine how long context information is stored after its > > termination. Unauthorized access to these objects can have one of > > two negative effects. If they are set to a value lower than > > required, e.g. to zero, then context information about past contexts > > might get lost. If they are set to a very high value, then context > > information will not be deleted and memory consumption of the agent > > implementation might become very high. However, unauthorized access > > to these objects cannot cause harm to existing ROHC connections nor > > can it allow manipulation of running instances of ROHC in a > > malicious way. > > > >The fourth paragraph says "[a]lthough the security risks arising > >from the ROHC-MIB module are not considered to be high", but the > >second paragraph says "[it is] important to control even GET and/or > >NOTIFY access to these objects and possibly to even encrypt the > >values of these objects when sending them over the network via > >SNMP." That seems contradictory. It is therefore suggest to > >modify the fourth paragraph so that it reads as originally written > >in the standard security considerations template: > > > > It is RECOMMENDED that implementers consider the security features > > as provided by the SNMPv3 framework (see [RFC3410], section 8), > > including full support for the SNMPv3 cryptographic mechanisms (for > > authentication and privacy). > > > >7.) IANA Considerations Section -- OK (none present and none > >required). > > > >8.) Copyright notices -- the abbreviated copyright notices that are > >supposed to appear on the front page and in the DESCRIPTION clause > >of each MODULE-IDENTITY invocation are missing and need to be added. > >See http://www.ietf.org/ID-nits.html section 1.2, > > section 4.3, and > > section 3.8. > > > >9.) MIB compilation -- the following problems are reported > by smilint: > > > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > >has been processed to get the following results: > >smilint -m -s -l 6 -i namelength-32 ROHC-MIB > > > >ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-MIB:184: [5] {index-element-accessible} warning: index element > >`rohcInstanceType' of row `rohcInstanceEntry' should be > >not-accessible in SMIv2 MIB > > > >FIXES: > >(a) add Counter32 to the list of things imported from SNMPv2-SMI > >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible > >(c) remove rohcInstanceType from rohcInstanceGroup > > > > > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > >has been processed to get the following results: > >smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB > > > >ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base > >type `Counter32' must be imported from SNMPv2-SMI > >ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base > >type `Counter32' must be imported from SNMPv2-SMI > > > >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > > > > > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > >has been processed to get the following results: > >smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB > > > >ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > >ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type > >`Counter32' must be imported from SNMPv2-SMI > > > >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > > > >10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html > >that is not covered above: > > > >(a) there are several places in the MIB modules where the lines > >extend beyond column 72. Most (but not all) of these could be fixed > >by eliminating the three-space indentation. Althought the RFC > >Editor can probably do this, it will save time and reduce the > >proabability of formatting errors in the final RFC if the authors > >would fix it themselves. See ID-nits section 1.1. > > > >(b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to > >the list of imperatives (although the standard boilerplate in RFC > >2119 does not include it, it is used in the Security Considerations > >section and it is defined in RFC 2119). > > > >(c) in Section 3, "Overview", 3rd paragraph: s/means/a means/ > > > >(d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/ > > > >(e) in Section 4, "Structure of the MIB modules", 1st paragraph: > >s/Section 6/Section 5/ > > > >(f) in Section 4, "Structure of the MIB modules", 2nd and 4th > >paragraphs: most acronyms must be expanded upon first use, > >except for those that everyone in the IETF can reasonably be > >expected to know. Note that this rule applies separately for > >the body of the memo and the abstract; see Sections 4.7 and 2.9 > >of or its successor document > >and review comment (2) above. > > > >(g) in Section 4.1, "The ROHC-MIB module", first paragraph: the > >tables are mentioned in a different order than they appear in the > >MIB module, which has rohcChannelTable before rohcInstanceTable. > >Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with > >the order in this paragraph but are "swapped" relative to the MIB > >module. It might be better if the order in the text matched that > >of the MIB module. > > > >(h) in Section 4.1, "The ROHC-MIB module", last paragraph: > >unexpanded acronym CID. > > > >(i) in Section 4.1.1, "rohcInstanceTable", 4th bullet: > >s/storagetime/storage time/ > > > >(j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed > >text from: > > > > o the state of the CID ('unused', 'active', 'expired', or > > > >to: > > > > o the state of the CID ('unused', 'active', 'expired', or > > 'terminated'. > > > >Note: a common cause of missing text in an I-D is a line in the > >nroff source that starts with a single quote as the first character > >of the line. > > > >11.) Technical content -- the following comments pertain to the > >material in Sections 3, 4, and 5. Please note that I am not an > >ROHC subject matter expert and so I do not have the knowledge to > >attempt a detailed verification that the MIB objects are indeed > >fit for the intended purposes. I'm presuming that the WG has > >already done that, so I've concentrated on MIB design issues. > >Issues already covered under (9) above won't be repeated here. > > > >(a) in Section 3, "Overview", next to last paragraph, it is stated > >that "the compressor context can be reinitialized." I didn't see > >any read-write or read-create objects in the MIB module that would > >support such a capability. If indeed there is no support for such > >a capability then the claim should be removed. > > > >(b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3, > >"rohcProfileTable", and also in the corresponding definitions in > >the ROHC-MIB module in Section 5: it is not clear why one needs a > >vendor, version number, and implementation description in both of > >these tables. Indeed, except for the descriptors and OIDs that > >are assigned, the definitions of rohcInstanceVendor, > >rohcInstanceVersion, and rohcInstanceDescr are identical with those > >for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr > >(respectively). It seems to me that the objects rohcProfileVendor, > >rohcProfileVersion, and rohcProfileDescr could be eliminated without > >loss of capability. The designers may also wish to consider moving > >rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into > >the rohcChannelTable or perhaps even turning them into scalars. > > > >(c) in Section 4.1.3, "rohcProfileTable", there is no mention of > >the per-profile Boolean flag that indicates whether the profile > >has been negotiated to be used at the instance. > > > >(d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations > >need to be changed in the following ways: > > > > - WG mailing list info (and optionally, charter page URL) needs to > > be present in the CONTACT-INFO clause; > > > > - there needs to be a REVISION/DESCRIPTION clause pair with a date > > identical to that in the LAST-UPDATED clause and a description > > indicating that the module is the initial published version; > > > > - the DESCRIPTION clause needs to include an abbreviated copyright > > notice (per (8) above). > > > >See sections 3.8 and > >4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY > >invocation could be changed from: > > > >rohcMIB MODULE-IDENTITY > > LAST-UPDATED "200209251358Z" > > ORGANIZATION "IETF Robust Header Compression Working Group" > > CONTACT-INFO > > "Juergen Quittek > > NEC Europe Ltd. > > Network Laboratories > > Kurfuersten-Anlage 34 > > 69221 Heidelberg > > Germany > > Tel: +49 6221 90511-15 > > E-mail: quittek@ccrle.nec.de" > > DESCRIPTION > > "This MIB module defines a set of basic objects for > > monitoring and configuring robust header compression. > > The module covers information about running instances > > of ROHC (compressors or decompressors) at IP interfaces. > > > > Information about compressor contexts and decompressor > > contexts has different structure for different profiles. > > Therefore it is not provided by this MIB module, but by > > individual modules for dofferent profiles." > > ::= { mib-2 XXX } > >-- XXX to be assigned by IANA. > > > >to something along the lines of: > > > >rohcMIB MODULE-IDENTITY > > LAST-UPDATED "200306250000Z" -- June 25, 2003 > > ORGANIZATION "IETF Robust Header Compression Working Group" > > CONTACT-INFO > > "WG charter: > > http://www.ietf.org/html.charters/rohc-charter.html > > > > Mailing Lists: > > General Discussion: rohc@ietf.org > > To Subscribe: rohc-request@ietf.org > > In Body: subscribe your_email_address > > > > Editor: > > Juergen Quittek > > NEC Europe Ltd. > > Network Laboratories > > Kurfuersten-Anlage 34 > > 69221 Heidelberg > > Germany > > Tel: +49 6221 90511-15 > > E-mail: quittek@ccrle.nec.de" > > DESCRIPTION > > "This MIB module defines a set of basic objects for > > monitoring and configuring robust header compression. > > The module covers information about running instances > > of ROHC (compressors or decompressors) at IP interfaces. > > > > Information about compressor contexts and decompressor > > contexts has different structure for different profiles. > > Therefore it is not provided by this MIB module, but by > > individual modules for different profiles. > > > > Copyright (C) The Internet Society (2003). This version > > of this MIB module is part of RFC yyyy; see the RFC > > itself for full legal notices." > >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > > > REVISION "200306250000Z" -- June 25, 2003 > > DESCRIPTION "Initial version, published as RFC yyyy." > >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > > > ::= { mib-2 XXX } > >-- XXX to be assigned by IANA. > > > >with the dates changed as appropriate. [Note also a typo fix: > >s/dofferent/different/.] Similar changes apply to the other > >MIB modules. > > > >(e) in Section 5, all MIB modules: the ordering of the index > >components is not consistent throughout. Specifically, although > >all tables are indexed by ifIndex and rohcChannelID, the tables > >without rohcInstanceType as an index component all have > >{ ifIndex, rohcChannelID, ... } as a common prefix, while those > >with rohcInstanceType do not: their common prefix is > >{ ifIndex, rohcInstanceType, rohcChannelID, ... }. While this > >will certainly work, and may be legitimate if one wishes to have a > >different sort order in different tables, the MIB designers should > >be aware that it tends to make the implementation harder than it > >otherwise would be, because there is less indexing code that can > >be shared between different tables. Unless there was a specific > >reason for choosing the specific index order that is in the draft, > >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. > > > >(f) in Section 5, all MIB modules: none of the Counter32 objects > >has a discontinuity time indicator. Such an indicator is required > >if events other than a reboot may result in a discontinuity (i.e., > >non-monotonic counting behaviour); see the first bullet of Section > >4.6.1.2 of . Since > >each counter is associated with a specific interface, a good > >solution in this case is to use IF-MIB's ifCounterDiscontinuityTime > >for this purpose, as is done in the EtherLike-MIB (RFC 2665), > >the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That > >would mean adding the following or similar text > > > > Discontinuities in the value of this counter can > > occur at re-initialization of the management > > system, and at other times as indicated by the > > value of ifCounterDiscontinuityTime. > > > >to the DESCRIPTION clause of each of the Counter32 objects. > > > >(g) in Section 5, all MIB modules: it is observed that many objects > >are defined with SYNTAX values of of Integer32 (0..2147483647), > >Integer32 (1..2147483647), and Integer32 (0..1000). While this is > >certainly acceptable, it is brought to the authors' attention that > >Unsigned32 is preferred when the range of values is non-negative; > >see Section 4.6.1.1. > >Changes, if any, are left to the authors' discretion. (Note: > >current usage is consistent for all objects; if a change is made, > >please be sure to do so everywhere; but see 11(m) first.) > > > >/********** The following comments apply to the ROHC-MIB **********/ > > > >(h) In the DESCRIPTION clause of rohcChannelID it says: > > > > The value is expected to remain constant at least from one > > re-initialization of the entity's network management system > > to the next re-initialization. > > > >I know that this same language is used in the IF-MIB, but it turns > >out that indices that don't remain fixed across reboots can lead > >to problems. See the thread "Referential integrity across reboots" > >at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140 > >Suggested remedy: change the above text to: > > > > 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. > > > >(i) In the DESCRIPTION clause of rohcChannelFeedbackFor: > >s/feddback/feedback/ > > > >(j) In the following object definition it is not specified what > >value the object should assume if there is no feedback channel: > > > >rohcInstanceFBChannelID OBJECT-TYPE > > SYNTAX RohcChannelIdentifier > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Identifier of the channel used for feedback." > > ::= { rohcInstanceEntry 4 } > > > >Shouldn't the DESCRIPTION clause state that the value 0 is used in > >that case? It would seem to be consistent with the instructions in > >the RohcChannelIdentifier DESCRIPTION clause to do this. > > > >(k) In the following object definition: > > > > rohcInstanceMRRU OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Maximum reconstructed reception unit. This is the > > size of the largest reconstructed unit in octets that > > the decompressor is expected to reassemble from > > segments (see RFC 3095, Section 5.2.5). Note that this > > size includes the CRC. If MRRU is negotiated to be 0, > > no segment headers are allowed on the channel." > > REFERENCE > > "RFC 3095, Section 5.1.1" > > ::= { rohcInstanceEntry 11 } > > > >the SYNTAX value and the DESCRIPTION clause are at odds. > > > >FIX: change the SYNTAX value to Integer32 (0..2147483647) > > > >(l) In the following object definition: > > > >rohcInstanceContextsCurrent OBJECT-TYPE > > SYNTAX Integer32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Number of currently active contexts created by this > instance." > > ::= { rohcInstanceEntry 15 } > > > >a more appropriate SYNTAX value would be Integer32 (0..2147483647) > >since the number of contexts cannot possibly be negative. > > > >(m) In the following object definition: > > > >rohcInstanceCompressionRatio OBJECT-TYPE > > SYNTAX Integer32 (0..1000) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates the compression ratio so far over all > > packets on the channel served by this instance. > The value is > > defined as 1000 * bytes(compressed) / > bytes(original) rounded > > to the next integer value. The number of bytes corresponds > > to all bytes of all IP packets including the IP header but > > excluding all lower layer headers." > > ::= { rohcInstanceEntry 20 } > > > >Is it theoretically possible for the compression ratio to > exceed unity > >in certain unfavorable cases? If so, then the range needs to be > >changed to allow for that, or the DESCRIPTION clause needs to state > >that the value is set to 1000 if the actual compression ratio exceeds > >unity. In the latter case a more appropriate SYNTAX value would be > >Gauge32 (0..1000) (see > >Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION > >RATIO OBJECTS. > > > >(n) I'm not sure if I properly understood the DESCRIPTION clause of > >the following object: > > > >rohcProfileNegotiated OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "When retrieved, this boolean object returns true > > if the profile has been negotiated to be used at > > the instance, i.e. is supported also by the > > corresponding compressor/decompressor." > > ::= { rohcProfileEntry 7 } > > > >My understanding is that an instance of this object corresponding to > >a particular triple should > >have the value true(1) if and only if at least one context with the > >same values is using that profile -- in > >other words, if and only if some instance of rohcContextProfile for > >the same values is equal to the rohcProfile > >value. If this understanding is _not_ correct, then clarification > >of the DESCRIPTION clause would be in order. > > > >(o) Several DESCRIPTION clauses in the ROHC-MIB refer to the > >non-existent object rohcContextType. They should refer instead to > >rohcInstanceType. The objects in question are: > > > >rohcContextDecompressorDepth > >rohcContextDecompressorFailures > >rohcContextDecompressorRepairs > > > >(p) In the following object definition [n.b. the above correction > >has been assumed to be applied]: > > > >rohcContextDecompressorDepth OBJECT-TYPE > > SYNTAX Integer32 (0..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates whether reverse decompression, for > > example as described in RFC 3095, Section 6.1, is used > > on this channel or not, and if used, to what extent. > > > > Its value is only valid for decompressor contexts, i.e. > > if rohcInstanceType has the value decompressor(2). > > > > The value of the reverse decompression depth indicates > > the maximum number of packets that are buffered, and thus > > possibly be reverse decompressed by the decompressor. > > A zero (0) value means that reverse decompression is not > > used." > > ::= { rohcContextEntry 7 } > > > >it is not clear whether this object should have the value 0 for > >compressor contexts, or whether it should not be instantiated at > >all for such contexts. > > > >(q) The rohcCompliance DESCRIPTION clause should mention that the > >ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of > >, last paragraph > >before end note. Examples may be found in the dot3Compliance2 > >statement in , the > >mauModIfCompl3 statement in , > >or the etherWisCompliance in > >(although it is requested that the embedded citations be avoided). > > > >/*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/ > > > >(r) The rohcUncmprCompliance DESCRIPTION clause should mention that > >the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as > >prerequisites. See 11(q) above for examples. > > > >/******** The following comments apply to the ROHC-RTP-MIB ********/ > > > >(s) The DESCRIPTION clauses of several columnar objects in the > >rohcRtpContextTable state that those objects are valid only for > >certain profiles or for certain contexts. The objects in question > >are: > > > >rohcRtpContextAlwaysPad > >rohcRtpContextLargePktsAllowed > >rohcRtpContextVerifyPeriod > >rohcRtpContextSizesAllowed > >rohcRtpContextSizesUsed > > > >If the intent is that those objects are to be instantiated only for > >the profiles or contexts to which they apply, then that fact should > >be made explicit in the DESCRIPTION clauses. > > > >(t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and > >rohcRtpContextSizesUsed both appear to have the same three > >typographical errors: > > > > rohcRtpContextSizesAllowed OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is only valid for decompressor > > contexts, i.e. if rohcContextType of the cooresponding > > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > > rohcContextEntry has the value compressor(2). > > ^^^^^^^^^^^^^ > > > > This object contains the number of different packet sizes > > that may be used in the context." > > REFERENCE > > "RFC 3095, Section 6.3.1" > > ::= { rohcRtpContextEntry 10 } > > > > rohcRtpContextSizesUsed OBJECT-TYPE > > SYNTAX Integer32 (1..2147483647) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is only valid for decompressor > > contexts, i.e. if rohcContextType of the cooresponding > > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > > rohcContextEntry has the value compressor(2). > > ^^^^^^^^^^^^^ > > > > This object contains the number of different packet sizes > > that are used in the context." > > REFERENCE > > "RFC 3095, Section 6.3.1" > > ::= { rohcRtpContextEntry 11 } > > > >Suggested fixes: s/rohcContextType/rohcInstanceType/ > > s/cooresponding/corresponding/ > > s/compressor(2)/decompressor(2)/ > > > >(u) There are some design issues with the rohcRtpPacketSizeTable: > > > >- the index column rohcRtpPacketSize with has values in the range > >0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that > >PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive > >integers, i.e., the value 0 is excluded as it does not make sense. > >FIX: change the range to 1..2147483647. (This also avoids > >running afoul of the SMIv2 rule that index values of zero should > >be avoided, except in special cases.) > > > >- the TruthValue column rohcRtpPacketSizeAllowed seems to be > >unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that > >"packet sizes not in the set of values for [PACKET_SIZES_ALLOWED] > >MUST NOT be used", it seems that an agent would never need to > >instantiate any of the other columns if rohcRtpPacketSizeAllowed > >had the value false(2). In other words, any row for which this > >objects is false should simply be absent from the table. > > > >(v) The rohcRtpCompliance DESCRIPTION clause should mention that > >the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as > >prerequisites. See 11(q) above for examples. > > > >This concludes the review of . > > > >Regards, > > > >Mike Heard > > > > > >_______________________________________________ > >Rohc mailing list > >Rohc@ietf.org > >https://www1.ietf.org/mailman/listinfo/rohc > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, > Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments > is confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create or > change any contractual relationship. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jul 4 18:46: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 SAA11406 for ; Fri, 4 Jul 2003 18:46: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 19YZJd-0008KN-Oh for rohc-archive@odin.ietf.org; Fri, 04 Jul 2003 18:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64Mk5OI032010 for rohc-archive@odin.ietf.org; Fri, 4 Jul 2003 18:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZJd-0008KD-LZ for rohc-web-archive@optimus.ietf.org; Fri, 04 Jul 2003 18:46: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 SAA11382 for ; Fri, 4 Jul 2003 18:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YZJa-0003Zj-00 for rohc-web-archive@ietf.org; Fri, 04 Jul 2003 18:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YZJa-0003Ze-00 for rohc-web-archive@ietf.org; Fri, 04 Jul 2003 18:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZJZ-0008Jt-GZ; Fri, 04 Jul 2003 18:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YZJT-0008Jg-Bt for rohc@optimus.ietf.org; Fri, 04 Jul 2003 18:45: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 SAA11377 for ; Fri, 4 Jul 2003 18:45:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YZJQ-0003Zb-00 for rohc@ietf.org; Fri, 04 Jul 2003 18:45:52 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19YZJJ-0003ZY-00 for rohc@ietf.org; Fri, 04 Jul 2003 18:45:46 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 02E338A7E2; Sat, 5 Jul 2003 08:14:55 +0930 (CST) Date: Sat, 5 Jul 2003 08:14:55 +0930 From: Alan Kennington To: ROHC mailing list Cc: Alan Kennington Message-ID: <20030705081455.A321@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] Question: CRC coverage of ROHC RTP feedback messages 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , There seems to be ambiguity in the specification of the CRC coverage for ROHC feedback messages. Can anyone tell me what the correct interpretation is? Could this be incorporated into the ROHC implementer's guide? The issue arises in RFC 3095, section 5.7.6.3, page 92: ========================================================= 5.7.6.3. The CRC option The CRC option contains an 8-bit CRC computed over the entire feedback payload, without the packet type and code octet, but including any CID fields, using the polynomial of section 5.9.1. If the CID is given with an Add-CID octet, the Add-CID octet immediately precedes the FEEDBACK-1 or FEEDBACK-2 format. For purposes of computing the CRC, the CRC fields of all CRC options are zero. ========================================================= It says above that the CRC does not cover the packet type and code octet. But does it cover the "size" octet if present? The "size" is effectively an optional extension of the "code" octet. On that basis, it would seem reasonable that the CRC does not cover it. But the RFC does not say this. It seems to deny this. Therefore it is ambiguous in a way which strongly affects interoperability. Is the answer written somewhere? Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington city: Adelaide, South Australia coords: 138.59 E, 34.88 S pgp-key: http://www.topology.org/ak/key_ak2.asc note: My e-mail address often changes due to spam abuse. note: If your e-mail bounces, please visit topology.org/extra/email.php _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sat Jul 5 16:03:30 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 QAA15180 for ; Sat, 5 Jul 2003 16:03:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YtFP-0005tO-4w for rohc-archive@odin.ietf.org; Sat, 05 Jul 2003 16:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65K33W9022644 for rohc-archive@odin.ietf.org; Sat, 5 Jul 2003 16:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YtFP-0005t6-0C for rohc-web-archive@optimus.ietf.org; Sat, 05 Jul 2003 16:03: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 QAA15174 for ; Sat, 5 Jul 2003 16:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YtFN-0005GI-00 for rohc-web-archive@ietf.org; Sat, 05 Jul 2003 16:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19YtFM-0005GF-00 for rohc-web-archive@ietf.org; Sat, 05 Jul 2003 16:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YtFM-0005sn-Sy; Sat, 05 Jul 2003 16:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YqiZ-0008FV-9d for rohc@optimus.ietf.org; Sat, 05 Jul 2003 13:20: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 NAA11843 for ; Sat, 5 Jul 2003 13:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YqiX-0003sx-00 for rohc@ietf.org; Sat, 05 Jul 2003 13:20:57 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19YqiW-0003su-00 for rohc@ietf.org; Sat, 05 Jul 2003 13:20:56 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h65HKsIi027111 for ; Sat, 5 Jul 2003 19:20:54 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Sat, 5 Jul 2003 19:20:54 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: rohc@ietf.org Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Sat, 5 Jul 2003 19:20:44 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > I find motivations to add an additional state for CR > > somewhat thin, also in relation to the limited amount > > of logic attached to it > > In general, I believe that the purpose of the compressor state > machine is to provide information needed by a context to > decide which packet format to use when compressing a header. > Different states allow a different range of packet formats to > be used. I rather see the compression states as a pedagogic way of describing how the compression process works. Note that RFC 3095 does not define 1-to-1 mappings between packet types and compression states, nor is the compression and decompression states the same. I do not believe we should extend the state set just because of context replication, that would rather be something to consider in implementation. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sat Jul 5 16:51: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 QAA15840 for ; Sat, 5 Jul 2003 16:51: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 19Ytzr-0007lg-9u for rohc-archive@odin.ietf.org; Sat, 05 Jul 2003 16:51:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h65Kp3kP029854 for rohc-archive@odin.ietf.org; Sat, 5 Jul 2003 16:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ytzr-0007lR-6M for rohc-web-archive@optimus.ietf.org; Sat, 05 Jul 2003 16:51: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 QAA15833 for ; Sat, 5 Jul 2003 16:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ytzp-0005Rs-00 for rohc-web-archive@ietf.org; Sat, 05 Jul 2003 16:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ytzo-0005Rp-00 for rohc-web-archive@ietf.org; Sat, 05 Jul 2003 16:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ytzp-0007l2-BV; Sat, 05 Jul 2003 16:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YtzN-0007ko-R0 for rohc@optimus.ietf.org; Sat, 05 Jul 2003 16:50:33 -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 QAA15830 for ; Sat, 5 Jul 2003 16:50:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YtzL-0005Rm-00 for rohc@ietf.org; Sat, 05 Jul 2003 16:50:31 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19YtzK-0005Rj-00 for rohc@ietf.org; Sat, 05 Jul 2003 16:50:30 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h65KoSg12453; Sat, 5 Jul 2003 13:50:28 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 5 Jul 2003 13:50:27 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ROHC mailing list cc: "Wijnen, Bert (Bert)" Subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Message-ID: 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 3 Jul 2003, Surtees, Abigail wrote: Abbie> Having had a look at the MIB I have a question about it. One Abbie> problem mentioned below is that rohcInstanceType should have Abbie> MAX-ACCESS value of not-accessible. Abbie> Abbie> The fix proposed by the MIB doctor is the following. Abbie> Abbie> >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible Abbie> >(c) remove rohcInstanceType from rohcInstanceGroup Abbie> Abbie> The reason it should be not-accessible is because it is used as Abbie> an index into the rohcInstanceTable and the rohcContextTable. Abbie> Abbie> Why does it need to be an index into these tables? Abbie> Abbie> In my understanding (please correct me if I'm wrong) from Abbie> reading the terminology draft, each instance will have its own Abbie> channel ID which can uniquely identify it on an interface. A Abbie> single instance can only be a compressor or a decompressor and Abbie> is already identified by ifIndex and rohcChannelID, so using the Abbie> rohcInstanceType as an index doesn't actually identify anything Abbie> further. Not being familiar with the terminology document, I cannot comment on whether that document would mandate a separate rohcChannelID value for a compressor and a decompressor. However, if it does say that, then Abbie;s statement is correct. >>>>> On Thu, 3 Jul 2003, Wijnen, Bert (Bert) replied: Bert> So this is something the WG needs to discuss. Indeed. Abbie> If it doesn't need to be an index, then a MAX-ACCESS value of Abbie> read-only is acceptable. Bert> If rohcInstanceType is not needed to uniquely identify Bert> an instance in the tables, then it is probably better to Bert> NOT use it as an index. And if not used as index, then Bert> indeed read-only access is fine. I would go further and make the stronger statement: if separate rohcChannelID values are supposed to be assigned to compressors and decompressors, then rohcInstanceType SHOULD NOT be an index, because doing so allows a common rohcChannelID value to be assigned to both. And if rohcChannelID is not an index component, then its MAX-ACCESS value MUST NOT be not-accessible (read-only is fine); otherwise, there is no way for a management application to determine its value. Regards, Mike Heard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jul 7 10:31: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 KAA27510 for ; Mon, 7 Jul 2003 10:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX1F-0003me-9i for rohc-archive@odin.ietf.org; Mon, 07 Jul 2003 10:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67EV5Vc014542 for rohc-archive@odin.ietf.org; Mon, 7 Jul 2003 10:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX1F-0003mT-2u for rohc-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 10:31: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 KAA27472 for ; Mon, 7 Jul 2003 10:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZX1C-0004oP-00 for rohc-web-archive@ietf.org; Mon, 07 Jul 2003 10:31:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZX1B-0004oL-00 for rohc-web-archive@ietf.org; Mon, 07 Jul 2003 10:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX1B-0003lu-Lk; Mon, 07 Jul 2003 10:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZX0z-0003kz-M3 for rohc@optimus.ietf.org; Mon, 07 Jul 2003 10:30:49 -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 KAA27461 for ; Mon, 7 Jul 2003 10:30:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZX0x-0004oE-00 for rohc@ietf.org; Mon, 07 Jul 2003 10:30:47 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19ZX0v-0004o9-00 for rohc@ietf.org; Mon, 07 Jul 2003 10:30:45 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h67EUDVI030939; Mon, 7 Jul 2003 16:30:14 +0200 (CEST) Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 29654B4A8F; Mon, 7 Jul 2003 16:12:53 +0200 (CEST) Cc: "Wijnen, Bert (Bert)" , "ROHC mailing list" X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.45 references: From: "Juergen Quittek" MIME-Version: 1.0 subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt To: "C. M. Heard" content-type: text/plain; charset="iso-8859-1" date: Mon, 07 Jul 2003 16:12:52 +0200 Message-Id: <20030707141253.29654B4A8F@venus.office> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tokyo.ccrle.nec.de id h67EUDVI030939 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mike,=0D =0D Thank you very much for this great review!=0D =0D Unfortunately, we did not had exensive discussions on this=0D document on the rohc mailing list. Your comments will help=0D improving the MIB module significantly.=0D =0D At first glance I agree to most of your comments. For some=0D of the remaining I would like to discuss with Martin first =0D and read the MIB carefully again.=0D =0D Unfortunately, I'm out of the office until the IETF meeting.=0D I will sit together with Martin in Vienna and we will give =0D you a response to each of your comments in that week.=0D =0D Cheers,=0D =0D Juergen=0D --=0D Juergen Quittek,=0D Network Laboratories, =0D NEC Europe Ltd.=0D > >>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote:=0D > Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt=0D > Bert> in the next week or two?=0D > =0D > >>>>> On Fri, 13 Jun 2003, C. M. Heard replied:=0D > CMH> I will volunteer to do this. Based on a quick look I think=0D > CMH> I should be able to turn around the review before June 26th.=0D > =0D > As noted above, I've volunteered to do a MIB Doctor review of=0D > . For the most part, I have been=0D > pleased with the quality of that document. However, there are a=0D > number of things that do need to be corrected, or at least looked=0D > at, before the document goes to the IESG. The detailed review=0D > comments below follow the checklist from Appendix A of the draft=0D > guidelines document .=0D > Those who wish to respond to these review comments should do so on=0D > the ROHC mailing list, with copies to Bert Wijnen and myself.=0D > =0D > 0.) Title -- s/Robus/Robust/=0D > =0D > 1.) I-D Boilerplate -- OK=0D > =0D > 2.) Abstract -- acronyms used in the abstract must be expanded on=0D > first use, except for those acronyms that everyone in the IETF can=0D > reasonably be expected to know (see Sections 4.5 and 2.9 of=0D > or its successor document).=0D > Certainly ROHC and LLA will need to be expanded; I'm not sure about=0D > ESP and RTP -- please check with the RFC Editor. Here is a partial=0D > fix:=0D > =0D > This memo defines a portion of the Management Information Base (MIB)=0D > for use with network management protocols in the Internet community.=0D > In particular, it describes a set of managed objects that allow=0D > monitoring of running instances of RObust Header Compression (ROHC).=0D > [ ... ]=0D > =0D > The remainder is left to the authors to sort out.=0D > =0D > 3.) MIB Boilerplate -- OK=0D > =0D > 4.) IPR Notices -- the required notices from RFC 2026 Sections=0D > 10.4(A) and 10.4(B) are present and no claims are noted; this=0D > is OK if indeed there are no relevant IPR disclosures. Note,=0D > however, that a search of the IPR statements on the IETF web site=0D > does reveal some claims that seem like they _might_ be relevant:=0D > =0D > Search Results for query =3D '(robust or robustness or robustly)=0D > and (header or head or headed or heading or headings or heads=0D > or headers) and (compression or compressions)'=0D > _________________________________________________________________=0D > =0D > Match: [All....] Format: [Long.] Sort by: [Title........]=0D > Refine search: ______________________________ Search=0D > _________________________________________________________________=0D > =0D > Documents 1 - 4 of 11 matches. More * 's indicate a better match.=0D > _________________________________________________________________=0D > =0D > [ERICSSON-ROCCO] *=0D > ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE=0D > UNDERTAKING In the AVT Working Group in the Internet=0D > Engineering Task Force, a proposal "RObust Checksum-based=0D > header COmpression (ROCCO)" dated June 22, 1999 has been=0D > made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at=0D > Lulea University ...=0D > http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557=0D > bytes=0D > =0D > [ERICSSON-SIGCOMP.txt] * * * *=0D > ... that might possibly have technical relations to the=0D > Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt.=0D > This draft is part of the Signaling Compression work=0D > taking place in the Robust Header Compression (ROHC) WG.=0D > See further Ericsson's general IPR statement:=0D > http://www.ietf.org/ietf/IPR/ERICSSON ...=0D > http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02,=0D > 466 bytes=0D > =0D > [NOKIA-RFC3095.txt] *=0D > ... : 1) "CID field handling in ROHC": FI 20002100, US=0D > 09/954562, PCT/FI01/00819 2) "Variable length context=0D > identifier for real time header compression": FI 20002307,=0D > US 09/978479, PCT/FI01/00902 3) "Variable length encoding of=0D > compressed data": US 09/536638, US 60/164330, ...=0D > http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02,=0D > 1373 bytes=0D > =0D > [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] *=0D > ... This is to advise the IETF that Telefonaktiebolaget LM=0D > Ericsson believes it owns patents and patent applications=0D > which may relate to RFC 3095, "RObust Header Compression=0D > (ROHC): Framework and four profiles: RTP, UDP, ESP, and=0D > uncompressed". See further Ericsson's general IPR=0D > statement: http://www.ietf.org/ietf/IPR/ERICSSON ...=0D > http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST-=0D > HEADER-COMPRESSION.txt 09/27/02, 439 bytes=0D > =0D > Return to the Seach Page=0D > _________________________________________________________________=0D > =0D > ht://Dig 3.1.6=0D > =0D > The document authors and the WG should examine these IPR disclosures=0D > and either determine for sure that none are required in order to=0D > implement the MIB module or else add the notice from RFC 2026=0D > Section 10.4(D). (The reviewer will be satisfied if the authors=0D > reply that the IPR section in the document is OK as it stands. All=0D > that's being requested is an assurance that you have done your=0D > homework.)=0D > =0D > 5.) References -- there are some missing normative references and=0D > some of the existing references contain minor errors or don't=0D > exactly follow the current RFC style. The style issues are listed=0D > only for completeness; RFC Editor will fix that in any case.=0D > =0D > (a) RFC 3411 needs to be added as a normative reference since=0D > SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB=0D > (c.f. Section 3.5).=0D > =0D > (b) RFC 2863 needs to be added as a normative reference since=0D > IF-MIB appears in the IMPORTS statement of all three MIB=0D > modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB.=0D > =0D > (c) [RFC3095] has an incorrect title and an author list that's not=0D > in the standard form.=0D > =0D > (d) [RFC3242] has an author list that's not in the standard form.=0D > =0D > (e) [RFCXXXX] has an author list that's not in the standard form,=0D > and it might be helpful to readers to indicate the I-D that will=0D > eventually turn into this RFC-to-be.=0D > =0D > 6.) Security Considerations Section -- there are two read/write=0D > objects but only one is mentioned. A possible fix would be to=0D > revise the first paragraph to read as follows:=0D > =0D > The managed objects defined by the ROHC-MIB module, the=0D > ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not=0D > have a MAX-ACCESS value of read-write and/or read-create except=0D > rohcInstanceContextStorageTime and rohcContextStorageTime, both of=0D > which have a MAX-ACCESS value of read-write. These objects=0D > determine how long context information is stored after its=0D > termination. Unauthorized access to these objects can have one of=0D > two negative effects. If they are set to a value lower than=0D > required, e.g. to zero, then context information about past contexts=0D > might get lost. If they are set to a very high value, then context=0D > information will not be deleted and memory consumption of the agent=0D > implementation might become very high. However, unauthorized access=0D > to these objects cannot cause harm to existing ROHC connections nor=0D > can it allow manipulation of running instances of ROHC in a=0D > malicious way.=0D > =0D > The fourth paragraph says "[a]lthough the security risks arising=0D > from the ROHC-MIB module are not considered to be high", but the=0D > second paragraph says "[it is] important to control even GET and/or=0D > NOTIFY access to these objects and possibly to even encrypt the=0D > values of these objects when sending them over the network via=0D > SNMP." That seems contradictory. It is therefore suggest to=0D > modify the fourth paragraph so that it reads as originally written=0D > in the standard security considerations template:=0D > =0D > It is RECOMMENDED that implementers consider the security features=0D > as provided by the SNMPv3 framework (see [RFC3410], section 8),=0D > including full support for the SNMPv3 cryptographic mechanisms (for=0D > authentication and privacy).=0D > =0D > 7.) IANA Considerations Section -- OK (none present and none=0D > required).=0D > =0D > 8.) Copyright notices -- the abbreviated copyright notices that are=0D > supposed to appear on the front page and in the DESCRIPTION clause=0D > of each MODULE-IDENTITY invocation are missing and need to be added.=0D > See http://www.ietf.org/ID-nits.html section 1.2,=0D > section 4.3, and=0D > section 3.8.=0D > =0D > 9.) MIB compilation -- the following problems are reported by smilint:=0D > =0D > This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)=0D > has been processed to get the following results:=0D > smilint -m -s -l 6 -i namelength-32 ROHC-MIB=0D > =0D > ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-MIB:184: [5] {index-element-accessible} warning: index element=0D > `rohcInstanceType' of row `rohcInstanceEntry' should be=0D > not-accessible in SMIv2 MIB=0D > =0D > FIXES:=0D > (a) add Counter32 to the list of things imported from SNMPv2-SMI=0D > (b) change MAX-ACCESS value of rohcInstanceType to not-accessible=0D > (c) remove rohcInstanceType from rohcInstanceGroup=0D > =0D > =0D > This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)=0D > has been processed to get the following results:=0D > smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB=0D > =0D > ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base=0D > type `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base=0D > type `Counter32' must be imported from SNMPv2-SMI=0D > =0D > FIX: add Counter32 to the list of things imported from SNMPv2-SMI=0D > =0D > =0D > This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)=0D > has been processed to get the following results:=0D > smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB=0D > =0D > ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type=0D > `Counter32' must be imported from SNMPv2-SMI=0D > =0D > FIX: add Counter32 to the list of things imported from SNMPv2-SMI=0D > =0D > 10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html=0D > that is not covered above:=0D > =0D > (a) there are several places in the MIB modules where the lines=0D > extend beyond column 72. Most (but not all) of these could be fixed=0D > by eliminating the three-space indentation. Althought the RFC=0D > Editor can probably do this, it will save time and reduce the=0D > proabability of formatting errors in the final RFC if the authors=0D > would fix it themselves. See ID-nits section 1.1.=0D > =0D > (b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to=0D > the list of imperatives (although the standard boilerplate in RFC=0D > 2119 does not include it, it is used in the Security Considerations=0D > section and it is defined in RFC 2119).=0D > =0D > (c) in Section 3, "Overview", 3rd paragraph: s/means/a means/=0D > =0D > (d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/=0D > =0D > (e) in Section 4, "Structure of the MIB modules", 1st paragraph:=0D > s/Section 6/Section 5/=0D > =0D > (f) in Section 4, "Structure of the MIB modules", 2nd and 4th=0D > paragraphs: most acronyms must be expanded upon first use,=0D > except for those that everyone in the IETF can reasonably be=0D > expected to know. Note that this rule applies separately for=0D > the body of the memo and the abstract; see Sections 4.7 and 2.9=0D > of or its successor document=0D > and review comment (2) above.=0D > =0D > (g) in Section 4.1, "The ROHC-MIB module", first paragraph: the=0D > tables are mentioned in a different order than they appear in the=0D > MIB module, which has rohcChannelTable before rohcInstanceTable.=0D > Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with=0D > the order in this paragraph but are "swapped" relative to the MIB=0D > module. It might be better if the order in the text matched that=0D > of the MIB module.=0D > =0D > (h) in Section 4.1, "The ROHC-MIB module", last paragraph:=0D > unexpanded acronym CID.=0D > =0D > (i) in Section 4.1.1, "rohcInstanceTable", 4th bullet:=0D > s/storagetime/storage time/=0D > =0D > (j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed=0D > text from:=0D > =0D > o the state of the CID ('unused', 'active', 'expired', or=0D > =0D > to:=0D > =0D > o the state of the CID ('unused', 'active', 'expired', or=0D > 'terminated'.=0D > =0D > Note: a common cause of missing text in an I-D is a line in the=0D > nroff source that starts with a single quote as the first character=0D > of the line.=0D > =0D > 11.) Technical content -- the following comments pertain to the=0D > material in Sections 3, 4, and 5. Please note that I am not an=0D > ROHC subject matter expert and so I do not have the knowledge to=0D > attempt a detailed verification that the MIB objects are indeed=0D > fit for the intended purposes. I'm presuming that the WG has=0D > already done that, so I've concentrated on MIB design issues.=0D > Issues already covered under (9) above won't be repeated here.=0D > =0D > (a) in Section 3, "Overview", next to last paragraph, it is stated=0D > that "the compressor context can be reinitialized." I didn't see=0D > any read-write or read-create objects in the MIB module that would=0D > support such a capability. If indeed there is no support for such=0D > a capability then the claim should be removed.=0D > =0D > (b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3,=0D > "rohcProfileTable", and also in the corresponding definitions in=0D > the ROHC-MIB module in Section 5: it is not clear why one needs a=0D > vendor, version number, and implementation description in both of=0D > these tables. Indeed, except for the descriptors and OIDs that=0D > are assigned, the definitions of rohcInstanceVendor,=0D > rohcInstanceVersion, and rohcInstanceDescr are identical with those=0D > for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr=0D > (respectively). It seems to me that the objects rohcProfileVendor,=0D > rohcProfileVersion, and rohcProfileDescr could be eliminated without=0D > loss of capability. The designers may also wish to consider moving=0D > rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into=0D > the rohcChannelTable or perhaps even turning them into scalars.=0D > =0D > (c) in Section 4.1.3, "rohcProfileTable", there is no mention of=0D > the per-profile Boolean flag that indicates whether the profile=0D > has been negotiated to be used at the instance.=0D > =0D > (d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations=0D > need to be changed in the following ways:=0D > =0D > - WG mailing list info (and optionally, charter page URL) needs to=0D > be present in the CONTACT-INFO clause;=0D > =0D > - there needs to be a REVISION/DESCRIPTION clause pair with a date=0D > identical to that in the LAST-UPDATED clause and a description=0D > indicating that the module is the initial published version;=0D > =0D > - the DESCRIPTION clause needs to include an abbreviated copyright=0D > notice (per (8) above).=0D > =0D > See sections 3.8 and=0D > 4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY=0D > invocation could be changed from:=0D > =0D > rohcMIB MODULE-IDENTITY=0D > LAST-UPDATED "200209251358Z"=0D > ORGANIZATION "IETF Robust Header Compression Working Group"=0D > CONTACT-INFO=0D > "Juergen Quittek=0D > NEC Europe Ltd.=0D > Network Laboratories=0D > Kurfuersten-Anlage 34=0D > 69221 Heidelberg=0D > Germany=0D > Tel: +49 6221 90511-15=0D > E-mail: quittek@ccrle.nec.de"=0D > DESCRIPTION=0D > "This MIB module defines a set of basic objects for=0D > monitoring and configuring robust header compression.=0D > The module covers information about running instances=0D > of ROHC (compressors or decompressors) at IP interfaces.=0D > =0D > Information about compressor contexts and decompressor=0D > contexts has different structure for different profiles.=0D > Therefore it is not provided by this MIB module, but by=0D > individual modules for dofferent profiles."=0D > ::=3D { mib-2 XXX }=0D > -- XXX to be assigned by IANA.=0D > =0D > to something along the lines of:=0D > =0D > rohcMIB MODULE-IDENTITY=0D > LAST-UPDATED "200306250000Z" -- June 25, 2003=0D > ORGANIZATION "IETF Robust Header Compression Working Group"=0D > CONTACT-INFO=0D > "WG charter:=0D > http://www.ietf.org/html.charters/rohc-charter.html=0D > =0D > Mailing Lists:=0D > General Discussion: rohc@ietf.org=0D > To Subscribe: rohc-request@ietf.org=0D > In Body: subscribe your_email_address=0D > =0D > Editor:=0D > Juergen Quittek=0D > NEC Europe Ltd.=0D > Network Laboratories=0D > Kurfuersten-Anlage 34=0D > 69221 Heidelberg=0D > Germany=0D > Tel: +49 6221 90511-15=0D > E-mail: quittek@ccrle.nec.de"=0D > DESCRIPTION=0D > "This MIB module defines a set of basic objects for=0D > monitoring and configuring robust header compression.=0D > The module covers information about running instances=0D > of ROHC (compressors or decompressors) at IP interfaces.=0D > =0D > Information about compressor contexts and decompressor=0D > contexts has different structure for different profiles.=0D > Therefore it is not provided by this MIB module, but by=0D > individual modules for different profiles.=0D > =0D > Copyright (C) The Internet Society (2003). This version=0D > of this MIB module is part of RFC yyyy; see the RFC=0D > itself for full legal notices."=0D > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice=0D > =0D > REVISION "200306250000Z" -- June 25, 2003=0D > DESCRIPTION "Initial version, published as RFC yyyy."=0D > -- RFC Ed.: replace yyyy with actual RFC number & remove this notice=0D > =0D > ::=3D { mib-2 XXX }=0D > -- XXX to be assigned by IANA.=0D > =0D > with the dates changed as appropriate. [Note also a typo fix:=0D > s/dofferent/different/.] Similar changes apply to the other=0D > MIB modules.=0D > =0D > (e) in Section 5, all MIB modules: the ordering of the index=0D > components is not consistent throughout. Specifically, although=0D > all tables are indexed by ifIndex and rohcChannelID, the tables=0D > without rohcInstanceType as an index component all have=0D > { ifIndex, rohcChannelID, ... } as a common prefix, while those=0D > with rohcInstanceType do not: their common prefix is=0D > { ifIndex, rohcInstanceType, rohcChannelID, ... }. While this=0D > will certainly work, and may be legitimate if one wishes to have a=0D > different sort order in different tables, the MIB designers should=0D > be aware that it tends to make the implementation harder than it=0D > otherwise would be, because there is less indexing code that can=0D > be shared between different tables. Unless there was a specific=0D > reason for choosing the specific index order that is in the draft,=0D > the authors may wish to consider changing the order of the leading=0D > components in the tables that have rohcInstanceType as an index=0D > component from:=0D > =0D > INDEX { ifIndex, rohcInstanceType, rohcChannelID, ... }=0D > =0D > to:=0D > =0D > INDEX { ifIndex, rohcChannelID, rohcInstanceType, ... }=0D > =0D > The affected row objects are rohcInstanceEntry and rohcContextTable=0D > in the ROHC-MIB module, rohcUncmprContextEntry in the=0D > ROHC-UNCOMPRESSED-MIB module, and rohcRtpContextTable and=0D > rohcRtpPacketSizeEntry in the ROHC-RTP-MIB module.=0D > =0D > (f) in Section 5, all MIB modules: none of the Counter32 objects=0D > has a discontinuity time indicator. Such an indicator is required=0D > if events other than a reboot may result in a discontinuity (i.e.,=0D > non-monotonic counting behaviour); see the first bullet of Section=0D > 4.6.1.2 of . Since=0D > each counter is associated with a specific interface, a good=0D > solution in this case is to use IF-MIB's ifCounterDiscontinuityTime=0D > for this purpose, as is done in the EtherLike-MIB (RFC 2665),=0D > the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That=0D > would mean adding the following or similar text=0D > =0D > Discontinuities in the value of this counter can=0D > occur at re-initialization of the management=0D > system, and at other times as indicated by the=0D > value of ifCounterDiscontinuityTime.=0D > =0D > to the DESCRIPTION clause of each of the Counter32 objects.=0D > =0D > (g) in Section 5, all MIB modules: it is observed that many objects=0D > are defined with SYNTAX values of of Integer32 (0..2147483647),=0D > Integer32 (1..2147483647), and Integer32 (0..1000). While this is=0D > certainly acceptable, it is brought to the authors' attention that=0D > Unsigned32 is preferred when the range of values is non-negative;=0D > see Section 4.6.1.1.=0D > Changes, if any, are left to the authors' discretion. (Note:=0D > current usage is consistent for all objects; if a change is made,=0D > please be sure to do so everywhere; but see 11(m) first.)=0D > =0D > /********** The following comments apply to the ROHC-MIB **********/=0D > =0D > (h) In the DESCRIPTION clause of rohcChannelID it says:=0D > =0D > The value is expected to remain constant at least from one=0D > re-initialization of the entity's network management system=0D > to the next re-initialization.=0D > =0D > I know that this same language is used in the IF-MIB, but it turns=0D > out that indices that don't remain fixed across reboots can lead=0D > to problems. See the thread "Referential integrity across reboots"=0D > at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140=0D > Suggested remedy: change the above text to:=0D > =0D > The value is REQUIRED to remain constant at least from one=0D > re-initialization of the entity's network management system=0D > to the next re-initialization. It is RECOMMENDED that the=0D > value persist across such re-initializations.=0D > =0D > (i) In the DESCRIPTION clause of rohcChannelFeedbackFor:=0D > s/feddback/feedback/=0D > =0D > (j) In the following object definition it is not specified what=0D > value the object should assume if there is no feedback channel:=0D > =0D > rohcInstanceFBChannelID OBJECT-TYPE=0D > SYNTAX RohcChannelIdentifier=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "Identifier of the channel used for feedback."=0D > ::=3D { rohcInstanceEntry 4 }=0D > =0D > Shouldn't the DESCRIPTION clause state that the value 0 is used in=0D > that case? It would seem to be consistent with the instructions in=0D > the RohcChannelIdentifier DESCRIPTION clause to do this.=0D > =0D > (k) In the following object definition:=0D > =0D > rohcInstanceMRRU OBJECT-TYPE=0D > SYNTAX Integer32 (1..2147483647)=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "Maximum reconstructed reception unit. This is the=0D > size of the largest reconstructed unit in octets that=0D > the decompressor is expected to reassemble from=0D > segments (see RFC 3095, Section 5.2.5). Note that this=0D > size includes the CRC. If MRRU is negotiated to be 0,=0D > no segment headers are allowed on the channel."=0D > REFERENCE=0D > "RFC 3095, Section 5.1.1"=0D > ::=3D { rohcInstanceEntry 11 }=0D > =0D > the SYNTAX value and the DESCRIPTION clause are at odds.=0D > =0D > FIX: change the SYNTAX value to Integer32 (0..2147483647)=0D > =0D > (l) In the following object definition:=0D > =0D > rohcInstanceContextsCurrent OBJECT-TYPE=0D > SYNTAX Integer32=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "Number of currently active contexts created by this instance."= =0D > ::=3D { rohcInstanceEntry 15 }=0D > =0D > a more appropriate SYNTAX value would be Integer32 (0..2147483647)=0D > since the number of contexts cannot possibly be negative.=0D > =0D > (m) In the following object definition:=0D > =0D > rohcInstanceCompressionRatio OBJECT-TYPE=0D > SYNTAX Integer32 (0..1000)=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "This object indicates the compression ratio so far over all=0D > packets on the channel served by this instance. The value is=0D > defined as 1000 * bytes(compressed) / bytes(original) rounded=0D > to the next integer value. The number of bytes corresponds=0D > to all bytes of all IP packets including the IP header but=0D > excluding all lower layer headers."=0D > ::=3D { rohcInstanceEntry 20 }=0D > =0D > Is it theoretically possible for the compression ratio to exceed unity=0D > in certain unfavorable cases? If so, then the range needs to be=0D > changed to allow for that, or the DESCRIPTION clause needs to state=0D > that the value is set to 1000 if the actual compression ratio exceeds=0D > unity. In the latter case a more appropriate SYNTAX value would be=0D > Gauge32 (0..1000) (see =0D > Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION=0D > RATIO OBJECTS.=0D > =0D > (n) I'm not sure if I properly understood the DESCRIPTION clause of=0D > the following object:=0D > =0D > rohcProfileNegotiated OBJECT-TYPE=0D > SYNTAX TruthValue=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "When retrieved, this boolean object returns true=0D > if the profile has been negotiated to be used at=0D > the instance, i.e. is supported also by the=0D > corresponding compressor/decompressor."=0D > ::=3D { rohcProfileEntry 7 }=0D > =0D > My understanding is that an instance of this object corresponding to=0D > a particular triple should=0D > have the value true(1) if and only if at least one context with the=0D > same values is using that profile -- in=0D > other words, if and only if some instance of rohcContextProfile for=0D > the same values is equal to the rohcProfile=0D > value. If this understanding is _not_ correct, then clarification=0D > of the DESCRIPTION clause would be in order.=0D > =0D > (o) Several DESCRIPTION clauses in the ROHC-MIB refer to the=0D > non-existent object rohcContextType. They should refer instead to=0D > rohcInstanceType. The objects in question are:=0D > =0D > rohcContextDecompressorDepth=0D > rohcContextDecompressorFailures=0D > rohcContextDecompressorRepairs=0D > =0D > (p) In the following object definition [n.b. the above correction=0D > has been assumed to be applied]:=0D > =0D > rohcContextDecompressorDepth OBJECT-TYPE=0D > SYNTAX Integer32 (0..2147483647)=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "This object indicates whether reverse decompression, for=0D > example as described in RFC 3095, Section 6.1, is used=0D > on this channel or not, and if used, to what extent.=0D > =0D > Its value is only valid for decompressor contexts, i.e.=0D > if rohcInstanceType has the value decompressor(2).=0D > =0D > The value of the reverse decompression depth indicates=0D > the maximum number of packets that are buffered, and thus=0D > possibly be reverse decompressed by the decompressor.=0D > A zero (0) value means that reverse decompression is not=0D > used."=0D > ::=3D { rohcContextEntry 7 }=0D > =0D > it is not clear whether this object should have the value 0 for=0D > compressor contexts, or whether it should not be instantiated at=0D > all for such contexts.=0D > =0D > (q) The rohcCompliance DESCRIPTION clause should mention that the=0D > ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of=0D > , last paragraph=0D > before end note. Examples may be found in the dot3Compliance2=0D > statement in , the=0D > mauModIfCompl3 statement in ,=0D > or the etherWisCompliance in =0D > (although it is requested that the embedded citations be avoided).=0D > =0D > /*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/=0D > =0D > (r) The rohcUncmprCompliance DESCRIPTION clause should mention that=0D > the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as=0D > prerequisites. See 11(q) above for examples.=0D > =0D > /******** The following comments apply to the ROHC-RTP-MIB ********/=0D > =0D > (s) The DESCRIPTION clauses of several columnar objects in the=0D > rohcRtpContextTable state that those objects are valid only for=0D > certain profiles or for certain contexts. The objects in question=0D > are:=0D > =0D > rohcRtpContextAlwaysPad=0D > rohcRtpContextLargePktsAllowed=0D > rohcRtpContextVerifyPeriod=0D > rohcRtpContextSizesAllowed=0D > rohcRtpContextSizesUsed=0D > =0D > If the intent is that those objects are to be instantiated only for=0D > the profiles or contexts to which they apply, then that fact should=0D > be made explicit in the DESCRIPTION clauses.=0D > =0D > (t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and=0D > rohcRtpContextSizesUsed both appear to have the same three=0D > typographical errors:=0D > =0D > rohcRtpContextSizesAllowed OBJECT-TYPE=0D > SYNTAX Integer32 (1..2147483647)=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "The value of this object is only valid for decompressor=0D > contexts, i.e. if rohcContextType of the cooresponding=0D > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^=0D > rohcContextEntry has the value compressor(2).=0D > ^^^^^^^^^^^^^=0D > =0D > This object contains the number of different packet sizes=0D > that may be used in the context."=0D > REFERENCE=0D > "RFC 3095, Section 6.3.1"=0D > ::=3D { rohcRtpContextEntry 10 }=0D > =0D > rohcRtpContextSizesUsed OBJECT-TYPE=0D > SYNTAX Integer32 (1..2147483647)=0D > MAX-ACCESS read-only=0D > STATUS current=0D > DESCRIPTION=0D > "The value of this object is only valid for decompressor=0D > contexts, i.e. if rohcContextType of the cooresponding=0D > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^=0D > rohcContextEntry has the value compressor(2).=0D > ^^^^^^^^^^^^^=0D > =0D > This object contains the number of different packet sizes=0D > that are used in the context."=0D > REFERENCE=0D > "RFC 3095, Section 6.3.1"=0D > ::=3D { rohcRtpContextEntry 11 }=0D > =0D > Suggested fixes: s/rohcContextType/rohcInstanceType/=0D > s/cooresponding/corresponding/=0D > s/compressor(2)/decompressor(2)/=0D > =0D > (u) There are some design issues with the rohcRtpPacketSizeTable:=0D > =0D > - the index column rohcRtpPacketSize with has values in the range=0D > 0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that=0D > PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive=0D > integers, i.e., the value 0 is excluded as it does not make sense.=0D > FIX: change the range to 1..2147483647. (This also avoids=0D > running afoul of the SMIv2 rule that index values of zero should=0D > be avoided, except in special cases.)=0D > =0D > - the TruthValue column rohcRtpPacketSizeAllowed seems to be=0D > unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that=0D > "packet sizes not in the set of values for [PACKET_SIZES_ALLOWED]=0D > MUST NOT be used", it seems that an agent would never need to=0D > instantiate any of the other columns if rohcRtpPacketSizeAllowed=0D > had the value false(2). In other words, any row for which this=0D > objects is false should simply be absent from the table.=0D > =0D > (v) The rohcRtpCompliance DESCRIPTION clause should mention that=0D > the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as=0D > prerequisites. See 11(q) above for examples.=0D > =0D > This concludes the review of .=0D > =0D > Regards,=0D > =0D > Mike Heard=0D > =0D > =0D > _______________________________________________=0D > Rohc mailing list=0D > Rohc@ietf.org=0D > https://www1.ietf.org/mailman/listinfo/rohc=0D > =0D --=20 =99=91 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jul 7 17:10:01 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 RAA15938 for ; Mon, 7 Jul 2003 17:10:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdEq-0006AA-Dj for rohc-archive@odin.ietf.org; Mon, 07 Jul 2003 17:09:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67L9WMc023686 for rohc-archive@odin.ietf.org; Mon, 7 Jul 2003 17:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdEq-00069x-9R for rohc-web-archive@optimus.ietf.org; Mon, 07 Jul 2003 17:09:32 -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 RAA15893 for ; Mon, 7 Jul 2003 17:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdEL-000686-9d; Mon, 07 Jul 2003 17:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcpT-00045r-NR for rohc@optimus.ietf.org; Mon, 07 Jul 2003 16:43: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 QAA14373 for ; Mon, 7 Jul 2003 16:43:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcpR-0002UN-00 for rohc@ietf.org; Mon, 07 Jul 2003 16:43:17 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19ZcpP-0002Tk-00 for rohc@ietf.org; Mon, 07 Jul 2003 16:43:15 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h67KgdVI042870; Mon, 7 Jul 2003 22:42:42 +0200 (CEST) Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 17F2FB561D; Mon, 7 Jul 2003 22:25:17 +0200 (CEST) Cc: "Wijnen, Bert (Bert)" , "'C. M. Heard'" , "ROHC mailing list" X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.45 references: From: "Juergen Quittek" MIME-Version: 1.0 subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt To: "Surtees, Abigail" content-type: text/plain; charset="iso-8859-1" date: Mon, 07 Jul 2003 22:25:16 +0200 Message-Id: <20030707202517.17F2FB561D@venus.office> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tokyo.ccrle.nec.de id h67KgdVI042870 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Abbie,=0D =0D Initially, rohcInstanceType was no index. Probably this is the=0D reason why we forgot to make it non-accessible. But after some discussion= s=0D with rohc people, partiularly including with Lars-Erik, we found that=0D when accessing the MIB a management station would typically look either=0D for compressors or for decompressors, but not for particular channels.=0D =0D Without the rohcInstanceType being part of the index, a management statio= n=0D looking for a particular compressor or looking for all compressors would = need=0D to browse through all compressor and decompressor contexts, read the type= =0D and ignore them if they are decompressors.=0D =0D But with the rohcInstanceType as n index before the channel ID, you can=0D first select whether you ant to browse compressors or decompressors and=0D then go through the (shorter) list of specific contexts.=0D =0D I think this is helpful and matches requirements of rohc management stati= ons.=0D =0D Cheers,=0D =0D Juergen=0D =0D > Hi All,=0D > =0D > Having had a look at the MIB I have a question about it. One problem=0D > mentioned below is that rohcInstanceType should have MAX-ACCESS value o= f=0D > not-accessible. =0D > =0D > The fix proposed by the MIB doctor is the following.=0D > =0D > >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible=0D > >(c) remove rohcInstanceType from rohcInstanceGroup=0D > =0D > The reason it should be not-accessible is because it is used as an inde= x=0D > into the rohcInstanceTable and the rohcContextTable.=0D > =0D > Why does it need to be an index into these tables?=0D > =0D > In my understanding (please correct me if I'm wrong) from reading the=0D > terminology draft, each instance will have its own channel ID which can= =0D > uniquely identify it on an interface. A single instance can only be a=0D > compressor or a decompressor and is already identified by ifIndex and=0D > rohcChannelID, so using the rohcInstanceType as an index doesn't actual= ly=0D > identify anything further. =0D > If it doesn't need to be an index, then a MAX-ACCESS value of read-only= is=0D > acceptable.=0D > =0D > Am I missing something?=0D > =0D > Best regards,=0D > =0D > Abbie=0D > Abbie Surtees=0D > Engineer=0D > Internet Applications and Mobility=0D > Roke Manor Research Ltd=0D > Tel: +44 (0) 1794 833131=0D > =0D > >-----Original Message-----=0D > >From: C. M. Heard [mailto:heard@pobox.com]=0D > >Sent: 25 June 2003 07:04=0D > >To: ROHC mailing list=0D > >Cc: Wijnen, Bert (Bert)=0D > >Subject: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt=0D > >=0D > >=0D > >>>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote:=0D > >Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt=0D > >Bert> in the next week or two?=0D > >=0D > >>>>>> On Fri, 13 Jun 2003, C. M. Heard replied:=0D > >CMH> I will volunteer to do this. Based on a quick look I think=0D > >CMH> I should be able to turn around the review before June 26th.=0D > >=0D > >As noted above, I've volunteered to do a MIB Doctor review of=0D > >. For the most part, I have been=0D > >pleased with the quality of that document. However, there are a=0D > >number of things that do need to be corrected, or at least looked=0D > >at, before the document goes to the IESG. The detailed review=0D > >comments below follow the checklist from Appendix A of the draft=0D > >guidelines document .=0D > >Those who wish to respond to these review comments should do so on=0D > >the ROHC mailing list, with copies to Bert Wijnen and myself.=0D > >=0D > >0.) Title -- s/Robus/Robust/=0D > >=0D > >1.) I-D Boilerplate -- OK=0D > >=0D > >2.) Abstract -- acronyms used in the abstract must be expanded on=0D > >first use, except for those acronyms that everyone in the IETF can=0D > >reasonably be expected to know (see Sections 4.5 and 2.9 of=0D > > or its successor document).=0D > >Certainly ROHC and LLA will need to be expanded; I'm not sure about=0D > >ESP and RTP -- please check with the RFC Editor. Here is a partial=0D > >fix:=0D > >=0D > > This memo defines a portion of the Management Information Base (MIB)=0D > > for use with network management protocols in the Internet community.=0D > > In particular, it describes a set of managed objects that allow=0D > > monitoring of running instances of RObust Header Compression (ROHC).=0D > > [ ... ]=0D > >=0D > >The remainder is left to the authors to sort out.=0D > >=0D > >3.) MIB Boilerplate -- OK=0D > >=0D > >4.) IPR Notices -- the required notices from RFC 2026 Sections=0D > >10.4(A) and 10.4(B) are present and no claims are noted; this=0D > >is OK if indeed there are no relevant IPR disclosures. Note,=0D > >however, that a search of the IPR statements on the IETF web site=0D > >does reveal some claims that seem like they _might_ be relevant:=0D > >=0D > > Search Results for query =3D '(robust or robustness or robustly)=0D > > and (header or head or headed or heading or headings or heads=0D > > or headers) and (compression or compressions)'=0D > > _________________________________________________________________=0D > >=0D > > Match: [All....] Format: [Long.] Sort by: [Title........]=0D > > Refine search: ______________________________ Search=0D > > _________________________________________________________________=0D > >=0D > > Documents 1 - 4 of 11 matches. More * 's indicate a better match.=0D > > _________________________________________________________________=0D > >=0D > > [ERICSSON-ROCCO] *=0D > > ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE=0D > > UNDERTAKING In the AVT Working Group in the Internet=0D > > Engineering Task Force, a proposal "RObust Checksum-based=0D > > header COmpression (ROCCO)" dated June 22, 1999 has been=0D > > made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at=0D > > Lulea University ...=0D > > http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557=0D > > bytes=0D > >=0D > > [ERICSSON-SIGCOMP.txt] * * * *=0D > > ... that might possibly have technical relations to the=0D > > Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt.=0D > > This draft is part of the Signaling Compression work=0D > > taking place in the Robust Header Compression (ROHC) WG.=0D > > See further Ericsson's general IPR statement:=0D > > http://www.ietf.org/ietf/IPR/ERICSSON ...=0D > > http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02,=0D > > 466 bytes=0D > >=0D > > [NOKIA-RFC3095.txt] *=0D > > ... : 1) "CID field handling in ROHC": FI 20002100, US=0D > > 09/954562, PCT/FI01/00819 2) "Variable length context=0D > > identifier for real time header compression": FI 20002307,=0D > > US 09/978479, PCT/FI01/00902 3) "Variable length encoding of=0D > > compressed data": US 09/536638, US 60/164330, ...=0D > > http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02,=0D > > 1373 bytes=0D > >=0D > > [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] *=0D > > ... This is to advise the IETF that Telefonaktiebolaget LM=0D > > Ericsson believes it owns patents and patent applications=0D > > which may relate to RFC 3095, "RObust Header Compression=0D > > (ROHC): Framework and four profiles: RTP, UDP, ESP, and=0D > > uncompressed". See further Ericsson's general IPR=0D > > statement: http://www.ietf.org/ietf/IPR/ERICSSON ...=0D > > http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST-=0D > > HEADER-COMPRESSION.txt 09/27/02, 439 bytes=0D > >=0D > > Return to the Seach Page=0D > > _________________________________________________________________=0D > >=0D > > ht://Dig 3.1.6=0D > >=0D > >The document authors and the WG should examine these IPR disclosures=0D > >and either determine for sure that none are required in order to=0D > >implement the MIB module or else add the notice from RFC 2026=0D > >Section 10.4(D). (The reviewer will be satisfied if the authors=0D > >reply that the IPR section in the document is OK as it stands. All=0D > >that's being requested is an assurance that you have done your=0D > >homework.)=0D > >=0D > >5.) References -- there are some missing normative references and=0D > >some of the existing references contain minor errors or don't=0D > >exactly follow the current RFC style. The style issues are listed=0D > >only for completeness; RFC Editor will fix that in any case.=0D > >=0D > >(a) RFC 3411 needs to be added as a normative reference since=0D > >SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB=0D > >(c.f. Section 3.5).=0D > >=0D > >(b) RFC 2863 needs to be added as a normative reference since=0D > >IF-MIB appears in the IMPORTS statement of all three MIB=0D > >modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB.=0D > >=0D > >(c) [RFC3095] has an incorrect title and an author list that's not=0D > >in the standard form.=0D > >=0D > >(d) [RFC3242] has an author list that's not in the standard form.=0D > >=0D > >(e) [RFCXXXX] has an author list that's not in the standard form,=0D > >and it might be helpful to readers to indicate the I-D that will=0D > >eventually turn into this RFC-to-be.=0D > >=0D > >6.) Security Considerations Section -- there are two read/write=0D > >objects but only one is mentioned. A possible fix would be to=0D > >revise the first paragraph to read as follows:=0D > >=0D > > The managed objects defined by the ROHC-MIB module, the=0D > > ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not=0D > > have a MAX-ACCESS value of read-write and/or read-create except=0D > > rohcInstanceContextStorageTime and rohcContextStorageTime, both of=0D > > which have a MAX-ACCESS value of read-write. These objects=0D > > determine how long context information is stored after its=0D > > termination. Unauthorized access to these objects can have one of=0D > > two negative effects. If they are set to a value lower than=0D > > required, e.g. to zero, then context information about past contexts=0D > > might get lost. If they are set to a very high value, then context=0D > > information will not be deleted and memory consumption of the agent=0D > > implementation might become very high. However, unauthorized access=0D > > to these objects cannot cause harm to existing ROHC connections nor=0D > > can it allow manipulation of running instances of ROHC in a=0D > > malicious way.=0D > >=0D > >The fourth paragraph says "[a]lthough the security risks arising=0D > >from the ROHC-MIB module are not considered to be high", but the=0D > >second paragraph says "[it is] important to control even GET and/or=0D > >NOTIFY access to these objects and possibly to even encrypt the=0D > >values of these objects when sending them over the network via=0D > >SNMP." That seems contradictory. It is therefore suggest to=0D > >modify the fourth paragraph so that it reads as originally written=0D > >in the standard security considerations template:=0D > >=0D > > It is RECOMMENDED that implementers consider the security features=0D > > as provided by the SNMPv3 framework (see [RFC3410], section 8),=0D > > including full support for the SNMPv3 cryptographic mechanisms (for=0D > > authentication and privacy).=0D > >=0D > >7.) IANA Considerations Section -- OK (none present and none=0D > >required).=0D > >=0D > >8.) Copyright notices -- the abbreviated copyright notices that are=0D > >supposed to appear on the front page and in the DESCRIPTION clause=0D > >of each MODULE-IDENTITY invocation are missing and need to be added.=0D > >See http://www.ietf.org/ID-nits.html section 1.2,=0D > > section 4.3, and=0D > > section 3.8.=0D > >=0D > >9.) MIB compilation -- the following problems are reported by smilint:= =0D > >=0D > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)=0D > >has been processed to get the following results:=0D > >smilint -m -s -l 6 -i namelength-32 ROHC-MIB=0D > >=0D > >ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-MIB:184: [5] {index-element-accessible} warning: index element=0D > >`rohcInstanceType' of row `rohcInstanceEntry' should be=0D > >not-accessible in SMIv2 MIB=0D > >=0D > >FIXES:=0D > >(a) add Counter32 to the list of things imported from SNMPv2-SMI=0D > >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible=0D > >(c) remove rohcInstanceType from rohcInstanceGroup=0D > >=0D > >=0D > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)=0D > >has been processed to get the following results:=0D > >smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB=0D > >=0D > >ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base=0D > >type `Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base=0D > >type `Counter32' must be imported from SNMPv2-SMI=0D > >=0D > >FIX: add Counter32 to the list of things imported from SNMPv2-SMI=0D > >=0D > >=0D > >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003)=0D > >has been processed to get the following results:=0D > >smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB=0D > >=0D > >ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type=0D > >`Counter32' must be imported from SNMPv2-SMI=0D > >=0D > >FIX: add Counter32 to the list of things imported from SNMPv2-SMI=0D > >=0D > >10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html=0D > >that is not covered above:=0D > >=0D > >(a) there are several places in the MIB modules where the lines=0D > >extend beyond column 72. Most (but not all) of these could be fixed=0D > >by eliminating the three-space indentation. Althought the RFC=0D > >Editor can probably do this, it will save time and reduce the=0D > >proabability of formatting errors in the final RFC if the authors=0D > >would fix it themselves. See ID-nits section 1.1.=0D > >=0D > >(b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to=0D > >the list of imperatives (although the standard boilerplate in RFC=0D > >2119 does not include it, it is used in the Security Considerations=0D > >section and it is defined in RFC 2119).=0D > >=0D > >(c) in Section 3, "Overview", 3rd paragraph: s/means/a means/=0D > >=0D > >(d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/=0D > >=0D > >(e) in Section 4, "Structure of the MIB modules", 1st paragraph:=0D > >s/Section 6/Section 5/=0D > >=0D > >(f) in Section 4, "Structure of the MIB modules", 2nd and 4th=0D > >paragraphs: most acronyms must be expanded upon first use,=0D > >except for those that everyone in the IETF can reasonably be=0D > >expected to know. Note that this rule applies separately for=0D > >the body of the memo and the abstract; see Sections 4.7 and 2.9=0D > >of or its successor document=0D > >and review comment (2) above.=0D > >=0D > >(g) in Section 4.1, "The ROHC-MIB module", first paragraph: the=0D > >tables are mentioned in a different order than they appear in the=0D > >MIB module, which has rohcChannelTable before rohcInstanceTable.=0D > >Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with=0D > >the order in this paragraph but are "swapped" relative to the MIB=0D > >module. It might be better if the order in the text matched that=0D > >of the MIB module.=0D > >=0D > >(h) in Section 4.1, "The ROHC-MIB module", last paragraph:=0D > >unexpanded acronym CID.=0D > >=0D > >(i) in Section 4.1.1, "rohcInstanceTable", 4th bullet:=0D > >s/storagetime/storage time/=0D > >=0D > >(j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed=0D > >text from:=0D > >=0D > > o the state of the CID ('unused', 'active', 'expired', or=0D > >=0D > >to:=0D > >=0D > > o the state of the CID ('unused', 'active', 'expired', or=0D > > 'terminated'.=0D > >=0D > >Note: a common cause of missing text in an I-D is a line in the=0D > >nroff source that starts with a single quote as the first character=0D > >of the line.=0D > >=0D > >11.) Technical content -- the following comments pertain to the=0D > >material in Sections 3, 4, and 5. Please note that I am not an=0D > >ROHC subject matter expert and so I do not have the knowledge to=0D > >attempt a detailed verification that the MIB objects are indeed=0D > >fit for the intended purposes. I'm presuming that the WG has=0D > >already done that, so I've concentrated on MIB design issues.=0D > >Issues already covered under (9) above won't be repeated here.=0D > >=0D > >(a) in Section 3, "Overview", next to last paragraph, it is stated=0D > >that "the compressor context can be reinitialized." I didn't see=0D > >any read-write or read-create objects in the MIB module that would=0D > >support such a capability. If indeed there is no support for such=0D > >a capability then the claim should be removed.=0D > >=0D > >(b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3,=0D > >"rohcProfileTable", and also in the corresponding definitions in=0D > >the ROHC-MIB module in Section 5: it is not clear why one needs a=0D > >vendor, version number, and implementation description in both of=0D > >these tables. Indeed, except for the descriptors and OIDs that=0D > >are assigned, the definitions of rohcInstanceVendor,=0D > >rohcInstanceVersion, and rohcInstanceDescr are identical with those=0D > >for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr=0D > >(respectively). It seems to me that the objects rohcProfileVendor,=0D > >rohcProfileVersion, and rohcProfileDescr could be eliminated without=0D > >loss of capability. The designers may also wish to consider moving=0D > >rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into=0D > >the rohcChannelTable or perhaps even turning them into scalars.=0D > >=0D > >(c) in Section 4.1.3, "rohcProfileTable", there is no mention of=0D > >the per-profile Boolean flag that indicates whether the profile=0D > >has been negotiated to be used at the instance.=0D > >=0D > >(d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations=0D > >need to be changed in the following ways:=0D > >=0D > > - WG mailing list info (and optionally, charter page URL) needs to=0D > > be present in the CONTACT-INFO clause;=0D > >=0D > > - there needs to be a REVISION/DESCRIPTION clause pair with a date=0D > > identical to that in the LAST-UPDATED clause and a description=0D > > indicating that the module is the initial published version;=0D > >=0D > > - the DESCRIPTION clause needs to include an abbreviated copyright=0D > > notice (per (8) above).=0D > >=0D > >See sections 3.8 and=0D > >4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY=0D > >invocation could be changed from:=0D > >=0D > >rohcMIB MODULE-IDENTITY=0D > > LAST-UPDATED "200209251358Z"=0D > > ORGANIZATION "IETF Robust Header Compression Working Group"=0D > > CONTACT-INFO=0D > > "Juergen Quittek=0D > > NEC Europe Ltd.=0D > > Network Laboratories=0D > > Kurfuersten-Anlage 34=0D > > 69221 Heidelberg=0D > > Germany=0D > > Tel: +49 6221 90511-15=0D > > E-mail: quittek@ccrle.nec.de"=0D > > DESCRIPTION=0D > > "This MIB module defines a set of basic objects for=0D > > monitoring and configuring robust header compression.=0D > > The module covers information about running instances=0D > > of ROHC (compressors or decompressors) at IP interfaces.=0D > >=0D > > Information about compressor contexts and decompressor=0D > > contexts has different structure for different profiles.=0D > > Therefore it is not provided by this MIB module, but by=0D > > individual modules for dofferent profiles."=0D > > ::=3D { mib-2 XXX }=0D > >-- XXX to be assigned by IANA.=0D > >=0D > >to something along the lines of:=0D > >=0D > >rohcMIB MODULE-IDENTITY=0D > > LAST-UPDATED "200306250000Z" -- June 25, 2003=0D > > ORGANIZATION "IETF Robust Header Compression Working Group"=0D > > CONTACT-INFO=0D > > "WG charter:=0D > > http://www.ietf.org/html.charters/rohc-charter.html=0D > >=0D > > Mailing Lists:=0D > > General Discussion: rohc@ietf.org=0D > > To Subscribe: rohc-request@ietf.org=0D > > In Body: subscribe your_email_address=0D > >=0D > > Editor:=0D > > Juergen Quittek=0D > > NEC Europe Ltd.=0D > > Network Laboratories=0D > > Kurfuersten-Anlage 34=0D > > 69221 Heidelberg=0D > > Germany=0D > > Tel: +49 6221 90511-15=0D > > E-mail: quittek@ccrle.nec.de"=0D > > DESCRIPTION=0D > > "This MIB module defines a set of basic objects for=0D > > monitoring and configuring robust header compression.=0D > > The module covers information about running instances=0D > > of ROHC (compressors or decompressors) at IP interfaces.=0D > >=0D > > Information about compressor contexts and decompressor=0D > > contexts has different structure for different profiles.=0D > > Therefore it is not provided by this MIB module, but by=0D > > individual modules for different profiles.=0D > >=0D > > Copyright (C) The Internet Society (2003). This version=0D > > of this MIB module is part of RFC yyyy; see the RFC=0D > > itself for full legal notices."=0D > >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice=0D > >=0D > > REVISION "200306250000Z" -- June 25, 2003=0D > > DESCRIPTION "Initial version, published as RFC yyyy."=0D > >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice=0D > >=0D > > ::=3D { mib-2 XXX }=0D > >-- XXX to be assigned by IANA.=0D > >=0D > >with the dates changed as appropriate. [Note also a typo fix:=0D > >s/dofferent/different/.] Similar changes apply to the other=0D > >MIB modules.=0D > >=0D > >(e) in Section 5, all MIB modules: the ordering of the index=0D > >components is not consistent throughout. Specifically, although=0D > >all tables are indexed by ifIndex and rohcChannelID, the tables=0D > >without rohcInstanceType as an index component all have=0D > >{ ifIndex, rohcChannelID, ... } as a common prefix, while those=0D > >with rohcInstanceType do not: their common prefix is=0D > >{ ifIndex, rohcInstanceType, rohcChannelID, ... }. While this=0D > >will certainly work, and may be legitimate if one wishes to have a=0D > >different sort order in different tables, the MIB designers should=0D > >be aware that it tends to make the implementation harder than it=0D > >otherwise would be, because there is less indexing code that can=0D > >be shared between different tables. Unless there was a specific=0D > >reason for choosing the specific index order that is in the draft,=0D > >the authors may wish to consider changing the order of the leading=0D > >components in the tables that have rohcInstanceType as an index=0D > >component from:=0D > >=0D > > INDEX { ifIndex, rohcInstanceType, rohcChannelID, ... }=0D > >=0D > >to:=0D > >=0D > > INDEX { ifIndex, rohcChannelID, rohcInstanceType, ... }=0D > >=0D > >The affected row objects are rohcInstanceEntry and rohcContextTable=0D > >in the ROHC-MIB module, rohcUncmprContextEntry in the=0D > >ROHC-UNCOMPRESSED-MIB module, and rohcRtpContextTable and=0D > >rohcRtpPacketSizeEntry in the ROHC-RTP-MIB module.=0D > >=0D > >(f) in Section 5, all MIB modules: none of the Counter32 objects=0D > >has a discontinuity time indicator. Such an indicator is required=0D > >if events other than a reboot may result in a discontinuity (i.e.,=0D > >non-monotonic counting behaviour); see the first bullet of Section=0D > >4.6.1.2 of . Since=0D > >each counter is associated with a specific interface, a good=0D > >solution in this case is to use IF-MIB's ifCounterDiscontinuityTime=0D > >for this purpose, as is done in the EtherLike-MIB (RFC 2665),=0D > >the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That=0D > >would mean adding the following or similar text=0D > >=0D > > Discontinuities in the value of this counter can=0D > > occur at re-initialization of the management=0D > > system, and at other times as indicated by the=0D > > value of ifCounterDiscontinuityTime.=0D > >=0D > >to the DESCRIPTION clause of each of the Counter32 objects.=0D > >=0D > >(g) in Section 5, all MIB modules: it is observed that many objects=0D > >are defined with SYNTAX values of of Integer32 (0..2147483647),=0D > >Integer32 (1..2147483647), and Integer32 (0..1000). While this is=0D > >certainly acceptable, it is brought to the authors' attention that=0D > >Unsigned32 is preferred when the range of values is non-negative;=0D > >see Section 4.6.1.1.=0D > >Changes, if any, are left to the authors' discretion. (Note:=0D > >current usage is consistent for all objects; if a change is made,=0D > >please be sure to do so everywhere; but see 11(m) first.)=0D > >=0D > >/********** The following comments apply to the ROHC-MIB **********/=0D > >=0D > >(h) In the DESCRIPTION clause of rohcChannelID it says:=0D > >=0D > > The value is expected to remain constant at least from one=0D > > re-initialization of the entity's network management system=0D > > to the next re-initialization.=0D > >=0D > >I know that this same language is used in the IF-MIB, but it turns=0D > >out that indices that don't remain fixed across reboots can lead=0D > >to problems. See the thread "Referential integrity across reboots"=0D > >at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140=0D > >Suggested remedy: change the above text to:=0D > >=0D > > The value is REQUIRED to remain constant at least from one=0D > > re-initialization of the entity's network management system=0D > > to the next re-initialization. It is RECOMMENDED that the=0D > > value persist across such re-initializations.=0D > >=0D > >(i) In the DESCRIPTION clause of rohcChannelFeedbackFor:=0D > >s/feddback/feedback/=0D > >=0D > >(j) In the following object definition it is not specified what=0D > >value the object should assume if there is no feedback channel:=0D > >=0D > >rohcInstanceFBChannelID OBJECT-TYPE=0D > > SYNTAX RohcChannelIdentifier=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "Identifier of the channel used for feedback."=0D > > ::=3D { rohcInstanceEntry 4 }=0D > >=0D > >Shouldn't the DESCRIPTION clause state that the value 0 is used in=0D > >that case? It would seem to be consistent with the instructions in=0D > >the RohcChannelIdentifier DESCRIPTION clause to do this.=0D > >=0D > >(k) In the following object definition:=0D > >=0D > > rohcInstanceMRRU OBJECT-TYPE=0D > > SYNTAX Integer32 (1..2147483647)=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "Maximum reconstructed reception unit. This is the=0D > > size of the largest reconstructed unit in octets that=0D > > the decompressor is expected to reassemble from=0D > > segments (see RFC 3095, Section 5.2.5). Note that this=0D > > size includes the CRC. If MRRU is negotiated to be 0,=0D > > no segment headers are allowed on the channel."=0D > > REFERENCE=0D > > "RFC 3095, Section 5.1.1"=0D > > ::=3D { rohcInstanceEntry 11 }=0D > >=0D > >the SYNTAX value and the DESCRIPTION clause are at odds.=0D > >=0D > >FIX: change the SYNTAX value to Integer32 (0..2147483647)=0D > >=0D > >(l) In the following object definition:=0D > >=0D > >rohcInstanceContextsCurrent OBJECT-TYPE=0D > > SYNTAX Integer32=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "Number of currently active contexts created by this instance.= "=0D > > ::=3D { rohcInstanceEntry 15 }=0D > >=0D > >a more appropriate SYNTAX value would be Integer32 (0..2147483647)=0D > >since the number of contexts cannot possibly be negative.=0D > >=0D > >(m) In the following object definition:=0D > >=0D > >rohcInstanceCompressionRatio OBJECT-TYPE=0D > > SYNTAX Integer32 (0..1000)=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "This object indicates the compression ratio so far over all=0D > > packets on the channel served by this instance. The value is= =0D > > defined as 1000 * bytes(compressed) / bytes(original) rounded= =0D > > to the next integer value. The number of bytes corresponds=0D > > to all bytes of all IP packets including the IP header but=0D > > excluding all lower layer headers."=0D > > ::=3D { rohcInstanceEntry 20 }=0D > >=0D > >Is it theoretically possible for the compression ratio to exceed unity= =0D > >in certain unfavorable cases? If so, then the range needs to be=0D > >changed to allow for that, or the DESCRIPTION clause needs to state=0D > >that the value is set to 1000 if the actual compression ratio exceeds=0D > >unity. In the latter case a more appropriate SYNTAX value would be=0D > >Gauge32 (0..1000) (see =0D > >Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION=0D > >RATIO OBJECTS.=0D > >=0D > >(n) I'm not sure if I properly understood the DESCRIPTION clause of=0D > >the following object:=0D > >=0D > >rohcProfileNegotiated OBJECT-TYPE=0D > > SYNTAX TruthValue=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "When retrieved, this boolean object returns true=0D > > if the profile has been negotiated to be used at=0D > > the instance, i.e. is supported also by the=0D > > corresponding compressor/decompressor."=0D > > ::=3D { rohcProfileEntry 7 }=0D > >=0D > >My understanding is that an instance of this object corresponding to=0D > >a particular triple should=0D > >have the value true(1) if and only if at least one context with the=0D > >same values is using that profile -- in=0D > >other words, if and only if some instance of rohcContextProfile for=0D > >the same values is equal to the rohcProfile=0D > >value. If this understanding is _not_ correct, then clarification=0D > >of the DESCRIPTION clause would be in order.=0D > >=0D > >(o) Several DESCRIPTION clauses in the ROHC-MIB refer to the=0D > >non-existent object rohcContextType. They should refer instead to=0D > >rohcInstanceType. The objects in question are:=0D > >=0D > >rohcContextDecompressorDepth=0D > >rohcContextDecompressorFailures=0D > >rohcContextDecompressorRepairs=0D > >=0D > >(p) In the following object definition [n.b. the above correction=0D > >has been assumed to be applied]:=0D > >=0D > >rohcContextDecompressorDepth OBJECT-TYPE=0D > > SYNTAX Integer32 (0..2147483647)=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "This object indicates whether reverse decompression, for=0D > > example as described in RFC 3095, Section 6.1, is used=0D > > on this channel or not, and if used, to what extent.=0D > >=0D > > Its value is only valid for decompressor contexts, i.e.=0D > > if rohcInstanceType has the value decompressor(2).=0D > >=0D > > The value of the reverse decompression depth indicates=0D > > the maximum number of packets that are buffered, and thus=0D > > possibly be reverse decompressed by the decompressor.=0D > > A zero (0) value means that reverse decompression is not=0D > > used."=0D > > ::=3D { rohcContextEntry 7 }=0D > >=0D > >it is not clear whether this object should have the value 0 for=0D > >compressor contexts, or whether it should not be instantiated at=0D > >all for such contexts.=0D > >=0D > >(q) The rohcCompliance DESCRIPTION clause should mention that the=0D > >ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of=0D > >, last paragraph=0D > >before end note. Examples may be found in the dot3Compliance2=0D > >statement in , the=0D > >mauModIfCompl3 statement in ,=0D > >or the etherWisCompliance in =0D > >(although it is requested that the embedded citations be avoided).=0D > >=0D > >/*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/=0D > >=0D > >(r) The rohcUncmprCompliance DESCRIPTION clause should mention that=0D > >the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as=0D > >prerequisites. See 11(q) above for examples.=0D > >=0D > >/******** The following comments apply to the ROHC-RTP-MIB ********/=0D > >=0D > >(s) The DESCRIPTION clauses of several columnar objects in the=0D > >rohcRtpContextTable state that those objects are valid only for=0D > >certain profiles or for certain contexts. The objects in question=0D > >are:=0D > >=0D > >rohcRtpContextAlwaysPad=0D > >rohcRtpContextLargePktsAllowed=0D > >rohcRtpContextVerifyPeriod=0D > >rohcRtpContextSizesAllowed=0D > >rohcRtpContextSizesUsed=0D > >=0D > >If the intent is that those objects are to be instantiated only for=0D > >the profiles or contexts to which they apply, then that fact should=0D > >be made explicit in the DESCRIPTION clauses.=0D > >=0D > >(t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and=0D > >rohcRtpContextSizesUsed both appear to have the same three=0D > >typographical errors:=0D > >=0D > > rohcRtpContextSizesAllowed OBJECT-TYPE=0D > > SYNTAX Integer32 (1..2147483647)=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "The value of this object is only valid for decompressor=0D > > contexts, i.e. if rohcContextType of the cooresponding=0D > > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^=0D > > rohcContextEntry has the value compressor(2).=0D > > ^^^^^^^^^^^^^=0D > >=0D > > This object contains the number of different packet sizes=0D > > that may be used in the context."=0D > > REFERENCE=0D > > "RFC 3095, Section 6.3.1"=0D > > ::=3D { rohcRtpContextEntry 10 }=0D > >=0D > > rohcRtpContextSizesUsed OBJECT-TYPE=0D > > SYNTAX Integer32 (1..2147483647)=0D > > MAX-ACCESS read-only=0D > > STATUS current=0D > > DESCRIPTION=0D > > "The value of this object is only valid for decompressor=0D > > contexts, i.e. if rohcContextType of the cooresponding=0D > > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^=0D > > rohcContextEntry has the value compressor(2).=0D > > ^^^^^^^^^^^^^=0D > >=0D > > This object contains the number of different packet sizes=0D > > that are used in the context."=0D > > REFERENCE=0D > > "RFC 3095, Section 6.3.1"=0D > > ::=3D { rohcRtpContextEntry 11 }=0D > >=0D > >Suggested fixes: s/rohcContextType/rohcInstanceType/=0D > > s/cooresponding/corresponding/=0D > > s/compressor(2)/decompressor(2)/=0D > >=0D > >(u) There are some design issues with the rohcRtpPacketSizeTable:=0D > >=0D > >- the index column rohcRtpPacketSize with has values in the range=0D > >0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that=0D > >PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive=0D > >integers, i.e., the value 0 is excluded as it does not make sense.=0D > >FIX: change the range to 1..2147483647. (This also avoids=0D > >running afoul of the SMIv2 rule that index values of zero should=0D > >be avoided, except in special cases.)=0D > >=0D > >- the TruthValue column rohcRtpPacketSizeAllowed seems to be=0D > >unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that=0D > >"packet sizes not in the set of values for [PACKET_SIZES_ALLOWED]=0D > >MUST NOT be used", it seems that an agent would never need to=0D > >instantiate any of the other columns if rohcRtpPacketSizeAllowed=0D > >had the value false(2). In other words, any row for which this=0D > >objects is false should simply be absent from the table.=0D > >=0D > >(v) The rohcRtpCompliance DESCRIPTION clause should mention that=0D > >the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as=0D > >prerequisites. See 11(q) above for examples.=0D > >=0D > >This concludes the review of .=0D > >=0D > >Regards,=0D > >=0D > >Mike Heard=0D > >=0D > >=0D > >_______________________________________________=0D > >Rohc mailing list=0D > >Rohc@ietf.org=0D > >https://www1.ietf.org/mailman/listinfo/rohc=0D > >=0D > =0D > _______________________________________________=0D > Rohc mailing list=0D > Rohc@ietf.org=0D > https://www1.ietf.org/mailman/listinfo/rohc=0D > =0D --=20 Q=9C _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 8 02:43:30 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 CAA11824 for ; Tue, 8 Jul 2003 02:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBr-0007Xv-5X for rohc-archive@odin.ietf.org; Tue, 08 Jul 2003 02:43:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h686h3JB029003 for rohc-archive@odin.ietf.org; Tue, 8 Jul 2003 02:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBq-0007Xd-To for rohc-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 02:43: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 CAA11793 for ; Tue, 8 Jul 2003 02:42:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmBn-0006vr-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 02:42:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmBm-0006vo-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 02:42:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmBo-0007Wu-Fu; Tue, 08 Jul 2003 02:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmAz-0007VY-AM for rohc@optimus.ietf.org; Tue, 08 Jul 2003 02:42: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 CAA11773 for ; Tue, 8 Jul 2003 02:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmAu-0006vP-00 for rohc@ietf.org; Tue, 08 Jul 2003 02:42:04 -0400 Received: from [203.199.93.15] (helo=WS0005.indiatimes.com) by ietf-mx with esmtp (Exim 4.12) id 19ZmAt-0006vA-00 for rohc@ietf.org; Tue, 08 Jul 2003 02:42:03 -0400 Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id MAA03554 for ; Tue, 8 Jul 2003 12:10:15 +0530 From: "waradvikas" Message-Id: <200307080640.MAA03554@WS0005.indiatimes.com> To: Reply-To: "waradvikas" Date: Tue, 08 Jul 2003 11:57:39 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20037821157391957747793" MIME-Version: 1.0 Subject: [rohc] [sigcomp] regarding state handlers 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --=_MAILER_ATTACH_BOUNDARY1_20037821157391957747793 Content-Type: text/plain; charset=us-ascii undefined Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now ! --=_MAILER_ATTACH_BOUNDARY1_20037821157391957747793 Content-Type: text/html; charset=us-ascii undefined
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com
Bid for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now ! --=_MAILER_ATTACH_BOUNDARY1_20037821157391957747793-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 8 03:08: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 DAA12447 for ; Tue, 8 Jul 2003 03:08: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 19Zma3-0000qJ-LE for rohc-archive@odin.ietf.org; Tue, 08 Jul 2003 03:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h687838q003232 for rohc-archive@odin.ietf.org; Tue, 8 Jul 2003 03:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zma2-0000q3-UN for rohc-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 03:08: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 DAA12438 for ; Tue, 8 Jul 2003 03:07:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmZy-00076v-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 03:07:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZmZy-00076s-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 03:07:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zma1-0000pg-CQ; Tue, 08 Jul 2003 03:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZmZS-0000hp-Mq for rohc@optimus.ietf.org; Tue, 08 Jul 2003 03:07:26 -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 DAA12429 for ; Tue, 8 Jul 2003 03:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZmZO-00076h-00 for rohc@ietf.org; Tue, 08 Jul 2003 03:07:22 -0400 Received: from ims21.stu.nus.edu.sg ([137.132.14.228]) by ietf-mx with esmtp (Exim 4.12) id 19ZmZN-00076e-00 for rohc@ietf.org; Tue, 08 Jul 2003 03:07:22 -0400 Received: from mbxsrv23.stu.nus.edu.sg ([137.132.14.233]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 15:07:15 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Date: Tue, 8 Jul 2003 15:07:14 +0800 Message-ID: <97B6AED9BBAE4845B2559DA63E6ECDC201A25777@MBXSRV23.stu.nus.edu.sg> Thread-Topic: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: Update and some topics to be discussed) Thread-Index: AcNDMJYumyl9rdWOTVqqWBtzs8+DOQB7QvMQ From: "Cho Chia Yuan" To: , Cc: , X-OriginalArrivalTime: 08 Jul 2003 07:07:15.0108 (UTC) FILETIME=[8F8B4E40:01C3451F] 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ghyslain, I have been working on Context Replication in ROHC-TCP and I already have a working implementation of CR in ROHC-TCP. Therefore, I hope that I can be of help to the ROHC effort. There are some points that I seek to discuss and address from the ROHC-CR draft and discussions: Section 3.2.1: "For simplicity, contexts with the same Source-IP and/or Destination-IP may be considered as replicable contexts, and the most recent one should be selected as the candidate to be replicated." The recommendation on 'same Source-IP and/or Destination-IP' can be broken down into three permutations. I have tested CR based on contexts with (i)same source-IP and same destination-IP and (ii)same source-IP but different destination-IP but not on (iii)same destination-IP but different source-IP, as I have doubts that there would be significant redundancy between packets from different sources. (i) and (ii) works fine with (i) being especially efficient, but would (iii) work? Concerning the feasibility of adding an 'IR-REPLICATE' state into the compressor state set: 'I find motivations to add an additional state for CR somewhat thin, also in relation to the limited amount of logic attached to it and because ROHC-CR does not define a complete state machine. This issue in my opinion is only a matter of how to document logic to support the IR-REPLICATE, it is not about the logic itself (for which we seem to have agreement). I'd prefer instead that we make an attempt in ensuring that the text for both the compressor and decompressor logic is clear when using the IR-REPLICATE.' I agree with the logic for CR. Because there is always a possibility of the context not being present at the decompressor, the compressor would always have to remember that it has sent IR-REPLICATE because it has to switch to IR instead when it receives STATIC-NACK. I guess this memory is inherent if CR is to be used. The issue is then whether you call this a separate 'state' or not. I have a suggestion: the ROHC can encapsulate the IR-REPLICATE 'sub-state' inside the IR state instead, since the possibility of using CR itself is up to implementation. However, state-machines do make logics much clearer, and ROHC-CR can do it be defining the IR-REPLICATE 'sub-state' in relation to the IR 'sub-state' within the ROHC IR state black box. Finally, I have some current work which may be of interest to ROHC-CR. (i)Statistical studies on the efficiency gains achievable through context replication. As predicted, it improves the efficiency of short-lived TCP flows tremendously. The justification for CR to be used is that the majority of TCP flows are smaller than ~10kB, the region where gains through CR are significant. (ii)Studying TCP/IP field behaviour between different TCP flows statistically to exploit the inter-flow redundancy in CR. The inter-flow delta has a larger variance than intra-flow delta and thus for CR to work without sending most fields uncompressed, the compression specification must be fine-tuned to suit the inter-flow field behaviour. The qualitative analysis on inter-flow behaviour in TCP-BEH was tremendously helpful, but due to the large variance of inter-flow behaviour, there is a need to determine this behaviour quantitatively. (iii)Studying the max number of contexts to keep for CR This is an implementation specific parameter. The problem is that CR requires a larger number of contexts to be kept. This aims to optimize between memory requirements and context replication gains. Do let me know if the above helps :) Chia Yuan, Cho Institute of Infocommunication Research National University of Singapore _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 8 07:59: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 HAA18454 for ; Tue, 8 Jul 2003 07:59:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zr7f-0005So-Q3 for rohc-archive@odin.ietf.org; Tue, 08 Jul 2003 07:59:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Bx3Hf020998 for rohc-archive@odin.ietf.org; Tue, 8 Jul 2003 07: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 19Zr7f-0005Sb-Jh for rohc-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 07: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 HAA18428 for ; Tue, 8 Jul 2003 07:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zr7e-0000x5-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 07:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zr7d-0000x2-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 07:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zr7c-0005Rp-Td; Tue, 08 Jul 2003 07: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 19ZoiL-0007Uy-VY for rohc@optimus.ietf.org; Tue, 08 Jul 2003 05:24:46 -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 FAA15618 for ; Tue, 8 Jul 2003 05:24:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZoiI-0000Ad-00 for rohc@ietf.org; Tue, 08 Jul 2003 05:24:42 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19ZoiH-0000AQ-00 for rohc@ietf.org; Tue, 08 Jul 2003 05:24:41 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <33ATA71T>; Tue, 8 Jul 2003 10:24:07 +0100 Message-ID: From: "Surtees, Abigail" To: "'Juergen Quittek'" Cc: "Wijnen, Bert (Bert)" , "'C. M. Heard'" , ROHC mailing list Subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Date: Tue, 8 Jul 2003 10:24:04 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Juergen, Thanks for your explanation. I agree that generating a list of compressors on a particular interface may be a useful thing to be able to do. However, looking at it from a MIB point of view I think it is confusing to have a seemingly redundant index. Hence, I suggest that rohcInstanceType continues to be an index but that there is some text added to the draft explaining why it is there and that if you want to uniquely identify one rohc instance (whether compressor or decompressor) then ifIndex and rohcChannelID are sufficient to do this. What do you think? Best regards, Abbie >Initially, rohcInstanceType was no index. Probably this is the > >reason why we forgot to make it non-accessible. But after some >discussions > >with rohc people, partiularly including with Lars-Erik, we found that > >when accessing the MIB a management station would typically look either > >for compressors or for decompressors, but not for particular channels. > > > >Without the rohcInstanceType being part of the index, a >management station > >looking for a particular compressor or looking for all >compressors would need > >to browse through all compressor and decompressor contexts, >read the type > >and ignore them if they are decompressors. > > > >But with the rohcInstanceType as n index before the channel ID, you can > >first select whether you ant to browse compressors or decompressors and > >then go through the (shorter) list of specific contexts. > > > >I think this is helpful and matches requirements of rohc >management stations. > > > >Cheers, > > > > Juergen > > > >> Hi All, > >> > >> Having had a look at the MIB I have a question about it. One problem > >> mentioned below is that rohcInstanceType should have >MAX-ACCESS value of > >> not-accessible. > >> > >> The fix proposed by the MIB doctor is the following. > >> > >> >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible > >> >(c) remove rohcInstanceType from rohcInstanceGroup > >> > >> The reason it should be not-accessible is because it is used >as an index > >> into the rohcInstanceTable and the rohcContextTable. > >> > >> Why does it need to be an index into these tables? > >> > >> In my understanding (please correct me if I'm wrong) from reading the > >> terminology draft, each instance will have its own channel >ID which can > >> uniquely identify it on an interface. A single instance can >only be a > >> compressor or a decompressor and is already identified by ifIndex and > >> rohcChannelID, so using the rohcInstanceType as an index >doesn't actually > >> identify anything further. > >> If it doesn't need to be an index, then a MAX-ACCESS value >of read-only is > >> acceptable. > >> > >> Am I missing something? > >> > >> Best regards, > >> > >> Abbie > >> Abbie Surtees > >> Engineer > >> Internet Applications and Mobility > >> Roke Manor Research Ltd > >> Tel: +44 (0) 1794 833131 > >> > >> >-----Original Message----- > >> >From: C. M. Heard [mailto:heard@pobox.com] > >> >Sent: 25 June 2003 07:04 > >> >To: ROHC mailing list > >> >Cc: Wijnen, Bert (Bert) > >> >Subject: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt > >> > > >> > > >> >>>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote: > >> >Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt > >> >Bert> in the next week or two? > >> > > >> >>>>>> On Fri, 13 Jun 2003, C. M. Heard replied: > >> >CMH> I will volunteer to do this. Based on a quick look I think > >> >CMH> I should be able to turn around the review before June 26th. > >> > > >> >As noted above, I've volunteered to do a MIB Doctor review of > >> >. For the most part, I have been > >> >pleased with the quality of that document. However, there are a > >> >number of things that do need to be corrected, or at least looked > >> >at, before the document goes to the IESG. The detailed review > >> >comments below follow the checklist from Appendix A of the draft > >> >guidelines document . > >> >Those who wish to respond to these review comments should do so on > >> >the ROHC mailing list, with copies to Bert Wijnen and myself. > >> > > >> >0.) Title -- s/Robus/Robust/ > >> > > >> >1.) I-D Boilerplate -- OK > >> > > >> >2.) Abstract -- acronyms used in the abstract must be expanded on > >> >first use, except for those acronyms that everyone in the IETF can > >> >reasonably be expected to know (see Sections 4.5 and 2.9 of > >> > or its successor document). > >> >Certainly ROHC and LLA will need to be expanded; I'm not sure about > >> >ESP and RTP -- please check with the RFC Editor. Here is a partial > >> >fix: > >> > > >> > 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 (ROHC). > >> > [ ... ] > >> > > >> >The remainder is left to the authors to sort out. > >> > > >> >3.) MIB Boilerplate -- OK > >> > > >> >4.) IPR Notices -- the required notices from RFC 2026 Sections > >> >10.4(A) and 10.4(B) are present and no claims are noted; this > >> >is OK if indeed there are no relevant IPR disclosures. Note, > >> >however, that a search of the IPR statements on the IETF web site > >> >does reveal some claims that seem like they _might_ be relevant: > >> > > >> > Search Results for query = '(robust or robustness or robustly) > >> > and (header or head or headed or heading or headings or heads > >> > or headers) and (compression or compressions)' > >> > _________________________________________________________________ > >> > > >> > Match: [All....] Format: [Long.] Sort by: [Title........] > >> > Refine search: ______________________________ Search > >> > _________________________________________________________________ > >> > > >> > Documents 1 - 4 of 11 matches. More * 's indicate a better match. > >> > _________________________________________________________________ > >> > > >> > [ERICSSON-ROCCO] * > >> > ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE > >> > UNDERTAKING In the AVT Working Group in the Internet > >> > Engineering Task Force, a proposal "RObust Checksum-based > >> > header COmpression (ROCCO)" dated June 22, 1999 has been > >> > made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at > >> > Lulea University ... > >> > http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557 > >> > bytes > >> > > >> > [ERICSSON-SIGCOMP.txt] * * * * > >> > ... that might possibly have technical relations to the > >> > Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt. > >> > This draft is part of the Signaling Compression work > >> > taking place in the Robust Header Compression (ROHC) WG. > >> > See further Ericsson's general IPR statement: > >> > http://www.ietf.org/ietf/IPR/ERICSSON ... > >> > http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02, > >> > 466 bytes > >> > > >> > [NOKIA-RFC3095.txt] * > >> > ... : 1) "CID field handling in ROHC": FI 20002100, US > >> > 09/954562, PCT/FI01/00819 2) "Variable length context > >> > identifier for real time header compression": FI 20002307, > >> > US 09/978479, PCT/FI01/00902 3) "Variable length encoding of > >> > compressed data": US 09/536638, US 60/164330, ... > >> > http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02, > >> > 1373 bytes > >> > > >> > [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] * > >> > ... This is to advise the IETF that Telefonaktiebolaget LM > >> > Ericsson believes it owns patents and patent applications > >> > which may relate to RFC 3095, "RObust Header Compression > >> > (ROHC): Framework and four profiles: RTP, UDP, ESP, and > >> > uncompressed". See further Ericsson's general IPR > >> > statement: http://www.ietf.org/ietf/IPR/ERICSSON ... > >> > http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST- > >> > HEADER-COMPRESSION.txt 09/27/02, 439 bytes > >> > > >> > Return to the Seach Page > >> > _________________________________________________________________ > >> > > >> > ht://Dig 3.1.6 > >> > > >> >The document authors and the WG should examine these IPR disclosures > >> >and either determine for sure that none are required in order to > >> >implement the MIB module or else add the notice from RFC 2026 > >> >Section 10.4(D). (The reviewer will be satisfied if the authors > >> >reply that the IPR section in the document is OK as it stands. All > >> >that's being requested is an assurance that you have done your > >> >homework.) > >> > > >> >5.) References -- there are some missing normative references and > >> >some of the existing references contain minor errors or don't > >> >exactly follow the current RFC style. The style issues are listed > >> >only for completeness; RFC Editor will fix that in any case. > >> > > >> >(a) RFC 3411 needs to be added as a normative reference since > >> >SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB > >> >(c.f. Section 3.5). > >> > > >> >(b) RFC 2863 needs to be added as a normative reference since > >> >IF-MIB appears in the IMPORTS statement of all three MIB > >> >modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB. > >> > > >> >(c) [RFC3095] has an incorrect title and an author list that's not > >> >in the standard form. > >> > > >> >(d) [RFC3242] has an author list that's not in the standard form. > >> > > >> >(e) [RFCXXXX] has an author list that's not in the standard form, > >> >and it might be helpful to readers to indicate the I-D that will > >> >eventually turn into this RFC-to-be. > >> > > >> >6.) Security Considerations Section -- there are two read/write > >> >objects but only one is mentioned. A possible fix would be to > >> >revise the first paragraph to read as follows: > >> > > >> > The managed objects defined by the ROHC-MIB module, the > >> > ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not > >> > have a MAX-ACCESS value of read-write and/or read-create except > >> > rohcInstanceContextStorageTime and rohcContextStorageTime, both of > >> > which have a MAX-ACCESS value of read-write. These objects > >> > determine how long context information is stored after its > >> > termination. Unauthorized access to these objects can have one of > >> > two negative effects. If they are set to a value lower than > >> > required, e.g. to zero, then context information about >past contexts > >> > might get lost. If they are set to a very high value, then context > >> > information will not be deleted and memory consumption of the agent > >> > implementation might become very high. However, >unauthorized access > >> > to these objects cannot cause harm to existing ROHC connections nor > >> > can it allow manipulation of running instances of ROHC in a > >> > malicious way. > >> > > >> >The fourth paragraph says "[a]lthough the security risks arising > >> >from the ROHC-MIB module are not considered to be high", but the > >> >second paragraph says "[it is] important to control even GET and/or > >> >NOTIFY access to these objects and possibly to even encrypt the > >> >values of these objects when sending them over the network via > >> >SNMP." That seems contradictory. It is therefore suggest to > >> >modify the fourth paragraph so that it reads as originally written > >> >in the standard security considerations template: > >> > > >> > It is RECOMMENDED that implementers consider the security features > >> > as provided by the SNMPv3 framework (see [RFC3410], section 8), > >> > including full support for the SNMPv3 cryptographic mechanisms (for > >> > authentication and privacy). > >> > > >> >7.) IANA Considerations Section -- OK (none present and none > >> >required). > >> > > >> >8.) Copyright notices -- the abbreviated copyright notices that are > >> >supposed to appear on the front page and in the DESCRIPTION clause > >> >of each MODULE-IDENTITY invocation are missing and need to be added. > >> >See http://www.ietf.org/ID-nits.html section 1.2, > >> > section 4.3, and > >> > section 3.8. > >> > > >> >9.) MIB compilation -- the following problems are reported >by smilint: > >> > > >> >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > >> >has been processed to get the following results: > >> >smilint -m -s -l 6 -i namelength-32 ROHC-MIB > >> > > >> >ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-MIB:184: [5] {index-element-accessible} warning: index element > >> >`rohcInstanceType' of row `rohcInstanceEntry' should be > >> >not-accessible in SMIv2 MIB > >> > > >> >FIXES: > >> >(a) add Counter32 to the list of things imported from SNMPv2-SMI > >> >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible > >> >(c) remove rohcInstanceType from rohcInstanceGroup > >> > > >> > > >> >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > >> >has been processed to get the following results: > >> >smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB > >> > > >> >ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base > >> >type `Counter32' must be imported from SNMPv2-SMI > >> >ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base > >> >type `Counter32' must be imported from SNMPv2-SMI > >> > > >> >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > >> > > >> > > >> >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > >> >has been processed to get the following results: > >> >smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB > >> > > >> >ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> >ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type > >> >`Counter32' must be imported from SNMPv2-SMI > >> > > >> >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > >> > > >> >10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html > >> >that is not covered above: > >> > > >> >(a) there are several places in the MIB modules where the lines > >> >extend beyond column 72. Most (but not all) of these could be fixed > >> >by eliminating the three-space indentation. Althought the RFC > >> >Editor can probably do this, it will save time and reduce the > >> >proabability of formatting errors in the final RFC if the authors > >> >would fix it themselves. See ID-nits section 1.1. > >> > > >> >(b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to > >> >the list of imperatives (although the standard boilerplate in RFC > >> >2119 does not include it, it is used in the Security Considerations > >> >section and it is defined in RFC 2119). > >> > > >> >(c) in Section 3, "Overview", 3rd paragraph: s/means/a means/ > >> > > >> >(d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/ > >> > > >> >(e) in Section 4, "Structure of the MIB modules", 1st paragraph: > >> >s/Section 6/Section 5/ > >> > > >> >(f) in Section 4, "Structure of the MIB modules", 2nd and 4th > >> >paragraphs: most acronyms must be expanded upon first use, > >> >except for those that everyone in the IETF can reasonably be > >> >expected to know. Note that this rule applies separately for > >> >the body of the memo and the abstract; see Sections 4.7 and 2.9 > >> >of or its successor document > >> >and review comment (2) above. > >> > > >> >(g) in Section 4.1, "The ROHC-MIB module", first paragraph: the > >> >tables are mentioned in a different order than they appear in the > >> >MIB module, which has rohcChannelTable before rohcInstanceTable. > >> >Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with > >> >the order in this paragraph but are "swapped" relative to the MIB > >> >module. It might be better if the order in the text matched that > >> >of the MIB module. > >> > > >> >(h) in Section 4.1, "The ROHC-MIB module", last paragraph: > >> >unexpanded acronym CID. > >> > > >> >(i) in Section 4.1.1, "rohcInstanceTable", 4th bullet: > >> >s/storagetime/storage time/ > >> > > >> >(j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed > >> >text from: > >> > > >> > o the state of the CID ('unused', 'active', 'expired', or > >> > > >> >to: > >> > > >> > o the state of the CID ('unused', 'active', 'expired', or > >> > 'terminated'. > >> > > >> >Note: a common cause of missing text in an I-D is a line in the > >> >nroff source that starts with a single quote as the first character > >> >of the line. > >> > > >> >11.) Technical content -- the following comments pertain to the > >> >material in Sections 3, 4, and 5. Please note that I am not an > >> >ROHC subject matter expert and so I do not have the knowledge to > >> >attempt a detailed verification that the MIB objects are indeed > >> >fit for the intended purposes. I'm presuming that the WG has > >> >already done that, so I've concentrated on MIB design issues. > >> >Issues already covered under (9) above won't be repeated here. > >> > > >> >(a) in Section 3, "Overview", next to last paragraph, it is stated > >> >that "the compressor context can be reinitialized." I didn't see > >> >any read-write or read-create objects in the MIB module that would > >> >support such a capability. If indeed there is no support for such > >> >a capability then the claim should be removed. > >> > > >> >(b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3, > >> >"rohcProfileTable", and also in the corresponding definitions in > >> >the ROHC-MIB module in Section 5: it is not clear why one needs a > >> >vendor, version number, and implementation description in both of > >> >these tables. Indeed, except for the descriptors and OIDs that > >> >are assigned, the definitions of rohcInstanceVendor, > >> >rohcInstanceVersion, and rohcInstanceDescr are identical with those > >> >for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr > >> >(respectively). It seems to me that the objects rohcProfileVendor, > >> >rohcProfileVersion, and rohcProfileDescr could be eliminated without > >> >loss of capability. The designers may also wish to consider moving > >> >rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into > >> >the rohcChannelTable or perhaps even turning them into scalars. > >> > > >> >(c) in Section 4.1.3, "rohcProfileTable", there is no mention of > >> >the per-profile Boolean flag that indicates whether the profile > >> >has been negotiated to be used at the instance. > >> > > >> >(d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations > >> >need to be changed in the following ways: > >> > > >> > - WG mailing list info (and optionally, charter page URL) needs to > >> > be present in the CONTACT-INFO clause; > >> > > >> > - there needs to be a REVISION/DESCRIPTION clause pair with a date > >> > identical to that in the LAST-UPDATED clause and a description > >> > indicating that the module is the initial published version; > >> > > >> > - the DESCRIPTION clause needs to include an abbreviated copyright > >> > notice (per (8) above). > >> > > >> >See sections 3.8 and > >> >4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY > >> >invocation could be changed from: > >> > > >> >rohcMIB MODULE-IDENTITY > >> > LAST-UPDATED "200209251358Z" > >> > ORGANIZATION "IETF Robust Header Compression Working Group" > >> > CONTACT-INFO > >> > "Juergen Quittek > >> > NEC Europe Ltd. > >> > Network Laboratories > >> > Kurfuersten-Anlage 34 > >> > 69221 Heidelberg > >> > Germany > >> > Tel: +49 6221 90511-15 > >> > E-mail: quittek@ccrle.nec.de" > >> > DESCRIPTION > >> > "This MIB module defines a set of basic objects for > >> > monitoring and configuring robust header compression. > >> > The module covers information about running instances > >> > of ROHC (compressors or decompressors) at IP interfaces. > >> > > >> > Information about compressor contexts and decompressor > >> > contexts has different structure for different profiles. > >> > Therefore it is not provided by this MIB module, but by > >> > individual modules for dofferent profiles." > >> > ::= { mib-2 XXX } > >> >-- XXX to be assigned by IANA. > >> > > >> >to something along the lines of: > >> > > >> >rohcMIB MODULE-IDENTITY > >> > LAST-UPDATED "200306250000Z" -- June 25, 2003 > >> > ORGANIZATION "IETF Robust Header Compression Working Group" > >> > CONTACT-INFO > >> > "WG charter: > >> > http://www.ietf.org/html.charters/rohc-charter.html > >> > > >> > Mailing Lists: > >> > General Discussion: rohc@ietf.org > >> > To Subscribe: rohc-request@ietf.org > >> > In Body: subscribe your_email_address > >> > > >> > Editor: > >> > Juergen Quittek > >> > NEC Europe Ltd. > >> > Network Laboratories > >> > Kurfuersten-Anlage 34 > >> > 69221 Heidelberg > >> > Germany > >> > Tel: +49 6221 90511-15 > >> > E-mail: quittek@ccrle.nec.de" > >> > DESCRIPTION > >> > "This MIB module defines a set of basic objects for > >> > monitoring and configuring robust header compression. > >> > The module covers information about running instances > >> > of ROHC (compressors or decompressors) at IP interfaces. > >> > > >> > Information about compressor contexts and decompressor > >> > contexts has different structure for different profiles. > >> > Therefore it is not provided by this MIB module, but by > >> > individual modules for different profiles. > >> > > >> > Copyright (C) The Internet Society (2003). This version > >> > of this MIB module is part of RFC yyyy; see the RFC > >> > itself for full legal notices." > >> >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > >> > > >> > REVISION "200306250000Z" -- June 25, 2003 > >> > DESCRIPTION "Initial version, published as RFC yyyy." > >> >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > >> > > >> > ::= { mib-2 XXX } > >> >-- XXX to be assigned by IANA. > >> > > >> >with the dates changed as appropriate. [Note also a typo fix: > >> >s/dofferent/different/.] Similar changes apply to the other > >> >MIB modules. > >> > > >> >(e) in Section 5, all MIB modules: the ordering of the index > >> >components is not consistent throughout. Specifically, although > >> >all tables are indexed by ifIndex and rohcChannelID, the tables > >> >without rohcInstanceType as an index component all have > >> >{ ifIndex, rohcChannelID, ... } as a common prefix, while those > >> >with rohcInstanceType do not: their common prefix is > >> >{ ifIndex, rohcInstanceType, rohcChannelID, ... }. While this > >> >will certainly work, and may be legitimate if one wishes to have a > >> >different sort order in different tables, the MIB designers should > >> >be aware that it tends to make the implementation harder than it > >> >otherwise would be, because there is less indexing code that can > >> >be shared between different tables. Unless there was a specific > >> >reason for choosing the specific index order that is in the draft, > >> >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. > >> > > >> >(f) in Section 5, all MIB modules: none of the Counter32 objects > >> >has a discontinuity time indicator. Such an indicator is required > >> >if events other than a reboot may result in a discontinuity (i.e., > >> >non-monotonic counting behaviour); see the first bullet of Section > >> >4.6.1.2 of . Since > >> >each counter is associated with a specific interface, a good > >> >solution in this case is to use IF-MIB's ifCounterDiscontinuityTime > >> >for this purpose, as is done in the EtherLike-MIB (RFC 2665), > >> >the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That > >> >would mean adding the following or similar text > >> > > >> > Discontinuities in the value of this counter can > >> > occur at re-initialization of the management > >> > system, and at other times as indicated by the > >> > value of ifCounterDiscontinuityTime. > >> > > >> >to the DESCRIPTION clause of each of the Counter32 objects. > >> > > >> >(g) in Section 5, all MIB modules: it is observed that many objects > >> >are defined with SYNTAX values of of Integer32 (0..2147483647), > >> >Integer32 (1..2147483647), and Integer32 (0..1000). While this is > >> >certainly acceptable, it is brought to the authors' attention that > >> >Unsigned32 is preferred when the range of values is non-negative; > >> >see Section 4.6.1.1. > >> >Changes, if any, are left to the authors' discretion. (Note: > >> >current usage is consistent for all objects; if a change is made, > >> >please be sure to do so everywhere; but see 11(m) first.) > >> > > >> >/********** The following comments apply to the ROHC-MIB **********/ > >> > > >> >(h) In the DESCRIPTION clause of rohcChannelID it says: > >> > > >> > The value is expected to remain constant at least from one > >> > re-initialization of the entity's network management system > >> > to the next re-initialization. > >> > > >> >I know that this same language is used in the IF-MIB, but it turns > >> >out that indices that don't remain fixed across reboots can lead > >> >to problems. See the thread "Referential integrity across reboots" > >> >at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140 > >> >Suggested remedy: change the above text to: > >> > > >> > 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. > >> > > >> >(i) In the DESCRIPTION clause of rohcChannelFeedbackFor: > >> >s/feddback/feedback/ > >> > > >> >(j) In the following object definition it is not specified what > >> >value the object should assume if there is no feedback channel: > >> > > >> >rohcInstanceFBChannelID OBJECT-TYPE > >> > SYNTAX RohcChannelIdentifier > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "Identifier of the channel used for feedback." > >> > ::= { rohcInstanceEntry 4 } > >> > > >> >Shouldn't the DESCRIPTION clause state that the value 0 is used in > >> >that case? It would seem to be consistent with the instructions in > >> >the RohcChannelIdentifier DESCRIPTION clause to do this. > >> > > >> >(k) In the following object definition: > >> > > >> > rohcInstanceMRRU OBJECT-TYPE > >> > SYNTAX Integer32 (1..2147483647) > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "Maximum reconstructed reception unit. This is the > >> > size of the largest reconstructed unit in octets that > >> > the decompressor is expected to reassemble from > >> > segments (see RFC 3095, Section 5.2.5). Note that this > >> > size includes the CRC. If MRRU is negotiated to be 0, > >> > no segment headers are allowed on the channel." > >> > REFERENCE > >> > "RFC 3095, Section 5.1.1" > >> > ::= { rohcInstanceEntry 11 } > >> > > >> >the SYNTAX value and the DESCRIPTION clause are at odds. > >> > > >> >FIX: change the SYNTAX value to Integer32 (0..2147483647) > >> > > >> >(l) In the following object definition: > >> > > >> >rohcInstanceContextsCurrent OBJECT-TYPE > >> > SYNTAX Integer32 > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "Number of currently active contexts created by >this instance." > >> > ::= { rohcInstanceEntry 15 } > >> > > >> >a more appropriate SYNTAX value would be Integer32 (0..2147483647) > >> >since the number of contexts cannot possibly be negative. > >> > > >> >(m) In the following object definition: > >> > > >> >rohcInstanceCompressionRatio OBJECT-TYPE > >> > SYNTAX Integer32 (0..1000) > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "This object indicates the compression ratio so far over all > >> > packets on the channel served by this instance. >The value is > >> > defined as 1000 * bytes(compressed) / >bytes(original) rounded > >> > to the next integer value. The number of bytes corresponds > >> > to all bytes of all IP packets including the IP header but > >> > excluding all lower layer headers." > >> > ::= { rohcInstanceEntry 20 } > >> > > >> >Is it theoretically possible for the compression ratio to >exceed unity > >> >in certain unfavorable cases? If so, then the range needs to be > >> >changed to allow for that, or the DESCRIPTION clause needs to state > >> >that the value is set to 1000 if the actual compression >ratio exceeds > >> >unity. In the latter case a more appropriate SYNTAX value would be > >> >Gauge32 (0..1000) (see > >> >Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION > >> >RATIO OBJECTS. > >> > > >> >(n) I'm not sure if I properly understood the DESCRIPTION clause of > >> >the following object: > >> > > >> >rohcProfileNegotiated OBJECT-TYPE > >> > SYNTAX TruthValue > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "When retrieved, this boolean object returns true > >> > if the profile has been negotiated to be used at > >> > the instance, i.e. is supported also by the > >> > corresponding compressor/decompressor." > >> > ::= { rohcProfileEntry 7 } > >> > > >> >My understanding is that an instance of this object corresponding to > >> >a particular triple should > >> >have the value true(1) if and only if at least one context with the > >> >same values is using that profile -- in > >> >other words, if and only if some instance of rohcContextProfile for > >> >the same values is equal to the rohcProfile > >> >value. If this understanding is _not_ correct, then clarification > >> >of the DESCRIPTION clause would be in order. > >> > > >> >(o) Several DESCRIPTION clauses in the ROHC-MIB refer to the > >> >non-existent object rohcContextType. They should refer instead to > >> >rohcInstanceType. The objects in question are: > >> > > >> >rohcContextDecompressorDepth > >> >rohcContextDecompressorFailures > >> >rohcContextDecompressorRepairs > >> > > >> >(p) In the following object definition [n.b. the above correction > >> >has been assumed to be applied]: > >> > > >> >rohcContextDecompressorDepth OBJECT-TYPE > >> > SYNTAX Integer32 (0..2147483647) > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "This object indicates whether reverse decompression, for > >> > example as described in RFC 3095, Section 6.1, is used > >> > on this channel or not, and if used, to what extent. > >> > > >> > Its value is only valid for decompressor contexts, i.e. > >> > if rohcInstanceType has the value decompressor(2). > >> > > >> > The value of the reverse decompression depth indicates > >> > the maximum number of packets that are buffered, and thus > >> > possibly be reverse decompressed by the decompressor. > >> > A zero (0) value means that reverse decompression is not > >> > used." > >> > ::= { rohcContextEntry 7 } > >> > > >> >it is not clear whether this object should have the value 0 for > >> >compressor contexts, or whether it should not be instantiated at > >> >all for such contexts. > >> > > >> >(q) The rohcCompliance DESCRIPTION clause should mention that the > >> >ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of > >> >, last paragraph > >> >before end note. Examples may be found in the dot3Compliance2 > >> >statement in , the > >> >mauModIfCompl3 statement in , > >> >or the etherWisCompliance in > >> >(although it is requested that the embedded citations be avoided). > >> > > >> >/*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/ > >> > > >> >(r) The rohcUncmprCompliance DESCRIPTION clause should mention that > >> >the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as > >> >prerequisites. See 11(q) above for examples. > >> > > >> >/******** The following comments apply to the ROHC-RTP-MIB ********/ > >> > > >> >(s) The DESCRIPTION clauses of several columnar objects in the > >> >rohcRtpContextTable state that those objects are valid only for > >> >certain profiles or for certain contexts. The objects in question > >> >are: > >> > > >> >rohcRtpContextAlwaysPad > >> >rohcRtpContextLargePktsAllowed > >> >rohcRtpContextVerifyPeriod > >> >rohcRtpContextSizesAllowed > >> >rohcRtpContextSizesUsed > >> > > >> >If the intent is that those objects are to be instantiated only for > >> >the profiles or contexts to which they apply, then that fact should > >> >be made explicit in the DESCRIPTION clauses. > >> > > >> >(t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and > >> >rohcRtpContextSizesUsed both appear to have the same three > >> >typographical errors: > >> > > >> > rohcRtpContextSizesAllowed OBJECT-TYPE > >> > SYNTAX Integer32 (1..2147483647) > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "The value of this object is only valid for decompressor > >> > contexts, i.e. if rohcContextType of the cooresponding > >> > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > >> > rohcContextEntry has the value compressor(2). > >> > ^^^^^^^^^^^^^ > >> > > >> > This object contains the number of different packet sizes > >> > that may be used in the context." > >> > REFERENCE > >> > "RFC 3095, Section 6.3.1" > >> > ::= { rohcRtpContextEntry 10 } > >> > > >> > rohcRtpContextSizesUsed OBJECT-TYPE > >> > SYNTAX Integer32 (1..2147483647) > >> > MAX-ACCESS read-only > >> > STATUS current > >> > DESCRIPTION > >> > "The value of this object is only valid for decompressor > >> > contexts, i.e. if rohcContextType of the cooresponding > >> > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > >> > rohcContextEntry has the value compressor(2). > >> > ^^^^^^^^^^^^^ > >> > > >> > This object contains the number of different >packet sizes > >> > that are used in the context." > >> > REFERENCE > >> > "RFC 3095, Section 6.3.1" > >> > ::= { rohcRtpContextEntry 11 } > >> > > >> >Suggested fixes: s/rohcContextType/rohcInstanceType/ > >> > s/cooresponding/corresponding/ > >> > s/compressor(2)/decompressor(2)/ > >> > > >> >(u) There are some design issues with the rohcRtpPacketSizeTable: > >> > > >> >- the index column rohcRtpPacketSize with has values in the range > >> >0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that > >> >PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive > >> >integers, i.e., the value 0 is excluded as it does not make sense. > >> >FIX: change the range to 1..2147483647. (This also avoids > >> >running afoul of the SMIv2 rule that index values of zero should > >> >be avoided, except in special cases.) > >> > > >> >- the TruthValue column rohcRtpPacketSizeAllowed seems to be > >> >unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that > >> >"packet sizes not in the set of values for [PACKET_SIZES_ALLOWED] > >> >MUST NOT be used", it seems that an agent would never need to > >> >instantiate any of the other columns if rohcRtpPacketSizeAllowed > >> >had the value false(2). In other words, any row for which this > >> >objects is false should simply be absent from the table. > >> > > >> >(v) The rohcRtpCompliance DESCRIPTION clause should mention that > >> >the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as > >> >prerequisites. See 11(q) above for examples. > >> > > >> >This concludes the review of . > >> > > >> >Regards, > >> > > >> >Mike Heard > >> > > >> > > >> >_______________________________________________ > >> >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 > >> > >-- >Qoe > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 8 11:31: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 LAA26830 for ; Tue, 8 Jul 2003 11:31: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 19ZuQq-0008TP-Bt for rohc-archive@odin.ietf.org; Tue, 08 Jul 2003 11:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68FV4ao032571 for rohc-archive@odin.ietf.org; Tue, 8 Jul 2003 11:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuQq-0008TG-8J for rohc-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 11:31: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 LAA26803 for ; Tue, 8 Jul 2003 11:31:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZuQp-0002et-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 11:31:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ZuQo-0002ep-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 11:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuQn-0008Sx-BW; Tue, 08 Jul 2003 11:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZuQN-0008NP-W6 for rohc@optimus.ietf.org; Tue, 08 Jul 2003 11:30:36 -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 LAA26754 for ; Tue, 8 Jul 2003 11:30:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZuQN-0002eR-00 for rohc@ietf.org; Tue, 08 Jul 2003 11:30:35 -0400 Received: from dijana.vest.hr ([161.53.165.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ZuQL-0002eC-00 for rohc@ietf.org; Tue, 08 Jul 2003 11:30:33 -0400 Received: from fesb.hr (boole.jadran.vest.hr [193.198.33.181]) by dijana.vest.hr (8.12.9/8.12.5) with ESMTP id h68FUPi8001944 for ; Tue, 8 Jul 2003 17:30:25 +0200 (MEST) Message-ID: <3F0AE414.70909@fesb.hr> Date: Tue, 08 Jul 2003 17:32:36 +0200 From: julije ozegovic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc Content-Type: multipart/mixed; boundary="------------080400070608070702010504" Subject: [rohc] ROHC-FN RTP Prolog code 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------080400070608070702010504 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Dear colleagues, enclosed please find a zipped Prolog file version 3.1 FN31-TCP-RTP.PL which includes RTP profile in ROHC-FN. RTP profile presented is adapted to the possibilities of current Prolog test program by ROKE MANOR: - UDP length is not inferred - NBO is not implemented - CRC is not implemented, zero bits are inserted - scale uses explicit scale factor (160) - list is shortened for 8 CSRCs, to avoid 64 bit order field However, it can be of benefit to review the capabilities of ROHC-FN. Best regards, Julije Ozegovic --------------080400070608070702010504 Content-Type: application/x-zip-compressed; name="FN31-TCP-RTP.ZIP" Content-Disposition: inline; filename="FN31-TCP-RTP.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAgAIAPtO4i63SOdQv0cAABdLAQAPAAAARk4zMS1UQ1AtUlRQLlBMxFprj9tGlv0e IP+B00FgNazW8P3IArswvE7sjeMEtpP5EARGkSx2c60WNSTldu+v33NvVZElUq9kBona3RKL xXvuq869VfLXN3/e68svvnYc5+2PL5/ffPvGqTfOT22zbm4x/OcqQXq8evPLj9+/evOd8/75 T877F+/ev/tG3+m9lbNarZw+WUHbb5yiud+2sutk54hN6WzbetN3zm4zjJc8bl3eSVHKttPy PhmBn0jiTF4pzwMsLenKifuviRzIEMVH2XdTW9++n9jaatXaf5etRuCn9q+x9U/PpUMJDbOa 21bcO3UHVT/JdbMlx/WY+f0L54dnb35867x98e7Fs7fPX/41yX+/Xct7uelFXzcbZ9P0iEfV tM4vCCWNBCZBEM5X/ZMOUx6cbdN1db6WTt+owDnNrneEs647fKwcsV7rYJCse9ErmcK5rT/J jY6lRKjLenPr3Mv+rilXzv/s8HT/uJXOVb6r1+XqiuTfSltyfycPSNYS6SYW8d9f/UR+r+q1 XDlvZbdbY5ZopdOJT/A+gkMT6bZzBb23u37Vf+6vWMW16KUR18pKttBSri51lm856x+SXXUH TKfbbbdNyyqTZrnI63XdP97kgtK2rLuire/rjehx37hlyfktnG7dPGiFcji567HMHp16XxXt mZe7qroXG/j/tmnr/u5+5fxQb+r73b0zWyZaZlf/n2S9iP1qFd7AyR/JtIXonBqQd81uXTq5 /Nu18YS/cl5TRIYY6ie1obR2Sfs7CMil3Dg7wkUwjRawa7O7z2ULzbUihN9syRoAv3v2/Pul 876+l10v7reO7IvVAB4MzjV+vYJTt7K9cl69NSSwdB7gAPaK2NLttkZonSvP8672PW6cW/ed QQhXzns8CK1bpAsyohKFHK3p67KGPbutmR+RRk8Q6HpTrHclLfHRPrasQhQ78gD82rNWkwiS u3T+aoVMCl+afJ6VfO/nAIgQYUM3XLz7x6sbzVDRyl157sp5lnfNetfL9SNkO3UphfNwh5U5 LAexeVR5Bkn4R44XmgMamuZ8Uop0NEsLv0FVWG/Vkqt5EUIqZZNxunRAj72sdmvgtrKQIIjy b2OWHTCkb2uqGTBetPRmkxHkidtN0/V1QZfaAOdBPmmlhjQpSFkL740FBAMr52XzAJpul3AS iGZNYYcQcMcDMk6qJH5o2vbRETm4YyAe5RNM3SgwSrr1I2FgBct/7ohGyC8T0utWzvNmA04k y8Ta+e/n33XG3V23u4dRd0Lly/RJZrStaLuR0jqBB5oWVZgTYzCs2QwhtCsmxlfOzxtM7XdY CYj8UtE0Aj1Bw1LgC9Hfwe8o0rxObevXoCVOcNDPlWhvdxQwpSRSFSu1quqixhjiXG+wqmEy MMsrR7YtQP/jZqGjTlxAxlA2msRtoHZVIySQLjd3At4sTb4Z8oPvjKs5tiAEa3kvChQlPHT1 9KlievDHNUjiri7unAISb5FUqrq0OjfIj6Xcyg07AkBqsoLTYuvNliof/KoqCfhZ0MJk2mey sI3VJVRsNg3nBgf3QarZZGRjuXTJfP/KKcTmCaVAvfnItRVie1CSojUBhW7Yw0jboevg5fkA 2tqt4a5md3tn5DaYJ9Y7okLRgvJagVRWYZWfTVZ0zJ1U0j/CS0pRiXRqsUD7fQdpuVXddr3F z+9qyne1Ekg5lT5KyiTdlyp1yW1kKi9hlPu+x4rueOm3zs3gbULH4t6tBa1qfqCTGKOnRzkq ULMVQ7N325JmLBCywde7jtc25xmHAvWhhwX9PLzkPNldO1Xb3Os24jOyimFXWuALMQfn4tE/ NFrBcYHcOPXi5fL58tvlz9cM1C1ee8vX/jVzn+3e4SFeEYC+qjeqB2JnXinRQ0o34EvkHs+0 u2otUnXrzsuljsqkjXeemxsof5/RudRyDQd9O9Qp5cfSTBgU5Wk/k/LQUhnbi496bTFBsQt5 CRLTzqkGNUOTsBZKCUQdpV7no+8MIedyusoq57HZcbepGGMPQYt9qXT4LCjHltToPNRAAbt/ 5Hb2Odv6qUYiE9OI1T4/NRswmTaQlzGe6wwTX9lpfqWoqX9ERuvQmXZ2LXK57k4mDvpfYgyd ivzga0/1hhuTlWrUV00XU7jp7k6UHhVgW4J2sMo2Da8VZnQtlOcSCocU5QSgejb1aWMP9awi nrrfwao7dGXc1E5KiHI31ka3lUVd1WMxM3upshVVr/JpYIFPzfoTUopah13dN1i/aNWM+lcs vEE3SN6gWnSFXkqWdcHMjHxBi7wT1HCIsrS4/NDyJMKkqOyrvXJ+rJD5OxTfpSp/nA06BSrN TEYsmp5+KEed87+0zVnXH6XqqLhB0Sqj81WrV1NbbXdq13vdpkJktgpvqF3nRvUWiWoYYLeh dbwhhlg7Rd0Wu3taI4XkVkWVBdWTb40HuGUO3BsUBr2UV84voq3JwxTB/bqmW129R2M37LZ0 GfgkYY8SjFKYsyAHXBsF9NYDe7ZPoTHwxy3JR/8jO6unfQOa+cDSnI0gfgZffeM836EqcVeh fUaZIJyrzTD7arakelNmAV6oukHTD8xTQyRQ52ehlqwisaWDkFL4QAAm2l0DiqO9xFgi9g5N FL1ajSb77V4KpmpBe92xQxu6l6E8lY1CgOYPoi1vzB6VtM4lRiURGZXtbuh+SQf7nMTa8OCZ dUOVuTmmKfXI1NUpuzWvU/6I7lErVBvbVZ6qvuVOcP9Ub5i77jn7iY73m3ksJDR1D4JFoZQq b0x2CLhFQWVqatZr1ZF0jxDx+ZuRk99K1a6PgV+wytf6tIhze3pzSesdQf27UyONbqmtWKTX 15PTpoOTZsdRB1/jTuad2kUzQzH2PC8LYgpKto18GCovXNU+/heXHE2JWjsmRpTUR504w05d BYA9yVyjxFKDh3ZvT24tO9ODGqENNZu8yomdyO9IKu5FWk6v5aHNa9nIjp4rhsWoMIct1z6k qR1qKc22RGMb+d7qQGDNKH7Ap602nSZUa6GKGAo5eI96svzRUKLu2kyZfbZGWdpwOtKWh3iD Q6OYA3Qt9cGMgVatCjJ5VGbAMDuroZnm+x0M3dzqExRVQQuhfDla3l1btVKnh7rBTTBlujk1 4V4OlXTd1zBc26OSQjvFQTsmCHdX9Lths6s6cN19U3UjgtAYtB8f6v5W1Kpy0F5Xqj4EeUeT TFeAQqKlqvxdvHn2w4vlL89e//zi+go9F5fthjzArZ+yh62AAiM6PHJPqaVswOWgqiqK3JSR AmqBQgJtRW7vzD6JN0PqIIOBKiQaDOaWjdP9UdJO5MsvvrlB0V1kkbv8XD0unz4lb6ux0FVj fx+HPI/HPi8BP44GkRr8Sg91sv+wZZL7gIS7XfQNooEs+sCHoB/08dXy13/uGui3qMS6k9hk 0lFJKx4XCA5d3ovPH7Cv7O8W7vVv16zrn39U/Z3cyJZOSeg8qkMXJf9sLb78grA/eM7NzX/u MevTp19+YVEoJ8oiXXru9A72PxLPlR/oEBMzblLlTZbrs1yVqeGSho4+3lQVInts1qBZOL1l VZNzT456BWf1+kNiw4kb7XsR31N+DJfu9V4lsyfGPPFAubMnJTxpoWY9fareSeZi31X2lfV4 OlE08K6dp0+tAc+anB1TyIv3rQh86ynP5ceaFmUFlPzhTh2La5Wdr7J0JusrbyoOQ7ZI77BI dXK0UCtfrJeber2c5en8ZeYvVFACHw8BMcsOaHFW2FQHl7SwXe6ptXAvtgtaKawkjJ4Kplqg Jnj4cZe/TrT0YtJyORlNjw3OzEnZp7/NcK185zOl2YRRxFxp62FqXGmze+L5wPZKcDikE/8f jMkfHrLxp0v2gMvcmZhLR7LMQorm8Z8n6fHwH15/VtCPTPiXQu3/i6HeI4Q9Yttjm5TZZ93l C48W4YSKYluIIr5OriuUb/oCKUdb9UH1Mcj4BIw08cBUu4GAXPiKMNU6ifSV0uCrYM5O/qiG 2pZ9cBe/ejpQ9GPezWf7Wv/8dj0T4i2euK6LdgivSL0/mc/yF0+e/FVtCn139le2KF/vfY8r nHtuYXu0cwVvZ/e/IhwOX9U5Nh1UfeRdwtKRq1uzWTV77EVfbIdI8F6Ab33ghUj3VNoNuwQ+ dVT7FPtrya43x5Zo4PXR6fA/WCyExcvrJW0E1pIOnBXeiLJ4+fp6ScjohvQjHcaWz1/rhBgl IfXcvcQ7kGwHftRMNXda0dQd7+B8b5bg859j8ryZ3FHeeG9/nndA3lSGu/esO9HSm838o/Js nU/pd8zb9tXh+6fiMY2KZz01j5ctdW7v/Jl9q/dlTO8f02+Ovv/8/vv4zCF50xx1l4dRLsu/ uT2HIzGNOd//bbbmwNRhhD2qGxSxLMpQ0XacR0XgClx4bqXfy9SNEnxIZCiwj/Zc88Jt34tL N8i8igd8iIjyEH99N8XtsvIKvyyHBzw3wM9QEUZlfFKGJaR4H5SRqZcUXhIXXu7ze+bmUCak 2pIXvkx9X8bSE0DPI0gnZWIZeFbZ+Zq+OQRDMe+b/6dikdSvBrhIXF8ScFK5cVJWA6BRgEAJ XAOKQQHX830/SMPcLWwvPDE7cefl+/c/8WmKhewPyEGB92I02Q3PmFxO/Z9WSXbE/26R+N7M /5Ps+vf7/iCAl7t4lwNAnMrfAZCypVnAhoRJGEWh7/oVTE6jED/4HHg+KVC6IkzjKgmSMBC+ m/DLl4kfV3EeR5AaxBWuozinuVGUBHGUwK+hFydxFEv1XFjEGZTMkwA4aYDsCLIgDnJzJ4mS 1HcDaBmE+E38MvAwy41pVhrEfsaaeEAj+a6S6gvoLKZ3gB3EaewlPuui9IZefokxmpXFmV8A OYuCsAJSip8oyAjzyLh/ZDycjWdBhE/RkfnJkflH9QkCupMk7L0QcUjIDoz7mOGeuOeduMda xEHiBmEQWFfJ3lVqEIYr37qCGxkhhVfHkTKJhlF4Ow4mVyXFaBjLMVby8zwP1xXijTuJP7nm Z6IwDKI4lORfPOIpfTBCfgvCLGQvItJhHJMXOS+QnfCARCYig+ENXHE+IncpWzhPkYFJHEc0 n35PrejKWtHRyQUX5LFacFLyis4omZP4+IpmAM+1AE5zlwGIhU8AxJqREOIcgGcBBBcBFPAU AZQCKZrKcwC+BeBfAJBjmQsCCDIXmZ/45wACC8C7CCDJOQZhiICDqc4BhBaAexFAVnoDQBQG 5wAiq0BVFwFUacQAVYm08BMGGEriD7TrOVQXg7EiAzYc7UrkabuK0iPYPJchwVZRUORZmJyx KxztQs2/DKDKRoDgXOjD2AI4Xe80QOGJcgAIknPJi1I4ApQXASSxZwBEWZxbfmFqARQXASC1 BgDU7XMAmQWQXwJQ+sUQA+HHZ2MgLABxEUAaJwYgK4rwHEBuAWQXAeTpEOQsy84GubAA0t8B 4GmA8iSAq4S7FVrfWPqnSbwofQ0gLQuK/fX97Xxlh1bHawDJIj8UntlpDDsP14sAmsqyqIqk 8mSCiiFRBtFrezFIvcjjQx1vmIgI5qS080BL5Z3peIOiiJKBAaLKz6eKpAFRd+LJsopkmcxa 77CIopOKXNZ6w+tVNWRpECbFGY/4xiMpd8aYVJaVBvIsBSrjCXRRPnenBapJEqNzDWPuml3V /VI3gR4GyRDxpyRQnQf3zxH3kxLdEvpr7slSH80BOuoI/VCYZL480YUEIYzLR+NEedK41A+1 cdh40r5CuElWHTBO6DCX3hHgiICLETg97dV9YPYqdqf+KeCAXh46Opf6dPwk6Fv9OFS+STz4 OmMvYSSO6R7ekTe4PuWxsITi5ag4fH1S8VArXkmjeInt0EzxDMWEFI8EGmMojuAPmx+jFhIE YU94I0RXaMZPq5pAVWmpmpxWNSpZ1QrbNq2q52bpCVXRaCPfIlI1lOibU+qqE8DEkdqlqa75 WAp4UK+6PAUSV6nnDQsLO69ypl4e5axekoZ6W+Oi0U9C8hi172rzIDkRAiSB2ughQWLUlbg4 6dGYI2dxgTitcqo96mVG5SjWe/49lYXyaILNC3EBmtaQ97oUft5zJWMeq90FZpQwJqRP2AHT 7rbgX49+aZ+HTQx9BrPgPTvFAWcp388KGBBlUiYuKpwrU2iaob4bys/1ydMhph2NSwam3e81 DxSkyCpIqSiHHh3FrDxwBJaS2zVB+NM6AN8dLEhDIbqsDiBBRRmOioADTisSmHqQ6iOYJA9z O/ZGAVOQLusByIIJMFVBVQ3VS1dE6gF4LBAZAx8A8IxlkeXiQ6eMc8vAyaNl7iHLUlPpjgFL AMcjcJ7+DmA+dAK7HgAujUurKMJmPooGDj2yDAYvJJYXvDPKlIbgBy9kojqujDgUXwIOIwCn I7Cofgcwe6HM/DkwKokBjtzQi+jExT120HbKJ5kVoDOqVdJUksEnaLoPqJaYSnIMWABYXJ4Z e8DskyL0glPA8EeG37MZkVtKnKYe1E1TqEbr8+KAEvlg/UCE7+V6I/spDcZMg3/RNwHHnAJF pKWIOKOIJ3N0uHjUOKUq43jqFFKAnOLFeXhsmaDjLaoRGGXlcmBOiaSsTgKjG4Gb8Df3Uv5b 0V/f5b8e//X5b8IzI/4cnPBT6Vp+OpTBlrp+odUtRj8Fs1V9gZ8Y2LOAk8uAg2AE9tI/AJxI APsj8LBRugSYA+RX2bkACUpi/sYC+46KQiOo4PPxv8sNkP403EUqh15Y4jeIKjBhEAjrLh9C hSEd+uIeSCPKUDSPzifHRGkUUk0JSxo9FoUEzgisKPinnYHpyhmxcUaVFzMCmzijcA9trwb4 0II/VMxs+EzBJ8kIn8yoC/BSw0e8BI7CUw5Gl7NVolMhkUMOFkkyh5e+gT8GjLZ57CgusNsG ZrtRfssZMGqnAY69Sfd6mLmT33eikpBarIpLWzbFX6a9LrCeDzG3yYSBwc81sAE60OGwirj0 lCKANOvU7PWrMtnrtqYKHGNupGM+HuYW5aF96DFg3jUVsR+eAqZkZM4uma1LP+C/yRGFohwK jYe/RT47W5ooVEwV8v10tjGeKJRzKSm5iJRcPqQqH1w4iLU8i6M8i5E8i228kxwDMxLLr/K0 GUFguMaYUeVVdM6vRxd5EgF+PIAusuoMfGy4Zti/02HIHD7a86IX6UOakL6EDfe/4uUDnIKO uuisxIdLfBnwURltoDEvod2+/ro35+00fXlXWF8O04GZq47T6Fxg/JL4VGdICZRZnk9Pm54M dDOanrknTJf6qCdT3y8eZTuoISw1Dp3e2WpIrUY5qpEnMzUSf2C9+CjDE3RuQR86vLGhNasl wzFYKrPZMRiiGGloGR+jE4YuLOgzqzfVdJJUg9VJOqcTSi2GjkU8/AcRYvm3w/FE22t2dxW7 gwJoj6sY3gNjR0kyHD+Yl/TyKMMv6JtBBUb8KKOeI6zCqoxkGiAvC1YHeUkc78YubSIyTKb/ uaK+ITBlZ9BC/T8V+n4C6epK/qLCjz0v9mU61eL/2/v257Z1HtHfd2b/B52c6dRuldaS3+15 TJsmJ5k6jjdJ07S9XY9sy62njp1rO+nJN/3jLwA+RVES5XTb3XNX36OxRAIgSAIgCBJ1EBad KRg3nIoOsHEMS8/mdBy1Ipg/uPHdimsmFWAAgehGE4j+E6SpYLuCcQs1XdRkNksUAxWtWoqK 9rgZdFs49JlTA1bobVCI8H/BtNOewmK0GzdaBMPKi1xq9OApN3JkHBJeF+EFWgcHP4O16eEu CZhqBLQdCWgxAqaKAH1ExbWpQUCYQwBfOTICWo4EtImAUVcSANMtAJOmDgY2CLvA5IBtKSUJ CDQCmo4EdIgAmNGSgE7QDaJgBHN1EsSByQHbykYSEGoENBwJ6DICJpIA0EwUkRY2QlBrockB m1krCahrBNQdCYiIgElbEYC7Q1E4CkHJgDltcqCVR0BDIyAl5jIIGBEBcSAJwJFOOxwNVC91 kwM2k00S0NQICBwJGDMCRooAjJKKQIOP65N6XDc5YPPSSQJaGgEm/iwCJkTAVMmBBq5Hw0Yd NACGIJgc6OYR0FYE8D3FYgJiRoCSA40OqB4wh2C5O2nEjSQHgrrmnie5GGpykakcFN7tzrTO Vs/TEMiZdLrtbjAdd6Bz43o87YRRtwkdHGKftTg5E5gQoyZtX6IzEqTAiC1I7E9K0v6cx9If kgFEImdAp5gBTWRAizFg8o9gAFmxnAFtRwa0iQG4p/UPYACF6HAGtBwZ0CEGtIN/BAPII8AZ 0HRkQJcxYPSPYABZ/5wBDUcGRMSATvMfwQBannAG1B0ZMGIMmP4jGEC2AGdA6MiAMTGg2/1H MIBMEc6AwJEBE2JA9I+wA5g5zhlQc2RAzBjwP8gOSNqFdc0uZE6AcYhe5gltisKqux4EjVY3 ZaaOcOEXIs/YIqJbi9udetAOuqO4HnXDoFUDEylivhxYLzuskwlxBxB3NcRRDuIGQ9xCxB1C PKorxPleB9s6WRIQaQR0HQnoMgImigC+QBfrZYd1MhEwBgJGGgGpEaUR0NEIiIgAPI7ECRAL 9C3Wy5ITY42QlMsigxMjImQSSEK2WC9LAiYaASmXRQYBY0bASBFQfr0sCYg1AlIuiwwCJkRA 3JQEbLFelgRMHcdCQ5uGMRIAi1ZFQPn1siCAcZ0TkHJZZHBgygiYSgK2WC8LQdQKHMdATREQ 1oiAWAkisV4uWCc3NXnY+BkOYsu2HxLQAAImGgGpoagRwDoM+AYENImAZlcSYLrvhHTIQowt jzXEJl5LywlxixC36goxFz+mNMDJmddyJGCqCGilVFEGAW1GwEQSIGa/ORlxbhSwnm80FPe9 zvoOEdBuSwLE5DPnQk7LG4HW8kkOYr3lXULcCSTitK+oGTRDDJxiwfV5BIQaAWNHAiJGwEgS 0OzASIyao+a4Ce+a0xbu0oWtOoa+FhFQ1wgYORIwIgK6TUlAq4NWWmvUGrcmrbg1bdfadBa0 3WgXEtDQCEiZIxkEjBkBat63O+1uO2qP2uP2pB3jLlYn6IQdQNApJKCpEZAyRzIImBABkZr3 nU6n24k6o864M+nEnWm3BhZL2K13G0ytGXKwpclBFsc7HSM545jFarbiIGiPxykHaqPWaU+n OGGEPhjFk1YNsExbo1F3VIPhF+IWfPl9FCKgAQSMFQGTlAdZI6DGCKgjARERMK4rAtztQkIM bY0nWstT5ryGuKMhHjHEE4XYsAtL7KNIQmKNkJREThNCXTBGQiZNRYhpFwrB7GAfyrEw1QhJ zY30WCCOTIiQVlsSomsCNNMc7EMxFpgy4ASk5GPGWIiJgHagCHC3CyXiQEOckosZiKcM8Ugi FqrIwR4Ufc+2sDjilDlmH4RBjRB3mgqxpvtK2oWSA3XHvtc4ACYcETKVhAhd6GAPSsQNDXFK HmYgDglxVwkgqyGatgc7mhxs/cxNcst+EhEyDtmIQEIanUmKH2lC2kBIWCNCOl1FiJtYsu4v t2ilELMwaSQknASpoakR0tAICYiQbl0SUrBcte4vIwENMPWngoA4aqXWShoBNY2AkBEwkQSU kIOsCyZTtjamlo/reYj1LqgT4qitEBtyMEMsWfeXqQta7EwbEdIdTVPWUkYXNIiQUSAJKViu WveXGSfanYkgACqnrIMMTjQZASNFgCGWMqSEdZ+ZxgKYXiNBSBBM8qanPhZaRMi4KQnJWK5a 95epC2DsylkwDUeus6DNECu5kLu9m7G/TAS0WyyokcZAs5GyDjII6BABEyUP9DUCXotRICcD PfCmrRyJnel0In04sNos9OF0amAdT6MRRlxGXVjHG47EEgYjcyAAAbFGQJ4/jw+FFhIwZgSM FQFlHYmAeKohLvTdcMQTQhy1avd1JELL2QTkBOT57/SWx0QATB/TkejqOETEgYa40GfD+xzx TtG6l4i5KnB1GI4xPFchrqUMQtN1ylo8qjHEkUKc4atwdhwCuLrGAZOOjL5nh1ViEOKOnstM x2GDnxkWBOT57bS+H4WMgLhmei6dHYZQval1QUoFZLS8TogxrlQgNixUV4chEtByHAM6AQ0i YKoETq7u0QTgT7ljE+/X/BytMKHGz7hh8zyR2AGTOV3Fm3jFkodR5kDKq0ZJrv6+ns/GM0wB oBLGRBtvdbPYzK7ixDWbO+KezSc7HqUC0nIQrSgrJN5Fr4rp13GG1Sc7RNwknkZQciiSFFRS 1wXzu2H9Id24XFwe9drN5Ho4E8iMmuxlRQ9f1T8juooKStU/XUd382U0qdSSL/ESvSFPlsm+ 0T17mFYI07WI5D56listx4nK1oB33I9n11EqY8Mzuh5weT2ku/Arp0f+3pF/euDvHfhHgX8U +vv9vSrdnctvql7FV9FsgZfnYhA1XUd8elR8abZ4OBSVqkSB2TsoDYZSOVDlo6B05cVyiGlU XK/9Fg8wpCwmg2fAXrzk+748g47aBgzjGfTsNpUFz9g15U+UDJBJmrybxWx6V/nz0P9zz98d +I8P/N03/mMaRvgJc4jsqfyeWs4alRKQbnL0YPppGbyqT7wXG8xUiDkvFpQw6tDf864wa4SR Q8ynPBU3PFcn3ouLAJfTVEI0ADlfL33vDabKYMRNFGkiS5pIs5GsTQnOcNoNrJX5fKaTBjIL 6EIlm8XsHngp8YSyMH2mv2Y8s56UojjWKPkGics7IzUeglSJvswsrU9V1iCCL3IXYZexLsLM dQPMXcfm+LNd7/jFpfe7hzZK6lJU9VQ+rZY3i0nlEMTCH95hADUO/Xm8+LT5DCBBFogfe4EP AKswr3+vwfz8vfY8Z6xxoHsEdA+B7kk4MNIl0EMO9JSAhr/XqjmkFsg1f4bggEzM3+evKx8+ +h8+VvMAWptJ5GXXia4xC2Vl6B/6h0HVlz+hXuCCKwSyFbIQxaQTttA/1LFBRYd6UAtKDvJK Vjgpb0D3YWdRYpQnVmtAygTKqLeilFWbrzFl4+EZqkT2U5i8k2g18UakcOWkRdUnkikna+AX llLzc/w3fBjPMFVatFlekUrjGCsv/B4NbT6+XiDJ6bZhtSEmC1tjBWu3XEXXdLc3YBtuUAou oCDmerSUxYRGm3hR6YWA3TLqOTE9OzGcvz3/fdX33gc4uTveI28cz+ZolLz3nnodqOm9t2Dm dfv+ezXU+v7Q/2BcevxRfu35/YwW3yxkO7IamuQbv7Vf1WMTynz5MvBfhv7Luv+y8a0XfkTs 2EOKsZX3vl7oY95otJILbK+7VeJM+PAeyKgjJUSsRkqjI3kHLfF0Khtd8SkwPzVr7FOQrtUM xKeAWKN/Cv0P6hLpZK26+JTG1WCfbLia4lMaV8v/ENjb1WyLTylcXf7JgqvbEZ9SuLpd/0Ng bxdmbuLfCFniU+CLNAmpT6H4FIjxZVFnCUUlBAKTwlwDkvQfBLKWL0qhuMyVzvLZrGZXlQEA gRnFZsMCRB4CGIDEzVB5CW0ncRLKIspQrt+LskOk7JDfCy6LIL+48ACsIHmU4EGJgyJH6KBB qEuXoQ+/EYcgEMCFdsuQJzBQpmEpo5BZhAg1YRQaaeZY5m2RWTa+ut7cFZtfX5eUtU+kRNGX sQNSPmgs8PxqaJKJ5SulP7Pk9+Z24Sre3KwW65Q9qLJL6kaZSu8A/SOGsBjWIEmH9PKJWZSK pVauNGQsYySFxIBH0LRCQ9GT/3EzG3+hPKLJ9OSUJH0RXamck7u4jn+Skygj1RczzKutZ4IX 9q6NtUC0MNt59ldlLg9evBPpO9aY1XTp1Sj/5e1yNqEl8EZksrZ2BwJLZNHEbtR+suX42qtQ 6mMwuDFFN7k3dHac7w3IcpljGk+e/Q/f4xW8vzB2St6ckxkKZBPfeSLZyoF/7udN8Wj1qYKS 4TCnDLriK3mWYmokZBetIF9/B16CsEpIkoAkSVLuBXlyz3j44oGZ+zkEfF3NNnHl4Rutb555 D6s+e4/icDHH/xYB2NOqewrAngBg6ZzE9BJOGuwwOzJLzxpAy8xXg5QEJB0MdzudmyA0rKwu VpKeNQ+m4cMrb7305tG/MMsNpsnc3F3jYJWOtR3vKyY/Xy5ZKmic+1ex93y3ahPwZgqaPw97 IOp7IOt7JOz9xweavO8xgR9JY1+bLHYtIPNZcgRiLUAr9MOe9BiQkuD64UBJa+4vg2U2JlVO rOaFXHohV+GYXTQh67MFfS8h6bm7gEkmGi9rU+BLdMi+HUostd7Mxmst1zUTV2vKjKkyfaqi XgXX+p9jkMdccl3FV0sSS9GnWMrZNwvKy7nRu4l5BT8D6XMmvpko4LRRTlWeHxqTpmI2Wkq5 fD1juHiKcSmv18v5DSWSxaTWT7y3M0z5yVPYQm2Wc1YnDoGBAfQVk9peLxeYaZ0Sekv1v7i5 GmHy4qmtn2kgmwONFhpMSXKNlSpx+O2wB0X2vu3hP4NvA/gHh+QBTcgHirNO64bEI1bqPf9U LdT1HwP6URruKZlgp95jL52EqPBRBvFBwOT7L+WBMPl46mZvJh+ohb4k1Blc+goDAXOOL70n T548RLHrpily6Xsox0kS9BZUW5No+dB/NFQC+9jSCzFDOg+KWBFnFSpn0LkSn4Mzh+Qy5p+Q UaIvNDvQlhWNaTL2ZTszSNlBvbxShZZQPt/yPGGaXTSJ52CCSgvhsBcgAKTM+LLHvuxZHUO2 B0ChlYRVyE7KbSyYMVnGknBgsW0iYryPZA7d4KVsJxu8PYJn692SdpRnGxwm3FIzxaQnCUyH RLt0KVtKB8Bnxfn+2fkZ20ALhGVlDnU/vec4NvcPYfm3CTMAhK4A6hkA6q4AGhkAGq4AmhkA mq4AWhkAWq4A2hkA2o4A/v3fVkZHqs3aNAj7ZjCAWYUZQCydmQ2kngHE0qHZQBoZQCydmg2k mQHE0rHZQFoZQCydmw2knQHE0sGZQPA/hkwW5iOb1+bHy2+XymT88O7bu95Hkjz6svcSLK1M WWZ7DCSXpG/e8XydmkgFyEPCxsTwJa1UN9GoEjSEbr6IV2KBEm0y1bHwi9yMxyDFpzdocRuu DrVjGE8I9i1CvtMEeLFqLtDJOcq4yGjKWOBz9URMuEN7RLVQaxCuT4RZmAEojT9wIoA/pTXv d1a8ruBexfeyC4Q1khgf7oo4MaI0GEX6V2JidZi+5S9LK9tbpm3N6q6q9pbpWrO6q6K9ZZrW rO6qZm+ZnjWruyrZW6ZlzequKvaW6VizuruCBRArvfO2UrC3q9AGoox6vV3VbSDKKNfbVcMG ooxqvV01bSDKKNbbVcsGooxavV21bSDKKdUH3sub2XxSefya7+uM8KfY/EDHucfj2GRQmooC NNxqT7zXCHCNznby+2AMByqzSbyJZnMM72FRBmsRL/ga12HPvAFzmmGdh+PlKn5ookYfle/F f6N7ixavizsRDaTEIouspOeGlrikSwWNPmqYz0gDosFct2zfiJx6REiQIMSgYLbwUPn63Me2 JRESVyhxYex9EtcT7wjjI26j1SwazeNd5o3StT5h9WZrDRliuMH85BhHJQItbuYRW/dH8zH8 TdsoM8DJIeK+23y99Caz9fU8uiPrQfo3jfZjXOg6umVbdMydOI+9HaZ9nmz+3uwQJkASr7xV PAVCFuOYxD6NqMpraY1cr5ab5Xg5rzxUtR/atJbSfjRGWaRqgippG1iCOWaLCVotlcFu5XL3 XbW6e3Byevzi3CdbhsfFAUM3m7shOW0poLBEOKJ8BCw96pOAgfGxPbTVchSNZvPZ5o4RhpHO 24MDZqATebkqHTdpQiJ76/uB06M5t2E+hXVaeDYoFydpkqU18PJ+kEx+vbsfOMGv4H5gEgP/ vrASA5/PMoToD7XoPMvCQpiw8d+bVTTmNmzPGtYkNBmGNJ35vf2+f/jmwLIgkUFYlm/UWDM4 +8B/jSjzYG4nMLaQCmWmxGxFhroc+07jonTnWxvxYfiNdfLHdC+bUJQIPzr1BgTmmV1iq5Lw AzTSeDW7AisG5gxWwKVzR2z8PgyCwA6EdTFTyqBx+FhsVnU95LzqEatmXEeaJpWfiqtjK2gs u29+kgpQoyPpV00MydeJ+oJqVhWr0Rv6aR3RNdxNY/+pZpdKj3sEfUBbVwferhf4ciqdVv2D kG1pQYlymzOLzeda5YAm7XD3AvoMfw8BcwV/cpVccsNHwgTK+wQyqLA2+BgXUjl+cenvnbza zw0Jtjx72EaMpSY+AAu8xx7CKQcFeY0zEUja819RfBVI/iF6nSqv/FdHZ3tl9xTVzGATyDug PlSBEAehnBkZk8sRvlc08zj5ZTEMXrxC3lZaDWBrv+pdLSdepxwI+8wGwCWZaZ8MQWo2aDOH Ix2isxER4kTBFvEtJAykzt0TUsy9xtMCi0+CrUFD8LWwHRWGMLEvC6PsYfW5/nP9sFoV8TAG wz7QX5X+i+N9v++fVL/1VGMqtAzzvRPRJPiA7iL4p+Q2L7aqLhqFuHiUkYhvRuylt9TZfnqI U/JUH+eIrPweN5h2m/hTvKr0KYqzjw3tP2eLMv0F/fvwN7EK+8O6Qsl7OBOAwEo/taee2Xfb toZGULJp1Is47XDswLwDcdZq8MlXdvtesocPjYeVjrerLUnFjFrP/hVzFA+3DhEQOHTmbzXN 5ejv4VgP5Dm85RUFot5569nVNSxjJ/Ho5tMnCmBaLufrZ2r+3EZzdOWDhQPioZr06NMU1gUF HeFDQZEq3dOLYcxKXDlKl8o9j5KE9ONPrJ7djHavUTNs8Fjnzziz+oZHoEULr78LM0a4QViQ USIClIessEC1hcfnBTtd6V1Q9DFCnC9BNfMwZebTYH4VOrq68EYslJWdzNxJngbc4ccjaFeL 6/sLPJkEWp+fS5K9uwJq2OBIHSm01HAe6KC6PiPafnAfKEJmnGrio4RQpbh3zoAA2nMhYtSL +uu/uLeMU5c7Km7AvbPMk5v36K3v0Vf36ikVlNZ3jUozujYAlu2JU0HqC/V5Tz+I0PPPT85f 5MW7nB79dXguVhT97HK9/QMqRvBI/WcW5bhPh72js3OfEOQQIChlpRFNXtw2P3HFCp/vHw94 teI6QIlRK6eOtnK48EWwircnzuCpcFIsRAHyaq7gPrA6X8GOV2hhXxQcjPMLIdZDNRvXyN7F 8iv8+htm4i5GkeKW8806xlB4chnvXi8BDQ/vJMTrDaZcZAD4GV081r70mnUizudHXgH2FZbc fAaQ8WJ584mFIgNCap1sMZ5aEvv4CTZ8ePntgG3b970/0Ebt0zju0wo1O/JdzI+X9qN6FpbD 6A5sTiPtuUDMF7gqfOk98sL/7Ac5Fg7jVgWWvH3vN6/ZyKfjJYH2nhJUaBuxfjhFrxhFNYN5 tdpURIF8KgMGa5fBeuS9zCmdan8O6JfeH7RKeAntCfngPI0jvlfEhDUd7CThSTaUJkvJ9L9I WlJXMfFILxCgoxDtzAswAC+C5/TvYjZP4eNbGDTuFWpDw1CouKKEv3AT/vy8/X1Uq1fhLYwX m9UdWHzE5SrGLuNCA9cZ8II3tM8a6vMGm0r0pPeKGtvff6sirlOXSPDrI4gXY5AaYGuw7qCN p6ON93W5+gIrgiOM8158qQqde6cdxEcNe40nMlcLdiSX+QCpf4AKHyhg3UinS9lxJzpyr4rg J0c26VURMp291Y6hjW82a3V2OH1Emfal4nk8lmeEdkB+LRfwdb4D/TmnBq0/z64RojjHLKLS 116P2AcEU/zN/I5F48yYhYGny7R7OXBi7UDf7OBHkL10+gHeLcEopvsLlvB+9XUGshPk66cl 2j7sMoPpCoaesFtIjPcCYq7e/AvGN2QoNADWPig98B90iPNhgQOHQjl6z3mzU9MnsM8gn9cT ayB5PoJEM4xPub8rLlAwrl14oxFcci4tlkNWz7eZP05OFPP5zjPV+17mNEFKz/oqwMJ2CsV0 JNU7ngVZ44CLzKE2iaezBfRDZfYkfkJX8dDgq1I/wM8h/BIj5yiD8+bngnZIrcUi6pZDQPMZ 3eNZ8NW2gyzBLG1s1lDbkMuEoG/a6YQmSdG3LKCPjpLyp+/9n99JNyXgapscF7JGAKBlL0C3 wPT4g5xeRR0cTSbMnzBEQVHp82sECgctm3Wh75ncZMRQ6zJg883y+fLTcHyzWsULMgmgQL6d 4olKVHgIonw1G92gn9gHMwKg4ImI7QAEEoL1XgHtwe131pqD0GeewNzyXBAmd5qYmV2sTLRu F4eB/RNla2yBOe0uBVI+atpJax9rntZZab5/WgJFf1V9tkn0l39Z9cXu0iVV92uFYtClUzWq AkZWwQ0fIGbWs6vZPFqJuI5Xe395O/6ON0LLgoJ10Jb4vMTFBSqwr+xUmThGBsgpzGW5wuhL GOUxLnzozQIP2aJG1GwVsYRhrjKPaRxaQvBbsJLfZ+vEDUHMHqkcB/5xaMoAcTlHkGvyzxa3 yy8xQhDV84aHKB0KuQS4sie8oCB0okCHWUyBTi9fJbEPJhtoszrxVr98jB0olAIXfq/i9ecl 2MzAblgFsmWbJfQHt4Ui6GJ+8RhVSyOvJDohS8oPdGHscLkQY2gBtJCIyD/2o0wommfeAER/ M/cmokxuvkUDMPRGq2gBqo7xKLqNYCLhpECTEll9AcY1K4IjGSbROl74/A0oH1xpM6tUXgPF VtbsECabc+IMJXNrqUCSHRa/p4DhZW/MhkGntSpY9W33vLGS4SOjLCxuL+yXsqUDY47sBTNo yC5qloWlKzTnKax1/aMC+cUYb5yLFTLEiE5cPyOGXUVfYhaiz22j457OO+4Zgpd+HyhOvDzi L3OGLHQadPKQpKFAACYlIPGhdn7V5dUI7L1KUbmr6FpALgzbsZJvbWgOED73mUnI/pYWTN0U vn62ccgmfJ5s5GOMuAfqmy4IVFMv59YEGdeyxqhDvSrdKVR9zs2wOjdOtU5ioRIiaCJpw9r6 8jXvSxozeGih8jrwX7tGTzG7GIwUAfBkcO5eV6fHB7R7rlVZly/o2jPs8WM5DNg7HBqXu6+d A/BYUNsmvqq8d6ee9a2wz7CHSjT+WEY6JULztkYPqMtEvX1vBpKc5wO9796PrJoc5+H2w0cO 58BFNmkUyBGvTibzgUAzQl+Xryh8Ld1t71nc2C/PLUrlvc+3VCWipM/wNbmBDSoYW6hN5/5F ihDml8psIevHE/LpgoUd4sEYVIMn2b2Z8InlFdwCttKfbF2BilDULWyFqoZ78Krehb4sT4of Z98BGk5QHoNEnvM/AoughB7by4Rp8RfQzZEA6/VzPkQxckqe8yWVSDdEJESz+HCxO/yG5/rM oadZKdkjW6tgRun2cqpx/YmcvcBLHqq0GZGjRLmZc4TlqmzrINvOStTpHUHxDm7aAUU5pZ2N s2T5dKvz0TCijgI+uLAV8P8wuIpr0Cju5/WGaDGV7Tj0QI8T0snjfcagyGlk7qjI4ykfk9J9 vQeQNszBenQqFlV4xwr3A2eeo/FxL1tZu3yFvJp9+ry5WuK9uWxJgYdi6B6r+BZ3AOWCAf3/ eP6CWWyzVeU4cRM0iGVbZLElht4W+Z4eabaA9ozx9d5S9LiQDKT2spAMLPXOjQwsahoOijm2 gGi0uaULDj1DBKNtwlheXVfqPytA5xgnBVhmMDpWd7QEpYWQXBjxL/8NbpuX3qcYfd1sjrA5 jVcLiXO/+3z35jYWrikKnGLXyvLbqMRFfvxuedrNYgEjOqQxbZTzq5EWd2L+DcihxhEvr+MV Gx14ROxrPJ/TRdFImbrXCEbl9WoWb5DB5L+jy63EubIdaM2Oj6EntDXCgx53iF75krz7Owi7 gsvWiA49i60r7vUS7gOxAQPtuMYNrtt4fse8/0wAphz/MmIdPhQ7FLUIdwyi9vP9Vp4Mcceg 66JiIRQrCHfweCR3n7l5L3JcQYrOA3cq9wuc3ILM/QJXNuc1bZC77aPwGqF/ETrWqIjdjkBt fBQ2FOsdgOGEOhC6+vx4wAMUdr2LEC8AhT+f4p8Yyp4ZU8DKlNvhokgIxCcw4d8clR2NKJDv 8KMHmwQWAO1gsvbkQhYNKIQrBtE5DSLuij+nPVM2FODvEDdasW0F4MQmvcuQhRnv5zulPW1q Fe6U5BjoLtRczRZDtmHqTFPuDQWMF7AgACn/8pUDAUwqumMvliIimKuMFHFGXyRFyksHba47 TnBcasj5IO4Th5dBjYA89djfrpOLFoHrm6ugRdcY87PB8VC9B7A4rhzBJdSd9NSLAAGM+XEY oRaAbCPchDd0l6qZDwhXtRfAxy+FSxSyMBGdY2XdKQ+IYAewSC2jmQNfmhgqGeRe/5p6RNjm rtdtlajGMTYoajMsh1KNAFBgjvexs4fGZ6vZrDdRMTBfK6ekxnysVf1dn4cLUwSRiigNWvl8 sgQCamwKMtgkcAYFLEm0Xnii8NUlLHTeE63v6VDFJSx+38H/2B/kpsGmt5jnhf4s2HvVrd8d stVZwDGs6NBs3RGGJcL4gGoWnTtiLRP/jY6kgPY+6LL40K/7jY8fxc0K+k3NfipriTBevR12 JRM7vM+uQ01sopARjDcUqP1efW/wmfABglDtBUljdB+myof92ke5071f86GaswFXc7Xgag4m HDtoTMxLMBkl9xHGF4C11guclAfjmLsGOS6wgd0vOSg4HSRuPOAXHhgXHXyf6wS+430C3/tC gXSuo23uE9A2Gr7HdQLf8T6B732hQPpGgVpVU6y5s2G2Zluo+3KRqXYDjPmF08snecriE5KN 4GnAlPEUuOp0uQQOfTOcCqPq0JFMrjc64XUVLzYUCLrLnW5jHmYnAkJrLLgWFcgz5dKm6MbE 9oNT+LmAClqPYv+eJCEWA7LVd9gD/xQv0IkhvAmH7Kg6dE8cU6PkJQqpc99f4rv1EhZT+CWf /w/4MbSCYvarHc4y8tGoR9jyIToZGI9Q8xUxXFUMfIyPFxc4+0UHZMTZjhC6mYXZUq8UXd1M R/CHdC4C75zr+2gvU/zugMw+J1LZ8fVP8UYej4Xa8LbQZxJU2OH39yq9Fh5+f59fsV9XbVuP o8UQxwUOsbq/GyQOPmfDEL1fRCQvp05S49CjjEMVbejh/tPF/ulB7+StbwQUkGfowrg34EKe +S9v9X+3WwLo0a4KuNj+qgB6RJbAlHd5zy32IRsweqP7ehQEbeBxhtOipzxQrTrb+9MnOJgd Q/9Su+RCnyFvoLff4kFc/3T/zB+wywffIh/f4GYYHVAuGwhe0eo/9uoCxikeVkY08O97JQve gux5W8dz7ef+PAJy3/oD19uc4UngCnRcAYDGj29pbhGKt6E7YAkCqvHa7v1dqeCS9O1zoOw3 r8/myRtg8yW/GAOEEt5weun9/huuUorjnPUnBY3+BjFJS6BLEMx4oPAyYB+xdwtkkPm8CQRT YbWFEToXogXQXXWJlPrOnaGVN1LS4br+N+gYVB9MhhituR9vLgxOf0/eiINcyJs3yJs3ogUa by7K8ibRjYrukNN9Ff1dAZrhN2/A1WzBX2zXENXD6CITLSqRGKFyGUIPXtLtCWo4GO3HPoQy 2904oA8yDWqdQy0jfSt2IVFBWQSNwL+lOAIR+NwjOQTyaIAxapSS0RnX20DJnLS0JYfk20AX uCSXNXPjgpsbKIgv3G4zYeYn1eyr4VOgk9WJxEC3di4Cjp/F0+uQ9axmeF8IntE4FWfmrGpL dhu68wUsRIAGYJ/EAepoprOU9YP2/V7SFL4QV3W4aCK9aYwEbqIUn8vGS0H+YMNjj13TsceC STA+pEKnQOXlRoFmt1xgijkHTyoDymAW0aIxhMbNXmBchJO6UfTY31QSl6ZlRYKfbXe8Szxu Uf05D9kl/N7xY1jVJg4CbQPQvoi6V+Ncdvqsj71x4bYWY1bjtoJV4bFmt/EKc6rBiNEtf224 bMU6jGrRgahVBpA/TFxiZWAWFmwyJuY7uJ+87+/R8lLhMSUp+R5uJ+/7e548NtLSC8LL3Xeq g/SIxcJRRKloS3T/PRZXlfusofQFlP+LP43kUe8fGpWDAUMDcZtP6qTEz4gReosXVuAmxXzO U48RKSoH2+nJ4d7uQd+brKLpxveu5zfk39MSsLMqlJIOoMQTb8fUWzv8Pgy6UoNnUYs3PLRH norip+jBmKKzbonhRPdb8BOAdEKQyRF1uNP/xRwS4qhucolvCZq0nK1OSUfjxqE0kEx/gqUs hrVtrq7pM24uJW8nqtorGFcYYT2AUZV/kOGSicqChsJbrZLExhB5kY9gffJocDXFfytD7Gdn 8llrcsu4HijNLooaNO4QSrPrsYVdOrdMNHRljtyDlqeB+NUMxcNRQ0Kx6VAP/pe3V8JPxu+/ RQR5BY2rIoKi8ttSQC1//JgdBOWKnP+gT0/1L8kTCazbj4PHj/nJuVr1+XEof3HYv4LWGKSq G5toAEcchDRJz6mU7I7UOXkDkIrq18pUMXGztWBlEDwaPApqNRhVTdzhw21p2uvD7M5GFds2 V8DKZbUrRa7a9qHNh9nYPFWXONLlZgiZp7ncajEGXOACsLho8gggHoEpA58tifhJIhFdzTsA 123YXeJzFRd08i3fa6virNd/p+KbE5wQO3TvM4pZbUSjbtZRqfuSnbE8ZDyxLBt5CMg6nk+H kxgV6wgVAVO5GGQhho12pCRk/nAnS1NIe4qFH07n0acSlefrEc01rTbygSI8HC14rarY9hO/ qWELjGxipoOOxdqDqOSCn2Udnm2ixSRaTWREueVE7c+KJTfpEIek1ybNdHSdX6NyI8OsoxGs Jzx1meUzYVIwNSsMC25k2HvdNAZYSE5OYbbZbVP/WQJLNwJ4xA/5mYTqXzFlC8L2NSNYWKRW cCnrRbeHMghPH3tI04/RTpXwP1/ngEC0FXbMO4mVnfRWENBvKn+j9ytreal1Fj8CSAKE7a6T 1pa8qfH7EgDvp5t5tBK9K0rU/L5RYnhNgVJ4ks0sKs8bRpvZWPuWjIGsaAPCT0QzJr5wylDo vJbWxtbggJcDeSqThQfzi0lI7IgbmCpikOQMOtKKZcZJxkBhwcxyvGqiTxFmP1kja+edAeOE polUKGeLaQxfJsPldAoLPWDJyxdnZVlyvzlUyCWaThVt9YR/EpniEGfB+XyNMNsce2wBaOHQ Ov6/N2hu3ZdH9+ZSMZ9SQmQLjjEsWCnFe4NeyTNRrAQLJGGK4eqeYoynZENYLjaUlFIHeR95 x9CHAy55vszkwrfs6n3rxbvL2p3NcDlcjhWJ6vK3nIQmdjdnsrqm+sZ0tHJ4tV5YOZGtjC2a 2GrX2cVSJVv60tYNGylBywaRTSD7Nyavg5YPDcqnupY7CtMWg2LZA2/w4l3v5MUrr7ff/+v8 0Ds68970X/dP3va9F+fe2fmL03Pv5MB7tb93cjw43T87Ozrp+97x/vnhySvv7cnp6zPvpN97 h4XPD/e9l/t/HfX7R/2/sBK+ONx/8Wr/9BcN05Bj+t0TIPflu139HavKP/l43G8Uq4MJE+YD FOFs6DRe64Jr9i8UWgNtUsRlfFpJ9tkmSCxnSMwstkEelHIyMw8nv7R/oN4UQUoO2Yp9wlp9 V+zQdYE/XzLXAtiiUmbX8mDEvfvGuXd2vU7BSs3sIJiT22NmJzOcOsjWRdrBEQXD5V4fl45Q Lo5XqGJ8NpfP1ERZb5aZnQENS15C8UpqomIFKI0z6xBkahaRk9VK0I8B+iu3/aSEu8nSLwRY NtaJVgOKYAlBcoNArMztjQfeGYi02HuED93TjQcw6MjywdHl/ivvbO9Fb987eLF3fnLKSj16 9AvDwKMW0F7wof/gwS4kZnBTfxStY26xPH7saYkhkw/zOVTOWKGc5iCyia76sG0aEuyzszze KLZO4lUeIFSaBCmXIFXDr5zRrWU6idXHivUSHZ9IIoHt04RX+BiPjR6H3q+1bf0rP94lc3o+ ePrm1eDp0UB6QH68ByaVS1YORc97oOyyokkjqxcVRFxuJZEyt5JX0XoDowSWPEN2GLOoAgM7 HK/GTMPJtotH8cCm/QqZkbBlwA7ctduJyUrXQy5EnHnNHQoO5TfLNV6FOgSeOpR2BjublICK /v/VbTxxKDpZsrtxP+FBD4fymJVAll87VGD+AxfGza5i4N5wPruNHYqLXLgl2OI8qK6H6+XN ahwPo8kEbT0XPmICaV6crVYn5lDXZnt62NZTm0ypByFyuq6Xq0KWYnGiyrUw0uJSTrDxCVM7 TLBlNRW/OU42LMrzvLkUhdUkOynlUni8Xo2HlOfZpfRVtPriJjWvo7v5MiqcaFi0WLJTInIa bBk2iAZsTQLVpZgre54wZZ+S8FSIdajmh8xYbyce9M+GeJ3Kr90a2AzKRQMy2vs1YPaDUhB6 VYbP7kso3k5SmPidQkrip5Ewj0TDb1STGkocy7cUbcqimrRPQuWO7qd6szuymg46WQ29VMAe 3hkPvP7LE4xGvYs3fHEvT+VhxvSEYjBAIfc7Rdx/4L1FMxqxqMRQ68/LG7rYWE81NZ99idld x+yctBU1n/eL0dJjDpusHioY4tpAA1hio6+olo3nzGtWCplYCriiI043wfKoGqipGx+wntS0 sgZCH1aB3HAxtLJelOP8tdtNdin2qKicVNG5eJhyTrQqUbSuldX1s+dAU0enydTWBqKOH7Ql Iun5MIlKTI6Ukk5TlOiNeqi4q+lqW0us9aAnH/3XPmy4wTKFG80/AqOwVDS7opAjogcSBobZ VQX10NZIziZWLzV78gonxoNumWSM5haThl2LNPyhXQyr0R/axZoNZudM6PNBrplgKWZbhaus Ja0x51oPvJObFUaPTmfzeO1dzdZrleRHximI1DonPLzG2zs73fuTtBZeCDnbUN410leTJSkp uvExYfIVUkSqH2/+ANMnmlBWN4C6xqBalaFLJITyNMBIHSZ841EUPZ10wZkMOpj7qeGrz0RE Tg1hfVhUekNpdGW/5k0uvbvJgnXp7raqtU4YUkaj+HaMaE5G2bRg4OU3a6+ggpDJ93UMWrHx 9pPPsB76QavQ3tQMiKRrLb8a8YbKu8M3HXUOKKAK1VB9RzhTLZbWukX96XBMRuXozAd8drNT //GKUjFdL7/Gq+nNXKQ1BLMW5PZXSt3wTAyZAhLN8Q8I+QR4UExqdmXOn3VyLeLQUDFrLdVo K0HNaD/wYVDVig5OfJBBklSVEmIVn7b430r5lXLN+f+t9d+uVvlKH4tjpLEwq7pmUbKlaojY aq5/ghYea/HEW76AvoqjBd5N1mp4Knsz2gqE70/vaM0S1axvrtF2jid//vu/peki5CnHC30q XtQmhVTJ4gWeJasoDLn/xMotSzvEJwfashcTpat1NCJZ7kb9ybIzfk4c8fneT96w2oz1zaok k7bYr6K1P8AsqoBof/BulCBNHwX/qN0oB7ZvsRvlBvX/u90oN7b80N0oNaf0kmyk4zdXYrBs iT0oLO68B0Wwnacylo7GX0qUxqgSxwGAxV2HLZeS8XjBNFth/2CFm1XhHpdoIDq/Xcperz87 l12tp1TWidavsJZafnVsVQkecCPB3EoRYtjLW3gVi1Xmigh96Bfp+FViSxYzhD2Pds8OKE08 iQWl2m8JanbHp0VOeEnnTsfnRX+MIxIsjB/qiDSkR2EvC8YlxIjRdUX1jI1MWa/CKso7S0fx 5+h2thRHLb1fG52q9zS//yvY50Hgh00cjzZAmLbv17BWCCiPGLyj4deg6UZMw2/UulnU1B0h 5VHTIBieGzUwnulmZzuoJgP1tAiUsZSxgWpVVY8rrSAgFPR4jaLd7tnbQRkgmb0UOkLJakq9 DBXZvdO4JxlNx/oFPdtiYJQMUBqcQ0j60rXvqlJ627VgI0AufJRK16rhy5sFZZ1lW0n0gn7y ex1VAc/Eqa1/US8V6RexO1Mc8aBKKhoMCrakgfMBTy27KHVRVig88TtFhuY5UExPl84pDNaG QUBiE8InawQjBxKSgc4TGzXExnhqB19VFdZVNmVaYWleWfHUlQdbvMD9m6b2O2C/E65mBZ4Z ZOmGC3OkLcyRoMnkjPdrPW2SFBo3+u6qvkYw0d7vcIJX4nxCEHZKxP44tLHgfELQaLgeUPBc jxYk7eQkJ7WpKQdvYUTe6tN0+K94tcQOph/LBfNOqi/6Y4aCuNm4CiBATxZQi0hBs+tSgd+6 mGSL6xzTAGQV1sYuX2ukyKbdGU1tsO2Z3aBVYoeGrEwQLSU81lgFPQzAXBzjperFi0nJGovl kCVpg1c/rio/Z/JDaxW7/7XB4Ob91ysknP8pSFQ8x1+fhyXPo26joMihXhZXR9PBC8NsMFao NVVUHx22otp0xQligyq+Db+AUnPyEGHheVzoLJVlR/Pl+EuCDsKV0bpmkmTEZJLM7IuOr5f5 tPlsVCS0yYrGAWajvt9xchcbtVLUqrjS1AgxCb7nQJECzOAPfVs7dygUdfM788LUU45l4/Hn JSwArud3iup1svvNAaA3cG0G6hrDu5Yoy8KEjLIZ1/V0/LY10EICU5TfFxiXjakGa9+c+0qU d5x/ojiTXiZFWj8UxkwbyBMN0eejViYxJZOUqLqWKZkEUWJWJivayOZDyToxDcq3nJv/D1BL AQIUABQAAgAIAPtO4i63SOdQv0cAABdLAQAPAAAAAAAAAAAAIAAAAAAAAABGTjMxLVRDUC1S VFAuUExQSwUGAAAAAAEAAQA9AAAA7EcAAAAA --------------080400070608070702010504-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 8 14:25: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 OAA03068 for ; Tue, 8 Jul 2003 14:25: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 19Zx9E-0002ti-0h for rohc-archive@odin.ietf.org; Tue, 08 Jul 2003 14:25:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68IP3hH011130 for rohc-archive@odin.ietf.org; Tue, 8 Jul 2003 14:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zx9D-0002tR-Ta for rohc-web-archive@optimus.ietf.org; Tue, 08 Jul 2003 14:25: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 OAA03058 for ; Tue, 8 Jul 2003 14:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zx9B-0004Jo-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 14:25:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zx9A-0004Jl-00 for rohc-web-archive@ietf.org; Tue, 08 Jul 2003 14:25:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zx9B-0002t4-1e; Tue, 08 Jul 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zx8Y-0002re-NY for rohc@optimus.ietf.org; Tue, 08 Jul 2003 14:24:22 -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 OAA03017 for ; Tue, 8 Jul 2003 14:24:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zx8W-0004In-00 for rohc@ietf.org; Tue, 08 Jul 2003 14:24:20 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zx8U-0004Ig-00 for rohc@ietf.org; Tue, 08 Jul 2003 14:24:19 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h68IODd14572; Tue, 8 Jul 2003 11:24:13 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 8 Jul 2003 11:24:12 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ROHC mailing list cc: "Wijnen, Bert (Bert)" Subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt Message-ID: 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , >>>>> 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. >>>>> 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. I definitely agree with this, and would even go further: I'd suggest that Section 4.1 emphasize that rohcChannelID identifies an "ROHC Channel" or an "ROHC feedback channel" as defined in Section 5 of , and not simply a "channel" as defined in Section 3 of that document (I'm assuming here that is the document that is cited as [RFCXXXX] ... even though the title given in the reference list does not quite match). Yes, I know it already says this, but the point is easily missed by a reader who is not 100% familiar with the ROHC terminology document. Indeed, a person (such as myself) who is familiar with MIB module technology but not with ROHC will tend to infer _from the structure of the MIB module_ that a given rohcChannelID could be associated with both a compressor and a decompressor. Put another way, the separation of rohcChannelTable, with rows identified by ifIndex and rohcChannelID, from rohcInstanceTable, with rows identified by ifIndex, rohcInstanceType, and rohcChannelID, tends to suggest that rohcInstanceTable is an extension of rohcChannelTable, with one row in the rohcChannelTable corresponding to two rows in the rohcInstanceTable ... which would be true if rohcChannelID identified a "channel" rather than an "ROHC Channel" or an "ROHC feedback channel", but not otherwise. Similar clarification should go in the DESCRIPTION clause of the RohcChannelIdentifier TC. Another alternative that might be worth considering is whether it would, in fact, be better to use in place of rohcChannelID an index that identifies a "channel" (as defined in Section 3 of ), and then use that index in conjunction with rohcInstanceType to identify a particular "ROHC Channel" (as defined in Section 5 of ). For my money, that is a somewhat more "natural" MIB design (more precisely, it is more in line with what we have come to expect), and it is probably easier to map an index that identifies a "channel" to an already-existing point-to-point connection identifier such as an ATM virtual circuit identifier. Mike _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 9 11:14:13 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 LAA04927 for ; Wed, 9 Jul 2003 11:14:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdY-0001Xo-HY for rohc-archive@odin.ietf.org; Wed, 09 Jul 2003 11:13:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FDe9f005915 for rohc-archive@odin.ietf.org; Wed, 9 Jul 2003 11:13:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGdY-0001XK-8P for rohc-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:13:40 -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 LAA04330 for ; Wed, 9 Jul 2003 11:13:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aGdX-0007Jp-00 for rohc-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aGdW-0007Fw-00 for rohc-web-archive@ietf.org; Wed, 09 Jul 2003 11:13:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd0-0000xi-6r; Wed, 09 Jul 2003 11:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aDrK-00028q-Mx for rohc@optimus.ietf.org; Wed, 09 Jul 2003 08:15:43 -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 IAA28584 for ; Wed, 9 Jul 2003 08:15:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aDrJ-0006I7-00 for rohc@ietf.org; Wed, 09 Jul 2003 08:15:41 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19aDrI-0006I0-00 for rohc@ietf.org; Wed, 09 Jul 2003 08:15:41 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSK122Y>; Wed, 9 Jul 2003 13:14:59 +0100 Message-ID: From: "Price, Richard" To: "'julije ozegovic'" , rohc Subject: RE: [rohc] ROHC-FN RTP Prolog code Date: Wed, 9 Jul 2003 13:15:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-2" 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > enclosed please find a zipped Prolog file version 3.1 > > FN31-TCP-RTP.PL > > which includes RTP profile in ROHC-FN. Hi Julije, I'm impressed you managed to get an RTP profile working using a ROHC-FN compiler designed for ROHC-TCP ;-) This work could be very useful when we're considering the extensibility of ROHC-FN itself. It's interesting to know how much effort is needed to define new profiles using ROHC-FN, whether the existing library of encoding methods is sufficient, and so forth. > RTP profile presented is adapted to the possibilities of current Prolog > test program by ROKE MANOR: > > - UDP length is not inferred > - NBO is not implemented > - CRC is not implemented, zero bits are inserted The above three encoding methods can be defined using ROHC-FN, so it shouldn't be a problem to introduce them if needed. > - scale uses explicit scale factor (160) The choice of scale factor for encoding the RTP Timestamp is left up to the implementer. Setting the scale factor to a fixed value of 160 is a valid implementation choice (although not necessarily the optimal choice)... > - list is shortened for 8 CSRCs, to avoid 64 bit order field This is a limitation of the current Prolog implementation. Since we're storing field values using floating-point numbers, the maximum field size that the Prolog implementation can currently handle is 53 bits. At some stage I intend to update the implementation to store fields "properly" as bit strings, removing the restriction on field sizes. Regards, Richard > However, it can be of benefit to review the capabilities of ROHC-FN. > > Best regards, > Julije Ozegovic > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 10 08:17: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 IAA28568 for ; Thu, 10 Jul 2003 08:17:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaMD-0002PQ-SY for rohc-archive@odin.ietf.org; Thu, 10 Jul 2003 08:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ACH59j009256 for rohc-archive@odin.ietf.org; Thu, 10 Jul 2003 08:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaMD-0002PD-NP for rohc-web-archive@optimus.ietf.org; Thu, 10 Jul 2003 08:17: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 IAA28550 for ; Thu, 10 Jul 2003 08:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aaMC-0002BL-00 for rohc-web-archive@ietf.org; Thu, 10 Jul 2003 08:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aaMB-0002BH-00 for rohc-web-archive@ietf.org; Thu, 10 Jul 2003 08:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aaM9-0002OQ-LS; Thu, 10 Jul 2003 08:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aV75-0003RV-5v for rohc@optimus.ietf.org; Thu, 10 Jul 2003 02:41: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 CAA19745 for ; Thu, 10 Jul 2003 02:41:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aV71-0007cx-00 for rohc@ietf.org; Thu, 10 Jul 2003 02:41:03 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19aV6z-0007cj-00 for rohc@ietf.org; Thu, 10 Jul 2003 02:41:01 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6A6eTVI036024; Thu, 10 Jul 2003 08:40:30 +0200 (CEST) Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id 9FFB2B5CC1; Thu, 10 Jul 2003 08:22:43 +0200 (CEST) Cc: "Wijnen, Bert (Bert)" , "'C. M. Heard'" , "ROHC mailing list" X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.45 references: From: "Juergen Quittek" MIME-Version: 1.0 subject: RE: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt To: "Surtees, Abigail" content-type: text/plain; charset="iso-8859-1" date: Thu, 10 Jul 2003 08:22:43 +0200 content-transfer-encoding: 7bit Message-Id: <20030710062243.9FFB2B5CC1@venus.office> 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Abbie, You're completely right. I will add some text as you suggested. Thanks, Juergen > Hi Juergen, > > Thanks for your explanation. I agree that generating a list of compressors > on a particular interface may be a useful thing to be able to do. > > However, looking at it from a MIB point of view I think it is confusing to > have a seemingly redundant index. > > Hence, I suggest that rohcInstanceType continues to be an index but that > there is some text added to the draft explaining why it is there and that if > you want to uniquely identify one rohc instance (whether compressor or > decompressor) then ifIndex and rohcChannelID are sufficient to do this. > What do you think? > > Best regards, > > Abbie > > > > >Initially, rohcInstanceType was no index. Probably this is the > > > >reason why we forgot to make it non-accessible. But after some > >discussions > > > >with rohc people, partiularly including with Lars-Erik, we found that > > > >when accessing the MIB a management station would typically look either > > > >for compressors or for decompressors, but not for particular channels. > > > > > > > >Without the rohcInstanceType being part of the index, a > >management station > > > >looking for a particular compressor or looking for all > >compressors would need > > > >to browse through all compressor and decompressor contexts, > >read the type > > > >and ignore them if they are decompressors. > > > > > > > >But with the rohcInstanceType as n index before the channel ID, you can > > > >first select whether you ant to browse compressors or decompressors and > > > >then go through the (shorter) list of specific contexts. > > > > > > > >I think this is helpful and matches requirements of rohc > >management stations. > > > > > > > >Cheers, > > > > > > > > Juergen > > > > > > > >> Hi All, > > > >> > > > >> Having had a look at the MIB I have a question about it. One problem > > > >> mentioned below is that rohcInstanceType should have > >MAX-ACCESS value of > > > >> not-accessible. > > > >> > > > >> The fix proposed by the MIB doctor is the following. > > > >> > > > >> >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible > > > >> >(c) remove rohcInstanceType from rohcInstanceGroup > > > >> > > > >> The reason it should be not-accessible is because it is used > >as an index > > > >> into the rohcInstanceTable and the rohcContextTable. > > > >> > > > >> Why does it need to be an index into these tables? > > > >> > > > >> In my understanding (please correct me if I'm wrong) from reading the > > > >> terminology draft, each instance will have its own channel > >ID which can > > > >> uniquely identify it on an interface. A single instance can > >only be a > > > >> compressor or a decompressor and is already identified by ifIndex and > > > >> rohcChannelID, so using the rohcInstanceType as an index > >doesn't actually > > > >> identify anything further. > > > >> If it doesn't need to be an index, then a MAX-ACCESS value > >of read-only is > > > >> acceptable. > > > >> > > > >> Am I missing something? > > > >> > > > >> Best regards, > > > >> > > > >> Abbie > > > >> Abbie Surtees > > > >> Engineer > > > >> Internet Applications and Mobility > > > >> Roke Manor Research Ltd > > > >> Tel: +44 (0) 1794 833131 > > > >> > > > >> >-----Original Message----- > > > >> >From: C. M. Heard [mailto:heard@pobox.com] > > > >> >Sent: 25 June 2003 07:04 > > > >> >To: ROHC mailing list > > > >> >Cc: Wijnen, Bert (Bert) > > > >> >Subject: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt > > > >> > > > > >> > > > > >> >>>>>> On Fri, 13 Jun 2003, Wijnen, Bert (Bert) wrote: > > > >> >Bert> WHo volunteers to review draft-ietf-rohc-mib-rtp-06.txt > > > >> >Bert> in the next week or two? > > > >> > > > > >> >>>>>> On Fri, 13 Jun 2003, C. M. Heard replied: > > > >> >CMH> I will volunteer to do this. Based on a quick look I think > > > >> >CMH> I should be able to turn around the review before June 26th. > > > >> > > > > >> >As noted above, I've volunteered to do a MIB Doctor review of > > > >> >. For the most part, I have been > > > >> >pleased with the quality of that document. However, there are a > > > >> >number of things that do need to be corrected, or at least looked > > > >> >at, before the document goes to the IESG. The detailed review > > > >> >comments below follow the checklist from Appendix A of the draft > > > >> >guidelines document . > > > >> >Those who wish to respond to these review comments should do so on > > > >> >the ROHC mailing list, with copies to Bert Wijnen and myself. > > > >> > > > > >> >0.) Title -- s/Robus/Robust/ > > > >> > > > > >> >1.) I-D Boilerplate -- OK > > > >> > > > > >> >2.) Abstract -- acronyms used in the abstract must be expanded on > > > >> >first use, except for those acronyms that everyone in the IETF can > > > >> >reasonably be expected to know (see Sections 4.5 and 2.9 of > > > >> > or its successor document). > > > >> >Certainly ROHC and LLA will need to be expanded; I'm not sure about > > > >> >ESP and RTP -- please check with the RFC Editor. Here is a partial > > > >> >fix: > > > >> > > > > >> > 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 (ROHC). > > > >> > [ ... ] > > > >> > > > > >> >The remainder is left to the authors to sort out. > > > >> > > > > >> >3.) MIB Boilerplate -- OK > > > >> > > > > >> >4.) IPR Notices -- the required notices from RFC 2026 Sections > > > >> >10.4(A) and 10.4(B) are present and no claims are noted; this > > > >> >is OK if indeed there are no relevant IPR disclosures. Note, > > > >> >however, that a search of the IPR statements on the IETF web site > > > >> >does reveal some claims that seem like they _might_ be relevant: > > > >> > > > > >> > Search Results for query = '(robust or robustness or robustly) > > > >> > and (header or head or headed or heading or headings or heads > > > >> > or headers) and (compression or compressions)' > > > >> > _________________________________________________________________ > > > >> > > > > >> > Match: [All....] Format: [Long.] Sort by: [Title........] > > > >> > Refine search: ______________________________ Search > > > >> > _________________________________________________________________ > > > >> > > > > >> > Documents 1 - 4 of 11 matches. More * 's indicate a better match. > > > >> > _________________________________________________________________ > > > >> > > > > >> > [ERICSSON-ROCCO] * > > > >> > ... Nordlundh VP IPR and Licensing Ericsson PATENT LICENSE > > > >> > UNDERTAKING In the AVT Working Group in the Internet > > > >> > Engineering Task Force, a proposal "RObust Checksum-based > > > >> > header COmpression (ROCCO)" dated June 22, 1999 has been > > > >> > made by Lars-Erik Jonsson at Ericsson, Mikael Degermark at > > > >> > Lulea University ... > > > >> > http://www.ietf.org/ietf/IPR/ERICSSON-ROCCO 09/01/99, 1557 > > > >> > bytes > > > >> > > > > >> > [ERICSSON-SIGCOMP.txt] * * * * > > > >> > ... that might possibly have technical relations to the > > > >> > Internet Draft draft-ietf-rohc-sigcomp-extended-**.txt. > > > >> > This draft is part of the Signaling Compression work > > > >> > taking place in the Robust Header Compression (ROHC) WG. > > > >> > See further Ericsson's general IPR statement: > > > >> > http://www.ietf.org/ietf/IPR/ERICSSON ... > > > >> > http://www.ietf.org/ietf/IPR/ERICSSON-SIGCOMP.txt 02/20/02, > > > >> > 466 bytes > > > >> > > > > >> > [NOKIA-RFC3095.txt] * > > > >> > ... : 1) "CID field handling in ROHC": FI 20002100, US > > > >> > 09/954562, PCT/FI01/00819 2) "Variable length context > > > >> > identifier for real time header compression": FI 20002307, > > > >> > US 09/978479, PCT/FI01/00902 3) "Variable length encoding of > > > >> > compressed data": US 09/536638, US 60/164330, ... > > > >> > http://www.ietf.org/ietf/IPR/NOKIA-RFC3095.txt 06/04/02, > > > >> > 1373 bytes > > > >> > > > > >> > [ERICSSON-RFC3095-ROBUST-HEADER-COMPRESSION.txt] * > > > >> > ... This is to advise the IETF that Telefonaktiebolaget LM > > > >> > Ericsson believes it owns patents and patent applications > > > >> > which may relate to RFC 3095, "RObust Header Compression > > > >> > (ROHC): Framework and four profiles: RTP, UDP, ESP, and > > > >> > uncompressed". See further Ericsson's general IPR > > > >> > statement: http://www.ietf.org/ietf/IPR/ERICSSON ... > > > >> > http://www.ietf.org/ietf/IPR/ERICSSON-RFC3095-ROBUST- > > > >> > HEADER-COMPRESSION.txt 09/27/02, 439 bytes > > > >> > > > > >> > Return to the Seach Page > > > >> > _________________________________________________________________ > > > >> > > > > >> > ht://Dig 3.1.6 > > > >> > > > > >> >The document authors and the WG should examine these IPR disclosures > > > >> >and either determine for sure that none are required in order to > > > >> >implement the MIB module or else add the notice from RFC 2026 > > > >> >Section 10.4(D). (The reviewer will be satisfied if the authors > > > >> >reply that the IPR section in the document is OK as it stands. All > > > >> >that's being requested is an assurance that you have done your > > > >> >homework.) > > > >> > > > > >> >5.) References -- there are some missing normative references and > > > >> >some of the existing references contain minor errors or don't > > > >> >exactly follow the current RFC style. The style issues are listed > > > >> >only for completeness; RFC Editor will fix that in any case. > > > >> > > > > >> >(a) RFC 3411 needs to be added as a normative reference since > > > >> >SNMP-FRAMEWORK-MIB appears in the IMPORTS statement of ROHC-MIB > > > >> >(c.f. Section 3.5). > > > >> > > > > >> >(b) RFC 2863 needs to be added as a normative reference since > > > >> >IF-MIB appears in the IMPORTS statement of all three MIB > > > >> >modules ROHC-MIB, ROHC-UNCOMPRESSED-MIB, and ROHC-RTP-MIB. > > > >> > > > > >> >(c) [RFC3095] has an incorrect title and an author list that's not > > > >> >in the standard form. > > > >> > > > > >> >(d) [RFC3242] has an author list that's not in the standard form. > > > >> > > > > >> >(e) [RFCXXXX] has an author list that's not in the standard form, > > > >> >and it might be helpful to readers to indicate the I-D that will > > > >> >eventually turn into this RFC-to-be. > > > >> > > > > >> >6.) Security Considerations Section -- there are two read/write > > > >> >objects but only one is mentioned. A possible fix would be to > > > >> >revise the first paragraph to read as follows: > > > >> > > > > >> > The managed objects defined by the ROHC-MIB module, the > > > >> > ROHC-UNCOMPRESSED-MIB module and the ROHC-RTP-MIB module do not > > > >> > have a MAX-ACCESS value of read-write and/or read-create except > > > >> > rohcInstanceContextStorageTime and rohcContextStorageTime, both of > > > >> > which have a MAX-ACCESS value of read-write. These objects > > > >> > determine how long context information is stored after its > > > >> > termination. Unauthorized access to these objects can have one of > > > >> > two negative effects. If they are set to a value lower than > > > >> > required, e.g. to zero, then context information about > >past contexts > > > >> > might get lost. If they are set to a very high value, then context > > > >> > information will not be deleted and memory consumption of the agent > > > >> > implementation might become very high. However, > >unauthorized access > > > >> > to these objects cannot cause harm to existing ROHC connections nor > > > >> > can it allow manipulation of running instances of ROHC in a > > > >> > malicious way. > > > >> > > > > >> >The fourth paragraph says "[a]lthough the security risks arising > > > >> >from the ROHC-MIB module are not considered to be high", but the > > > >> >second paragraph says "[it is] important to control even GET and/or > > > >> >NOTIFY access to these objects and possibly to even encrypt the > > > >> >values of these objects when sending them over the network via > > > >> >SNMP." That seems contradictory. It is therefore suggest to > > > >> >modify the fourth paragraph so that it reads as originally written > > > >> >in the standard security considerations template: > > > >> > > > > >> > It is RECOMMENDED that implementers consider the security features > > > >> > as provided by the SNMPv3 framework (see [RFC3410], section 8), > > > >> > including full support for the SNMPv3 cryptographic mechanisms (for > > > >> > authentication and privacy). > > > >> > > > > >> >7.) IANA Considerations Section -- OK (none present and none > > > >> >required). > > > >> > > > > >> >8.) Copyright notices -- the abbreviated copyright notices that are > > > >> >supposed to appear on the front page and in the DESCRIPTION clause > > > >> >of each MODULE-IDENTITY invocation are missing and need to be added. > > > >> >See http://www.ietf.org/ID-nits.html section 1.2, > > > >> > section 4.3, and > > > >> > section 3.8. > > > >> > > > > >> >9.) MIB compilation -- the following problems are reported > >by smilint: > > > >> > > > > >> >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > > > >> >has been processed to get the following results: > > > >> >smilint -m -s -l 6 -i namelength-32 ROHC-MIB > > > >> > > > > >> >ROHC-MIB:206: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:208: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:209: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:210: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:211: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:353: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:369: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:377: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:386: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:395: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:535: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:536: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:537: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:538: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:539: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:540: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:667: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:675: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:684: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:693: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:702: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:713: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-MIB:184: [5] {index-element-accessible} warning: index element > > > >> >`rohcInstanceType' of row `rohcInstanceEntry' should be > > > >> >not-accessible in SMIv2 MIB > > > >> > > > > >> >FIXES: > > > >> >(a) add Counter32 to the list of things imported from SNMPv2-SMI > > > >> >(b) change MAX-ACCESS value of rohcInstanceType to not-accessible > > > >> >(c) remove rohcInstanceType from rohcInstanceGroup > > > >> > > > > >> > > > > >> >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > > > >> >has been processed to get the following results: > > > >> >smilint -m -s -l 6 -i namelength-32 ROHC-UNCOMPRESSED-MIB > > > >> > > > > >> >ROHC-UNCOMPRESSED-MIB:73: [2] {basetype-not-imported} SMIv2 base > > > >> >type `Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-UNCOMPRESSED-MIB:107: [2] {basetype-not-imported} SMIv2 base > > > >> >type `Counter32' must be imported from SNMPv2-SMI > > > >> > > > > >> >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > > > >> > > > > >> > > > > >> >This command (smilint 0.4.2-pre1, as of Mon May 19 16:33:46 2003) > > > >> >has been processed to get the following results: > > > >> >smilint -m -s -l 6 -i namelength-32 ROHC-RTP-MIB > > > >> > > > > >> >ROHC-RTP-MIB:83: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:84: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:85: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:86: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:87: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:88: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:89: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:91: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:210: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:221: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:232: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:243: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:255: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:268: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:280: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> >ROHC-RTP-MIB:293: [2] {basetype-not-imported} SMIv2 base type > > > >> >`Counter32' must be imported from SNMPv2-SMI > > > >> > > > > >> >FIX: add Counter32 to the list of things imported from SNMPv2-SMI > > > >> > > > > >> >10.) Other issues, e.g., stuff in http://www.ietf.org/ID-nits.html > > > >> >that is not covered above: > > > >> > > > > >> >(a) there are several places in the MIB modules where the lines > > > >> >extend beyond column 72. Most (but not all) of these could be fixed > > > >> >by eliminating the three-space indentation. Althought the RFC > > > >> >Editor can probably do this, it will save time and reduce the > > > >> >proabability of formatting errors in the final RFC if the authors > > > >> >would fix it themselves. See ID-nits section 1.1. > > > >> > > > > >> >(b) in Section 1, "Introduction", please add "NOT RECOMMENDED" to > > > >> >the list of imperatives (although the standard boilerplate in RFC > > > >> >2119 does not include it, it is used in the Security Considerations > > > >> >section and it is defined in RFC 2119). > > > >> > > > > >> >(c) in Section 3, "Overview", 3rd paragraph: s/means/a means/ > > > >> > > > > >> >(d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/ > > > >> > > > > >> >(e) in Section 4, "Structure of the MIB modules", 1st paragraph: > > > >> >s/Section 6/Section 5/ > > > >> > > > > >> >(f) in Section 4, "Structure of the MIB modules", 2nd and 4th > > > >> >paragraphs: most acronyms must be expanded upon first use, > > > >> >except for those that everyone in the IETF can reasonably be > > > >> >expected to know. Note that this rule applies separately for > > > >> >the body of the memo and the abstract; see Sections 4.7 and 2.9 > > > >> >of or its successor document > > > >> >and review comment (2) above. > > > >> > > > > >> >(g) in Section 4.1, "The ROHC-MIB module", first paragraph: the > > > >> >tables are mentioned in a different order than they appear in the > > > >> >MIB module, which has rohcChannelTable before rohcInstanceTable. > > > >> >Similarly, the ordering of Sections 4.1.1 and 4.1.2 agree with > > > >> >the order in this paragraph but are "swapped" relative to the MIB > > > >> >module. It might be better if the order in the text matched that > > > >> >of the MIB module. > > > >> > > > > >> >(h) in Section 4.1, "The ROHC-MIB module", last paragraph: > > > >> >unexpanded acronym CID. > > > >> > > > > >> >(i) in Section 4.1.1, "rohcInstanceTable", 4th bullet: > > > >> >s/storagetime/storage time/ > > > >> > > > > >> >(j) in Section 4.1.4, "rohcContextTable", 3rd bullet, changed > > > >> >text from: > > > >> > > > > >> > o the state of the CID ('unused', 'active', 'expired', or > > > >> > > > > >> >to: > > > >> > > > > >> > o the state of the CID ('unused', 'active', 'expired', or > > > >> > 'terminated'. > > > >> > > > > >> >Note: a common cause of missing text in an I-D is a line in the > > > >> >nroff source that starts with a single quote as the first character > > > >> >of the line. > > > >> > > > > >> >11.) Technical content -- the following comments pertain to the > > > >> >material in Sections 3, 4, and 5. Please note that I am not an > > > >> >ROHC subject matter expert and so I do not have the knowledge to > > > >> >attempt a detailed verification that the MIB objects are indeed > > > >> >fit for the intended purposes. I'm presuming that the WG has > > > >> >already done that, so I've concentrated on MIB design issues. > > > >> >Issues already covered under (9) above won't be repeated here. > > > >> > > > > >> >(a) in Section 3, "Overview", next to last paragraph, it is stated > > > >> >that "the compressor context can be reinitialized." I didn't see > > > >> >any read-write or read-create objects in the MIB module that would > > > >> >support such a capability. If indeed there is no support for such > > > >> >a capability then the claim should be removed. > > > >> > > > > >> >(b) in Section 4.1.1, "rohcInstanceTable", and Section 4.1.3, > > > >> >"rohcProfileTable", and also in the corresponding definitions in > > > >> >the ROHC-MIB module in Section 5: it is not clear why one needs a > > > >> >vendor, version number, and implementation description in both of > > > >> >these tables. Indeed, except for the descriptors and OIDs that > > > >> >are assigned, the definitions of rohcInstanceVendor, > > > >> >rohcInstanceVersion, and rohcInstanceDescr are identical with those > > > >> >for rohcProfileVendor, rohcProfileVersion, and rohcProfileDescr > > > >> >(respectively). It seems to me that the objects rohcProfileVendor, > > > >> >rohcProfileVersion, and rohcProfileDescr could be eliminated without > > > >> >loss of capability. The designers may also wish to consider moving > > > >> >rohcInstanceVendor, rohcInstanceVersion, and rohcInstanceDescr into > > > >> >the rohcChannelTable or perhaps even turning them into scalars. > > > >> > > > > >> >(c) in Section 4.1.3, "rohcProfileTable", there is no mention of > > > >> >the per-profile Boolean flag that indicates whether the profile > > > >> >has been negotiated to be used at the instance. > > > >> > > > > >> >(d) in Section 5, all MIB modules: the MODULE-IDENTITY invocations > > > >> >need to be changed in the following ways: > > > >> > > > > >> > - WG mailing list info (and optionally, charter page URL) needs to > > > >> > be present in the CONTACT-INFO clause; > > > >> > > > > >> > - there needs to be a REVISION/DESCRIPTION clause pair with a date > > > >> > identical to that in the LAST-UPDATED clause and a description > > > >> > indicating that the module is the initial published version; > > > >> > > > > >> > - the DESCRIPTION clause needs to include an abbreviated copyright > > > >> > notice (per (8) above). > > > >> > > > > >> >See sections 3.8 and > > > >> >4.5 for more details. As an example, the ROHC-MIB MODULE-IDENTITY > > > >> >invocation could be changed from: > > > >> > > > > >> >rohcMIB MODULE-IDENTITY > > > >> > LAST-UPDATED "200209251358Z" > > > >> > ORGANIZATION "IETF Robust Header Compression Working Group" > > > >> > CONTACT-INFO > > > >> > "Juergen Quittek > > > >> > NEC Europe Ltd. > > > >> > Network Laboratories > > > >> > Kurfuersten-Anlage 34 > > > >> > 69221 Heidelberg > > > >> > Germany > > > >> > Tel: +49 6221 90511-15 > > > >> > E-mail: quittek@ccrle.nec.de" > > > >> > DESCRIPTION > > > >> > "This MIB module defines a set of basic objects for > > > >> > monitoring and configuring robust header compression. > > > >> > The module covers information about running instances > > > >> > of ROHC (compressors or decompressors) at IP interfaces. > > > >> > > > > >> > Information about compressor contexts and decompressor > > > >> > contexts has different structure for different profiles. > > > >> > Therefore it is not provided by this MIB module, but by > > > >> > individual modules for dofferent profiles." > > > >> > ::= { mib-2 XXX } > > > >> >-- XXX to be assigned by IANA. > > > >> > > > > >> >to something along the lines of: > > > >> > > > > >> >rohcMIB MODULE-IDENTITY > > > >> > LAST-UPDATED "200306250000Z" -- June 25, 2003 > > > >> > ORGANIZATION "IETF Robust Header Compression Working Group" > > > >> > CONTACT-INFO > > > >> > "WG charter: > > > >> > http://www.ietf.org/html.charters/rohc-charter.html > > > >> > > > > >> > Mailing Lists: > > > >> > General Discussion: rohc@ietf.org > > > >> > To Subscribe: rohc-request@ietf.org > > > >> > In Body: subscribe your_email_address > > > >> > > > > >> > Editor: > > > >> > Juergen Quittek > > > >> > NEC Europe Ltd. > > > >> > Network Laboratories > > > >> > Kurfuersten-Anlage 34 > > > >> > 69221 Heidelberg > > > >> > Germany > > > >> > Tel: +49 6221 90511-15 > > > >> > E-mail: quittek@ccrle.nec.de" > > > >> > DESCRIPTION > > > >> > "This MIB module defines a set of basic objects for > > > >> > monitoring and configuring robust header compression. > > > >> > The module covers information about running instances > > > >> > of ROHC (compressors or decompressors) at IP interfaces. > > > >> > > > > >> > Information about compressor contexts and decompressor > > > >> > contexts has different structure for different profiles. > > > >> > Therefore it is not provided by this MIB module, but by > > > >> > individual modules for different profiles. > > > >> > > > > >> > Copyright (C) The Internet Society (2003). This version > > > >> > of this MIB module is part of RFC yyyy; see the RFC > > > >> > itself for full legal notices." > > > >> >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > > >> > > > > >> > REVISION "200306250000Z" -- June 25, 2003 > > > >> > DESCRIPTION "Initial version, published as RFC yyyy." > > > >> >-- RFC Ed.: replace yyyy with actual RFC number & remove this notice > > > >> > > > > >> > ::= { mib-2 XXX } > > > >> >-- XXX to be assigned by IANA. > > > >> > > > > >> >with the dates changed as appropriate. [Note also a typo fix: > > > >> >s/dofferent/different/.] Similar changes apply to the other > > > >> >MIB modules. > > > >> > > > > >> >(e) in Section 5, all MIB modules: the ordering of the index > > > >> >components is not consistent throughout. Specifically, although > > > >> >all tables are indexed by ifIndex and rohcChannelID, the tables > > > >> >without rohcInstanceType as an index component all have > > > >> >{ ifIndex, rohcChannelID, ... } as a common prefix, while those > > > >> >with rohcInstanceType do not: their common prefix is > > > >> >{ ifIndex, rohcInstanceType, rohcChannelID, ... }. While this > > > >> >will certainly work, and may be legitimate if one wishes to have a > > > >> >different sort order in different tables, the MIB designers should > > > >> >be aware that it tends to make the implementation harder than it > > > >> >otherwise would be, because there is less indexing code that can > > > >> >be shared between different tables. Unless there was a specific > > > >> >reason for choosing the specific index order that is in the draft, > > > >> >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. > > > >> > > > > >> >(f) in Section 5, all MIB modules: none of the Counter32 objects > > > >> >has a discontinuity time indicator. Such an indicator is required > > > >> >if events other than a reboot may result in a discontinuity (i.e., > > > >> >non-monotonic counting behaviour); see the first bullet of Section > > > >> >4.6.1.2 of . Since > > > >> >each counter is associated with a specific interface, a good > > > >> >solution in this case is to use IF-MIB's ifCounterDiscontinuityTime > > > >> >for this purpose, as is done in the EtherLike-MIB (RFC 2665), > > > >> >the MAU-MIB (RFC 2668), or the DIFFSERV-MIB (RFC 3289). That > > > >> >would mean adding the following or similar text > > > >> > > > > >> > Discontinuities in the value of this counter can > > > >> > occur at re-initialization of the management > > > >> > system, and at other times as indicated by the > > > >> > value of ifCounterDiscontinuityTime. > > > >> > > > > >> >to the DESCRIPTION clause of each of the Counter32 objects. > > > >> > > > > >> >(g) in Section 5, all MIB modules: it is observed that many objects > > > >> >are defined with SYNTAX values of of Integer32 (0..2147483647), > > > >> >Integer32 (1..2147483647), and Integer32 (0..1000). While this is > > > >> >certainly acceptable, it is brought to the authors' attention that > > > >> >Unsigned32 is preferred when the range of values is non-negative; > > > >> >see Section 4.6.1.1. > > > >> >Changes, if any, are left to the authors' discretion. (Note: > > > >> >current usage is consistent for all objects; if a change is made, > > > >> >please be sure to do so everywhere; but see 11(m) first.) > > > >> > > > > >> >/********** The following comments apply to the ROHC-MIB **********/ > > > >> > > > > >> >(h) In the DESCRIPTION clause of rohcChannelID it says: > > > >> > > > > >> > The value is expected to remain constant at least from one > > > >> > re-initialization of the entity's network management system > > > >> > to the next re-initialization. > > > >> > > > > >> >I know that this same language is used in the IF-MIB, but it turns > > > >> >out that indices that don't remain fixed across reboots can lead > > > >> >to problems. See the thread "Referential integrity across reboots" > > > >> >at this URL: http://ops.ietf.org/lists/mibs/mibs.2002/#00140 > > > >> >Suggested remedy: change the above text to: > > > >> > > > > >> > 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. > > > >> > > > > >> >(i) In the DESCRIPTION clause of rohcChannelFeedbackFor: > > > >> >s/feddback/feedback/ > > > >> > > > > >> >(j) In the following object definition it is not specified what > > > >> >value the object should assume if there is no feedback channel: > > > >> > > > > >> >rohcInstanceFBChannelID OBJECT-TYPE > > > >> > SYNTAX RohcChannelIdentifier > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "Identifier of the channel used for feedback." > > > >> > ::= { rohcInstanceEntry 4 } > > > >> > > > > >> >Shouldn't the DESCRIPTION clause state that the value 0 is used in > > > >> >that case? It would seem to be consistent with the instructions in > > > >> >the RohcChannelIdentifier DESCRIPTION clause to do this. > > > >> > > > > >> >(k) In the following object definition: > > > >> > > > > >> > rohcInstanceMRRU OBJECT-TYPE > > > >> > SYNTAX Integer32 (1..2147483647) > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "Maximum reconstructed reception unit. This is the > > > >> > size of the largest reconstructed unit in octets that > > > >> > the decompressor is expected to reassemble from > > > >> > segments (see RFC 3095, Section 5.2.5). Note that this > > > >> > size includes the CRC. If MRRU is negotiated to be 0, > > > >> > no segment headers are allowed on the channel." > > > >> > REFERENCE > > > >> > "RFC 3095, Section 5.1.1" > > > >> > ::= { rohcInstanceEntry 11 } > > > >> > > > > >> >the SYNTAX value and the DESCRIPTION clause are at odds. > > > >> > > > > >> >FIX: change the SYNTAX value to Integer32 (0..2147483647) > > > >> > > > > >> >(l) In the following object definition: > > > >> > > > > >> >rohcInstanceContextsCurrent OBJECT-TYPE > > > >> > SYNTAX Integer32 > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "Number of currently active contexts created by > >this instance." > > > >> > ::= { rohcInstanceEntry 15 } > > > >> > > > > >> >a more appropriate SYNTAX value would be Integer32 (0..2147483647) > > > >> >since the number of contexts cannot possibly be negative. > > > >> > > > > >> >(m) In the following object definition: > > > >> > > > > >> >rohcInstanceCompressionRatio OBJECT-TYPE > > > >> > SYNTAX Integer32 (0..1000) > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "This object indicates the compression ratio so far over all > > > >> > packets on the channel served by this instance. > >The value is > > > >> > defined as 1000 * bytes(compressed) / > >bytes(original) rounded > > > >> > to the next integer value. The number of bytes corresponds > > > >> > to all bytes of all IP packets including the IP header but > > > >> > excluding all lower layer headers." > > > >> > ::= { rohcInstanceEntry 20 } > > > >> > > > > >> >Is it theoretically possible for the compression ratio to > >exceed unity > > > >> >in certain unfavorable cases? If so, then the range needs to be > > > >> >changed to allow for that, or the DESCRIPTION clause needs to state > > > >> >that the value is set to 1000 if the actual compression > >ratio exceeds > > > >> >unity. In the latter case a more appropriate SYNTAX value would be > > > >> >Gauge32 (0..1000) (see > > > >> >Section 4.6.1.1). NOTE: THIS COMMENT APPLIES TO ALL COMPRESSION > > > >> >RATIO OBJECTS. > > > >> > > > > >> >(n) I'm not sure if I properly understood the DESCRIPTION clause of > > > >> >the following object: > > > >> > > > > >> >rohcProfileNegotiated OBJECT-TYPE > > > >> > SYNTAX TruthValue > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "When retrieved, this boolean object returns true > > > >> > if the profile has been negotiated to be used at > > > >> > the instance, i.e. is supported also by the > > > >> > corresponding compressor/decompressor." > > > >> > ::= { rohcProfileEntry 7 } > > > >> > > > > >> >My understanding is that an instance of this object corresponding to > > > >> >a particular triple should > > > >> >have the value true(1) if and only if at least one context with the > > > >> >same values is using that profile -- in > > > >> >other words, if and only if some instance of rohcContextProfile for > > > >> >the same values is equal to the rohcProfile > > > >> >value. If this understanding is _not_ correct, then clarification > > > >> >of the DESCRIPTION clause would be in order. > > > >> > > > > >> >(o) Several DESCRIPTION clauses in the ROHC-MIB refer to the > > > >> >non-existent object rohcContextType. They should refer instead to > > > >> >rohcInstanceType. The objects in question are: > > > >> > > > > >> >rohcContextDecompressorDepth > > > >> >rohcContextDecompressorFailures > > > >> >rohcContextDecompressorRepairs > > > >> > > > > >> >(p) In the following object definition [n.b. the above correction > > > >> >has been assumed to be applied]: > > > >> > > > > >> >rohcContextDecompressorDepth OBJECT-TYPE > > > >> > SYNTAX Integer32 (0..2147483647) > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "This object indicates whether reverse decompression, for > > > >> > example as described in RFC 3095, Section 6.1, is used > > > >> > on this channel or not, and if used, to what extent. > > > >> > > > > >> > Its value is only valid for decompressor contexts, i.e. > > > >> > if rohcInstanceType has the value decompressor(2). > > > >> > > > > >> > The value of the reverse decompression depth indicates > > > >> > the maximum number of packets that are buffered, and thus > > > >> > possibly be reverse decompressed by the decompressor. > > > >> > A zero (0) value means that reverse decompression is not > > > >> > used." > > > >> > ::= { rohcContextEntry 7 } > > > >> > > > > >> >it is not clear whether this object should have the value 0 for > > > >> >compressor contexts, or whether it should not be instantiated at > > > >> >all for such contexts. > > > >> > > > > >> >(q) The rohcCompliance DESCRIPTION clause should mention that the > > > >> >ROHC-MIB requires the IF-MIB as a prerequisite. See Section 4.8 of > > > >> >, last paragraph > > > >> >before end note. Examples may be found in the dot3Compliance2 > > > >> >statement in , the > > > >> >mauModIfCompl3 statement in , > > > >> >or the etherWisCompliance in > > > >> >(although it is requested that the embedded citations be avoided). > > > >> > > > > >> >/*** The following comment applies to the ROHC-UNCOMPRESSED-MIB ***/ > > > >> > > > > >> >(r) The rohcUncmprCompliance DESCRIPTION clause should mention that > > > >> >the ROHC-UNCOMPRESSED-MIB requires the ROHC-MIB and the IF-MIB as > > > >> >prerequisites. See 11(q) above for examples. > > > >> > > > > >> >/******** The following comments apply to the ROHC-RTP-MIB ********/ > > > >> > > > > >> >(s) The DESCRIPTION clauses of several columnar objects in the > > > >> >rohcRtpContextTable state that those objects are valid only for > > > >> >certain profiles or for certain contexts. The objects in question > > > >> >are: > > > >> > > > > >> >rohcRtpContextAlwaysPad > > > >> >rohcRtpContextLargePktsAllowed > > > >> >rohcRtpContextVerifyPeriod > > > >> >rohcRtpContextSizesAllowed > > > >> >rohcRtpContextSizesUsed > > > >> > > > > >> >If the intent is that those objects are to be instantiated only for > > > >> >the profiles or contexts to which they apply, then that fact should > > > >> >be made explicit in the DESCRIPTION clauses. > > > >> > > > > >> >(t) The DESCRIPTION clauses of rohcRtpContextSizesAllowed and > > > >> >rohcRtpContextSizesUsed both appear to have the same three > > > >> >typographical errors: > > > >> > > > > >> > rohcRtpContextSizesAllowed OBJECT-TYPE > > > >> > SYNTAX Integer32 (1..2147483647) > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "The value of this object is only valid for decompressor > > > >> > contexts, i.e. if rohcContextType of the cooresponding > > > >> > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > > > >> > rohcContextEntry has the value compressor(2). > > > >> > ^^^^^^^^^^^^^ > > > >> > > > > >> > This object contains the number of different packet sizes > > > >> > that may be used in the context." > > > >> > REFERENCE > > > >> > "RFC 3095, Section 6.3.1" > > > >> > ::= { rohcRtpContextEntry 10 } > > > >> > > > > >> > rohcRtpContextSizesUsed OBJECT-TYPE > > > >> > SYNTAX Integer32 (1..2147483647) > > > >> > MAX-ACCESS read-only > > > >> > STATUS current > > > >> > DESCRIPTION > > > >> > "The value of this object is only valid for decompressor > > > >> > contexts, i.e. if rohcContextType of the cooresponding > > > >> > ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ > > > >> > rohcContextEntry has the value compressor(2). > > > >> > ^^^^^^^^^^^^^ > > > >> > > > > >> > This object contains the number of different > >packet sizes > > > >> > that are used in the context." > > > >> > REFERENCE > > > >> > "RFC 3095, Section 6.3.1" > > > >> > ::= { rohcRtpContextEntry 11 } > > > >> > > > > >> >Suggested fixes: s/rohcContextType/rohcInstanceType/ > > > >> > s/cooresponding/corresponding/ > > > >> > s/compressor(2)/decompressor(2)/ > > > >> > > > > >> >(u) There are some design issues with the rohcRtpPacketSizeTable: > > > >> > > > > >> >- the index column rohcRtpPacketSize with has values in the range > > > >> >0..2147483647. In fact RFC 3095 Section 6.3.1 stipulates that > > > >> >PACKET_SIZES_ALLOWED and PACKET_SIZES_USED must be positive > > > >> >integers, i.e., the value 0 is excluded as it does not make sense. > > > >> >FIX: change the range to 1..2147483647. (This also avoids > > > >> >running afoul of the SMIv2 rule that index values of zero should > > > >> >be avoided, except in special cases.) > > > >> > > > > >> >- the TruthValue column rohcRtpPacketSizeAllowed seems to be > > > >> >unnecessary. Given that RFC 3095 Section 6.3.1 stipulates that > > > >> >"packet sizes not in the set of values for [PACKET_SIZES_ALLOWED] > > > >> >MUST NOT be used", it seems that an agent would never need to > > > >> >instantiate any of the other columns if rohcRtpPacketSizeAllowed > > > >> >had the value false(2). In other words, any row for which this > > > >> >objects is false should simply be absent from the table. > > > >> > > > > >> >(v) The rohcRtpCompliance DESCRIPTION clause should mention that > > > >> >the ROHC-RTP-MIB requires the ROHC-MIB and the IF-MIB as > > > >> >prerequisites. See 11(q) above for examples. > > > >> > > > > >> >This concludes the review of . > > > >> > > > > >> >Regards, > > > >> > > > > >> >Mike Heard > > > >> > > > > >> > > > > >> >_______________________________________________ > > > >> >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 > > > >> > > > >-- > >Qoe > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. > > -- t; &g! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jul 11 06:20:30 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 GAA23938 for ; Fri, 11 Jul 2003 06:20: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 19av0W-0003ba-9F for rohc-archive@odin.ietf.org; Fri, 11 Jul 2003 06:20:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BAK4mX013834 for rohc-archive@odin.ietf.org; Fri, 11 Jul 2003 06:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19av0V-0003az-O5 for rohc-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 06:20: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 GAA23922 for ; Fri, 11 Jul 2003 06:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19av0R-0004Qh-00 for rohc-web-archive@ietf.org; Fri, 11 Jul 2003 06:19:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19av0R-0004Qe-00 for rohc-web-archive@ietf.org; Fri, 11 Jul 2003 06:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19av0T-0003aJ-6W; Fri, 11 Jul 2003 06:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19av0D-0003WF-9W for rohc@optimus.ietf.org; Fri, 11 Jul 2003 06:19: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 GAA23889 for ; Fri, 11 Jul 2003 06:19:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19av09-0004Pb-00 for rohc@ietf.org; Fri, 11 Jul 2003 06:19:41 -0400 Received: from web20504.mail.yahoo.com ([216.136.226.139]) by ietf-mx with smtp (Exim 4.12) id 19av08-0004PT-00 for rohc@ietf.org; Fri, 11 Jul 2003 06:19:41 -0400 Message-ID: <20030711101937.39197.qmail@web20504.mail.yahoo.com> Received: from [202.134.200.4] by web20504.mail.yahoo.com via HTTP; Fri, 11 Jul 2003 03:19:37 PDT Date: Fri, 11 Jul 2003 03:19:37 -0700 (PDT) From: abc abc To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [rohc] GRE checksum doubt 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Optional GRE checksum field is shown twice based on presence of GRE Flag C.Also no reference to inner and outer GRE Header is present in corresponding section. It seems this creates slight ambiguity in ROHC RFC as to whether 1) GRE checksum for GRE Header is to be included twice(Though it does look improbable). 2) When inner and outer GRE Headers are present , first GRE checksum refers to outer GRE Header and second GRE checksum refers to inner GRE Header. Any clarifications on the above are welcome. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jul 11 12:34: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 MAA05203 for ; Fri, 11 Jul 2003 12:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0qV-0000E7-8l for rohc-archive@odin.ietf.org; Fri, 11 Jul 2003 12:34:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BGY7Oj000861 for rohc-archive@odin.ietf.org; Fri, 11 Jul 2003 12:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0qV-0000Do-44 for rohc-web-archive@optimus.ietf.org; Fri, 11 Jul 2003 12:34: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 MAA05199 for ; Fri, 11 Jul 2003 12:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0qT-0006yU-00 for rohc-web-archive@ietf.org; Fri, 11 Jul 2003 12:34:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19b0qT-0006yQ-00 for rohc-web-archive@ietf.org; Fri, 11 Jul 2003 12:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0qO-0000DT-Gc; Fri, 11 Jul 2003 12:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b0q9-0000DE-Lj for rohc@optimus.ietf.org; Fri, 11 Jul 2003 12:33: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 MAA05194 for ; Fri, 11 Jul 2003 12:33:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b0q8-0006yM-00 for rohc@ietf.org; Fri, 11 Jul 2003 12:33:44 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19b0q7-0006yJ-00 for rohc@ietf.org; Fri, 11 Jul 2003 12:33:43 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6BGXgIi006749; Fri, 11 Jul 2003 18:33:42 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 11 Jul 2003 18:33:42 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: abc abc , rohc@ietf.org Subject: RE: [rohc] GRE checksum doubt Date: Fri, 11 Jul 2003 18:33:36 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , It might be a good idea to check the ROHC archive. /L-E > -----Original Message----- > From: abc abc [mailto:rohc_doubts@yahoo.com] > Sent: den 11 juli 2003 12:20 > To: rohc@ietf.org > Subject: [rohc] GRE checksum doubt > > > > Optional GRE checksum field is shown twice based on > presence of GRE Flag C.Also no reference to inner and > outer GRE Header is present in corresponding section. > > It seems this creates slight ambiguity in ROHC RFC as > to whether > 1) GRE checksum for GRE Header is to be included > twice(Though it does look improbable). > 2) When inner and outer GRE Headers are present , > first GRE checksum refers to outer GRE Header and > second GRE checksum refers to inner GRE Header. > > Any clarifications on the above are welcome. > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > _______________________________________________ > 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 Mon Jul 14 06:59: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 GAA07774 for ; Mon, 14 Jul 2003 06:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c12u-0005q3-ET for rohc-archive@odin.ietf.org; Mon, 14 Jul 2003 06:59:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EAx4hQ022439 for rohc-archive@odin.ietf.org; Mon, 14 Jul 2003 06:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c12u-0005pq-9O for rohc-web-archive@optimus.ietf.org; Mon, 14 Jul 2003 06:59: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 GAA07743 for ; Mon, 14 Jul 2003 06:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c12q-0004UW-00 for rohc-web-archive@ietf.org; Mon, 14 Jul 2003 06:59:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19c12p-0004US-00 for rohc-web-archive@ietf.org; Mon, 14 Jul 2003 06: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 19c12r-0005ox-Df; Mon, 14 Jul 2003 06:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c12j-0005oD-UP for rohc@optimus.ietf.org; Mon, 14 Jul 2003 06:58:53 -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 GAA07727; Mon, 14 Jul 2003 06:58:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c12f-0004Tw-00; Mon, 14 Jul 2003 06:58:49 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19c12e-0004Tm-00; Mon, 14 Jul 2003 06:58:48 -0400 Received: from tzi.org (nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h6EAwd6X003905; Mon, 14 Jul 2003 12:58:39 +0200 (MEST) Date: Mon, 14 Jul 2003 12:58:33 +0200 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann , agenda@ietf.org To: rohc@ietf.org From: Carsten Bormann Content-Transfer-Encoding: 7bit Message-Id: <1C8F7F70-B5EA-11D7-A370-00039390397C@tzi.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [rohc] Agenda for Tuesday meeting 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ROHCers, attached please find the agenda for the Tuesday ROHC meeting. Please advise of any omissions or errors. See you tomorrow! Gruesse, Carsten Robust Header Compression WG (rohc) Tuesday, July 15 at 1415-1515 and 1545-1645 =========================================== CHAIRS: Carsten Bormann Lars-Erik Jonsson AGENDA: Chair admonishments and agenda bashing (Bormann) 5 - NOTE: It is assumed that people have read all drafts Formal header compression notation 55 * Documents: draft-ietf-rohc-formal-notation-01.txt http://www.dmn.tzi.org/ietf/rohc/draft-ozegovic-rohc-fn-requirements- 0pre.txt http://www.dmn.tzi.org/ietf/rohc/draft-ozegovic-rohc-fn-rtp-0pre.txt [break; we expect to have an AD present after the break] WG status update (Bormann) 5 MIB doctor review issues (Quittek) 10 draft-ietf-rohc-mib-rtp-06.txt draft-ietf-rohc-terminology-and-examples-02.txt (MIB doctor review discussion on mailing list) ROHC RTP (Bormann) 10 * Documents: draft-ietf-rohc-rtp-impl-guide-03.txt draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt draft-ietf-rohc-ip-only-02.txt draft-ietf-rohc-udp-lite-00.txt - Implementer's Guide (0) - Implementation status & feature test list (0) - A ROHC profile for IP only (5) - ROHC profiles for UDP-Lite (5) Signaling compression 10 * Documents: draft-roach-sigcomp-nack-01.txt draft-ietf-rohc-sigcomp-user-guide-00.txt draft-ietf-rohc-sigcomp-impl-guide-01.txt draft-ietf-rohc-sigcomp-sip-00.txt draft-price-rohc-sigcomp-torture-tests-02.txt - Document status (Bormann) (10) ROHC TCP 25 * Documents: draft-ietf-rohc-tcp-requirements-06.txt draft-ietf-rohc-tcp-field-behavior-02.txt draft-ietf-rohc-tcp-04.txt draft-ietf-rohc-tcp-enhancement-01.txt draft-ietf-rohc-context-replication-00.txt draft-price-rohc-tcp-packet-formats-00.txt - Context replication (Pelletier) (5) - TCP issues (West) (20) ================================ DRAFT SUMMARY: Approved for publication: None! Submitted to IESG: RFW/RTP: draft-ietf-rohc-mib-rtp-06.txt RFW/RTP: draft-ietf-rohc-terminology-and-examples-02.txt Current WG drafts: RTP: draft-ietf-rohc-rtp-impl-guide-03.txt RTP: draft-ietf-rohc-rtp-rfc3095-interoperability-02.txt RTP: draft-ietf-rohc-ip-only-02.txt RTP: draft-ietf-rohc-udp-lite-00.txt SIG: draft-ietf-rohc-sigcomp-user-guide-00.txt SIG: draft-ietf-rohc-sigcomp-impl-guide-01.txt SIG: draft-ietf-rohc-sigcomp-sip-00.txt TCP: draft-ietf-rohc-tcp-requirements-06.txt (not on agenda) TCP: draft-ietf-rohc-tcp-field-behavior-02.txt (not on agenda) TCP: draft-ietf-rohc-tcp-04.txt (not on agenda) TCP: draft-ietf-rohc-tcp-enhancement-01.txt (not on agenda) SCP: draft-ietf-rohc-sctp-requirements-02.txt NOT: draft-ietf-rohc-formal-notation-01.txt TCP: draft-ietf-rohc-context-replication-00.txt Individual submissions: SIG: draft-price-rohc-sigcomp-torture-tests-02.txt SIG: draft-roach-sigcomp-nack-01.txt NOT: draft-ozegovic-mornar-dccp-epic-00.txt TCP: draft-price-rohc-tcp-packet-formats-00.txt Late submissions: NOT: http://www.dmn.tzi.org/ietf/rohc/draft-ozegovic-rohc-fn-requirements- 0pre.txt NOT: http://www.dmn.tzi.org/ietf/rohc/draft-ozegovic-rohc-fn-rtp-0pre.txt Legend: RFW: ROHC Framework RTP: ROHC RTP, including IP, UDP, ESP, etc SIG: ROHC Signaling Compression NOT: Compression notation TCP: ROHC TCP SCP: ROHC SCTP _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 16 07:06:49 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 HAA25334 for ; Wed, 16 Jul 2003 07:06:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ck76-00025X-Nw for rohc-archive@odin.ietf.org; Wed, 16 Jul 2003 07:06:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GB6Ofg008013 for rohc-archive@odin.ietf.org; Wed, 16 Jul 2003 07:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ck76-00024s-Jj for rohc-web-archive@optimus.ietf.org; Wed, 16 Jul 2003 07:06:24 -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 HAA25328 for ; Wed, 16 Jul 2003 07:06:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ck72-0005tm-00 for rohc-web-archive@ietf.org; Wed, 16 Jul 2003 07:06:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ck6w-0005tc-00 for rohc-web-archive@ietf.org; Wed, 16 Jul 2003 07:06:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ck6j-00021j-Fg; Wed, 16 Jul 2003 07: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 19ck6T-00021G-JO for rohc@optimus.ietf.org; Wed, 16 Jul 2003 07:05: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 HAA25314; Wed, 16 Jul 2003 07:05:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ck5Q-0005tF-00; Wed, 16 Jul 2003 07:04:40 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ck5F-0005t8-00; Wed, 16 Jul 2003 07:04:29 -0400 Received: from tzi.org (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h6GB38hX019089; Wed, 16 Jul 2003 13:03:08 +0200 (MEST) Date: Wed, 16 Jul 2003 13:03:04 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Carsten Bormann To: rohc@ietf.org From: Carsten Bormann Content-Transfer-Encoding: 7bit Message-Id: <12B3CCF4-B77D-11D7-B4D9-00039390397C@tzi.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [rohc] ROHC-57 slides 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The slides that were used during the ROHC WG meeting at IETF 57 are now at the secondary ROHC web site http://www.dmn.tzi.org/ietf/rohc or directly http://www.dmn.tzi.org/ietf/rohc/rohc-57.pdf BTW, I took the liberty to remove some exuberant background pictures to keep the file size below 1 MByte. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 17 04:10:37 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 EAA22194 for ; Thu, 17 Jul 2003 04:10:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3q5-0003Me-Vr for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 04:10:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H8A9BK012927 for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 04:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3q4-0003MQ-S6 for rohc-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 04:10: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 EAA22179 for ; Thu, 17 Jul 2003 04:10:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3q2-0002mM-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 04:10:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d3pw-0002mJ-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 04:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3py-0003M3-70; Thu, 17 Jul 2003 04:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d3oz-0003K6-Q8 for rohc@optimus.ietf.org; Thu, 17 Jul 2003 04:09: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 EAA22125 for ; Thu, 17 Jul 2003 04:08:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d3ow-0002kG-00 for rohc@ietf.org; Thu, 17 Jul 2003 04:08:58 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19d3oh-0002j2-00 for rohc@ietf.org; Thu, 17 Jul 2003 04:08:47 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1QH7>; Thu, 17 Jul 2003 09:07:52 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1PG6; Thu, 17 Jul 2003 09:07:51 +0100 From: "West, Mark" To: rohc@ietf.org Date: Thu, 17 Jul 2003 09:08:17 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] Verifying decompression in ROHC-TCP 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, The good ol' IPR issue is looming over rohc TCP, even as I type..! Specifically, this relates to the use of a CRC to verify correct decompression (a la RFC 3095). [note that we are only talking about verifying decompression -- we are not considering 'context repair' (in 3095-speak)] So, we appear to have (at least) 3 choices, which I document here to see if anyone wants to discuss it... please..! 1/ try and do something very close to the 3095 approach, but avoid infriging the claimed IPR. A proposal along these lines could be to CRC the *context*. (This means some header fields are not included and some meta-data is included). It has essentially the same strength as the ROHC RTP scheme. The biggest disadvantage is that this requires us to define the CRC over the context (i.e. some format for the context), which is somewhat unpleasant. 1a/ a slight modification of the above, in which we only CRC the context fields that are updated by the packet. So, we are trying to protect the mapping between the compressed and uncompressed representations. It has (most of) the same properties of scheme 1. It should be possible to specify this in a way that is slightly less onerous to compute... 2/ do it just like 1144/2507, i.e. rely solely upon the TCP checksum. There are many problems with this, which include: - known weaknesses of the TCP checksum - issues with the changes that are signalled by deltas in 1144/2507 - lack of coverage of much of the IP header (and, worse, IPv6 extension headers) - coverage includes the payload, which may be large and which (for compression) we don't care about Although we *could* do it this way, it is one of the things that we really wanted to fix in ROHC-TCP. 3/ do something weird... for example: use the TCP checksum to verify correct decompression (as per 1144/2507), acknowledging that this has a number of weaknesses. However, in addtion, we make use of the Master Sequence Number (MSN) to add some extra protection. Define the MSN to be (say) a 32-bit value. Send a small number of LSBs of this in each packet. Also send a small checksum calculated over the MSN + the *compressed* packet. At the decompressor, decode the MSN and verify the checksum. [I assume that we have specified how robust we want ROHC-TCP to be (e.g. to 3 consecutive packet losses)] If the MSN doesn't verify, we call decompression failure. If it *does* verify, then we check it: if it's within the robustness bounds, we attempt decompression (we believe that we have a valid compressed packet for which decompression will work). Otherwise, we call decompression failure. Only if we attempt decompression (and believe that it will succeed) do we use the TCP checksum to finally verify decompression. This still has most of the weaknesses of 1144/2507, but we *aren't* using the checksum blindly to verify arbitrary decompression attempts. Maybe this makes things better? Another small point to note is that the decompression methods of ROHC *might* (and I haven't thought this through fully) be less vulnerable to the 1144/2507 delta encoding with regard to exposing weaknesses in the TCP/IP checksum. 4/ random aside: is a message digest the same thing as a checksum..? ;-) Comments welcome... Cheers, Mark. -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 17 05:14: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 FAA24767 for ; Thu, 17 Jul 2003 05:14:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4q0-0000T0-26 for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 05:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9E8tq001790 for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 05:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4pz-0000Sn-VD for rohc-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:14: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 FAA24764 for ; Thu, 17 Jul 2003 05:14:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4pw-0003b0-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 05:14:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4pr-0003ax-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 05:13:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4pt-0000RM-D6; Thu, 17 Jul 2003 05: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 19d4p0-0000Jw-UF for rohc@optimus.ietf.org; Thu, 17 Jul 2003 05:13: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 FAA24693 for ; Thu, 17 Jul 2003 05:13:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4ox-0003aT-00 for rohc@ietf.org; Thu, 17 Jul 2003 05:13:03 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19d4on-0003Zi-00 for rohc@ietf.org; Thu, 17 Jul 2003 05:12:53 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6H9AjIi018101; Thu, 17 Jul 2003 11:10:45 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 17 Jul 2003 11:10:45 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "West, Mark" , rohc@ietf.org Subject: RE: [rohc] Verifying decompression in ROHC-TCP Date: Thu, 17 Jul 2003 11:10:37 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Some general questions/observations: 1) Do we believe there is relevant IPR on the CRC approach from 3095? 2) Do we believe that this is the only 3095-IPR we should be "afraid" of? Finding out how to tackle the situation is the next step after answering yes to the two questions above. /L-E > -----Original Message----- > From: West, Mark [mailto:mark.a.west@roke.co.uk] > Sent: den 17 juli 2003 11:08 > To: rohc@ietf.org > Subject: [rohc] Verifying decompression in ROHC-TCP > > > > Hi all, > > The good ol' IPR issue is looming over rohc TCP, even as I type..! > Specifically, this relates to the use of a CRC to verify correct > decompression (a la RFC 3095). > > [note that we are only talking about verifying decompression > -- we are not > considering 'context repair' (in 3095-speak)] > > So, we appear to have (at least) 3 choices, which I document > here to see > if anyone wants to discuss it... please..! > > 1/ try and do something very close to the 3095 approach, but avoid > infriging the claimed IPR. A proposal along these lines > could be to CRC > the *context*. (This means some header fields are not > included and some > meta-data is included). It has essentially the same strength > as the ROHC > RTP scheme. The biggest disadvantage is that this requires > us to define > the CRC over the context (i.e. some format for the context), which is > somewhat unpleasant. > > 1a/ a slight modification of the above, in which we only CRC > the context > fields that are updated by the packet. So, we are trying to > protect the > mapping between the compressed and uncompressed > representations. It has > (most of) the same properties of scheme 1. It should be possible to > specify this in a way that is slightly less onerous to compute... > > 2/ do it just like 1144/2507, i.e. rely solely upon the TCP checksum. > There are many problems with this, which include: > - known weaknesses of the TCP checksum > - issues with the changes that are signalled by deltas in 1144/2507 > - lack of coverage of much of the IP header > (and, worse, IPv6 extension headers) > - coverage includes the payload, which may be large and which (for > compression) we don't care about > Although we *could* do it this way, it is one of the things > that we really > wanted to fix in ROHC-TCP. > > 3/ do something weird... for example: use the TCP checksum to verify > correct decompression (as per 1144/2507), acknowledging that > this has a > number of weaknesses. However, in addtion, we make use of the Master > Sequence Number (MSN) to add some extra protection. > > Define the MSN to be (say) a 32-bit value. Send a small > number of LSBs of > this in each packet. Also send a small checksum calculated > over the MSN + > the *compressed* packet. At the decompressor, decode the MSN > and verify > the checksum. [I assume that we have specified how robust we want > ROHC-TCP to be (e.g. to 3 consecutive packet losses)] > > If the MSN doesn't verify, we call decompression failure. If > it *does* > verify, then we check it: if it's within the robustness > bounds, we attempt > decompression (we believe that we have a valid compressed > packet for which > decompression will work). > Otherwise, we call decompression failure. Only if we attempt > decompression (and believe that it will succeed) do we use the TCP > checksum to finally verify decompression. > > This still has most of the weaknesses of 1144/2507, but we > *aren't* using > the checksum blindly to verify arbitrary decompression > attempts. Maybe > this makes things better? > > Another small point to note is that the decompression methods of ROHC > *might* (and I haven't thought this through fully) be less > vulnerable to > the 1144/2507 delta encoding with regard to exposing weaknesses in the > TCP/IP checksum. > > 4/ random aside: is a message digest the same thing as a > checksum..? ;-) > > Comments welcome... > > Cheers, > > Mark. > > -- > Mark A. West, Consultant Engineer > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > _______________________________________________ > 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 Jul 17 05:24: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 FAA25706 for ; Thu, 17 Jul 2003 05:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4zg-0001Hm-24 for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 05:24:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6H9O8Lu004938 for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 05:24:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4zf-0001HZ-UG for rohc-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 05:24: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 FAA25692 for ; Thu, 17 Jul 2003 05:24:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4zc-0003lo-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 05:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d4zX-0003ll-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 05:23:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d4zY-0001FE-RY; Thu, 17 Jul 2003 05: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 19d4yc-0001C5-LS for rohc@optimus.ietf.org; Thu, 17 Jul 2003 05:23: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 FAA25648 for ; Thu, 17 Jul 2003 05:22:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d4yZ-0003l2-00 for rohc@ietf.org; Thu, 17 Jul 2003 05:22:59 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19d4yO-0003ix-00 for rohc@ietf.org; Thu, 17 Jul 2003 05:22:48 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1QY1>; Thu, 17 Jul 2003 10:20:52 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1PKS; Thu, 17 Jul 2003 10:20:46 +0100 From: "West, Mark" To: "Lars-Erik Jonsson (LU/EAB)" Cc: rohc@ietf.org Date: Thu, 17 Jul 2003 10:21:13 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: RE: [rohc] Verifying decompression in ROHC-TCP In-Reply-To: Message-ID: 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Lars-Erik, In respect of 1, perhaps someone can clarify the status of patent WO0079763 / CA2375830 "Robust Header Compression in Packet Communications"..? (I believe that at least one of the authors regularly reads this list ;-) In respect of 2, this is a good question. The CRC issue appears, to me, to be 'clear and present'. As to others, we've had no indication of problmes so far, but... So, I'll go for a 'yes' and a 'maybe' ;-) Mark. -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 On Thu, 17 Jul 2003, Lars-Erik Jonsson (LU/EAB) wrote: > Date: Thu, 17 Jul 2003 11:10:37 +0200 > From: "Lars-Erik Jonsson (LU/EAB)" > To: "West, Mark" , rohc@ietf.org > Subject: RE: [rohc] Verifying decompression in ROHC-TCP > > Some general questions/observations: > > 1) Do we believe there is relevant IPR on the CRC approach from 3095? > > 2) Do we believe that this is the only 3095-IPR we should be "afraid" of? > > > Finding out how to tackle the situation is the next step after answering yes to the two questions above. > > /L-E > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 17 06:55: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 GAA29354 for ; Thu, 17 Jul 2003 06:55:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6Pl-0007lV-3B for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 06:55:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HAt9Gf029826 for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 06:55:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6Pk-0007kO-VF for rohc-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 06:55: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 GAA29333 for ; Thu, 17 Jul 2003 06:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6Pg-0004f2-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 06:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d6Pa-0004ez-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 06:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6Pd-0007iY-OD; Thu, 17 Jul 2003 06:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6Ol-0007cH-Fr for rohc@optimus.ietf.org; Thu, 17 Jul 2003 06:54: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 GAA29308 for ; Thu, 17 Jul 2003 06:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6Oh-0004eR-00 for rohc@ietf.org; Thu, 17 Jul 2003 06:54:03 -0400 Received: from gandalf.icr.a-star.edu.sg ([137.132.31.244]) by ietf-mx with esmtp (Exim 4.12) id 19d6OK-0004du-00 for rohc@ietf.org; Thu, 17 Jul 2003 06:53:40 -0400 Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.9+Sun/8.12.2) with ESMTP id h6HAq6qe021257 for ; Thu, 17 Jul 2003 18:52:06 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Thu, 17 Jul 2003 18:51:33 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 2B04C34334; Thu, 17 Jul 2003 18:51:36 +0800 (SGT) Date: Thu, 17 Jul 2003 18:51:36 +0800 From: Sukanta Kumar Hazra To: rohc@ietf.org Subject: Re: [rohc] Verifying decompression in ROHC-TCP Message-ID: <20030717105136.GA644@localhost> Mail-Followup-To: rohc@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 User-Agent: Mutt/1.5.4i 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Some form of hash maybe, as discussed in point 4. Are there any reasons why it might not be a good idea? - Sukanta ----- Original Message ----- From: ""West, Mark" " Date: Thu, 17 Jul, 2003 17:08 SGT Subject: [rohc] Verifying decompression in ROHC-TCP > > Hi all, > > The good ol' IPR issue is looming over rohc TCP, even as I type..! > Specifically, this relates to the use of a CRC to verify correct > decompression (a la RFC 3095). > > [note that we are only talking about verifying decompression -- we are not > considering 'context repair' (in 3095-speak)] > > So, we appear to have (at least) 3 choices, which I document here to see > if anyone wants to discuss it... please..! > > 1/ try and do something very close to the 3095 approach, but avoid > infriging the claimed IPR. A proposal along these lines could be to CRC > the *context*. (This means some header fields are not included and some > meta-data is included). It has essentially the same strength as the ROHC > RTP scheme. The biggest disadvantage is that this requires us to define > the CRC over the context (i.e. some format for the context), which is > somewhat unpleasant. > > 1a/ a slight modification of the above, in which we only CRC the context > fields that are updated by the packet. So, we are trying to protect the > mapping between the compressed and uncompressed representations. It has > (most of) the same properties of scheme 1. It should be possible to > specify this in a way that is slightly less onerous to compute... > > 2/ do it just like 1144/2507, i.e. rely solely upon the TCP checksum. > There are many problems with this, which include: > - known weaknesses of the TCP checksum > - issues with the changes that are signalled by deltas in 1144/2507 > - lack of coverage of much of the IP header > (and, worse, IPv6 extension headers) > - coverage includes the payload, which may be large and which (for > compression) we don't care about > Although we *could* do it this way, it is one of the things that we really > wanted to fix in ROHC-TCP. > > 3/ do something weird... for example: use the TCP checksum to verify > correct decompression (as per 1144/2507), acknowledging that this has a > number of weaknesses. However, in addtion, we make use of the Master > Sequence Number (MSN) to add some extra protection. > > Define the MSN to be (say) a 32-bit value. Send a small number of LSBs of > this in each packet. Also send a small checksum calculated over the MSN + > the *compressed* packet. At the decompressor, decode the MSN and verify > the checksum. [I assume that we have specified how robust we want > ROHC-TCP to be (e.g. to 3 consecutive packet losses)] > > If the MSN doesn't verify, we call decompression failure. If it *does* > verify, then we check it: if it's within the robustness bounds, we attempt > decompression (we believe that we have a valid compressed packet for which > decompression will work). > Otherwise, we call decompression failure. Only if we attempt > decompression (and believe that it will succeed) do we use the TCP > checksum to finally verify decompression. > > This still has most of the weaknesses of 1144/2507, but we *aren't* using > the checksum blindly to verify arbitrary decompression attempts. Maybe > this makes things better? > > Another small point to note is that the decompression methods of ROHC > *might* (and I haven't thought this through fully) be less vulnerable to > the 1144/2507 delta encoding with regard to exposing weaknesses in the > TCP/IP checksum. > > 4/ random aside: is a message digest the same thing as a checksum..? ;-) > > Comments welcome... > > Cheers, > > Mark. > > -- > Mark A. West, Consultant Engineer > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc -- Sukanta K. Hazra http://www.icr.a-star.edu.sg/~sukanta/ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 17 07:09:40 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 HAA29758 for ; Thu, 17 Jul 2003 07:09:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6dN-0000mB-Tm for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 07:09:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HB9Drd002980 for rohc-archive@odin.ietf.org; Thu, 17 Jul 2003 07:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6dN-0000lz-Q0 for rohc-web-archive@optimus.ietf.org; Thu, 17 Jul 2003 07:09:13 -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 HAA29748 for ; Thu, 17 Jul 2003 07:09:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6dJ-0004oz-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 07:09:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19d6dD-0004ov-00 for rohc-web-archive@ietf.org; Thu, 17 Jul 2003 07:09:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6dA-0000jL-US; Thu, 17 Jul 2003 07:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19d6cV-0000it-Su for rohc@optimus.ietf.org; Thu, 17 Jul 2003 07:08: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 HAA29735 for ; Thu, 17 Jul 2003 07:08:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19d6cR-0004oj-00 for rohc@ietf.org; Thu, 17 Jul 2003 07:08:15 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19d6cG-0004oX-00 for rohc@ietf.org; Thu, 17 Jul 2003 07:08:04 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <3SSL1RNY>; Thu, 17 Jul 2003 12:07:13 +0100 Received: from mjw-pc.roke.co.uk ([193.118.194.159]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3SSK1PPV; Thu, 17 Jul 2003 12:07:10 +0100 From: "West, Mark" To: Sukanta Kumar Hazra Cc: rohc@ietf.org Date: Thu, 17 Jul 2003 12:07:37 +0000 (GMT) X-X-Sender: maw@mjw-pc.roke.co.uk Subject: Re: [rohc] Verifying decompression in ROHC-TCP In-Reply-To: <20030717105136.GA644@localhost> Message-ID: 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Unfortunately, the most obvious reason why it might not be a good idea is that if a hash can be regarded as a checksum, then it's probably covered by the IPR that we're concerned about..! Cheers, Mark. On Thu, 17 Jul 2003, Sukanta Kumar Hazra wrote: > Date: Thu, 17 Jul 2003 18:51:36 +0800 > From: Sukanta Kumar Hazra > To: rohc@ietf.org > Subject: Re: [rohc] Verifying decompression in ROHC-TCP > > Some form of hash maybe, as discussed in point 4. Are there any reasons > why it might not be a good idea? > > - Sukanta > ----- Original Message ----- > From: ""West, Mark" " > Date: Thu, 17 Jul, 2003 17:08 SGT > Subject: [rohc] Verifying decompression in ROHC-TCP > > > > > Hi all, > > > > The good ol' IPR issue is looming over rohc TCP, even as I type..! > > Specifically, this relates to the use of a CRC to verify correct > > decompression (a la RFC 3095). > > > > [note that we are only talking about verifying decompression -- we are not > > considering 'context repair' (in 3095-speak)] > > > > So, we appear to have (at least) 3 choices, which I document here to see > > if anyone wants to discuss it... please..! > > > > 1/ try and do something very close to the 3095 approach, but avoid > > infriging the claimed IPR. A proposal along these lines could be to CRC > > the *context*. (This means some header fields are not included and some > > meta-data is included). It has essentially the same strength as the ROHC > > RTP scheme. The biggest disadvantage is that this requires us to define > > the CRC over the context (i.e. some format for the context), which is > > somewhat unpleasant. > > > > 1a/ a slight modification of the above, in which we only CRC the context > > fields that are updated by the packet. So, we are trying to protect the > > mapping between the compressed and uncompressed representations. It has > > (most of) the same properties of scheme 1. It should be possible to > > specify this in a way that is slightly less onerous to compute... > > > > 2/ do it just like 1144/2507, i.e. rely solely upon the TCP checksum. > > There are many problems with this, which include: > > - known weaknesses of the TCP checksum > > - issues with the changes that are signalled by deltas in 1144/2507 > > - lack of coverage of much of the IP header > > (and, worse, IPv6 extension headers) > > - coverage includes the payload, which may be large and which (for > > compression) we don't care about > > Although we *could* do it this way, it is one of the things that we really > > wanted to fix in ROHC-TCP. > > > > 3/ do something weird... for example: use the TCP checksum to verify > > correct decompression (as per 1144/2507), acknowledging that this has a > > number of weaknesses. However, in addtion, we make use of the Master > > Sequence Number (MSN) to add some extra protection. > > > > Define the MSN to be (say) a 32-bit value. Send a small number of LSBs of > > this in each packet. Also send a small checksum calculated over the MSN + > > the *compressed* packet. At the decompressor, decode the MSN and verify > > the checksum. [I assume that we have specified how robust we want > > ROHC-TCP to be (e.g. to 3 consecutive packet losses)] > > > > If the MSN doesn't verify, we call decompression failure. If it *does* > > verify, then we check it: if it's within the robustness bounds, we attempt > > decompression (we believe that we have a valid compressed packet for which > > decompression will work). > > Otherwise, we call decompression failure. Only if we attempt > > decompression (and believe that it will succeed) do we use the TCP > > checksum to finally verify decompression. > > > > This still has most of the weaknesses of 1144/2507, but we *aren't* using > > the checksum blindly to verify arbitrary decompression attempts. Maybe > > this makes things better? > > > > Another small point to note is that the decompression methods of ROHC > > *might* (and I haven't thought this through fully) be less vulnerable to > > the 1144/2507 delta encoding with regard to exposing weaknesses in the > > TCP/IP checksum. > > > > 4/ random aside: is a message digest the same thing as a checksum..? ;-) > > > > Comments welcome... > > > > Cheers, > > > > Mark. > > > > -- > > Mark A. West, Consultant Engineer > > Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN > > Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > -- > Sukanta K. Hazra http://www.icr.a-star.edu.sg/~sukanta/ > > _______________________________________________ > 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 Sat Jul 19 20:16:39 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 UAA26463 for ; Sat, 19 Jul 2003 20:16:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19e1s4-0006ed-Of for rohc-archive@odin.ietf.org; Sat, 19 Jul 2003 20:16:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6K0GC9l025575 for rohc-archive@odin.ietf.org; Sat, 19 Jul 2003 20:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19e1s4-0006eQ-Lw for rohc-web-archive@optimus.ietf.org; Sat, 19 Jul 2003 20:16:12 -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 UAA26449 for ; Sat, 19 Jul 2003 20:16:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19e1s2-0005Ic-00 for rohc-web-archive@ietf.org; Sat, 19 Jul 2003 20:16:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19e1rx-0005IW-00 for rohc-web-archive@ietf.org; Sat, 19 Jul 2003 20:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19e1rs-0006e3-Pi; Sat, 19 Jul 2003 20:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19e1rc-0006dk-7s for rohc@optimus.ietf.org; Sat, 19 Jul 2003 20:15:44 -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 UAA26424 for ; Sat, 19 Jul 2003 20:15:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19e1ra-0005IB-00 for rohc@ietf.org; Sat, 19 Jul 2003 20:15:42 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19e1rO-0005H8-00 for rohc@ietf.org; Sat, 19 Jul 2003 20:15:31 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 413098A7FA; Sun, 20 Jul 2003 09:43:43 +0930 (CST) Date: Sun, 20 Jul 2003 09:43:43 +0930 From: Alan Kennington To: ROHC mailing list Cc: Alan Kennington Message-ID: <20030720094343.B4194@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] Tsc field interpretation for RFC 3095 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , I've just come across another small apparent ambiguity in RFC 3095. For the extension type 3, the RFC has this on page 85: ================================================ 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 1 | S |R-TS | Tsc | I | ip | rtp | (FLAGS) +-----+-----+-----+-----+-----+-----+-----+-----+ [....] S, R-TS, I, ip, rtp, ip2: Indicate presence of fields as shown to the right of each field above. Tsc: Tsc = 0 indicates that TS is not scaled; Tsc = 1 indicates that TS is scaled according to section 4.5.3, using value(TS_STRIDE). Context(Tsc) is always 1. If scaling is not desired, the compressor will establish TS_STRIDE = 1. SN: See the beginning of section 5.7. TS: Variable number of bits of TS, encoded according to section 4.5.6. See the beginning of section 5.7. ================================================ Suppose I have R-TS = 0. This means there is no TS field in the extension 3. Question: Does this mean that Tsc is ignored? In other words, does Tsc only apply to the TS field in the extension 3? If I send a UOR-2 with extension 3 with R-TS = 0 and Tsc = 0, does this mean that the 6 bits of TS in the base header are unscaled? Both interpretations seem reasonable. Could someone please tell me what the current consensus on this is? I think this should be in the ROHC implementer's guide. Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington website: http://www.topology.org/ city: Adelaide, South Australia coords: 138.59 E, 34.88 S timezone: UTC+0930 http://www.topology.org/site/timezone.html pgp-key: http://www.topology.org/ak/key_ak2.asc note: My e-mail address often changes due to spam abuse. note: If your e-mail bounces, please visit topology.org/extra/email.php _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun Jul 20 19:15: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 TAA00545 for ; Sun, 20 Jul 2003 19:15:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNOW-0005BP-7e for rohc-archive@odin.ietf.org; Sun, 20 Jul 2003 19:15:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6KNF86i019919 for rohc-archive@odin.ietf.org; Sun, 20 Jul 2003 19:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNOW-0005BB-3U for rohc-web-archive@optimus.ietf.org; Sun, 20 Jul 2003 19:15: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 TAA00534 for ; Sun, 20 Jul 2003 19:15:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eNOU-0005mM-00 for rohc-web-archive@ietf.org; Sun, 20 Jul 2003 19:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eNOO-0005mJ-00 for rohc-web-archive@ietf.org; Sun, 20 Jul 2003 19:15:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNOP-0005Ab-3G; Sun, 20 Jul 2003 19:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eNNy-0005AB-M7 for rohc@optimus.ietf.org; Sun, 20 Jul 2003 19:14: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 TAA00513 for ; Sun, 20 Jul 2003 19:14:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eNNx-0005le-00 for rohc@ietf.org; Sun, 20 Jul 2003 19:14:33 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19eNNl-0005lC-00 for rohc@ietf.org; Sun, 20 Jul 2003 19:14:22 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 00EBB8A75C; Mon, 21 Jul 2003 08:43:27 +0930 (CST) Date: Mon, 21 Jul 2003 08:43:27 +0930 From: Alan Kennington To: ROHC mailing list Cc: Alan Kennington Subject: Re: [rohc] Verifying decompression in ROHC-TCP Message-ID: <20030721084327.A10124@dog.topology.org> Reply-To: Alan Kennington References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from lars-erik.jonsson@ericsson.com on Thu, Jul 17, 2003 at 11:10:37AM +0200 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Thu, Jul 17, 2003 at 11:10:37AM +0200, Lars-Erik Jonsson (LU/EAB) wrote: > Some general questions/observations: > > 1) Do we believe there is relevant IPR on the CRC approach from 3095? > > 2) Do we believe that this is the only 3095-IPR we should be "afraid" of? > > > Finding out how to tackle the situation is the next step after answering yes to the two questions above. > L-E, Can you (or any one else) give an indication of whether it would be safe for an open source developer to release a linux open source implementation of ROHC? I'm particularly interested in the RFC 3095 profiles 0, 1, 2 and 3. I notice that there is an implementation of profiles 0, 2, 4 and 7 for linux kernel for PPP over ethernet already in the public domain on sourceforge: http://rohc.sourceforge.net/ Particularly for academics, it would be nice to have an open reference implementation for teaching and research. My particular interest is in ROHC/PPP implementations. At first I thought that linux PPP/ROHC would not be any sort of competition to the 3G world because no mobile phone company would worry about compression on dial-up phone lines. But now I'm starting to think that ROHC/PPP could be a serious competitor, because people could use VoIP/ROHC/PPP/ethernet on DSL and Wireless LAN links, Some people say that wireless LAN will be a serious competitor to 3G. I'm not in that industry any more; so I can't say. Is there a procedure whereby linux developers could get an assurance that they would not be sued for releasing an RFC 3095 implementation? Or is it simply not possible? Linux developers just don't have any money for lawyers; so they have to do what they're told! If it is not possible, then I imagine that linux developers will some day have to develop their own patent-safe compression protocol for VoIP over wireless LAN etc. for linux PDAs and laptops etc. Given the rising popularity of linux PDAs (from a small starting point), such an alternative could be a competitor to ROHC. Therefore it might be in the interests of the 3G companies to encourage widespread adoption of ROHC by _explicitly_ permitting an open source version. Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington website: http://www.topology.org/ city: Adelaide, South Australia coords: 138.59 E, 34.88 S timezone: UTC+0930 http://www.topology.org/site/timezone.html pgp-key: http://www.topology.org/ak/key_ak2.asc note: My e-mail address often changes due to spam abuse. note: If your e-mail bounces, please visit topology.org/extra/email.php _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jul 21 13:19:56 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 NAA04389 for ; Mon, 21 Jul 2003 13:19:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeJv-0005aa-MQ for rohc-archive@odin.ietf.org; Mon, 21 Jul 2003 13:19:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LHJVP8021478 for rohc-archive@odin.ietf.org; Mon, 21 Jul 2003 13:19:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeJv-0005aL-IC for rohc-web-archive@optimus.ietf.org; Mon, 21 Jul 2003 13:19: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 NAA04296 for ; Mon, 21 Jul 2003 13:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eeGh-0004ni-00 for rohc-web-archive@ietf.org; Mon, 21 Jul 2003 13:16:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19eeGc-0004ne-00 for rohc-web-archive@ietf.org; Mon, 21 Jul 2003 13:16:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eeGX-0005Uf-9f; Mon, 21 Jul 2003 13: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 19dX9M-0002e1-Hq for rohc@optimus.ietf.org; Fri, 18 Jul 2003 11:28:00 -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 LAA03950 for ; Fri, 18 Jul 2003 11:27:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dX9L-0001io-00 for rohc@ietf.org; Fri, 18 Jul 2003 11:27:59 -0400 Received: from sea1-f74.sea1.hotmail.com ([207.68.163.74] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19dX9B-0001iQ-00 for rohc@ietf.org; Fri, 18 Jul 2003 11:27:49 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Jul 2003 08:26:52 -0700 Received: from 192.75.88.232 by sea1fd.sea1.hotmail.msn.com with HTTP; Fri, 18 Jul 2003 15:26:52 GMT X-Originating-IP: [192.75.88.232] X-Originating-Email: [stevestevens1@hotmail.com] From: "steve stevens" To: rohc@ietf.org Date: Fri, 18 Jul 2003 15:26:52 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jul 2003 15:26:52.0944 (UTC) FILETIME=[03DB9100:01C34D41] Subject: [rohc] ROHC implementation 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hello Everyone! I am interested in implementing and testing ROHC on a LINUX platform in a wirelessLAN environment. I have read rfc3095 and the internet draft "draft-fleming-rohc-wireless-ethernet-med-01.txt". I want to know how to get started implementing and what resources can help me in implementing the protocol. Please help. Thanks!! Steve _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Jul 22 14:14:43 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 OAA21461 for ; Tue, 22 Jul 2003 14:14:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1eP-0001r8-Md for rohc-archive@odin.ietf.org; Tue, 22 Jul 2003 14:14:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MIED01007101 for rohc-archive@odin.ietf.org; Tue, 22 Jul 2003 14:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1eP-0001q1-HB for rohc-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 14:14:13 -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 OAA21433 for ; Tue, 22 Jul 2003 14:14:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1eN-0006Qb-00 for rohc-web-archive@ietf.org; Tue, 22 Jul 2003 14:14:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f1eH-0006QS-00 for rohc-web-archive@ietf.org; Tue, 22 Jul 2003 14:14:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f1eD-0001mw-0k; Tue, 22 Jul 2003 14: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 19f1dt-0001mi-Cf for rohc@optimus.ietf.org; Tue, 22 Jul 2003 14:13:41 -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 OAA21416 for ; Tue, 22 Jul 2003 14:13:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f1dq-0006QK-00 for rohc@ietf.org; Tue, 22 Jul 2003 14:13:38 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19f1dg-0006PL-00 for rohc@ietf.org; Tue, 22 Jul 2003 14:13:28 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 13:47:32 -0400 Message-ID: From: Remi Pelland To: "'Price, Richard'" , "'rohc@ietf.org'" Subject: RE: [rohc] Problem with RFC 3095 Extension Header encoding Date: Tue, 22 Jul 2003 13:47:31 -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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I was interrested to see the answers to the questions below about = extension header encoding. Unfortunately, I haven't seen any feedback on the = mailing list. How do current implementations support AH, ESP and GRE? How are these sequence numbers encoded? Thanks, R=E9mi. -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: Wednesday, June 04, 2003 12:19 PM To: rohc@ietf.org Subject: [rohc] Problem with RFC 3095 Extension Header encoding Hi, I'm currently attempting to add support for IP Extension Headers to our ROHC-TCP implementation - the plan is to reuse the existing packet formats from RFC 3095. However, I'm having some difficulty decoding the compressed versions of the AH, ESP and GRE Sequence Numbers. What isn't clear from the standard is the following: 1. What interpretation interval should I use to decode the sequence number LSBs? 2. Should the decoded sequence number be treated as an absolute value, or as an offset from the RTP Sequence Number? If I've missed the relevant text in RFC 3095, please let me know! Thanks, Richard _______________________________________________ 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 Tue Jul 22 14:50: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 OAA22356 for ; Tue, 22 Jul 2003 14:50:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2DA-0003XG-7F for rohc-archive@odin.ietf.org; Tue, 22 Jul 2003 14:50:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MIo82m013584 for rohc-archive@odin.ietf.org; Tue, 22 Jul 2003 14:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2DA-0003Wy-2G for rohc-web-archive@optimus.ietf.org; Tue, 22 Jul 2003 14:50: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 OAA22349 for ; Tue, 22 Jul 2003 14:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2D7-0006eN-00 for rohc-web-archive@ietf.org; Tue, 22 Jul 2003 14:50:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19f2D1-0006eJ-00 for rohc-web-archive@ietf.org; Tue, 22 Jul 2003 14:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2D3-0003UD-91; Tue, 22 Jul 2003 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f2Co-0003TT-Rh for rohc@optimus.ietf.org; Tue, 22 Jul 2003 14:49:46 -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 OAA22335 for ; Tue, 22 Jul 2003 14:49:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f2Cm-0006dr-00 for rohc@ietf.org; Tue, 22 Jul 2003 14:49:44 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19f2Cb-0006do-00 for rohc@ietf.org; Tue, 22 Jul 2003 14:49:33 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 14:25:28 -0400 Message-ID: From: Remi Pelland To: "'rohc@ietf.org'" Date: Tue, 22 Jul 2003 14:25:27 -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 Subject: [rohc] RFC-3095 question: Parsing of UOR-2-* + Extension 3 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Section 4.8 of the ROHC Implementer's Guide (rev 03) says that when the = RND flag changes in Extension 3, "the decompressor should re-parse the = UOR-2-* packet." Instead of parsing the UOR-2-* packet and re-parsing it if RND changes, = is it correct to simply parse the packet using the value of RND included = in the Extension 3, regardless if it changes or not (provided the field is = present in the extension)? When the RND flag is not in the extension, then as usual, the value of RND in the associated decompressor context is used. = =20 In other words, when parsing an UOR-2-* packet that contains an = Extension 3, the value of RND included in the extension overrides the one in the = context when parsing. Off course this requires to take peek at the Extension 3 content before parsing the packet, but this is possible since the X-bit is at the same location for all UOR-2-* packets. Thanks, R=E9mi. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 23 15:16:43 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 PAA25650 for ; Wed, 23 Jul 2003 15:16:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5z-0001Rl-JC for rohc-archive@odin.ietf.org; Wed, 23 Jul 2003 15:16:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NJGFri005551 for rohc-archive@odin.ietf.org; Wed, 23 Jul 2003 15:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5z-0001RL-Fr for rohc-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 15:16:15 -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 PAA25559 for ; Wed, 23 Jul 2003 15:16:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fP5y-00076A-00 for rohc-web-archive@ietf.org; Wed, 23 Jul 2003 15:16:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fP5s-00075w-00 for rohc-web-archive@ietf.org; Wed, 23 Jul 2003 15:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5l-0001Is-At; Wed, 23 Jul 2003 15: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 19fP4w-0001FX-GB for rohc@optimus.ietf.org; Wed, 23 Jul 2003 15:15:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25298; Wed, 23 Jul 2003 15:15:07 -0400 (EDT) Message-Id: <200307231915.PAA25298@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, 23 Jul 2003 15:15:07 -0400 Subject: [rohc] I-D ACTION:draft-ozegovic-rohc-fn-requirements-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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ROHC Formal Notation Requirements Author(s) : J. Ozegovic Filename : draft-ozegovic-rohc-fn-requirements-00.txt Pages : 19 Date : 2003-7-23 This draft describes requirements expected to be achieved with profile formal notation system for ROHC. The RObust Header Compression (ROHC) [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. The role of formal notation is to provide a simple method for ROHC profile specification. It is to be used in the phase of profile refinement to achieve maximal compression ratio possible, as well as in the phase of software implementation to provide unambiguous profile specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ozegovic-rohc-fn-requirements-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-ozegovic-rohc-fn-requirements-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-ozegovic-rohc-fn-requirements-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-7-23151117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ozegovic-rohc-fn-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ozegovic-rohc-fn-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23151117.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 Jul 23 16:03:12 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 PAA25648 for ; Wed, 23 Jul 2003 15:16:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5z-0001RS-GF for rohc-archive@odin.ietf.org; Wed, 23 Jul 2003 15:16:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NJGF5K005537 for rohc-archive@odin.ietf.org; Wed, 23 Jul 2003 15:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5z-0001RE-Br for rohc-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 15:16:15 -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 PAA25558 for ; Wed, 23 Jul 2003 15:16:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fP5y-00076D-00 for rohc-web-archive@ietf.org; Wed, 23 Jul 2003 15:16:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fP5s-00075x-00 for rohc-web-archive@ietf.org; Wed, 23 Jul 2003 15:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5l-0001J4-Ja; Wed, 23 Jul 2003 15: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 19fP51-0001I5-KE for rohc@optimus.ietf.org; Wed, 23 Jul 2003 15:15:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25320; Wed, 23 Jul 2003 15:15:13 -0400 (EDT) Message-Id: <200307231915.PAA25320@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, 23 Jul 2003 15:15:12 -0400 Subject: [rohc] I-D ACTION:draft-ozegovic-rtp-rohc-fn-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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Profile in ROHC-FN Author(s) : J. Ozegovic Filename : draft-ozegovic-rtp-rohc-fn-00.txt Pages : 9 Date : 2003-7-23 This draft describes a profile for compressing RTP/IP using the Robust Header Compression Formal Notation. The RObust Header Compression [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. This draft describes a modification of previously published RTP profiles for ROHC to conform to ROHC-FN [2] and Prolog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ozegovic-rtp-rohc-fn-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-ozegovic-rtp-rohc-fn-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-ozegovic-rtp-rohc-fn-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-7-23151126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ozegovic-rtp-rohc-fn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ozegovic-rtp-rohc-fn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23151126.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 Jul 24 18:49:30 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 SAA05053 for ; Thu, 24 Jul 2003 18:49:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fotW-000312-RC for rohc-archive@odin.ietf.org; Thu, 24 Jul 2003 18:49:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OMn6Ts011591 for rohc-archive@odin.ietf.org; Thu, 24 Jul 2003 18:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fotW-00030s-M3 for rohc-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 18:49: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 SAA05050 for ; Thu, 24 Jul 2003 18:48:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fotH-0002z4-00 for rohc-web-archive@ietf.org; Thu, 24 Jul 2003 18:48:51 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fotB-0002yy-00 for rohc-web-archive@ietf.org; Thu, 24 Jul 2003 18:48:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fosT-0002yN-EN; Thu, 24 Jul 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 19forh-0002y2-9h for rohc@optimus.ietf.org; Thu, 24 Jul 2003 18:47:13 -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 SAA05030 for ; Thu, 24 Jul 2003 18:47:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fore-0002ys-00 for rohc@ietf.org; Thu, 24 Jul 2003 18:47:10 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19forT-0002ym-00 for rohc@ietf.org; Thu, 24 Jul 2003 18:46:59 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 18:22:35 -0400 Message-ID: From: Remi Pelland To: "'Carsten Bormann'" , rohc@ietf.org Date: Thu, 24 Jul 2003 18:22:30 -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 Subject: [rohc] CRC calculation example in ROHC implementer's guide 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Carsten, I am not very familiar with CRC calculations and I have a question = about the algorithm you provided in the ROHC implementer's guide. Actually, I = want to make sure I get it straight : a) Assume the data on which the CRC is to be calculated is located = somewhere in memory; b) The CRC calculation starts with the LSB of the first byte and bits = are processed sequentially until the MSB of the first byte is reached and processed; c) Then, it processes the LSB of the second byte and progresses until = it reaches the MSB of the second byte; d) Bits are processed from LSB to MSB until the last byte is reached = and processed. The last bit processed is thus the MSB of the last byte. Do I have the proper understanding? I have not seen anything in RFC-3095 saying that for each byte, the LSB = is the first bit that is shifted in the calculation register. Instead, I = was under the impression that the data over which the CRC is calculated = would simply be treated as a stream of bits in memory, starting with the MSB = of the first byte and progressing linearly until the LSB of the last byte. Was this method chosen so bits are processed in the order they are sent = out on the network? (Assuming all link layers send the LSB first.) Thanks, R=E9mi. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun Jul 27 19:40:12 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 TAA29045 for ; Sun, 27 Jul 2003 19:40:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gv7A-0004DK-DN for rohc-archive@odin.ietf.org; Sun, 27 Jul 2003 19:39:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6RNdihv016194 for rohc-archive@odin.ietf.org; Sun, 27 Jul 2003 19:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gv7A-0004D7-A3 for rohc-web-archive@optimus.ietf.org; Sun, 27 Jul 2003 19:39:44 -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 TAA29042 for ; Sun, 27 Jul 2003 19:39:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gv78-0001GO-00 for rohc-web-archive@ietf.org; Sun, 27 Jul 2003 19:39:42 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19gv78-0001GK-00 for rohc-web-archive@ietf.org; Sun, 27 Jul 2003 19:39:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gv6T-00049p-Bu; Sun, 27 Jul 2003 19:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gv6I-00049S-Mq for rohc@optimus.ietf.org; Sun, 27 Jul 2003 19:38: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 TAA28991 for ; Sun, 27 Jul 2003 19:38:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gv6H-0001FB-00 for rohc@ietf.org; Sun, 27 Jul 2003 19:38:49 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19gv6G-0001Ew-00 for rohc@ietf.org; Sun, 27 Jul 2003 19:38:48 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jul 2003 00:38:08 +0100 Received: from localhost (orion.roke.co.uk [193.118.192.66]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PRAWX0H5; Mon, 28 Jul 2003 00:38:02 +0100 From: "West, Mark" To: rohc@ietf.org Date: Mon, 28 Jul 2003 00:37:58 +0100 (GMT Daylight Time) Message-ID: X-X-Sender: maw1@maw-laptop.roke.co.uk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] TCP compression 'open issues' 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Fellow ROHC-ers, For those of you who couldn't make the IETF or, alternatively, found ospf more compelling and so missed the 'open issues' presentation, here is a summary of the issues with suggested answers [for most cases]. It's a bit terse, so if you don't understand anything, give me a shout. Acks or nacks would be appreciated. (especially if the nack has a 'reason code' and a suggested fix/answer ;-) - ip version will be '4' or '6' -> encode it in a single bit - ipv4 ip id can be 'byte-swapped' -> we should account for this... - random ipv4 ip id behaviour -> we should treat this as a special case (as does 3095) - 'always 0' ipv4 ip id behaviour -> we should treat this as a special case (as the IP only profile draft) - TCP 'psh' flag -> don't bother trying to compress it - should it be posisble to 'replicate' the DSCP -> yes, but this requires static/irregular behaviour in the IR-replicate - should it be posisble to 'replicate' TTL -> yes (see also DSCP, above) - should it be possible to replicate ipv4 ip id -> no, but it should be possible to replicate the behaviour (random, irregular, counting, nbo flag) - what about the reserved bits? -> we should handle these since we don't know how they'll be used in the future, suggest that they are either all always carried, or never carried - does 'df' need to be supported in compressed packets -> no - can we exploit common values for TTL -> not a lot of point, because this would rely upon the compressor being co-located with the end-point and the saving is not great (especially as TTL could be replicated) - ECN -> should be supported (the bits either always sent or never) -> little point in trying to compress the ECN bits (we are assuming ECN nonces) - IP headers (how many should be compressed) -> as many as are there - is it worth having simpler formats for ipv6 -> yes - does tcp change the use of extension headers in any way -> no - should we assume frequent changes to the TCP window -> yes, but common values might be established - TCP urgent flag / pointer -> URG flag of 0 means URP is ignored expect it be 0 / unchanging -> URG is used infrequently; not worth much effort for special handling - TCP Sequence / Acknowledgement numbers - Behaviour is structured -> to what extent can/should we exploit this - Many cases where packets may frequently have the same size - How robust (in terms of packet loss) does ROHC-TCP need to be? -> suggest a small number (e.g. 2) - What (max) size should be assumed for the TCP MSS? -> Ethernet (1460 bytes)? - is it worth treating 'SYN-only' options specially to optimise initialisation? -> yes - is it worth handling options that come and go (e.g. SACK)? -> yes - is it worth compressing the timestamp option? -> yes, but what clock resolutions are commonly used? - is it worth linking the TS option to the ack flag? -> no, because ACK is only unset on the initial SYN packet - are there options other than SACK, TS, WSCALE, MSS that should be compressed? -> no, but 'generic' options should be compressed more efficiently if they remain static - Master Sequence Number (MSN) - do you need it in every packet? -> maybe! (can only ack packets with MSN, other fields might depend on it) - Is a 3-bit CRC enough to protect TCP compression? -> Warning: large IPR discussion required at this point! -> However, generally, we need to think about issues relating to the TCP checksum (which is carried end-to-end) and the need for additional protection. It is clear that 'damage propagation' for TCP is really bad news... Curiously, the IPR discussion seems to have gone quiet. But, never fear, I will follow up on this topic shortly! Cheers, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 04:12:10 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 EAA23408 for ; Wed, 30 Jul 2003 04:12:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hm3l-000876-1E for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 04:11:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U8Bi88031182 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 04:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hm3j-00086r-OY for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 04:11:43 -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 EAA23388 for ; Wed, 30 Jul 2003 04:11:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hm3g-0005u6-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 04:11:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hm3f-0005u2-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 04:11:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hm33-00084G-A6; Wed, 30 Jul 2003 04:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hm2m-00083s-D6 for rohc@optimus.ietf.org; Wed, 30 Jul 2003 04:10:44 -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 EAA23361 for ; Wed, 30 Jul 2003 04:10:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hm2i-0005tj-00 for rohc@ietf.org; Wed, 30 Jul 2003 04:10:40 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19hm2i-0005tU-00 for rohc@ietf.org; Wed, 30 Jul 2003 04:10:40 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6U8A6VI056580 for ; Wed, 30 Jul 2003 10:10:06 +0200 (CEST) Received: from [10.1.1.171] (m-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 96E94BBCBD for ; Wed, 30 Jul 2003 09:49:07 +0200 (CEST) Date: Wed, 30 Jul 2003 10:11:44 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Quittek?= To: rohc@ietf.org Message-ID: <2147483647.1059559904@[10.1.1.171]> 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 Content-Transfer-Encoding: 7bit Subject: [rohc] ROHC compression ratio 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, These is questions on the compression ratio were raised by Mike Heard when he reviewed the ROHC MIB: Is there a theoretical proof that compressed headers are always shorter than uncompressed ones (for the already standardized profiles)? If not, is there a theoretical limit of how much a compressed header can exceed the size of an uncompressed one? 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 Wed Jul 30 05:18:08 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 FAA24699 for ; Wed, 30 Jul 2003 05:18:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn5a-0001hl-UZ for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 05:17:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U9Hg3b006549 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 05:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn5a-0001hY-Qx for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 05:17: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 FAA24690 for ; Wed, 30 Jul 2003 05:17:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hn5W-0006Em-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 05:17:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hn5W-0006Ej-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 05:17:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn4v-0001ey-Du; Wed, 30 Jul 2003 05:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn4k-0001eZ-Mb for rohc@optimus.ietf.org; Wed, 30 Jul 2003 05:16: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 FAA24662 for ; Wed, 30 Jul 2003 05:16:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hn4g-0006Dz-00 for rohc@ietf.org; Wed, 30 Jul 2003 05:16:46 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19hn4e-0006Db-00 for rohc@ietf.org; Wed, 30 Jul 2003 05:16:45 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 140C88A7F5; Wed, 30 Jul 2003 18:46:06 +0930 (CST) Date: Wed, 30 Jul 2003 18:46:06 +0930 From: Alan Kennington To: =?iso-8859-1?Q?J=FCrgen?= Quittek Cc: ROHC mailing list , Alan Kennington Subject: Re: [rohc] ROHC compression ratio Message-ID: <20030730184606.A14758@dog.topology.org> Reply-To: Alan Kennington References: <2147483647.1059559904@[10.1.1.171]> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <2147483647.1059559904@[10.1.1.171]>; from quittek@ccrle.nec.de on Wed, Jul 30, 2003 at 10:11:44AM +0200 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2003 at 10:11:44AM +0200, J=FCrgen Quittek wrote: >=20 > Is there a theoretical proof that compressed headers are always > shorter than uncompressed ones (for the already standardized profiles)? >=20 > If not, is there a theoretical limit of how much a compressed > header can exceed the size of an uncompressed one? Juergen, Individual compressed packets are often larger than the original IPv4 pac= ket. I see this often when I am sending IR packets in ROHC RTP profile 0x0001. Here is an example from one of my packet logs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TX context: CID=3D5 profile=3D1 mode=3DU trans=3DD tss=3D44960 RND=3D1 NB= O=3D1 rtype=3DIR ROHC packet type=3DIR CRC=3D0xf3 IP version=3D4 protocol=3D17(UDP) IP src=3D192.168.0.1 IP dst=3D192.168.0= .2 UDP src=3D5060 UDP dst=3D5000 SSRC=3D0x3afc4712 TOS=3D0x00000010 TTL=3D64 IP-ID=3D0x0000 DF=3D1 RND=3D1 NBO=3D1 Extn header list: ET=3D0 GP=3D0 PS=3D1 CC=3D0 UDP-CS=3D0x757d RTP: V=3D2 P=3D0 RX=3D1 CC=3D0 M=3D1 PT=3D0x03 SN=3D0x9030(36912) TS=3D0x= 0000b040(45120) ROHC packet length =3D 178 octets. ROHC=3D0005 fd0501f3 4011c0a8 0001c0a8 000213c4 13883afc 47121040 0000e01= 0 757d908 3 90300000 b0401007 c0afa000 d820a2e1 5a500049 24924924 50004924 92492450= 004924 92 49245000 49249249 24d820a2 e15a5000 49249249 24500049 24924924 5000492= 4 92492 450 00492492 4924d820 a2e15a50 00492492 49245000 49249249 24500049 249249= 24 5000 4924 924924d8 20a2e15a 50004924 92492450 00492492 49245000 49249249 24500= 049 249 24924 IPv4 packet length =3D 174 octets. IP=3D0021 451000ac 00004000 4011b8dd c0a80001 c0a80002 13c41388 0098757d = 80839030=20 0000b040 3afc4712 d820a2e1 5a500049 24924924 50004924 92492450 00492492 4= 9245000 49249249 24d820a2 e15a5000 49249249 24500049 24924924 50004924 92492450 = 0049249 2 4924d820 a2e15a50 00492492 49245000 49249249 24500049 24924924 50004924= 924924 d8 20a2e15a 50004924 92492450 00492492 49245000 49249249 24500049 2492492= 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Normally only IR packets will be larger than the corresponding IPv4 packe= ts. The "negative compression" can be larger than 4 bytes if you have a CSRC list or some other kinds of context set-up. There is a limit to the "negative compression" size difference, but I don't know what it is. Perhaps it is about 20 or 24 octets maximum, maybe a bit more.=20 I think it would be difficult, but not impossible, for a UOR-2 or IR-DYN packet to be larger than the original IP packet. This is, of course, a big issue for implementers who have to keep within the MTU for a PPP interface for example. If the "negative compressed" packet is larger than the MTU, it may be rejected by the decompressor end of the link. This is rare for RTP because RTP packets are usually small. But I imagine that this happens very often for plain UDP and plain IP. To fix this problem, you need to set the MRU about 24 bytes or so larger than the MTU which the IP layer sees. You can see that if UDP packets are sent out with size equal to the MTU, then all of the "negative compressing" IR packets will be lost by the RX = side if the MRU equals the MTU of the TX side. Therefore the context will neve= r be established, and communication will be impossible. Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington website: http://www.topology.org/ city: Adelaide, South Australia coords: 138.59 E, 34.88 S timezone: UTC+0930 http://www.topology.org/site/timezone.html pgp-key: http://www.topology.org/ak/key_ak2.asc note: My e-mail address often changes due to spam abuse. : If your e-mail bounces, please visit topology.org/extra/email.p= hp _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 09: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 JAA00532 for ; Wed, 30 Jul 2003 09:45:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrGP-0001AD-B4 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 09:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UDj9Rp004469 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 09:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrGP-00019y-7H for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 09:45: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 JAA00522 for ; Wed, 30 Jul 2003 09:45:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrGL-000051-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 09:45:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hrGL-00004y-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 09:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrGH-00018S-39; Wed, 30 Jul 2003 09:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrFg-00016P-Md for rohc@optimus.ietf.org; Wed, 30 Jul 2003 09:44:29 -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 JAA00510 for ; Wed, 30 Jul 2003 09:44:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrFe-00004o-00 for rohc@ietf.org; Wed, 30 Jul 2003 09:44:22 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19hrFe-00004k-00 for rohc@ietf.org; Wed, 30 Jul 2003 09:44:22 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 09:20:01 -0400 Message-ID: From: Remi Pelland To: "'Carsten Bormann'" , "'rohc@ietf.org'" Subject: FW: [rohc] CRC calculation example in ROHC implementer's guide Date: Wed, 30 Jul 2003 09:20:01 -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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does anyone have any comments on my understanding of the CRC = calculation - please see below? I haven't heard anything back from Carsten yet, and = I really do need this information quite soon. Thanks in advance, R=E9mi. -----Original Message----- From: Remi Pelland [mailto:remi.pelland@octasic.com] Sent: Thursday, July 24, 2003 6:23 PM To: 'Carsten Bormann'; rohc@ietf.org Subject: [rohc] CRC calculation example in ROHC implementer's guide Carsten, I am not very familiar with CRC calculations and I have a question = about the algorithm you provided in the ROHC implementer's guide. Actually, I = want to make sure I get it straight : a) Assume the data on which the CRC is to be calculated is located = somewhere in memory; b) The CRC calculation starts with the LSB of the first byte and bits = are processed sequentially until the MSB of the first byte is reached and processed; c) Then, it processes the LSB of the second byte and progresses until = it reaches the MSB of the second byte; d) Bits are processed from LSB to MSB until the last byte is reached = and processed. The last bit processed is thus the MSB of the last byte. Do I have the proper understanding? I have not seen anything in RFC-3095 saying that for each byte, the LSB = is the first bit that is shifted in the calculation register. Instead, I = was under the impression that the data over which the CRC is calculated = would simply be treated as a stream of bits in memory, starting with the MSB = of the first byte and progressing linearly until the LSB of the last byte. Was this method chosen so bits are processed in the order they are sent = out on the network? (Assuming all link layers send the LSB first.) Thanks, R=E9mi. _______________________________________________ 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 Wed Jul 30 10:08:08 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 KAA01852 for ; Wed, 30 Jul 2003 10:08:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrcE-0001v8-RF for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 10:07:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UE7gFp007376 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 10:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrcE-0001ut-NP for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 10:07: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 KAA01800 for ; Wed, 30 Jul 2003 10:07:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrcC-0000No-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 10:07:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hrcB-0000Nl-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 10:07:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrbZ-0001hF-4x; Wed, 30 Jul 2003 10:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrap-0001gn-KM for rohc@optimus.ietf.org; Wed, 30 Jul 2003 10:06:15 -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 KAA01660 for ; Wed, 30 Jul 2003 10:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrak-0000NY-00 for rohc@ietf.org; Wed, 30 Jul 2003 10:06:10 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19hraj-0000NV-00 for rohc@ietf.org; Wed, 30 Jul 2003 10:06:09 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 09:41:53 -0400 Message-ID: From: Remi Pelland To: "'Alan Kennington'" , "'rohc@ietf.org'" Subject: RE: [rohc] ROHC compression ratio Date: Wed, 30 Jul 2003 09:41:52 -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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Alan, I used your IR packet to validate my parsing algorithm, and I found = that in the RTP part of the dynamic context an empty Generic CSRC List is = present although the associated CC field is 0. Section 4.3.3 of the = Implementer's Guide says that when the CC field is 0, the Generic CSRC List is not included in the dynamic chain. Salut, Remi. -----Original Message----- From: Alan Kennington [mailto:ak1.rohc@topology.org] Sent: Wednesday, July 30, 2003 5:16 AM To: J=FCrgen Quittek Cc: ROHC mailing list; Alan Kennington Subject: Re: [rohc] ROHC compression ratio On Wed, Jul 30, 2003 at 10:11:44AM +0200, J=FCrgen Quittek wrote: >=20 > Is there a theoretical proof that compressed headers are always > shorter than uncompressed ones (for the already standardized = profiles)? >=20 > If not, is there a theoretical limit of how much a compressed > header can exceed the size of an uncompressed one? Juergen, Individual compressed packets are often larger than the original IPv4 packet. I see this often when I am sending IR packets in ROHC RTP profile = 0x0001. Here is an example from one of my packet logs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TX context: CID=3D5 profile=3D1 mode=3DU trans=3DD tss=3D44960 RND=3D1 = NBO=3D1 rtype=3DIR ROHC packet type=3DIR CRC=3D0xf3 IP version=3D4 protocol=3D17(UDP) IP src=3D192.168.0.1 IP = dst=3D192.168.0.2 UDP src=3D5060 UDP dst=3D5000 SSRC=3D0x3afc4712 TOS=3D0x00000010 TTL=3D64 IP-ID=3D0x0000 DF=3D1 RND=3D1 NBO=3D1 Extn header list: ET=3D0 GP=3D0 PS=3D1 CC=3D0 UDP-CS=3D0x757d RTP: V=3D2 P=3D0 RX=3D1 CC=3D0 M=3D1 PT=3D0x03 SN=3D0x9030(36912) = TS=3D0x0000b040(45120) ROHC packet length =3D 178 octets. ROHC=3D0005 fd0501f3 4011c0a8 0001c0a8 000213c4 13883afc 47121040 = 0000e010 757d908 3 90300000 b0401007 c0afa000 d820a2e1 5a500049 24924924 50004924 = 92492450 004924 92 49245000 49249249 24d820a2 e15a5000 49249249 24500049 24924924 = 50004924 92492 450 00492492 4924d820 a2e15a50 00492492 49245000 49249249 24500049 = 24924924 5000 4924 924924d8 20a2e15a 50004924 92492450 00492492 49245000 49249249 = 24500049 249 24924 IPv4 packet length =3D 174 octets. IP=3D0021 451000ac 00004000 4011b8dd c0a80001 c0a80002 13c41388 = 0098757d 80839030=20 0000b040 3afc4712 d820a2e1 5a500049 24924924 50004924 92492450 00492492 49245000 49249249 24d820a2 e15a5000 49249249 24500049 24924924 50004924 = 92492450 0049249 2 4924d820 a2e15a50 00492492 49245000 49249249 24500049 24924924 = 50004924 924924 d8 20a2e15a 50004924 92492450 00492492 49245000 49249249 24500049 = 24924924 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Normally only IR packets will be larger than the corresponding IPv4 = packets. The "negative compression" can be larger than 4 bytes if you have a = CSRC list or some other kinds of context set-up. There is a limit to the "negative compression" size difference, but I don't know what it is. Perhaps it is about 20 or 24 octets maximum, maybe a bit more.=20 I think it would be difficult, but not impossible, for a UOR-2 or = IR-DYN packet to be larger than the original IP packet. This is, of course, a big issue for implementers who have to keep = within the MTU for a PPP interface for example. If the "negative compressed" packet is larger than the MTU, it may be rejected by the decompressor = end of the link. This is rare for RTP because RTP packets are usually = small. But I imagine that this happens very often for plain UDP and plain IP. To fix this problem, you need to set the MRU about 24 bytes or so = larger than the MTU which the IP layer sees. You can see that if UDP packets are sent out with size equal to the = MTU, then all of the "negative compressing" IR packets will be lost by the = RX side if the MRU equals the MTU of the TX side. Therefore the context will = never be established, and communication will be impossible. Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington website: http://www.topology.org/ city: Adelaide, South Australia coords: 138.59 E, 34.88 S timezone: UTC+0930 http://www.topology.org/site/timezone.html pgp-key: http://www.topology.org/ak/key_ak2.asc note: My e-mail address often changes due to spam abuse. : If your e-mail bounces, please visit = topology.org/extra/email.php _______________________________________________ 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 Wed Jul 30 10:31:14 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 KAA03335 for ; Wed, 30 Jul 2003 10:31:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hryZ-0002ar-71 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 10:30:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UEUlUA009965 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 10:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hryZ-0002ae-4E for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 10:30:47 -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 KAA03316 for ; Wed, 30 Jul 2003 10:30:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hryW-0000Za-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 10:30:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hryW-0000ZX-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 10:30:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrxp-0002Wz-P5; Wed, 30 Jul 2003 10:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrxm-0002WT-OX for rohc@optimus.ietf.org; Wed, 30 Jul 2003 10:29: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 KAA03278 for ; Wed, 30 Jul 2003 10:29:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrxk-0000Yo-00 for rohc@ietf.org; Wed, 30 Jul 2003 10:29:56 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19hrxi-0000YT-00 for rohc@ietf.org; Wed, 30 Jul 2003 10:29:55 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id A20DA50AF0; Wed, 30 Jul 2003 23:59:21 +0930 (CST) Date: Wed, 30 Jul 2003 23:59:21 +0930 From: Alan Kennington To: Remi Pelland Cc: ROHC mailing list , Alan Kennington Subject: Re: [rohc] ROHC compression ratio Message-ID: <20030730235921.A17845@dog.topology.org> Reply-To: Alan Kennington References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from remi.pelland@octasic.com on Wed, Jul 30, 2003 at 09:41:52AM -0400 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Wed, Jul 30, 2003 at 09:41:52AM -0400, Remi Pelland wrote: > > the RTP part of the dynamic context an empty Generic CSRC List is present > although the associated CC field is 0. Section 4.3.3 of the Implementer's > Guide says that when the CC field is 0, the Generic CSRC List is not > included in the dynamic chain. > Remi, Well, that's delightful. That's the first time anyone's checked the correctness of my encoding. Now the ROHC implementer's guide, version 3, part 4.3.1, says =================================================== The generic extension header list starts with an octet that is always present, so its length is one octet, at least. If the 'GP' bit in the first octet is set to 1 then the length of the list is two octets, even if the list is empty. =================================================== Then section 4.3.2 says: =================================================== Section 5.7.7.6 defines the static and dynamic parts of the RTP header. This section indicates a 'Generic CSRC list' field in the dynamic chain, which has a variable length. This field uses the same encoding rules as the 'Generic extension header list' in the IPv4 header, so the same rules apply to its length. =================================================== This seems pretty clear to me - the CSRC list must have at least 1 octet even if CC equals 0. Hmmm. Then this is contradicted in 4.3.3 of the implementer's guide: =================================================== Section 5.7.7.6 defines the static and dynamic parts of the RTP header. In the dynamic part, a 'CC' field indicates the number of CSRC items present in the 'Generic CSRC list'. It should be noted that when the value of this CC field is equal to zero, there is no Generic CSRC list present in the dynamic chain, i.e. the field comment should have said "variable length, present if CC > 0". A 'CC' field can also be found within the 'Generic CSRC list' (when present), and these fields would then have the same meaning. In order to decode a compressed packet correctly it's necessary to know the 'CC' value because it has serious impact on the packet's length. In normal case, the values of the fields are equal. Proposed behavior if the values are different: Both fields are within the RTP dynamic part but only the second 'CC' field resides inside the 'Generic CSRC list' together with the XI items. Since the 'CC' value determines the number of XI items in the CSRC list and isn't used otherwise, the first CC field should be ignored and only the second field (inside the CSRC list) should be used for incoming packets. For outgoing packets both fields should be set to the same value. =================================================== So this means that if CC == 0, then the CSRC list is not present. This is very confusing. It seems to me that even the "clarifications" in the Implementer's guide might be contradictory. So what is the real answer? Salut aussi, Alan Kennington. -------------------------------------------------------------------- nom: Dr. Alan Kennington website: http://www.topology.org/ ville: Adelaide, Australie Me'ridionale coords: 138.59 E, 34.88 S zone UTC: +0930 http://www.topology.org/site/timezone.html clef-pgp: http://www.topology.org/ak/key_ak2.asc note: Mon adresse de courriel se change souvent a` cause du spam. : Si votre courriel bounce, visiter SVP topology.org/extra/email.php _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 10:58:10 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 KAA03955 for ; Wed, 30 Jul 2003 10:58:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsOd-0003Yd-Jw for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 10:57:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UEvhq8013674 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 10:57:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsOd-0003YR-D6 for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 10:57:43 -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 KAA03939 for ; Wed, 30 Jul 2003 10:57:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hsOa-0000pN-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 10:57:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hsOa-0000pK-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 10:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsNx-0003VI-He; Wed, 30 Jul 2003 10:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsNi-0003V0-SH for rohc@optimus.ietf.org; Wed, 30 Jul 2003 10:56:47 -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 KAA03913 for ; Wed, 30 Jul 2003 10:56:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hsNg-0000on-00 for rohc@ietf.org; Wed, 30 Jul 2003 10:56:44 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19hsNf-0000oR-00 for rohc@ietf.org; Wed, 30 Jul 2003 10:56:43 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 15:55:59 +0100 Message-ID: From: "Surtees, Abigail" To: "'Alan Kennington'" , Remi Pelland Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Wed, 30 Jul 2003 15:55:54 +0100 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alan, Remi, I remember we had problems with this at the first interop (hence there = being a section about it in the implementer's guide). In my = understanding and our implementation; for both the CSRC list (and also = for the IP extension header list), there is one byte of zero in the = dynamic chain if the list is empty. =20 Here is the trace of an IR packet from our implementation (showing the = 1 byte lists with ^^^^): 0: FD 01 57 40 11 00 00 00 00 00 00 00 00 33 73 8F : = =FD.W@.........3s. 16: 59 15 64 96 E0 E0 26 30 EE 20 00 00 00 90 35 C0 : Y.d.=E0=E0&0=EE = ....5=C0 ^^^^ 32: 45 5F CA 6A 56 00 04 00 01 02 03 04 05 06 07 50 : = E_=CAjV..........P ^^^^ 48: 4B 54 3A 20 20 20 31 : KT: 1 where the original packet is: 0: 45 E0 00 38 30 EE 00 00 26 11 62 E8 00 00 00 00 : = E=E0.80=EE..&.b=E8.... 16: 00 00 00 00 33 73 8F 59 00 24 00 00 80 35 C0 45 : = ....3s.Y.$...5=C0E 32: 5F CA 6A 56 15 64 96 E0 00 01 02 03 04 05 06 07 : = _=CAjV.d.=E0........ 48: 50 4B 54 3A 20 20 20 31 : PKT: 1 Alan, I think you are right that the implementer's guide appears to be = contradictory and I believe that implementations that have been interop = tested follow 4.3.1 and 4.3.2. =20 Regards, Abbie >-----Original Message----- >From: Alan Kennington [mailto:ak1.rohc@topology.org] >Sent: 30 July 2003 15:29 >To: Remi Pelland >Cc: ROHC mailing list; Alan Kennington >Subject: Re: [rohc] ROHC compression ratio > > >On Wed, Jul 30, 2003 at 09:41:52AM -0400, Remi Pelland wrote: >>=20 >> the RTP part of the dynamic context an empty Generic CSRC=20 >List is present >> although the associated CC field is 0. Section 4.3.3 of the=20 >Implementer's >> Guide says that when the CC field is 0, the Generic CSRC List is not >> included in the dynamic chain. >>=20 > > >Remi, > >Well, that's delightful. That's the first time anyone's checked the >correctness of my encoding. > >Now the ROHC implementer's guide, version 3, part 4.3.1, says > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > The generic extension header list starts with an octet that=20 >is always > present, so its length is one octet, at least. If the 'GP' bit in > the first octet is set to 1 then the length of the list is two > octets, even if the list is empty. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >Then section 4.3.2 says: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Section 5.7.7.6 defines the static and dynamic parts of the RTP > header. This section indicates a 'Generic CSRC list' field in the > dynamic chain, which has a variable length. This field=20 >uses the same > encoding rules as the 'Generic extension header list' in the IPv4 > header, so the same rules apply to its length. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >This seems pretty clear to me - the CSRC list must have at=20 >least 1 octet >even if CC equals 0. > >Hmmm. Then this is contradicted in 4.3.3 of the implementer's guide: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Section 5.7.7.6 defines the static and dynamic parts of the RTP > header. In the dynamic part, a 'CC' field indicates the number of > CSRC items present in the 'Generic CSRC list'. It should be noted > that when the value of this CC field is equal to zero, there is no > Generic CSRC list present in the dynamic chain, i.e. the field > comment should have said "variable length, present if CC >=20 >0". A 'CC' > field can also be found within the 'Generic CSRC list' (when > present), and these fields would then have the same=20 >meaning. In order > to decode a compressed packet correctly it's necessary to know the > 'CC' value because it has serious impact on the packet's length. = In > normal case, the values of the fields are equal. > > Proposed behavior if the values are different: > Both fields are within the RTP dynamic part but only the second > 'CC' field resides inside the 'Generic CSRC list' together with > the XI items. Since the 'CC' value determines the number of XI > items in the CSRC list and isn't used otherwise, the first CC > field should be ignored and only the second field=20 >(inside the CSRC > list) should be used for incoming packets. For outgoing packets > both fields should be set to the same value. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >So this means that if CC =3D=3D 0, then the CSRC list is not present. >This is very confusing. It seems to me that even the "clarifications" >in the Implementer's guide might be contradictory. > >So what is the real answer? > >Salut aussi, >Alan Kennington. > >-------------------------------------------------------------------- > nom: Dr. Alan Kennington > website: http://www.topology.org/ > ville: Adelaide, Australie Me'ridionale > coords: 138.59 E, 34.88 S >zone UTC: +0930 http://www.topology.org/site/timezone.html >clef-pgp: http://www.topology.org/ak/key_ak2.asc > note: Mon adresse de courriel se change souvent a` cause du spam. > : Si votre courriel bounce, visiter SVP=20 >topology.org/extra/email.php > >_______________________________________________ >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 Wed Jul 30 11:10:04 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 LAA04249 for ; Wed, 30 Jul 2003 11:10:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsaC-00040b-VL for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 11:09:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UF9ekK015403 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 11:09:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsaC-00040M-Ru for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11:09:40 -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 LAA04229 for ; Wed, 30 Jul 2003 11:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hsaA-0000ww-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 11:09:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hsa9-0000wt-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 11:09:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsZY-0003xd-So; Wed, 30 Jul 2003 11:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsYv-0003w3-FP for rohc@optimus.ietf.org; Wed, 30 Jul 2003 11:08:21 -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 LAA04212 for ; Wed, 30 Jul 2003 11:08:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hsYs-0000wC-00 for rohc@ietf.org; Wed, 30 Jul 2003 11:08:18 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19hsYq-0000vq-00 for rohc@ietf.org; Wed, 30 Jul 2003 11:08:17 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 49DF68A5F7; Thu, 31 Jul 2003 00:37:44 +0930 (CST) Date: Thu, 31 Jul 2003 00:37:44 +0930 From: Alan Kennington To: Remi Pelland Cc: ROHC mailing list , Alan Kennington Subject: Re: FW: [rohc] CRC calculation example in ROHC implementer's guide Message-ID: <20030731003744.A18618@dog.topology.org> Reply-To: Alan Kennington References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from remi.pelland@octasic.com on Wed, Jul 30, 2003 at 09:20:01AM -0400 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Wed, Jul 30, 2003 at 09:20:01AM -0400, Remi Pelland wrote: > > Does anyone have any comments on my understanding of the CRC calculation - > please see below? I haven't heard anything back from Carsten yet, and I > really do need this information quite soon. > Re'mi, I'm not an expert on CRC coding, but I'll say how I see the story here. The CRC-8 in ROHC (RFC 3095) is identical to the CRC8 in ATM cells, where 8 bits protect 32 bits in the 5 octet header. (In fact, I believe this actually gives you at least 1 bit of error correction, not just detection.) The CRC-32 in ROHC is identical to the CRC-32 in AAL-5. I know about these because I coded them in simulation software for AAL and ATM in the olden days. Now the Telcos always number bits from left to right, and CCITT (in the olden days) used to do this, whereas computer people number the bits from the right. So there has always been confusion because of this. (I once worked in a company where the software people wrote all of the software with the bits backwards relative to the hardware people, and they only discovered this after they worked separately for 12 months!) Since the Telco sector thinks that bit 0 is on the left, that means that the ROHC CRC polynomials follow the Telco thinking rather computer science. The order in which bits are fed onto the line is not knowable from layers 4, 3 and 2 in which we are working. Some links might even send the bits in parallel, or interleaved etc. Therefore chronological order of bits cannot logically be referred to when defining CRC calculations. I checked Carsten Bormann's algorithms relative to my old ATM and AAL5 software, and the CRC values are correct according to those definitions. A consequence of this is that the C or Perl algorithms look a bit strange. About the total ordering of bits, the order of bits must be as if they were transmitted LSBit first, but the bytes all look backwards to a computer scientist: 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 <== power of 2 octet 0 octet 1 So the processing shifts the computer scientist's LSBit into the register first, and progresses through the octets from first to last. So I agree with your steps a to d, but this is because of the Telco/PTT bit-ordering, not because of the physical layer temporal order. Cheers, Alan. PS. As the Germans always say: Alles ohne Gewa"hr! -------------------------------------------------------------------- name: Dr. Alan Kennington website: http://www.topology.org/ city: Adelaide, South Australia coords: 138.59 E, 34.88 S timezone: UTC+0930 http://www.topology.org/site/timezone.html pgp-key: http://www.topology.org/ak/key_ak2.asc note: My e-mail address often changes due to spam abuse. : If your e-mail bounces, please visit topology.org/extra/email.php _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 11:18:03 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 LAA04629 for ; Wed, 30 Jul 2003 11:18:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hshu-0004Gq-BY for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 11:17:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFHcQv016410 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 11:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hshu-0004Gb-73 for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11:17:38 -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 LAA04578 for ; Wed, 30 Jul 2003 11:17:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hsht-00010o-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 11:17:37 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hshs-00010l-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 11:17:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hshJ-00048U-Po; Wed, 30 Jul 2003 11:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsgl-00046Q-C0 for rohc@optimus.ietf.org; Wed, 30 Jul 2003 11:16:27 -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 LAA04466 for ; Wed, 30 Jul 2003 11:15:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hsfZ-0000zS-00 for rohc@ietf.org; Wed, 30 Jul 2003 11:15:13 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19hsfX-0000yq-00 for rohc@ietf.org; Wed, 30 Jul 2003 11:15:12 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id CBF528A805; Thu, 31 Jul 2003 00:44:38 +0930 (CST) Date: Thu, 31 Jul 2003 00:44:38 +0930 From: Alan Kennington To: "Surtees, Abigail" Cc: ROHC mailing list , Alan Kennington Subject: Re: [rohc] ROHC compression ratio Message-ID: <20030731004438.B18618@dog.topology.org> Reply-To: Alan Kennington References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from abigail.surtees@roke.co.uk on Wed, Jul 30, 2003 at 03:55:54PM +0100 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Wed, Jul 30, 2003 at 03:55:54PM +0100, Surtees, Abigail wrote: > > Alan, I think you are right that the implementer's guide appears to be contradictory and I believe that implementations that have been interop tested follow 4.3.1 and 4.3.2. > Abigail, Hellelujah! I can't believe I got this right considering that I'm working in isolation in the deserts of South Australia with only the RFCs to go by. (Well, to be honest, it's been pouring with rain here for the last 3 days...) Cheers and thanks, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 11:39:05 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 LAA05222 for ; Wed, 30 Jul 2003 11:39:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ht2D-0005CV-HJ for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 11:38:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFcb7Y019985 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 11:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ht2D-0005CG-E9 for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11:38:37 -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 LAA05168 for ; Wed, 30 Jul 2003 11:38:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ht2C-00019N-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 11:38:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ht2B-00019K-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 11:38:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ht1d-00057X-6b; Wed, 30 Jul 2003 11: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 19ht0x-0004ys-9B for rohc@optimus.ietf.org; Wed, 30 Jul 2003 11:37: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 LAA05108 for ; Wed, 30 Jul 2003 11:37:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ht0v-00018k-00 for rohc@ietf.org; Wed, 30 Jul 2003 11:37:17 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19ht0u-00018h-00 for rohc@ietf.org; Wed, 30 Jul 2003 11:37:17 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 11:12:58 -0400 Message-ID: From: Remi Pelland To: "'Surtees, Abigail'" , "'Alan Kennington'" Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Wed, 30 Jul 2003 11:12:58 -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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Abbie, Well, now I'm a bit confused. Originally, my implementation added the = empty CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I removed = it after reading the implementer's guide. I understand that interoperability tests were done with the empty CSRC = list byte present, but the implementer's guide says otherwise in section = 4.3.3( (...)It should be noted that when the value of this CC field is equal = to zero, there is no Generic CSRC list present in the dynamic chain, i.e. = the field comment should have said "variable length, present if CC > 0" = (...) ). I guess because it was very specific to that field, I must have taken = that sentence as a special case for the CSRC list. =20 Now, I don't mind putting the empty byte back, buy I want to be sure = I'm doing the right thing. So I ask: what is the proper way to handle = empty CSRC lists? Peter, Lars-Erik any thoughts? Thanks, R=E9mi. -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Wednesday, July 30, 2003 10:56 AM To: 'Alan Kennington'; Remi Pelland Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Hi Alan, Remi, I remember we had problems with this at the first interop (hence there = being a section about it in the implementer's guide). In my understanding = and our implementation; for both the CSRC list (and also for the IP extension = header list), there is one byte of zero in the dynamic chain if the list is = empty. Here is the trace of an IR packet from our implementation (showing the = 1 byte lists with ^^^^): 0: FD 01 57 40 11 00 00 00 00 00 00 00 00 33 73 8F : = =FD.W@.........3s. 16: 59 15 64 96 E0 E0 26 30 EE 20 00 00 00 90 35 C0 : Y.d.=E0=E0&0=EE = ....5=C0 ^^^^ 32: 45 5F CA 6A 56 00 04 00 01 02 03 04 05 06 07 50 : = E_=CAjV..........P ^^^^ 48: 4B 54 3A 20 20 20 31 : KT: 1 where the original packet is: 0: 45 E0 00 38 30 EE 00 00 26 11 62 E8 00 00 00 00 : = E=E0.80=EE..&.b=E8.... 16: 00 00 00 00 33 73 8F 59 00 24 00 00 80 35 C0 45 : = ....3s.Y.$...5=C0E 32: 5F CA 6A 56 15 64 96 E0 00 01 02 03 04 05 06 07 : = _=CAjV.d.=E0........ 48: 50 4B 54 3A 20 20 20 31 : PKT: 1 Alan, I think you are right that the implementer's guide appears to be contradictory and I believe that implementations that have been interop tested follow 4.3.1 and 4.3.2. =20 Regards, Abbie >-----Original Message----- >From: Alan Kennington [mailto:ak1.rohc@topology.org] >Sent: 30 July 2003 15:29 >To: Remi Pelland >Cc: ROHC mailing list; Alan Kennington >Subject: Re: [rohc] ROHC compression ratio > > >On Wed, Jul 30, 2003 at 09:41:52AM -0400, Remi Pelland wrote: >>=20 >> the RTP part of the dynamic context an empty Generic CSRC=20 >List is present >> although the associated CC field is 0. Section 4.3.3 of the=20 >Implementer's >> Guide says that when the CC field is 0, the Generic CSRC List is not >> included in the dynamic chain. >>=20 > > >Remi, > >Well, that's delightful. That's the first time anyone's checked the >correctness of my encoding. > >Now the ROHC implementer's guide, version 3, part 4.3.1, says > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > The generic extension header list starts with an octet that=20 >is always > present, so its length is one octet, at least. If the 'GP' bit in > the first octet is set to 1 then the length of the list is two > octets, even if the list is empty. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >Then section 4.3.2 says: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Section 5.7.7.6 defines the static and dynamic parts of the RTP > header. This section indicates a 'Generic CSRC list' field in the > dynamic chain, which has a variable length. This field=20 >uses the same > encoding rules as the 'Generic extension header list' in the IPv4 > header, so the same rules apply to its length. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >This seems pretty clear to me - the CSRC list must have at=20 >least 1 octet >even if CC equals 0. > >Hmmm. Then this is contradicted in 4.3.3 of the implementer's guide: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Section 5.7.7.6 defines the static and dynamic parts of the RTP > header. In the dynamic part, a 'CC' field indicates the number of > CSRC items present in the 'Generic CSRC list'. It should be noted > that when the value of this CC field is equal to zero, there is no > Generic CSRC list present in the dynamic chain, i.e. the field > comment should have said "variable length, present if CC >=20 >0". A 'CC' > field can also be found within the 'Generic CSRC list' (when > present), and these fields would then have the same=20 >meaning. In order > to decode a compressed packet correctly it's necessary to know the > 'CC' value because it has serious impact on the packet's length. = In > normal case, the values of the fields are equal. > > Proposed behavior if the values are different: > Both fields are within the RTP dynamic part but only the second > 'CC' field resides inside the 'Generic CSRC list' together with > the XI items. Since the 'CC' value determines the number of XI > items in the CSRC list and isn't used otherwise, the first CC > field should be ignored and only the second field=20 >(inside the CSRC > list) should be used for incoming packets. For outgoing packets > both fields should be set to the same value. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >So this means that if CC =3D=3D 0, then the CSRC list is not present. >This is very confusing. It seems to me that even the "clarifications" >in the Implementer's guide might be contradictory. > >So what is the real answer? > >Salut aussi, >Alan Kennington. > >-------------------------------------------------------------------- > nom: Dr. Alan Kennington > website: http://www.topology.org/ > ville: Adelaide, Australie Me'ridionale > coords: 138.59 E, 34.88 S >zone UTC: +0930 http://www.topology.org/site/timezone.html >clef-pgp: http://www.topology.org/ak/key_ak2.asc > note: Mon adresse de courriel se change souvent a` cause du spam. > : Si votre courriel bounce, visiter SVP=20 >topology.org/extra/email.php > >_______________________________________________ >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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 12:35:04 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 MAA07436 for ; Wed, 30 Jul 2003 12:35:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htuQ-0008Ij-1P for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 12:34:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGYcLY031908 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 12:34:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htuP-0008IZ-SQ for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:34:37 -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 MAA07361 for ; Wed, 30 Jul 2003 12:34:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htuO-0001e5-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 12:34:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htuN-0001e2-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 12:34:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19http-00088H-Be; Wed, 30 Jul 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19httJ-00086L-Jv for rohc@optimus.ietf.org; Wed, 30 Jul 2003 12:33:29 -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 MAA07306 for ; Wed, 30 Jul 2003 12:33:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19httH-0001cq-00 for rohc@ietf.org; Wed, 30 Jul 2003 12:33:27 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19httF-0001cn-00 for rohc@ietf.org; Wed, 30 Jul 2003 12:33:25 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 12:09:06 -0400 Message-ID: From: Remi Pelland To: "'Surtees, Abigail'" Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Wed, 30 Jul 2003 12:09:05 -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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Abbie, I was just wondering: the interop tests you were mentionning, were they = done before or after publication of version 03 of the implementer's guide? I was just thinking that if the interop was done before this particular publication, perhaps the intent was to remove the empty CSRC list byte = (to improve compression, I guess) even though the prior tests were made = with the empty CSRC list byte present. I noticed that the sentence saying that "the Generic CSRC List should = not be present when CC=3D0" was not in the implementer's guide before version = 03 (February 28, 2003). =20 So I'm thinking that this may have been added after the interop tests = you were talking about. Just trying to figure this out... Thanks, Remi. -----Original Message----- From: Remi Pelland [mailto:remi.pelland@octasic.com] Sent: Wednesday, July 30, 2003 11:13 AM To: 'Surtees, Abigail'; 'Alan Kennington' Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Hi Abbie, Well, now I'm a bit confused. Originally, my implementation added the = empty CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I removed = it after reading the implementer's guide. I understand that interoperability tests were done with the empty CSRC = list byte present, but the implementer's guide says otherwise in section = 4.3.3( (...)It should be noted that when the value of this CC field is equal = to zero, there is no Generic CSRC list present in the dynamic chain, i.e. = the field comment should have said "variable length, present if CC > 0" = (...) ). I guess because it was very specific to that field, I must have taken = that sentence as a special case for the CSRC list. =20 Now, I don't mind putting the empty byte back, buy I want to be sure = I'm doing the right thing. So I ask: what is the proper way to handle = empty CSRC lists? Peter, Lars-Erik any thoughts? Thanks, R=E9mi. -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Wednesday, July 30, 2003 10:56 AM To: 'Alan Kennington'; Remi Pelland Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Hi Alan, Remi, I remember we had problems with this at the first interop (hence there = being a section about it in the implementer's guide). In my understanding = and our implementation; for both the CSRC list (and also for the IP extension = header list), there is one byte of zero in the dynamic chain if the list is = empty. Here is the trace of an IR packet from our implementation (showing the = 1 byte lists with ^^^^): 0: FD 01 57 40 11 00 00 00 00 00 00 00 00 33 73 8F : = =FD.W@.........3s. 16: 59 15 64 96 E0 E0 26 30 EE 20 00 00 00 90 35 C0 : Y.d.=E0=E0&0=EE = ....5=C0 ^^^^ 32: 45 5F CA 6A 56 00 04 00 01 02 03 04 05 06 07 50 : = E_=CAjV..........P ^^^^ 48: 4B 54 3A 20 20 20 31 : KT: 1 where the original packet is: 0: 45 E0 00 38 30 EE 00 00 26 11 62 E8 00 00 00 00 : = E=E0.80=EE..&.b=E8.... 16: 00 00 00 00 33 73 8F 59 00 24 00 00 80 35 C0 45 : = ....3s.Y.$...5=C0E 32: 5F CA 6A 56 15 64 96 E0 00 01 02 03 04 05 06 07 : = _=CAjV.d.=E0........ 48: 50 4B 54 3A 20 20 20 31 : PKT: 1 Alan, I think you are right that the implementer's guide appears to be contradictory and I believe that implementations that have been interop tested follow 4.3.1 and 4.3.2. =20 Regards, Abbie >-----Original Message----- >From: Alan Kennington [mailto:ak1.rohc@topology.org] >Sent: 30 July 2003 15:29 >To: Remi Pelland >Cc: ROHC mailing list; Alan Kennington >Subject: Re: [rohc] ROHC compression ratio > > >On Wed, Jul 30, 2003 at 09:41:52AM -0400, Remi Pelland wrote: >>=20 >> the RTP part of the dynamic context an empty Generic CSRC=20 >List is present >> although the associated CC field is 0. Section 4.3.3 of the=20 >Implementer's >> Guide says that when the CC field is 0, the Generic CSRC List is not >> included in the dynamic chain. >>=20 > > >Remi, > >Well, that's delightful. That's the first time anyone's checked the >correctness of my encoding. > >Now the ROHC implementer's guide, version 3, part 4.3.1, says > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > The generic extension header list starts with an octet that=20 >is always > present, so its length is one octet, at least. If the 'GP' bit in > the first octet is set to 1 then the length of the list is two > octets, even if the list is empty. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >Then section 4.3.2 says: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Section 5.7.7.6 defines the static and dynamic parts of the RTP > header. This section indicates a 'Generic CSRC list' field in the > dynamic chain, which has a variable length. This field=20 >uses the same > encoding rules as the 'Generic extension header list' in the IPv4 > header, so the same rules apply to its length. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >This seems pretty clear to me - the CSRC list must have at=20 >least 1 octet >even if CC equals 0. > >Hmmm. Then this is contradicted in 4.3.3 of the implementer's guide: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Section 5.7.7.6 defines the static and dynamic parts of the RTP > header. In the dynamic part, a 'CC' field indicates the number of > CSRC items present in the 'Generic CSRC list'. It should be noted > that when the value of this CC field is equal to zero, there is no > Generic CSRC list present in the dynamic chain, i.e. the field > comment should have said "variable length, present if CC >=20 >0". A 'CC' > field can also be found within the 'Generic CSRC list' (when > present), and these fields would then have the same=20 >meaning. In order > to decode a compressed packet correctly it's necessary to know the > 'CC' value because it has serious impact on the packet's length. = In > normal case, the values of the fields are equal. > > Proposed behavior if the values are different: > Both fields are within the RTP dynamic part but only the second > 'CC' field resides inside the 'Generic CSRC list' together with > the XI items. Since the 'CC' value determines the number of XI > items in the CSRC list and isn't used otherwise, the first CC > field should be ignored and only the second field=20 >(inside the CSRC > list) should be used for incoming packets. For outgoing packets > both fields should be set to the same value. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >So this means that if CC =3D=3D 0, then the CSRC list is not present. >This is very confusing. It seems to me that even the "clarifications" >in the Implementer's guide might be contradictory. > >So what is the real answer? > >Salut aussi, >Alan Kennington. > >-------------------------------------------------------------------- > nom: Dr. Alan Kennington > website: http://www.topology.org/ > ville: Adelaide, Australie Me'ridionale > coords: 138.59 E, 34.88 S >zone UTC: +0930 http://www.topology.org/site/timezone.html >clef-pgp: http://www.topology.org/ak/key_ak2.asc > note: Mon adresse de courriel se change souvent a` cause du spam. > : Si votre courriel bounce, visiter SVP=20 >topology.org/extra/email.php > >_______________________________________________ >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 _______________________________________________ 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 Wed Jul 30 12:54:04 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 MAA07989 for ; Wed, 30 Jul 2003 12:54:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huCq-0000il-1P for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 12:53:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGrecO002765 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 12:53:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huCp-0000iW-U8 for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:53: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 MAA07979 for ; Wed, 30 Jul 2003 12:53:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huCo-0001kq-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 12:53:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19huCn-0001kn-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 12:53:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huCD-0000g3-HN; Wed, 30 Jul 2003 12:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huBR-0000eb-1C for rohc@optimus.ietf.org; Wed, 30 Jul 2003 12:52:13 -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 MAA07945 for ; Wed, 30 Jul 2003 12:52:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huBP-0001kG-00 for rohc@ietf.org; Wed, 30 Jul 2003 12:52:11 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19huBO-0001k7-00 for rohc@ietf.org; Wed, 30 Jul 2003 12:52:10 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 17:51:40 +0100 Message-ID: From: "Surtees, Abigail" To: "'Remi Pelland'" , "'Alan Kennington'" Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Wed, 30 Jul 2003 17:51:34 +0100 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alan, Remi, Answering two mails in one: There have been 4 rohc interop tests July 2001, Nov 2001, April 2002 = and Oct 2002. We attended the first 3 but not the 4th so I may have = missed something there. However, I think that the byte of zero has to = be present otherwise the IR packet cannot be decompressed correctly for = the following reason. =20 (If I'm wrong and/or there was something I missed at the 4th interop = then I hope someone will correct me...) Both CRSC lists and generic extension header lists are encoded = according to list compression in section 5.8. When the decompressor reads the dynamic chain it reads the parts of the = IP header. When it reads the next byte how does it know whether it is = the first byte of generic extension header list or it is the first byte = of UDP checksum? =20 Surely it must read a byte of header list that indicates the list is = empty according to 5.8.6 and then go on to read the UDP checksum? This follows through then to the CSRC list (even though the CC field in = the dynamic chain can indicate that the CSRC list will be empty). Having the byte there allows generic list processing to look at the = header in the appropriate place. If this were not the case then there = would have to be extra logic (which I believe is not in the RFC) to say = check the protocol field to find out if there is a generic IP extension = header list present and check the CC field to find out if the CSRC list = is present. Consequently I think the byte should be present. I hope this makes sense. Regards, Abbie Abbie Surtees Engineer Networks Roke Manor Research Ltd Tel: +44 (0) 1794 833131 > >Well, now I'm a bit confused. Originally, my implementation=20 >added the empty >CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I=20 >removed it >after reading the implementer's guide. > >I understand that interoperability tests were done with the=20 >empty CSRC list >byte present, but the implementer's guide says otherwise in=20 >section 4.3.3( >(...)It should be noted that when the value of this CC field=20 >is equal to >zero, there is no Generic CSRC list present in the dynamic=20 >chain, i.e. the >field comment should have said "variable length, present if CC=20 >> 0" (...) ). >I guess because it was very specific to that field, I must=20 >have taken that >sentence as a special case for the CSRC list. =20 > >Now, I don't mind putting the empty byte back, buy I want to=20 >be sure I'm >doing the right thing. So I ask: what is the proper way to=20 >handle empty >CSRC lists? Peter, Lars-Erik any thoughts? > >Thanks, >R=E9mi. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 14:26:02 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 OAA11862 for ; Wed, 30 Jul 2003 14:26:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvdp-00068N-TH for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 14:25:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIPb6I023573 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 14:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvdp-000688-Q0 for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 14:25:37 -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 OAA11829 for ; Wed, 30 Jul 2003 14:25:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvdn-0002Xi-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 14:25:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hvdm-0002Xf-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 14:25:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvdF-00065F-Ap; Wed, 30 Jul 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvck-00063s-8e for rohc@optimus.ietf.org; Wed, 30 Jul 2003 14:24:30 -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 OAA11766 for ; Wed, 30 Jul 2003 14:24:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvch-0002Ws-00 for rohc@ietf.org; Wed, 30 Jul 2003 14:24:27 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19hvcg-0002Wp-00 for rohc@ietf.org; Wed, 30 Jul 2003 14:24:26 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 14:00:09 -0400 Message-ID: From: Remi Pelland To: "'Surtees, Abigail'" Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Wed, 30 Jul 2003 14:00:08 -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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Abbie, I agree with you that for IP extension headers, the generic extension = header list must always be present, empty or not, otherwise it would be = impossible to properly parse the packet. The second paragraph of section 4.3.1 in = the implementer's guide says that exactly. However, my understanding of the beginning of section 4.3.3 is that the meaning of the generic CSRC list field is modified with respect to what = is defined in the RFC. In my understanding, sections 4.3.1 and 4.3.3 do create a difference = between the generic extension header list and the generic CSRC list in the particular case where these lists are empty: for IP extension header, 1 = or 2 bytes are present, while for CSRC list no byte is present (presence = being established based on the CC field of the first byte of the RTP dynamic chain). Thanks, Remi. -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Wednesday, July 30, 2003 12:52 PM To: 'Remi Pelland'; 'Alan Kennington' Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Hi Alan, Remi, Answering two mails in one: There have been 4 rohc interop tests July 2001, Nov 2001, April 2002 = and Oct 2002. We attended the first 3 but not the 4th so I may have missed something there. However, I think that the byte of zero has to be = present otherwise the IR packet cannot be decompressed correctly for the = following reason. =20 (If I'm wrong and/or there was something I missed at the 4th interop = then I hope someone will correct me...) Both CRSC lists and generic extension header lists are encoded = according to list compression in section 5.8. When the decompressor reads the dynamic chain it reads the parts of the = IP header. When it reads the next byte how does it know whether it is the first byte of generic extension header list or it is the first byte of = UDP checksum? =20 Surely it must read a byte of header list that indicates the list is = empty according to 5.8.6 and then go on to read the UDP checksum? This follows through then to the CSRC list (even though the CC field in = the dynamic chain can indicate that the CSRC list will be empty). Having the byte there allows generic list processing to look at the = header in the appropriate place. If this were not the case then there would = have to be extra logic (which I believe is not in the RFC) to say check the protocol field to find out if there is a generic IP extension header = list present and check the CC field to find out if the CSRC list is present. Consequently I think the byte should be present. I hope this makes sense. Regards, Abbie Abbie Surtees Engineer Networks Roke Manor Research Ltd Tel: +44 (0) 1794 833131 > >Well, now I'm a bit confused. Originally, my implementation=20 >added the empty >CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I=20 >removed it >after reading the implementer's guide. > >I understand that interoperability tests were done with the=20 >empty CSRC list >byte present, but the implementer's guide says otherwise in=20 >section 4.3.3( >(...)It should be noted that when the value of this CC field=20 >is equal to >zero, there is no Generic CSRC list present in the dynamic=20 >chain, i.e. the >field comment should have said "variable length, present if CC=20 >> 0" (...) ). >I guess because it was very specific to that field, I must=20 >have taken that >sentence as a special case for the CSRC list. =20 > >Now, I don't mind putting the empty byte back, buy I want to=20 >be sure I'm >doing the right thing. So I ask: what is the proper way to=20 >handle empty >CSRC lists? Peter, Lars-Erik any thoughts? > >Thanks, >R=E9mi. > _______________________________________________ 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 Wed Jul 30 18:04: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 SAA20323 for ; Wed, 30 Jul 2003 18:04:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3J-0007TU-2b for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 18:04:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UM49I0028689 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 18:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3I-0007R7-SF for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 18:04: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 SAA20227 for ; Wed, 30 Jul 2003 18:04:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz3G-0004FM-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 18:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hz3F-0004FJ-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 18:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz3C-0007NE-C9; Wed, 30 Jul 2003 18:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hz2N-0007LI-EQ for rohc@optimus.ietf.org; Wed, 30 Jul 2003 18:03:11 -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 SAA20104 for ; Wed, 30 Jul 2003 18:03:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hz2K-0004ET-00 for rohc@ietf.org; Wed, 30 Jul 2003 18:03:08 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19hz2J-0004EQ-00 for rohc@ietf.org; Wed, 30 Jul 2003 18:03:07 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 17:38:51 -0400 Message-ID: From: Remi Pelland To: "'Surtees, Abigail'" , "'Alan Kennington'" Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Wed, 30 Jul 2003 17:38:50 -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 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA20105 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Abbie and Alan, I found the following message sent by Lars-Erik which discusses the chang= es he intended to do to the implementer's guide, just before version 03 was released. Point #3 discusses the empty generic CSRC list. Based on his comments, it seems like the generic CSRC list field must not be included when the list is empty. =20 http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01308.ht= ml However, this only applies to the CSRC list and not to the IP extension header lists. Salut, Remi. -----Original Message----- From: Remi Pelland [mailto:remi.pelland@octasic.com] Sent: Wednesday, July 30, 2003 2:00 PM To: 'Surtees, Abigail' Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Abbie, I agree with you that for IP extension headers, the generic extension hea= der list must always be present, empty or not, otherwise it would be impossib= le to properly parse the packet. The second paragraph of section 4.3.1 in t= he implementer's guide says that exactly. However, my understanding of the beginning of section 4.3.3 is that the meaning of the generic CSRC list field is modified with respect to what i= s defined in the RFC. In my understanding, sections 4.3.1 and 4.3.3 do create a difference betw= een the generic extension header list and the generic CSRC list in the particular case where these lists are empty: for IP extension header, 1 o= r 2 bytes are present, while for CSRC list no byte is present (presence being established based on the CC field of the first byte of the RTP dynamic chain). Thanks, Remi. -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Wednesday, July 30, 2003 12:52 PM To: 'Remi Pelland'; 'Alan Kennington' Cc: ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Hi Alan, Remi, Answering two mails in one: There have been 4 rohc interop tests July 2001, Nov 2001, April 2002 and = Oct 2002. We attended the first 3 but not the 4th so I may have missed something there. However, I think that the byte of zero has to be presen= t otherwise the IR packet cannot be decompressed correctly for the followin= g reason. =20 (If I'm wrong and/or there was something I missed at the 4th interop then= I hope someone will correct me...) Both CRSC lists and generic extension header lists are encoded according = to list compression in section 5.8. When the decompressor reads the dynamic chain it reads the parts of the I= P header. When it reads the next byte how does it know whether it is the first byte of generic extension header list or it is the first byte of UD= P checksum? =20 Surely it must read a byte of header list that indicates the list is empt= y according to 5.8.6 and then go on to read the UDP checksum? This follows through then to the CSRC list (even though the CC field in t= he dynamic chain can indicate that the CSRC list will be empty). Having the byte there allows generic list processing to look at the heade= r in the appropriate place. If this were not the case then there would hav= e to be extra logic (which I believe is not in the RFC) to say check the protocol field to find out if there is a generic IP extension header list present and check the CC field to find out if the CSRC list is present. Consequently I think the byte should be present. I hope this makes sense. Regards, Abbie Abbie Surtees Engineer Networks Roke Manor Research Ltd Tel: +44 (0) 1794 833131 > >Well, now I'm a bit confused. Originally, my implementation=20 >added the empty >CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I=20 >removed it >after reading the implementer's guide. > >I understand that interoperability tests were done with the=20 >empty CSRC list >byte present, but the implementer's guide says otherwise in=20 >section 4.3.3( >(...)It should be noted that when the value of this CC field=20 >is equal to >zero, there is no Generic CSRC list present in the dynamic=20 >chain, i.e. the >field comment should have said "variable length, present if CC=20 >> 0" (...) ). >I guess because it was very specific to that field, I must=20 >have taken that >sentence as a special case for the CSRC list. =20 > >Now, I don't mind putting the empty byte back, buy I want to=20 >be sure I'm >doing the right thing. So I ask: what is the proper way to=20 >handle empty >CSRC lists? Peter, Lars-Erik any thoughts? > >Thanks, >R=E9mi. > _______________________________________________ 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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jul 30 19:10:30 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 TAA22753 for ; Wed, 30 Jul 2003 19:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i059-0001UM-M3 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 19:10:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UNA7fH005719 for rohc-archive@odin.ietf.org; Wed, 30 Jul 2003 19: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 19i059-0001UA-IQ for rohc-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 19: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 TAA22747 for ; Wed, 30 Jul 2003 19:10:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i056-00052q-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 19:10:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i055-00052n-00 for rohc-web-archive@ietf.org; Wed, 30 Jul 2003 19: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 19i052-0001To-SI; Wed, 30 Jul 2003 19:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i04D-0001TN-VW for rohc@optimus.ietf.org; Wed, 30 Jul 2003 19:09: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 TAA22742 for ; Wed, 30 Jul 2003 19:09:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i04A-00052J-00 for rohc@ietf.org; Wed, 30 Jul 2003 19:09:06 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19i049-000521-00 for rohc@ietf.org; Wed, 30 Jul 2003 19:09:06 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id D3C148A632; Thu, 31 Jul 2003 08:38:31 +0930 (CST) Date: Thu, 31 Jul 2003 08:38:31 +0930 From: Alan Kennington To: Remi Pelland Cc: ROHC mailing list Message-ID: <20030731083831.A20558@dog.topology.org> Reply-To: Alan Kennington References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from remi.pelland@octasic.com on Wed, Jul 30, 2003 at 09:41:52AM -0400 X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] interop testing over TCP/IP? 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , On Wed, Jul 30, 2003 at 09:41:52AM -0400, Remi Pelland wrote: > > > I used your IR packet to validate my parsing algorithm, and I found that in > the RTP part of the dynamic context an empty Generic CSRC List is present > although the associated CC field is 0. Section 4.3.3 of the Implementer's > Guide says that when the CC field is 0, the Generic CSRC List is not > included in the dynamic chain. > Remi, Since you were able to test interoperability of my single packet using a hex dump over the e-mail, this makes me think of an extension of this idea. For people like me who do not have a big travel budget, it would be possible to test interoperability by using "ROHC over UDP/IP". In other words, instead of putting ROHC PDUs in L2 packets, we could define UDP/IP as a kind of link layer substitute. Then we could all test interoperability of our ROHC implementations every day over the net. I guess that one little problem with this is the packet ordering guarantee, but this can be fixed by adding sequence numbers to all ROHC packets and inserting a small delay on the RX side to re-order packets - or else out-of- order packets could be discarded. I guess jitter could be rather high. But certainly "ROHC over UDP/IP" would give a better assessment of interoperability than exchanging hex dumps over e-mail. A really crazy person could define "ROHC over SMTP", I guess. (This reminds me of Carrier Pigeon IP: http://www.ietf.org/rfc/rfc1149.txt?number=1149 http://www.blug.linux.no/rfc1149/ ) Cheers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 31 03:26:35 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 DAA14383 for ; Thu, 31 Jul 2003 03:26:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7p9-0001Mp-8v for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 03:26:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7Q76J005254 for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 03:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7p9-0001Mf-3S for rohc-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 03:26: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 DAA14377 for ; Thu, 31 Jul 2003 03:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7p6-0000Ky-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 03:26:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i7p6-0000Kv-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 03:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7p2-0001MI-JK; Thu, 31 Jul 2003 03:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7og-0001Lw-H1 for rohc@optimus.ietf.org; Thu, 31 Jul 2003 03:25:38 -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 DAA14374 for ; Thu, 31 Jul 2003 03:25:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7oe-0000Kr-00 for rohc@ietf.org; Thu, 31 Jul 2003 03:25:36 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19i7od-0000Kn-00 for rohc@ietf.org; Thu, 31 Jul 2003 03:25:35 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6V7PYjG006606; Thu, 31 Jul 2003 09:25:35 +0200 (MEST) Received: from caffreys (caffreys.ericsson.se [147.214.181.21]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id N8XN7DT5; Thu, 31 Jul 2003 09:25:34 +0200 Date: Thu, 31 Jul 2003 09:30:31 +0200 (CEST) From: Vicknesan Ayadurai X-X-Sender: vick@caffreys.ericsson.se To: Remi Pelland cc: "'Surtees, Abigail'" , "'Alan Kennington'" , ROHC mailing list Subject: RE: [rohc] ROHC compression ratio In-Reply-To: Message-ID: <20030731090802.J6980-100000@caffreys.ericsson.se> MIME-Version: 1.0 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Remi/Abbie/Alan, Thought I'd join in the fray with my "2-octets" worth here... Specific to the CC/Generic CSRC list discussion, we did do some basic CSRC-list compression testing at the 4th interop in Berlin last year. At that point, a CC-value of 0 (in the IRDYN dynamic chain) would still result in a 1-octet Generic CSRC List. In fact, there have been implementations which would produce a 2-octet Generic CSRC list (when said CC-value was 0), since a Generic CSRC list would be produced and subsequently assigned a (1-octet) gen_id as well. I believe I'm partially responsible for the text by Lars-Erik in the link below (forwarded by Remi), since I brought this issue up after the interop event. I also believe the intention now is to interpret a CC-value of 0 as NO Generic CSRC list present, but perhaps that can be confirmed/verified by someone else... Regards, vick +----------------------------------------------------+ Vicknesan AYADURAI SwitchLab, Ericsson Research - Stockholm, Sweden Phone : +46 8 5087 8084 / Fax: +46 8 5087 8090 +----------------------------------------------------+ On Wed, 30 Jul 2003, Remi Pelland wrote: > > Hi Abbie and Alan, > > I found the following message sent by Lars-Erik which discusses the chang= es > he intended to do to the implementer's guide, just before version 03 was > released. Point #3 discusses the empty generic CSRC list. Based on his > comments, it seems like the generic CSRC list field must not be included > when the list is empty. > > http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01308.ht= ml > > However, this only applies to the CSRC list and not to the IP extension > header lists. > > Salut, > Remi. > > > -----Original Message----- > From: Remi Pelland [mailto:remi.pelland@octasic.com] > Sent: Wednesday, July 30, 2003 2:00 PM > To: 'Surtees, Abigail' > Cc: ROHC mailing list > Subject: RE: [rohc] ROHC compression ratio > > > > Abbie, > > I agree with you that for IP extension headers, the generic extension hea= der > list must always be present, empty or not, otherwise it would be impossib= le > to properly parse the packet. The second paragraph of section 4.3.1 in t= he > implementer's guide says that exactly. > > However, my understanding of the beginning of section 4.3.3 is that the > meaning of the generic CSRC list field is modified with respect to what i= s > defined in the RFC. > > In my understanding, sections 4.3.1 and 4.3.3 do create a difference betw= een > the generic extension header list and the generic CSRC list in the > particular case where these lists are empty: for IP extension header, 1 o= r 2 > bytes are present, while for CSRC list no byte is present (presence being > established based on the CC field of the first byte of the RTP dynamic > chain). > > Thanks, > Remi. > > -----Original Message----- > From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] > Sent: Wednesday, July 30, 2003 12:52 PM > To: 'Remi Pelland'; 'Alan Kennington' > Cc: ROHC mailing list > Subject: RE: [rohc] ROHC compression ratio > > > Hi Alan, Remi, > > Answering two mails in one: > > There have been 4 rohc interop tests July 2001, Nov 2001, April 2002 and = Oct > 2002. We attended the first 3 but not the 4th so I may have missed > something there. However, I think that the byte of zero has to be presen= t > otherwise the IR packet cannot be decompressed correctly for the followin= g > reason. > (If I'm wrong and/or there was something I missed at the 4th interop then= I > hope someone will correct me...) > > Both CRSC lists and generic extension header lists are encoded according = to > list compression in section 5.8. > > When the decompressor reads the dynamic chain it reads the parts of the I= P > header. When it reads the next byte how does it know whether it is the > first byte of generic extension header list or it is the first byte of UD= P > checksum? > Surely it must read a byte of header list that indicates the list is empt= y > according to 5.8.6 and then go on to read the UDP checksum? > > This follows through then to the CSRC list (even though the CC field in t= he > dynamic chain can indicate that the CSRC list will be empty). > > Having the byte there allows generic list processing to look at the heade= r > in the appropriate place. If this were not the case then there would hav= e > to be extra logic (which I believe is not in the RFC) to say check the > protocol field to find out if there is a generic IP extension header list > present and check the CC field to find out if the CSRC list is present. > > Consequently I think the byte should be present. > > I hope this makes sense. > > Regards, > > Abbie > > Abbie Surtees > Engineer > Networks > Roke Manor Research Ltd > Tel: +44 (0) 1794 833131 > > > > > >Well, now I'm a bit confused. Originally, my implementation > >added the empty > >CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I > >removed it > >after reading the implementer's guide. > > > >I understand that interoperability tests were done with the > >empty CSRC list > >byte present, but the implementer's guide says otherwise in > >section 4.3.3( > >(...)It should be noted that when the value of this CC field > >is equal to > >zero, there is no Generic CSRC list present in the dynamic > >chain, i.e. the > >field comment should have said "variable length, present if CC > >> 0" (...) ). > >I guess because it was very specific to that field, I must > >have taken that > >sentence as a special case for the CSRC list. > > > >Now, I don't mind putting the empty byte back, buy I want to > >be sure I'm > >doing the right thing. So I ask: what is the proper way to > >handle empty > >CSRC lists? Peter, Lars-Erik any thoughts? > > > >Thanks, > >R=E9mi. > > > > > _______________________________________________ > 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 > > _______________________________________________ > 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 Jul 31 04:06: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 EAA15581 for ; Thu, 31 Jul 2003 04:06:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8Rr-00049s-8t for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 04:06:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V867dH015983 for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 04:06:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8Rr-00049i-2Z for rohc-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 04:06: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 EAA15570 for ; Thu, 31 Jul 2003 04:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i8Ro-0000c9-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 04:06:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19i8Rn-0000c6-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 04:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8Rk-00048C-KA; Thu, 31 Jul 2003 04:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8Qq-00046Y-0L for rohc@optimus.ietf.org; Thu, 31 Jul 2003 04:05: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 EAA15561 for ; Thu, 31 Jul 2003 04:05:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i8Qn-0000bw-00 for rohc@ietf.org; Thu, 31 Jul 2003 04:05:01 -0400 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx with esmtp (Exim 4.12) id 19i8Qm-0000bd-00 for rohc@ietf.org; Thu, 31 Jul 2003 04:05:00 -0400 Received: from windows_bb (internal.effnet.com [192.168.100.159] (may be forged)) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id h6V74P0r016467 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 31 Jul 2003 09:04:26 +0200 Date: Thu, 31 Jul 2003 10:12:25 +0200 To: Vicknesan Ayadurai , Remi Pelland Subject: Re: [rohc] ROHC compression ratio Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: "'Surtees, Abigail'" , "'Alan Kennington'" , ROHC mailing list References: <20030731090802.J6980-100000@caffreys.ericsson.se> From: Tommy Lundemo Organization: Effnet AB MIME-Version: 1.0 Message-ID: In-Reply-To: <20030731090802.J6980-100000@caffreys.ericsson.se> User-Agent: Opera7.11/Win32 M2 build 2887 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by effnet.com id h6V74P0r016467 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vick/Remi/Abbie/Alan/all! I just wanted to give you my opinion on this. The extra (CC=3D0, generic CSRC list=3D0) octet needs to be there accordi= ng to=20 the standard (variable length, not optional field in 5.7.7.6), even thoug= h=20 I agree that for future updates it should not be necessary. The point is that we are trying to get interoperable implementations, then I think we cannot allow the Implementers Guide to override things in the current standard, but only advise on how to implement the present standard and possibly make suggestions on how to improve it in the future. Best Regards / Tommy Lundemo, Effnet AB On Thu, 31 Jul 2003 09:30:31 +0200 (CEST), Vicknesan Ayadurai=20 wrote: > Hi Remi/Abbie/Alan, > > Thought I'd join in the fray with my "2-octets" worth here... > > Specific to the CC/Generic CSRC list discussion, we did do some basic > CSRC-list compression testing at the 4th interop in Berlin last year. > > At that point, a CC-value of 0 (in the IRDYN dynamic chain) would > still result in a 1-octet Generic CSRC List. In fact, there have been > implementations which would produce a 2-octet Generic CSRC list (when > said CC-value was 0), since a Generic CSRC list would be produced and > subsequently assigned a (1-octet) gen_id as well. > > I believe I'm partially responsible for the text by Lars-Erik in the > link below (forwarded by Remi), since I brought this issue up after > the interop event. > > I also believe the intention now is to interpret a CC-value of 0 as NO > Generic CSRC list present, but perhaps that can be confirmed/verified > by someone else... > > Regards, > vick > +----------------------------------------------------+ > Vicknesan AYADURAI > SwitchLab, Ericsson Research - Stockholm, Sweden > Phone : +46 8 5087 8084 / Fax: +46 8 5087 8090 > +----------------------------------------------------+ > > On Wed, 30 Jul 2003, Remi Pelland wrote: > >> >> Hi Abbie and Alan, >> >> I found the following message sent by Lars-Erik which discusses the=20 >> changes >> he intended to do to the implementer's guide, just before version 03 w= as >> released. Point #3 discusses the empty generic CSRC list. Based on h= is >> comments, it seems like the generic CSRC list field must not be includ= ed >> when the list is empty. >> >> http://www1.ietf.org/mail-archive/working-=20 >> groups/rohc/current/msg01308.html >> >> However, this only applies to the CSRC list and not to the IP extensio= n >> header lists. >> >> Salut, >> Remi. >> >> >> -----Original Message----- >> From: Remi Pelland [mailto:remi.pelland@octasic.com] >> Sent: Wednesday, July 30, 2003 2:00 PM >> To: 'Surtees, Abigail' >> Cc: ROHC mailing list >> Subject: RE: [rohc] ROHC compression ratio >> >> >> >> Abbie, >> >> I agree with you that for IP extension headers, the generic extension=20 >> header >> list must always be present, empty or not, otherwise it would be=20 >> impossible >> to properly parse the packet. The second paragraph of section 4.3.1 i= n=20 >> the >> implementer's guide says that exactly. >> >> However, my understanding of the beginning of section 4.3.3 is that th= e >> meaning of the generic CSRC list field is modified with respect to wha= t=20 >> is >> defined in the RFC. >> >> In my understanding, sections 4.3.1 and 4.3.3 do create a difference=20 >> between >> the generic extension header list and the generic CSRC list in the >> particular case where these lists are empty: for IP extension header, = 1=20 >> or 2 >> bytes are present, while for CSRC list no byte is present (presence=20 >> being >> established based on the CC field of the first byte of the RTP dynamic >> chain). >> >> Thanks, >> Remi. >> >> -----Original Message----- >> From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] >> Sent: Wednesday, July 30, 2003 12:52 PM >> To: 'Remi Pelland'; 'Alan Kennington' >> Cc: ROHC mailing list >> Subject: RE: [rohc] ROHC compression ratio >> >> >> Hi Alan, Remi, >> >> Answering two mails in one: >> >> There have been 4 rohc interop tests July 2001, Nov 2001, April 2002 a= nd=20 >> Oct >> 2002. We attended the first 3 but not the 4th so I may have missed >> something there. However, I think that the byte of zero has to be=20 >> present >> otherwise the IR packet cannot be decompressed correctly for the=20 >> following >> reason. >> (If I'm wrong and/or there was something I missed at the 4th interop=20 >> then I >> hope someone will correct me...) >> >> Both CRSC lists and generic extension header lists are encoded accordi= ng=20 >> to >> list compression in section 5.8. >> >> When the decompressor reads the dynamic chain it reads the parts of th= e=20 >> IP >> header. When it reads the next byte how does it know whether it is th= e >> first byte of generic extension header list or it is the first byte of= =20 >> UDP >> checksum? >> Surely it must read a byte of header list that indicates the list is=20 >> empty >> according to 5.8.6 and then go on to read the UDP checksum? >> >> This follows through then to the CSRC list (even though the CC field i= n=20 >> the >> dynamic chain can indicate that the CSRC list will be empty). >> >> Having the byte there allows generic list processing to look at the=20 >> header >> in the appropriate place. If this were not the case then there would=20 >> have >> to be extra logic (which I believe is not in the RFC) to say check the >> protocol field to find out if there is a generic IP extension header=20 >> list >> present and check the CC field to find out if the CSRC list is present. >> >> Consequently I think the byte should be present. >> >> I hope this makes sense. >> >> Regards, >> >> Abbie >> >> Abbie Surtees >> Engineer >> Networks >> Roke Manor Research Ltd >> Tel: +44 (0) 1794 833131 >> >> >> > >> >Well, now I'm a bit confused. Originally, my implementation >> >added the empty >> >CSRC list byte - as stated in RFC 3095, section 5.7.7.6, but I >> >removed it >> >after reading the implementer's guide. >> > >> >I understand that interoperability tests were done with the >> >empty CSRC list >> >byte present, but the implementer's guide says otherwise in >> >section 4.3.3( >> >(...)It should be noted that when the value of this CC field >> >is equal to >> >zero, there is no Generic CSRC list present in the dynamic >> >chain, i.e. the >> >field comment should have said "variable length, present if CC >> >> 0" (...) ). >> >I guess because it was very specific to that field, I must >> >have taken that >> >sentence as a special case for the CSRC list. >> > >> >Now, I don't mind putting the empty byte back, buy I want to >> >be sure I'm >> >doing the right thing. So I ask: what is the proper way to >> >handle empty >> >CSRC lists? Peter, Lars-Erik any thoughts? >> > >> >Thanks, >> >R=E9mi. >> > >> >> >> _______________________________________________ >> 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 >> >> _______________________________________________ >> 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 > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 31 09:38:36 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 JAA25115 for ; Thu, 31 Jul 2003 09:38:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDdA-0000L4-CZ for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 09:38:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VDc8bN001301 for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 09: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 19iDdA-0000Ku-7K for rohc-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 09:38: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 JAA25079 for ; Thu, 31 Jul 2003 09:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDd8-0003mh-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 09:38:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iDd7-0003md-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 09:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDd3-0000Is-2E; Thu, 31 Jul 2003 09: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 19iDcN-000081-06 for rohc@optimus.ietf.org; Thu, 31 Jul 2003 09:37:20 -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 JAA24947 for ; Thu, 31 Jul 2003 09:37:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDcL-0003ki-00 for rohc@ietf.org; Thu, 31 Jul 2003 09:37:17 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19iDcK-0003jQ-00 for rohc@ietf.org; Thu, 31 Jul 2003 09:37:16 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 14:36:45 +0100 Message-ID: From: "Surtees, Abigail" To: "'Tommy Lundemo'" , Vicknesan Ayadurai , Remi Pelland Cc: "'Alan Kennington'" , ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Thu, 31 Jul 2003 14:36:42 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Tommy, Vick, Remi, Alan, all, Thanks for your opinion Tommy. I agree with you - the Implementer's Guide should clarify things that are ambiguous in the RFC (e.g. how to calculate the CRC) but should not change things that are clear. If it did it would mean that an implementation that does what is specified in the RFC cannot interoperate with one that follows what is in the implementer's guide, which would not be a good state of affairs. If there are changes like this to be made, then they should be made when the RFC progresses to draft standard. If the implementer's guide is also a log of things that need changing then they should be clearly marked or, preferably, put in a separate section e.g. an appendix. Regards, Abbie > >I just wanted to give you my opinion on this. >The extra (CC=0, generic CSRC list=0) octet needs to be there >according to >the standard (variable length, not optional field in 5.7.7.6), >even though >I agree that for future updates it should not be >necessary. > >The point is that we are trying to get interoperable >implementations, then I think we cannot allow the Implementers >Guide to override things in the current standard, but only >advise on how to implement the present standard and possibly >make suggestions on how to improve it in the future. > >Best Regards > >/ Tommy Lundemo, Effnet AB > >On Thu, 31 Jul 2003 09:30:31 +0200 (CEST), Vicknesan Ayadurai > wrote: > >> Hi Remi/Abbie/Alan, >> >> Thought I'd join in the fray with my "2-octets" worth here... >> >> Specific to the CC/Generic CSRC list discussion, we did do some basic >> CSRC-list compression testing at the 4th interop in Berlin last year. >> >> At that point, a CC-value of 0 (in the IRDYN dynamic chain) would >> still result in a 1-octet Generic CSRC List. In fact, there have been >> implementations which would produce a 2-octet Generic CSRC list (when >> said CC-value was 0), since a Generic CSRC list would be produced and >> subsequently assigned a (1-octet) gen_id as well. >> >> I believe I'm partially responsible for the text by Lars-Erik in the >> link below (forwarded by Remi), since I brought this issue up after >> the interop event. >> >> I also believe the intention now is to interpret a CC-value >of 0 as NO >> Generic CSRC list present, but perhaps that can be confirmed/verified >> by someone else... >> >> Regards, >> vick >> +----------------------------------------------------+ >> Vicknesan AYADURAI >> SwitchLab, Ericsson Research - Stockholm, Sweden >> Phone : +46 8 5087 8084 / Fax: +46 8 5087 8090 >> +----------------------------------------------------+ >> _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 31 09:57: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 JAA25894 for ; Thu, 31 Jul 2003 09:57:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDvZ-0000zv-7g for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 09:57:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VDv9XS003829 for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 09:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDvZ-0000zg-4Q for rohc-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 09:57: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 JAA25880 for ; Thu, 31 Jul 2003 09:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDvX-0003xX-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 09:57:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iDvW-0003xU-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 09:57:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDvS-0000wf-Cv; Thu, 31 Jul 2003 09:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDvL-0000wD-9a for rohc@optimus.ietf.org; Thu, 31 Jul 2003 09:56: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 JAA25860 for ; Thu, 31 Jul 2003 09:56:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDvI-0003xC-00 for rohc@ietf.org; Thu, 31 Jul 2003 09:56:52 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19iDvH-0003x9-00 for rohc@ietf.org; Thu, 31 Jul 2003 09:56:51 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 09:32:29 -0400 Message-ID: From: Remi Pelland To: "'Surtees, Abigail'" , "'Tommy Lundemo'" , Vicknesan Ayadurai Cc: "'Alan Kennington'" , ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Thu, 31 Jul 2003 09:32:27 -0400 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Everyone, Abbie and Tommy make a good point and I agree with it. But now that the implementer's guide is out there and says what it says at the beginning of 4.3.3, how should this be handled? Is there a concensus that the empty CSRC list should be represented by 1 or 2 bytes? If so, the implementer's guide should probably be modified. Regards, Remi. -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Thursday, July 31, 2003 9:37 AM To: 'Tommy Lundemo'; Vicknesan Ayadurai; Remi Pelland Cc: 'Alan Kennington'; ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Hi Tommy, Vick, Remi, Alan, all, Thanks for your opinion Tommy. I agree with you - the Implementer's Guide should clarify things that are ambiguous in the RFC (e.g. how to calculate the CRC) but should not change things that are clear. If it did it would mean that an implementation that does what is specified in the RFC cannot interoperate with one that follows what is in the implementer's guide, which would not be a good state of affairs. If there are changes like this to be made, then they should be made when the RFC progresses to draft standard. If the implementer's guide is also a log of things that need changing then they should be clearly marked or, preferably, put in a separate section e.g. an appendix. Regards, Abbie > >I just wanted to give you my opinion on this. >The extra (CC=0, generic CSRC list=0) octet needs to be there >according to >the standard (variable length, not optional field in 5.7.7.6), >even though >I agree that for future updates it should not be >necessary. > >The point is that we are trying to get interoperable >implementations, then I think we cannot allow the Implementers >Guide to override things in the current standard, but only >advise on how to implement the present standard and possibly >make suggestions on how to improve it in the future. > >Best Regards > >/ Tommy Lundemo, Effnet AB > >On Thu, 31 Jul 2003 09:30:31 +0200 (CEST), Vicknesan Ayadurai > wrote: > >> Hi Remi/Abbie/Alan, >> >> Thought I'd join in the fray with my "2-octets" worth here... >> >> Specific to the CC/Generic CSRC list discussion, we did do some basic >> CSRC-list compression testing at the 4th interop in Berlin last year. >> >> At that point, a CC-value of 0 (in the IRDYN dynamic chain) would >> still result in a 1-octet Generic CSRC List. In fact, there have been >> implementations which would produce a 2-octet Generic CSRC list (when >> said CC-value was 0), since a Generic CSRC list would be produced and >> subsequently assigned a (1-octet) gen_id as well. >> >> I believe I'm partially responsible for the text by Lars-Erik in the >> link below (forwarded by Remi), since I brought this issue up after >> the interop event. >> >> I also believe the intention now is to interpret a CC-value >of 0 as NO >> Generic CSRC list present, but perhaps that can be confirmed/verified >> by someone else... >> >> Regards, >> vick >> +----------------------------------------------------+ >> Vicknesan AYADURAI >> SwitchLab, Ericsson Research - Stockholm, Sweden >> Phone : +46 8 5087 8084 / Fax: +46 8 5087 8090 >> +----------------------------------------------------+ >> _______________________________________________ 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 Jul 31 10:18: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 KAA27941 for ; Thu, 31 Jul 2003 10:18: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 19iEFq-0002Mv-TV for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 10:18:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEI6Fv009100 for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 10:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEFq-0002Mh-QR for rohc-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:18: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 KAA27934 for ; Thu, 31 Jul 2003 10:18:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEFo-00049C-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 10:18:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEFo-000499-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 10:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEFk-0002Jw-80; Thu, 31 Jul 2003 10:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEFG-0002JU-1p for rohc@optimus.ietf.org; Thu, 31 Jul 2003 10:17:30 -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 KAA27874 for ; Thu, 31 Jul 2003 10:17:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEFD-00048n-00 for rohc@ietf.org; Thu, 31 Jul 2003 10:17:27 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19iEFD-00048e-00 for rohc@ietf.org; Thu, 31 Jul 2003 10:17:27 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 15:16:55 +0100 Message-ID: From: "Surtees, Abigail" To: "'Remi Pelland'" , "'Tommy Lundemo'" , Vicknesan Ayadurai Cc: "'Alan Kennington'" , ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Thu, 31 Jul 2003 15:16:52 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Remi, all, > >Abbie and Tommy make a good point and I agree with it. But >now that the >implementer's guide is out there and says what it says at the >beginning of >4.3.3, how should this be handled? > Good question ... anyone? >Is there a concensus that the empty CSRC list should be >represented by 1 or >2 bytes? If so, the implementer's guide should probably be modified. > Are you referring here to section 4.3.1 of the Implementer's guide? I think this section is clear and that it is an implementation decision whether the GP bit is set or not (and consequently whether the empty CSRC list is represented by 1 or 2 bytes) so there is no need to change this section of the guide. Regards, Abbie >Regards, >Remi. > >-----Original Message----- >From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] >Sent: Thursday, July 31, 2003 9:37 AM >To: 'Tommy Lundemo'; Vicknesan Ayadurai; Remi Pelland >Cc: 'Alan Kennington'; ROHC mailing list >Subject: RE: [rohc] ROHC compression ratio > > >Hi Tommy, Vick, Remi, Alan, all, > >Thanks for your opinion Tommy. I agree with you - the >Implementer's Guide >should clarify things that are ambiguous in the RFC (e.g. how >to calculate >the CRC) but should not change things that are clear. If it >did it would >mean that an implementation that does what is specified in the >RFC cannot >interoperate with one that follows what is in the >implementer's guide, which >would not be a good state of affairs. > >If there are changes like this to be made, then they should be >made when the >RFC progresses to draft standard. If the implementer's guide >is also a log >of things that need changing then they should be clearly marked or, >preferably, put in a separate section e.g. an appendix. > >Regards, > >Abbie > > >> >>I just wanted to give you my opinion on this. >>The extra (CC=0, generic CSRC list=0) octet needs to be there >>according to >>the standard (variable length, not optional field in 5.7.7.6), >>even though >>I agree that for future updates it should not be >>necessary. >> >>The point is that we are trying to get interoperable >>implementations, then I think we cannot allow the Implementers >>Guide to override things in the current standard, but only >>advise on how to implement the present standard and possibly >>make suggestions on how to improve it in the future. >> >>Best Regards >> >>/ Tommy Lundemo, Effnet AB >> >>On Thu, 31 Jul 2003 09:30:31 +0200 (CEST), Vicknesan Ayadurai >> wrote: >> >>> Hi Remi/Abbie/Alan, >>> >>> Thought I'd join in the fray with my "2-octets" worth here... >>> >>> Specific to the CC/Generic CSRC list discussion, we did do >some basic >>> CSRC-list compression testing at the 4th interop in Berlin >last year. >>> >>> At that point, a CC-value of 0 (in the IRDYN dynamic chain) would >>> still result in a 1-octet Generic CSRC List. In fact, there >have been >>> implementations which would produce a 2-octet Generic CSRC >list (when >>> said CC-value was 0), since a Generic CSRC list would be >produced and >>> subsequently assigned a (1-octet) gen_id as well. >>> >>> I believe I'm partially responsible for the text by Lars-Erik in the >>> link below (forwarded by Remi), since I brought this issue up after >>> the interop event. >>> >>> I also believe the intention now is to interpret a CC-value >>of 0 as NO >>> Generic CSRC list present, but perhaps that can be >confirmed/verified >>> by someone else... >>> >>> Regards, >>> vick >>> +----------------------------------------------------+ >>> Vicknesan AYADURAI >>> SwitchLab, Ericsson Research - Stockholm, Sweden >>> Phone : +46 8 5087 8084 / Fax: +46 8 5087 8090 >>> +----------------------------------------------------+ >>> > >_______________________________________________ >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 Jul 31 10: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 KAA29611 for ; Thu, 31 Jul 2003 10:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEWK-0002l2-9h for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 10:35:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEZ8nk010601 for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 10:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEWK-0002ku-3M for rohc-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:35: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 KAA29599 for ; Thu, 31 Jul 2003 10:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEWH-0004dJ-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 10:35:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEWH-0004dG-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 10:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEWD-0002kV-CW; Thu, 31 Jul 2003 10:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEVx-0002k4-9R for rohc@optimus.ietf.org; Thu, 31 Jul 2003 10:34: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 KAA29583 for ; Thu, 31 Jul 2003 10:34:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEVs-0004d6-00 for rohc@ietf.org; Thu, 31 Jul 2003 10:34:40 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19iEVr-0004d3-00 for rohc@ietf.org; Thu, 31 Jul 2003 10:34:39 -0400 Received: by exchsvr.octasic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 10:10:20 -0400 Message-ID: From: Remi Pelland To: "'Surtees, Abigail'" , Remi Pelland , "'Tommy Lundemo'" , Vicknesan Ayadurai Cc: "'Alan Kennington'" , ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Thu, 31 Jul 2003 10:10:14 -0400 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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Abbie, I was not particularly referring to 4.3.1 - it's fine the way it is. All I was trying to ask is if there was a concensus that when the CSRC list is empty, that the encoding to be used is the one defined in the RFC, as opposed to what is stated at the beginning of sectioin 4.3.3 of the implementer's guide (i.e. your implementation vs mine :-) ). That's all... Thanks, Remi. -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Thursday, July 31, 2003 10:17 AM To: 'Remi Pelland'; 'Tommy Lundemo'; Vicknesan Ayadurai Cc: 'Alan Kennington'; ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Hi Remi, all, > >Abbie and Tommy make a good point and I agree with it. But >now that the >implementer's guide is out there and says what it says at the >beginning of >4.3.3, how should this be handled? > Good question ... anyone? >Is there a concensus that the empty CSRC list should be >represented by 1 or >2 bytes? If so, the implementer's guide should probably be modified. > Are you referring here to section 4.3.1 of the Implementer's guide? I think this section is clear and that it is an implementation decision whether the GP bit is set or not (and consequently whether the empty CSRC list is represented by 1 or 2 bytes) so there is no need to change this section of the guide. Regards, Abbie >Regards, >Remi. > >-----Original Message----- >From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] >Sent: Thursday, July 31, 2003 9:37 AM >To: 'Tommy Lundemo'; Vicknesan Ayadurai; Remi Pelland >Cc: 'Alan Kennington'; ROHC mailing list >Subject: RE: [rohc] ROHC compression ratio > > >Hi Tommy, Vick, Remi, Alan, all, > >Thanks for your opinion Tommy. I agree with you - the >Implementer's Guide >should clarify things that are ambiguous in the RFC (e.g. how >to calculate >the CRC) but should not change things that are clear. If it >did it would >mean that an implementation that does what is specified in the >RFC cannot >interoperate with one that follows what is in the >implementer's guide, which >would not be a good state of affairs. > >If there are changes like this to be made, then they should be >made when the >RFC progresses to draft standard. If the implementer's guide >is also a log >of things that need changing then they should be clearly marked or, >preferably, put in a separate section e.g. an appendix. > >Regards, > >Abbie > > >> >>I just wanted to give you my opinion on this. >>The extra (CC=0, generic CSRC list=0) octet needs to be there >>according to >>the standard (variable length, not optional field in 5.7.7.6), >>even though >>I agree that for future updates it should not be >>necessary. >> >>The point is that we are trying to get interoperable >>implementations, then I think we cannot allow the Implementers >>Guide to override things in the current standard, but only >>advise on how to implement the present standard and possibly >>make suggestions on how to improve it in the future. >> >>Best Regards >> >>/ Tommy Lundemo, Effnet AB >> >>On Thu, 31 Jul 2003 09:30:31 +0200 (CEST), Vicknesan Ayadurai >> wrote: >> >>> Hi Remi/Abbie/Alan, >>> >>> Thought I'd join in the fray with my "2-octets" worth here... >>> >>> Specific to the CC/Generic CSRC list discussion, we did do >some basic >>> CSRC-list compression testing at the 4th interop in Berlin >last year. >>> >>> At that point, a CC-value of 0 (in the IRDYN dynamic chain) would >>> still result in a 1-octet Generic CSRC List. In fact, there >have been >>> implementations which would produce a 2-octet Generic CSRC >list (when >>> said CC-value was 0), since a Generic CSRC list would be >produced and >>> subsequently assigned a (1-octet) gen_id as well. >>> >>> I believe I'm partially responsible for the text by Lars-Erik in the >>> link below (forwarded by Remi), since I brought this issue up after >>> the interop event. >>> >>> I also believe the intention now is to interpret a CC-value >>of 0 as NO >>> Generic CSRC list present, but perhaps that can be >confirmed/verified >>> by someone else... >>> >>> Regards, >>> vick >>> +----------------------------------------------------+ >>> Vicknesan AYADURAI >>> SwitchLab, Ericsson Research - Stockholm, Sweden >>> Phone : +46 8 5087 8084 / Fax: +46 8 5087 8090 >>> +----------------------------------------------------+ >>> > >_______________________________________________ >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 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jul 31 10:45:41 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 KAA00097 for ; Thu, 31 Jul 2003 10:45:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEfz-0003wg-9L for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 10:45:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEj74Q015160 for rohc-archive@odin.ietf.org; Thu, 31 Jul 2003 10:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEfz-0003wR-66 for rohc-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 10:45: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 KAA00062 for ; Thu, 31 Jul 2003 10:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEfw-0004kp-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 10:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iEfw-0004km-00 for rohc-web-archive@ietf.org; Thu, 31 Jul 2003 10:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEfs-0003rC-Hh; Thu, 31 Jul 2003 10:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEf8-0003pB-Io for rohc@optimus.ietf.org; Thu, 31 Jul 2003 10:44:15 -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 KAA00026 for ; Thu, 31 Jul 2003 10:44:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEf6-0004k7-00 for rohc@ietf.org; Thu, 31 Jul 2003 10:44:12 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19iEf5-0004jB-00 for rohc@ietf.org; Thu, 31 Jul 2003 10:44:11 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jul 2003 15:43:40 +0100 Message-ID: From: "Surtees, Abigail" To: "'Remi Pelland'" , "'Tommy Lundemo'" , Vicknesan Ayadurai Cc: "'Alan Kennington'" , ROHC mailing list Subject: RE: [rohc] ROHC compression ratio Date: Thu, 31 Jul 2003 15:43:37 +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: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Remi, Alan, I misinterpreted your question. Thanks for the clarifications. Regards, Abbie >I was not particularly referring to 4.3.1 - it's fine the way it is. > >All I was trying to ask is if there was a concensus that when >the CSRC list >is empty, that the encoding to be used is the one defined in >the RFC, as >opposed to what is stated at the beginning of sectioin 4.3.3 of the >implementer's guide (i.e. your implementation vs mine :-) ). >That's all... > >Thanks, >Remi. > >-----Original Message----- >From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] >Sent: Thursday, July 31, 2003 10:17 AM >To: 'Remi Pelland'; 'Tommy Lundemo'; Vicknesan Ayadurai >Cc: 'Alan Kennington'; ROHC mailing list >Subject: RE: [rohc] ROHC compression ratio > > >Hi Remi, all, >> >>Abbie and Tommy make a good point and I agree with it. But >>now that the >>implementer's guide is out there and says what it says at the >>beginning of >>4.3.3, how should this be handled? >> >Good question ... anyone? > >>Is there a concensus that the empty CSRC list should be >>represented by 1 or >>2 bytes? If so, the implementer's guide should probably be modified. >> >Are you referring here to section 4.3.1 of the Implementer's >guide? I think >this section is clear and that it is an implementation >decision whether the >GP bit is set or not (and consequently whether the empty CSRC list is >represented by 1 or 2 bytes) so there is no need to change >this section of >the guide. > >Regards, > >Abbie > >>Regards, >>Remi. >> _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc