Re: [6lo] AD Evaluation: draft-ietf-6lo-lowpanz

[Brian Haberman <[e-mail]>]

Hi Anders,
    Looks good to me. Go ahead and submit it.

Regards,
Brian

On 9/22/14 4:59 AM, Anders Brandt wrote:
> Brian,
> 
>>      I should have caught this yesterday... 
> 
> So should I, I guess...
> 
>> Are there changes needed in section 
>> 5 to deal with the "MAY support GHC" clause in section 3?
> 
> I think they are not strictly needed, but for completeness, I have changed this text
> 
> "IPv6 header compression MUST be implemented according to [RFC6282].
> This section will simply identify substitutions that should be made
> when interpreting the text of [RFC6282]."
> 
> to this text:
> 
> "IPv6 header compression [RFC6282] MUST be implemented and
> [RFC_TBD_GHC] compression for higher layers MAY be implemented.
> This section will simply identify substitutions that should be made
> when interpreting the text of [RFC6282] and [RFC_TBD_GHC]."
> 
> A new draft-draft is attached.
> Please let me know if I should submit it as -07.
> 
> Thanks,
>   Anders
> 
>> -----Original Message-----
>> From: Brian Haberman [mailto:[e-mail]]
>> Sent: 19. september 2014 16:45
>> To: Anders Brandt; [e-mail]; [e-mail]
>> Subject: Re: AD Evaluation: draft-ietf-6lo-lowpanz
>>
>> Hi Anders,
>>      I should have caught this yesterday... Are there changes needed in section
>> 5 to deal with the "MAY support GHC" clause in section 3?
>>
>> Brian
>>
>>
>> On 9/18/14 8:48 AM, Brian Haberman wrote:
>>> Hi Anders,
>>>      These changes look good.  Go ahead and submit this update and I
>>> will move it along to IETF Last Call.
>>>
>>> Regards,
>>> Brian
>>>
>>> On 9/18/14 5:18 AM, Anders Brandt wrote:
>>>> Hi Brian,
>>>>
>>>> (inserted a few of Carsten's comments where relevant)
>>>>
>>>> Please see comments inline.
>>>> The attached draft2 files contain the changes proposed in this mail.
>>>>
>>>> Cheers,
>>>>   Anders
>>>>
>>>>> -----Original Message-----
>>>>> From: Brian Haberman [mailto:[e-mail]]
>>>>> Sent: 17. september 2014 17:36
>>>>> To: Anders Brandt; [e-mail];
>>>>> [e-mail]
>>>>> Subject: Re: AD Evaluation: draft-ietf-6lo-lowpanz
>>>>>
>>>>> Hi Anders,
>>>>>      I have snipped all the pieces where we have a way forward...
>>>>>
>>>>> On 9/17/14 10:04 AM, Anders Brandt wrote:
>>>>>
>>>>>>
>>>>>>       >    - Can the use of RFC 6282 compression be replaced with the
>>>>>>       >  functionality
>>>>>>       > specified in draft-ietf-6lo-ghc?
>>>>>>
>>>>>> As Carsten Borman already responded:
>>>>>>
>>>> <snip>
>>>>>> I agree in Carsten's observations. I am however reluctant making
>>>>>> GHC a hard requirement.
>>>> <snip>
>>>>> Is it worthwhile to mention that the stateless nature of 6282 is
>>>>> preferable in some deployment scenarios?  That should prevent other
>>>>> reviewers from asking the same question (especially since GHC is in IESG
>> review right now).
>>>>
>>>> Inserted by Anders Brandt:
>>>>> (Carsten Borman wrote:
>> 	)
>>>>> (But in the end I agree that mandatory GHC is maybe a bit much for the
>> very	)
>>>>> (low-end devices we are seeing lowpanz on.
>> 		)
>>>>> (Just not for the reason that GHC somehow needs state.
>> 	)
>>>>
>>>> Section 3.  "6LoWPAN Adaptation Layer and Frame Format" says:
>>>>
>>>> "IPv6 header compression [RFC6282] MUST be supported by
>>>> implementations of this specification."
>>>>
>>>> I propose adding
>>>>
>>>> "Further, implementations MAY support Generic Header Compression
>>>> (GHC) [TBD_RFC_GHC]. A node implementing [TBD_RFC_GHC] MUST
>> probe its
>>>> peers for GHC support before applying GHC compression."
>>>>
>>>>>>       >    - I don't understand the statement that a node MAY support the
>> M
>>>>>>       > flag in
>>>> <snip>
>>>>>> The option allows for deployments with the full addressing
>>>>>> flexibility provided by DHCP while fully capable nodes can still be
>>>>>> used in cost
>>>>> optimized deployments.
>>>>>
>>>>> Ok, I understand the logic now, but think it can be said differently.
>>>>> In reality, the M bit is understood, but is not honored.  Given
>>>>> that, it may be better to say that some deployments do not support
>>>>> stateful address assignments and implementations may optimize by
>>>>> cost and omit stateful addressing protocols.
>>>>
>>>> The existing text says:
>>>>
>>>> "A node interface MAY support the M flag of the RA message for the
>>>> construction of routable IPv6 addresses. "
>>>>
>>>> It is proposed to append this text:
>>>>
>>>> "A cost optimized node implementation may save memory by skipping
>>>> support for the M flag."
>>>>
>>>>>>       > * Section 2.2 - How would routing protocols support
>>>>>> subnet-wide
>>>>> multicast
>>>>>>       > forwarding if packets are encoded as broadcast messages?
>>>> <snip>
>>>>> Actually, a simple sentence pointing out that G.9959 does not
>>>>> support link- layer multicast would clarify things nicely.
>>>>
>>>> The existing text says:
>>>>
>>>> " G.9959 supports direct-range IPv6 multicast while subnet-
>>>>    wide multicast is not supported natively by G.9959. "
>>>>
>>>> I see no need for a change (?)
>>>>
>>>>>>       > * Section 3 - The naming of the headers when discussing their
>> order of
>>>>>>       > appearance is confusing.  Why refer to the "addressing
>>>>>> header" when
>>>> <snip>
>>>>> I did not realize it was taken directly out of 4944.  I am fine with
>>>>> leaving it as is then.
>>>>>
>>>>> Regards,
>>>>> Brian
>>>>
>>>
>