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
