From exim@www1.ietf.org Sat Jan 3 23:31:16 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23672 for ; Sat, 3 Jan 2004 23:31:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AczuZ-0003aE-DP for rohc-archive@odin.ietf.org; Sat, 03 Jan 2004 23:30:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i044UlDv013771 for rohc-archive@odin.ietf.org; Sat, 3 Jan 2004 23:30:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AczuY-0003a2-Sw for rohc-web-archive@optimus.ietf.org; Sat, 03 Jan 2004 23:30:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23639 for ; Sat, 3 Jan 2004 23:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AczuW-00030k-00 for rohc-web-archive@ietf.org; Sat, 03 Jan 2004 23:30:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aczse-0002wn-00 for rohc-web-archive@ietf.org; Sat, 03 Jan 2004 23:28:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aczqv-0002sf-00 for rohc-web-archive@ietf.org; Sat, 03 Jan 2004 23:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aczqu-0003Sw-KL; Sat, 03 Jan 2004 23:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AczqY-0003SG-Jd for rohc@optimus.ietf.org; Sat, 03 Jan 2004 23:26:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23558 for ; Sat, 3 Jan 2004 23:26:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AczqW-0002pr-00 for rohc@ietf.org; Sat, 03 Jan 2004 23:26:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aczof-0002n3-00 for rohc@ietf.org; Sat, 03 Jan 2004 23:24:43 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1Aczo6-0002kJ-00 for rohc@ietf.org; Sat, 03 Jan 2004 23:24:06 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i044NVEG015597 for ; Sun, 4 Jan 2004 05:23:35 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i044NVSF015596 for ; Sun, 4 Jan 2004 05:23:31 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i044NUEC015593; Sun, 04 Jan 2004 05:23:31 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 77067F5B82; Sun, 4 Jan 2004 05:23:25 +0100 (CET) Date: Sun, 04 Jan 2004 05:25:47 +0100 From: Juergen Quittek To: rohc@ietf.org Cc: heard@pobox.com, bwijnen@lucent.com Message-ID: <2147483647.1073193947@[10.1.1.26]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Subject: [rohc] ROHC MIB update (-09) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, After receiving valuable comments from Bert Wijnen, I posted a new version of the ROHC MIB. If you want to have a look at it before it becomes available in the I-D repository, please have a look at . Below please find the list of changes from version -08 to version -09. Not listed are 10 fixed typos discovered by Bert. Happy New Year, 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 MIB Issues =============== ======================================================================== 8. Missing DISPLAY-HINT clauses in textual conventions ======================================================================== Problem Description: ------------------------------------------------------------------------ Textual conventions RohcChannelIdentifier and RohcChannelIdentifierOrZero are missing DISPLAY-HINT clauses. raised by Mike Heard ======================================================================== Suggested solution: ------------------------------------------------------------------------ add DISPLAY-HIN clause to RohcChannelIdentifier and RohcChannelIdentifierOrZero DISPLAY-HINT "d" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 9. Range of rohcContextProfile ======================================================================== Problem Description: ------------------------------------------------------------------------ The range of rohcProfile is limited to Unsigned32 (0..65535). rohcContextProfile can only have values valid for rohcProfile, but its renge is just Unsigned32. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace SYNTAX clause of rohcContextProfile "SYNTAX Unsigned32" by "SYNTAX Unsigned32 (0..65535)" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 10. Relation between rohcProfile and rohcContextProfile ======================================================================== Problem Description: ------------------------------------------------------------------------ For each value of rohcContextProfile there must exist an entry in the rohcProfileTable that has the same rohcChannelID as first part of the index and that has rohcProfile with the rohcChannelStatus), an OID is assingned that is not in line with the other OIDs assinged to columnar objects of this table. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace DESCRIPTION clause of rohcContextProfile "Identifier of the profile for this context. The profile is identified by its index in the rohcProfileTable for this instance." by "Identifier of the profile for this context. The profile is identified by its index in the rohcProfileTable for this instance. There MUST exist a corresponding entry in the rohcProfileTable using the value of rohcContextProfile as second part of the index (and using the same rohcChannelID as first part of the index)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 11. Avoinding gap in rohcContextTable ======================================================================== Problem Description: ------------------------------------------------------------------------ For object rohcDecompressorDepth in the rohcContextTable, the current description says that it MUST NOT be instantiated if the entry describes a compressor context. An entry describing a compressor context would have a single gap at the OID of this object. Dealing with gaps complicates MIB and manager implementations. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace in DESCRIPTION clause of object rohcContextDecompressorDepth "Its value is only valid for decompressor contexts, i.e. if rohcInstanceType has the value decompressor(2). For compressor contexts where rohcInstanceType has the value compressor(1), this object MUST NOT be instantiated." by "Its value is only valid for decompressor contexts, i.e. if rohcInstanceType has the value decompressor(2). For compressor contexts where rohcInstanceType has the value compressor(1), the value of this object is irrelavant and MUST be set to zero (0)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 12. Confusing description of RohcChannelIdentifier ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of textual convention RohcChannelIdentifier calls 0 a reserved value, but the syntax does not allow 0 to be used. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace in DESCRIPTION clauses of textual convention RohcChannelIdentifier "The value of 0 is reserved, it must not be used as identifier of an existing channel." by "The value of 0 must not be used as identifier of an existing channel." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 13. DESCRIPTION clause of rohcChannelFeedbackFor ======================================================================== Problem Description: ------------------------------------------------------------------------ Incorrect enumeration: rohcChannelFeedbackFor OBJECT-TYPE SYNTAX RohcChannelIdentifierOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The index of another channel of this interface for which the channel serves as feedback channel. If no feedback information is transferred on this channel, then the value of this ID is 0. If the channel type is set ==> to none(1), then the value of this object must be 0. ==> If the channel type is ROHC(2) and the value of this object is a valid channel ID, then feedback information is piggy-backed on the ROHC channel." In the channelType 1 is listed as "notInUse" !! Would it be better to say MUST instead of "must" ?? And ROHC(2) is listyed as lower case rohc(2) !! And what if the channelType is 3? is it then such that this object MUST contain a valid ChannelIdentifier? For reference: rohcChannelType OBJECT-TYPE SYNTAX INTEGER { notInUse(1), rohc(2), dedicatedFeedback(3) } raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace second paragraph of DESCRIPTION clause of rohcChannelFeedbackFor "If no feedback information is transferred on this channel, then the value of this ID is 0. If the channel type is set to none(1), then the value of this object must be 0. If the channel type is ROHC(2) and the value of this object is a valid channel ID, then feedback information is piggy-backed on the ROHC channel." by "If no feedback information is transferred on this channel, then the value of this ID is 0. If the channel type is set to notInUse(1), then the value of this object MUST be 0. If the channel type is rohc(2) and the value of this object is a valid channel ID, then feedback information is piggy-backed on the ROHC channel. If the channel type is dedicatedFeedback(3), then feedback is transferred on this channel and the value of this object MUST be different from 0 and MUST identify an existing ROHC channel." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 14. persistency of rohcInstanceContextStorageTime ======================================================================== Problem Description: ------------------------------------------------------------------------ rohcInstanceContextStorageTime is a read-write object. Might be good to say something about expected persistency of a change made to that object. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ append to DESCRIPTION clause of rohcInstanceContextStorageTime "ROHC-MIB implementations SHOULD store the set value of this object persistently." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 15. What does "respectively" mean in DESCRIPTION clauses? ======================================================================== Problem Description: ------------------------------------------------------------------------ The use of the term "respectively" in the DESCRIPTION clauses of rohcInstanceIRs, rohcInstanceIRDYNs and rohcInstanceFeedbacks is not clear. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace in all three DESCRIPTION clauses "sent or received, respectively, by this instance" by "that are either sent or received by this instance" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 16. Terms IR and IRDYN are never explained ======================================================================== Problem Description: ------------------------------------------------------------------------ "IR" and "IRDYN" used in names of objects rohcInstanceIRs and rohcInstanceIRDYNs are not explained. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace single bullet in section 4.1.2 "o the total number of packets passing this instance, and" by three bullets "o the total number of packets passing this instance o the total number of static Initialization and Refreshs (IRs) passing this instance o the total number of dynamic Initialization and Refreshs (IR- DYNs) passing this instance, and" add REFERENCE clause to object rohcInstanceIRs "RFC 3095, Section 5.7.7.1" add REFERENCE clause to object rohcInstanceIRDYNs "RFC 3095, Section 5.7.7.2" add REFERENCE clause to object rohcContextIRs "RFC 3095, Section 5.7.7.1" add REFERENCE clause to object rohcContextIRDYNs "RFC 3095, Section 5.7.7.2" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 17. Textual conventions for Ratios and mean sizes ======================================================================== Problem Description: ------------------------------------------------------------------------ There are four mean size objects and five compression ratio objects. a few textual conventions might be appropriate. raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ add new TC RohcCompressionRatio ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A number indicating a compression ratio over a set of bytes. The value is defined as 1000 * bytes(compressed) / bytes(original) rounded to the next integer value. Note that compressed sets of bytes can be larger than the corresponding uncompressed ones. Therefore, the number can be greater than 1000." SYNTAX Unsigned32 and use it for objects rohcInstanceCompressionRatio, rohcContextAllPacketsRatio, rohcContextAllHeadersRatio, rohcContextLastPacketsRatio, rohcContextLastHeadersRatio. replace DESCRIPTION clause of rohcInstanceCompressionRatio "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. Note that compressed packets can be larger than the corresponding uncompressed ones. Therefore, this object can return values greater than 1000 when it is retrieved." by "This object indicates the compression ratio so far over all packets on the channel served by this instance. The compression is computed over all bytes of the IP packets including the IP header but excluding all lower layer headers." replace DESCRIPTION clause of rohcContextAllPacketsRatio "This object indicates the compression ratio so far over all packets passing this context. 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. Note that compressed packets can be larger than the corresponding uncompressed ones. Therefore, this object can return values greater than 1000 when it is retrieved." by "This object indicates the compression ratio so far over all packets passing this context. The compression is computed over all bytes of the IP packets including the IP header but excluding all lower layer headers." replace DESCRIPTION clause of rohcContextAllHeadersRatio "This object indicates the compression ratio so far over all packet headers passing this context. 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 headers that are subject to compression for the used profile. Note that compressed headers can be larger than the corresponding uncompressed ones. Therefore, this object can return values greater than 1000 when it is retrieved." by "This object indicates the compression ratio so far over all packet headers passing this context. The compression is computed over all bytes of all headers that are subject to compression for the used profile." replace DESCRIPTION clause of rohcContextLastPacketsRatio "This object indicates the compression ratio concerning the last 16 packets passing this context or concerning all packets passing this context if they are less than 16, so far. 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 the IP packets including the IP header but excluding all lower layer headers. Note that compressed packets can be larger than the corresponding uncompressed ones. Therefore, this object can return values greater than 1000 when it is retrieved." by "This object indicates the compression ratio concerning the last 16 packets passing this context or concerning all packets passing this context if they are less than 16, so far. The compression is computed over all bytes of the IP packets including the IP header but excluding all lower layer headers." replace DESCRIPTION clause of rohcContextLastHeadersRatio "This object indicates the compression ratio concerning the headers of the last 16 packets passing this context or concerning the headers of all packets passing this context if they are less than 16, so far. 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 headers that are subject to compression for the used profile. Note that compressed headers can be larger than the corresponding uncompressed ones. Therefore, this object can return values greater than 1000 when it is retrieved." by "This object indicates the compression ratio concerning the headers of the last 16 packets passing this context or concerning the headers of all packets passing this context if they are less than 16, so far. The compression is computed over all bytes of all headers that are subject to compression for the used profile." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 18. ======================================================================== Problem Description: ------------------------------------------------------------------------ In rohcRtpContextTable and rohcRtpPacketSizeTable there are several objects that MUST NOT be instantiated in some cases. Bert: "I again wonder if it would be easier on management apps (possibly even agent implementations) to just say that the value must be false for rohcProfile values other than 0x0005 In fact you have a lot of those objects that would NOT be instantiated. And I wonder if that is easy. I can live with it though." raised by Bert Wijnen ======================================================================== Suggested solution: ------------------------------------------------------------------------ no change ======================================================================== Status: no document change required ======================================================================== _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Jan 9 16:48:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18631 for ; Fri, 9 Jan 2004 16:48:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af4UY-0000cr-Vj for rohc-archive@odin.ietf.org; Fri, 09 Jan 2004 16:48:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i09LmUTF002398 for rohc-archive@odin.ietf.org; Fri, 9 Jan 2004 16:48:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af4UY-0000cZ-QK for rohc-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 16:48:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18536 for ; Fri, 9 Jan 2004 16:48:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af4UW-0001PT-00 for rohc-web-archive@ietf.org; Fri, 09 Jan 2004 16:48:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af4Sq-0001Di-00 for rohc-web-archive@ietf.org; Fri, 09 Jan 2004 16:46:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Af4RG-000118-01 for rohc-web-archive@ietf.org; Fri, 09 Jan 2004 16:45:07 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Af4Bq-0002CR-MP for rohc-web-archive@ietf.org; Fri, 09 Jan 2004 16:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af4Bl-00081Y-Hu; Fri, 09 Jan 2004 16:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af4BB-0007zJ-9C for rohc@optimus.ietf.org; Fri, 09 Jan 2004 16:28:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17123; Fri, 9 Jan 2004 16:28:26 -0500 (EST) Message-Id: <200401092128.QAA17123@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: Fri, 09 Jan 2004 16:28:26 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-mib-rtp-09.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Definitions of Managed Objects for Robus Header Compression Author(s) : J. Quittek Filename : draft-ietf-rohc-mib-rtp-09.txt Pages : 52 Date : 2004-1-9 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of robust header compression. The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP profile, the ROHC UDP profile, and the ROHC ESP profile. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-mib-rtp-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-mib-rtp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-mib-rtp-09.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: <2004-1-9164757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-mib-rtp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-mib-rtp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-9164757.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun Jan 11 03:47:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20135 for ; Sun, 11 Jan 2004 03:47:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfbFH-0001NE-Pu for rohc-archive@odin.ietf.org; Sun, 11 Jan 2004 03:46:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0B8kt4X005277 for rohc-archive@odin.ietf.org; Sun, 11 Jan 2004 03:46:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfbFH-0001N2-7R for rohc-web-archive@optimus.ietf.org; Sun, 11 Jan 2004 03:46:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20131 for ; Sun, 11 Jan 2004 03:46:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfbFE-0004zJ-00 for rohc-web-archive@ietf.org; Sun, 11 Jan 2004 03:46:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfbDP-0004s6-00 for rohc-web-archive@ietf.org; Sun, 11 Jan 2004 03:45:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AfbCU-0004kU-00 for rohc-web-archive@ietf.org; Sun, 11 Jan 2004 03:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfbCT-0001FG-Q0; Sun, 11 Jan 2004 03:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AfbC0-0001DD-O2 for rohc@optimus.ietf.org; Sun, 11 Jan 2004 03:43:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20000 for ; Sun, 11 Jan 2004 03:43:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfbBy-0004j5-00 for rohc@ietf.org; Sun, 11 Jan 2004 03:43:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfbAc-0004bg-00 for rohc@ietf.org; Sun, 11 Jan 2004 03:42:06 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afb7C-0004Q0-00 for rohc@ietf.org; Sun, 11 Jan 2004 03:38:34 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i0B8bSK30809; Sun, 11 Jan 2004 00:37:29 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 11 Jan 2004 00:37:27 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Juergen Quittek cc: rohc@ietf.org, bwijnen@lucent.com In-Reply-To: <2147483647.1073193947@[10.1.1.26]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [rohc] Re: ROHC MIB update (-09) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Sun, 4 Jan 2004, Juergen Quittek wrote: > After receiving valuable comments from Bert Wijnen, > I posted a new version of the ROHC MIB. I finally got a chance to look at the new version. The changes all look good to me. //cmh _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jan 12 16:47:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23649 for ; Mon, 12 Jan 2004 16:47:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9tg-0006vr-Qg for rohc-archive@odin.ietf.org; Mon, 12 Jan 2004 16:46:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CLkuOZ026643 for rohc-archive@odin.ietf.org; Mon, 12 Jan 2004 16:46:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9tg-0006ve-ML for rohc-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:46:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23569 for ; Mon, 12 Jan 2004 16:46:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9te-0003xX-00 for rohc-web-archive@ietf.org; Mon, 12 Jan 2004 16:46:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9rW-0003kd-00 for rohc-web-archive@ietf.org; Mon, 12 Jan 2004 16:44:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag9q4-0003bC-00 for rohc-web-archive@ietf.org; Mon, 12 Jan 2004 16:43:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9pt-0006ok-4I; Mon, 12 Jan 2004 16:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9p7-0006nq-La for rohc@optimus.ietf.org; Mon, 12 Jan 2004 16:42:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23145 for ; Mon, 12 Jan 2004 16:42:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9p5-0003Xr-00 for rohc@ietf.org; Mon, 12 Jan 2004 16:42:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9nQ-0003Pa-00 for rohc@ietf.org; Mon, 12 Jan 2004 16:40:29 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ag9lp-0003Fc-00 for rohc@ietf.org; Mon, 12 Jan 2004 16:38:49 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag9lo-0003Fn-74; Mon, 12 Jan 2004 21:38:48 +0000 To: "C. M. Heard" cc: Juergen Quittek , rohc@ietf.org, bwijnen@lucent.com Subject: Re: [rohc] Re: ROHC MIB update (-09) In-Reply-To: Message from "C. M. Heard" of "Sun, 11 Jan 2004 00:37:27 PST." Date: Mon, 12 Jan 2004 13:38:47 -0800 From: Allison Mankin Message-Id: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Folks, I've put the ROHC MIB on the 22 January IESG agenda. Thanks. Allison > On Sun, 4 Jan 2004, Juergen Quittek wrote: > > After receiving valuable comments from Bert Wijnen, > > I posted a new version of the ROHC MIB. > > I finally got a chance to look at the new version. The > changes all look good to me. > > //cmh > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Jan 19 18:19:13 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15018 for ; Mon, 19 Jan 2004 18:19:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiifP-0000O0-2c for rohc-archive@odin.ietf.org; Mon, 19 Jan 2004 18:18:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JNIlcv001480 for rohc-archive@odin.ietf.org; Mon, 19 Jan 2004 18:18:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiifO-0000Nl-Rx for rohc-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 18:18:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14953 for ; Mon, 19 Jan 2004 18:18:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aiif7-00062A-00 for rohc-web-archive@ietf.org; Mon, 19 Jan 2004 18:18:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aiias-0005oN-00 for rohc-web-archive@ietf.org; Mon, 19 Jan 2004 18:14:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiiYC-0005c7-00 for rohc-web-archive@ietf.org; Mon, 19 Jan 2004 18:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiiXu-0006Uv-1U; Mon, 19 Jan 2004 18:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiiXN-0006M1-IT for rohc@optimus.ietf.org; Mon, 19 Jan 2004 18:10:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14193 for ; Mon, 19 Jan 2004 18:10:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiiXF-0005Zz-00 for rohc@ietf.org; Mon, 19 Jan 2004 18:10:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiiTh-0005Oh-00 for rohc@ietf.org; Mon, 19 Jan 2004 18:06:41 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AiiQ0-0005Am-00 for rohc@ietf.org; Mon, 19 Jan 2004 18:02:52 -0500 Received: from IL0015NJMAZZAR2 (h192-11-174-219.lucent.com [192.11.174.219]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with SMTP id i0JN1rD27593 for ; Mon, 19 Jan 2004 17:01:53 -0600 (CST) Date: Mon, 19 Jan 2004 17:01:51 -0600 To: rohc@ietf.org From: iesg-secretary@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------084875080360036" Subject: [rohc] Hi 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 ----------084875080360036 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) Found virus WORM_BAGLE.A in file xsrjpyact.exe The file xsrjpyact.exe is moved to /var/log/virus/virXEQqQHLKa. This is a machine-generated message, please do not reply via email. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770. --------------------------------------------------------- ----------084875080360036 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) igrgkwnxtxyaok -- Test, yep. ----------084875080360036 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) xsrjpyact.exe is removed from here because it contains a virus. --------------------------------------------------------- ----------084875080360036-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Jan 21 11:17:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27725 for ; Wed, 21 Jan 2004 11:17:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjL2W-0001oJ-L6 for rohc-archive@odin.ietf.org; Wed, 21 Jan 2004 11:17:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0LGHCvg006953 for rohc-archive@odin.ietf.org; Wed, 21 Jan 2004 11:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjL2W-0001o4-GJ for rohc-web-archive@optimus.ietf.org; Wed, 21 Jan 2004 11:17:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27719 for ; Wed, 21 Jan 2004 11:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjL2V-0005Pm-00 for rohc-web-archive@ietf.org; Wed, 21 Jan 2004 11:17:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjL1W-0005Nv-00 for rohc-web-archive@ietf.org; Wed, 21 Jan 2004 11:16:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjL1O-0005MP-00 for rohc-web-archive@ietf.org; Wed, 21 Jan 2004 11:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjL1N-0001io-61; Wed, 21 Jan 2004 11:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjL0X-0001g7-RI for rohc@optimus.ietf.org; Wed, 21 Jan 2004 11:15:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27688 for ; Wed, 21 Jan 2004 11:15:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjL0W-0005LP-00 for rohc@ietf.org; Wed, 21 Jan 2004 11:15:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjKza-0005JR-00 for rohc@ietf.org; Wed, 21 Jan 2004 11:14:10 -0500 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 1AjKz4-0005Gs-00 for rohc@ietf.org; Wed, 21 Jan 2004 11:13:39 -0500 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Jan 2004 16:12:55 -0000 Message-ID: From: "Price, Richard" To: "'lars-erik.jonsson@ericsson.com'" , "'cabo@tzi.org'" , "'rohc@ietf.org'" Date: Wed, 21 Jan 2004 16:13:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] SigComp drafts 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi ROHCers, I noticed that the SigComp User Guide and the SigComp torture tests have both expired, and I was wondering what the plan was regarding these drafts. Would it be useful to eventually publish them as Informational RFCs? If so, is there any outstanding work that needs to be done on either draft? Nothing immediately springs to mind, but I've been out of the loop for a while... Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sun Jan 25 06:17:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28174 for ; Sun, 25 Jan 2004 06:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkiGH-00048W-KH for rohc-archive@odin.ietf.org; Sun, 25 Jan 2004 06:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0PBH5j7015896 for rohc-archive@odin.ietf.org; Sun, 25 Jan 2004 06:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkiGH-00048J-Dn for rohc-web-archive@optimus.ietf.org; Sun, 25 Jan 2004 06:17:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28135 for ; Sun, 25 Jan 2004 06:17:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkiGD-00065R-00 for rohc-web-archive@ietf.org; Sun, 25 Jan 2004 06:17:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkiFE-00062c-00 for rohc-web-archive@ietf.org; Sun, 25 Jan 2004 06:16:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AkiEH-00060P-00 for rohc-web-archive@ietf.org; Sun, 25 Jan 2004 06:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkiEJ-0003uv-9Y; Sun, 25 Jan 2004 06:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AkiDO-0003u1-Ts for rohc@optimus.ietf.org; Sun, 25 Jan 2004 06:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28059 for ; Sun, 25 Jan 2004 06:14:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AkiDL-0005y2-00 for rohc@ietf.org; Sun, 25 Jan 2004 06:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AkiCO-0005wO-00 for rohc@ietf.org; Sun, 25 Jan 2004 06:13:04 -0500 Received: from bay10-f15.bay10.hotmail.com ([64.4.37.15] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AkiCD-0005v1-00 for rohc@ietf.org; Sun, 25 Jan 2004 06:12:53 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 25 Jan 2004 03:12:24 -0800 Received: from 80.74.106.2 by by10fd.bay10.hotmail.msn.com with HTTP; Sun, 25 Jan 2004 11:12:24 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [johnyjsmith1970@hotmail.com] X-Sender: johnyjsmith1970@hotmail.com From: "John Smith" To: rohc@ietf.org Date: Sun, 25 Jan 2004 11:12:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jan 2004 11:12:24.0364 (UTC) FILETIME=[1BF966C0:01C3E334] Subject: [rohc] SigComp Compartments Memory Managment 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Hi, In RFC-3320 6.2.2. If the state creation request needs more state memory than the total state_memory_size for the compartment, the state handler deletes all but the first (state_memory_size - 64) bytes from the state_value. It sets the state_length to (state_memory_size - 64), and recalculates the state_identifier as defined in Section 9.4.9. What does it mean? It seems to make no sense by itself? How is it used? For what purpose? Does it have to do with some specific mechanism of memory book-keeping in the compressor ? Thank You, John. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* 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 Wed Jan 28 06:28:06 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26075 for ; Wed, 28 Jan 2004 06:28:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnrA-0006Dv-FB for rohc-archive@odin.ietf.org; Wed, 28 Jan 2004 06:27:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SBRerB023917 for rohc-archive@odin.ietf.org; Wed, 28 Jan 2004 06:27:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlnrA-0006Dg-Aa for rohc-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 06:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26057 for ; Wed, 28 Jan 2004 06:27:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alnr6-0006PE-00 for rohc-web-archive@ietf.org; Wed, 28 Jan 2004 06:27:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlnqI-0006JW-00 for rohc-web-archive@ietf.org; Wed, 28 Jan 2004 06:26:47 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlnpZ-0006D6-00 for rohc-web-archive@ietf.org; Wed, 28 Jan 2004 06:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alnpa-00064X-Ou; Wed, 28 Jan 2004 06:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alnp9-00063a-KJ for rohc@optimus.ietf.org; Wed, 28 Jan 2004 06:25:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25903 for ; Wed, 28 Jan 2004 06:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alnp5-0006An-00 for rohc@ietf.org; Wed, 28 Jan 2004 06:25:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlnoB-00065f-00 for rohc@ietf.org; Wed, 28 Jan 2004 06:24:35 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Alnnh-00060l-00 for rohc@ietf.org; Wed, 28 Jan 2004 06:24:05 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0SBNxV22552 for ; Wed, 28 Jan 2004 13:23:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 28 Jan 2004 13:23:57 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 28 Jan 2004 13:23:56 +0200 Received: from agni.research.nokia.com (hed040-220.research.nokia.com [172.21.40.220]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id NAA09155; Wed, 28 Jan 2004 13:24:06 +0200 (EET) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i0SBNtKe012460; Wed, 28 Jan 2004 13:23:55 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i0SAf9oB011425; Wed, 28 Jan 2004 12:41:09 +0200 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: John Smith Cc: rohc@ietf.org Subject: Re: [rohc] SigComp Compartments Memory Managment X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: (John Smith's message of "Sun, 25 Jan 2004 11:12:24 +0000") User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) References: Date: Wed, 28 Jan 2004 12:41:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 28 Jan 2004 11:23:56.0965 (UTC) FILETIME=[38092D50:01C3E591] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 John Smith writes: >What does it mean? It seems to make no sense by itself? >How is it used? For what purpose? >Does it have to do with some specific mechanism of memory book-keeping in >the compressor ? Only thing I can imagine is to make sure that there are no state items with higher priority in the compartment. So, if you have a sms=8192, you have state item S0 size=4000 priority=100 and you insert a state item S2 size=3000 p=10, then state item S3 s=2000 p=10, the S3 pushes away S2. If you insert S1 size=64000 priority=0 before S2, S3 pushes away S1, not S2. --Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Jan 29 08:27:02 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16207 for ; Thu, 29 Jan 2004 08:27:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmCBl-0006iu-UY for rohc-archive@odin.ietf.org; Thu, 29 Jan 2004 08:26:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TDQXFg025840 for rohc-archive@odin.ietf.org; Thu, 29 Jan 2004 08:26:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmCBl-0006ih-Q5 for rohc-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 08:26:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16204 for ; Thu, 29 Jan 2004 08:26:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmCBk-00032g-00 for rohc-web-archive@ietf.org; Thu, 29 Jan 2004 08:26:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmCAt-0002uu-00 for rohc-web-archive@ietf.org; Thu, 29 Jan 2004 08:25:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmCAL-0002mZ-00 for rohc-web-archive@ietf.org; Thu, 29 Jan 2004 08:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmCAI-0006Mx-R9; Thu, 29 Jan 2004 08:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AloiB-0001oW-CG for rohc@optimus.ietf.org; Wed, 28 Jan 2004 07:22:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28186 for ; Wed, 28 Jan 2004 07:22:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AloiA-0003Tr-00 for rohc@ietf.org; Wed, 28 Jan 2004 07:22:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlohC-0003Pq-00 for rohc@ietf.org; Wed, 28 Jan 2004 07:21:27 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AlogE-0003Ig-00 for rohc@ietf.org; Wed, 28 Jan 2004 07:20:27 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0SCKNqY002841; Wed, 28 Jan 2004 13:20:23 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 13:20:27 +0100 Message-ID: From: "Lajos Zaccomer (IJ/ETH)" To: John Smith Cc: rohc@ietf.org, "'Pekka Pessi'" Subject: RE: [rohc] SigComp Compartments Memory Managment Date: Wed, 28 Jan 2004 13:23:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Hi, In the second example, S1 (64000 bytes) would empty (delete S0) the state memory regardless its priority that affects only the order in which the already saved states should be removed. So the statements are true, but a little confusing, in my opinion. Though these examples, no doubt, will help in understanding the state removal meschanism, they don't say anything about the purpose and usage of the truncation. I can give you a fairly straightforward example: If you're going to save a state whithout knowing the state memory size of the other endpoint, with state truncation, you have the chance trying to save a state bigger than the default state memory size. Together with the acknowledgment of this state or even before, the other endpoint might advertise its parameters, and you can decide how much of your state was actually saved. (As parameter advertisement is optional, you may end up with an ack but not knowing the remote state memory size. In such a case, you should not use the saved state at all, as an ack in itself doesn't mean successful state save. If you should refer to an invalid state ID later, that means decompression failure, which you must avoid!) Without this feature, a big state would not be saved at all, and you should wait for a message from the other endpoint before saving anything there, causing a latency in the compression efficiency improvement (supposing we can compress a message better with a state than wit! hout, which is not always true ;-). BR/Zacco -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of Pekka Pessi Sent: Wednesday, January 28, 2004 11:41 AM To: John Smith Cc: rohc@ietf.org Subject: Re: [rohc] SigComp Compartments Memory Managment John Smith writes: >What does it mean? It seems to make no sense by itself? >How is it used? For what purpose? >Does it have to do with some specific mechanism of memory book-keeping in >the compressor ? Only thing I can imagine is to make sure that there are no state items with higher priority in the compartment. So, if you have a sms=8192, you have state item S0 size=4000 priority=100 and you insert a state item S2 size=3000 p=10, then state item S3 s=2000 p=10, the S3 pushes away S2. If you insert S1 size=64000 priority=0 before S2, S3 pushes away S1, not S2. --Pekka _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc