From exim@www1.ietf.org Fri Aug 8 05: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 FAA06011 for ; Fri, 8 Aug 2003 05: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 19l3to-0004lh-T9 for rohc-archive@odin.ietf.org; Fri, 08 Aug 2003 05:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h789p4te018325 for rohc-archive@odin.ietf.org; Fri, 8 Aug 2003 05:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l3to-0004lU-Nu for rohc-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 05:51: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 FAA05976 for ; Fri, 8 Aug 2003 05:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l3tk-0007PB-00 for rohc-web-archive@ietf.org; Fri, 08 Aug 2003 05:51:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l3tk-0007P7-00 for rohc-web-archive@ietf.org; Fri, 08 Aug 2003 05: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 19l3tl-0004kn-LG; Fri, 08 Aug 2003 05: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 19l3tT-0004jn-SL for rohc@optimus.ietf.org; Fri, 08 Aug 2003 05:50: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 FAA05909 for ; Fri, 8 Aug 2003 05:50:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l3tQ-0007OI-00 for rohc@ietf.org; Fri, 08 Aug 2003 05:50:40 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19l3tO-0007O3-00 for rohc@ietf.org; Fri, 08 Aug 2003 05:50:38 -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 h789o9VI050245; Fri, 8 Aug 2003 11:50:09 +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 E05BEBDA87; Fri, 8 Aug 2003 11:27:41 +0200 (CEST) Date: Fri, 08 Aug 2003 11:51:54 +0200 From: =?ISO-8859-1?Q?J=FCrgen_Quittek?= 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 Message-ID: <2147483647.1060343514@[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 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 Mike, Unfortunately, it took some time until we could check all your comments. Again thank you very much for this really helpful work. The document improved a lot! Below please find the detailed responses on all of your comments with two exceptions. - 4.) IPR Notices We are still checking the patent issues. We will post the results on the mailing list (with CC to you and Bert). - 11.) (e) ordering of the index components This is discussed in a separate email thread on the list. Juergen --On June 24, 2003 23:04 h -0700 "C. M. Heard" wrote: [...] > > 0.) Title -- s/Robus/Robust/ fixed. > 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. done. > 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: > [...] > > 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.) We'll started checking this at the IETF meeting. We have to continue discussing this on the mailing list. > 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). done. > (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. done. > (c) [RFC3095] has an incorrect title and an author list that's not > in the standard form. I replaced "et al." by the complete list of authors, but I do not know what is wrong with the title? > (d) [RFC3242] has an author list that's not in the standard form. done. > (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. done. > 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. done. Thank you for the suggestion. > 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). done. > 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. Copyright notices added to front page and to each MODULE-IDENTITY statement. > 9.) MIB compilation -- the following problems are reported by smilint: I was surprised to see these error messages. Looks like i used an older, buggy version of smilint :-( > 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: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 done. > 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 done. > 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: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 done. > 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. All fixed. This happened, because I checked the length of lines for the raw MIB files, not for the formatted I-D, where all MIB models were indented by three blanks. > (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). done. > (c) in Section 3, "Overview", 3rd paragraph: s/means/a means/ done. > (d) in Section 3, "Overview", 5th paragraph: s/[3242]/[RFC3242]/ done. > (e) in Section 4, "Structure of the MIB modules", 1st paragraph: > s/Section 6/Section 5/ done. > (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. fixed. > (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. done. > (h) in Section 4.1, "The ROHC-MIB module", last paragraph: > unexpanded acronym CID. fixed. > (i) in Section 4.1.1, "rohcInstanceTable", 4th bullet: > s/storagetime/storage time/ done. > (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. This was exactly the case. But the hidden text was more than just 'terminated': o the state of the CID ('unused', 'active', 'expired', or 'terminated'), also used as part of the table index, > 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. Yes, I removed this feature from an earlier version of the MIB without consistently removing all text referring to it. Now, I replaced For fault management compressor/decompressor state and mode can be checked and the compressor context can be reinitialized. by For fault management compressor/decompressor state and mode can be checked. > (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. We discussed this issue for some time already. I will summarize the arguments in a separate message on the mailing list (with CC to you and Bert) in order to decide what change to apply. > (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. added o a flag indicating whether or not using this profile has been negotiated with the corresponding (de)compressor. > (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. done for all three 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. See separate email thread on this issue. > (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. done. Thanks for the suggestion. > (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.) applied the following replacements: RohcChannelIdentifier: Integer32 (0..2147483647) -> Unsigned32 rohcInstanceClockRes: Integer32 (0..2147483647) -> Unsigned32 rohcInstanceMaxCID: Integer32 (1..2147483647) -> Unsigned32 (1..4294967295) rohcInstanceCompressionRatio: Integer32 (0..1000) -> Unsigned32 (0..1000) rohcProfile: Integer32 (0..2147483647) -> Unsigned32 rohcContextCID: Integer32 (0..2147483647) -> Unsigned32 rohcContextProfile: Integer32 (0..2147483647) -> Unsigned32 rohcContextDecompressorDepth: Integer32 (0..2147483647) -> Unsigned32 rohcContextAllPacketsRatio: Integer32 (0..1000) -> Unsigned32 (0..1000) rohcContextAllHeadersRatio: Integer32 (0..1000) -> Unsigned32 (0..1000) rohcContextAllPacketsMeanSize: Integer32 (0..2147483647) -> Unsigned32, rohcContextAllHeadersMeanSize: Integer32 (0..2147483647) -> Unsigned32, rohcContextLastPacketsRatio: Integer32 (0..1000) -> Unsigned32 (0..1000) rohcContextLastHeadersRatio: Integer32 (0..1000) -> Unsigned32 (0..1000) rohcContextLastPacketsMeanSize: Integer32 (0..2147483647) -> Unsigned32, rohcContextLastHeadersMeanSize: Integer32 (0..2147483647) -> Unsigned32 rohcRtpContextVerifyPeriod: Integer32 (0..2147483647) -> Unsigned32 rohcRtpContextSizesAllowed: Integer32 (1..2147483647) -> Unsigned32 (1..4294967295) rohcRtpContextSizesUsed: Integer32 (1..2147483647) -> Unsigned32 (1..4294967295) rohcRtpPacketSize: Integer32 (0..2147483647) -> Unsigned32 > /********** 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. done. > (i) In the DESCRIPTION clause of rohcChannelFeedbackFor: > s/feddback/feedback/ done. > (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. done. > (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) changed to Unsigned32. > (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. changed to Unsigned32. > (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. Yes, indeed. It is possible that compressed packets are significantly larger than uncompressed ones. Changed the syntax of all compression ratio objects (rohcInstanceCompressionRatio, rohcContextAllPacketsRatio, rohcContextAllHeadersRatio, rohcContextLastPacketsRatio, rohcContextLastHeadersRatio) from Integer(0..1000) Unsigned. For all of them, added the following sentence to the description: "Note that compressed packets/headers can be larger than the corresponding uncompressed ones. Therefore, this object can return values greater than 1000 when it is retrieved." > (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 fixed. The same fix was applied to the following objects in module ROHC-RTP-MIB: rohcRtpContextSizesAllowed rohcRtpContextSizesUsed > (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. extended the second paragraph of the description: "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." > (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). added to description: "Note that compliance with this compliance statement requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]." > /*** 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. added to description: "Note that compliance with this compliance statement requires compliance with the rohcCompliance MODULE-COMPLIANCE statement of the ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]." > /******** 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. for rohcRtpContextAlwaysPad, rohcRtpContextLargePktsAllowed and rohcRtpContextVerifyPeriod extended description by: "The value of this object is only valid for LLA profiles, i.e. if the corresponding rohcProfile has a value of 0x0005. If the corresponding rohcProfile has a value other than 0x0005, then this object MUST NOT be instantiated." also extended the descriptions of rohcRtpContextNHPs, rohcRtpContextCSPs, rohcRtpContextCCPs, rohcRtpContextPktsLostPhysical, rohcRtpContextPktsLostPreLink, rohcRtpPacketSizePreferred and rohcRtpPacketSizeRestrictedType by this text. for rohcRtpContextSizesAllowed and rohcRtpContextSizesUsed, extended description by: "For compressor contexts where rohcInstanceType has the value compressor(1), this object MUST NOT be instantiated. also extended the description of rohcRtpPacketSizeUsed by: "The value of this object is only valid for UDP, RTP, and ESP profiles, i.e. if the corresponding rohcProfile has a value of either 0x0001, 0x0002 or 0x0003. If the corresponding rohcProfile has a value other than 0x0001, 0x0002 or 0x0003, then this object MUST NOT be instantiated." > (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)/ applied suggested fixes. > (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.) changed SYNTAX to Unsigned32 (1..4294967295) > - 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. removed rohcRtpPacketSizeAllowed. > (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. added to description: "Note that compliance with this compliance statement requires compliance with the rohcCompliance MODULE-COMPLIANCE statement of the ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]." > This concludes the review of . > > Regards, > > Mike Heard > > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc > -- 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 Fri Aug 8 13:30:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18517 for ; Fri, 8 Aug 2003 13:30:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB18-0006dS-Pw for rohc-archive@odin.ietf.org; Fri, 08 Aug 2003 13:27:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78HR67C025502 for rohc-archive@odin.ietf.org; Fri, 8 Aug 2003 13:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB18-0006dF-Jm for rohc-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 13:27: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 NAA18474 for ; Fri, 8 Aug 2003 13:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lB16-0002Jd-00 for rohc-web-archive@ietf.org; Fri, 08 Aug 2003 13:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lB15-0002Ja-00 for rohc-web-archive@ietf.org; Fri, 08 Aug 2003 13:27:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lB13-0006ct-5Z; Fri, 08 Aug 2003 13: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 19lB0j-0006cZ-Ta for rohc@optimus.ietf.org; Fri, 08 Aug 2003 13:26: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 NAA18468 for ; Fri, 8 Aug 2003 13:26:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lB0h-0002JW-00 for rohc@ietf.org; Fri, 08 Aug 2003 13:26:39 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19lB0h-0002JT-00 for rohc@ietf.org; Fri, 08 Aug 2003 13:26:39 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h78HQYo25176; Fri, 8 Aug 2003 10:26:34 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 8 Aug 2003 10:26:34 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: =?ISO-8859-1?Q?J=FCrgen_Quittek?= cc: ROHC mailing list , "Wijnen, Bert (Bert)" Subject: Re: [rohc] MIB Doctor review of draft-ietf-rohc-mib-rtp-06.txt In-Reply-To: <2147483647.1060343514@[10.1.1.171]> Message-ID: 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 On Fri, 8 Aug 2003, J=FCrgen Quittek wrote: > Unfortunately, it took some time until we could check all your > comments. Again thank you very much for this really helpful > work. The document improved a lot! Thanks for the detailed point-by-point responses. You no doubt have already seen Bert's suggestion for how to avoid citations in the MIB module, so I only have a couple of points to add. > > (c) [RFC3095] has an incorrect title and an author list that's > > not in the standard form. >=20 > I replaced "et al." by the complete list of authors, but I do not > know what is wrong with the title? The title is listed as "An RObust Header Compression [...]"; the word "An" is extraneous. Here is how the it looks in RFC 3241: [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. The one in RFC 3242 is similar. > > 9.) MIB compilation -- the following problems are reported by > > smilint: >=20 > I was surprised to see these error messages. > Looks like i used an older, buggy version of smilint :-( Actually, that's true. It turns out that previous versions of smilint didn't check for failure to import the base types that were "inherited" from SMIv1. I was bitten by this when I wrote the WIS MIB ... ironically, I had checked SMICng 2.2.07, which did not require any SMIv2 base types to be imported. The problem is fixed in current versions of smilint and SMICng. Regarding 11(e): > > the authors may wish to consider changing the order of the leading > > components in the tables that have rohcInstanceType as an index > > component from: > > > > INDEX { ifIndex, rohcInstanceType, rohcChannelID, ... } > > > > to: > > > > INDEX { ifIndex, rohcChannelID, rohcInstanceType, ... } > > > > The affected row objects are rohcInstanceEntry and rohcContextTable > > in the ROHC-MIB module, rohcUncmprContextEntry in the > > ROHC-UNCOMPRESSED-MIB module, and rohcRtpContextTable and > > rohcRtpPacketSizeEntry in the ROHC-RTP-MIB module. >=20 > See separate email thread on this issue. Actually, I think that you have already provided a good rationale for the existing indexing scheme. Back on 8 Jul 2003, I wrote: % >>>>> On Mon, 7 Jul 2003, Juergen Quittek wrote: % Juergen> Initially, rohcInstanceType was no index. Probably this % Juergen> is the reason why we forgot to make it non-accessible. % Juergen> But after some discussions with rohc people, partiularly % Juergen> including with Lars-Erik, we found that when accessing % Juergen> the MIB a management station would typically look either % Juergen> for compressors or for decompressors, but not for % Juergen> particular channels. % % That makes sense. % % Juergen> Without the rohcInstanceType being part of the index, a % Juergen> management station looking for a particular compressor % Juergen> or looking for all compressors would need to browse % Juergen> through all compressor and decompressor contexts, read % Juergen> the type and ignore them if they are decompressors. % Juergen> % Juergen> But with the rohcInstanceType as n index before the % Juergen> channel ID, you can first select whether you ant to % Juergen> browse compressors or decompressors and then go through % Juergen> the (shorter) list of specific contexts. % Juergen> % Juergen> I think this is helpful and matches requirements of rohc % Juergen> management stations. % % This explanation also provides a response to review comment 11(e), % as it provides a good reason why rohcInstanceType should precede % rohcChannelID in the INDEX clauses where it appears. Abigail Surtees did ask for some explanatory text explaining why rohcInstanceType is present as an index, which you agreed to provide; and if, when you add that text, you would also note (as is done above) the reason why is appears before rohcChannelID, then as far as I'm concerned the issue is closed. Thanks, Mike _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Aug 18 13:50: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 NAA27358 for ; Mon, 18 Aug 2003 13:50: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 19oo8p-0006oF-Nn for rohc-archive@odin.ietf.org; Mon, 18 Aug 2003 13:50:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IHo3WQ026171 for rohc-archive@odin.ietf.org; Mon, 18 Aug 2003 13:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oo8p-0006o2-Dg for rohc-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 13:50: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 NAA27342 for ; Mon, 18 Aug 2003 13:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oo8n-0001FA-00 for rohc-web-archive@ietf.org; Mon, 18 Aug 2003 13:50:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oo8m-0001F6-00 for rohc-web-archive@ietf.org; Mon, 18 Aug 2003 13:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oo8m-0006nj-Pk; Mon, 18 Aug 2003 13:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oo8U-0006mV-50 for rohc@optimus.ietf.org; Mon, 18 Aug 2003 13:49: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 NAA27336 for ; Mon, 18 Aug 2003 13:49:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oo8R-0001Es-00 for rohc@ietf.org; Mon, 18 Aug 2003 13:49:39 -0400 Received: from dijana.vest.hr ([161.53.165.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19oo8O-0001Em-00 for rohc@ietf.org; Mon, 18 Aug 2003 13:49:36 -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 h7IHnMMq022755 for ; Mon, 18 Aug 2003 19:49:24 +0200 (MEST) Message-ID: <3F411279.8050408@fesb.hr> Date: Mon, 18 Aug 2003 19:52:57 +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="------------090509060209000005090609" Subject: [rohc] ROHC-FN SCTP 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. --------------090509060209000005090609 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.2 FN32-TCP-RTP-SCTP.PL which includes SCTP profile in ROHC-FN. SCTP profile presented is adapted to the possibilities of current Prolog test program by ROKE MANOR: - UNCOMPRESSIBLE method is restricted to 53 bits (uses IRREGULAR) - LIST nesting is not possible (order, presence conflict) However, it can be of benefit to review the capabilities of ROHC-FN. Best regards, Julije Ozegovic --------------090509060209000005090609 Content-Type: application/x-zip-compressed; name="FN32-TCP-RTP-SCTP.ZIP" Content-Disposition: inline; filename="FN32-TCP-RTP-SCTP.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAgAIALCdEi9nUWGid1YAAA+sAQAUAAAARk4zMi1UQ1AtUlRQLVNDVFAuUEzEWm1v 28aW/l6g/4HXRREZkVW+v3SBXQTetMk2TYsk7f1QFMaQHNrcyKKuSNnx/vp9zpkZckTqrb1F I8eWOBye57zNc86M8vXV3/f68ouvHcd599Or66vv3jr1yvl50yybWwz/vUqQHq/f/vrTD6/f fu98uP7Z+fDy/Yf33+o7nbdwFouF0yULaPutUzT3641sW9k6YlU660296lpnu+rHSx63Lu+k KOWm1fIejMAHkjiRV8rTAHNLunLi7mskBzJE8VF27djWdx9Gtm60apu/ylYj8GHzuW19fz02 ttW6tdFfZKwR+EASP4Oxf/vC2bd6YVZzuxH3Tt1C1Qe5bNbkuA4zf3jp/Pji7U/vnHcv3798 8e761edZ6ffrpbyXq050dbNyVk2HeFTNxvkVoaSRwCQIwvm6e9ZiyqOzbtq2zpfS6RoVOKfZ do5wlnWLj5UjlksdDJJ1LzolUzi39YNc6VhKhLqsV7fOvezumnLh/M8WT3dPa+lc5Nt6WS4u SP6ttCV3d3KPZC2RboKxvnn9M/m9qpdy4byT7XaJWWIjnVY8wPsIDk2k284F9F5vu0X3qbtg FZeik0bcRlZyAy3l4lxn+Zaz/inZVXfAdNrtet1sWGXSLBd5vay7p6tcUNqWdVts6vt6JTrc N26Zc34Lp102j1qhHE5uOyyzJ6feVUV75tW2qu7FCv6/bTZ1d3e/cH6sV/X99t6ZLBMts63/ T7JeRPW1Cm/g5E9k2ky0Tg3Iu2a7LJ1c/uPSeMJfOG8oIn0M9ZPaUFq7pP0dBORSrpwt4SKY RgvYtdre53IDzbUihN+syRoAv39x/cPc+VDfy7YT92tHdsWiBw965xq/XsCpa7m5cF6/MyQw dx7hAPaKWNPtTY3QOhee513setw4t+5agxAunA94EFpvkC7IiEoUcrCmq8sa9mzXZn5EGj1D oOtVsdyWtMQH+9iyClFsyQPwa8dajSJI7tL5qxUyKXxu8nlW8n2YAiBChA3dcPH+n6+vNENF C3fhuQvnRd42y20nl0+Q7dSlFM7jHVZmvxzE6knlGSThHzleaA5oaJrzoBRpaZYWfoWqsFyr JVfzIoRUyibjdOmAHjtZbZfA3chCgiDKfwxZtseQblNTzYDxYkNvNhlBnrhdNW1XF3SpDXAe 5bON1JAmBSlr4b2hgGBg4bxqHkHTmzmcBKJZUtghBNzxiIyTKokfm83myRE5uKMnHuUTTF0p MEq65RNhYAXLf22JRsgvI9JrF851swInkmVi6fz39fetcXfbbu9h1J1Q+TJ+khltLTbtQGmt wAPNBlWYE6M3rFn1IbQrJsYXzi8rTO22WAmI/FzRNAI9QsNS4AvR3cHvKNK8Tm3rl6AlTnDQ z4XY3G4pYEpJpCpWalXVRY0xxLleYVXDZGCWF47cbAD6H1czHXXiAjKGstEkbgO1qxohgXS5 uhPwZmnyzZAffGdczbEFIVjLe1agKOGhi+fPFdODPy5BEnd1cecUkHiLpFLVZaNzg/xYyrVc sSMApCYrOC22Xq2p8sGvqpKAnwUtTKZ9JgvbWF1CxWrVcG5wcB+lmk1GNpZL58z3r51CrJ5R CtSrj1xbIbYDJSlaE1Doij2MtO27Dl6ej6Ct7RLuara3d0Zug3liuSUqFBtQ3kYglVVY5SeT FS1zJ5X0j/CSUlQinTZYoN2ug7Tcqt60ncXP72vKd7USSDmVPkrKKN3nKnXJbWQqL2GU+67D im556W+cq97bhI7FvV0KWtX8QCsxRk8PclSgJiuGZm/XJc2YIWS9r7ctr23OMw4F6kMHC7pp eMl5sr10qk1zr9uIT8gqhl1ogS/FFJyLR/fYaAWHBXLl1LNX8+v5d/NfLhmonb3x5m/8S+Y+ 2739Q7wiAH1Rr1QPxM68UKL7lG7Al8g9nml31Vqk6tadV3MdlVEb71ybGyh/n9C51HIJB33X 1ynlx9JM6BXlab+Q8tBSGduJj3ptMUGxC3kJEtNOqQY1Q5OwFkoJRB2lXueD7wwh53K8yirn qdlyt6kYYwdBi32ldPgkKMfm1Og81kABu3/kdvaabX2okcjENGKxy0/NCkymDeRljOdaw8QX dppfKGrqnpDROnSmnV2KXC7bo4mD/pcYQ6ciP/jGU73hymSlGvVV08UUbrq7I6VHBdiWoB2s sk3Da4UZXQvluYTCIUU5AaieTX3a0EO9qIin7rew6g5dGTe1oxKi3I210a5lUVf1UMzMXqrc iKpT+dSzwEOzfEBKUeuwrbsG6xetmlH/goU36AbJG1SLLtBLybIumJmRL2iRt4IaDlGWFpfv W55EmBSVXbUXzk8VMn+L4jtX5Y+zQadApZnJiEXT0/XlqHX+l7Y5y/qjVB0VNyhaZXS+avVq aqvtTu1yp9tUiMxW4RW169yo3iJRDQNsV7SOV8QQS6eoN8X2ntZIIblVUWVB9eRr4wFumQP3 CoVBL+WF86vY1ORhiuBuXdOtrt6jsRu2a7oMfJKwQwlGKcyZkQMujQJ664E920NoDPxpTfLR /8jW6mnfgmZuWJqzEsTP4KtvnestqhJ3FdpnlAnCuVj1sy8mS6ozZRbghaobNH3PPDVEAnV+ FmrJKhKbOwgphQ8EYKLdNqA42ksMJWLn0ETRq9Vost/upWCqFrTXHTq0vnvpy1PZKARo/ig2 5ZXZo5LWucSoJCKjst323S/pYJ+TWBsePLNsqDI3hzSlHpm6OmW35nXKH9E+aYVqY7vKU9W3 3Anun+oVc9c9Zz/R8W4zj4WEpu5RsCiUUuWN0Q4BtyioTE3Ncqk6kvYJIj59O3DyO6na9SHw M1b5Up8WcW6Pb85pvSOo3zg10uiW2opZenk5Om3aO2lyHLX3Nexk3qtdNDMUY0/zsiCmoGRb yce+8sJVm6f/4pKjKVFrx8SIkvqkE6ffqasAsCeZa5RYavDQ7u3IrWVrelAjtKFmk1c5sRP5 HUnFvciG02u+b/NaNrKl54p+MSrMfsu1C2lqh1pKky3R0EZ+sDoQWDOI7/Fpq02nCdVSqCKG Qg7eo54sfzKUqLs2U2ZfLFGWVpyOtOUh3uDQKOYAXUt9MGOgVauCTB6U6THMzqpvpvl+C0NX t/oERVXQQihfDpa3l1at1OmhbnATTJluTk24l0MlXXY1DNf2qKTQTnHQjgnC3Rbdtt/sqg5c d99U3YggNAbtx/u6vxa1qhy015WqD0He0STTFaCQaKkqf2dvX/z4cv7rize/vLy8QM/FZbsh D3Drp+xhK6DAgA6P3FNqKRtw2auqiiI3ZaSAWqCQQFuR2zuzT+LNkDrIYKAKiQaDuWXjdH+S tBP58otvr1B0Z1nkzj9VT/Pnz8nbaix01dg3w5Dn8dinOeCH0SBSg1/poVZ2N2smuRsk3O2s axANZNENH4Le6OOr+W//2jbQb1aJZSuxyaSjko14miE4dHkvPt1gX9ndzdzL3y9Z17//qPp7 uZIbOiWh86gWXZT8u7X48gvCvvGcq6v/3GHW58+//MKiUE6UWTr33PEd7H8knitv6BATM65S 5U2W67NclanhnIYOPt5UFSJ7aFavWTi+ZVWTU08OegUn9fpTYsORG+17Ed9Tfgzn7uVOJbMn xjxxT7mzJyU8aaZmPX+u3knmbNdV9pX1eDpSNPAunefPrQHPmpwdUsiLd60IfOspz+XHmg3K Cij55k4di2uVna+ydCLrK28sDkO2SG+/SHVyNFMrXyznq3o5n+Tp9GXmz1RQAh8PATHL9mhx UthYB5e0sF3uqbVwL9YzWimsJIweC6ZaoCZ4+HHnv4209GLScj4aTQ8NTsxJ2ae/T3CtfOcz pcmEQcRUaethalxps3vk+cD2SrA/pCP/743Jnx6y8cdLdo/L3ImYc0eyzEKKpvGfJunh8O9f f1bQD0z4t0Lt/5uh3iGEHWLbYZuU2WfZ5jOPFuGIimJbiCK+Vi4rlG/6AilHW3Wj+hhkfAJG GnlgrF1PQC58RZhqnUT6SmnwVTBlJ39QQ23LbtzZb54OFP2Yd/PZvtY/v19OhHizZ67roh3C K1Lvz6az/NmzZ5+rTaHvzj5ni/L1zve4wrnnFrZDO1fwdnb3K8L+8FWdY9NB1UfeJcwdubg1 m1Wzx551xbqPBO8F+NYNL0S6p9Ku3yXwqaPap9hfS7adObZEA6+PTvv/rmMhzF5dzmkjsJR0 4KzwBpTZqzeXc0JGN6QfaTE2v36jE2KQhNRzdxJvT7Lt+VEz1dxxRVN3vL3zvUmCT38OyfMm cgd5w73ded4eeWMZ7s6z7khLbzLzz8qzdT6m3yFv21f77x+LxzgqnvXUNF621Km902d2rd6V Mb5/SL8p+u7zu+/DM/vkjXPUne9HOS//pvbsj8Q45nz/98maA1OHEfaoblDEsihDRdtxHhWB K3DhuZV+L1M3SvAhkaHAPtpzzQu3fS8u3SDzKh7wISLKQ/z13RS3y8or/LLsH/DcAD99RRiU 8UkZlpDivVdGpl5SeElceLnP75mbQ5mQakte+DL1fRlLTwA9jyCdlIll4Fll52v65hAMxbxv /p+KRVK/GeAicX1JwEnlxklZ9YBGAQIlcA0oegVcz/f9IA1zt7C98MzsxJ1XHz78zKcpFrLf IwcF3ovBZDc8YXI59n9aJdkB/7tF4nsT/4+y66/3/V4AL3fxLnuAOJV/ACBlS7OADQmTMIpC 3/UrmJxGIX7wOfB8UqB0RZjGVRIkYSB8N+GXLxM/ruI8jiA1iCtcR3FOc6MoCeIogV9DL07i KJbqubCIMyiZJwFw0gDZEWRBHOTmThIlqe8G0DII8Zv4ZeBhlhvTrDSI/Yw18YBG8l0l1RfQ WYzvADuI09hLfNZF6Q29/BJjNCuLM78AchYFYQWkFD9RkBHmgXH/wHg4Gc+CCJ+iA/OTA/MP 6hMEdCdJ2Hsh4pCQHRj3McM9cs87co+1iIPEDcIgsK6SnavUIPRXvnUFNzJCCq8OI2US9aPw dhyMrkqKUT+WY6zk53kerivEG3cSf3TNz0RhGERxKMm/eMRT+mCE/BaEWcheRKTDOCYvcl4g O+EBiUxEBsMbuOJ8RO5StnCeIgOTOI5oPv0eW9GVtaKjowsuyGO14KTkFZ1RMifx4RXNAJ5r ARznLgMQC58AiDUjIcQpAM8CCM4CKOApAigFUjSVpwB8C8A/AyDHMhcEEGQuMj/xTwEEFoB3 FkCScwzCEAEHU50CCC0A9yyArPR6gCgMTgFEVoGqzgKo0ogBqhJp4ScM0JfEH2nXs68uBkNF Bmw42JXI43YVpUeweS5Dgq2ioMizMDlhVzjYhZp/HkCVDQDBqdCHsQVwvN5pgMITZQ8QJKeS F6VwACjPAkhizwCIsji1/MLUAijOAkBq9QCo26cAMgsgPweg9Is+BsKPT8ZAWADiLIA0TgxA VhThKYDcAsjOAsjTPshZlp0McmEBpH8AwNMA5VEAVwl3K7S+sfSPk3hR+hpAWhYUu+v7u+nK Dq2O1wCSRX4oPLPT6HcerhcBNJVlURVJ5ckEFUOiDKLX9mKQepHH+zreMBERzElp54GWyjvR 8QZFESU9A0SVn48VSQOi7sSTZRXJMpm03mERRUcVOa/1hterqs/SIEyKEx7xjUdS7owxqSwr DeRZClTGE+iifO5OC1STJEbnGsbcNbuq+6VuAj0MkiHiT0mgOg/unyPuJyW6JfTX3JOlPpoD dNQR+qEwyXx5pAsJQhiXD8aJ8qhxqR9q47DxpH2FcJOs2mOc0GEuvQPAEQEXA3B63Ku7wOxV 7E79Y8ABvTx0dC716fhJ0Lf6cah8k3jwdcZewkgc0z28I29wfcxjYQnFy0Fx+Pqo4qFWvJJG 8RLboYniGYoJKR4JNMZQHMHvNz9GLSQIwp7wRoiu0IwfVzWBqtJSNTmualSyqhW2bVpVz83S I6qi0Ua+RaRqKNE3p9RVJ4CJI7VLU13zoRTwoF51fgokrlLP6xcWdl7lRL08ylm9JA31tsZF o5+E5DFq39XmQXIiBEgCtdFDgsSoK3Fx1KMxR87iAnFc5VR71MuMylGs9/w7Kgvl0QSbF+IC NK0h73Up/LznSoY8VrsLzChhTEifsAOm3W3Bvx790j4Pmxj6DGbBe3aMA05Svp8VMCDKpExc VDhXptA0Q303lJ/rk6d9TDsYl/RMu9tr7ilIkVWQUlH2PTqKWbnnCCwlt2uC8Md1AL7bW5D6 QnReHUCCijIcFAEHHFckMPUg1UcwSR7mduyNAqYgndcDkAUjYKqCqhqql66I1APwWCAyBt4D 4BnLIsvF+04Zp5aBkwfL3H2WpabSHQKWAI4H4Dz9A8B86AR23QNcGpdWUYTNfBT1HHpgGfRe SCwveCeUKQ3B917IRHVYGbEvvgQcRgBOB2BR/QFg9kKZ+VNgVBIDHLmhF9GJi3vooO2YTzIr QCdUq6SpJL1P0HTvUS0xleQQsACwOD8zdoDZJ0XoBceA4Y8MvyczIreUOE49qJumUA3W58Ue JfLe+p4IP8jlSnZjGoyZBj/TNwGHnAJFpKWIOKGIJ3N0uHjUOKUq43jsFFKAnOLFeXhomaDj LaoBGGXlfGBOiaSsjgKjG4Gb8Df3Uv5b0V/f5b8e//X5b8IzI/4cHPFT6Vp+2pfBlrp+odUt Bj8Fk1V9hp8Y2LOAk/OAg2AA9tI/AZxIAPsDcL9ROgeYA+RX2akACUpi/sYC+46KQiOo4PPx v8sNkP7U30Uqh15Y4jeIKjBhEAjrLh9ChSEd+uIeSCPKUDQPzifHRGkUUk0JSxo9FIUEzgis KPjHnYHpyhmxcUaVFxMCGzmjcPdtr3r40ILfV8xs+EzBJ8kAn0yoC/BSw0e8BA7CUw5G57NV olMhkX0OFkkyhZe+gT8EjLZ56CjOsNsGZrtRfssJMGqnAY69Ufe6n7mTP3aikpBarIpLWzbF X6a9LrCe9zG3yYSewU81sAE60P6wirj0mCKANOvU7PWrMtnptsYKHGJupGM+HOYW5b596CFg 3jUVsR8eA6ZkZM4uma1LP+C/yQGFohwKDYe/RT45WxopVIwV8v10sjEeKZRzKSm5iJRcPqQq H1w4iLU8i6M8i5E8i228oxwDMxLLr/K4GUFguMaYUeVVdMqvBxd5EgF+OIAusuoEfGy4pt+/ 02HIFD7a8aIX6UOakL6EDXe/4uUDnIKOuuisxIdLfBnwURltoDEvod2+/ro35+00fXlXWF8O 04GZq47T6Fxg+JL4WGdICZRZnk+Pm570dDOYnrlHTJf6qCdT3y8eZDuoISw19p3e2WpIrUY5 qJEnEzUSv2e9+CDDE3RuQe87vLGhNasl/TFYKrPJMRiiGGloGR+iE4YuLOgTqzfVdJJUvdVJ OqUTSi2GjkXc/wcRYvl3/fHEptPs7ip2BwXQHlcxvAfGjpKkP34wL+nlUYZf0DeDCoz4UUY9 R1iFVRnJNEBeFqwO8pI43o1d2kRkmEz/c0V9Q2DKTq+F+n8q9P0E0vX/ubvaHrltJP19gf0P 2gAHjy+yV6Sotyxyi2R2jTEwF8x5nT3HRjCgRMpu7EzPoLtnHB/y46+q+CK23ts5IDj3JLan JVY9LBaLT5GUmGhaqOA5YznXZR9FCsGibIHcWBQlmLGB1DNrG5lL6D+48J3rpI8CCBCEbqRA 9MOGKMyqoM5xpJOZ4SxSA4o8GaAomoxVObq+mdSADL2AARH+YG1ZtJCMVlrkJGPUFrNows1T 6+D4fUj4uoiIBQ3Mfg/TDt3dA2gDAMVKALkB0HYAQo/SSdsDwGcA2MzRAMhXAigIQF15ANDd GFCaFAg2BDvWt8BYKuUBsABAthJASQCgR3sAJauYZDX0VcU061tgLLPxAHgAQKwEUBkAygOA kYl2pHHBYVjjfQuM0VoPIA0ApCsBSAKgig4Arg5JXnMYZIBO9y2QzwEQAYBBmJsAUBMAzTwA 9HRa4RA4vKR9C4xRNg8gCwCwlQAaA6DuAOAuKQkjeJOqVKd9C4zN0nkAeQCgr38KgCIAbRcH BOajXKQwAuAWhL4FqjkARQfArikuA9AGQBcHRAlDD9AhSHeV0OLYAiwNpucpLvIgLpohB4N3 UbapyZ5bDnBUWRUVa5sSGlenui25rDJoYI5tlls4CjpEndHyJU5GQhSoTUIy/hlE2t/nM9Ie 3gAE0RqgXDZAhgbIjQHUF2EAYrHWAMVKAxRkAFzT+gIMQFt0rAHylQYoyQAF+yIMQDMC1gDZ SgNUxgD1F2EAYv/WAGKlASQZoMy+CANQemINkK40QG0M0H4RBiAuYA3AVxqgIQNU1RdhAKIi 1gBspQEUGUB+ETzA0HFrgGSlAbQxwP8jHnDMC9OAF5pJgIbjLLOiRVHIulPGRF4NaGqNiR9H m5kkokp0UaasYFWtU1lxlidAkaSZy4F8eUWeTIpLUFwFiuWMYmEU56i4JMV12imen3UYy5M9 ABkAqFYCqAwA1QGwCbrLl1fkyQSgAQB1AGDgUQGAMgAgCQA+jmQBuAT9M/Jlb4kmADKYspiw RE1AFPNAPiNf9gBUAGAwZTEBoDEA6g7A6fmyB6ADAIMpiwkAigDozAP4jHzZA2hX+oIIuqFG AJC0dgBOz5cdAGN1C2AwZTFhgdYAaD2Az8iXXSDK2UofSDoAPCEAugtELl9eyJOzIB6K32OC eGTZDwEIAKACAANXDACYBgO7AYCMAGSVB9CfvnPRYUox1lwHivt6R2pOinNSnKedYht++tEA O+dczRFA2wHIB0PRBIDCAFAegOv9/c6IfWPB9HahYbntQ9OXBKAoPADX+fp9YabmggU1VzOK w5pXpLhkXvFwrihjGceNU2Zz/RwAHgBoVgKQBkDtAWQleKLM6qzJ4LuszXGVjucpbn1dApAG AOqVAGoCUGUeQF4iS8vrvMlVrvO2SAp6FrQQxSIAEQAY0JEJAI0B0PX7oiyqQhZ10RSq0LiK VbKSl6CgXASQBQAGdGQCgCIAsuv3ZVlWpSzrsilVqcu2SoCx8CqthBnWenEwD+Kg2cfbNgin 0WavZq4ZK5pmMIEqkrJoW+wwbjyotcoT0NLmdV3VCbgfxyX409dRCIAAAE0HQA1mkAMAiQGQ IgBJAJq0A7CeF5JiqKtWQc0HdD5QXAaKa6NYdYp7vPCEdRQPRAdABhF5CISaoEEgKuuA9Hmh C8wr+KH3hTYAMugbQ18giygCkhceSDgSIE1bwQ+dL5jBwAIYxMcJX9AEoGAdgPW80CtmgeJB XJxQ3BrFtVfshqIVfNC1vVnCsooHdGzcCVlCisusUxyMfSfyQm+BdGXbBxYACkdAWg/EjYUr +KBXLALFg3g4oZiT4qoLQKNEdMgHyyAO5r/nIvnIehIBabjxCAQiSjWwxxBIAUB4QkDKqgOy LiyNri/nlClos00agXDFBq4ZABEBEEZAqtQDWUhXR9eXEYAAqt86AFrmg1wpAJAEALgBoDyA E+KgaQLVmtyYat6kc4rDJkhJsSw6xb04OBGWRteXqQly80wbAanqdsCWJppAEJCaeSAL6ero +rKxRFEqBwAKD9jBhCUyA6DuAPTC0kSUGF1nJl8A6lU7IIypue4Z+kJOQJrMA5lIV0fXl6kJ wHd9L2h5vbYXFEZxFxdml3cn1pcJQJGbTY3kA5kYsIMJACUBUF08CHMEfC3GQpxk4caboptI LNtW+TkcyDYX53DKBNhxK2vccSkryON7E4knEEYzgQAAdABgbj7PukKOABoDoOkAnDqRCIrb QPHi3I1VrEixzJPfOpEINTcd0AKYm78La64JAHSf/kTi2olDVMwCxYtzNrbNUW+L7N4rtkPB 2gnDBrfndoqTASHsT52aGteJUSw7xRNzFasnDkFcGligj2Oi7c3DKhqC+MqZy8mJQ2GfGXYA 5ubtgravuQGgk/7M5eoJQyieBU0wGAImap6SYtxX6hT3GOraCUMEkK/0gRCAIABtF3Bmx54g ANqXoOHxnBj89vj7vjneZKoKehAN39qS4J5r6MdJgm/KSHLe0GMCqm4q5K28KGVSQQ0UDIdZ CbfSI1fwYQIyh0qWieHdkqYC0IvxZUiAvajC/a6I4BlG5me3Wj1jz5r9PoRltkbiBlowWGof 5Ybfc25g1bqoEBaOSU0jWjBuI0TZNmXVCpVjezDjOQwKwfAkMgovKW9LBytrWgmjCBfM/PRb LAoRlAECuYRAlTor8DFPw3BsZIXIaDXyKpNadSk6NB/HiaxJBAIQ1AGCegkBMEyuVSZ7mlOr 2Q8yAt9CNfI0x5Hm5pS6CwljtBa2XzFmNQur2SdibiVyVrMKNFdLmiEoiLxmNpgxYTVnVrNn m/TSH/iZ0ixAsxkSSDPT+ZLmBGgl9MDi2Nq5beeO3YEnwg+6Id0HvycF47TB3XnmrE1AXWr2 +BpkSiwha0SZ68YN7c4meW2QdfsbgWLTj0UmLLI8QObuxTsGA0toOzOcWITZYquJKmVZWvUQ aovQsxIgnPTTs13Yq2dtx8F2ZmrcIGuTJWQyVW3GU5WYdgX+zzAtnaw7x7qLQANf7CtFqmuV KjsKBW+MPA6PvB8eeRe1yy5ql0CRq/zEqJ0vRW0MjVOGRQQcETQdApktIeAqy4C9mIcVQZMJ f2LAVJ2GNAENKqhjs6QhBYLKNT2qZjxXNGBm88CpreOks3iNOtBYL2ls27RlbZH2NKqTNLaB RrmkUehMt/jetyONnK/VCE6ozcqW0VgsWjUH/5Y+UQDaZT2kZBxz6S6Y9MKcQSZWI0MmYrY8 GmTlovVTBt0I1wls+LIai0BjGL5GQ7/XHLRCudiblNJ5XfpWsJrNslVPMz1WNKfZvEvOak6X NFe8kpB7Nz3NTc/KzH0/2X9RcxZ4XrLoB9Bza3yDTTkfttJ+2DIbeLBjpaVqUmriGvp/Wgky NL7mAJWyBrN+zVVZVfi+HF1DuIAgWeFLjSyrK/IyrZVJl0VKVJnCVi6kzAAt1gcrN1Ztj6AO EGRLCFqIg1rnRZ/VOY0lg9BWCj/ZPsfqCIEABCpAUCwhSIGYg1c7nsGs5spq9qmESKc7mNfc nlL3Km8g+cvtqj7jVrO0mn0WJcwLG2c1G8NZzWJJM5eQ/pSOLQLDM5prq9mvts+xOtQMvaAx djGaebWkWWsY8xNe9OqsjObsKNz50AKeCWGxkErWgWcy+z8ntzDXB499eqRoIx0gXewbTcag w7unRZxHlrlF2nFuw/F8YLZImgDprN8gMsPuDLIkXUKWsSzH9x0c27BqDbLCp/3E7JIBsnYt Mg692awTE7KyrRfjSZbnCgYNz+6EBJ188Dyo1wB1N7t7rAa9pAH6JWQFWbXE7kQ/TJp9PdjZ 0pJLs91Q1/gS1pZcoVIpdhuWqbTI2wZ0Sugg+NxvyZqaNmXlLkyyTCggBWaDSk0TfhQm4d9C ZjitO5385rRoDwikR2DTsDkEAjutSloXJqckC6ib2Tpl6qb0kuS0Kdss86GA2zrUJc8441WX 4KUimE9iqb2vgcGiKnW1Kvn1CHmAUC0hhCFcFk1hJxTBrEazsgi7ocF+7H3M3qctwlVJskeY BgibJYSZrJKGs7pnw9Yi7IaQTARbuJwNIWkwCHvJ9AJCESCslxAWPC2rwrWgsw3uRiGE3VBz NG3rbF1yi7CzdW5+phBCEVkECOtFhLpOhGwzdWxDKQ1C2WkuwuUNf19tEEo5uM8GvyznHFzJ 7Gqru0fw5mxsdunYGsilGkA6yhqWOT+1rdvYnlR71Dbl7nlBY3tSnfXvm4wiiDAPvGAxikiI WvhWBReeBc5o8WyyFTFOmYWltX7WNoxn+DKLhfCc9cOz2W6E/CktcQUQS9eqFDX2LlCa1VlO 1FnVrG5r83onnJHNm7RSTMuM3h+eEIttVVpK09RZRZzCsNha5CmntzhOslhEwAUgEB0CXi4h yLIcyXM6F56pbig5C+pWLEnWRQbDKEu7OaQqrbXxclu3MBUaTfdRs0Cr5p3mhC9pTiApTfO0 cW7qrKfKpJE6mO10QfcYoQgQmgv0fTWaMnnbFKe0u6gTKSFl72muxjXLweqB15zUqZlDtZrz Jc1pCu1dQa7l581Ig+ppHu261BpQV9XVtWgX61rgPsicdbzZtAa3rTEZ9gwyc30NMmwFRV6s qlLgSugSMtnKMmkFP24FU7ueh6ZzfYODh+pOc92qxfavqlrXMFDacNaW4F/p+KDk+rXZR2jr liz2gVRCVgRdsBfOfpcj1vB4tQ9yh+ep/x4HrL0+Otf7Xu7krT7o3T6SdHSxVngq8Tba3h0i /cv9zabZ4AnQ9jx2PP/5EO0etofNrT46Ze0rd8za86+i6P3mUZtjmPcgPYKvH24OeBRxd1t4 Ght/+vwrAqd0K+HOa3dG9dngtEh7NGB8TQduriiA+xoe1P31xmmzRZdL0qDWL+Y1mm/Pwtee hGLt5WAtMbyK3wTXjkrey083d1KdJcdf4tlM13gotDzszTVaudSHffRwbw4J394/gJG3Cs9m xn+a877twc/uKGw8OrnZ3MvBQeDf0KlTd/fXdMTy2auX8fnL+NWL+PxF/JLFL3n89x/On9KR jPYA1J2+lZstnsmI7+ahUy5fvVw+i9V9rBTnD1p1Ys5fnCyGTginwi/ZyYW3d9f15rBfe5qs +4BBTtXUsxmYF8+O/a02g4b6HDHGZtCyn1PY2cycfvu8iy2ATG0aeYBgst20n87+ehH/9Tx+ dhV//SJ+9mP8NbkRXsKj6c+jj5vDB3Ngu69U9AjhCM+5v2vpgLAI+mb0uGk0XZBPn0ffgXNr iUepbzUemH4Rn0e3eBg5nQK5P0iIT4BAxXT8OV6gU+A3+wMKhALuYHk63nQfvQCRN/u7OPoR T2A34FQH7eFeoTR/evtx6RhlYre7Gi1s+zO9wModLflyG/3T1pHjofF41qVSdMQ6/WtjDnrt ojP6Gp3pTmH4kz330vVgFGk6MSHYu2PsjUH/rLT7J8k3oel5hE1mmgjMF1/FL+IfTR//5ln0 n9+9ib6NcLzvj8HB5+z97u5hq84uICz8R3TBoMRFfKO37w8fQCTEAvfLOYtB4FPo198m0D+/ Tf4y42tW6DkJPUeh514OeLoXemGFviKh/Nvk6QzUhbgWb1AcwAQbPI33Z+9+jt/9/HRO4Gg1 Cd50GXl/r6Fm1/FFfMGexv5XKMfW6OIAu1PGMUyu0sbji1AbFFxRDkrBnVdzd55ZKD/C2IiN ddg96DASBCzDxwToOtCJYdCq9eGjBp4hrT9CvzWEATqvkjsV1TQa+06LQ19M3axfAq9gr8Tv f4ELzeYWuo483N3SkGY1nn0XX5JrW//6DiEP64bFrqFX6T0WGG2WW3lPR8aCtusDRsEt3Bhf 8rF72xt5OOjt2SUH7SNeb8FcjoOx9r2M3z6No7cMO3cZ/XvU6M0NMpa30Z+jEkpGb0c027I/ xG87V/shvo7f9c7S/NlfvYx/mKjxw9bXY6qix3azh0F35UyH6n/5PYu/5/H3afy9+PWS/4za sYU6w569jcObfp7zxlG4YPZ0XSFrhHdvAUaKSAhsAEWU3nZQkyhEKSp3ifUvZYm5xIalMuYu MTJNeInH77qzSY9Lpe7SUJcwl8Z0Ze7SUFcev2Pj9coKd2mgq7KXRnRVpbs00FVV8Ts2Xi8Y a9w1UnZ0icXu9O3BJe4uMedfI8PZ0UDlAoKJwnYEpOh/xXyp2N2F4XI2OvvPYbe5PbsCIdCj TG/YQshDAVcQcSeGvKPRzusklUvIMK7/JmQXiOzCHjfrb0F72eABWiHydIEHIw6GHDcGXfEw ulzH8DvqcABBHB9nhvZc7I4ankQKDSNEqUek8DXdb5gZAJb7/cOtYULACvXt/eHTMv36eBdt 9cfo7r5PwPbA7nDwQbKACTLkykjJXFq8p9O9AUAvqbK8cKcPD7vtfsAHo3Z3dzsgZd2p4dA+ zoWdW0MkvaYvn/dvpdsGaS25zIiPDJT05JG04KZr15L/9bBp/hV9gISUckrXQlhnGW0lmtyO z89wfuD5zPnrg7bYHJ7so/s7kFbf6JDvjpkWQDvaDpdRVkeXr777yZ0Kv9cHlJTgH/LxbqMo BT6goMnmQGEP28D5sBmDX006vo/OwPc+IeFuH27MtElojtfnV8RcgATtyTNN6kcnO/7JmNPb 5jXRUIBNdm9B+eFud/Yifh3PdXG5e3+GkeFi5h6cqz+bY4oDT5i+9Qzt+i3YEoLVUSRhFEmO 4x6bi3u9j00eDN2fAfBxtznosyc/Bm3zTfTkaWy+x3C4vcH/lgScB8WjTsC5EzDSOEfdy03S YIONKxtp2Z7QU/prD8qRpFCMnXZ63RcRaDVlsZCfsYugGz65jfZ30Y38n09xBIkSUOtP9+is fsLuq+gjJNOHuztIqCH3xL5/q6O/PHs6FuCRIF/ftRbPHiL9JYT6S4j1lxTs469fBPH+0gR8 6cl+0FnGR4E9DgNd3Ny7XIAy9ItLP2NAg4QdH1500drOl0GaDTH+OJt3cek7n4XfgEWOYv10 oL88ivR2usBEJvKXfT/ge3Vovq8g9zlAmU0Dxu5sSeFqj5N61kJY9+7W6Axz/Q8a4rGNXLf6 9o7CknyvfZz9cXuz+Ze2U4BWtJkV/ADQb0z4NqHAYoNxDo3U3DwoGB+j5gHjKFVmY3SBxXaA xsfr/d3Nw4GG6O3Np+fRf0ObIujDBxiNoTSF6SNwKAwIEERH/cv93VbjrA2Yuxv+tw+3NURz qO9IO5Mj9x2NEg0zSNoRa3DHxa8Xl3DL+a/n+NfVr1fwF7rkC+qQ/9ZZdlXecPRxmfpl/KpL 1MNfruiXk+W+Igr2Kvo6YqcX7gjxC2bi+59OF2Li46t1fPP4A6VwLgnHDBt9HUEAx31/Fz1/ /vwJht11I8UsvifeT45FfwbqvttAm0JLQvuRq7Bx3wpvMkR6TorLiKduOo3QrQU/o3MG8in0 z8Uo1xYBD7ymmRN/RgvrRjJz5fNoUMeDLufuWmRC83abmwkLeJHSN0BBPUO4uGQoAJH1rpyb K+ejE0NjHxCFLAmLEE+arSzQmCmy5CawzDIRGT5GmNfr5A2405i8c5I31ron8qhozDn6ck/q KX08x8JCSbRMN+BSoQDbK17//R+v/2EW0JhjVn1Xj4drmU1/fRHSvwOfEMDXCkgnBKRrBYgJ AWKtgGxCQLZWQD4hIF8roJgQUKwU8Mc/7HoN2R1MMRQxvsYMYnZ8QshIY04LSSeEjDTotBAx IWSkUaeFZBNCRhp2Wkg+IWSkcaeFFBNCRhp4Usgf/7DvNXKwJD+UM7IfAITs+ZSIkTaeEJFO iRhp4QkRYkrESPtOiMimRIy07rgI/OkNco6Pm0DZv/jm1zcdB3/3068/Xf5MoTycR3gD1HVy cBj79JS8oQH8p0uDIBijQPI1aTPj2htK/Q+yPmPCkZ1/6p3L+ORhkt+4iaaHpoFhsX3AFKY3 d9QtwWpFsh9R8qdgRFzmOgskZ4bdLLHQiRkTO96TET4hwetqGFQIEz7HsycEDfWzVQDs52Qq 83/MZNaK+5v+TUTL0bsj/1jPbI48KpCxRGi8JlPGEBj75cns5dHQl37xtdzl0ZCXfvG1zOXR UJd+8bW85dEQl37xtazl0dCWfvG1nOXRkJZ+8fWMBUTswsb7LMbyuONjIk7hK4+7dEzEKWzl cSfGRJzCVR532ZiIU5jK4y4fE3EKT3ncFWMiTmMpj/uwWT+Dozzu+aiA1QzlcZ/+b3vP2tRG kuT3i7j/0IODsGQ3Ni0eg8ezs4FB2AQgFIAF47k5hRBtUFhInCTs8cb8+MtHvbu6u1pi8MSu e2PWSKrMysqqysrKV3sRBOsnn6frXgTB2snn6YYXQQXdZDl6cz8YXtWeHwh/4yV+lE45dOhE Ir5SBUvqqFfH3PsiOqBkCHQCkT0SY4tQJ7hKZ73BEMPOOPplKuNjD9A+8FPUZmMuwjztjyfp U7drtJ3GUfoHml3JqDL6KqPU9OnCkcT03JPphVQSSWOMB/UN0oDdnO20hT+TjM1ESGIR4lAw GEWow8TC9jsnEaqvhuoLS43Zfb2I9jFu53NvMuhdDtMVtpKayhP1Gg2mRmfYw/1olk4wvk8G AN0Pe2yP6g378De59wbQp8CI/uDhdBxdDaZ3w95XUsKU3d0ZP8ZBT3uf2XXMZu5hGi3xIf5i 9sdsiXqCTtJJNEk/AiGjfkqnJ62o2oFS6u4m49m4Px7Wnmrop77DXysRtEY5MtuiSqlYniCj wegKlb9ae6V2sfJrvb6yd3xytH0Wk0oo4jWBobPZ1y45EyjQtUKYrHokLjMamZCBDjc/tsn4 snc5GA5mX5kwDNGfHx0wA50b40nleF4XE6mtD4fOjDKeh/kUbuzhWbta/K5LljHAi8Uwufz6 dTF0kl/JYmishb8oLmvhi12GGOOuETXquZ/Jm0D6x2zS64urwKE33E4eYxhqdxofNlvxu/d7 nnudCg70/EaDdZMG9uID7LII53wCYw6pUGVLDCZ031FrP2hdVJ587yB+6/7Jk/x7dpZdLFqE 759EbULzk19i65bwAU6k/mRwCyoM7BkEQAvElgxIeJokiR8JTzEfynDiiLW4UTfPoeDLozQ+ 4HXc1afiTLwnGyKwbdP9SR2ABh22vd9akgcWvKSaQRGMvqGP3hW9il5e/l89v1V23SPqPXKp 7kUrURKrrXRSj/ca7GqFFtWchqPZzWptjzZtd6UDc4afu9BzDT+KI7miI1LhBMpbhDKp8Rhi jFeqHW1fxDvHu83CUHXPs4NjxBh/4gOwIHoeIZ5qWJDXuBOBpJ14l+L+QPJ30XhX24139093 qvq69c7gDRTt0RzqAJ29htoZOZsrEH9UtvME+VV7aG/vIm9rm+vA1lY9uh1fRVvVUPh3NiCu yEz/Zkgyu8HYOaLTLtpssUPcKDgi4drEAP9CX6Vm7h1msYyuJVuTdcnX0nHUuEMrXgBW2dP6 a/Pj9Gm9LuO0HIb9Rn/VWttHzbgVH9f/PNSDqdE1LI6O5ZDgB7S6wT8Vww9wVGtyUNiXiH6T cffYe+VQD47zaOCWPDHXOXZWPfYCVLtZep1Oai2KLm7hQFuv+VJmfkH/Pv1Z3sJ+8d5Qih7B BCCw1srEeuTO3byjoRVkD41mEbcdrh3YdyDONtfF5qsaVqLYI5bG09pWtGJcSeWOmg7+lYou ns4duiL7MJk/1zZXq/8Q13qi8kPHtxQg/TWaDm7v4Bp7lV7eX19TYN14PJz+pPfP594QPSKg 4YB4qNuOEdrCpqCg1FIUFJnWh2YzjKVKa/vZVoV5Ujamx8/QPr2/XLnDk2GGaczfIkf7vYiM 7I2i1grsGGkG4eA3KzJZhFJxAOUoEvuCs36jDkXFI8bhGI5mET7PNg22q1Cq9ii65BBrzhhe srNUl0TaDrkGxXnfwYw5OPVFvpya3QlQw4sjk+rqgQhe6HB03WC3rWQRLFJmnBjio4JQpXwM wYAExtORuRNl8/UXz5aTDbyk41nCJ8vNKF5gth5irhaaKR0s2QqNlnSmNgGW7chsNf0Lzfmh mSBzGJ8dn20XxWGd7L99dyZvFK38dofNPWpG+Oj4z20q+j7pHu6fnsXUQQEBklJujd0U5ROI TEBufNY8aguwchigxIEqgDFuDp1YBlFFOzI3VIc5YyNK3NB7Bd3pOu+H036McEQKWsf9hRjX Gno3TpG9o/EX+PQH7MQVjG5Gz/39NMUUDTIZr9yNoRsRdkwdT+FuIPbfVOSOY7mFcbSxRsTF IhUbcN9iy9kNoExH4/trDpGHDml0asSYTSfDISw2/Pbmzz2OfmhFv6CO2qJ13KIban5Ghtwf b/wppB6Ww+pOfEYj4+lgzx28Fb6JnkWN/20lBRoOc6sGV95W9HO0sV5MxxtCHb0krDA2Yn33 I1rFKNoe1KvJrCYbFFOZMK4VxvUselPQOjP+AtRvol/olvAGxtMQi/Mk7QlfEQtrSjgm4Uk6 lCFLSfXv2JrUbUo8MhskaChEPbMDCmAneU3/jgbDTH/ChUHrXnftnDCUwqApEV+ECX9RB2KR ozWqiRGmo9nkK2h8xOU6xtTjRQPvGfCFGGiLBxqLAbuH6PHhLg221TzXmQCZ4iairAnxog9S A3QNng5yPO3Poi/jySe4Eexj/sHoU12euV+NAhF4wt5hpvBkxKnibAOk+QEqYqCAp5GynjkN j0pB6Cb4UyCbTFDETDnhRnpk/3421Tnt2dR58kulw7SvcteWQH6NR/DrcAnmc0gDmt4M7hCj zK+X2RLT6JDYBwRTGNPwKwc1DVjDwKxHo14MbqwlmJsl/BFkL2XlwHdjUIqprsYYvp98GYDs BPl6PUbdh4tsfJzA0pN6C4nxw4SYaw6/w3xDhsIA4O6D0gP/QYO4WBa4cCgi5vC1GHZm+yT+ HRQLOHkHUnk7JJphfSr/rizs4ZQDeW8QXHEvjcZdhot96k+QEcV9HninRg+lThOm7K6vAy4c pzyY9tXxjjlKU1xwPXepXaUfByOYh9rgRfqCSk/R4qvTPMDHLnySK2c/h/PuzyXjUKcWByaO u9DNDZrH8/Brt4NqwZo2DqtrOORyMZhOO5NQmxTTZQFztG/Ln1b0P/+gs8nCazg5OgoiAdRq FmBaYHv8QkavsgnuXV2xPaGLgqLWEuUtShct77pGHLncZGJodDm4hbN8OL7u9u8nk3REKgE0 KNZTIglEjbsgyieDy3u0E8egRgAWzNSZD0GiMHjrXRgPut95NHuNmC2Bhe2FILQ9Taxmlx8m xrTLJPX4WOsac/ScNZcCKb8bp5MxPh6eMVlZvl+PgaK39ZidRG/ji3osvUsXBB6vlorBkEk1 qEqYrJLKMyBmpoPbwbA3kXEduztvo6V4KbpEzYKCdVCXuBnj5QIPsC+c7SjTG6FzCnMZTzCI FVZ5ihcf+maEyd94Ihq6irzCsKks4hOHrhCiOpv9+2BqVa5ifaR2lMRHDVcGyKIxSaHKPxh9 Hn9KEYMEL1oesnVDyiXoK3/DSwoaQRSYOMspMOkVtyT+wWUDOautb82ieJzoqgQufJ6k05sx 6MzAbrgF8rXNE/qDbqEeTLEoiEdg2c5r1iTkSfm2KYwDil4xQ0uwNYiI4nQ0rULRPovaIPo3 Citk5XLzHBXARnQ56Y3gqGMe9T73YCPhpkCVElndAeWam+BKhk00TUex+AYOH7xps1aqypPx zZqTg3nPydxeNmvpQJIljt/TyLAIIeswaLTWDeuxr/4gt2w8c9rC5bbjLxaYDYzZ9zfMoSG/ qdsWrq4wnJdw1433S+QXM97J15YyxIlOnP5EDLvtfUo500HoRkeHJu+EZQi+jFtAsfXlvviy YMnCpMEkd0kayg5ApYROYoAuBh3fXoK+Vytrd9u7k5hLw3a85HsHWoBE7H1WCflvpcGsucI3 zlcOecMXyUaxxoh7cHxT4Uq99Qqqeai4lilGHZqgVOuq/lqoYWtCOTUmiUMlZNCErcP65vJA zCWtGcz9qB0k8UFo9BTrxaCkSITH7bNwWJOeGLrdCQXlKR9ROT6c8SO1DPg7XBoXKwfBAXgc 1DZLb2sfwqnnuZX6Gc5QhcEfqUgnKzRv7u6h6ypRbw/NQJLzYqG3wueRwdQ6b8y/fNRyTkJk k0GBWvE6Y14sBNoR5r18QuFr2Wn7wHFjP7z2HCofYuFSVR3ZNsMDMgM7VDBbaExncSdDCNul ckfI83hMNl3QsBuYX4TH4HH+bFo2saKGc+DW5yffK/AglLClo9Bg6IPXcB3zWm6Ln2DbASpO 0B6DRF6LPxKPoIQZ28nF6bEXUEVTwHXwWixRjJxS+ed0JFLlEks0yx86K90/MT3SXXqGlpK/ sg0AN0r3sABMnJ/I2Q4WH6mTM6LgEBVqzj62q7PrIF/PsmAO96H5FjrtgKKC1sHKmd0+O+ri bpio/UQsLhwF/D8srnIIWsWtotmQI6a2WwEzcCgI2Srifc6iKBhk4aoo4qlYk8p8vQOYZmxg 3T+Rlyqs/SPswLl5NDH6srW2K27Ik8H1zex2jPWc+UqBSTFUXy39jB5AdWFA+z/mX7DGNpjU jqwK5SCWfZHFnhh6X+R7dqX5Atpz1tcHT9OjUjKQ2otSMrDVr2FkYFNXcdDM8QVEo86tTHBo GSIcP7o4xrd3tbVvFaBzhJsCNDNYHZOvdAWli5C6GIlf/gZvV1DWpxRt3bxHeE9jySuZPt0U 3pvPqTRNUeAUlzsWVdJkgUnxLgXyZnHAiImpT45yUbJr9FXuvzYZ1ETH47t0wqsDU8S+pMMh FTBHynS9LViVd5NBOkMGk/2Oiq7JvLIlGM1SjKEn5BoRQY9LRK/6kqz7S4i7htfWHuWOS9eV sHpJ84F0wMA47tDB9TkdfmXrPwvAjOFfRazDD+UGRSPCHYOo42K7VaRC3DHouqxZA5qVhDtE IpK7xWbeToEpSNO5F05ls8TILclslpiyBa/JQR7mRxEQjbjTCISoSW9Hoh0fpQNFuD1QnPAM hKk+O2qLAIWVqNPAwrTw50v8E0PZc2MKuE01DxdFQmB/sif8W3Tl70Y2KDb40YNDAg2APJg8 nkLMcgCleOUiOqNFJEzxZ+Qz5aUAfzfQ0YpjK0EnnfQhSxZ2fFxslI6MrVXqKSlQ0EOouR2M uuwwDaapsNAD8wIuBCDl3+wGEMBSMbz3cikig7mqSJHg7sukSHXpYOz1wA2OVw21H2Sde/gy WSUkLyP+O3Rz0SVwen+bbFJ5bZEbnHb194AW11UgOuu4U5Z6GSCAMT8BK9SDkB3hLr5uuFTN fUC4al+AWL8ULlHKQis6x8u6ExEQwQlYdCyjmgO/bGCoZFJYljjzyLDNlejVZgUw0eM6RW02 qnWpVwAcYIHvCeCH1ufmxsbaBh4MbGsVlKyyjbVuftcS4cIUQaQjSpPNYj55AgENNiU5bJJ9 JiUssUYvLVH41QVcdD4QrR8oqeICLr+/wn/8B5lpcOibbHmhP0t8r6b2u0S6Ogccw40O1dYl qVgijt/wmEXjjrzLpH+gISkh3we9xKARr8Xrv/8uKyuYFcTjzNt0pPIaLXFdK07e5zK9lhOF lGCsUKD9vaZv8CdpAwShepjYymgTtspvzdXflae7uRoDWLACtxqqwa0GqHCcaEzMs5iMknsf 4wtAWztMgg4P5lj4CXJUogOHFzkoyQ6SFQ9EwQOn0MHDlBN4wHoCD11QIPsOrnnqCRiOhoco J/CA9QQeuqBAtqLAat04WAt3w2DKLtSmumRqb4Czv3B7xSRPOT7BHoR4PZ1WnpLQM11dgRux G06FUXVoSCbTG2V43aajGQWCrgijW1+E2cmA0FUOrsUD5Cdt0qboRsv9EBR+LrHCqUexfy9s jOWIfPABPvDrdIRGDGlNeMep6jA9aUqDUkUUMnnfn9Kv0zFcpvCXYv4vizS0kmb+0g6nOe9J 0o/U5RtoZGAe4clXxnANmMQYHy8Li8dlCTIyt6MB08xhtjQrZSXFKQW/S3kRWLqvFaO+TPG7 bVL7gkjl9PXrdKbSYwEavi21mSQ1Tn7/oF/7hsnvH4oBW2t6bNN+b9TFdYFLbC1eSazE53wc cvbLiBTtdCY1Lj16E1bNWHrof+o0T/YOj89jJ6CALEMdp25AR+X8V9f6H6xKAD1GqYDO/KUC 6JFvr8xYl3fCYh/yEaM1umVGQZADTzCcLj3VkRrg7PszNzioHd34wihyYe6Q9zDb55iIG580 T+M213A8Rz6+R2cYJShXDQSvGfDPozWJ4wSTlbEb+PeDlgXnIHvO1zCv/Swe9oDc87gdWmUc HquvxOwrAdT44zntLerivBGOWKEAMAEdPt+1Gl5Jz18DZT9HLd4n74HNF6IwBgglLBR7Ef3j Z7yllMc5m08GG/0NYpKuQBcgmDGh8CLhH3F2S2SQ+7xPJFPhtoUROh05ApiuNdUpzV04Q2vv laTDe/3PMDF4fLAMcUazGG86DqcfkjcykQt58x55816OwOBNpypvrGnUdDcE3be9P2pAM3wW A7gdjMQX8w1EzzCayOSIKrywo3bRgBm8oOoJejk448c5hDbzVRwwF5mBdU1grSJ9a34hUUNZ BIPAv5U4AhH4OiI5BPKojTFq9KrQ4L7OEy1zstKWDJLniSlwSS4b6kZHqBsoiDth1UxY/STI ll4+JWeyzkhMTG2nk4j+OZ7exGy+bQ/rhWCOxonMmfMeW2ra0JwvcWEHqAC2SBzgGc1nltZ+ UL/fsVXhjizVEXISmUNjEoSKUp6XjUVBfuHlscNlOnY4mATjQ2qUBaqKGyWG3tLBVx8GWFIZ KeMso8VgCK2bncQphJMpJ3oUz2pW0bS8SPDT+dK75BMW1V/wkF4iircfwa3WSgSaB6H/ErXQ 4EI8fd7HP7jGvBpj3uDmwlUTsWaf0wm+6w9WjKn5G8tlLtZhVIuJRN8ygPyuVcTK6VlqsHZM zAOYn6KHt2hFmfCYipQ8hNkpenjLU8QrLXshvFj5VU+QGbFYuoroFckVpn+By1VtkTuUeYGK f4g/9lSq96NG5WDAUFtW88lkSnyLGKFzLFiBTorhULwSj0jR7wY8OX63s7LXiq4mvY+zOLob 3pN9r6deSShA6FWJgCW9ipbcc2tJ1MOgkhri7X7pTIT2qKwokUUPyhTlulnLiepbiAxAyhBk OaKTO+Mf3CUhU3XtK74naNKTW52Rjk7FoSySXHuCpy2Gtc1u7+hndC7Z1YnqfgCnhBHCAY66 +oMUl9yuPN1QeKtXkvgYogr5SNbbqcH1DP+9DPHnzhSz1uWWUx4oyy6KGnRqCGXZ9dzDLpNb bjdUMkf5oFU2kCjNUL4cjU4oNh3g4L8iX4nIjG+eYwdFDZ1SEUlZ+3kpoJE/f86JoOIgFx/o p5fmL3ZGAk/7UfL8ucicW62/PmqoTwL3Ezg12hlwx4kGeGQipEt6AZA9HZk8eQeRjuo32tTx heLehrV28qz9LFldhVW1gR4+dEuTrw/fOu6A+NxcCbfLG1eGXO32IefDoO9m1VkpXWGKkJvN FQbFDOjgBbC8qZ0CiCkwVfDzlUhkEsnoajEBeG/D6ZI/1/FCp74VvrY67nrzcya+2eKE9NB9 yGnm1REd2LxUqUXJzrkeMk8810YRAjJNhx+7VykerJd4EPCRi0EWctkYKSUNtocHaZpS2lMs fPfjsHddAXg4vaS9ZkAjHyjCI1CDN0Cl209+poGNMLKJVQezF+8M4iGXfCvt8HTWG131Jlcq otyTUfutYsldOmSS9NSlmVLXRRmVexVm3buE+0Ski1n+JFUKPmalYiGUDP+su8oAh+QUNGZn t+/4zxNYphIgIn7IziSP/gkftiBsD5hgqZF60WW0F1MfyiE8m/aQpR+jnWqN/z0oQIHd1jjN 2+6VM701BrSbqs9o/cq7XhqTJVIASYCwd51ObcWbVVEvAfq9vh/2JnJ2ZYvVuOW06N5RoBRm srlNVb5hbzboG7/ZMZA1Y0HEVjSj9YugDIXOgdI25kYHvGyrrEwODxaFSUjsyApMNblIChYd nYpV1knOQuFgZrVeDdGnCfNn1ijoohwwQWiWSN3lYPQxhV+uuuOPH+GiByx5s31alSWL7aFS LtF2qhm3J/yTyJRJnCX5+QZhvj323IPQw6Fp+n/3qG4tyqOFuVTOp4wQmYNj3AsCZXjv0Kt4 JptVYIEiTDN8WRcqxoBKXsPqtqHFlM7kfRYdwSS2EdwHu+uDtvOHdy0kJME+DdQFuqoVYG4j QIgNgCWFWnZHmkRdRK7gxSh+c6kNbhyhfUrR7N5OR15O5B/qnhPdqx/6xVstX4qTC4hXXLLp w8gb0f8by/1kM4YBFVO9Wrias5qHsX6j9vavh8fbu9Fhs/X27F20fxq9bx20js9b0fZZdHq2 fXIWHe9Fu82d46P2SfP0dP+4FUdHzbN3x7vR+fHJwWl03Dr8FRufvWtGb5pv91ut/dZbBMIv 3jW3d5snPxg9dUVP/4gkyqb6bsX8jkHFTzGmDV6mOsHhim2JMiwOjc9TUwAO/oXCr21sirSK bcxmn2+DpGqHpKz5tYuwVJO9RX2K4v9t/U0ZJnvJ1vwb1msD4+TtEr+AYq4HsedoGtypBIuF 5yZ4dlairZIbnztBsCfn75kzPIImyDdFRgKKxhFSHyhkIrSphM6amPfyqd4o09k4dzJgYM5h pM6i8oNUKXneJcjHNXZO2i9hPwLsu2F+Kcts5ZkXQqwGG0Srg0WyhDCFYSBWFs7GcnQKIi2N nuFD9b4xkYNSn/f2L5q70enO9mEz2tveOTs+4VbPnv3APYjoB1QdYpg/eHAKiRniynDZm6ZC 83n+PDJeMGk/bLuonXKjguFgZ1fm0YdjMzrBOTst4o1m61U6KUKEhyZhKiRIQ8S1U6p+ZpJY f65Zr7oTG0m+L7XNL/ERtgcdX47ny3gC3D9rv4iaPaqjxy3vR4MZBmNsceV2rMnMSZBUxB1j rga3INrGH6PGOjaRgFz5lP/W++8QjyieN1YfolrtcKWWUfmeHTFPDuvy3yiO2pGwkFsm8iPM oT1qRE9Wv5Gx6eSs/fL9bvvlflvZdh7ftpR52bDaHFG0rDXFsm2swMsaYl9hLZGysJa3vekM 1i1c5rqcZloGwGi7/Umfz1w1dvloHvjO41JmWNoVaKYrfs3VBrrrCrEWzGthKgloPxtPschr F3ga0DoY7eCqAlb0bEw+p1cBTa/GXPX3GkVMQHt834JqPw0AYMtICOMGtylwrzscfE4Dmsu3 /FZgS/CiuutOx/eTftoF2YjaZwgf8b3Yojm/w+TKXerGbs8u27WM+yzzIEZB1914UspSbE5U hTZGWkLaSTa+4IOQBVveUPG3wM2GTcVpFNIU7recAxbSuD+d9Lv0BuuQ1re9yacwqXnX+zoc 90o3GjYtl+z0pnpabDlakYFsSgI1pFkoe4TlJiPhqRFPqGFhzbEAWA9anhtYKObJq1VQALT1 CGR09CRhZUAfECYo9+e3bpQ7ynRPolqSlvjZTljJWY/X6/YJJQsOeJpuqKaGtLexChP+S3PY WwrMRG2Dod0M2CMmYzlqvTlG1e5rOhPmBkMfJFT6YHBQIfe3yri/HJ2jYo+96FdeTW/G91Sy 2XyJ1nDwKeUqzpwB7u1a7PvR5ThiE1LeDJUscWOhAS7pwiyD8vGc7XiVOpOXk9DuiNMboHnU na5pGpd5Jo1T2UBhLqtEuZKcU9lsKvp88uqVPaU4oxLYPqIL++HD2RqV1XTNaGuez1EATVsm Te5p7XS0FSc/qo6ULcYlytocmUM6S5E1G2sNzV3jrPaNxAsHM/nsr314ucE1RSjNj9Gj1FQM vaKUI3IGLAXDnaoSONQ17N3EcJndU9TYWg+mZpKzmjdZGr7ySMNHnWK4jT7qFBs6mJ8zjVgs ckMFyzDbK1wVlNLGgqGWo+P7CcbFfhwM02l0O5hO9euLVASGfGnQsQgcinZOT3b+SacWlroc zOiNcnReXY3pkKJalpbKV0oRHf1Y0wRUn94Vva8OsE4xXFi/e0y+6ioyECN1+Co7ER9yaJIu OZNDBxvE1mP9MxFRACG1D8+Rvq5PdK2/Fm0uc7pJgw2Z7h811NRSpJxBCQeRHE5O26xgEO1n 06gEQMrkRU2V3t7E+MmKudaIk81SfdNQIGxjXzEY8Ybah+N3TYcBXQAIQei5oz4zI1bauuf4 M/G4jCo4M5fF7uZ6BumEXjJ1N/6STj7eD+ULG0GtBbn9hV5K8ZNcMiUkuusfOhQbYLmc1Hxg wZ+pfRcJGKjctR4wcm7oHR0nMSyq1bKUkN9U+CeB0qu+yvNIvgMVAxWq89+h/nZQ1YF+L4/+ xsYMOuX430oQMmpcnD/JJjtUxLfiAn2b9kZYdW2T3S38JeoK1N8/o/0pv4Jnen+HunN69c// /q8sXdR5xvBCP5Vfam0hVbF5iWXJKwobwn7i5ZZnHPKnANryLxOVwbYMIvmtlOaTp2d8G6fV 2c43dljN+qazymbSHP4quvsDzjIA7PaRvVGSNHMV/Ft5owLYPoc3Kgzrf5w3Kowtj+qN0nvK bMkrHX8LJQbbVvBBYfNgHxThDt7K2LrX/1ShNca5BC4AbB66bIWUTPsjPtlK5wcB7ielPi45 QDR+h7S9m94Et51MP1LbIFq/wF1q/CVwVBV4IJQE15UixXBUdPEqF6tsimjEMC/K8KvFlmrm CHsRx58f4mo91oVS+1uSVb/h0yMnItu4sxWLpo9jiAQN41ENkY70KJ1lyThLjDhTVwbnODIV XI0BVTXWy/Sm93kwlkmk0ZP1rXr0snj+azjnSRI3NnA9+hDhCwmfNFZLERURg9UnniQbYcSs x+urr/KoWQvEVETNOuGIwqiB9Uw1q/2oNhjVyzJUzlXGh2qzrmdcnwoSQ8mMr1L83YKznVRB kjtLjUAseUNZq0JF/uysL0jGRiB8ycxuMhotA/QJLjDYtnTjdw2UdbuWOALUxUcf6QYYfnk/ ovfpsiuJvqCPomKlbhC5fRr3XzyXys4X6Z0pj3jQLTUNDgVz0iD4gJGlIYe6bCsPPPk5Q4Zh OdBMz7YuaAzahkOA5YSISRvByAFLMlCmtAMhHeMZD74GldpVPmVGY6VeeftZ0xZs+QX6bzaM zwl/tkzNGj0rZNmBS3XkR6mOJBssZ6Ina1mVpFS5Mb2r5h3B7XaxdImoQsZE0tiqEPsTMMaS jIlkfT00ZSIKTXaw9WSbk8bWVIu3NCJvcv2x+690MsYJpg/jEVsn9S/m44aChOm4GiFgtxvo S6SkOfSqIOpJ2mwJ3WMGgrzGxtoVd40M2eSdMY4Nds+sJJsVPDSkZYJoqWCxRhC0MABzcY1X gktHVxUhRuMuv34Ovno8UJH58qhQ5eZ/YzGEWf9NAMv4n8FEzQvs9UW9FFnUfRSUGdSr9rVl nMEjR21wbqiruqm5OnxNje2KG8SHVf7W/QSHWpCFCBsP01JjqWp7ORz3P1l0UF85o9uwScae XJJZv9iKzTbXsxsHkLq1AZ3sagceRM9WkMHYgcvQqyNLM2vEJXnBpaJEmMMh+m0aPKXQNMzy LBrTXAW2Tfs3Y7gC3A2/aqqn9gJwl4A5wKkbquss8FWrLQcKOW1zShFtxT96Qy0UMk35osiE dMwM2PgteK5k+8AdKJuz/HIpMuahNGra6dwaiLkjjTbWprQp0bCeTWmjqLQvbVAf4WIxebem Q/sCu/ObVHT6xg7LaX+W66+0PX3YspS5fZXVUuJoznoSEdbo+9/KkxjCO2k7CW/OZFSBELb8 wNb/cT7IQL7I9VgFZnFvpOXvUZslKnb4vFD2JD9UxkaUXVZGaxWpqlthCwpaLQTM3i+XfXzM bV/Y2M1wMBZ5ZI82KLvHtyiijA6DqgJ8XoY/clPb6XF/fCw3Faa8P0pn4gzJyWWk3yo4v6l9 sPebWoP4xveUzsptKNS8fyPPkuJEJW57P/rUlTUpSo40BwI3RZU0KmdPlYJm91RRazVPjiux 3B9ozwhjC4TSM1MCJRVvY4IU5XnxZZ4JMtqTjcpmKeukjY3Sd/ZqKxX1Ud268kBgofGf3+H+ nnBVwPrj8adBis6WAHscQVhmNOy2EpQ0fAXINQrZbRSF7K5veUN2xR7NEEpY547RpaEIp83W aiZ7srH6ovhAtjC418Cy9FV6aoXd131IHVaY3F8szDdvLEmD07PmZeU6szKAk0XJYXOzct3H ynV5TadebfGvMC4u/sXjnALskQoDjfygAfzIgbUaLI/GXLOo97k3AJV8mP6wCO65hjQYDWYL gHaDPD9ecOk0mmfAoKNOZpdpb2ZwdBlTEYXQXhArj+qBsPYuQdvKmfk4stDPgX16cz+7Gn8J cE8Vgi8wj+lkMp7MCSsOSzT2LoZhgbUEd+p0Xtj+l3lHPr2iV3kP01n4Swnn1E8Koct1FHq0 kA50HGagLO9hDlL+ek4nouzTc4htNOo53WqP4gIuxYKekzVdzISevOHmZGe+2jCrlZgYMpRb 8S8GBa8oAIYxIJLd7bNtRiLKcxhcwYNEjUdd/bXvM1vSZDmafb1LA/hDYQZBUdf0KAsVwcHp r/teFgX+QhfgrDxLRzeeDkqtpEbjKpjv7gZBjWnAgZWVNIBQoLTjxfjNDsayLWAboe/Os2Kx 7J+Wo/s4uoyj1FilkvNWQ228W6egr00dOU6Gu8aGDN3ajJPVxrqIJnezlTdeWIs2vxeBdsOH Y9WVCDDzHjQ5+9K0M5o4ckn5UQ/YwbKewQIrJZwSM3+bm5sLyMHhuPvk3hJOvoD4Mnpk0UwL fE2FXxpUmKtSU2HIWGN3V1qDoj5KOIR87QSuLOTYlmcmGoaU3G/tn+VJSVR8s/Ojwz4WkJLM sMcWkzigASY0Bphe6eldfe5OvpT7zOmZziZp77Y7vi+1ApvNB2GilUkfBgt5urTc9Sa92zAG U/sc4WpMlgYo3Kxb7l41Oe+gyBpK+VfJe4vMYhA9AwUgtvFZzUJRLzaIMRWhhBmz4YIUi6pN UxdZjq7i6DaO7h5KdmUmXZP1rWVXWUU7Jbu2dw6inXz51e258VlSfjW+yy/7+TeUX8ti/Z3i KpGnXMTOJTEKaaIxkdkLZe0xF4oT2O50GrxSKk18//72ftg9O23hZqm2nK97d6KslbGe4cuI vqy0Me49mFDECkzL7nO4f3oGIuB0f7cZ0d/tk+M3h82j0x8yTeEJEUQ4GLTDBrHAkduKEaL0 T5iwNKSsycnq6+RR+INTBDMincVVWaRmeF4WmUtkjpNIqTPmcpeNi89vuTIs/Ibh3p39yhZ7 RBBYEEc830G/AWigFREBwq2H2NpjNVRIzLaL2AxzPFeNdX0lzBKU33M1s6HsfCN7Udhw+86U 7LHvGhsetXBjdREqBArzVm+IOocMTia6X3DDI/I5l+N30McDDdzwuBzCNzy29mx4hcRs+ygb 3iQov+e/ZsMrXmdHnYPCtGsKFf9dc/vk7E1zO9eUpVyeVgdSw1/PaviPehOcQ5eyzAQBr5Wg J98oUFkVW8gmkJk183qWN3NCW3MTub7P3DeYue03xye5e40CAQwcbukbe8aCp4vQfp+uwifv ymPwTjc25+XH6u6xxFgPp+/en+3iuztzloQMv/B1jVltj2hgUVXit3yiI9wUly2DbDGiQKKZ sShZZnjIegRmrLu+TpMZYmzNk5Pjk7xBUXSMAW0P6tW3trU+in2k37ufpnNbR/4tBI1mgdHY LcJgjLLyvYnWWZe6qa7X/z2AA+8UmpUVrhYGkOeG4aKkLx/ihlHm/vOQ9VddMNbdC4bBeg0s ytsSWfgK5wqCRYwF13B5siY9zk43EMyz1W3wufa6QvEQmx3ZZzR2DKmGT2+92KUnTpmd4+OD /WbU3Hl3nHfWGNGURpdGtn7Gb/L9RuA+Dyj57YkrUHx0DCt/6cybG1Dy+FqPqfK4Ch2+IP6w edbM1ep0oKtvcK6JIXhwBt6HHmJOBy71C94N3jZbzZP9HeabetccHIuCh2aYruzZPEryug6Y dbU/+zejT0oRLCF9M6RVwS51pT13Xbq5lXg32ovtnM3J5ceU6MYAS8cHc/P/UEsBAhQAFAAC AAgAsJ0SL2dRYaJ3VgAAD6wBABQAAAAAAAAAAAAgAAAAAAAAAEZOMzItVENQLVJUUC1TQ1RQ LlBMUEsFBgAAAAABAAEAQgAAAKlWAAAAAA== --------------090509060209000005090609-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Wed Aug 20 04:54:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29804 for ; Wed, 20 Aug 2003 04:54: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 19pOjE-0001zB-Jn for rohc-archive@odin.ietf.org; Wed, 20 Aug 2003 04:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K8s454007628 for rohc-archive@odin.ietf.org; Wed, 20 Aug 2003 04: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 19pOjE-0001yw-Ea for rohc-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 04: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 EAA29781 for ; Wed, 20 Aug 2003 04:53:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pOjB-0006Ft-00 for rohc-web-archive@ietf.org; Wed, 20 Aug 2003 04:54:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pOjA-0006Fl-00 for rohc-web-archive@ietf.org; Wed, 20 Aug 2003 04: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 19pOjA-0001yS-UR; Wed, 20 Aug 2003 04: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 19pOj7-0001y5-6F for rohc@optimus.ietf.org; Wed, 20 Aug 2003 04:53:57 -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 EAA29772 for ; Wed, 20 Aug 2003 04:53:50 -0400 (EDT) From: goy@research.nera.no Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pOj4-0006Fh-00 for rohc@ietf.org; Wed, 20 Aug 2003 04:53:54 -0400 Received: from [195.204.181.165] (helo=notesmta2.nera.no) by ietf-mx with esmtp (Exim 4.12) id 19pOj2-0006Fe-00 for rohc@ietf.org; Wed, 20 Aug 2003 04:53:53 -0400 To: rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 20 Aug 2003 10:53:50 +0200 X-MIMETrack: Serialize by Router on NOTESMTA2/NORWAY/NERA(Release 5.0.11 |July 24, 2002) at 2003-08-20 10:52:25 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [rohc] ROHC efficiency 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 Dear colleagues I'm study the use of ROHC with RTP/UDP/IP traffic over a satelite link.= Therefor I would be intersted in the ROHC compression efficiensy when t= here a PER of 10^-3 - 10^-6 on the link. Also which effect does this have on the traffic after the decompressor?= If anyone have an oppineon on these problems I would be very glad to kn= ow. Sincerly Geir =C5ge =D8ye Nera Research Research Scientist Phd Applied Mathemathics Phone +47 55225559 Fax +47 55225299 goy@research.nera.no = _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Aug 22 13:36:50 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 NAA09126 for ; Fri, 22 Aug 2003 13:36:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpn-0005WK-H0 for rohc-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MHaNbW021210 for rohc-archive@odin.ietf.org; Fri, 22 Aug 2003 13:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpm-0005SU-Ix for rohc-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 13:36: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 NAA08925 for ; Fri, 22 Aug 2003 13:36:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qFpj-0007LA-00 for rohc-web-archive@ietf.org; Fri, 22 Aug 2003 13:36:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qFpi-0007L4-00 for rohc-web-archive@ietf.org; Fri, 22 Aug 2003 13:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFpi-0005PW-8o; Fri, 22 Aug 2003 13:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qFJg-00046w-2n for rohc@optimus.ietf.org; Fri, 22 Aug 2003 13:03: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 NAA07298 for ; Fri, 22 Aug 2003 13:03:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qFJe-0006zc-00 for rohc@ietf.org; Fri, 22 Aug 2003 13:03:10 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19qFJc-0006z8-00 for rohc@ietf.org; Fri, 22 Aug 2003 13:03:09 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id 5854E63649; Sat, 23 Aug 2003 02:32:33 +0930 (CST) Date: Sat, 23 Aug 2003 02:32:32 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030823023232.A14973@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] ROHC implementer's guide - error in mode transition diagram? 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 an error in the mode transition diagram for transitions to U-mode in the ROHC Implementer's Guide, version 3. Is this true? The diagram on page 5 (part 3.3) shows no change of mode to mode U in the decompressor even though an IR/IR-DYN/UOR-2(SN,U) packet is received. Surely it is more sensible for the decompressor to change to U mode if the compressor has made the transition to U mode. In a sense, this could be a metaphysical question, since the compressor should keep sending mode-independent packets until it receives U-mode ACKs from the decompressor. But then why is the corresponding mode change made for the O->R, U->R and R->O diagrams in RFC 3095? Question 2: Suppose the decompressor initiates the mode transition U -> O when the feedback link is down or non-existent. Then the compressor is stuck in U mode forever and the decompressor is stuck in O mode forever. Is this true? Since D_TRANS is not changed in this transition, the decompressor will not be aware of the fact that the compressor has not changed mode. So maybe the decompressor will be free to initiate the change O -> R? Question 3: Suppose the decompressor initiate the mode transition U -> R when the feedback link is down or non-existent. Then the decompressor will stay in D_TRANS = I forever. Is this true? CHeers, Alan Kennington. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Aug 25 05:01: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 FAA04632 for ; Mon, 25 Aug 2003 05:01: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 19rDDo-0006OT-5Q for rohc-archive@odin.ietf.org; Mon, 25 Aug 2003 05:01:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P918hJ024570 for rohc-archive@odin.ietf.org; Mon, 25 Aug 2003 05:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDDn-0006OD-UA for rohc-web-archive@optimus.ietf.org; Mon, 25 Aug 2003 05:01: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 FAA04601 for ; Mon, 25 Aug 2003 05:01:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rDDk-0005Ob-00 for rohc-web-archive@ietf.org; Mon, 25 Aug 2003 05:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rDDj-0005OX-00 for rohc-web-archive@ietf.org; Mon, 25 Aug 2003 05:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDDi-0006Nn-AL; Mon, 25 Aug 2003 05:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l72m-0003vi-Kq for rohc@optimus.ietf.org; Fri, 08 Aug 2003 09:12:32 -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 JAA09835 for ; Fri, 8 Aug 2003 09:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l72l-0000Wy-00 for rohc@ietf.org; Fri, 08 Aug 2003 09:12:31 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19l72k-0000Wp-00 for rohc@ietf.org; Fri, 08 Aug 2003 09:12:30 -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 h78DBuU13482 for ; Fri, 8 Aug 2003 08:11:56 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Aug 2003 15:11:54 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155022579AA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: =?iso-8859-1?Q?J=FCrgen_Quittek?= , "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: Fri, 8 Aug 2003 15:11:02 +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: , When I see things like: added to description: "Note that compliance with this compliance statement requires compliance with the rohcCompliance MODULE-COMPLIANCE statement of the ROHC-MIB and with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]." I'd say that instead of [RFC2863], it would probably be better to use (RFC 2863). The reason is that when the MIB module gets extracted from the RFC, then the citation is lost, and besides, (RFC 2863) seems to me to be a clearly enoug ptr to the document. Thanks, Bert _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Aug 25 05:29:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06016 for ; Mon, 25 Aug 2003 05:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDep-0007YV-Ij for rohc-archive@odin.ietf.org; Mon, 25 Aug 2003 05:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P9T3c9029037 for rohc-archive@odin.ietf.org; Mon, 25 Aug 2003 05:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDep-0007YG-EJ for rohc-web-archive@optimus.ietf.org; Mon, 25 Aug 2003 05:29: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 FAA05948 for ; Mon, 25 Aug 2003 05:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rDel-0005yB-00 for rohc-web-archive@ietf.org; Mon, 25 Aug 2003 05:29:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rDek-0005y4-00 for rohc-web-archive@ietf.org; Mon, 25 Aug 2003 05:28:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDem-0007XK-Cp; Mon, 25 Aug 2003 05:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pG9S-0001OP-TH for rohc@optimus.ietf.org; Tue, 19 Aug 2003 19:44: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 TAA15930 for ; Tue, 19 Aug 2003 19:44:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pG9R-0001eS-00 for rohc@ietf.org; Tue, 19 Aug 2003 19:44:33 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19pG9Q-0001eN-00 for rohc@ietf.org; Tue, 19 Aug 2003 19:44:32 -0400 Message-ID: <02f601c366ab$db9cc130$0a6015ac@dclkempt40> From: "James Kempf" To: Date: Tue, 19 Aug 2003 16:44:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] Incompatibility between Header Compression and Context Transfer 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 In Vienna, someone in the Seamoby meeting mentioned that there are three header compression schemes, and only one of them is compatible with context transfer. I'm trying to sort out what to do about context transfer for header compression in Seamoby. Could someone point out a document that describes the problem? Or, if that's not possible, summarize in a paragraph or two? I'm not on the ROHC list, so please send it to me privately. Thanx. jak _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Mon Aug 25 05:29:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06018 for ; Mon, 25 Aug 2003 05:29:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDep-0007Yl-Pz for rohc-archive@odin.ietf.org; Mon, 25 Aug 2003 05:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P9T3oV029053 for rohc-archive@odin.ietf.org; Mon, 25 Aug 2003 05:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDep-0007YW-Ma for rohc-web-archive@optimus.ietf.org; Mon, 25 Aug 2003 05:29: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 FAA05947 for ; Mon, 25 Aug 2003 05:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rDel-0005yE-00 for rohc-web-archive@ietf.org; Mon, 25 Aug 2003 05:29:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rDek-0005y5-00 for rohc-web-archive@ietf.org; Mon, 25 Aug 2003 05:28:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDem-0007XW-Lt; Mon, 25 Aug 2003 05:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qwH6-0003vw-NN for rohc@optimus.ietf.org; Sun, 24 Aug 2003 10:55: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 KAA09085 for ; Sun, 24 Aug 2003 10:55:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qwH4-0007Iw-00 for rohc@ietf.org; Sun, 24 Aug 2003 10:55:22 -0400 Received: from mailgw3.technion.ac.il ([132.68.238.36]) by ietf-mx with esmtp (Exim 4.12) id 19qwH3-0007It-00 for rohc@ietf.org; Sun, 24 Aug 2003 10:55:21 -0400 Received: from localhost (debian [127.0.0.1]) by mailgw3.technion.ac.il (Postfix) with ESMTP id D97461676DD for ; Sun, 24 Aug 2003 17:55:19 +0300 (IDT) Received: from mailgw3.technion.ac.il ([127.0.0.1]) by localhost (mailgw3.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07567-01-73 for ; Sun, 24 Aug 2003 17:55:19 +0300 (IDT) Received: from techst02.technion.ac.il (techst02.technion.ac.il [132.68.0.22]) by mailgw3.technion.ac.il (Postfix) with ESMTP id 7895E1676B3 for ; Sun, 24 Aug 2003 17:55:19 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by techst02.technion.ac.il (Postfix) with ESMTP id 80F6C14C94 for ; Sun, 24 Aug 2003 17:55:17 +0300 (IDT) Received: from techst02.technion.ac.il ([127.0.0.1]) by localhost (techst02.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16366-01-33 for ; Sun, 24 Aug 2003 17:54:56 +0300 (IDT) Received: by techst02.technion.ac.il (Postfix, from userid 25265) id 56BD214D2E; Sun, 24 Aug 2003 17:54:56 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by techst02.technion.ac.il (Postfix) with ESMTP id 48E2B11DBC for ; Sun, 24 Aug 2003 17:54:54 +0300 (IDT) Date: Sun, 24 Aug 2003 17:54:50 +0300 (IDT) From: Rozental Valentin To: rohc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il X-Virus-Scanned: by amavisd-new at technion.ac.il Subject: [rohc] ROHC perormance info 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! I'd like to get statistical information about ROHC, such as: 1. Average and variance of the header compression ratio. 2. Average and variance of the overhead time(header compression time) 3. method prevalence in current(future) systems. I'll be glad to get any information! Thank you in advance! Regards, Valentin Rozental. About me: I'm a student of Computer Science Department of the Technion(IIT - Israel Institute of Technology). I take a part in a student project "Cellular network simulator"(which is dealing with analyzing of resource distribution and its management). We want to include "TCP/IP header compression" feature into our simulator. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Tue Aug 26 15:06:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23791 for ; Tue, 26 Aug 2003 15:06:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj8e-0006Nf-OL for rohc-archive@odin.ietf.org; Tue, 26 Aug 2003 15:05:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QJ5uGM024526 for rohc-archive@odin.ietf.org; Tue, 26 Aug 2003 15:05:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj8e-0006NV-KG for rohc-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 15:05: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 PAA23580 for ; Tue, 26 Aug 2003 15:05:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rj87-0006G5-Sp; Tue, 26 Aug 2003 15:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rPgv-0003LH-SL for rohc@optimus.ietf.org; Mon, 25 Aug 2003 18:20: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 SAA20281 for ; Mon, 25 Aug 2003 18:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rPgs-0000LA-00 for rohc@ietf.org; Mon, 25 Aug 2003 18:19:58 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19rPgs-0000L7-00 for rohc@ietf.org; Mon, 25 Aug 2003 18:19:58 -0400 Received: by EXCHSVR with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Aug 2003 18:17:18 -0400 Message-ID: From: Remi Pelland To: "'rohc@ietf.org'" Date: Mon, 25 Aug 2003 18:17:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Empty CSRC list issue in IR packet. 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, A couple of weeks ago, there was a discussion about a section in the latest implementer's guide that corrects RFC 3095 with regards to the handling of empty CSRC lists: section 5.7.7.6 of the RFC says that an empty generic list is inserted, while section 4.3.3. of the implementer's guide modifies the RFC by saying that no generic list should be present. There seemed to be a concensus among those involved in the discussion to follow the RFC since this is how interoperability was tested. That's fine and I do not want to restart the discussion on this. Now, it has been a couple of weeks and there hasn't been any final conclusion on this issue (i.e. officially stating that the RFC method should be used, anouncing the associated correction to the implementer's guide, etc...). Based on the concensus that existed, I don't think there's a problem for those who currently receive mailing list messages. However, it seems to me like there's a risk that future implementations may use either methods, leading to interoperability problems. Thanks, Remi. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Thu Aug 28 02:28: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 CAA06811 for ; Thu, 28 Aug 2003 02:28: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 19sDnH-0008AB-B6 for rohc-archive@odin.ietf.org; Wed, 27 Aug 2003 23:49:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3ntcB031375 for rohc-archive@odin.ietf.org; Wed, 27 Aug 2003 23:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAnU-00028M-8L for rohc-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 20:37:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23122 for ; Wed, 27 Aug 2003 20:37:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sAnR-0004Bb-00 for rohc-web-archive@ietf.org; Wed, 27 Aug 2003 20:37:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sAnQ-0004BV-00 for rohc-web-archive@ietf.org; Wed, 27 Aug 2003 20:37:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Qp-0002aD-C7; Wed, 27 Aug 2003 14:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s20g-00078f-2y for rohc@optimus.ietf.org; Wed, 27 Aug 2003 11:14:58 -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 LAA07046 for ; Wed, 27 Aug 2003 11:14:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s20f-0000UJ-00 for rohc@ietf.org; Wed, 27 Aug 2003 11:14:57 -0400 Received: from exchsvr.octasic.com ([216.208.79.4]) by ietf-mx with esmtp (Exim 4.12) id 19s20e-0000U9-00 for rohc@ietf.org; Wed, 27 Aug 2003 11:14:56 -0400 Received: by EXCHSVR with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 11:12:19 -0400 Message-ID: From: Remi Pelland To: "'Ghyslain Pelletier'" Cc: "'rohc@ietf.org'" Subject: RE: [rohc] Empty CSRC list issue in IR packet. Date: Wed, 27 Aug 2003 11:12:12 -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 Ghyslain, Your understanding is correct. As for removing section 4.3.3, I think it would be usefull to leave the portion that proposes a behavior when the CC field in the dynamic part = of the RTP context and the CC field in the CSRC list do not match. Thanks, Remi. -----Original Message----- From: Ghyslain Pelletier [mailto:Ghyslain.Pelletier@ericsson.com] Sent: Wednesday, August 27, 2003 10:06 AM To: Remi Pelland Cc: 'rohc@ietf.org' Subject: Re: [rohc] Empty CSRC list issue in IR packet. Hi all, Does the following summarizes accurately the consensus that Remi is looking after? 1) Section 4.3.1 and 4.3.2 of the implementer's guide clarifies rfc3095, and they should remain as they are. =20 The text is clear, bring a clarification inline with the standard, and this has been interop tested. These two sections therefore do not need to be modified. In summary, when an empty CSRC list is present, an empty generic list (1-2 octets) must be inserted. Tommy's mail would then represent the consensus on this: =20 http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01654.h= tml 2) Section 4.3.3 of the implementer's guide should be removed. Section 4.3.3 of the implementer's guide is a "deviation" from the standard that proposes an improvement that would remove the need to send an empty generic list (1-2 octets) in the presence of an empty CSRC list. It is a deviation in the sense that the generic CSRC list in rfc3095 is of variable lenght but is not optional (must be present), while the text in 4.3.3 is keeping it of variable length but makes it optional. Section 4.3.3 should thus be removed from the implementer's guide, but could later be considered as a proposed improvement when bringing rfc3095 to draft standard if the profile gets updated at the same time. Abigail's mail would then represent the consensus on this: =20 http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01655.h= tml Is my understanding of the conclusions/consensus correct? If so, then we will update the Implementer's guide accordingly. /Ghyslain --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. Remi Pelland wrote: >=20 > Hi, >=20 > A couple of weeks ago, there was a discussion about a section in the latest > implementer's guide that corrects RFC 3095 with regards to the = handling of > empty CSRC lists: section 5.7.7.6 of the RFC says that an empty = generic list > is inserted, while section 4.3.3. of the implementer's guide modifies = the > RFC by saying that no generic list should be present. >=20 > There seemed to be a concensus among those involved in the discussion = to > follow the RFC since this is how interoperability was tested. That's = fine > and I do not want to restart the discussion on this. >=20 > Now, it has been a couple of weeks and there hasn't been any final > conclusion on this issue (i.e. officially stating that the RFC method should > be used, anouncing the associated correction to the implementer's = guide, > etc...). >=20 > Based on the concensus that existed, I don't think there's a problem = for > those who currently receive mailing list messages. However, it seems = to me > like there's a risk that future implementations may use either = methods, > leading to interoperability problems. >=20 > Thanks, > Remi. >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Aug 29 07:30:11 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 HAA12987 for ; Fri, 29 Aug 2003 07:30: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 19sfxm-00051w-Ug for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 05:54:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T9sc6i019327 for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 05:54:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sfa8-0003V4-Jg for rohc-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 05:30: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 FAA02915 for ; Fri, 29 Aug 2003 05:30:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sfa4-00067f-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 05:30:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sfa4-00067c-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 05:30:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sfPI-0002z5-RS; Fri, 29 Aug 2003 05:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s0u0-0004gg-8C for rohc@optimus.ietf.org; Wed, 27 Aug 2003 10:04: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 KAA28484 for ; Wed, 27 Aug 2003 10:03:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0tx-0006KH-00 for rohc@ietf.org; Wed, 27 Aug 2003 10:03:58 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19s0tx-0006KE-00 for rohc@ietf.org; Wed, 27 Aug 2003 10:03:57 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7RE3s31020659; Wed, 27 Aug 2003 16:03:55 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Q9L3DB48; Wed, 27 Aug 2003 16:03:54 +0200 Received: by lms001.lu.erisoft.se id QAA08685; Wed, 27 Aug 2003 16:03:55 +0200 (MET DST) Message-ID: <3F4CBAC0.443A0D0B@ericsson.com> Date: Wed, 27 Aug 2003 16:05:52 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Remi Pelland CC: "'rohc@ietf.org'" Subject: Re: [rohc] Empty CSRC list issue in IR packet. References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin-ext.wise.edt.ericsson.se id h7RE3s31020659 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 all, Does the following summarizes accurately the consensus that Remi is looking after? 1) Section 4.3.1 and 4.3.2 of the implementer's guide clarifies rfc3095, and they should remain as they are. =20 The text is clear, bring a clarification inline with the standard, and this has been interop tested. These two sections therefore do not need to be modified. In summary, when an empty CSRC list is present, an empty generic list (1-2 octets) must be inserted. Tommy's mail would then represent the consensus on this: =20 http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01654.ht= ml 2) Section 4.3.3 of the implementer's guide should be removed. Section 4.3.3 of the implementer's guide is a "deviation" from the standard that proposes an improvement that would remove the need to send an empty generic list (1-2 octets) in the presence of an empty CSRC list. It is a deviation in the sense that the generic CSRC list in rfc3095 is of variable lenght but is not optional (must be present), while the text in 4.3.3 is keeping it of variable length but makes it optional. Section 4.3.3 should thus be removed from the implementer's guide, but could later be considered as a proposed improvement when bringing rfc3095 to draft standard if the profile gets updated at the same time. Abigail's mail would then represent the consensus on this: =20 http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01655.ht= ml Is my understanding of the conclusions/consensus correct? If so, then we will update the Implementer's guide accordingly. /Ghyslain --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. Remi Pelland wrote: >=20 > Hi, >=20 > A couple of weeks ago, there was a discussion about a section in the la= test > implementer's guide that corrects RFC 3095 with regards to the handling= of > empty CSRC lists: section 5.7.7.6 of the RFC says that an empty generic= list > is inserted, while section 4.3.3. of the implementer's guide modifies t= he > RFC by saying that no generic list should be present. >=20 > There seemed to be a concensus among those involved in the discussion t= o > follow the RFC since this is how interoperability was tested. That's f= ine > and I do not want to restart the discussion on this. >=20 > Now, it has been a couple of weeks and there hasn't been any final > conclusion on this issue (i.e. officially stating that the RFC method s= hould > be used, anouncing the associated correction to the implementer's guide= , > etc...). >=20 > Based on the concensus that existed, I don't think there's a problem fo= r > those who currently receive mailing list messages. However, it seems t= o me > like there's a risk that future implementations may use either methods, > leading to interoperability problems. >=20 > Thanks, > Remi. >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Aug 29 07:55:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15051 for ; Fri, 29 Aug 2003 07:55:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgJQ-0006fH-5N for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 06:17:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TAGww2025600 for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 06:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sfUL-0003Bj-MX for rohc-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 05: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 FAA02310 for ; Fri, 29 Aug 2003 05:24:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sfUI-0005vj-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 05:24:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sfUH-0005vf-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 05:24:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sfPJ-0002zN-V1; Fri, 29 Aug 2003 05:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2Pj-0007wT-Kd for rohc@optimus.ietf.org; Wed, 27 Aug 2003 11:40:52 -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 LAA10192 for ; Wed, 27 Aug 2003 11:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2Pi-0001IC-00 for rohc@ietf.org; Wed, 27 Aug 2003 11:40:50 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19s2Ph-0001I9-00 for rohc@ietf.org; Wed, 27 Aug 2003 11:40:49 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7RFel31010528; Wed, 27 Aug 2003 17:40:47 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QXY5YM8F; Wed, 27 Aug 2003 17:40:46 +0200 Received: by lms001.lu.erisoft.se id RAA10309; Wed, 27 Aug 2003 17:40:48 +0200 (MET DST) Message-ID: <3F4CD175.9A035A92@ericsson.com> Date: Wed, 27 Aug 2003 17:42:45 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Remi Pelland CC: "'rohc@ietf.org'" Subject: Re: [rohc] Empty CSRC list issue in IR packet. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Absolutely - sorry about that. Only the text from "It should be noted ..." up to "... present if CC > 0"." should be removed in 4.3.3. I was a bit to fast taking the entire stuff out. Thanks. /Ghyslain Remi Pelland wrote: > > Hi Ghyslain, > > Your understanding is correct. > > As for removing section 4.3.3, I think it would be usefull to leave the > portion that proposes a behavior when the CC field in the dynamic part of > the RTP context and the CC field in the CSRC list do not match. > > Thanks, > Remi. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Aug 29 09:16: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 JAA21536 for ; Fri, 29 Aug 2003 09:16: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 19shql-0003Da-SH for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 07:55:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TBtUHp012352 for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 07:55:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgON-0006wm-1b for rohc-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 06:22: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 GAA07909 for ; Fri, 29 Aug 2003 06:21:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sgOI-0007TH-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 06:22:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sgOH-0007TE-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 06:22:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sfPJ-0002zD-EZ; Fri, 29 Aug 2003 05:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2EC-0007SK-OY for rohc@optimus.ietf.org; Wed, 27 Aug 2003 11:28:57 -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 LAA08965 for ; Wed, 27 Aug 2003 11:28:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2EB-00012T-00 for rohc@ietf.org; Wed, 27 Aug 2003 11:28:55 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19s2EA-00012Q-00 for rohc@ietf.org; Wed, 27 Aug 2003 11:28:55 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7RFSrAv017091; Wed, 27 Aug 2003 17:28:53 +0200 (MEST) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QXZA0FMA; Wed, 27 Aug 2003 17:29:38 +0200 Received: by lms001.lu.erisoft.se id RAA10088; Wed, 27 Aug 2003 17:28:54 +0200 (MET DST) Message-ID: <3F4CCEAA.47CACFAD@ericsson.com> Date: Wed, 27 Aug 2003 17:30:50 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "rohc@ietf.org" CC: kristofer.sandlund@effnet.com, Ghyslain Pelletier Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross-ext.wise.edt.ericsson.se id h7RFSrAv017091 Content-Transfer-Encoding: quoted-printable Subject: [rohc] Compressed lists in UO-1-ID packets 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 all, I have received two comments from Kristofer regarding the implementer's guide, section 4.3.4 - "CSRC lists in UO-1-ID packets": 1) Section 4.3.4 state that even if UO-1-ID packets are not context updating, when carrying a CSRC list the translation table should be updated anyway. The comment is that this should apply to extension headers compressed using list compression as well. We note here that (RFC3095 section 5.8.6) the format is the same for CSRC lists and header lists, so this seems a correct observation to me. Thus it seems that the text in the implementer's guide should be rephrased so that it applies to the type of encoding, not the type of list, e.g. something like "Compressed list in UO-1-ID packets" instead of "CSRC lists in UO-1-ID packets" plus other rephrasing as needed in the section. 2) In rfc3095, regarding the context updating properties of UO-1*: the text in section 5.7.3 states: "Values provided in extensions, except those in other SN, TS, or IP-ID fields, do not update the context". =20 Quoting the comment: > For example with AH-SN, if > > - no compressed list is sent in an extension 3 and > - the AH-SN field is not present > > then the AH-SN is assumed to be incremented by: > "delta_(RTP)SN * normal-AH-SN-delta". > > Therefore such "other" sequence number will be fully dependent > on the RTP SN (for the RTP profile) when the AH-SN is not being > sent. > > If the table value for this sequence number is not updated while > the RTP SN is updated in the context, it will be necessary to > either: > > a) a mapping will have to be saved for that RTP SN from which this > AH-SN was derived from, so that the delta can be applied from > this SN instead of from the one that will be calculated for > the next packet. > > b) send at least the LSBs of the AH-SN in the next packet, since > applying delta_sn from the updated RTP SN will not produce the > correct result for AH-SN. This seems to be a waste of > compression efficiency. It thus seems pointless to not update the other sequence number when updating the "master SN" that it is depending upon. As the fields SN, TS and IP-ID refer to (and only to) the fields as defined at the beginning of section 5.7, a clarification seems to be needed along the following lines: "The only values provided in extensions that upate the context are the additional bits for the SN, TS, or IP-ID fields and the sequence number fields of extension headers. Other values provided in extensions do not update the context." Are these proper clarifications to bring into the implementer's guide? /Ghyslain --=20 Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegr=E4nd 11 Box 920, S-97128 Lule=E5, SWEDEN Phone : +46 (0) 920 20 24 32=20 Mobile: +46 (0) 706 09 27 73 Ghyslain.Pelletier@ericsson.com http://www.ericsson.com I have a new mail address: Ghyslain.Pelletier@ericsson.com My old e-mail address will function until 2004-06-01. Please change my address in your personal address book. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Aug 29 11:04:57 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 LAA01144 for ; Fri, 29 Aug 2003 11:04:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skH7-0002rl-KX for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 10:30:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TEUq1e011012 for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 10:30:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sjay-0000G8-C0 for rohc-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 09:47: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 JAA23776 for ; Fri, 29 Aug 2003 09:47:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sjav-0003Jf-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 09:47:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sjav-0003Jc-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 09:47:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sitm-0006O1-PV; Fri, 29 Aug 2003 09:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19shJ0-00014Z-Uz for rohc@optimus.ietf.org; Fri, 29 Aug 2003 07:20: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 HAA12274 for ; Fri, 29 Aug 2003 07:20:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19shJ0-0000dK-00 for rohc@ietf.org; Fri, 29 Aug 2003 07:20:38 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19shIz-0000dH-00 for rohc@ietf.org; Fri, 29 Aug 2003 07:20:37 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7TBKYAv000351; Fri, 29 Aug 2003 13:20:35 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 29 Aug 2003 13:20:33 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "Ghyslain Pelletier (LU/EAB)" , Remi Pelland Cc: "'rohc@ietf.org'" Subject: RE: [rohc] Empty CSRC list issue in IR packet. Date: Fri, 29 Aug 2003 13:20:15 +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: , > 2) Section 4.3.3 of the implementer's guide should be removed. I do not agree, as we have already agreed on this interpretation of 3095. Personally, I would not be sure about the interpretation from 3095 only, so the implementer's guide should make this clear. Therefore, we agreed on the obvious interpretation, as currently stated in 4.3.3. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Fri Aug 29 11:28:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02805 for ; Fri, 29 Aug 2003 11:28:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skoP-0004GS-W9 for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 11:05:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TF5Gq4016380 for rohc-archive@odin.ietf.org; Fri, 29 Aug 2003 11:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19skDT-0002eA-0h for rohc-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 10:27: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 KAA28475 for ; Fri, 29 Aug 2003 10:26:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19skDQ-0004eh-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 10:27:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19skDQ-0004ee-00 for rohc-web-archive@ietf.org; Fri, 29 Aug 2003 10:27:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sjbk-0000LF-5s; Fri, 29 Aug 2003 09:48:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19shMq-0001Gy-Hu for rohc@optimus.ietf.org; Fri, 29 Aug 2003 07:24: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 HAA12608 for ; Fri, 29 Aug 2003 07:24:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19shMp-0000i8-00 for rohc@ietf.org; Fri, 29 Aug 2003 07:24:35 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19shMo-0000i4-00 for rohc@ietf.org; Fri, 29 Aug 2003 07:24:35 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7TBOXAv001419 for ; Fri, 29 Aug 2003 13:24:33 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 29 Aug 2003 13:24:32 +0200 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'rohc@ietf.org'" Date: Fri, 29 Aug 2003 13:24:16 +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 Subject: [rohc] Chair is back (working 2 hours a day) 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 all, After almost 3 months, I am now back at work 2 hours per day. I will thus be able to follow discussions and do some chair work, but do not expect too much at this point. Hopefully I will get better with time and be able to work more. Cheers, /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated.=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From exim@www1.ietf.org Sat Aug 30 11:37: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 LAA18632 for ; Sat, 30 Aug 2003 11:37:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t7O7-0001yZ-Lt for rohc-archive@odin.ietf.org; Sat, 30 Aug 2003 11:11:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7UFBdgn007589 for rohc-archive@odin.ietf.org; Sat, 30 Aug 2003 11:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t6nJ-0007rA-0v for rohc-web-archive@optimus.ietf.org; Sat, 30 Aug 2003 10:33: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 KAA15324 for ; Sat, 30 Aug 2003 10:33:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t6nG-00064i-00 for rohc-web-archive@ietf.org; Sat, 30 Aug 2003 10:33:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19t6nF-00064e-00 for rohc-web-archive@ietf.org; Sat, 30 Aug 2003 10:33:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t63r-0006JL-Dr; Sat, 30 Aug 2003 09:46:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t3Pm-0000Hu-Nn for rohc@optimus.ietf.org; Sat, 30 Aug 2003 06:57: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 GAA06494 for ; Sat, 30 Aug 2003 06:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t3Pi-0000zK-00 for rohc@ietf.org; Sat, 30 Aug 2003 06:57:02 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19t3Pg-0000sP-00 for rohc@ietf.org; Sat, 30 Aug 2003 06:57:01 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id D5D0D51799; Sat, 30 Aug 2003 20:26:26 +0930 (CST) Date: Sat, 30 Aug 2003 20:26:26 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030830202626.A7779@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] query: encoding of IP-ID for RND=0 in extn3 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 am having some difficulty in interpreting RFC 3095, 5.7, page 75. ============================================================ IP-ID: A compressed IP-ID field. IP-ID fields in compressed base headers carry the compressed IP-ID of the innermost IPv4 header whose corresponding RND flag is not 1. The rules below assume that the IP-ID is for the innermost IP header. If it is for an outer IP header, the RND2 and NBO2 flags are used instead of RND and NBO. If value(RND) = 0, hdr(IP-ID) is compressed using Offset IP-ID encoding (see section 4.5.5) using p = 0 and default-slope(IP-ID offset) = 0. If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID is then passed as additional octets at the end of the compressed header, after any extensions. If value(NBO) = 0, the octets of hdr(IP-ID) are swapped before compression and after decompression. The value of NBO is ignored when value(RND) = 1. ============================================================= Suppose I have RND=0 and I send a UO-1-ID packet with extension 3. Suppose also that I include the 16-bit IP Identification field in the extension 3. This is in 5.7.5, p.85. Then the IP-ID field is clearly not compressed. But RND = 0. But sometimes the IP-ID field in the IP packets does not follow the established pattern. Therefore I may have to send all 16 bits even when RND = 0. The above rules tell me what happens when RND = 0 and the IP-ID is compressed. But here the IP-ID is _not_ compressed. Question: Now should I swap the bytes of IP-ID according to NBO? Should I subtract SN from the IP Identification field before I write it into the type 3 extension? I think that it is equally credible that the IP-ID is encoded (1) without SN offset and bytes swap (i.e. verbatim) or (2) with SN offset and bytes swap. Can anyone tell me what the majority view on this is? Cheers, Alan Kennington. PS. The ROHC implementer's guide, version 3, 4.8, page 7, says that the 16-bit IP Identification field in an IR/IR-DYN packet must be sent verbatim because it is called "Identification", not IP-ID. This tends to make me think that the extn 3 IP-ID _may_ be the swapped/offset version of IP-ID. But it is still unclear to me. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc