From rohc-bounces@ietf.org Fri Dec 01 02:44:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq33g-0007ne-RV; Fri, 01 Dec 2006 02:43:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq33f-0007nW-4T for rohc@ietf.org; Fri, 01 Dec 2006 02:43:43 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq33X-0000Qh-KV for rohc@ietf.org; Fri, 01 Dec 2006 02:43:43 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E98BF1014; Fri, 1 Dec 2006 08:43:32 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 08:43:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] question about rohc tcp profile Date: Fri, 1 Dec 2006 08:43:32 +0100 Message-ID: In-Reply-To: <20061130132905.48281.qmail@web27614.mail.ukl.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] question about rohc tcp profile Thread-Index: AccUg267SHdv+0pMT3W530fY6/QrmQAmF07A From: "Kristofer Sandlund \(LU/EAB\)" To: "ben ata ibtissem" , X-OriginalArrivalTime: 01 Dec 2006 07:43:32.0699 (UTC) FILETIME=[668AD2B0:01C7151C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, just adding some more information to what Mark has already said. If you're implementing ROHC-TCP, my most important advice would be: a) If you are starting from scratch: Immediately shred and delete all = copies of RFC3095 that you have lying around to confusing framework with = profiles. Implement the framework from the ROHC framework draft (see below) b) If you already have a RFC3095 implementation: Immediately shred and=20 delete all copies of RFC3095 that you have lying around to avoid = confusing=20 framework with profiles. Re-use the framework implementation as-is. So in either case, reading RFC3095 will only cause you grief (it already = has since you're asking about R-mode). ROHC-TCP does not have any = _normative_=20 reference to RFC3095 so there is no reason to read that one when = implementing=20 the ROHC-TCP profile.=20 The only documents you need to read are ROHC-TCP, ROHC-FN and ROHC = Framework: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-framework-= 04.txt http://tools.ietf.org/wg/rohc/draft-ietf-rohc-formal-notation/draft-ietf-= rohc-formal-notation-12.txt http://tools.ietf.org/wg/rohc/draft-ietf-rohc-tcp/draft-ietf-rohc-tcp-14.= txt Regarding uni/bi-directional operation of the ROHC-TCP profile, the = logic is=20 quite clearly stated in sections 4.2.2, 5.2.1, 5.2.1.2 and 5.3.2 of the = tcp-14=20 draft, so you should read those. BR, Kristofer ben ata ibtissem wrote on den 30 november = 2006 14:29 : > hello, > I implement the profile rohc tcp of rohc ,but i have > one probleme, in fact for rohc to transit from one > mode to an other i.e for example from unidirectionnel > mode to o mode or R mode, it use the feedbacks and > especially the field mode in witch the decompressor > indicate what mode he wish to use , but for the > feedbacks of tcp this field(mode field ) don't exist > so it can't transit from one mode to an other , to my > opinion since the tcp is usally bidirectionnel and all > is acquitted so the profile rohc tcp we allways be in > the R mode > the question is:is it, my opinion, true or not, and if > it is true , we wil have an other problem in fact rohc > always start in the Unidirectionnel mode so how can i > do i.e can i initialise the mode directly in the R > mode or i can't? > thank you >=20 >=20 >=20 >=20 >=20 >=20 > ______________________________________________________________ > _____________ Yahoo! Mail r=E9invente le mail ! D=E9couvrez le nouveau > Yahoo! Mail et son interface r=E9volutionnaire. > http://fr.mail.yahoo.com >=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 rohc-bounces@ietf.org Mon Dec 04 10:42:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFxD-0002RN-Ld; Mon, 04 Dec 2006 10:42:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFxB-0002Pn-Em for rohc@ietf.org; Mon, 04 Dec 2006 10:42:01 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrFx4-0006cA-Vn for rohc@ietf.org; Mon, 04 Dec 2006 10:42:01 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6B8C9518; Mon, 4 Dec 2006 16:41:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:41:36 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 16:30:25 +0100 Message-ID: <45743F11.2040603@ericsson.com> Date: Mon, 04 Dec 2006 16:30:25 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "West, Mark" , Adam Roach , "Surtees, Abigail" , rohc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Dec 2006 15:30:25.0706 (UTC) FILETIME=[1ED5B8A0:01C717B9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [rohc] AD evaluation of draft-ietf-rohc-sigcomp-impl-guide-08 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, In my review of the document I found a few issues that will require an update of the draft before progressing to IETF last call. 1. The fact that this document updates RFC 3320, RFC 3321 and RFC3485 needs to be included in both abstract and introduction. In addition it would be good if the first page header included: "Updates (if approved): RFC 3320, RFC 3321, RFC 3485" 2. Section 9.2: "200OK" I think should be changed to "200 OK" for better readability. In addition I think there is a need to explain that the 200 OK and INVITE talked about in the text is SIP request and responses. 3. This doesn't need to go into the document. But I need an answer to the question: Why didn't the ROHC WG update the three RFCs themselves rather then publishing a implementators guide? Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Dec 04 10:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGAW-0000zQ-DC; Mon, 04 Dec 2006 10:55:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGAV-0000wk-RY for rohc@ietf.org; Mon, 04 Dec 2006 10:55:47 -0500 Received: from web27609.mail.ukl.yahoo.com ([217.146.177.228]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrGAQ-0008HS-Fu for rohc@ietf.org; Mon, 04 Dec 2006 10:55:47 -0500 Received: (qmail 66568 invoked by uid 60001); 4 Dec 2006 15:55:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=xm1oPLULf5HnpNBh1yEGNOv6VRXWl28Yl/PNGGoDfTDdHdNNhzyRAWwYI5XWNG4WWzsgCHQO2Qa6qWKSc68qqybrmcLc9gItq6R3Q4t0BANBzHVF1iGT2YuVCrRfI13FZrtzaUm5EL20hgI3tEL7Wv/49MzITRwap1zQnJO1dtI=; X-YMail-OSG: bScu1pcVM1kH9Fd.LxIw0TDHASK48lerTDLSkxv2 Received: from [193.52.74.23] by web27609.mail.ukl.yahoo.com via HTTP; Mon, 04 Dec 2006 16:55:21 CET Date: Mon, 4 Dec 2006 16:55:21 +0100 (CET) From: ben ata ibtissem To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <580890.65925.qm@web27609.mail.ukl.yahoo.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [rohc] ROHC WINDOW X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org hello, firstly i would to say thank you for the members of the rohc mailing list whose respeond to my questions. Secondly, i implement the rohc tcp profile, i just want to know if it is necessarly to use the window to save for example some values of some fields, for example when a compressor receive a ACK with the option MSN not VALID from the decompressor he must know which packet has been acquitted by this ACK and he must use some information of older packets for these reasons i want to know if it is necessarly that the compressor use a window to save these older values. i hope that you will understand my question thank you ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Dec 04 23:40:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrS6p-000355-BS; Mon, 04 Dec 2006 23:40:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrS6n-000306-DJ for rohc@ietf.org; Mon, 04 Dec 2006 23:40:45 -0500 Received: from web7705.mail.in.yahoo.com ([202.86.4.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrS6k-000369-Lm for rohc@ietf.org; Mon, 04 Dec 2006 23:40:44 -0500 Received: (qmail 71096 invoked by uid 60001); 5 Dec 2006 04:40:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=FubxCT1a8Q6eAaXuC/MVI47bvJAvoj1XS9+VnnkfOSSbLtD1aZoU9gieqp/R+8K37q2Gv4w4JlGfRjoiQvMf1Rw9ED+Xu6nEzTCaCEt0VMKukMH/3wjT4wzUYRC0F4pcUhORxfGRKZwqSttZ18gIKEg3/1IET2MtIo8MvpmLew8= ; Message-ID: <20061205044033.71094.qmail@web7705.mail.in.yahoo.com> Received: from [61.12.13.194] by web7705.mail.in.yahoo.com via HTTP; Tue, 05 Dec 2006 10:10:33 IST Date: Tue, 5 Dec 2006 10:10:33 +0530 (IST) From: Sreenath S To: rohc@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [rohc] Query about SigComp Decompression. X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1219584356==" Errors-To: rohc-bounces@ietf.org --===============1219584356== Content-Type: multipart/alternative; boundary="0-191138467-1165293633=:70602" --0-191138467-1165293633=:70602 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable =0AHi All,=0A=0AI have a doubt about zlib decompression.=0AI am using DEFLA= TE as the compression algorithm and have custom build zlib=0ADEFLATE compre= ssor.=0A=0ADo we need to strip off 2-byte zlib header and 4-byte adler32 fr= om=0Acompressed data, before we give the compressed data to UDVM. Then aft= er=0Asuccesfull decompression, decompressor can check for adler32.=0A=0AOr = the logic to strip off 2-byte zlib header and checking of adler32 reside=0A= inside the DEFLATE bytecode. =0A=0ABest Regards,=0A Sreenath=0A=0A=0A=0A= =0A=0A=0A=0A=0A=09=09=0A___________________________________________________= _______=0AYahoo! India Answers: Share what you know. Learn something new=0A= http://in.answers.yahoo.com/ --0-191138467-1165293633=:70602 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable

Hi All,

I have a doubt abou= t zlib decompression.
I am using DEFLATE as the compression algorithm an= d have custom build zlib
DEFLATE compressor.

Do we need to strip = off 2-byte zlib header and 4-byte adler32 from
compressed data, before w= e give the compressed  data to UDVM. Then after
succesfull dec= ompression, decompressor can check for adler32.

Or the logic to stri= p off 2-byte zlib header and checking of adler32 reside
inside the DEFLA= TE bytecode.

Best Regards,
   Sreenath



=0A=09=0A=0A=09=0A=09=09
=0AFind = out what India is talking about on - Yahoo! Answers India
= =0ASend FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. <= a href=3D"http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messen= ger.yahoo.com">Get it NOW --0-191138467-1165293633=:70602-- --===============1219584356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1219584356==-- From rohc-bounces@ietf.org Tue Dec 05 06:29:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYUD-0001tx-Hw; Tue, 05 Dec 2006 06:29:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYUC-0001tr-DK for rohc@ietf.org; Tue, 05 Dec 2006 06:29:20 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrYUB-0000mh-2z for rohc@ietf.org; Tue, 05 Dec 2006 06:29:20 -0500 Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id 84F6520A2E0; Tue, 5 Dec 2006 12:29:17 +0100 (CET) Received: by shell.iptel.org (sSMTP sendmail emulation); Tue, 5 Dec 2006 12:29:10 +0100 Date: Tue, 5 Dec 2006 12:29:10 +0100 From: cco To: Sreenath S Subject: Re: [rohc] Query about SigComp Decompression. Message-ID: <20061205112909.GC649@shell> References: <20061205044033.71094.qmail@web7705.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061205044033.71094.qmail@web7705.mail.in.yahoo.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Tue, Dec 05, 2006 at 10:10:33AM +0530, Sreenath S wrote: > > Hi All, > > I have a doubt about zlib decompression. > I am using DEFLATE as the compression algorithm and have custom build zlib > DEFLATE compressor. > > Do we need to strip off 2-byte zlib header and 4-byte adler32 from > compressed data, before we give the compressed data to UDVM. Then after > succesfull decompression, decompressor can check for adler32. > > Or the logic to strip off 2-byte zlib header and checking of adler32 reside > inside the DEFLATE bytecode. cristian: the important question here is: "which DEFLATE bytecode?". however since this protocol is meant for compression the rule of thumb would be: strip-off anything you do not really need or use. the only information that would be really helpful in your case is: CINFO (Compression info) For CM = 8, CINFO is the base-2 logarithm of the LZ77 window size, minus eight (CINFO=7 indicates a 32K window size). Values of CINFO above 7 are not allowed in this version of the specification. CINFO is not defined in this specification for CM not equal to 8. (from "ZLIB Compressed Data Format Specification version 3.3") however you can encode this on as few as 3 bits. (is a value between 0 and 7) all the other is either not needed or can be impl. differently for sigcomp (for example dictionary is handled at protocol level, using states; and dictionary is mandatory for sip anyway) whether you include CRC or not is again up to you; it is not mandated by any of the sigcomp rfc/drafts. if you include it you must check it in the bytecode. (be careful there is no ADLER32() in the udvm instruction set; if you chose adler32 you will need to implement it somehow using existant udvm instructions... ) now, if you want to "eat" some extra byte(s) from the input packet in your decompresor just use the INPUT-BYTES() instruction and copy them one by one at an address in the udvm vm you do not really use for some other computation. bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Dec 05 06:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYls-0003n3-9M; Tue, 05 Dec 2006 06:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrYlq-0003mw-8T for rohc@ietf.org; Tue, 05 Dec 2006 06:47:34 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrYlo-0005f3-RY for rohc@ietf.org; Tue, 05 Dec 2006 06:47:34 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id kB5BlBGj005295; Tue, 5 Dec 2006 11:47:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] AD evaluation of draft-ietf-rohc-sigcomp-impl-guide-08 Date: Tue, 5 Dec 2006 11:47:11 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] AD evaluation of draft-ietf-rohc-sigcomp-impl-guide-08 Thread-Index: AccXuudeQcpoorHGSJ2ucs9/BQBqngAp2kKw From: "Surtees, Abigail" To: "Magnus Westerlund" , "West, Mark" , "Adam Roach" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: lars-erik@lejonsson.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Magnus, >=20 > 1. The fact that this document updates RFC 3320, RFC 3321 and=20 > RFC3485 needs to be included in both abstract and=20 > introduction. In addition it would be good if the first page=20 > header included: "Updates (if approved):=20 > RFC 3320, RFC 3321, RFC 3485" >=20 OK. > 2. Section 9.2: "200OK" I think should be changed to "200 OK"=20 > for better readability. In addition I think there is a need=20 > to explain that the 200 OK and INVITE talked about in the=20 > text is SIP request and responses. >=20 OK. Can these both be fixed in auth48? > 3. This doesn't need to go into the document. But I need an=20 > answer to the question: Why didn't the ROHC WG update the=20 > three RFCs themselves rather then publishing a implementators guide? >=20 Good question. We started collecting corrections and clarifications, which got put into an 'implementer's guide', which there seemed to be some consensus for publishing. There was some talk of a SigComp DS quite a while ago, but nothing recently and no discussion of updating anything other than RFC3320. =20 Lars-Erik, can you shed any light on this? Best regards, Abbie > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Dec 05 07:29:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZPy-0002Co-UM; Tue, 05 Dec 2006 07:29:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrZPx-0002Ca-B4 for rohc@ietf.org; Tue, 05 Dec 2006 07:29:01 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrZPs-0004uA-05 for rohc@ietf.org; Tue, 05 Dec 2006 07:29:01 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6DC2C8F1; Tue, 5 Dec 2006 13:28:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 13:28:53 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 13:28:53 +0100 Message-ID: <45756605.1020807@ericsson.com> Date: Tue, 05 Dec 2006 13:28:53 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Surtees, Abigail" Subject: Re: [rohc] AD evaluation of draft-ietf-rohc-sigcomp-impl-guide-08 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2006 12:28:53.0267 (UTC) FILETIME=[ECD92E30:01C71868] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "West, Mark" , rohc@ietf.org, Adam Roach , lars-erik@lejonsson.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Surtees, Abigail skrev: > Hi Magnus, >> 1. The fact that this document updates RFC 3320, RFC 3321 and >> RFC3485 needs to be included in both abstract and >> introduction. In addition it would be good if the first page >> header included: "Updates (if approved): >> RFC 3320, RFC 3321, RFC 3485" >> > OK. > >> 2. Section 9.2: "200OK" I think should be changed to "200 OK" >> for better readability. In addition I think there is a need >> to explain that the 200 OK and INVITE talked about in the >> text is SIP request and responses. >> > OK. Can these both be fixed in auth48? No, please submit an updated version. Otherwise it will result in comments from other reviewers. We don't need to waste their time on things we do know are needed. So please resubmit an updated version as soon as possible. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Dec 05 11:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grcty-0007GU-8N; Tue, 05 Dec 2006 11:12:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grctw-0007GC-D6 for rohc@ietf.org; Tue, 05 Dec 2006 11:12:12 -0500 Received: from mother.ludd.ltu.se ([130.240.16.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grctu-0001SU-Ut for rohc@ietf.org; Tue, 05 Dec 2006 11:12:12 -0500 Received: from jymden3 (jymden.campus.luth.se [130.240.198.36]) by mother.ludd.ltu.se (8.13.6+Sun/8.12.10) with SMTP id kB5GBmWI018154; Tue, 5 Dec 2006 17:11:49 +0100 (MET) Message-ID: <003601c71888$7cad0080$24c6f082@jymden3> From: "Lars-Erik Jonsson" To: "Surtees, Abigail" , "Magnus Westerlund" , "West, Mark" , "Adam Roach" , References: Subject: Re: [rohc] AD evaluation of draft-ietf-rohc-sigcomp-impl-guide-08 Date: Tue, 5 Dec 2006 17:14:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org > > 3. This doesn't need to go into the document. But I need an > > answer to the question: Why didn't the ROHC WG update the > > three RFCs themselves rather then publishing a implementators guide? > > > Good question. We started collecting corrections and clarifications, > which got put into an 'implementer's guide', which there seemed to be > some consensus for publishing. There was some talk of a SigComp DS > quite a while ago, but nothing recently and no discussion of updating > anything other than RFC3320. > > Lars-Erik, can you shed any light on this? I'll try! When we started the work to collect the substance that now constitutes the impl-guide, we did not have a clear plan with the document. I fully agree with Magnus that updating the RFCs would be preferable, but then we would have to get that work done, and I am not too optimistic about the possibilities to get commitments to do that work. And in any case, getting this document out *now* is still desirable, and does not necessarily reduce the possibilities to get the other RFCs updated. If someone asks this question, I would say that I am convinced getting this document out as an RFC is for sure much better than nothing. If we can then get people to go further and work on updating RFC 3320 etc, that would be great! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 06 06:23:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grurl-0001u4-SX; Wed, 06 Dec 2006 06:23:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grurk-0001ty-0E for rohc@ietf.org; Wed, 06 Dec 2006 06:23:08 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grurg-0000B1-TE for rohc@ietf.org; Wed, 06 Dec 2006 06:23:06 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id kB6BL2KZ013813; Wed, 6 Dec 2006 11:21:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] AD evaluation of draft-ietf-rohc-sigcomp-impl-guide-08 Date: Wed, 6 Dec 2006 11:21:01 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] AD evaluation of draft-ietf-rohc-sigcomp-impl-guide-08 Thread-Index: AccYaP6zlL+/4WR9QySWtJHD1RxglQAv43Hw From: "Surtees, Abigail" To: "Magnus Westerlund" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "West, Mark" , rohc@ietf.org, Adam Roach , lars-erik@lejonsson.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Magnus, I've submitted an updated version.=20 Best regards, Abbie > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: 05 December 2006 12:29 > To: Surtees, Abigail > Cc: West, Mark; Adam Roach; rohc@ietf.org; lars-erik@lejonsson.com > Subject: Re: [rohc] AD evaluation of=20 > draft-ietf-rohc-sigcomp-impl-guide-08 >=20 > Surtees, Abigail skrev: > > Hi Magnus, > >> 1. The fact that this document updates RFC 3320, RFC 3321 and > >> RFC3485 needs to be included in both abstract and introduction. In=20 > >> addition it would be good if the first page header=20 > included: "Updates=20 > >> (if approved): > >> RFC 3320, RFC 3321, RFC 3485" > >> > > OK. > >=20 > >> 2. Section 9.2: "200OK" I think should be changed to "200 OK"=20 > >> for better readability. In addition I think there is a need to=20 > >> explain that the 200 OK and INVITE talked about in the text is SIP=20 > >> request and responses. > >> > > OK. Can these both be fixed in auth48? >=20 > No, please submit an updated version. Otherwise it will=20 > result in comments from other reviewers. We don't need to=20 > waste their time on things we do know are needed. >=20 > So please resubmit an updated version as soon as possible. >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 06 08:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwlP-0006i3-Cu; Wed, 06 Dec 2006 08:24:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwlO-0006hv-3Y for rohc@ietf.org; Wed, 06 Dec 2006 08:24:42 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrwlM-000336-Qc for rohc@ietf.org; Wed, 06 Dec 2006 08:24:42 -0500 Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id F3AB120A2E1 for ; Wed, 6 Dec 2006 14:24:26 +0100 (CET) Received: by shell.iptel.org (sSMTP sendmail emulation); Wed, 6 Dec 2006 14:24:19 +0100 Date: Wed, 6 Dec 2006 14:24:19 +0100 From: cco To: rohc@ietf.org Message-ID: <20061206132419.GE649@shell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [rohc] accessing sigcomp state with a psi>6bytes X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org hi! as the sigcomp specs reccomend more than 6 bytes should be used for accessing a state in order to avoid (SHA1) collisions. can an internal hash function (which maps SHA1 signatures to some limited interval, like 0...32k) benefit from the extra bytes in the psi for better distributing the SHA1 signatures in the hash buckets? i.e. is there an easy computable function that when applied over an prefix of the SHA1 signatures would produce an short which is better distributed within 0...32k (for example) than an arbitrary short taken _directly_ from the prefix? thanks! bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 06 08:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwoL-0007R5-Bk; Wed, 06 Dec 2006 08:27:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrwoJ-0007Pi-Pl for rohc@ietf.org; Wed, 06 Dec 2006 08:27:43 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrwoH-0003UJ-VV for rohc@ietf.org; Wed, 06 Dec 2006 08:27:43 -0500 Received: from [192.168.101.51] (c-ef7c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.239]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id kB6CaZcF020669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Dec 2006 13:36:36 +0100 Message-ID: <4576C6AA.3030803@effnet.com> Date: Wed, 06 Dec 2006 14:33:30 +0100 From: Carl Knutsson User-Agent: Thunderbird 1.5.0.5 (X11/20060809) MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" References: <026F8EEDAD2C4342A993203088C1FC0503A7D24C@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0503A7D24C@esealmw109.eemea.ericsson.se> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rohc@ietf.org Subject: [rohc] Encapsulating ESPnull header in ESP profile (ROHCv2 profile draft) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Kristofer and Ghyslain, In draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt, it is impossible to fully compress an ESPnull encapsulated ESP flow. The decompressor will not be able to parse the static chain for IP/ESPnull/IP/ESP. When parsing the static chain the for the header above, the decompressor have no way of knowing if the ESP null header is the end-point header or an encapsulating header. My only conclusion is that only the IP/ESPnull part of the header can be compressed for the ESP profile. Is this correct? If not, please explain how to parse the static chain for this flow. /Calle esp_null(next_header_value) { UNCOMPRESSED { spi [ 32 ]; sequence_number [ 32 ]; } CONTROL { nh_field [ 8 ]; } DEFAULT { spi =:= static; sequence_number =:= static; nh_field =:= static; } COMPRESSED esp_static { nh_field =:= compressed_value(8, next_header_value) [ 8 ]; spi =:= irregular(32) [ 32 ]; } } esp(profile) { UNCOMPRESSED { spi [ 32 ]; sequence_number [ 32 ]; ENFORCE(profile == PROFILE_ESP_0103); } DEFAULT { spi =:= static; sequence_number =:= static; } COMPRESSED esp_static { spi =:= irregular(32) [ 32 ]; } } _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 06 10:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryLq-0006B2-OO; Wed, 06 Dec 2006 10:06:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryLp-0006Ax-ET for rohc@ietf.org; Wed, 06 Dec 2006 10:06:25 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GryLh-00026p-RD for rohc@ietf.org; Wed, 06 Dec 2006 10:06:25 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D59DEAF0; Wed, 6 Dec 2006 16:06:12 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 16:06:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Dec 2006 16:06:11 +0100 Message-ID: In-Reply-To: <4576C6AA.3030803@effnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Encapsulating ESPnull header in ESP profile (ROHCv2 profile draft) Thread-Index: AccZOefrzccWF5jJQRGseqqZX3IorgAA5eAw From: "Kristofer Sandlund \(LU/EAB\)" To: "Carl Knutsson" , "Ghyslain Pelletier \(LU/EAB\)" X-OriginalArrivalTime: 06 Dec 2006 15:06:12.0606 (UTC) FILETIME=[118BC1E0:01C71948] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: rohc@ietf.org Subject: [rohc] RE: Encapsulating ESPnull header in ESP profile (ROHCv2 profile draft) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Calle, thanks for catching that, this is actually a problem with the current draft that I hadn't noticed. I see three alternative ways of solving this: 1) Add an extra indicator byte to espnull_static and to esp_static. To keep the compatibility of extension headers with ROHC-TCP and also to avoid this extra overhead, I'm not very fond of this solution. 2) Make some dirty tricks with the protocol numbers so that ESP NULL uses a different protocol number in the compressed headers and the decompressor maps this back to the actual protocol number. I think this can be made to work, but since it requires doing changes in the previous header in the chain and such evil, I don't think this is a good idea even though it is efficient. 3) Disallow the ESP profile to compress ESPnull headers in the chain preceeding the "actual" ESP header. Not the most efficient way of doing things, but since this is a corner-case, it would be in line with or design principle (keep it simple this time!) to go with this solution. If this is the chosen solution, I can ban this with a simple ENFORCE-statement. So clearly, I'd say number 3 of the above. Does anyone have any other smart ideas here or have any preferences w.r.t. a solution? /Kristofer Carl Knutsson wrote on den 6 december 2006 14:34 : > Kristofer and Ghyslain, >=20 > In draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt, it is > impossible to fully compress an ESPnull encapsulated ESP flow. The > decompressor=20 > will not be able to > parse the static chain for IP/ESPnull/IP/ESP. >=20 > When parsing the static chain the for the header above, the > decompressor have no way of knowing if the ESP null header is the > end-point header=20 > or an encapsulating > header. My only conclusion is that only the IP/ESPnull part > of the header can be > compressed for the ESP profile. Is this correct? >=20 > If not, please explain how to parse the static chain for this flow. >=20 > /Calle >=20 > esp_null(next_header_value) > { > UNCOMPRESSED { > spi [ 32 ]; > sequence_number [ 32 ]; > } >=20 > CONTROL { > nh_field [ 8 ]; > } >=20 > DEFAULT { > spi =3D:=3D static; > sequence_number =3D:=3D static; > nh_field =3D:=3D static; > } >=20 > COMPRESSED esp_static { > nh_field =3D:=3D compressed_value(8, next_header_value) [ 8 ]; > spi =3D:=3D irregular(32) [ 32 ]; = =20 > } } >=20 > esp(profile) > { > UNCOMPRESSED { > spi [ 32 ]; > sequence_number [ 32 ]; > ENFORCE(profile =3D=3D PROFILE_ESP_0103); > } >=20 > DEFAULT { > spi =3D:=3D static; > sequence_number =3D:=3D static; > } >=20 > COMPRESSED esp_static { > spi =3D:=3D irregular(32) [ 32 ]; > } > } _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 06 10:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gryk0-0002Dj-5d; Wed, 06 Dec 2006 10:31:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gryjy-0002DH-Cr for rohc@ietf.org; Wed, 06 Dec 2006 10:31:22 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gryjw-0007CV-Gv for rohc@ietf.org; Wed, 06 Dec 2006 10:31:22 -0500 Received: from [192.168.101.51] (c-ef7c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.239]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id kB6EeOcF021695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Dec 2006 15:40:24 +0100 Message-ID: <4576E3B1.5090003@effnet.com> Date: Wed, 06 Dec 2006 16:37:21 +0100 From: Carl Knutsson User-Agent: Thunderbird 1.5.0.5 (X11/20060809) MIME-Version: 1.0 To: "Kristofer Sandlund (LU/EAB)" References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" Subject: [rohc] Re: Encapsulating ESPnull header in ESP profile (ROHCv2 profile draft) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Thanks Kristofer, There is a fourth alternative. As in 1), but only add the field to esp_static. This field must differ from all the allowed next header/protocol values of all the IP extension headers. It will add one octet to all IR packets for the ESP profile. This alternative does not affect the compatibility with the TCP profile. I haven't decided which alternative I prefer. I will get back to the list when I have:) /Calle Kristofer Sandlund (LU/EAB) wrote: > Hi Calle, > > thanks for catching that, this is actually a problem with the current > draft > that I hadn't noticed. > > I see three alternative ways of solving this: > 1) Add an extra indicator byte to espnull_static and to esp_static. To > keep > the compatibility of extension headers with ROHC-TCP and also to avoid > this > extra overhead, I'm not very fond of this solution. > 2) Make some dirty tricks with the protocol numbers so that ESP NULL > uses > a different protocol number in the compressed headers and the > decompressor > maps this back to the actual protocol number. I think this can be made > to work, > but since it requires doing changes in the previous header in the chain > and > such evil, I don't think this is a good idea even though it is > efficient. > 3) Disallow the ESP profile to compress ESPnull headers in the chain > preceeding > the "actual" ESP header. Not the most efficient way of doing things, but > since this is a corner-case, it would be in line with or design > principle > (keep it simple this time!) to go with this solution. If this is the > chosen > solution, I can ban this with a simple ENFORCE-statement. > > So clearly, I'd say number 3 of the above. > Does anyone have any other smart ideas here or have any preferences > w.r.t. > a solution? > > /Kristofer > > Carl Knutsson wrote on den 6 december > 2006 14:34 : > >> Kristofer and Ghyslain, >> >> In draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt, it is >> impossible to fully compress an ESPnull encapsulated ESP flow. The >> decompressor >> will not be able to >> parse the static chain for IP/ESPnull/IP/ESP. >> >> When parsing the static chain the for the header above, the >> decompressor have no way of knowing if the ESP null header is the >> end-point header >> or an encapsulating >> header. My only conclusion is that only the IP/ESPnull part >> of the header can be >> compressed for the ESP profile. Is this correct? >> >> If not, please explain how to parse the static chain for this flow. >> >> /Calle >> >> esp_null(next_header_value) >> { >> UNCOMPRESSED { >> spi [ 32 ]; >> sequence_number [ 32 ]; >> } >> >> CONTROL { >> nh_field [ 8 ]; >> } >> >> DEFAULT { >> spi =:= static; >> sequence_number =:= static; >> nh_field =:= static; >> } >> >> COMPRESSED esp_static { >> nh_field =:= compressed_value(8, next_header_value) [ 8 ]; >> spi =:= irregular(32) [ 32 ]; >> } } >> >> esp(profile) >> { >> UNCOMPRESSED { >> spi [ 32 ]; >> sequence_number [ 32 ]; >> ENFORCE(profile == PROFILE_ESP_0103); >> } >> >> DEFAULT { >> spi =:= static; >> sequence_number =:= static; >> } >> >> COMPRESSED esp_static { >> spi =:= irregular(32) [ 32 ]; >> } >> } _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 06 18:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6Wx-0004sA-J7; Wed, 06 Dec 2006 18:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6Wn-0004kE-3d; Wed, 06 Dec 2006 18:50:17 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs6WY-00025G-Bd; Wed, 06 Dec 2006 18:50:17 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5011C328FF; Wed, 6 Dec 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gs6WY-0006qf-5A; Wed, 06 Dec 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 06 Dec 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-impl-guide-09.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Implementer's Guide for SigComp Author(s) : A. Surtees, et al. Filename : draft-ietf-rohc-sigcomp-impl-guide-09.txt Pages : 24 Date : 2006-12-6 This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document (if approved) updates: RFC 3320, RFC 3321, RFC 3485. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-impl-guide-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-6162145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-impl-guide-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-6162145.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Wed Dec 06 18:50:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6XB-0005LZ-Jg; Wed, 06 Dec 2006 18:50:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs6X3-0004zs-83; Wed, 06 Dec 2006 18:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gs6X2-0003IS-V4; Wed, 06 Dec 2006 18:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 98015175E0; Wed, 6 Dec 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gs6WY-0006qi-6J; Wed, 06 Dec 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 06 Dec 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-impl-guide-09.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Implementer's Guide for SigComp Author(s) : A. Surtees, et al. Filename : draft-ietf-rohc-sigcomp-impl-guide-09.txt Pages : 24 Date : 2006-12-6 This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document (if approved) updates: RFC 3320, RFC 3321, RFC 3485. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-impl-guide-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-6163239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-impl-guide-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-6163239.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Thu Dec 07 09:42:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKRk-00065p-NK; Thu, 07 Dec 2006 09:42:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKRh-00060G-9q; Thu, 07 Dec 2006 09:41:57 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsKRg-0001wo-1e; Thu, 07 Dec 2006 09:41:57 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0141E2AC5E; Thu, 7 Dec 2006 14:41:26 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GsKRB-0001fU-Og; Thu, 07 Dec 2006 09:41:25 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 07 Dec 2006 09:41:25 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rohc@ietf.org Subject: [rohc] Last Call: 'Implementer's Guide for SigComp' to Proposed Standard (draft-ietf-rohc-sigcomp-impl-guide) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org The IESG has received a request from the Robust Header Compression WG to consider the following document: - 'Implementer's Guide for SigComp ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-12-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-09.txt _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Dec 08 08:11:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfVk-00074Y-7e; Fri, 08 Dec 2006 08:11:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfVj-00074M-9c for rohc@ietf.org; Fri, 08 Dec 2006 08:11:31 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsfVb-0002zg-QO for rohc@ietf.org; Fri, 08 Dec 2006 08:11:31 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB838B9D; Fri, 8 Dec 2006 14:11:18 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 14:11:18 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 14:11:18 +0100 Message-ID: <45796476.6010801@ericsson.com> Date: Fri, 08 Dec 2006 14:11:18 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: robert.finking@roke.co.uk, EPLGHPE , rohc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2006 13:11:18.0699 (UTC) FILETIME=[594887B0:01C71ACA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, I have reviewed formal notation and have few comments. In general the document is quite readable and easy to understand for being a definition of a formal notation. 1. Section 4.9: Enforce statements. It is not clear here that all ENFORCE statements within a particular scope have an OR relation to them. I think that needs clarification in this section. 2. Section 4.11.6: " Usage of the "THIS" keyword (see Section 4.6) as shown in the example above, is typical when using "crc" encoding. It causes the CRC to be calculated over all fields in the header." First of all I think the usage of "header" in the last sentence in the above paragraph is wrong. Because this depends on which scope "THIS" has. From the example above you can't determine a particular scope as you don't see the full definition of the encoding. 3. B.5, In the example for encoding obvious you haven't changed the sequence_no =:= lsb(0,-3) to sequence_no =:= lsb(2,-3). To me it seems that it should have been changed after the discussion in the last paragraph of Section B.4. The alternative I see which may be more clear would actually to include in B.4 at the end the corrected example. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Dec 08 08:19:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsfdf-0002GY-CD; Fri, 08 Dec 2006 08:19:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsfde-0002GK-Mm for rohc@ietf.org; Fri, 08 Dec 2006 08:19:42 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsfdd-0004ww-3d for rohc@ietf.org; Fri, 08 Dec 2006 08:19:42 -0500 Received: from [192.168.101.51] (c-ef7c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.239]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id kB8CSWcF007841 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 8 Dec 2006 13:28:33 +0100 Message-ID: <457967E7.8080805@effnet.com> Date: Fri, 08 Dec 2006 14:25:59 +0100 From: Carl Knutsson User-Agent: Thunderbird 1.5.0.5 (X11/20060809) MIME-Version: 1.0 To: rohc Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-tcp-14.txt X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org I forgot to cc the rohc-list... -------- Original Message -------- Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-tcp-14.txt Date: Fri, 08 Dec 2006 14:17:42 +0100 From: Carl Knutsson To: Kristofer Sandlund (LU/EAB) CC: Ghyslain Pelletier (LU/EAB) , West, Mark , Lars-Erik Jonsson (LU/EAB) , lars-erik@lejonsson.com References: Ghyslain, Kristofer, L-E, Mark, I have briefly checked the fn of the tcp-draft (draft-ietf-rohc-tcp-14.txt) and I couldn't find the definition of the following encoding methods. I fear that a typo or two have found its way into the draft. Correct me if I am wrong. Please check the following: o on page 73, 74, in compressed format tcp_irregular och tcp_dynamic: tcp_res_flags =:= tstatic_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; Typo? Replace with: tcp_res_flags =:= static_or_irreg(ecn_used.CVALUE, 4) [ 0, 4 ]; o On page 73, in Compressed formats tcp_dynamic och tcp_replicate: ack_stride =:= static_or_irr16(ack_stride_flag.CVALUE) [ 0, 16 ]; In earlier drafts there were an encoding method for static_or_irreg16. It could be replaced by: ack_stride =:= static_or_irregular(ack_stride_flag.CVALUE, 16) [ 0, 16 ]; rgds, /Calle Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Robust Header Compression Working Group of the IETF. > > Title : RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) > Author(s) : G. Pelletier, et al. > Filename : draft-ietf-rohc-tcp-14.txt > Pages : 94 > Date : 2006-11-26 > > This document specifies a ROHC (Robust Header Compression) profile > for compression of TCP/IP packets. The profile, called ROHC-TCP, > provides efficient and robust compression of TCP headers, including > frequently used TCP options such as SACK (Selective Acknowledgments) > and Timestamps. > ROHC-TCP works well when used over links with significant error rates > and long round-trip times. For many bandwidth-limited links where > header compression is essential, such characteristics are common. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-14.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-rohc-tcp-14.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-rohc-tcp-14.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 rohc-bounces@ietf.org Fri Dec 08 08:41:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsfz1-0002Hv-J2; Fri, 08 Dec 2006 08:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsfyz-0002Hn-QE for rohc@ietf.org; Fri, 08 Dec 2006 08:41:45 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsfyL-000132-DF for rohc@ietf.org; Fri, 08 Dec 2006 08:41:45 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id kB8Dek8e022384; Fri, 8 Dec 2006 14:40:46 +0100 (CET) In-Reply-To: <45796476.6010801@ericsson.com> References: <45796476.6010801@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12 Date: Fri, 8 Dec 2006 14:40:37 +0100 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Carsten Bormann , rohc@ietf.org, robert.finking@roke.co.uk, EPLGHPE X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Dec 08 2006, at 14:11, Magnus Westerlund wrote: > Hi, > > I have reviewed formal notation and have few comments. In general > the document is quite readable and easy to understand for being a > definition of a formal notation. > > 1. Section 4.9: Enforce statements. > > It is not clear here that all ENFORCE statements within a > particular scope have an OR relation to them. I think that needs > clarification in this section. The ENFORCE statements have an AND relationship to them, i.e., each and all of them must be fulfilled for a format to succeed. To me, this is reasonably clear from the statement: There are three possible conditions that the expression may be in: 1. The boolean expression evaluates to false, in which case the local scope of the format that contains the "ENFORCE" statement cannot be used, I.e., one of them evaluating to false makes the format fail. This is exactly the definition of a conjunction, i.e., an AND relationship. See also 4.12.1.1 (but this only talks about uncompressed formats; the same is true of compressed formats). But it would not hurt to add this clarification in a note or in introductory text. E.g., 4.9 could start with NEW: "ENFORCE" statements provide a way to add predicates to a format, all of which must be fulfilled for a format to succeed. As another editorial improvement, this would also say what they are good for before delving into what they are like. > 2. Section 4.11.6: > > " Usage of the "THIS" keyword (see Section 4.6) as shown in the > example > above, is typical when using "crc" encoding. It causes the CRC > to be > calculated over all fields in the header." > > First of all I think the usage of "header" in the last sentence in > the above paragraph is wrong. Because this depends on which scope > "THIS" has. From the example above you can't determine a particular > scope as you don't see the full definition of the encoding. Good catch. I didn't flag this because I thought that at this point it should be clear how THIS needs to be used for this to be true but, again, this is a useful clarification. Proposal: OLD: It causes the CRC to be calculated over all fields in the header. NEW: E.g., when used in the encoding method for an entire header, it causes the CRC to be calculated over all fields in the header. > > 3. B.5, In the example for encoding obvious you haven't changed the > sequence_no =:= lsb(0,-3) to sequence_no =:= lsb(2,-3). To me it > seems that it should have been changed after the discussion in the > last paragraph of Section B.4. The alternative I see which may be > more clear would actually to include in B.4 at the end the > corrected example. It might be sufficient to just introduce the line: sequence_no =:= lsb(2, -3); at the end of B.4 (and fix the line in B.5, of course). Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Dec 08 09:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgKn-0002r3-Lk; Fri, 08 Dec 2006 09:04:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgKl-0002qw-9C for rohc@ietf.org; Fri, 08 Dec 2006 09:04:15 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsgKf-0005Oj-QO for rohc@ietf.org; Fri, 08 Dec 2006 09:04:15 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E360A4F0001; Fri, 8 Dec 2006 15:04:06 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 15:04:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12 Date: Fri, 8 Dec 2006 15:04:06 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0501CD5707@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12 Thread-Index: AccaznzyfGPILh0rTsekIfFeM+ic4wAApLpw From: "Ghyslain Pelletier \(LU/EAB\)" To: "Carsten Bormann" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 08 Dec 2006 14:04:06.0730 (UTC) FILETIME=[B993B2A0:01C71AD1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: robert.finking@roke.co.uk, rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Magnus, Carsten, Thanks for your comments; the resolution proposed by Carsten is ok with me. Magnus - do you want us to produce an updated draft already for this, or can we wait? ///Ghyslain Carsten Bormann wrote: > On Dec 08 2006, at 14:11, Magnus Westerlund wrote: >=20 >> Hi, >>=20 >> I have reviewed formal notation and have few comments. In general the >> document is quite readable and easy to understand for being a >> definition of a formal notation. >>=20 >> 1. Section 4.9: Enforce statements. >>=20 >> It is not clear here that all ENFORCE statements within a particular >> scope have an OR relation to them. I think that needs clarification >> in this section. >=20 > The ENFORCE statements have an AND relationship to them, > i.e., each and all of them must be fulfilled for a format to succeed. >=20 > To me, this is reasonably clear from the statement: >=20 > There are three possible conditions that the expression may be in: >=20 > 1. The boolean expression evaluates to false, in which case the > local scope of the format that contains the "ENFORCE" > statement cannot be used, >=20 > I.e., one of them evaluating to false makes the format fail. > This is exactly the definition of a conjunction, i.e., an AND > relationship.=20 >=20 > See also 4.12.1.1 (but this only talks about uncompressed > formats; the same is true of compressed formats). >=20 > But it would not hurt to add this clarification in a note or > in introductory text. > E.g., 4.9 could start with >=20 > NEW: > "ENFORCE" statements provide a way to add predicates to a > format, all of which must be fulfilled for a format to succeed. >=20 > As another editorial improvement, this would also say what > they are good for before delving into what they are like. >=20 >> 2. Section 4.11.6: >>=20 >> " Usage of the "THIS" keyword (see Section 4.6) as shown in the >> example above, is typical when using "crc" encoding. It causes >> the CRC to be calculated over all fields in the header." >>=20 >> First of all I think the usage of "header" in the last sentence in >> the above paragraph is wrong. Because this depends on which scope >> "THIS" has. From the example above you can't determine a particular >> scope as you don't see the full definition of the encoding. >=20 > Good catch. > I didn't flag this because I thought that at this point it > should be clear how THIS needs to be used for this to be true > but, again, this is a useful clarification. >=20 > Proposal: > OLD: > It causes the CRC to be > calculated over all fields in the header. > NEW: > E.g., when used in the encoding method for an entire header, > it causes the CRC to be > calculated over all fields in the header. >=20 >>=20 >> 3. B.5, In the example for encoding obvious you haven't changed the >> sequence_no =3D:=3D lsb(0,-3) to sequence_no =3D:=3D lsb(2,-3). To me = it >> seems that it should have been changed after the discussion in the >> last paragraph of Section B.4. The alternative I see which may be >> more clear would actually to include in B.4 at the end the >> corrected example. >=20 > It might be sufficient to just introduce the line: > sequence_no =3D:=3D lsb(2, -3); > at the end of B.4 (and fix the line in B.5, of course). >=20 > Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Dec 08 09:07:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgOL-0004eY-Pu; Fri, 08 Dec 2006 09:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgOK-0004e0-8D for rohc@ietf.org; Fri, 08 Dec 2006 09:07:56 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsgO6-0006NI-9Q for rohc@ietf.org; Fri, 08 Dec 2006 09:07:56 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 71BF9DF2; Fri, 8 Dec 2006 15:07:39 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 15:07:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] I-D ACTION:draft-ietf-rohc-tcp-14.txt Date: Fri, 8 Dec 2006 15:07:33 +0100 Message-ID: In-Reply-To: <457967E7.8080805@effnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] I-D ACTION:draft-ietf-rohc-tcp-14.txt Thread-Index: AccayzxShKcbc2UuQp6WG7IyFF/auwABLAsQ From: "Kristofer Sandlund \(LU/EAB\)" To: "Carl Knutsson" , "rohc" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 08 Dec 2006 14:07:34.0352 (UTC) FILETIME=[35544D00:01C71AD2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Calle, thanks for catching these evil typos. I have updated the TCP XML on the CVS with this change. Magnus, do you want us to submit a new version of ROHC-TCP now, or should we wait? /Kristofer Carl Knutsson wrote on den 8 december 2006 14:26 : > I forgot to cc the rohc-list... >=20 >=20 > -------- Original Message -------- > Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-tcp-14.txt > Date: Fri, 08 Dec 2006 14:17:42 +0100 > From: Carl Knutsson > To: Kristofer Sandlund (LU/EAB) > CC: Ghyslain Pelletier (LU/EAB) > , West, Mark > , Lars-Erik Jonsson (LU/EAB) > , lars-erik@lejonsson.com > References: >=20 > Ghyslain, Kristofer, L-E, Mark, >=20 > I have briefly checked the fn of the tcp-draft > (draft-ietf-rohc-tcp-14.txt) and I > couldn't find the definition of the following encoding > methods. I fear that a typo > or two have found its way into the draft. Correct me if I am wrong. >=20 > Please check the following: >=20 > o on page 73, 74, in compressed format tcp_irregular och tcp_dynamic: >=20 > tcp_res_flags =3D:=3D tstatic_or_irreg(ecn_used.CVALUE, 4) [ = 0, 4 > ];=20 >=20 > Typo? Replace with: >=20 > tcp_res_flags =3D:=3D static_or_irreg(ecn_used.CVALUE, 4) [ 0, = 4 ]; >=20 >=20 > o On page 73, in Compressed formats tcp_dynamic och tcp_replicate: >=20 > ack_stride =3D:=3D static_or_irr16(ack_stride_flag.CVALUE) [ 0, 16 = ]; >=20 >=20 > In earlier drafts there were an encoding method for > static_or_irreg16. It could be > replaced by: >=20 > ack_stride =3D:=3D static_or_irregular(ack_stride_flag.CVALUE, 16) = =20 > [ 0, 16 ];=20 >=20 >=20 > rgds, > /Calle >=20 >=20 > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Robust Header >> Compression Working Group of the IETF.=20 >>=20 >> Title : RObust Header Compression (ROHC): A Profile for TCP/IP >> (ROHC-TCP) Author(s) : G. Pelletier, et al. >> Filename : draft-ietf-rohc-tcp-14.txt >> Pages : 94 >> Date : 2006-11-26 >>=20 >> This document specifies a ROHC (Robust Header Compression) profile >> for compression of TCP/IP packets. The profile, called ROHC-TCP, >> provides efficient and robust compression of TCP headers, >> including frequently used TCP options such as SACK (Selective >> Acknowledgments) and Timestamps. ROHC-TCP works well when used >> over links with significant error rates and long round-trip >> times. For many bandwidth-limited links where header compression >> is essential, such characteristics are common.=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-14.txt >>=20 >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body >> of the message. You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >>=20 >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-ietf-rohc-tcp-14.txt". >>=20 >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> Internet-Drafts can also be obtained by e-mail. >>=20 >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-rohc-tcp-14.txt". >>=20 >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft.=20 >>=20 >>=20 >>=20 > -------------------------------------------------------------- > ---------- >>=20 >> _______________________________________________ >> Rohc mailing list >> Rohc@ietf.org >> https://www1.ietf.org/mailman/listinfo/rohc >=20 >=20 >=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 rohc-bounces@ietf.org Fri Dec 08 09:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgWG-0007rg-LC; Fri, 08 Dec 2006 09:16:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgWE-0007rZ-PQ for rohc@ietf.org; Fri, 08 Dec 2006 09:16:06 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsgW4-0008JX-Kz for rohc@ietf.org; Fri, 08 Dec 2006 09:16:06 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB782CEB; Fri, 8 Dec 2006 15:15:51 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 15:15:51 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 15:13:45 +0100 Message-ID: <45797319.1050801@ericsson.com> Date: Fri, 08 Dec 2006 15:13:45 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" Subject: Re: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12 References: <026F8EEDAD2C4342A993203088C1FC0501CD5707@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0501CD5707@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2006 14:13:45.0443 (UTC) FILETIME=[12844B30:01C71AD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Carsten Bormann , rohc@ietf.org, robert.finking@roke.co.uk X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Ghyslain Pelletier (LU/EAB) skrev: > Magnus, Carsten, > > Thanks for your comments; the resolution proposed by Carsten is ok with > me. And with me. > > Magnus - do you want us to produce an updated draft already for this, or > can we wait? Please produce a new draft. That way I can go to IETF last call as soon as the draft becomes available. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Dec 08 11:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsisF-00015w-Hu; Fri, 08 Dec 2006 11:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsisE-00015r-M1 for rohc@ietf.org; Fri, 08 Dec 2006 11:46:58 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsisD-00007T-9F for rohc@ietf.org; Fri, 08 Dec 2006 11:46:58 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id kB8GkmLT025665; Fri, 8 Dec 2006 16:46:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12 Date: Fri, 8 Dec 2006 16:46:48 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] AD evaluation of draft-ietf-rohc-formal-notation-12 Thread-Index: Acca02mZJ3aIAhlSQZOPBuAL6kZBRAAFOgLA From: "Finking, Robert" To: "Magnus Westerlund" , "Ghyslain Pelletier \(LU/EAB\)" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Carsten Bormann , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org >=20 > Please produce a new draft. That way I can go to IETF last=20 > call as soon=20 > as the draft becomes available. >=20 Great =3D) Ghyslain are you happy doing this? Sorry I haven't been available to do much editing at this crucial stage. Raffles _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Dec 11 15:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts77-0001s0-DN; Mon, 11 Dec 2006 15:51:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gts6b-0000t4-5e; Mon, 11 Dec 2006 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gts6a-0006Ac-Es; Mon, 11 Dec 2006 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 573322AC89; Mon, 11 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gts66-0007ie-1O; Mon, 11 Dec 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 11 Dec 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-tcp-15.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) Author(s) : G. Pelletier, et al. Filename : draft-ietf-rohc-tcp-15.txt Pages : 93 Date : 2006-12-11 This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-tcp-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-tcp-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-11142044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-tcp-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-tcp-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-11142044.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Tue Dec 12 12:11:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuB9t-0005Rv-4C; Tue, 12 Dec 2006 12:11:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuB9r-0005Rl-64 for rohc@ietf.org; Tue, 12 Dec 2006 12:11:11 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuB9p-0007OC-Et for rohc@ietf.org; Tue, 12 Dec 2006 12:11:11 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id kBCHAJK4003602; Tue, 12 Dec 2006 17:10:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Dec 2006 17:10:18 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Second WG last-call for SIP/SigComp - dedicated review Thread-Index: AcbuzRndN0JXkkp7RxmzKDCgwAGyVwPCbh9QB9rEDaA= From: "Surtees, Abigail" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: lars-erik@lejonsson.com, Gonzalo Camarillo Subject: [rohc] Second WG last-call for SIP/SigComp - dedicated review X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi All, Here are my CDR comments on draft-ietf-rohc-sigcomp-sip-04.txt. I am surprised to find that some of my comments from the first WGLC have neither been addressed by email nor addressed in the updated document (unless the email got missed?) Those that have been addressed, I've removed from this email. Those that haven't are still here with a note. There are also some new comments. The nits are in a separate section at the bottom. Best regards, Abbie Abstract and introduction: "Any implementation of SigComp for use with SIP must confirm to this document."=20 This sentence appears in the introduction too. What does this mean without the must being a MUST (I realise it shouldn't be a MUST in the abstract)? What does this mean for legacy implementations / implementations conforming to other specifications e.g. 3GPP TS24.229? [12/12/06] no response Introduction: "Additionally, it must support ...[3485] and ...[3486]." Again no standards language. Support for 3485 is specified further on in the document (so I think isn't needed here) but support for 3486 isn't so what does this mean for support of that RFC? [12/12/06] no response Section 3.1: I know the 'reason' part here but I think it should be written more clearly (I think if you were new to it you'd have to read it several times). Add another sentence to explain the example. Also, the SigComp user guide refers to 'circular buffer' not 'ring buffer' so it may be worth using 'circular buffer' here (ring buffer isn't used anywhere else). [12/12/06] no response Section 3.2: The arguments now is: * 'non-zero SMS removes uncertainty' - that's not strictly true because the application can still refuse state creation. * Stateless SIP implementations are unlikely to do SigComp - fair enough * 2K per compartment isn't a huge overhead for a stateful implementation - ok [12/12/06] Some text has been removed from this section which is fine, but the first point still seems slightly disingenuous and could cause confusion. Section 3.5: Add a statement that because the static dictionary is mandatory it does not need to be advertised (last point in this email discussion http://www1.ietf.org/mail-archive/web/rohc/current/msg04463.html). [12/12/06] no response Section 8.2 Re: Use of IP address and port/connection for the remote application identifier for legacy systems. If a client fails (losing all SIP state including SigComp compartment) and re-REGISTERS with the same IP address, how can the SIP stack tell that the old compartment is invalid. I realise that the answer is probably that this circumstance is relatively unlikely and that NACK would recover the situation, but I think this should be made clearer. Section 8.3=20 I think this section should be combined with section 8.4. The definition of when compartments should be opened and closed needs to be stronger. In this section, section 8.4 and section 12, there are strong echoes of the fact that it used to be possible to have different compartment lifetimes. I think there should be standards language (probably SHOULDs) stating when compartments should be opened and closed. i.e. compartments SHOULD last the lifetime of the registration, but leaving the possibility for early closure and NACK recovery in extreme cases (e.g. overload conditions). Section 8.3 (Paragraph about keeping state beyond the end of a compartment): This paragraph still refers to compartments lasting the length of a dialog or transaction! How useful is the technique described in this paragraph, now that a compartment lifetime is a registration?=20 Section 8.4 See comment on section 8.3 about strengthening compartment definition. I also think the security implications of opening a compartment on receipt of a REGISTER should be mentioned. Compartments and state can only be created if the application says so, but, particularly if the decompressing node is a proxy, the non-2xx response may take a while to be generated. Section 8.4 "However, applications MAY also choose to keep these compartments open for a longer period of time, as discussed previously." Does the 'as discussed previously refer to the 'paragraph about keeping state beyond the end of a compartment'? If so, then i) I'm not sure it's that useful and ii) the wording implies something different. If not, then what does it refer to? Section 8.5 I was surprised to see this section (but maybe I missed it's discussion on the list). I can understand softening the 'SHOULD' in RFC3486, but I don't think it should be a 'SHOULD NOT' - it depends on the stateless algorithm in use and the size of the message being compressed. With a stateless algorithm that has short bytecode and a large message (e.g. INVITE) it is possible to still achieve non-trivial compression gain. Section 12: I think section 12 should either be part of section 8 or become section 9 (preferably the former) because it is an example of compartment creation and deletion. [12/12/06] This was a comment about section 10 before. No response. As mentioned above several sentences have echoes of the possibility of having variable compartment lifetime: "This compartment will be valid, at least, for the duration of the registration." Remove the 'at least' "The compartment opened by the outbound proxy will be valid, at least, for the duration of the registration." Remove the 'at least' "Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of the compartment created before, this compartment is used to compress the INVITE request." What other compartment could be used? Nits: Section 3: page 3 "Note: a SigComp endpoint MAY offer additional resources if available;" - make clear that it's additional over and above the minimum values specified in this document rather than the basic SigComp minimum values. [11/12/06] no response Section 4: second paragraph: "For a message-based transport such as UDP or SCTP, this can be done per message." -> "For a message-based transport such as UDP or SCTP, distinguishing between SigComp and non-SigComp messages can be done per message." [12/12/06] no response Section 4: third paragraph: "For a stream-based transport such as TCP, this can be done per connection." -> "For a message-based transport such as UDP or SCTP, distinguishing between SigComp and non-SigComp has to be done per connection." [12/12/06] no response Section 4: final note: Refers to 'a SigComp structured TCP connection' - I think the word structured is unnecessary and mildly confusing in this note. [12/12/06] no response. Alternatively make it 'SigComp-structured' Section 7:=20 Phraseology 'failure occurred to' and 'loss occurred to' feel slightly clumsy. Rephrase to: 'failure occurred on' and 'If the response was lost, ...' Section 8.1: "Incoming responses: the remote application identifier is the same as the one of the previously-sent request that initiated the transaction the response belongs to." ->=20 "Incoming responses: the remote application identifier is the same as that of the previously-sent request that initiated the transaction to which the response belongs." "Outgoing responses: the remote application identifier is the same as the previously-received request that initiated the transaction the response belongs to." -> "Outgoing responses: the remote application identifier is the same as that of the previously-received request that initiated the transaction to which the response belongs." [12/12/06] was section 6.1; no response comparment -> compartment (1 instance in section 8.3 and 1 in section 11) Section 8.4: last paragraph "If following the previous rules" -> "If, following the rules above, " > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] > Sent: 13 October 2006 14:40 > To: rohc@ietf.org > Subject: [rohc] WG last-call for SIP/SigComp >=20 >=20 > Soon after the publication of SigComp (RFC 3320), work with a document > defining the specifics of using SigComp for SIP message compression=20 > was initialised. For various reasons, the finalisation of this=20 > document has taken much more time than anticipated, but me and the=20 > authors now believe it should be ready for publication. This is an=20 > essential document for the application of SigComp on SIP, and it is=20 > thus important that we finally get it out of the pipe. We are=20 > therefore now issuing a working group last-call on the following=20 > document: > =20 > draft-ietf-rohc-sigcomp-sip-03.txt > (for publication as Proposed Standard) > =20 > This will be the usual two-week WG last-call as suggested in RFC 2418. > Please direct last-call comments to the ROHC mailing list=20 > rohc@ietf.org before Fri, 2006-10-27, 18:00 UTC. > =20 > /L-E >=20 > -------------------------------------- > Lars-Erik Jonsson > IETF ROHC WG Chair > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 8 404 29 61 >=20 > My opinions are my personal opinions and should not be considered as=20 > the opinions of my employer, if not explicitly stated. >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=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 rohc-bounces@ietf.org Tue Dec 12 15:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEaw-0006we-GO; Tue, 12 Dec 2006 15:51:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEap-0006ca-IB; Tue, 12 Dec 2006 15:51:15 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuEao-0001ye-7n; Tue, 12 Dec 2006 15:51:15 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 2B5712AD5B; Tue, 12 Dec 2006 20:50:44 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuEaJ-000873-Gd; Tue, 12 Dec 2006 15:50:43 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Dec 2006 15:50:43 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-formal-notation-13.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Formal Notation for Robust Header Compression (ROHC-FN) Author(s) : G. Pelletier, R. Finking Filename : draft-ietf-rohc-formal-notation-13.txt Pages : 65 Date : 2006-12-12 This document defines ROHC-FN (RObust Header Compression - Formal Notation): a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help simplifying future profile development work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-formal-notation-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-formal-notation-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-formal-notation-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-12141910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-formal-notation-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-formal-notation-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-12141910.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Tue Dec 12 16:55:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuFan-0000Vd-3Y; Tue, 12 Dec 2006 16:55:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuFal-0000VE-1L for rohc@ietf.org; Tue, 12 Dec 2006 16:55:15 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuFaU-0004HA-Ul for rohc@ietf.org; Tue, 12 Dec 2006 16:55:14 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id kBCLss5G020576; Tue, 12 Dec 2006 22:54:54 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68EB40AA-6369-4C4D-B7FA-D20B4663451A@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] I-D ACTION:draft-ietf-rohc-formal-notation-13.txt Date: Tue, 12 Dec 2006 22:54:53 +0100 To: rohc@ietf.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Great work. One absolutely minor nit of the AUTH48 kind: OLD: This section gives a definition of the syntax of ROHC-FN in ABNF [RFC4234], using "fnspec" as the start rule. ; overall structure fnspec = S *(constdef S) [globctl S] 1*(methdef S) NEW: This section gives a definition of the syntax of ROHC-FN in ABNF [RFC4234], using "fnspec" as the start rule. ; overall structure fnspec = S *(constdef S) [globctl S] 1*(methdef S) i.e., insert a blank line to separate the actual ABNF from the introductory sentence. (Of course, no need for a re-spin for that kind of nit -- if the RFC editor doesn't fix it by themselves, it can be fixed at AUTH48.) Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 13 09:59:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVZY-0005T0-AW; Wed, 13 Dec 2006 09:59:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVZW-0005SW-54; Wed, 13 Dec 2006 09:59:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuVZT-0007Ji-RN; Wed, 13 Dec 2006 09:59:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C2A3F2ACF3; Wed, 13 Dec 2006 14:58:29 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuVYz-0002U1-H5; Wed, 13 Dec 2006 09:58:29 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 13 Dec 2006 09:58:29 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rohc@ietf.org Subject: [rohc] Last Call: 'Formal Notation for Robust Header Compression (ROHC-FN)' to Proposed Standard (draft-ietf-rohc-formal-notation) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org The IESG has received a request from the Robust Header Compression WG to consider the following document: - 'Formal Notation for Robust Header Compression (ROHC-FN) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2007-01-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-formal-notation-13.txt _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Dec 13 12:04:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXWu-0003eP-4i; Wed, 13 Dec 2006 12:04:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXWt-0003cC-4P for rohc@ietf.org; Wed, 13 Dec 2006 12:04:27 -0500 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuXWr-0003ql-JS for rohc@ietf.org; Wed, 13 Dec 2006 12:04:27 -0500 Received: from shell.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with SMTP id E038D20A2F2; Wed, 13 Dec 2006 18:04:23 +0100 (CET) Received: by shell.iptel.org (sSMTP sendmail emulation); Wed, 13 Dec 2006 18:04:15 +0100 Date: Wed, 13 Dec 2006 18:04:15 +0100 From: cco To: "Surtees, Abigail" Subject: Re: [rohc] Second WG last-call for SIP/SigComp - dedicated review Message-ID: <20061213170415.GC1973@shell> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: lars-erik@lejonsson.com, rohc@ietf.org, Gonzalo Camarillo X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Tue, Dec 12, 2006 at 05:10:18PM -0000, Surtees, Abigail wrote: > Hi All, > > Here are my CDR comments on draft-ietf-rohc-sigcomp-sip-04.txt. I am > surprised to find that some of my comments from the first WGLC have > neither been addressed by email nor addressed in the updated document > (unless the email got missed?) > > Those that have been addressed, I've removed from this email. Those > that haven't are still here with a note. There are also some new > comments. > > The nits are in a separate section at the bottom. > > Best regards, > > Abbie > > Abstract and introduction: > "Any implementation of SigComp for use with SIP must confirm to this > document." > This sentence appears in the introduction too. What does this mean > without the must being a MUST (I realise it shouldn't be a MUST in the > abstract)? What does this mean for legacy implementations / > implementations conforming to other specifications e.g. 3GPP TS24.229? > [12/12/06] no response > > Introduction: > "Additionally, it must support ...[3485] and ...[3486]." > Again no standards language. Support for 3485 is specified further on > in the document (so I think isn't needed here) but support for 3486 > isn't so what does this mean for support of that RFC? > [12/12/06] no response > > Section 3.1: > I know the 'reason' part here but I think it should be written more > clearly (I think if you were new to it you'd have to read it several > times). Add another sentence to explain the example. Also, the SigComp > user guide refers to 'circular buffer' not 'ring buffer' so it may be > worth using 'circular buffer' here (ring buffer isn't used anywhere > else). > [12/12/06] no response > > Section 3.2: > The arguments now is: > * 'non-zero SMS removes uncertainty' - that's not strictly true because > the application can still refuse state creation. > * Stateless SIP implementations are unlikely to do SigComp - fair > enough > * 2K per compartment isn't a huge overhead for a stateful > implementation - ok > [12/12/06] Some text has been removed from this section which is fine, > but the first point still seems slightly disingenuous and could cause > confusion. > > Section 3.5: > Add a statement that because the static dictionary is mandatory it does > not need to be advertised (last point in this email discussion > http://www1.ietf.org/mail-archive/web/rohc/current/msg04463.html). > [12/12/06] no response > > Section 8.2 > Re: Use of IP address and port/connection for the remote application > identifier for legacy systems. If a client fails (losing all SIP state > including SigComp compartment) and re-REGISTERS with the same IP > address, how can the SIP stack tell that the old compartment is invalid. > I realise that the answer is probably that this circumstance is > relatively unlikely and that NACK would recover the situation, but I > think this should be made clearer. cristian: since I have seen this situation during testing I guess it is _not_ relatively unlikely at all. if we assume a config like: phone(sigcomp) ---- Proxy (P-CSCF w/ sigcomp) === IMS_cloud two distinct scenarios are possible here: 1. phone registers sucessfully with the proxy; phone reboots/restarts/or does whatever which produces a compartment loss. phone comes back online _within_ the lifetime of the compartment on the proxy (ip/port mapping). when the proxy will send a compressed message using the compartment (and assuming existant remote state) the phone will NACK it. 2. same thing but this time the compartment loss happens on the proxy. the proxy will NACK the first compression packet it sees from the phone after it is back online. bye now! cristian _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Dec 14 07:58:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqA9-0002mZ-Oc; Thu, 14 Dec 2006 07:58:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqA8-0002mU-T7 for rohc@ietf.org; Thu, 14 Dec 2006 07:58:12 -0500 Received: from mother.ludd.ltu.se ([130.240.16.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuqA7-0006KO-Ek for rohc@ietf.org; Thu, 14 Dec 2006 07:58:12 -0500 Received: from brother.ludd.ltu.se (callek@brother.ludd.ltu.se [130.240.16.78]) by mother.ludd.ltu.se (8.13.6+Sun/8.12.10) with ESMTP id kBECwAFS018984 for ; Thu, 14 Dec 2006 13:58:10 +0100 (MET) Date: Thu, 14 Dec 2006 13:58:10 +0100 (MET) From: Carl Knutsson To: rohc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [rohc] sdvl() in *-rohcv2-profiles-00.txt (fwd) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Kristofer, Ghyslain, rohcers, The svdl encoding method uses reference based lsb encoding. Not all of the encoding methods that use sdvl encoding needs to be lsb-encoded using the context as a reference. For example optional_stride uses sdvl. This may be okey in compressed packets, but I don't like the idea to compress the ts_stride using the context ts_stride as reference when decompressing a dynamic chain. 1. I suggest to always use zero as reference and a p-value of 0 for lsb-encoding the ts_stride. (the ts_stride is always positive?). I think we need to add a new encoding method for this. 2. My second proposal is to remove the lsb-encoding from the sdvl encoding method or to have an argument for p value (none, quarter, half, three quarters). To enable fields to be sdvl-encoded with different p values. 3. The p-values needs to be changed in the sdvl-encoding method. At least the compressed format lsb7 (field =:= lsb(14, 16383)), since it can only encode the field to smaller values than the current reference. Compressed formats lsb21 and lsb29 use the same p-value. If my suggestion 2 is not accepted I propose a change use 2^k/-1 for all p-values. field =:= lsb(7, 63) [ 7 ]; field =:= lsb(14, 8191) [ 14 ]; field =:= lsb(21, 1048575) [ 21 ]; field =:= lsb(29, 268435456) [ 29 ]; *-profiles-00.txt (old values): field =:= lsb(7, 63) [ 7 ]; field =:= lsb(14, 16383) [ 14 ]; field =:= lsb(21, 65535) [ 21 ]; field =:= lsb(29, 65535) [ 29 ]; rgds, /Carl Knutsson _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Dec 18 10:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKZg-0001sb-Nx; Mon, 18 Dec 2006 10:38:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKZf-0001sU-67 for rohc@ietf.org; Mon, 18 Dec 2006 10:38:43 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwKZa-0002NK-I9 for rohc@ietf.org; Mon, 18 Dec 2006 10:38:43 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F0A475AF; Mon, 18 Dec 2006 16:38:35 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 16:38:35 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Dec 2006 16:38:34 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sdvl() in *-rohcv2-profiles-00.txt Thread-Index: AccfebkecTufd/0JRFCUcwrX8Sdi3gDPoB6w From: "Kristofer Sandlund \(LU/EAB\)" To: "Carl Knutsson" , , "Ghyslain Pelletier \(LU/EAB\)" X-OriginalArrivalTime: 18 Dec 2006 15:38:35.0776 (UTC) FILETIME=[94B8F800:01C722BA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Subject: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Calle, you're right that there are bugs in the SDVL-related code in the draft, and you pointed out _some_ of them, but we're still at -00 of the draft, so that is to be expected :) - I agree that "stride" should not use LSB-encoding, it should use "pure LSB", i.e. only compress away leading zeros. Therefore, I have made a new encoding method for optional_stride (see below). - Regarding other SDVL-encoded values (SN, scaled TS, unscaled TS), these are used in co_common. And since we no longer have an IR-DYN packet in these profiles, the co_common needs to be able to send the full 32-bit values of the TS when used for repair. Therefore, the SDVL in v2 is no longer the exact same one as in the framework draft (and rfc3095), instead the 4th format is 28 bits long, and there is a 32-bit irregular coded format that has an 8-bit discriminator (so I change the name to sdvl_lsb). This applies to both forms of SDVL. I guess it could be possible to add extra discriminators at the top level to avoid having an 8-bit discriminator here, so I'll but that on my TODO-list and maybe I'll get back to it in the future. - The LSB offset (the so-called p-value) for SDVL is changed to be 50% of the interval. New suggested FN code for the draft (replacement for sdvl and optional_stride): sdvl_lsb(field_width) { UNCOMPRESSED { field [ field_width ]; } COMPRESSED lsb7 { discriminator =3D:=3D '0' [ 1 ]; field =3D:=3D lsb(7, 2^6 - 1) [ 7 ]; } COMPRESSED lsb14 { discriminator =3D:=3D '10' [ 2 ]; field =3D:=3D lsb(14, 2^13 - 1) [ 14 ]; } COMPRESSED lsb21 { discriminator =3D:=3D '110' [ 3 ]; field =3D:=3D lsb(21, 2^20 - 1) [ 21 ]; } COMPRESSED lsb28 { discriminator =3D:=3D '1110' [ 4 ]; field =3D:=3D lsb(28, 2^27 - 1) [ 28 ]; } COMPRESSED lsb32 { discriminator =3D:=3D '11111111' [ 8 ]; field =3D:=3D irregular(32) [ 32 ]; } } optional_stride(flag) { UNCOMPRESSED { field [ 32 ]; } COMPRESSED present_7bit { discriminator =3D:=3D '0' [ 1 ]; ENFORCE(flag =3D=3D 1); ENFORCE(field.UVALUE < 2^7); ENFORCE(field.CVALUE =3D=3D field.UVALUE); field [ 7 ]; } COMPRESSED present_14bit { discriminator =3D:=3D '10' [ 2 ]; ENFORCE(flag =3D=3D 1); ENFORCE(field.UVALUE < 2^14); ENFORCE(field.CVALUE =3D=3D field.UVALUE); field [ 14 ]; } COMPRESSED present_21bit { discriminator =3D:=3D '110' [ 3 ]; ENFORCE(flag =3D=3D 1); ENFORCE(field.UVALUE < 2^21); ENFORCE(field.CVALUE =3D=3D field.UVALUE); field [ 21 ]; } COMPRESSED present_28bit { discriminator =3D:=3D '1110' [ 4 ]; ENFORCE(flag =3D=3D 1); ENFORCE(field.UVALUE < 2^28); ENFORCE(field.CVALUE =3D=3D field.UVALUE); field [ 28 ]; } COMPRESSED present_32bit { discriminator =3D:=3D '11111111' [ 8 ]; ENFORCE(flag =3D=3D 1); ENFORCE(field.CVALUE =3D=3D field.UVALUE); field [ 32 ]; } =20 COMPRESSED not_present { field =3D:=3D static; ENFORCE(flag =3D=3D 0); } } And the latter encoding method is called from optional_stride, while the former one is called from optional_[un]scaled_timestamp and from where the sequence number is encoded in the co_common formats. Does this seem like the correct fix for this? /Kristofer Carl Knutsson wrote on den 14 december 2006 13:20 : > Kristofer, Ghyslain, rohcers, >=20 > The svdl encoding method uses reference based lsb encoding. Not all of > the encoding methods that use sdvl encoding needs to be > lsb-encoded using > the context as a reference. For example optional_stride uses > sdvl. This > may be okey in compressed packets, but I don't like the idea > to compress > the ts_stride using the context ts_stride as reference when > decompressing a dynamic chain. >=20 > 1. I suggest to always use zero as reference and a p-value of 0 for > lsb-encoding the ts_stride. (the ts_stride is always positive?). I > think we need to add a new encoding method for this. >=20 > 2. My second proposal is to remove the lsb-encoding from the sdvl > encoding method or to have an argument for p value (none, > quarter, half, > three quarters). To enable fields to be sdvl-encoded with different p > values.=20 >=20 > 3. The p-values needs to be changed in the sdvl-encoding > method. At least > the compressed format lsb7 (field =3D:=3D lsb(14, 16383)), since > it can only > encode the field to smaller values than the current > reference. Compressed > formats lsb21 and lsb29 use the same p-value. If my > suggestion 2 is not > accepted I propose a change use 2^k/-1 for all p-values. >=20 > field =3D:=3D lsb(7, 63) [ 7 ]; > field =3D:=3D lsb(14, 8191) [ 14 ]; > field =3D:=3D lsb(21, 1048575) [ 21 ]; > field =3D:=3D lsb(29, 268435456) [ 29 ]; >=20 > *-profiles-00.txt (old values): > field =3D:=3D lsb(7, 63) [ 7 ]; > field =3D:=3D lsb(14, 16383) [ 14 ]; > field =3D:=3D lsb(21, 65535) [ 21 ]; > field =3D:=3D lsb(29, 65535) [ 29 ]; >=20 > rgds, > /Carl Knutsson _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Dec 19 05:33:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwcHh-0000jk-JK; Tue, 19 Dec 2006 05:33:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwcHg-0000jf-IF for rohc@ietf.org; Tue, 19 Dec 2006 05:33:20 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwcHe-0006CO-F2 for rohc@ietf.org; Tue, 19 Dec 2006 05:33:20 -0500 Received: from [192.168.101.51] (c-ef7c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.239]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id kBJAoJYp009379 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Dec 2006 11:50:20 +0100 Message-ID: <4587C1BC.5050008@effnet.com> Date: Tue, 19 Dec 2006 11:41:00 +0100 From: Carl Knutsson User-Agent: Thunderbird 1.5.0.8 (X11/20061217) MIME-Version: 1.0 To: "Kristofer Sandlund (LU/EAB)" Subject: Re: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: Carl Knutsson , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Kristofer, comments inline.. Kristofer Sandlund (LU/EAB) wrote: > Hi Calle, > > you're right that there are bugs in the SDVL-related code in the draft, > and you pointed out _some_ of them, but we're still at -00 of the draft, > so that is to be expected :) > Agreed. > - I agree that "stride" should not use LSB-encoding, it should use "pure LSB", > i.e. only compress away leading zeros. Therefore, I have made a new encoding > method for optional_stride (see below). > - Regarding other SDVL-encoded values (SN, scaled TS, unscaled TS), > these are used in co_common. And since we no longer have an IR-DYN packet in these > profiles, the co_common needs to be able to send the full 32-bit values of > the TS when used for repair. Therefore, the SDVL in v2 is no longer the > exact same one as in the framework draft (and rfc3095), instead the 4th format > is 28 bits long, and there is a 32-bit irregular coded format that has > an 8-bit discriminator (so I change the name to sdvl_lsb). This applies to > both forms of SDVL. I guess it could be possible to add extra discriminators > at the top level to avoid having an 8-bit discriminator here, so I'll but > that on my TODO-list and maybe I'll get back to it in the future. Agreed. Since we don't have the IR-DYN packet any more, it is important to be able to TS in full in co_common. It is also important to be able to send for IPv4 identification and the sequence number in full too. Since the fields are sdvl encoded, I believe the comment of the co_common packet format should be changed to reflect this for the RTP-profiles. ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE, ip_id_indicator.UVALUE) [0, 8, 16, 24]; sequence_number =:= sdvl_lsb(sequence_number.ULENGTH) [8, 16, 24]; If the format fail when lsb is larger than the field? In that case maybe we should change the last compressed format in sdvl_lsb: From: COMPRESSED lsb32 { discriminator =:= '11111111' [ 8 ]; field =:= irregular(32) [ 32 ]; } To: COMPRESSED lsb32 { discriminator =:= '11111111' [ 8 ]; field =:= irregular(field_width) [ field_width ]; } > - The LSB offset (the so-called p-value) for SDVL is changed to be 50% > of the interval. > Agreed. > New suggested FN code for the draft (replacement for sdvl and > optional_stride): > > sdvl_lsb(field_width) > { > UNCOMPRESSED { > field [ field_width ]; > } > > COMPRESSED lsb7 { > discriminator =:= '0' [ 1 ]; > field =:= lsb(7, 2^6 - 1) [ 7 ]; > } > > COMPRESSED lsb14 { > discriminator =:= '10' [ 2 ]; > field =:= lsb(14, 2^13 - 1) [ 14 ]; > } > > COMPRESSED lsb21 { > discriminator =:= '110' [ 3 ]; > field =:= lsb(21, 2^20 - 1) [ 21 ]; > } > > COMPRESSED lsb28 { > discriminator =:= '1110' [ 4 ]; > field =:= lsb(28, 2^27 - 1) [ 28 ]; > } > > COMPRESSED lsb32 { > discriminator =:= '11111111' [ 8 ]; > field =:= irregular(32) [ 32 ]; > } > } > > optional_stride(flag) > { > UNCOMPRESSED { > field [ 32 ]; > } > > COMPRESSED present_7bit { > discriminator =:= '0' [ 1 ]; > ENFORCE(flag == 1); > ENFORCE(field.UVALUE < 2^7); > ENFORCE(field.CVALUE == field.UVALUE); > field [ 7 ]; > } > > COMPRESSED present_14bit { > discriminator =:= '10' [ 2 ]; > ENFORCE(flag == 1); > ENFORCE(field.UVALUE < 2^14); > ENFORCE(field.CVALUE == field.UVALUE); > field [ 14 ]; > } > > COMPRESSED present_21bit { > discriminator =:= '110' [ 3 ]; > ENFORCE(flag == 1); > ENFORCE(field.UVALUE < 2^21); > ENFORCE(field.CVALUE == field.UVALUE); > field [ 21 ]; > } > > COMPRESSED present_28bit { > discriminator =:= '1110' [ 4 ]; > ENFORCE(flag == 1); > ENFORCE(field.UVALUE < 2^28); > ENFORCE(field.CVALUE == field.UVALUE); > field [ 28 ]; > } > > COMPRESSED present_32bit { > discriminator =:= '11111111' [ 8 ]; > ENFORCE(flag == 1); > ENFORCE(field.CVALUE == field.UVALUE); > field [ 32 ]; > } > > COMPRESSED not_present { > field =:= static; > ENFORCE(flag == 0); > } > } > > And the latter encoding method is called from optional_stride, while the > former one is called from optional_[un]scaled_timestamp and from where the > sequence number is encoded in the co_common formats. > > Does this seem like the correct fix for this? Yes. (but maybe 28 bits is sufficient for the ts_stride). /Calle > > /Kristofer > > > Carl Knutsson wrote on den 14 december 2006 > 13:20 : > >> Kristofer, Ghyslain, rohcers, >> >> The svdl encoding method uses reference based lsb encoding. Not all of >> the encoding methods that use sdvl encoding needs to be >> lsb-encoded using >> the context as a reference. For example optional_stride uses >> sdvl. This >> may be okey in compressed packets, but I don't like the idea >> to compress >> the ts_stride using the context ts_stride as reference when >> decompressing a dynamic chain. >> >> 1. I suggest to always use zero as reference and a p-value of 0 for >> lsb-encoding the ts_stride. (the ts_stride is always positive?). I >> think we need to add a new encoding method for this. >> >> 2. My second proposal is to remove the lsb-encoding from the sdvl >> encoding method or to have an argument for p value (none, >> quarter, half, >> three quarters). To enable fields to be sdvl-encoded with different p >> values. >> >> 3. The p-values needs to be changed in the sdvl-encoding >> method. At least >> the compressed format lsb7 (field =:= lsb(14, 16383)), since >> it can only >> encode the field to smaller values than the current >> reference. Compressed >> formats lsb21 and lsb29 use the same p-value. If my >> suggestion 2 is not >> accepted I propose a change use 2^k/-1 for all p-values. >> >> field =:= lsb(7, 63) [ 7 ]; >> field =:= lsb(14, 8191) [ 14 ]; >> field =:= lsb(21, 1048575) [ 21 ]; >> field =:= lsb(29, 268435456) [ 29 ]; >> >> *-profiles-00.txt (old values): >> field =:= lsb(7, 63) [ 7 ]; >> field =:= lsb(14, 16383) [ 14 ]; >> field =:= lsb(21, 65535) [ 21 ]; >> field =:= lsb(29, 65535) [ 29 ]; >> >> rgds, >> /Carl Knutsson > > _______________________________________________ > 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 rohc-bounces@ietf.org Tue Dec 19 05:52:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwcaC-0002jG-Lx; Tue, 19 Dec 2006 05:52:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwcaC-0002io-2x for rohc@ietf.org; Tue, 19 Dec 2006 05:52:28 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwca8-0001B5-Fi for rohc@ietf.org; Tue, 19 Dec 2006 05:52:28 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AA0DD1147; Tue, 19 Dec 2006 11:52:19 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 11:52:19 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt Date: Tue, 19 Dec 2006 11:52:18 +0100 Message-ID: In-Reply-To: <4587C1BC.5050008@effnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt Thread-Index: AccjWK9hwwRGDKIGRMSVc3pje082ZgAAWj5w From: "Kristofer Sandlund \(LU/EAB\)" To: "Carl Knutsson" X-OriginalArrivalTime: 19 Dec 2006 10:52:19.0519 (UTC) FILETIME=[C149E4F0:01C7235B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Carl Knutsson , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Calle, some comments inline. Carl Knutsson wrote on den 19 december 2006 11:41 : >=20 > Since we don't have the IR-DYN packet any more, it is > important to be able to TS in > full in co_common. It is also important to be able to send > for IPv4 identification > and the sequence number in full too. Since the fields are > sdvl encoded, I believe the > comment of the co_common packet format should be changed to > reflect this for the > RTP-profiles. >=20 > ip_id =3D:=3D optional_ip_id_lsb(ip_id_behavior.UVALUE, > ip_id_indicator.UVALUE) [0, 8, 16, > 24]; sequence_number =3D:=3D sdvl_lsb(sequence_number.ULENGTH) [8, = 16, > 24];=20 I don't think the IP-ID is relevant here, it does not use SDVL, and already provides an "Uncompressed format", but I agree on the SN, see below. >=20 >=20 > If the format fail when lsb is larger than the field? In that > case maybe we should > change the last compressed format in sdvl_lsb: >=20 > From: > COMPRESSED lsb32 { > discriminator =3D:=3D '11111111' [ 8 ]; > field =3D:=3D irregular(32) [ 32 ]; > } >=20 > To: > COMPRESSED lsb32 { > discriminator =3D:=3D '11111111' [ 8 ]; > field =3D:=3D irregular(field_width) [ field_width ]; } ACK. I will fix this, I had forgotten that this was used for 16-bit fields as well. >>=20 >> Does this seem like the correct fix for this? >=20 > Yes. (but maybe 28 bits is sufficient for the ts_stride). Well, I'd guess that 14 or at most 21 should be enough in any realistic case, but I don't see an extra cost in having a 32-bit format to catch any "stupid" case, since the implementation cost for that is minimal. /Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Dec 21 05:09:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxKrM-0005s3-V5; Thu, 21 Dec 2006 05:09:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxKrL-0005rZ-RY for rohc@ietf.org; Thu, 21 Dec 2006 05:09:07 -0500 Received: from [194.237.235.30] (helo=effnet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GxKrJ-0003IB-9u for rohc@ietf.org; Thu, 21 Dec 2006 05:09:07 -0500 Received: from [192.168.101.51] (c-ef7c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.239]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id kBLAQBYp027372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Dec 2006 11:26:12 +0100 Message-ID: <458A5F34.3050705@effnet.com> Date: Thu, 21 Dec 2006 11:17:24 +0100 From: Carl Knutsson User-Agent: Thunderbird 1.5.0.8 (X11/20061217) MIME-Version: 1.0 To: "Kristofer Sandlund (LU/EAB)" Subject: Re: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Carl Knutsson , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Kristofer, I agree on all changes... Now we will be to send TS, TS_STRIDE and SN can be sent in full in co_com= mon. One question, can a 16-bit field be encoded with the formats lsb21 and ls= b24 in encoding method sdvl? Or will the two formats fail if the lsb is larger t= han encoded field? What happens when a decompression results in larger number= than can be described in the original field? I couldn't find the answer in the def= inition of lsb encoding method. God Jul och Gott Nytt =C5r, /Calle Kristofer Sandlund (LU/EAB) wrote: > Hi Calle, >=20 > some comments inline. >=20 > Carl Knutsson wrote on den 19 decembe= r > 2006 11:41 : >=20 > >=20 >> Since we don't have the IR-DYN packet any more, it is >> important to be able to TS in >> full in co_common. It is also important to be able to send >> for IPv4 identification >> and the sequence number in full too. Since the fields are >> sdvl encoded, I believe the >> comment of the co_common packet format should be changed to >> reflect this for the >> RTP-profiles. >> >> ip_id =3D:=3D optional_ip_id_lsb(ip_id_behavior.UVALUE, >> ip_id_indicator.UVALUE) [0, 8, 16, >> 24]; sequence_number =3D:=3D sdvl_lsb(sequence_number.ULENGTH) [8, = 16, >> 24];=20 >=20 > I don't think the IP-ID is relevant here, it does not use SDVL, and > already provides an "Uncompressed format", but I agree on the SN, see > below. My mistake... >=20 >> >> If the format fail when lsb is larger than the field? In that >> case maybe we should >> change the last compressed format in sdvl_lsb: >> >> From: >> COMPRESSED lsb32 { >> discriminator =3D:=3D '11111111' [ 8 ]; >> field =3D:=3D irregular(32) [ 32 ]; >> } >> >> To: >> COMPRESSED lsb32 { >> discriminator =3D:=3D '11111111' [ 8 ]; >> field =3D:=3D irregular(field_width) [ field_width ]; } >=20 > ACK. I will fix this, I had forgotten that this was used for 16-bit > fields > as well. > Good! > >=20 >>> Does this seem like the correct fix for this? >> Yes. (but maybe 28 bits is sufficient for the ts_stride). >=20 > Well, I'd guess that 14 or at most 21 should be enough in any realistic= > case, > but I don't see an extra cost in having a 32-bit format to catch any > "stupid" case, since the implementation cost for that is minimal. >=20 I agree, it is foolproof and the implementation cost is minimal. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Dec 21 07:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxN1U-0002u8-9a; Thu, 21 Dec 2006 07:27:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxN1S-0002u1-Nl for rohc@ietf.org; Thu, 21 Dec 2006 07:27:42 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxN1P-0007za-9d for rohc@ietf.org; Thu, 21 Dec 2006 07:27:42 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B003D4F0086; Thu, 21 Dec 2006 13:27:36 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 13:27:36 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt Date: Thu, 21 Dec 2006 13:27:35 +0100 Message-ID: In-Reply-To: <458A5F34.3050705@effnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt Thread-Index: Acck56IDOFxdUCnERUiYm0QjFoHB/QADqW2Q From: "Kristofer Sandlund \(LU/EAB\)" To: "Carl Knutsson" , "Finking, Robert" X-OriginalArrivalTime: 21 Dec 2006 12:27:36.0490 (UTC) FILETIME=[65B1F0A0:01C724FB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Carl Knutsson , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Carl Knutsson wrote on den 21 december 2006 11:17 : > One question, can a 16-bit field be encoded with the formats lsb21 > and lsb24 in encoding method sdvl? Or will the two formats fail if > the lsb is larger than encoded field? What happens when a > decompression results in larger number than can be described in the > original field? I couldn't find the=20 > answer in the definition > of lsb encoding method. >=20 Calle, my view is that (as in 3095) it should be legal that "k" can be larger=20 than the uncompressed field length, but not that the value in the compressed field can be larger than the highest possible uncompressed value.=20 Or better said: - CLENGTH > ULENGTH =3D> ok (as long as MSBs are zero-padding) - CVALUE >=3D 2^ULENGTH =3D> impossible at the compressor, discard at decompressor But, I agree that after reading the definition in the FN draft, I'm not sure how the first of these two conditions is to be interpreted. Raffles and/or Ghyslain, do you know how to interpret this from the FN spec?=20 Should we add some clarification during AUTH-48 or is this covered by the current FN spec? /Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Dec 21 08:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxO6a-00088d-IF; Thu, 21 Dec 2006 08:37:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxO6Z-00088P-EA for rohc@ietf.org; Thu, 21 Dec 2006 08:37:03 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxO61-0008US-9V for rohc@ietf.org; Thu, 21 Dec 2006 08:37:03 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id kBLDaMIB009140; Thu, 21 Dec 2006 14:36:22 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <94B4E43A-D988-4C05-B0E2-14B14A21692D@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt Date: Thu, 21 Dec 2006 14:36:18 +0100 To: "Kristofer Sandlund \(LU/EAB\)" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rohc@ietf.org, "Finking, Robert" , "Ghyslain Pelletier \(LU/EAB\)" , Carl Knutsson , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Dec 21 2006, at 13:27, Kristofer Sandlund ((LU/EAB)) wrote: > Or better said: > - CLENGTH > ULENGTH => ok (as long as MSBs are zero-padding) > - CVALUE >= 2^ULENGTH => impossible at the compressor, discard at > decompressor > > But, I agree that after reading the definition in the FN draft, I'm > not > sure > how the first of these two conditions is to be interpreted. Well, that's a reason why the library encoding methods should be formally specified as far as possible. Unfortunately, we don't have a way to talk about the context and the resulting interpretation intervals in FN: this is why static and lsb are not formally specified. The text says that: 1 The parameter "num_lsbs_param" binds with the "CLENGTH" attribute, 2 The value of the "ULENGTH" can be derived from the information stored in the context. 3 the "UVALUE" attribute binds to the value within the interval whose least significant bits match the "CVALUE" attribute. which to me seems consistent with your interpretation above, even if the term "least significant bits" is a bit confusing. 1 and 3 leave all the freedom that is needed. Re 2: CVALUE and UVALUE have the interesting property that they bind to bit strings in a modulo/zero extending fashion [1]. So, during decompression, excess bits in the UVALUE will be discarded at the decompressor. If there are excess leading zero bits in the field(s) that contribute to the CVALUE, this does not matter, as the FN is in terms of positive integers and not in terms of bit strings. If they are non-zero, the CVALUE will be out of bounds and the match 3 talks about won't happen (which I would read as "the format fails"). I'm not sure this will be the last observation about a boundary case in the FN. Instead of tweaking the FN document until that no longer happens, I'd rather do what has been successfully done in ROHC before: keep running User Guide/Implementor Guide documents (as I-Ds first and as RFCs a couple of years later) that document the common view about the boundary cases. Gruesse, Carsten [1] 3.2.1, last para: The bit string is the binary representation of the value attribute of the field, modulo "2^length", where "length" is the length attribute of the field. See also 4.4.2. I'm not a big fan of this implicit conversion approach, see my review comments, but this is the way it is, and in this case it happens to help. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Dec 21 09:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOUH-0004Ix-51; Thu, 21 Dec 2006 09:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOUG-0004Ir-Ha for rohc@ietf.org; Thu, 21 Dec 2006 09:01:32 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxOUE-0005Ll-2i for rohc@ietf.org; Thu, 21 Dec 2006 09:01:32 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id kBLE0oZ0029350; Thu, 21 Dec 2006 14:00:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Dec 2006 14:00:50 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FN example Thread-Index: AcclCGvt7dE3z2DHT/yRKWVaZ6rjRA== From: "Finking, Robert" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: robert.finking@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Ghyslain Pelletier \(LU/EAB\)" Subject: [rohc] FN example X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org I had a few minutes to spare prior to a meeting, and started compiling an example of the ROHC formal notation, but have run out of time... if anybody wants to help finish if off you're most welcome to contribute. Apologies for any errors! Christmas greetings Raffles pear_tree { UNCOMPRESSED { partridge [1]; } } first_day { UNCOMPRESSED { pear_tree [1]; } } second_day { UNCOMPRESSED { turtle_doves [2]; } } twelve_days { UNCOMPRESSED { day_number [4]; true_loves_gift [VARIABLE]; } INTITIAL { day_number =3D:=3D uncompressed_value(4, 1); true_loves_gift =3D:=3D pear_tree; } } _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc