Subject: [6lo] Draft wording for liaison statement

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Jul 2015 12:34:04 +0200

We held a hum regarding the content of a liaison statement to send to ITU-T SG15 in response to the recent liaison statement from SG15.  The WG has been asked to respond by Friday.  Included below is a rough transcription of the words I used in the hum yesterday.  Scott, Samita, Gabriel, James and I will write up the final liaison statement for transmission to SG-15 on Friday.  If you have any comments on the *content* (not the specific language, which we will likely rewrite) of the text, please comment to the list by Thursday.

-----

The IETF will not change the definitions of the code points specified in RFC 4944 and RFC 6282, as published in IANA registry "IPv6 Low Power Personal Area Network Parameters" <http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml>, in such a way as to affect the ITU-T G.9903 and G.9905 specifications.

The IETF 6lo working group offers to collaborate with ITU-T SG15 in establishing a new registry for the code points following the ESC dispatch code.  This new registry will be populated at the time of its establishment with the Command ID values as defined in G.9903 and G.9905.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2015 16:47:50 +0200

Le 21/07/2015 12:34, Ralph Droms a écrit :
> We held a hum regarding the content of a liaison statement to send to
> ITU-T SG15 in response to the recent liaison statement from SG15.  The
> WG has been asked to respond by Friday.  Included below is a rough
> transcription of the words I used in the hum yesterday.  Scott, Samita,
> Gabriel, James and I will write up the final liaison statement for
> transmission to SG-15 on Friday.  If you have any comments on the
> *content* (not the specific language, which we will likely rewrite) of
> the text, please comment to the list by Thursday.
>
> -----
>
> The IETF will not change the definitions of the code points specified in
> RFC 4944 and RFC 6282, as published in IANA registry "IPv6 Low Power
> Personal Area Network Parameters"
> <http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml>,
> in such a way as to affect the ITU-T G.9903 and G.9905 specifications.

I agree, it is neutral enough.

But I dont understand why is IANA reserving anything below the IP layer?

Provided there is an explanation for it that I missed (sorry), I dont 
understand why IANA is not reserving something for the IPv6 Base Header 
altogether - a simple plain IPv6 Base Header uncompressed.?

> The IETF 6lo working group offers to collaborate with ITU-T SG15 in
> establishing a new registry for the code points following the ESC
> dispatch code.  This new registry will be populated at the time of its
> establishment with the Command ID values as defined in G.9903 and G.9905.

I can agree to it.  But I still need to understand why IANA needs to 
control this.

Alex

>
>
>
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 21 Jul 2015 12:54:46 -0400

On Tue, Jul 21, 2015 at 10:47 AM, Alexandru Petrescu <
[email-masked]> wrote:

>> <
>> http://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml
>> >,
> <kel>
Isn't that what the 01 000001 Dispatch Value bit pattern is for?  Or are you
talking about another name space?

Kerry
</kel>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 10:35:12 +0200

Le 21/07/2015 18:54, Kerry Lynn a écrit :
> On Tue, Jul 21, 2015 at 10:47 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>
>
> We held a hum regarding the content of a liaison statement to send
> to ITU-T SG15 in response to the recent liaison statement from SG15.
> The WG has been asked to respond by Friday.  Included below is a
> rough transcription of the words I used in the hum yesterday.
> Scott, Samita, Gabriel, James and I will write up the final liaison
> statement for transmission to SG-15 on Friday.  If you have any
> comments on the *content* (not the specific language, which we will
> likely rewrite) of the text, please comment to the list by Thursday.
>
> -----
>
> The IETF will not change the definitions of the code points specified
> in RFC 4944 and RFC 6282, as published in IANA registry "IPv6 Low
> Power Personal Area Network Parameters"
in such a way as to affect the ITU-T G.9903 and G.9905
> specifications.
> understand why IANA is not reserving something for the IPv6 Base
> Header altogether - a simple plain IPv6 Base Header uncompressed.?
>
> <kel> Isn't that what the 01 000001 Dispatch Value bit pattern is
> for?  Or are you talking about another name space?
>
> Kerry </kel>

Is it the "IPv6 - uncompressed IPv6 Addresses"?  If yes, its textual
description looks confusing?  It should, in my reading, rather say "IPv6
Header defined in RFC2460".

Additionally, there is another one appearing later called:
"IPv6 Header RFC6282".  IMHO that should be "IPv6 Header RFC2460".

And I dont understand why we have two values.

Looks as if we could have a packet DispatchType=LOWPAN, followed by a
LOWPAN_NHC=IPv6Header and then the IPv6Header.

With the risk of disturbing with statements, but avoiding to make too
many question marks:

This seems against the goal of _reducing_ headers.

Alex

> dispatch code.  This new registry will be populated at the time of
> its establishment with the Command ID values as defined in G.9903 and
> G.9905.
>
>
> _______________________________________________ 6lo mailing list
> [email-masked] <mailto:[email-masked]>
> _______________________________________________ 6lo mailing list
> [email-masked] <mailto:[email-masked]>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 22 Jul 2015 10:12:56 +0100

Alexandru - I don't understand what your issue is.

Page 6 shows:

   A LoWPAN encapsulated IPv6 datagram:

      +---------------+-------------+---------+
      | IPv6 Dispatch | IPv6 Header | Payload |
      +---------------+-------------+---------+

That is pretty clear to me - it says "IPv6 Header".

Figure 2 perhaps could have been worded better but as the document is about
compressing IPv6 addresses, then I guess the idea was to impart the intent
that there is no IPv6 address compression because the full IPv6 header is
being used.

The IPv6 entry is further explained:

   IPv6:  Specifies that the following header is an uncompressed IPv6
      header [RFC2460 <http://tools.ietf.org/html/rfc2460>].

That is completely unambiguous.

Robert

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Jul 2015 13:23:51 +0200

Robert,

> Alexandru - I don't understand what your issue is.

Two issues:

- why the description of the parameter for the IPv6 Header says RFC4944 
instead of RFC2460?

- why there are two values for IPv6 Header:  "01 000001" and "1110111N"

The first issue is unclear to me, see below why.  For the second issue, 
I dont know what you think.

>     A LoWPAN encapsulated IPv6 datagram:

The problem is that the same RFC4944 on its same page 6 tells this below 
the above:
>    A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:
>
>       +--------------+------------+---------+
>       | HC1 Dispatch | HC1 Header | Payload |
>       +--------------+------------+---------+

If, on the other hand, you refer solely to rfc2460 (instead of rfc4944) 
it would be clearer, because that rfc2460 defines authoritatively the 
IPv6 Header and only it.

>
> Figure 2 perhaps could have been worded better but as the document is
> about compressing IPv6 addresses, then I guess the idea was to impart
> the intent that there is no IPv6 address compression because the full
> IPv6 header is being used.

If RFC4944 had only that figure you display as an excerpt then it would 
have been clear.

>        header [RFC2460 <http://tools.ietf.org/html/rfc2460>].

Ok.  But it makes it as a double indirection.  IT would have been 
shorter to directly refer to rfc2460, not through an additional indirection.

> That is completely unambiguous.

Ok, let's say for me it is two times longer to find.

Alex

>
> Robert
>
> On 22 July 2015 at 09:35, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>         wrote:
>
>
>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 22 Jul 2015 15:40:43 +0100

Hi Alex,

Comments inline.

Robert

> - why the description of the parameter for the IPv6 Header says RFC4944

<RCC>Please point out where you are referring to?</RCC>

> - why there are two values for IPv6 Header:  "01 000001" and "1110111N"

<RCC>"01 000001" is the dispatch code, which is what I refer to. "1110111N"
is the IPHC NHC field for indicating what follows and is specific to IPHC
and not a dispatch code.</RCC>

>
> The first issue is unclear to me, see below why.  For the second issue, I
> dont know what you think.
>
>
>> Page 6 shows:
>>
> If, on the other hand, you refer solely to rfc2460 (instead of rfc4944) it
> would be clearer, because that rfc2460 defines authoritatively the IPv6
> Header and only it.

<RCC>The diagram you added is for HC1 dispatch, using HC1 header
compression as defined in RFC 4944. It does not apply to RFC 2460 IPv6
header. What is unclear about this?</RCC>

> If RFC4944 had only that figure you display as an excerpt then it would

<RCC>The whole point of RFC 4944 is to define a set of dispatch codes, one
of which is the IPv6 dispatch code. So I fail to see how one figure would
work for a set of dispatch codes</RCC>

> Ok.  But it makes it as a double indirection.  IT would have been shorter
> to directly refer to rfc2460, not through an additional indirection.
>

<RCC>It is a direct reference to RFC 2460 - no indirection. But there
again, I am starting to wonder what you mean by "IT" above.</RCC>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jul 2015 18:51:56 +0200

Robert Cragie wrote:
>     - why the description of the parameter for the IPv6 Header says
>     RFC4944 instead of RFC2460?
> 
> 

https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml

It says 4944, because 4944 defines how IPv6 is encoded (uncompressed) in
a 802.15.4 frame: The MAC payload begins with a dispatch byte (decimal
65), followed by the IP packet.  4944 says:

      header [RFC2460].

where 2460 is a normative reference.  This is all exactly as it should
be (except that we have since learned it's not so bright to have both
uncompressed and compressed alternatives available).

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Wed, 22 Jul 2015 18:02:25 +0100

Thanks Carsten - I thought Alex was referring to the documents themselves
somehow.

I agree with what you say.

Robert

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Jul 2015 13:56:59 +0200

Robert, thanks, and to Carsten.

The point I am trying to make is that at that IANA URL we see two 
different values for IPv6 Header.

You seem to be saying that one is used if there is no LOWPAN header and 
the other one is used inside that LOWPAN header, if it is present.

I would like to understnad whether or not the presence of the LOWPAN 
header with a compressed IPv6 Header is shorter overall than LOWPAN 
header absent but with a full IPv6 Header.  And if yes, by how much.

Yours,

Alex

Le 22/07/2015 16:40, Robert Cragie a écrit :
> Hi Alex,
>
> Comments inline.
>
> Robert
>
> On 22 July 2015 at 12:23, Alexandru Petrescu
> <RCC>"01 000001" is the dispatch code, which is what I refer to.
> "1110111N" is the IPHC NHC field for indicating what follows and is
> specific to IPHC and not a dispatch code.</RCC>
>
>
>     The first issue is unclear to me, see below why.  For the second
>     issue, I dont know what you think.
>
>
>         Page 6 shows:
>
>     The problem is that the same RFC4944 on its same page 6 tells this
>     below the above:
>
>     If, on the other hand, you refer solely to rfc2460 (instead of
>     rfc4944) it would be clearer, because that rfc2460 defines
>     authoritatively the IPv6 Header and only it.
>
>
>     If RFC4944 had only that figure you display as an excerpt then it
>     would have been clear.
>
> <RCC>The whole point of RFC 4944 is to define a set of dispatch codes,
> one of which is the IPv6 dispatch code. So I fail to see how one figure
> would work for a set of dispatch codes</RCC>
>
>
>         <mailto:[email-masked]>>> wrote:
>
>
>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>>>
>
>                  wrote:
>
>
>
>                  But I dont understand why is IANA reserving anything
>         below the IP
>                  layer?
>
>                  Provided there is an explanation for it that I missed
>         (sorry), I
>                  dont
>         <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>
>         <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>