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
