Re: [6lo] Draft wording for liaison statement

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

On 22 July 2015 at 09:35, Alexandru Petrescu <alexandru.petrescu@gmail.com>
wrote:

>
>
> Le 21/07/2015 18:54, Kerry Lynn a écrit :
>
>> On Tue, Jul 21, 2015 at 10:47 AM, Alexandru Petrescu
>> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>>
>>
>> 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
>> 6lo@ietf.org <mailto:6lo@ietf.org>
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>> _______________________________________________ 6lo mailing list
>> 6lo@ietf.org <mailto:6lo@ietf.org>
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>