Re: [6lo] Draft wording for liaison statement

[Alexandru Petrescu <[e-mail]>]

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
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Robert,
>
>     Le 22/07/2015 11:12, Robert Cragie a écrit :
>
>         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?
>
>
> <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:
>
>              A LoWPAN encapsulated IPv6 datagram:
>
>                 +---------------+-------------+---------+
>                 | IPv6 Dispatch | IPv6 Header | Payload |
>                 +---------------+-------------+---------+
>
>
>         That is pretty clear to me - it says "IPv6 Header".
>
>
>     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.
>
>
> <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>
>
>
>
>
>         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.
>
> <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>
>
>
>         The IPv6 entry is further explained:
>
>              IPv6:  Specifies that the following header is an
>         uncompressed IPv6
>                 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.
>
>
> <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>
>
>
>
>
>         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
>         <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[e-mail]
>         <mailto:[e-mail]>>> wrote:
>
>
>
>              Le 21/07/2015 18:54, Kerry Lynn a écrit :
>
>                  On Tue, Jul 21, 2015 at 10:47 AM, Alexandru Petrescu
>                  <[e-mail]
>         <mailto:[e-mail]>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>
>
>                  <mailto:[e-mail]
>         <mailto:[e-mail]>>>>
>
>                  wrote:
>
>
>
>                  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.?
>
>                  <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
>
>                  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
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>                  <mailto:[e-mail] <mailto:[e-mail]>>>
>         https://www.ietf.org/mailman/listinfo/6lo
>
>
>                  _______________________________________________ 6lo
>         mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>                  <mailto:[e-mail] <mailto:[e-mail]>>>
>         https://www.ietf.org/mailman/listinfo/6lo
>
>
>
>              _______________________________________________
>              6lo mailing list
>         [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>         https://www.ietf.org/mailman/listinfo/6lo
>
>
>
>