Hi, I'm also in favor of working on that document, but some details are not clear to me.
- Does this compression scheme is suppose to replace RFC 4944 ? or does it mean that sensors will have to implement both ? - SAC/DAC usage is not clear for me. draft does not specify it, but does it mean that RA will carry the prefix and the context number and the sensor will just put the DAC/SAC bits are reference ? -> For DAC, does it take into account outside prefixes ? Laurent On Wed, Aug 27, 2008 at 19:36, Jonathan Hui <[EMAIL PROTECTED]> wrote: > > Thanks for the comments. See below: > > On Aug 27, 2008, at 10:22 AM, Chol Su Kang wrote: > > Here are my comments on draft-hui-6lowpan-hc-01.txt. > > > > Figure 1. LOWPAN_IPHC is shown as 1 octet. > > But the text describes it is a two-octets field. > > That is a mistake in the document. I didn't have a chance to carefully > update everything, as you have pointed out in the following comments. > > > Figure 1. It shows "Uncompressed fields follow" after LOWPAN_IPHC. > > But, Figure 5 shows differently. > > Figures 1 and 5 agree with each other. Uncompressed fields refer to > those IP fields that are carried inline. > > > Sec 2.1 pg 5 > > "Next Hop" for NH bit? > > Next Hop and Next Header usages are confusing. > > Yes, this is a mistake and was already pointed out a few times on the > list. > > > Sec 2.1 pg 5 > > SAC(?) for Source Address Mode > > Another typo. > > > Sec 2.2 pg 6 > > Is this ID requiring upper-layer integrity checks? > > Are such checks used to detect out of sync, or prevent out of sync? > > Can you provide a reference for pseudo-header checksum? > > From RFC 2460: "when UDP packets are originated by an IPv6 node, the > UDP checksum is not optional" > > > What is the reason for limiting the uni-cast address range > > to 15-bit range? > > See RFC 4944. > > > Sec 2.3 pg 8 > > What is "well-known mapping"? Is it referring well-known multicast > > addresses? > > Refers to the table labeled as "9-bit to 112-bit Group ID Mapping" > > > Sec 2.4 > > Is this intended Range order, i.e. Range 0, 2, 1, 3, 4? > > Typo again. > > > Sec 3 > > Figure 5: > > "In-line IP Fields"? Is this "In-line IPv6 header fields"? > > Yes. I'm not sure I understand the difference. > > > Sec 4 > > It states that another short address range is reserved in this > > document. > > However, Sec 2.4 shows the reservation/usage of three additional > > ranges. > > They are already reserved. See RFC 4944. > > -- > Jonathan Hui > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Pascal Thubert (pthubert) > > Sent: Tuesday, August 26, 2008 3:30 AM > > To: Carsten Bormann > > Cc: 6lowpan > > Subject: Re: [6lowpan] HC-01 ready to advance to WG document? > > > > Hi Carsten: > > > > Resending your call. There were a number of votes in favor, so I > > suggest > > that those against should speak now or forever hold their peace. > > > > Pascal > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Carsten Bormann > >> Sent: jeudi 31 juillet 2008 18:56 > >> To: 6lowpan > >> Cc: Carsten Bormann > >> Subject: [6lowpan] HC-01 ready to advance to WG document? > >> > >> Lowpanners, > >> > >> we were so pressed for time at the WG meeting that the chairs forgot > >> to ask "the question": > >> > >> Do we believe that draft-hui-6lowpan-hc-01.txt is now ready to become > >> the WG document for charter item 2, "6LoWPAN Improved Header > >> Compression"? > >> > >> Note that moving the document to WG document status does not mean we > >> have to agree with every detail in there. > >> We just need to agree that it is a good basis for the remaining work. > >> (Moving to WG document status also means that all further changes > >> should be the result of work in the WG, so it also removes a little > >> flexibility that the authors of an individual draft have.) > >> I believe there was tacit agreement in the room in Dublin, and I now > >> want to make the agreement explicit on the mailing list. > >> > >> As the document has been pretty non-contentious, I'm looking forward > >> to comments until Monday 1800 UTC. > >> If there are no objections by this time, I'll ask Jonathan to > >> resubmit > >> the draft as a WG document (possibly with the changes resulting from > >> this meeting). > >> > >> 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 > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > >
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
