Re: [6lo] Draft wording for liaison statement

[Robert Cragie <[e-mail]>]

Hi Alex,

Comments inline.

Robert

On 22 July 2015 at 12:23, Alexandru Petrescu <[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]>>
>> 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
>>
>>
>>
>