Re: [lp-wan] Benjamin Kaduk's Discuss on draft-ietf-lpwan-ipv6-static-context-hc-21: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hello Carles, all,

> Perhaps we might say that "SCHC provides adaptation layer functionality"
earlier in the document (e.g. in Section 1).
[DB] good point, I'll consider this improvement if there's a version -23.

Best regards

Dominique 

Le 02/11/19 12:29, « Carles Gomez Montenegro » <[e-mail]> a
écrit :

>Hi,
>
>(Removing Benjamin and the rest of the IESG.)
>
>On the point below:
>
>>>> 
>>>>>----------------------------------------------------------------------
>>>> >COMMENT:
>>>> 
>>>>>----------------------------------------------------------------------
>>>> >
>>>> >It's perhaps a little interesting/surprising to see this document
>>>> >describe itself as just "header compression [with some fragmentation
>>>> >support]".  Is this intended (after profiling) to be the entire IPv6
>>>> >adaptation layer for the LPWAN technologies in question, or would
>>>> there
>>>> >need to be an additional adaptation layer?
>>>> [DB] yes, this is the entire adaptation layer for the LPWAN
>>>> technologies
>>>> in question, after profiling.
>>>> The Abstract says:
>>>> "This document defines the Static Context Header Compression (SCHC)
>>>> framework, which provides both header compression and fragmentation
>>>> functionalities. SCHC has been designed for Low Power Wide Area
>>>> Networks
>>>> (LPWAN)."
>>>> And also
>>>> "This document also specifies a fragmentation and reassembly mechanism
>>>>Å  "
>>>> Can you please elaborate on what text made you think this
>>>> specification
>>>> only provided support for fragmentation, not the full real
>>>> fragmentation
>>>> protocol?
>>>> The word "support" is only used in sentences like "the fragmentation
>>>> functionality supports IPv6 MTU requirement of 1280 bytes".
>>>> We dont mandate the use of SCHC fragmentation because some layer 2
>>>> technologies have their own one.
>>>> This moderation may have make it look like this document does not
>>>>contain
>>>> a full real fragmentation protocol. We'll happily correct this
>>>> misunderstanding.
>>>
>>>I don't think there was anything that gave me the impression that this
>>> was
>>>an incomplete protocol.  Rather, I had the sense that "adaption layer"
>>> is
>>>a
>>>specific keyword that was commonly used for this sort of protocol.  I am
>>>not entirely sure why I have that impression, though, as it doesn't
>>> appear
>>>in (e.g.) RFC 8200.  It does appear in the discussion of IPv6 over other
>>>technologies, though (e.g., RFC 4944), and there's even an entire
>>> document
>>>for "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms".  So I
>>>was just thinking that some readers might be helped by using that
>>> specific
>>>keyword in the description of what this document does, is all.
>> [DB] Got it, thanks for your detailed explanation. I guess we could have
>> used the term "adaptation layer".
>> Or, thinking aloud, maybe it is better to leave to the schc-over-foo
>> documents to specify "The adaptation layer between IP and foo" and keep
>> this draft as the description of the tool box that allows building such
>> an
>> adaptation layer.
>> We will discuss it in the WG and consider a change for -23.
>
>We do have text in the document (beginning of Section 5) where we say:
>
>   "SCHC can be characterized as an adaptation layer between an upper
>   layer (typically, IPv6) and an underlying layer (typically, an LPWAN
>   technology)."
>
>It is true, though, that a complete adaptation layer for a specific
>underlying technology would comprise both the generic SCHC functionality
>and the corresponding profile.
>
>Perhaps we might say that "SCHC provides adaptation layer functionality"
>earlier in the document (e.g. in Section 1).
>
>Thanks,
>
>Carles
>


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.