On Feb 26, 2010, at 12:32 , Anders Brandt wrote: > Hi > > I support the proposal of a simple correction to fragmentation: > > * new dispatch codes for generic datagrams - > fragments may carry compressed or uncompressed; it does not matter. > > * reject fragments of old type in the transition period > > * strongly deprecate old dispatch code by 2011
This makes sense. Although I don't see a reason for the transition period. Why not just depreciate the old dispatch in the HC draft as it updates RFC4944. Zach > > Cheers, > Anders > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Daniel Gavelle >> Sent: Thursday, February 25, 2010 15:18 >> To: [email protected] >> Subject: Re: [6lowpan] WGLC for 6lowpan HC draft >> >> On the subject of forward and backward compatibility, I think >> the dispatch codes for fragmentation (FRAG1, FRAGN) should be >> changed to values that are currently reserved if we move to >> sending the datagram_size and datagram_offset as compressed >> and uncompressed values. >> This will mean that during the transition period, it will >> be much easier to sort out interoperability problems where >> some nodes use compressed values and some nodes are running >> older code using uncompressed values. >> >> I don't think the new nodes should support both compressed >> and uncompressed offsets / sizes but should simply reject >> fragments that don't have the dispatch codes they are expecting. >> >> The existing dispatch codes would not be lost forever as they >> could be strongly deprecated and then recycled in a future RFC. >> >> Daniel. >> >> >> >> Jonathan Hui wrote: >>> >>> It would be helpful to know what people's expectations are >> relative to >>> what this specific draft should include relative to an acceptable >>> timeline of getting a document out. Few comments: >>> >>> - The WG currently does not have a proposal for TCP header >>> compression, let alone one that we have built some consensus around. >>> - The RPL protocol mechanisms and headers are still in flux. It is >>> difficult to propose a concrete way of compressing them without >>> knowing what they will look like. For example, within >> ROLL, we will >>> be proposing ways to "pack" lists of addresses such that common >>> prefixes are only carried once within the datagram. >>> - The general 6lowpan-hc format is generic enough to be >> used on top of >>> other fragmentation mechanisms and/or frame sizes. Do we >> really want >>> to limit its capabilities to a particular fragmentation and >> frame size? >>> >>> There always seems to be a tension between splitting functionality >>> across different drafts vs. delaying the current draft to >> "sneak" in >>> new functionality. I'm all for sneaking in fixes to RFC >> 4944 (i.e. >>> simple changes to fragmentation) or additional functionality for >>> expediency if we can realize that expedience. But waiting until we >>> design a TCP header compression mechanism that we can build >> consensus >>> around probably isn't the best approach, in my opinion, and >> should be >>> left to a separate draft. >>> >>> So what do others think? >>> >>> (I will start a new thread specifically on fragmentation + >>> forward-compatibility so that we drive towards closure on that >>> specific issue). >>> >>> -- >>> Jonathan Hui >>> >>> On Feb 24, 2010, at 10:55 PM, Robert Cragie wrote: >>> >>>> Hi Geoff, >>>> >>>> I concur with Joseph's statements and thus do not support >> forwarding >>>> the draft to IESG yet. >>>> >>>> Robert >>>> Robert Cragie (Pacific Gas & Electric) >>>> >>>> Gridmerge Ltd. >>>> 89 Greenfield Crescent, >>>> Wakefield, WF4 4WA, UK >>>> +44 (0) 1924 910888 >>>> http://www.gridmerge.com >>>> >>>> >>>> >>>> Reddy, Joseph wrote: >>>>> >>>>> >>>>> Hi Geoff, >>>>> >>>>> I do not support forwarding this doc to IESG yet. I would >> like the >>>>> following issues addressed >>>>> >>>>> ** Investigate possible TCP header compression scheme >>>>> >>>>> ** Explain strategy for compressing RPL headers ( I >> understand this >>>>> could be done in the ROLL group, but I have not seen a definite >>>>> statement either way ) >>>>> >>>>> ** Resolve the "forward compatability" issue ( ideally, while >>>>> maintaining backwards-comptability ) >>>>> >>>>> >>>>> -Regards, Joseph >>>>> >>>>> >>>>> >>>>> >> -------------------------------------------------------------------- >>>>> -- >>>>> >>>>> Message: 1 >>>>> Date: Sat, 13 Feb 2010 00:56:31 -0700 >>>>> From: Geoff Mulligan <[email protected]> >>>>> Subject: [6lowpan] WGLC for 6lowpan HC draft >>>>> To: 6lowpan <[email protected]> >>>>> Message-ID: <1266047791.3643.48.ca...@dellx1> >>>>> Content-Type: text/plain >>>>> >>>>> Folks, >>>>> I realized that I have made a huge slip-up. The HC draft has >>>>> languished for the past few months. >>>>> At the meeting in Hiroshima we said that we would last call this >>>>> draft, but I failed to send out the actual last call. So... >>>>> >>>>> This note formally starts the WG Last Call for comments on >>>>> draft-ietf-6lowpan-hc-06, "Compression Format for IPv6 >> Datagrams in >>>>> 6LoWPAN Networks". >>>>> >>>>> The document can be found at: >>>>> http://www.ietf.org/id/draft-ietf-6lowpan-hc-06.txt >>>>> >>>>> The document is intended to be submitted by this Working Group to >>>>> the IESG for publication as a Standards Track document. >>>>> >>>>> Please review the document carefully (one last time), and >> send your >>>>> comments to the 6lowpan list. Please also indicate in >> your response >>>>> whether or not you think this document is ready to go to the IESG. >>>>> >>>>> Because of my gaffe this Last Call will end Wednesday February 24 >>>>> 2010 at 2359 UTC. >>>>> >>>>> Thanks, >>>>> Geoff >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ************************************** >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> >> -- >> __________________________________________________ >> Daniel Gavelle, Software Engineer >> Tel: +44 114 281 2655 >> Fax: +44 114 281 2951 >> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg >> No: 3191371 Registered In England http://www.jennic.com >> __________________________________________________ >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan >> > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
