Re: [6lo] Draft wording for liaison statement

[Alexandru Petrescu <[e-mail]>]

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?

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

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

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

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

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