Subject: Re: [lp-wan] Protocol Action: 'Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6' to Proposed Standard (draft-ietf-lpwan-ipv6-static-context-hc-24.txt)

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Dec 2019 08:13:20 +0100

Chic! :-)

Congratulations for completing a great foundation to make IPv6 work with a few more billions of nodes!

Grüße, Carsten

> On Dec 11, 2019, at 23:59, The IESG <[email-masked]> wrote:
> 
> The IESG has approved the following document:
> - 'Static Context Header Compression (SCHC) and fragmentation for LPWAN,
>   application to UDP/IPv6'
>  (draft-ietf-lpwan-ipv6-static-context-hc-24.txt) as Proposed Standard
> 
> This document is the product of the IPv6 over Low Power Wide-Area Networks
> Working Group.
> 
> The IESG contact persons are Éric Vyncke and Suresh Krishnan.
> 
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
> 
> 
> 
> 
> 
> Technical Summary
> 
>  This document defines the Static Context Header Compression (SCHC)
>   framework, which provides both header compression and fragmentation
>   functionalities.  SCHC has been tailored for Low Power Wide Area
>   Networks (LPWAN).
> 
>   SCHC compression is based on a common static context stored in both
>   the LPWAN devices and the network side.  This document defines a
>   header compression mechanism and its application to compress IPv6/UDP
>   headers.
> 
>   This document also specifies a fragmentation and reassembly mechanism
>   that is used to support the IPv6 MTU requirement over the LPWAN
>   technologies.  Fragmentation is needed for IPv6 datagrams that, after
>   SCHC compression or when such compression was not possible, still
>   exceed the layer two maximum payload size.
> 
>   The SCHC header compression and fragmentation mechanisms are
>   independent of the specific LPWAN technology over which they are
>   used.  Note that this document defines generic functionalities and
>   advisedly offers flexibility with regard to parameter settings and
>   mechanism choices.  Such settings and choices are expected to be made
>   in other technology-specific documents.
> 
> Working Group Summary
> 
>  The WGLC comments were rich but did not show
>  fundamental issues in the design. The 30 open tickets lead mostly to editorial
>  changes that helped clarify the text ann avoid misinterpretation. We spent the
>  last IETF meeting and multiple interim going through the tickets and addressed
>  them concensualy. 
> 
> Document Quality
> 
>  The protocol has been implemented and demonstrated over LoRa and SigFox
>  technologies. There is only one vendor proposing a stack at this point.
>  The reviewers are acknowledged in the document. The original
>  shepherd was Dominique Barthel. He went so deep in the process, proposing
>  edits and helping with the corrected text, that the chairs asked him to move
>  to a co-author position, and took over shepherding, not because he was not
>  good enough, but because he did too well at it.
> 
> Personnel
> 
>  The Document Shepherd is Pascal Thubert. The Responsible Area Director is Suresh Krishnan.
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: The IESG <[email-masked]>
Date: Wed, 11 Dec 2019 14:59:41 -0800

Technical Summary

Working Group Summary

Document Quality

Personnel