Subject: [6lowapp] Proposed charter for 6LoWAPP BOF

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Oct 2009 07:42:57 +0100

I've been talking to various folks about the how quickly they would  
like to get initial standards on this topic complete. To move quickly,  
I think we need an initial charter that is extremely focused and makes  
it clear what we are going to go do. After we meat the initial goals  
of the WG, we could expand the WG to explore into more area and extend  
the protocols to do more. I bounced some ideas around with Zack,  
Carsten, and Don and have put an initial draft of what I think of as a  
focused charter might look like below.

It's just a straw man and it has some problems in it. I've been trying  
to merge all the various things different people have told me and  
organize them. I'm not promoting that I think this is the best plan -  
it just a plan that we can use as a baseline to talk about what we  
really want to do as group and if this charter reflects that or not.

Please, read it. Think about, if the WG did this, could you live with  
that. If No, why and what requirements do you have this does not meet.  
If you could live with it but some changes would make it better, what  
are they.

Thanks, Cullen

----------------------------------------

Applications are being developed for networks that have very limed  
packets sizes, have high degree of packet loss, and where a  
substantial number of devices that may be powered of at any point in  
time but periodically "wake up" for beef periods of time. These  
Networks are referred to as Constrained Networks (CNEets). Low-Power  
Wireless Personal Area Networks (LoWPANs) are an example of this type  
of network. These networks are becoming increasing important for  
applications such as home automation, energy management, and the  
Internet of Things. This working group will define a framework a  
limited class of applications that deal with manipulation of simple  
resources on devices on a CNet. This includes applications to monitor  
simple sensors such as a temperature gauge, light switch, or power  
meter and control an actuator such as a light switch, heating system,  
or door lock. Typical uses include power management and reporting, and  
home automation.

The general architecture consists of nodes on the CNet, called  
Devices, that have one or more Resources that represent sensors and  
actuators. Devices send message to change and query resources on other  
devices. Devices can send notifications about changed resource values  
to subscribed Devices. In other words, the architecture requires push,  
pull and and a notify approach to manipulating resources. As part of  
the framework for building these applications, the WG will define a  
CNet Application Protocol (CoAP) for manipulation or Resources on  
Devices. The framework will also specify a way to define new interface  
profiles that can be defined by vendors and other standards bodies to  
define the particular Resources on a Device and what manipulation are  
possible.

There are also nodes called PEPs (Performance Enhancing Proxy) that  
gateway between the protocols typically used by the applications on  
the Internet and the protocol used on the CNet. An application on the  
general network can use HTTP REST to communicate with the PEP which  
will use CoAP to manipulate the Resource on the Device. The WG will  
define a mapping on the PEP from the CoAP to the a HTTP  REST API.  
Each interface profile will define the Resources on the device that  
application can manipulate and what manipulations are possible.  This  
will determine the HTTP REST APIs on the PEPs and the CoAP protocol  
encoding to manipulate the Resources on the Device it will also  
specify an XML MINE type for each class of Device that can be used to  
described the Resource state in the the body of HTTP REST messages.  
The WG may also work on a mapping to SNMP on the PEP. It is worth  
noting that the PEP does not have to be deployed at the boundary of  
the CNet and the more general network but can be deployed at various  
location in the network.

The PEP boxes can provide various forms of "caching". For example, if  
a temperature sensor is normally asleep but wakes up every five  
minutes and sends the current temperature to the a PEP that  
subscribed, when the PEP receives a request over HTTP for that  
temperature resource, it can respond with the last seen value instead  
of trying to query the Device which is currently asleep. The PEPs may  
also provide support for discovering devices that may not be currently  
responding as they are temporarily asleep.

The initial work item of the WG are to define:

1) A requirements and architecture document that documents the high  
level boxes and arrows view of the protocol along with high level  
description of how the security, particular for commissioning of new  
devices into the network will work. The WG may also produce a document  
that describes various uses cases that help motivate the requirements.

2) Specification of the framework for defining interface profiles and  
the defining the CoAP. The CoAP will be able to set and query a  
resource on a Device. It will allow a device to publish a value or  
event to another Device. It will support a  non-reliable multicast  
message to be sent to a group of devices to manipulate a resource on  
all the devices simultaneously (roughly within 50 ms of each other).  
The protocol will operate over UDP assuming a TBD byte payload and  
assume an underlying network bandwidth of approximately TBD kbps. The  
payload will be based on interface profile specific XML document  
compressed with EXI.

3) Specification on how to use the CoAP to discover Devices on the  
LoPAN and to interrogate them to find out which interface profiles  
they support.

4) Specification for the HTTP REST based API on the PEP to communicate  
with Devices.

4a) Possibly specify a separate specifications with mappings to SNMP.  
[[NOte: In the BOF it would be nice to figure out if this is in the  
charter or not.]]

5) A small set of basic interface profiles to illustrate how this is  
done. Interface profiles will be done for a power meter, a light and  
light switch, and temperature sensor.

6) A document with operation and management advice about running a  
network using these applications.

Security, particularly keying of new Devices, is very challenging for  
these applications. On one hand this needs to support models where an  
end user can introduce a new device onto their network that may have  
no display or not input capability's. On the other end this may  
transport information about alarm systems or controlling door locks to  
a building over a wireless network.

The CoAP protocol will support three commissioning methodologies.

1) Duckling mode. One device is put in a "mother duck" mode where it  
listens for broadcasts of Devices trying to imprint. Other Devices are  
put in a "duckling" mode where they broad cast to the "mother duck"  
Device then "imprint" by forming a new shared secret between the two  
Devices. Once this is complete the devices are taken out of this mode  
and can be use in a secure fashion.

2) Out of Band Key mode. Each device in manufactured with an initial  
symmetric key physically printed on the side in numeric and barcode  
form. Alternatively the device could have a barcode that forms a URL  
which when dereferenced with appropriate authorization provides a  
secure access to the key. A human can enter or scan this into a  
computer that can then be used form a secure connection with the  
Device. Once a secure connection is formed, the symmetric key can be  
changed.

3) Certificate mode. Each device is manufactured with a certificate  
with an asymmetric key. The fingerprint of the certificate is printed  
on a barcode. During commissioning, a computer can scan the barcode,  
the connect to the device and replace the certificate with a locally  
generated certificate that can be used for forming secure connections.

Modes 1 and 2 are mandatory to implement but mode 3 is option. In all  
modes, once Device A and Device B have formed a secure connection with  
Device C, Device C can be used to transitively introduce A and B so  
now A and B have a secure connection with  C. This transitive trust  
introduction can be used during commissioning even if A and B do not  
yet have network connectivity to each other.

The CoAP will use CMS for object security. The WG will request the  
security area define a subset of CMS along with an EXI encoding  
instead of ASN.1 that is appropriate for a CNet network and for theses  
types of devices. It will have one mandatory to implement crytpo  
profile with no public key cryptograph to support modes 1 and 2 and  
additional crypto profile with public key cryptograph for support of  
mode 3. In mode 3, it will (or will not TBD) require support for  
Elliptical Curve Cryptograph (ECC).

The WG will coordinate on requirements from TBD (other SDO and  
organizations). The WG will closing coordinate with other IETF WGs  
including ROLL 6LowPAN and appropriate groups in OAM and Security.

Milestone:

Jan 2010 - Select WG document for basis of CoAP protocol

Jun 2010 - Requirements and Architecture to IESG as Info

Dec 2010 - Core protocol specification to IESG as PS

Dec 2010 - HTTP Rest API mapping to IESG as PS

Mar 2011 - Discovery specification to IESG as PS

Mar 2011 - Specifications of basic interface profiles to IESG as PS

Mar 2012 - Ops & Management advice to IESG as Info

---

From: Jukka Manner <[email-masked]>
Date: Thu, 29 Oct 2009 16:20:56 +0200

Hi,

I'm somewhat struggling with understanding the charter, but at least two 
items pop out:

1. This seems to indicate that 6lowapp will not be tied to any existing 
work, it will work on its own goals, but in collaboration with others 
(which is somewhat open as what it means). I would have expected that 
6lowapp would specifically look at existing work in related WGs and see 
how build on top of that.

2. The charter goes quite far in the design of the solution and it's 
details. To me this seems a bit too far into the future, but also 
somewhat limited and very specific and narrow(?). Maybe this is fine for 
a BOF charter, but way too detailed for a WG charter.

I'll comment more when I understand the goals more (if that happens 
anytime soon).

regards,
Jukka

Cullen Jennings wrote:
> 
> I've been talking to various folks about the how quickly they would like 
> to get initial standards on this topic complete. To move quickly, I 
> think we need an initial charter that is extremely focused and makes it 
> clear what we are going to go do. After we meat the initial goals of the 
> WG, we could expand the WG to explore into more area and extend the 
> protocols to do more. I bounced some ideas around with Zack, Carsten, 
> and Don and have put an initial draft of what I think of as a focused 
> charter might look like below.
> 
> organize them. I'm not promoting that I think this is the best plan - it 
> just a plan that we can use as a baseline to talk about what we really 
> want to do as group and if this charter reflects that or not.
> 
> packets sizes, have high degree of packet loss, and where a substantial 
> number of devices that may be powered of at any point in time but 
> periodically "wake up" for beef periods of time. These Networks are 
> referred to as Constrained Networks (CNEets). Low-Power Wireless 
> Personal Area Networks (LoWPANs) are an example of this type of network. 
> These networks are becoming increasing important for applications such 
> as home automation, energy management, and the Internet of Things. This 
> working group will define a framework a limited class of applications 
> that deal with manipulation of simple resources on devices on a CNet. 
> This includes applications to monitor simple sensors such as a 
> temperature gauge, light switch, or power meter and control an actuator 
> such as a light switch, heating system, or door lock. Typical uses 
> include power management and reporting, and home automation.
> 
> The general architecture consists of nodes on the CNet, called Devices, 
> that have one or more Resources that represent sensors and actuators. 
> Devices send message to change and query resources on other devices. 
> Devices can send notifications about changed resource values to 
> subscribed Devices. In other words, the architecture requires push, pull 
> and and a notify approach to manipulating resources. As part of the 
> framework for building these applications, the WG will define a CNet 
> Application Protocol (CoAP) for manipulation or Resources on Devices. 
> The framework will also specify a way to define new interface profiles 
> that can be defined by vendors and other standards bodies to define the 
> particular Resources on a Device and what manipulation are possible.
> 
> gateway between the protocols typically used by the applications on the 
> Internet and the protocol used on the CNet. An application on the 
> general network can use HTTP REST to communicate with the PEP which will 
> use CoAP to manipulate the Resource on the Device. The WG will define a 
> mapping on the PEP from the CoAP to the a HTTP  REST API. Each interface 
> profile will define the Resources on the device that application can 
> manipulate and what manipulations are possible.  This will determine the 
> HTTP REST APIs on the PEPs and the CoAP protocol encoding to manipulate 
> the Resources on the Device it will also specify an XML MINE type for 
> each class of Device that can be used to described the Resource state in 
> the the body of HTTP REST messages. The WG may also work on a mapping to 
> SNMP on the PEP. It is worth noting that the PEP does not have to be 
> deployed at the boundary of the CNet and the more general network but 
> can be deployed at various location in the network.
> 
> The PEP boxes can provide various forms of "caching". For example, if a 
> temperature sensor is normally asleep but wakes up every five minutes 
> and sends the current temperature to the a PEP that subscribed, when the 
> PEP receives a request over HTTP for that temperature resource, it can 
> respond with the last seen value instead of trying to query the Device 
> which is currently asleep. The PEPs may also provide support for 
> discovering devices that may not be currently responding as they are 
> temporarily asleep.
> 
> the defining the CoAP. The CoAP will be able to set and query a resource 
> on a Device. It will allow a device to publish a value or event to 
> another Device. It will support a  non-reliable multicast message to be 
> sent to a group of devices to manipulate a resource on all the devices 
> simultaneously (roughly within 50 ms of each other). The protocol will 
> operate over UDP assuming a TBD byte payload and assume an underlying 
> network bandwidth of approximately TBD kbps. The payload will be based 
> on interface profile specific XML document compressed with EXI.
> 
> 3) Specification on how to use the CoAP to discover Devices on the LoPAN 
> and to interrogate them to find out which interface profiles they support.
> 
> end user can introduce a new device onto their network that may have no 
> display or not input capability's. On the other end this may transport 
> information about alarm systems or controlling door locks to a building 
> over a wireless network.
> 
> which when dereferenced with appropriate authorization provides a secure 
> access to the key. A human can enter or scan this into a computer that 
> can then be used form a secure connection with the Device. Once a secure 
> connection is formed, the symmetric key can be changed.
> 
> 3) Certificate mode. Each device is manufactured with a certificate with 
> an asymmetric key. The fingerprint of the certificate is printed on a 
> barcode. During commissioning, a computer can scan the barcode, the 
> connect to the device and replace the certificate with a locally 
> Device C, Device C can be used to transitively introduce A and B so now 
> A and B have a secure connection with  C. This transitive trust 
> introduction can be used during commissioning even if A and B do not yet 
> have network connectivity to each other.
> 
> security area define a subset of CMS along with an EXI encoding instead 
> of ASN.1 that is appropriate for a CNet network and for theses types of 
> devices. It will have one mandatory to implement crytpo profile with no 
> public key cryptograph to support modes 1 and 2 and additional crypto 
> profile with public key cryptograph for support of mode 3. In mode 3, it 
> will (or will not TBD) require support for Elliptical Curve Cryptograph 
> (ECC).
> 
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Helsinki University of Technology Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320 (Otakaari 5A)
P.O. Box 3000, FIN-02015 TKK      E-mail: [email-masked]
Finland                           WWW:    www.comnet.tkk.fi

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 29 Oct 2009 07:48:05 -0700

Sorry for the resend...   First one was with the wrong e-mail account.

Don

-----Original Message-----
From: Don Sturek 
Sent: Thursday, October 29, 2009 7:37 AM
To: 'Cullen Jennings'; [email-masked]
Cc: Zach Shelby; Carsten Bormann; Lisa Dusseault
Subject: RE: Proposed charter for 6LoWAPP BOF

Hi Cullen,

Overall, the proposed charter looks interesting.

On the Commissioning methods, I think making the "Duckling" mode mandatory
as indicated in the text below should not be decided in the charter.
Unless this commissioning method has undergone some form of security review,
it could well be something we (at least in Smart Energy) cannot use.  It
would be a shame to waste code space for something like this.

While we (again Smart Energy) are looking at a RESTfull HTTP architecture,
it would be good to point out that this is only one option.  It would be
nice to see if other popular communication solutions can work as well.

One more thng:   The discussion below indicates two level of communication:
PEPs and CoAps.   I would hope we could avoid this.  It would be nice to
address and communicate with CoAp devices as you would with any other device
on the internet whether a PEP was present or not.  I would not want to have
the group focused on this type of gateway approach.

Overall though this was a good start for the charter.

Don

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Wednesday, October 28, 2009 11:43 PM
To: [email-masked]
Cc: Zach Shelby; Carsten Bormann; Don Sturek; Lisa Dusseault
Subject: Proposed charter for 6LoWAPP BOF

Thanks, Cullen

Milestone:

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 29 Oct 2009 14:11:39 -0400

My comments:

The charter seems to combine goals as well as architecture together in one
go. Probably can be simplified ? Specific comments below:

On Thu, Oct 29, 2009 at 2:42 AM, Cullen Jennings <[email-masked]> wrote:

>
>
> Applications are being developed for networks that have very limed packets
> sizes, have high degree of packet loss, and where a substantial number of
> devices that may be powered of at any point in time but periodically "wake
> up" for beef periods of time. These Networks are referred to as Constrained
> Networks (CNEets). Low-Power Wireless Personal Area Networks (LoWPANs) are
> an example of this type of network. These networks are becoming increasing
> important for applications such as home automation, energy management, and
> the Internet of Things. This working group will define a framework a limited
> class of applications that deal with manipulation of simple resources on
> devices on a CNet. This includes applications to monitor simple sensors such
> as a temperature gauge, light switch, or power meter and control an actuator
> such as a light switch, heating system, or door lock. Typical uses include
> power management and reporting, and home automation.
>

ARC> We are implicitly stating that devices in a lowpan will have simple
management requirements (kind of like set/get mostly). I'd like to see this
group also consider (in terms of usecases) what are the various control
functions that are desirable, given an internet connect ecosystem? I don't
think we should assume that just because most home control was mostly about
simple on/off/read  till date, that is what we should architect for. It is a
minimal requirement, but not complete by itself.

> Devices send message to change and query resources on other devices. Devices
> can send notifications about changed resource values to subscribed Devices.
> In other words, the architecture requires push, pull and and a notify
> approach to manipulating resources. As part of the framework for building
> these applications, the WG will define a CNet Application Protocol (CoAP)
> for manipulation or Resources on Devices. The framework will also specify a
> way to define new interface profiles that can be defined by vendors and
> other standards bodies to define the particular Resources on a Device and
> what manipulation are possible.
>
> There are also nodes called PEPs (Performance Enhancing Proxy) that gateway
> between the protocols typically used by the applications on the Internet and
> the protocol used on the CNet. An application on the general network can use
> HTTP REST to communicate with the PEP which will use CoAP to manipulate the
> Resource on the Device. The WG will define a mapping on the PEP from the
> CoAP to the a HTTP  REST API. Each interface profile will define the
> Resources on the device that application can manipulate and what
> manipulations are possible.  This will determine the HTTP REST APIs on the
> PEPs and the CoAP protocol encoding to manipulate the Resources on the
> Device it will also specify an XML MINE type for each class of Device that
> can be used to described the Resource state in the the body of HTTP REST
> messages. The WG may also work on a mapping to SNMP on the PEP. It is worth
> noting that the PEP does not have to be deployed at the boundary of the CNet
> and the more general network but can be deployed at various location in the
> network.
>

ARC> I don't think HTTP to XX mapping should be assumed at this stage. HTTP
may be a popular protocol, but there could be others. So a general goal of
internet protocols to device control protocol mapping is more suitable

> temperature sensor is normally asleep but wakes up every five minutes and
> sends the current temperature to the a PEP that subscribed, when the PEP
> receives a request over HTTP for that temperature resource, it can respond
> with the last seen value instead of trying to query the Device which is
> currently asleep. The PEPs may also provide support for discovering devices
> that may not be currently responding as they are temporarily asleep.
>

ARC> Is this needed as a part of the charter?

> listens for broadcasts of Devices trying to imprint. Other Devices are put
> in a "duckling" mode where they broad cast to the "mother duck" Device then
> "imprint" by forming a new shared secret between the two Devices. Once this
> is complete the devices are taken out of this mode and can be use in a
> secure fashion.
>

<etc>

ARC> This seems to be a requirement specification of what a CoAP should be.
I think it should be left for a dedicated req doc, not as part of a charter.

Arjun Roychowdhury

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 29 Oct 2009 12:10:01 -0700

Hi Arjun,

As sponsoring Area Director, I've asked that the BOF discuss a more
focused WG charter because this isn't "the charter for low-power IP
applications protocols" it's merely *a* charter for a subset of those
things.  We can't boil the ocean in one WG or even come to agreement
on forming a WG if the scope is too big.  Besides considering that
other WGs can tackle this larger space, consider that this WG could
always go on to more complex use cases after solving simple ones.

I mention this in response to your mail although others have been
leaning in both directions, because I can give specific examples:

On Thu, Oct 29, 2009 at 11:11 AM, Arjun Roychowdhury
<[email-masked]> wrote:
> go.

Yes, because WGs seem to need not only functional goals but also at
least an anchoring architecture to start from.  I've been involved in
many software projects, both internal and community (open source) and
while software projects seem to be able to decide on an architecture
starting from a blank page, WGs seem to have more difficulty.

> minimal requirement, but not complete by itself.

What would the WGs achievable objectives here be?  So far I can only
see "Write a requirements or use cases document for possible other
control functions".  Without a solid scope here, I don't think the WG
could take on more than that.

> internet protocols to device control protocol mapping is more suitable

It is a popular protocol, and some groups specifically have
interoperability with HTTP as a deployment requirement, so perhaps
this is just the first.  It's definitely not the only.  The general
goal of mapping protocols is not, IMO, achievable at this point.  I
wouldn't object if the charter picked something other than HTTP that
was achievable, but I don't see how the WG could tackle "internet
protocols" as a class.

I do appreciate your input, but I wanted the chance to expose the
pressure I'm putting the BOF co-ordinators under to specify a small
set of documents and an achievable scope.  I hope this reassures you
that the IETF would not be saying no to a larger scope in the longer
run.

thanks,
Lisa Dusseault

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Oct 2009 13:21:43 -0600

> always go on to more complex use cases after solving simple ones.

Thanks for the clarification, Lisa. One thing I see missing from the
proposed charter is a clear problem statement. The charter states that
Low-Power Wireless Personal Area Networks are increasingly important and
that the WG will define a framework for manipulation of resources that
are available on LoWPANs. But I'm not sure what is driving the need for
such a framework, exactly what problem we're solving at the IETF, how
our solutions will serve the needs of operators, device manufacturers,
application developers, and end users, and why we think that the IETF
can bring special expertise or insight to bear on an application space
that is already being addressed by other SDOs and industry groups.
However, I freely admit that I might be missing context. :)

/psa

---

From: Arjun Roychowdhury <[email-masked]>
Date: Thu, 29 Oct 2009 15:25:31 -0400

Hi Lisa, responses inlined.
regds
arjun

> always go on to more complex use cases after solving simple ones.

ARC> I think this comment pretty much summarizes the difference of thought
between what I thought 6lowapp vs doing vs what you are describing. The
group name itself, "6lowapp" seems to specify it is a group to to specificy
low-power IP app protocols, and not a
subset. draft-bormann-6lowpan-6lowapp-problem-01 also seems to indicate this
group is dealing with the larger set.

So my comment would be if this is not so, then it needs to be explicitly
stated, otherwise the natural understanding is 6lowapp is the application
protocol group for 6lowpan devices - and what comes out of here, would
likely be adopted going forward in deployments,

I can respond to your other comments in more detail, but then again, if the
scope is going to be limited, then so be it.

-- 
Arjun Roychowdhury

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 29 Oct 2009 14:40:21 -0700

> likely be adopted going forward in deployments,

Fair enough, and I think there has been some talk of choosing a name
for the WG that would not imply so large a scope as the BOF does.

> scope is going to be limited, then so be it.

The discussion is still open about what the limited scope is going to
be however!  I did not mean to shut down debate but to channel it
early towards picking part of the 80% value according to the 80/20
rule, or alternately to pick the most important pieces to build first.

BTW, there has already been discussion about further splitting up the
work besides just 6LOWPAN and whatever WG is spun off by a 6LOWAPP
BOF; I wouldn't be surprised at if we saw another charter proposed by
next summer, if not sooner.

Lisa

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 29 Oct 2009 22:08:16 -0700

Hi Cullen,

This is a good start.  Generally, I think it covers the necessary work  
items.  But while its important to have a focused charter that  
constrains the work, I'd rather have the charter focus on one or more  
target applications rather than a particular solution.  Doing so will  
let the application requirements guide the solutions.  See below:

On Oct 28, 2009, at 11:42 PM, Cullen Jennings wrote:

> devices into the network will work. The WG may also produce a  
> document that describes various uses cases that help motivate the  
> requirements.

Generating requirements is the most important first step.  Though, I  
would suggest generating a set of application-specific requirements  
documents for a small and carefully chosen set of applications.  The  
charter should indicate what applications we will work on first.  It  
is useful to call out different applications due to their diversity.   
We did this in ROLL and it allowed us identify a base set of common  
features and those outside the base.  It drives what we work on and  
the solutions.  Just as important, it helped to bring other WG members  
up to speed on the variety of application requirements.  Fortunately,  
we already have a number of individual submissions - but are there  
other not-yet-represented application areas that people want to work on?

I would drop the "and architecture" from "requirements and  
architecture document".  I'd prefer that the requirements docs drive  
the architecture, not specify it.

> 2) Specification of the framework for defining interface profiles  
> and the defining the CoAP. The CoAP will be able to set and query a  
> assume an underlying network bandwidth of approximately TBD kbps.  
> The payload will be based on interface profile specific XML document  
> compressed with EXI.

I would drop all the "it will do X, Y, Z".  Let the requirements  
documents guide what the protocol/framework will support.

> LoPAN and to interrogate them to find out which interface profiles  

Good.

> 4) Specification for the HTTP REST based API on the PEP to  
> communicate with Devices.
>
> 4a) Possibly specify a separate specifications with mappings to  
> SNMP. [[NOte: In the BOF it would be nice to figure out if this is  
> in the charter or not.]]

A REST/HTTP interface to the nodes is useful.  But based on my  
experience, such a device provides the most benefit as a full-blown  
gateway, not just a proxy.  In particular, just intercepting requests  
is not sufficient.  For example, the gateway may queue data/events  
sent periodically by a node which are slurped up by a REST/HTTP  
client.  The gateway may also provide additional metadata about the  
data (e.g. when it was received).  There's a number of additional non- 
proxy-like functions I can think of.  So I'd suggest changing the name  
to indicate gateway.

> light switch, and temperature sensor.

Again, let the set of application requirements drive the specific  
interface profiles we develop.

> network using these applications.

Good.

> Security, particularly keying of new Devices, is very challenging  
> for these applications. On one hand this needs to support models  
> where an end user can introduce a new device onto their network that  
> may have no display or not input capability's. On the other end this  
> may transport information about alarm systems or controlling door  
> locks to a building over a wireless network.

Important as well.  Though I wouldn't go so far as to say what is  
mandatory and what is not in the charter.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Oct 2009 08:33:43 +0100

Jonathan,

I believe we have enough requirements documents.

Application requirements are documented e.g. in the ZigBee/Homeplug  
MRD.  The ROLL documents also contain a lot of information about  
application requirements.  These have been focused on routing  
requirements in their later versions (and a lot of information that is  
useful to us has been removed), but people have already started  
resurrecting the earlier documents and retargeting them for 6lowapp.

Now, application *protocol* requirements. Well, there are general  
technical requirements of constrained nodes/networks; I think we know  
these (both the ROLL documents and the 6LoWPAN documents contain  
some).  I'd say beyond those there are no "requirements" for a  
protocol, unless you have an architecture.  E.g., if you don't know  
whether PEPs (or gateways) are part of the architecture, you don't  
know whether you are designing for 100 % end-to-end usage or for usage  
that can get help from a PEP where required.  That's why  
"requirements" and architecture are one milestone in the charter  
proposal.

I understand that to build a bridge, you first write a requirements  
document (how many cars per hour?), and then design the bridge.  This  
works well because bridges are a lot like each other, so you know what  
questions to ask (in essence, there is a well-known architecture for  
bridges).  That kind of engineering is what engineers are mostly  
taught to do and what "feels right" to many, even though it is often  
not the way successful information/communication technologies work is  
done.  In a design activity like the one we are undertaking,  
requirements (really: objectives) and solutions evolve in parallel.   
That's why it would not only be *slow* to spend a year on requirements  
first, but also be *wrong* fundamentally.

Back to the application requirements: I do agree we should focus on a  
small number of specific areas of application, at least for making  
sure we have thought through some specific examples for each in  
detail.  I think it would be useful if we called them out explicitly  
in the charter.  Right now I'm seeing a lot of interest in 6lowapp  
from Energy (SE V2 etc.) and building automation (which may or may not  
include home automation).  The charter does identify light switches,  
temp sensors, power meters, HVAC systems, and door locks as specific  
items that we will look at; so maybe we should be a bit more specific  
and identify the communication relationships we are addressing (and  
add light fixtures, plug-in vehicles and washing machines in the  
process).

Gruesse, Carsten

PS.: I wrote more on the rationale for trying not to get stuck in a  
requirements mire in
http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 30 Oct 2009 01:32:03 -0700

Hi Carsten,

On Oct 30, 2009, at 12:33 AM, Carsten Bormann wrote:

> Back to the application requirements: I do agree we should focus on  
> a small number of specific areas of application, at least for making  
> from Energy (SE V2 etc.) and building automation (which may or may  
> not include home automation).  The charter does identify light  
> switches, temp sensors, power meters, HVAC systems, and door locks  
> as specific items that we will look at; so maybe we should be a bit  
> more specific and identify the communication relationships we are  
> addressing (and add light fixtures, plug-in vehicles and washing  
> machines in the process).

It certainly would have helped me if the charter would have been more  
precise about what applications or subsets of applications we are  
trying to address.  Without that knowledge, its hard to say whether or  
not we have the proper requirements written anywhere.  BTW, I don't  
think the ZigBee/Homeplug MRD is sufficient in itself.  Is the TRD  
available?

Given the application(s), it would be even better if somewhere we  
indicated what functionality we plan to develop first.  Are we only  
addressing manipulation of attributes that are relatively small in  
size?  Are the most important profiles to get done first power, light,  
light switch, and temp?

In the end, if we are to take knowledge of the application  
requirements for granted, the charter should be precise about what we  
are addressing.  It's good to see that we are in line here.

> http://www.ietf.org/mail-archive/web/6lowapp/current/msg00038.html

I do prefer your suggested terminology of "objectives" vs.  
"requirements".

--
Jonathan Hui

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 30 Oct 2009 06:18:07 -0700

Hi Jonathan,

In ZigBee/HomePlug, we are working on a TRD to address the MRD and Use Cases
(have you also looked at the use cases?).   We hope to have a draft of the
TRD posted soon.

Don

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 1:32 AM
To: Carsten Bormann
Cc: Cullen Jennings; Don Sturek; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Hi Carsten,

--
Jonathan Hui

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 30 Oct 2009 06:25:41 -0700

Hi Carsten,

It would be good to avoid PEPs as much as possible.   These devices are
controversial in cost constrained deployments since they imply a standalone
box someplace (that the customer does not get benefit from functionally) or
some translation which eventually is outdated.

We were hoping to scope a useful, mainstream subset of existing protocols.
This is why we plan to start with HTTP (obviously not a full implementation
but whatever meaningful legal subset we can use) along with a RESTful
message exchange.  At least this is what we are going to start with, in
terms of interoperability testing.

Clearly the story does not stop here.  Ideally we would like to see as many
mainstream services as practical/possible deployed on these small devices
(hopefully without proxy).

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: Friday, October 30, 2009 12:34 AM
To: Jonathan Hui
Cc: Don Sturek; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Jonathan,

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 30 Oct 2009 08:09:00 -0700

Hi Don,

> some translation which eventually is outdated.

It seems that the desire to avoid the use of translation proxies/ 
gateways in SE 2 is driven by both business and technical reasons, is  
this accurate?  (Security may be another good reason to avoid the use  
of translation proxies/gateways).

Do you see value in a back-end service for SE 2 that can centrally  
buffer/store data from, accept and schedule requests to, and offer the  
data/node capabilities of large numbers of LLN devices in an  
aggregated and structured manner using one or more standard  
interfaces?  Such a service is not a proxy and also not really a  
gateway.  This is more of what I was envisioning that the PEP should  
really be, and the terms PEP and gateway do not capture that well.

--
Jonathan Hui

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 30 Oct 2009 08:20:42 -0700

Hi Jonathan,

Most utilities already have Data Aggregators in their network.  Those are
typically used in the neighborhood area network where collections of meters
are interfaced to the utility back office.  One example of this is Outage
notification.    Having a few meters tell you there is an outage is fine,
having all of the meters in Los Angeles tell you the power went out is not
helpful.......

Don

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 8:09 AM
To: [email-masked]
Cc: 'Carsten Bormann'; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Hi Don,

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 30 Oct 2009 08:48:56 -0700

Hi Don,

> having all of the meters in Los Angeles tell you the power went out  

Right.  Then I would ask if you would find it useful/necessary for  
this WG to work on standardizing a service that can effectively  
aggregate LLN devices?

I'm really asking these questions because I don't think it's obvious  
what pieces are necessary.  Even less obvious if we don't have clear- 
cut application targets.

--
Jonathan Hui

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 30 Oct 2009 09:02:18 -0700

Hi Jonathan,

Aggregators are great devices when defined by end customers to meet an
application need.  The trouble comes in when we introduce them for network
layer support in non-obvious places.

I think we should try to find solutions which avoid PEPs and other
aggregation devices in general.  If we find we have to have these devices,
we should work with those responsible for deployment to be sure this maps to
their solution space.

Don

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: Friday, October 30, 2009 8:49 AM
To: [email-masked]
Cc: 'Carsten Bormann'; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Hi Don,

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 30 Oct 2009 09:19:09 -0700

Hi Don,

> layer support in non-obvious places.

Exactly!  If we don't know what the service provider's requirements  
are, we can't design for them, much less avoid conflicting with them.

> we should work with those responsible for deployment to be sure this  

I would agree with this approach.

--
Jonathan Hui

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 31 Oct 2009 11:29:20 -0600

So trying to get specific advice about how to edit stuff here ...

So Jonathan sounds like you would like the list of existing use case /  
requirements document added to the charter as input to the WG and and  
also an explicit list of applications the WG will consider. That seems  
well worth trying.

Can you and other folks on the email list help

1) list the documents we can start with

2) list the applications or subsets of applications we should start  
with in the first phrase. Once we have a list we can decide if we need  
to prioritize are argue stuff in or out.

Thanks Cullen

On Oct 30, 2009, at 2:32 , Jonathan Hui wrote:

>> a small number of specific areas of application, at least for  
>> making sure we have thought through some specific examples for each  
>> in detail.  I think it would be useful if we called them out  
>> explicitly in the charter.  Right now I'm seeing a lot of interest  
>> in 6lowapp from Energy (SE V2 etc.) and building automation (which  
>> may or may not include home automation).  The charter does identify  
>> light switches, temp sensors, power meters, HVAC systems, and door  
>> locks as specific items that we will look at; so maybe we should be  
>> a bit more specific and identify the communication relationships we  
>> are addressing (and add light fixtures, plug-in vehicles and  
>> washing machines in the process).
>
> It certainly would have helped me if the charter would have been  
> more precise about what applications or subsets of applications we  
> are trying to address.  Without that knowledge, its hard to say  
> whether or not we have the proper requirements written anywhere.   
> BTW, I don't think the ZigBee/Homeplug MRD is sufficient in itself.   
> Is the TRD available?
>
> size?  Are the most important profiles to get done first power,  
> light, light switch, and temp?
>
> requirements for granted, the charter should be precise about what  
> we are addressing.  It's good to see that we are in line here.
>
>> Gruesse, Carsten
>>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 31 Oct 2009 11:29:27 -0600

On Oct 29, 2009, at 8:20 , Jukka Manner wrote:

> 1. This seems to indicate that 6lowapp will not be tied to any  
> existing work, it will work on its own goals, but in collaboration  
> with others (which is somewhat open as what it means). I would have  
> expected that 6lowapp would specifically look at existing work in  
> related WGs and see how build on top of that.

My mistake - I did not mean to imply that it was not layered on top of  
closely related existing work. I think most people assumed that this  
would run on top of a LoPAN but it seemed they also wanted it to be  
able to run on top of a other things including a normal IP LAN and  
WAN. Clearly this is all about same use cases as 6LoPAN and ties  
closing with 6LoPAN and ROLL as well as work going on at many other  
SDOs. However, I'm not sure what needs to be said. Are WG drafts with  
use case / requirements from other WG that we should be referencing?  
Give me ideas on what things you were thinking here. Clearly the IESG  
would not be keen on chartering a new WG to do something another WG  
was already charted to do - repeating work in two places seldom ends  
well :-) Can you suggest some specific text for the charter that you  
think would have fairly wide consent and captures what you are looking  
for here?

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 31 Oct 2009 11:29:41 -0600

On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:

> My comments:
>
> The charter seems to combine goals as well as architecture together  
> in one go. Probably can be simplified ? Specific comments below:
>
>
> Wireless Personal Area Networks (LoWPANs) are an example of this  
> type of network. These networks are becoming increasing important  
> for applications such as home automation, energy management, and the  
> resources on devices on a CNet. This includes applications to  
> monitor simple sensors such as a temperature gauge, light switch, or  
> power meter and control an actuator such as a light switch, heating  
> system, or door lock. Typical uses include power management and  
> reporting, and home automation.
>
> ARC> We are implicitly stating that devices in a lowpan will have  
> simple management requirements (kind of like set/get mostly). I'd  
> like to see this group also consider (in terms of usecases) what are  
> the various control functions that are desirable, given an internet  
> connect ecosystem? I don't think we should assume that just because  
> most home control was mostly about simple on/off/read  till date,  
> that is what we should architect for. It is a minimal requirement,  
> but not complete by itself.

You bring up an important architecture consideration in design of a  
system like this. Roughly I think about the different levels of data/ 
transaction models we could have as going something like this

In order of complexity...

1) simple set of fixed variables that could be controlled

2) a single flat list of dynamically changeable set of variables that  
can can take on simple types (I might place IPFIX as being somewhat  
close to this model)

3) a hierarchical list of variables that can be related (I'd place  
basic usage SNMP roughly in this category but more advanced usage of  
SNMP probably can do category 4)

4) a REST based approach (I'd place HTTP REST in this case)

5) a full RPC model (I'd place CORBA in this class)

Every use case I have seen so far could be solved by 3, 4, or 5. I  
think most people have expressed an opinion that about 4 looks about  
the right level of flexibility for this. So the questions is, if there  
is pretty good agreement on that, then I think we should just roll  
with it as tentative decision and see what it starts looking like as a  
design evolves. As the design evolves, one may find this was a bogus  
choice and need to revisit it. If you think there is a strong argument  
for 3 or 5 or even 1 or 2, lets get that info out on the list.

> actuators. Devices send message to change and query resources on  
> other devices. Devices can send notifications about changed resource  
> values to subscribed Devices. In other words, the architecture  
> requires push, pull and and a notify approach to manipulating  
> resources. As part of the framework for building these applications,  
> the WG will define a CNet Application Protocol (CoAP) for  
> manipulation or Resources on Devices. The framework will also  
> specify a way to define new interface profiles that can be defined  
> by vendors and other standards bodies to define the particular  
> Resources on a Device and what manipulation are possible.
>
> the Internet and the protocol used on the CNet. An application on  
> the general network can use HTTP REST to communicate with the PEP  
> which will use CoAP to manipulate the Resource on the Device. The WG  
> will define a mapping on the PEP from the CoAP to the a HTTP  REST  
> API. Each interface profile will define the Resources on the device  
> that application can manipulate and what manipulations are  
> possible.  This will determine the HTTP REST APIs on the PEPs and  
> the CoAP protocol encoding to manipulate the Resources on the Device  
> it will also specify an XML MINE type for each class of Device that  
> can be used to described the Resource state in the the body of HTTP  
> REST messages. The WG may also work on a mapping to SNMP on the PEP.  
> It is worth noting that the PEP does not have to be deployed at the  
> boundary of the CNet and the more general network but can be  
> deployed at various location in the network.
>
> ARC> I don't think HTTP to XX mapping should be assumed at this  
> stage. HTTP may be a popular protocol, but there could be others. So  
> a general goal of internet protocols to device control protocol  
> mapping is more suitable

OK - The way I want to try and derive us towards a decision here is  
get a list of candidate protocols then for each one ask the yes/no is  
the their agreement that we should do a mapping to that protocol.  The  
protocols I have heard so far are HTTP, SNMP,  SMTP. So two questions

1) what other protocols mapping should we do?

2) Given some people want HTTP, can you live with the answer to HTTP  
being yes and understanding that just because we said yes to HTTP does  
not mean we are saying no to everything else?

>
>
> The PEP boxes can provide various forms of "caching". For example,  
> if a temperature sensor is normally asleep but wakes up every five  
> temperature resource, it can respond with the last seen value  
> instead of trying to query the Device which is currently asleep. The  
> PEPs may also provide support for discovering devices that may not  
> be currently responding as they are temporarily asleep.
>

I don't know. I had someone I showed the charter to say, "but no I  
need a cache somewhere, these Device use low power" and I put this in  
to show that the PEP could be used this way.

> listens for broadcasts of Devices trying to imprint. Other Devices  
> are put in a "duckling" mode where they broad cast to the "mother  
> duck" Device then "imprint" by forming a new shared secret between  
> the two Devices. Once this is complete the devices are taken out of  
> this mode and can be use in a secure fashion.
>
> <etc>
>
> ARC> This seems to be a requirement specification of what a CoAP  
> should be. I think it should be left for a dedicated req doc, not as  
> part of a charter.

Fair enough. See my other thread on Architecture Sketch. I agree with  
you there are cons to doing something like this in the charter.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 31 Oct 2009 11:29:51 -0600

On Oct 29, 2009, at 13:25 , Arjun Roychowdhury wrote:

>
> On Thu, Oct 29, 2009 at 3:10 PM, Lisa Dusseault <[email-masked] 
> > wrote:
>
> ARC> I think this comment pretty much summarizes the difference of  
> thought between what I thought 6lowapp vs doing vs what you are  
> describing. The group name itself, "6lowapp" seems to specify it is  
> a group to to specificy low-power IP app protocols, and not a  
> subset. draft-bormann-6lowpan-6lowapp-problem-01 also seems to  
> indicate this group is dealing with the larger set.
>
> So my comment would be if this is not so, then it needs to be  
> explicitly stated, otherwise the natural understanding is 6lowapp is  
> the application protocol group for 6lowpan devices - and what comes  
> out of here, would likely be adopted going forward in deployments,
>
> I can respond to your other comments in more detail, but then again,  
> if the scope is going to be limited, then so be it.
>

This is a good point about the name. When I started talking to people  
about the use cases and requirements for this WG, it became clear to  
me that we might want a name that was different than 6LoAPP. By the  
time I figured this out the name of the BOF had already been submitted  
in the the scheduling for IETF 76 so the BOF name was somewhat locked  
down but we really need to talk about the name of the WG. We would not  
want a name that caused people to daw the wrong conclusions.

So to comment on scope for a second

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 31 Oct 2009 11:30:16 -0600

On Oct 29, 2009, at 8:37 , Don Sturek wrote:

> On the Commissioning methods, I think making the "Duckling" mode  
> mandatory as indicated in the text below should not be decided in  
> the charter.

Fair enough. Let me start a separate thread on this.

>  Unless this commissioning method has undergone some form of  
> security review, it could well be something we (at least in Smart  
> Energy) cannot use.

Agree, but even worse. The IETF is not going to publish any of this as  
an RFC until it has had reasonable security review so I certainly  
don't want anything that would be a significant innovation in security  
or is broken from a security point of view.

> It would be a shame to waste code space for something like this.
>
> While we (again Smart Energy) are looking at a RESTfull HTTP  
> architecture, it would be good to point out that this is only one  
> option.  It would be nice to see if other popular communication  
> solutions can work as well.

Yep - several other people have told me this too. What other popular  
protocols should we consider?

>
> One more thng:   The discussion below indicates two level of  
> communication:   PEPs and CoAps.   I would hope we could avoid  
> this.  It would be nice to address and communicate with CoAp devices  
> as you would with any other device on the internet whether a PEP was  
> present or not.  I would not want to have the group focused on this  
> type of gateway approach.

Agree - I was trying to make it clear any computer on the internet  
could talk CoAp directly to Device but failed to express that. Could  
you suggest some text to make that clear?

---

From: Shidan <[email-masked]>
Date: Sat, 31 Oct 2009 14:33:36 -0400

Hi Cullen, I would check the motivational draft Arjun and I submitted for
SIP.

> OK - The way I want to try and derive us towards a decision here is get a
> list of candidate protocols then for each one ask the yes/no is the their
> agreement that we should do a mapping to that protocol.  The protocols I
> have heard so far are HTTP, SNMP,  SMTP. So two questions
>

In general there are many practical applications which are using SIP and
XMPP for M2M communications. This should be a consideration.

>
> 2) Given some people want HTTP, can you live with the answer to HTTP being
> yes and understanding that just because we said yes to HTTP does not mean we
> are saying no to everything else?
>
>
Personally, I think HTTP is the most important and minimum protocol to
support.

---

From: "Don Sturek" <[email-masked]>
Date: Sat, 31 Oct 2009 17:09:55 -0700

Hi Cullen,

I don't have a lot to add to what you wrote below except on the question of
what other application protocols to suggest:
1)  We (the Smart Energy team) would like to use something that is
mainstream and extensible.  We could resort to a proprietary binary protocol
to address our near term needs but it would be a shame to do this
2)  We would like to start with assumption we can use a simplified version
of RESTfull HTTP with the following backup plans:		
      a.  Providing some alternative to TCP if we find we cannot use that
due to code size or performance on wireless mesh links (see my earlier note)
	b.  Providing some backup to HTTP text if we find the number of
packets generated causes congestion/throughput issues.

We welcome other suggestions like XMPP and SIP but we did look at those and
ruled them out for reasons like:
1)  Verboseness (using text string exchanges for devices with very small
transmit/receive packet sizes)
2)  Session management overhead

Don

---

From: "Don Sturek" <[email-masked]>
Date: Sat, 31 Oct 2009 17:15:16 -0700

Hi Cullen,

One important use case to consider:
1)  Devices to manage are running on 6LowPAN (using some 6LowAPP defined
protocol).   Controlling devices are running someplace on the wider
internet.
2)  Does this mean that the scope of protocol work in 6LowAPP needs to
identify this type of control as a valid use case?  
3)  Does the use of 6LowAPP protocols on the wider internet need to then be
in the scope of 6LowAPP?

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cullen Jennings
Sent: Saturday, October 31, 2009 10:29 AM
To: Jukka Manner
Cc: Don Sturek; [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

---

From: "Don Sturek" <[email-masked]>
Date: Sat, 31 Oct 2009 17:27:09 -0700

There are a lot of use cases to start with.  Here is a starter set:
1)  OpenHAN:
http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-%200808
19-1.pdf
2)  SmartGridipedia:
http://www.smartgridipedia.org/index.php/Category:Use_Cases, both the
Intelligrid and Southern California Edison use cases are good
3)  ZigBee/HomePlug Market Requirements and Use Cases (which we are using
for our Smart Energy V2 work):
http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf 

There are more is the list above is not enough.  For the NIST Smart Grid
standards work, several other groups are generating use cases as we
speak.....

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cullen Jennings
Sent: Saturday, October 31, 2009 10:29 AM
To: Jonathan Hui; Carsten Bormann
Cc: [email-masked]
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

Thanks Cullen