Subject: Re: [6lo] 6lo Digest, Vol 6, Issue 7 - Charter-04 proposal

From: Shahid Raza <[email-masked]>
Date: Tue, 8 Oct 2013 22:03:57 +0200

Oh...Based on the discussions and questions raised in the 6lo BoF during the IETF 87, it was decided (before voting for the charter) that we should not restrict to the Generic Header Compression. This text "Specifications, such as header compression, that are applicable to more than one adaptation layer specification" is new. The original text approved during the BoF was "common infrastructure specification such as header compression specific to constrained node networks". The new text leaves out our work on "IPsec header compression" that was presented during the 6lo BoF (http://tools.ietf.org/html/draft-raza-6lowpan-ipsec-01). The new wording "applicable to more than one" should not be in the charter. In the 6lo working group we should be able to discuss the pros and cons of both the generic and the 6LoWPAN-styled header compression and adapt the one that is efficient and suitable for the IoT protocols.  
/Shahid
---------------------------------------------------------------
Shahid RazaPhD, Senior ResearcherNetworked Embedded Systems group
Swedish Institute of Computer Science (SICS)
SICS Swedish ICT, Stockholm, Sweden
Ph. No. +46 768831797
http://www.shahidraza.info
Research Interests: IoT, Security, WSNs---------------------------------------------------------------

From: [email-masked]
Subject: 6lo Digest, Vol 6, Issue 7 - 
To: [email-masked]
Date: Tue, 8 Oct 2013 12:01:00 -0700

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 
 
https://www.ietf.org/mailman/listinfo/6lo
 
Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send 6lo mailing list submissions to
	[email-masked]
 
To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/6lo
or, via email, send a message with subject or body 'help' to
	[email-masked]
 
You can reach the person managing the list at
	[email-masked]
 
When replying, please edit your Subject line so it is more specific
than "Re: Contents of 6lo digest..."

--Forwarded Message Attachment--
From: [email-masked]
To: [email-masked]
Date: Tue, 8 Oct 2013 09:16:11 -0700
Subject: [6lo] Charter-04 proposal

Hi,
 
below is an updated version of the charter based on the discussions on
the list. Note that Brian needs the charter updates by today COB in
order to have it ready for the next IESG telechat (or otherwise it
would be delayed).

charter
====================
6lo focuses on Internet Area work that is needed for constrained node
networks with the characteristics of:
* limited power, memory and processing resources
* hard upper bounds on state, code space and processing cycles
* optimization of energy and network bandwidth usage
* lack of some layer 2 services like complete device connectivity and
  broadcast/multicast
 
Specifically, 6lo will work on:
 
1. IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies
(RFC4944, RFC6282, RFC6775) for link layer technologies of interest in
constrained node networks
 
================
OLD
2. Related MIB modules
 
NEW
2. Information and data models (e.g., MIB modules) for these
adaptation layers for basic monitoring and troubleshooting.
================
 
3. Specifications, such as header compression, that are applicable to more
than one adaptation layer specification
 
4. Maintenance and informational documents required for the existing
IETF specifications in this space.
 
Only specifications targeting constrained node networks are in scope.
6lo will work closely with the 6man working group, which will continue
to work on IP-over-foo documents outside the constrained node network
space and will continue to be the focal point for IPv6 maintenance.
================
OLD
For adaptation layer specifications that do not have implications on
IPv6 architecture, 6man will be notified about 6lo's working group
last call. Specifications that might have such an impact (e.g., by
using IPv6 addresses in a specific way or by introducing new ND
options) will be closely coordinated with 6man, and/or specific parts
will be fanned out to 6man documents.
 
NEW
For adaptation layer specifications that do not have implications on
IPv6 architecture, 6man will be notified about 6lo's working group
last call. Specifications that might have such an impact (e.g., by
using IPv6 addresses in a specific way or by introducing new ND
options or by exposing to IPv6 a link model different from either
Ethernet or 6lowpan) will be closely coordinated with 6man, and/or
specific parts will be fanned out to 6man documents.
================
Beyond 6man, 6lo will also coordinate with LWIG and INTAREA.
 
6lo works on small, focused pieces of Internet Area work. 6lo does not
take on larger cross-layer efforts. The working group will continue to
reuse existing protocols and mechanisms whenever reasonable and
possible.
 
Security and management work that is not specific to the link layers being
worked on is out of scope. Work related to routing is out of scope. 6lo
will coordinate closely with the working groups in other areas that focus
on constrained node networks, such as ROLL (RTG) and CoRE (APP).

--Forwarded Message Attachment--
From: [email-masked]
CC: [email-masked]
To: [email-masked]
Date: Tue, 8 Oct 2013 18:25:16 +0200
Subject: Re: [6lo] Charter-04 proposal

On Oct 8, 2013, at 18:16, Ulrich Herberg <[email-masked]> wrote:
 
> updated version of the charter 
 
Works for me.
 
Thanks for coordinating this!
 
Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Oct 2013 22:19:01 +0200

Shahid,

the entirety of RFC 6282 would fall under "applicable to more than one adaptation layer specification" (it is currently being referenced by BT-LE, lowpanz, 6lobac, dect-ule).  One example that we had in mind when that phrase was coined was GHC.  So why would draft-raza-6lowpan-ipsec-01, which just plugs into the NHC extension point of RFC 6282, like GHC does, not be?

Grüße, Carsten

---

From: Shahid Raza <[email-masked]>
Date: Tue, 8 Oct 2013 22:30:39 +0200

Good!!
I misunderstood it then. I read it as "a single header compression scheme that fits to multiple headers, such as GHC".
Thanks for the clarification.

Regards
Shahid