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

["Carles Gomez Montenegro" <[e-mail]>]

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