Hi Jonathan Maybe a good reason to stick to the current format and change the misleading wording around it, what do you think? In any case, I'm all for starting 4944bis and recoverable frags today, though.
Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: vendredi 10 octobre 2008 18:02 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Geoff Mulligan; [email protected] >Subject: Re: [6lowpan] rfc4944, hc and dispatchs > > >Hi Pascal: > >I'm for pushing HC through as quickly as possible. We are already >behind according to the charter text. > >The one dependency I see is the structure of the dispatch byte. If we >choose a dispatch value(s) that is compatible with RFC 4944, then we >are fine, I think. But if we want extra bits by changing the layout of >the dispatch values/identifiers for Frag/Mesh headers (as both I and >Julien have proposed) then this creates a dependency on defining that >new dispatch assignment scheme. > >-- >Jonathan Hui > > >On Oct 10, 2008, at 8:51 AM, Pascal Thubert (pthubert) wrote: > >> I'm all with you, Jonathan, as long as that does not delay HC. >> >> This is why I proposed a structured set of document that leaves HC >> with >> its current scope as opposed to making it a full revision of 4944. >> Makes >> sense? >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>> Sent: jeudi 9 octobre 2008 21:17 >>> To: Pascal Thubert (pthubert) >>> Cc: Carsten Bormann; Geoff Mulligan; [email protected] >>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>> >>> >>> In general, I'm in support of Pascal's proposal. Cleaning up the >>> format to use a stacked-header format was just one of the items and >>> there were many other things we wanted to fix before pushing out RFC >>> 4944. But we were far too late to the game in doing a complete >>> overhaul of the doc. I think *now* is the time to make improvements >>> to >>> RFC 4944. >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On Oct 9, 2008, at 10:41 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi Carsten: >>>> >>>> Some implementations and dependant standards would require a >>>> timeline >>>> for this. Leaving it up in the air does not help our users do their >>>> product planning? >>>> >>>> Considering the attention and the work on the new LOWPAN_IPHC, I >>>> expect >>>> that we'll be ready for WGLC after 2/3 more respins. That could be >>>> achieved by Minneapolis time if we can rally all interested parties >> to >>>> comment on the existing published spec. So could you chairs please: >>>> >>>>>>>>>>>>>> propose a time line to the WG along those lines >> <<<<<<<<<<<< >>>>>>>>>>>>>> raise WG attention on this work? >> <<<<<<<<<<<< >>>> >>>> Also by or at Minneapolis, my sensation is that we should not only >>>> discuss the terms of deprecating RFC 4944 HC but also consider the >>>> spec >>>> as a whole: >>>> >>>> - Mesh Header is a layer violation. I talked to implementers and >> their >>>> message is that they do not use it because it's never exactely what >>>> that >>>> specific radio needs; so they end up with their own mesh header >> anyway >>>> and will not duplicate things for the sake of comliance. Instead we >>>> might need a Routing header, pretty useful for source routing in >> route >>>> over. >>>> >>>> - Fragments are not recovered individually. We have enough >>>> experience to >>>> know where that leads should a 6LoWPAN network experience either >>>> high >>>> load or high BER. We have a draft on the works to deprecate that >>>> with >>>> recoverable fragments. >>>> >>>> - The Current HC WG doc covers all the compression cases in RFC >>>> 4944, >>>> bigger and badder. >>>> >>>> So what's left? >>>> >>>> My proposal is to start a 4944bis that would focus on the addressing >>>> architecture, would be the placeholder to control the dispatch type >>>> but >>>> would defer to the drafts/RFCs that actually detail the operation of >>>> each dispatch type. >>>> >>>> What do you think? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>>> Behalf Of Carsten Bormann >>>>> Sent: jeudi 9 octobre 2008 16:43 >>>>> To: Julien Abeille (jabeille) >>>>> Cc: Carsten Bormann; [email protected] >>>>> Subject: Re: [6lowpan] rfc4944, hc and dispatchs >>>>> >>>>> On Oct 09 2008, at 16:09, Julien Abeille (jabeille) wrote: >>>>> >>>>>> - does it officialy deprecate the old header compression scheme? >>>>> >>>>> My impression of the mailing list consensus is that this is what >>>>> the >>>>> WG wants to achieve. >>>>> At the time this was discussed, I cautioned that it is premature to >>>>> decide on replacing something existing with known flaws with >>>>> something >>>>> not yet quite cooked (and, hence, with unknown flaws). >>>>> So I expect we'll ultimately decide this question at the time HC >>>>> and >>>>> the related specs come up for WGLC. >>>>> Clearly, the stated intention of many WG members is to make this >>>>> happen, as it would be wasteful to support two HC schemes in tiny >>>>> implementations. >>>>> >>>>> Gruesse, Carsten >>>>> >>>>> _______________________________________________ >>>>> 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
