Subject: Re: [6lowpan] HC-01 ready to advance to WG document?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Aug 2008 12:29:37 +0200

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-masked] [mailto:[email-masked]] 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-masked]
>https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Chol Su Kang" <[email-masked]>
Date: Wed, 27 Aug 2008 10:22:31 -0700

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.
   Figure 1. It shows "Uncompressed fields follow" after LOWPAN_IPHC.
             But, Figure 5 shows differently.

Sec 2.1 pg 5
    "Next Hop" for NH bit?
    Next Hop and Next Header usages are confusing.

Sec 2.1 pg 5
    SAC(?) for Source Address Mode

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? 

    What is the reason for limiting the uni-cast address range
     to 15-bit range?

Sec 2.3 pg 8
    What is "well-known mapping"? Is it referring well-known multicast
     addresses?

Sec 2.4
    Is this intended Range order, i.e. Range 0, 2, 1, 3, 4?

Sec 3
    Figure 5:
       "In-line IP Fields"? Is this "In-line IPv6 header fields"?

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.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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:

Pascal

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 27 Aug 2008 10:36:37 -0700

Thanks for the comments. See below:

>             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.

>             But, Figure 5 shows differently.

Figures 1 and 5 agree with each other. Uncompressed fields refer to  
those IP fields that are carried inline.

>    Next Hop and Next Header usages are confusing.

Yes, this is a mistake and was already pointed out a few times on the  
list.

>    SAC(?) for Source Address Mode

Another typo.

>    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

See RFC 4944.

>    What is "well-known mapping"? Is it referring well-known multicast

Refers to the table labeled as "9-bit to 112-bit Group ID Mapping"

>    Is this intended Range order, i.e. Range 0, 2, 1, 3, 4?

Typo again.

>       "In-line IP Fields"? Is this "In-line IPv6 header fields"?

Yes. I'm not sure I understand the difference.

>    However, Sec 2.4 shows the reservation/usage of three additional

They are already reserved. See RFC 4944.

--
Jonathan Hui

---

From: "Laurent Toutain" <[email-masked]>
Date: Fri, 29 Aug 2008 10:24:41 +0200

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