Re: [6lowapp] Next rev of CoRE Charter

[Behcet Sarikaya <[e-mail]>]

Instead of removing LoWPAN how about 
Low-Power Wireless Personal Area Networks (LoWPANs) 

add here 
with IEEE 802.15.4 or many other low power link layers.

That would require less changes.

My 2 cents.

Behcet




----- Original Message ----
> From: Cullen Jennings <[e-mail]>
> To: JP Vasseur <[e-mail]>
> Cc: [e-mail]
> Sent: Tue, February 2, 2010 3:50:52 PM
> Subject: Re: [6lowapp] Next rev of CoRE Charter
> 
> 
> Hi JP, 
> 
> Thanks for comments. Some questions inline before I figure out how to integrate 
> these.  If this email makes no sense, drop me a note and I'll give you a phone 
> call and figure out to sort it out. 
> 
> Cullen
> 
> 
> On Feb 2, 2010, at 12:57 AM, JP Vasseur wrote:
> 
> > Hi Cullen,
> > 
> > First comment is that I fully support the charter, and look forward to seeing 
> an active WG, lots of
> > items that we need to work on :-)
> > 
> > Comments below,
> > 
> > On Jan 30, 2010, at 7:16 PM, Cullen Jennings wrote:
> > 
> >> 
> >> Thanks to all the great comments form people and the work from Zach, Carsten, 
> and Lisa for this this version. This version clarified a bunch of issues and 
> also removed a bunch of text that did really need to be in the charter. 
> Documents tend to have words added over time and every so often they need to go 
> on a diet :-) I'm really happy with this version and my view is that it is 
> probably close enough to send to the IESG. Just to let everyone on the list know 
> the process here, what happens next is:
> >> 
> >> 1) See if there are any last minute screams on the email list about this 
> version of the charter
> >> 
> >> 2) Send it to the AD (Lisa). She might have some changes before she moves it 
> forward to the IESG but Lisa's been very involved along the way here so no 
> expecting any huge surprises at that pint
> >> 
> >> 3) Lisa puts in an schedule for IESG call and IAB and EISG look at it. Some 
> change might happen.
> >> 
> >> 4) The IESG sends it out to the whole community for and IETF Last Call. 
> Anyone including folks on this list can send comment. LIkely some changes.
> >> 
> >> 5) It gets put back on an IESG call for formal approval as a WG
> >> 
> >> There's variants of how things can happen but the above is roughly what I 
> expect to happen for this charter.
> >> 
> >> I've attached the charter below. If you see something in it you really can't 
> live with, yell. If you see typos, things that need better wording, or so on, 
> send proposed text changes.
> >> 
> >> One chug was we removed the word CoGII and instead just talked about 
> translators. Another word we could that was suggested was "proxy" or just talk 
> about things that provide a "mapping function". I really don't much of an 
> opinion about which of these words, or others, would be best but if people have 
> thoughts, Speak up.
> >> 
> >> Thanks, Cullen
> >> 
> >> ------------------------------------------------------------
> >> 
> >> 
> >> CoRE (Constrained RESTful Environments)
> >> 
> >> CoRE is providing a framework for resource-oriented applications
> >> intended to run on constrained IP networks.  A constrained IP network
> >> has limited packet sizes, may exhibit a high degree of packet loss, and
> >> may have a substantial number of devices that may be powered off at any
> >> point in time but periodically "wake up" for brief periods of time.
> > 
> > JP>
> > 1) I would suggest to first try to adopt a common "language" across Working
> > Groups. In ROLL, we use the term LLN to refer to Low power and Lossy Networks.
> > Using similar terminology could help.
> 
> Agree with common language in general but in some earlier but in earlier 
> discussion I understood from people and LLN was a description about the network 
> and not so much the constraints of the hosts that ran on it. (I may have totally 
> misunderstood what they were saying) It seemed like what people were trying to 
> say here was a related to but not the same as LLN. Can you point at the best 
> definition of LLN over in ROLL and perhaps I can try and sort this out. 
> 
> > 2) I'd slightly reword to say that LLN are characterized by constrained 
> environments
> > in terms of devices (CPU, Memory, power) interconnected by low speed lossy 
> links.
> 
> > 
> >> These networks and the nodes within them are characterized by severe
> >> limits on throughput, available power, and particularly on the
> >> complexity that can be supported with limited code size and limited RAM
> >> per node.  More generally, we speak of constrained networks whenever at
> >> least some of the nodes and networks involved exhibit these
> >> characteristics.  Low-Power Wireless Personal Area Networks (LoWPANs)
> >> are an example of this type of network. LoWPANs are part of home and
> >> building automation, energy management, and the Internet of Things.
> > 
> > JP> I would definitely suggest to remove that last sentence ... We've been 
> struggling
> > with the term 6lowpan, trying to explain that "The Internet Of Things" refers 
> to the
> > use of IPv6 in LLNs. 6LoWPAN is one instantiation for IPv6 in IEEE 802.15.4 
> but
> > there are many other low power link layers, and this is one of the beauty of 
> IP to
> > be able to support those. The Internet of things will (and is already) made of 
> such
> > low power link layers. That looks like a cosmetic terminology comment but it 
> will
> > avoid a ton of confusion.
> 
> I think that was my mistake - Thanks for catching. What I was trying to do is 
> motivate they type of places that might be able to use the output of the CoRE 
> WG. What I was trying to say is "Constrained networks can occur as part of home 
> and building automation, energy management, and the Internet of Things." 
> 
> > 
> >> 
> >> The CoRE working group will define a framework for a limited class of
> >> applications: those that deal with the manipulation of simple resources
> >> on constrained networks. This includes applications to monitor simple
> >> sensors (e.g. temperature sensors, light switches, and power meters), to
> >> control actuators (e.g. light switches, heating controllers, and door
> >> locks), and to manage devices.
> >> 
> >> The general architecture consists of nodes on the constrained network,
> >> called Devices, that are responsible for one or more Resources that may
> >> represent sensors, actuators, combinations of values or other
> >> information.  Devices send messages to change and query resources on
> >> other Devices. Devices can send notifications about changed resource
> >> values to Devices that have subscribed to receive notification about
> >> changes. A Device can also publish or be queried about its
> >> description. Typically a single physical host on the network would have
> >> just one Device but a host may represent multiple logical Devices. As
> >> part of the framework for building these applications, the WG will
> >> define a Constrained Application Protocol (CoAP) for the manipulation of
> >> Resources on a Device.
> >> 
> >> CoAP will be designed for use between Devices on the same constrained
> >> network, between Devices and general nodes on the Internet, and between
> >> Devices on different constrained networks both joined by an
> >> internet. CoAP targets the type of operating environments defined in the
> >> ROLL and 6LOWPAN working groups which have additional constraints
> >> compared to normal IP networks, but the CoAP protocol will also operate
> >> over traditional IP networks.
> >> 
> >> There also may be translators that interconnect between other Internet
> >> protocols and the Devices using the CoAP protocol.  The WG will define a
> >> mapping from CoAP to an HTTP REST API; this mapping will not depend on a
> >> specific application. It is worth noting that translation does not have
> >> to occur at the boundary between the constrained network and the more
> >> general network, but can be deployed at various locations in the
> >> unconstrained network.
> > 
> > It might be worth clearly spelling out that such "Translators" are not 
> protocol
> > translation gateways but sensor, devices, ... are IPv6 enabled devices.
> 
> I might not be understanding what point you are getting at here. Uh, I think we 
> have had pretty clear input the CoRE application level could be running over v4 
> or v6. The charters tried to be pretty explicit that it is not v6 specific. I'm 
> trying to reflect the consensus here and the actually consensus call would be up 
> to Lisa as the AD but I did get a fair amount of input on topic and it all 
> seemed to go towards the direction of, yes this definitely has to work on v6, 
> but to make something that is above layer 3 be only for v6 would encourage layer 
> violations of the worst kind and there was no need for that. I think the general 
> approach for IETF application layer protocols is to work on both v4 and v6 
> unless there is some really good reason they can't. 
> 
> > 
> >> 
> >> CoAP will support 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 a translator that has subscribed,
> >> when the translator 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.
> > 
> > Completely in line with that architecture. Just note that nothing prevent an 
> end
> > device with enough resource to natively support HTTP though.
> 
> Yep - agree. But do we need to say anything about that here? I'm just not sure 
> what words to put in. Clearly we can do HTTP/Rest API over IP today without any 
> new standardization. Nothing here would be saying don't do that. 
> 
> 
> > 
> >> 
> >> The initial work item of the WG is to define a protocol specification
> >> for CoAP that includes:
> >> 
> >> 1) The ability to create, read, update and delete a Resource on a
> >>  Device.
> >> 
> >> 2) The ability to allow a Device to publish a value or event to another
> >>  Device that has subscribed to be notified of changes, as well as the
> >>  way for a Device to subscribe to receive publishes from another
> >>  Device.
> >> 
> >> 3) The ability to support a non-reliable multicast message to be sent to
> >>  a group of Devices to manipulate a resource on all the Devices.
> >> 
> >> 4) The core CoAP functionality MUST operate well over UDP and UDP MUST
> >>  be implemented on CoAP Devices.  There may be OPTIONAL functions in
> >>  CoAP (e.g. delivery of larger chunks of data) which if implemented
> >>  are implemented over TCP. Applications which require the optional TCP
> >>  features will limit themselves to a narrower subset of deployment
> >>  cases.
> > 
> > I would suggest to delete the last sentence though.
> 
> There as a lot of discussion leading to this sentence and I'm cautions to open 
> the can worms. The issues of taking it out is the following. Clearly some people 
> think that TCP won't meet all the needs or we would probably not bother to do 
> UDP at all. But given you are doing UDP, why would you bother with TCP, and the 
> answer is there are probably good reasons to use it in some cases. Then the 
> questions comes up, so OK what about when you don't have it. We end of with this 
> circular argument about the everything that works over UDP must work over TCP 
> and visa versa so why have both. This sentence in the charter tries to break 
> that argument by pointing out the obvious which is some stuff is just not going 
> to be work as well, if at all, over UDP and also TCP is not going to be 
> available 100% of the time. I realize this paragraph makes almost no sense but I 
> hope you can figure out what I am getting at if not, glad to give you a call and 
> get to the point where I can explain well enou
> gh to fix this email
> 
> > 
> >> 
> >> 5) A definition of how to use CoAP to advertise about or query for a
> >>  Device's description. This description may include the device name
> >>  and a list of its Resources, each with a URL, an interface
> >>  description URI (pointing e.g. to a WADL document) and an optional
> >>  name. The name taxonomy used for this description will be consistent
> >>  with other IETF work, e.g. draft-cheshire-dnsext-dns-sd.
> > 
> > Does that cover the discovery aspects (of both the devices and the services)?
> > If so, great otherwise i would suggest to clearly spell it out since this is 
> in my
> > opinion a core components.
> 
> It covers the naming aspects of device and services. (More or discover bellow)
> 
> > 
> >> 
> >> 6) Specification for the HTTP REST based API and translation to
> >>  communicate with Devices. Translation should make use of Device
> >>  description information and should not need code updates to deal with
> >>  new Devices.
> >> 
> >> 7) Consider operational and manageability aspects of the protocol and at
> >>  a minimum provide a way to tell if a Device is powered on or not.
> > 
> > That is a really a "minimum" ... do we need to be so restrictive ?
> 
> It's definitely a pretty minimal minimum. The question is what do we add beyond 
> that and do we need to do it in the charter. Note this bullet does not stop the 
> WG from doing more, just sets a minimum bar. Honestly, this bar is so low but 
> every time I tried to raise the bar, I failed. Ideas welcome. I pretty much 
> expect that folks would have a way of finding out things like firmware version 
> and such but do to the privacy aspects of some of that, people have argued that 
> would be one of the "Resources" defined which you can access via the CoRE 
> protocol and not part of the CoRE protocol itself. I'm working with Dan 
> Romascanu (Ops AD) has been following this charter and I know he is has sent me 
> some emails that I have not got to yet so I expect to be able to improve this 
> point  a bit but doubt we can figure out any really significant changes that can 
> get widespread agreement. 
> 
> > 
> >> 
> >> The working group will not develop a reliable multicast solution, and
> >> will not develop a general service discovery solution.
> > 
> > That is the part I was a bit worried about ... without service discovery, 
> deployments will
> > certainly be extremely difficult. We should at least work on the selection of 
> a discovery
> > protocols, many candidates exist ... and potentially re-charter, should 
> protocol extension
> > will required.
> 
> So I share your concern and was very skeptical of how this could be useful 
> without a Discovery protocol. However, at the BOF, there was a surprisingly 
> strong HUM at the end to throw Discovery under the bus. This sort of freaked me 
> out at first but as I came to talk to more people about it, I realized that 
> people had widely varying views of what Discovery meant. Here's my current 
> understanding of what sort of "Discover" in the scope of this charter and what 
> is out of scope. 
> 
> First, a discovery protocol can be decoupled from a data transfer protocol. For 
> example, a printer can be discovered with UPnP, Bonjour, SLP, etc even though 
> one might use IPP to print to it. What we are trying to do here is more the IPP 
> like protocol. Second, the charter has the word " A Device can also publish or 
> be queried about its description." I'll update this a bit but the intention was, 
> if you know the IP address of a Device, you can ask it what resources it 
> supports - basically what's it profile. A device should also decide to publish 
> out to other devices what resources it supports. It could publish them to a 
> multicast group. A device could also sent out to multicast group what resources 
> do you support and get back answers from many devices. Some people think this is 
> discover and many do not. They think it is just a device saying what 
> characteristics it has and consider Discover much more complicated.  The other 
> part in the proposed charter around discover is being c
> onsistent with existing naming constraints. The goal here is to make sure that 
> whatever this WG selects around name devices and services, it's got to make sure 
> that this is not impossible for an application to use in some multicast DNS 
> discover protocol. 
> 
> That my rough, and perhaps somewhat confused, interpretation of the state of the 
> current charter and given the strong HUMs at the end of the BOF, I don't see how 
> we have this WG take on a full blown discovery effort without re-charting (or 
> re-boffing) which is something I am perfectly happy to delay to do later.
> 
> 
> >> description. 
> > 
> >> 
> >> Security, particularly keying of new Devices, is very challenging for
> >> these applications. The WG will work to select approaches to security
> >> bootstrapping which are realistic given the constraints and requirements
> >> of the network.  To ensure that any two nodes can join together, all
> >> nodes must implement at least one universal bootstrapping method.
> >> 
> >> Security can be achieved using either session security or object
> >> security.  For both object and session security, the WG will work with
> >> the security area to select appropriate security framework and protocol
> >> as well as selecting a minimal required to implement cipher suite. CoAP
> >> will initially look at CMS (RFC 5652), TLS/DTLS, and EAP.
> >> 
> >> The WG will coordinate on requirements from many organizations including
> >> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI,
> >> ASHRAE/BACnet; other SDOs and organizations. The WG will closely
> >> coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate
> >> groups in the IETF OPS and Security areas.
> >> 
> >> Milestones:
> >> 
> >> Apr 2010 - Select WG document for basis of the CoAP protocol
> >> 
> >> Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API
> >>          submitted to IESG as PS
> >> 
> >> Dec 2010 - Constrained security bootstrapping specification submitted to
> >>          IESG as PS
> >> 
> >> Jan 2011 - Recharter to add things reduced out of initial scope
> >> 
> >> 
> >> _______________________________________________
> >> 6lowapp mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/6lowapp
> > 
> 
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp