Subject: Re: [6lowapp] Architecture Sketch in Charter

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 1 Nov 2009 09:50:54 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings

> 
> 4) The OAM folks must be thinking, so how is this different 
> from what we do every single day?
> 

I prefer the term 'OPS folks' :-) OAM is just one of the tools in our
kit. 

This is not completely new stuff for OPS. Actually we have already seen
similar work done in other SDOs for various 'low-xxx' devices attached
to networks. The typical challenges are the low resources on the device,
the mapping and sometimes optimization of protocols on specific
transports and the security model which usually offers less at the lower
level than management or OAM protocols are used to. Solutions exist and
they are not rocket science, but it is important to think about the
operational model and about the way the network will be managed from the
start. When operational and manageability aspects are left for a later
stage there is always the risk that the management solution will be to
expensive to implement and deploy, and this will impact interoperability
and scalability of the overall technology. From this point of view I am
concerned to see the item 'Mar 2012 - Ops & Management advice to IESG as
Info' showing up almost two years later than the architecture
requirements in the charter proposal. I think this item should be
synchronized or come just a short delay after the core protocol
requirements in the proposed WG scheduled.

---

From: Shidan <[email-masked]>
Date: Sun, 1 Nov 2009 18:29:04 -0400

Hi Don, just the fact that ZigBee will move to IP is great progress and we
have to consider that maybe its 802.15.4 and HomePlug today, but this will
hopefully be something that opens up utilities and vendors to many other
options. So I fully agree this has to be something that makes sense and
works well on the net without gateways and proxies. This
was significant hurdle in my eyes and seems to have been overcome by your
work and this hopefully this WG for the utility HANs.

I think there is sufficient time to examine the systems I have talked about
and I think if one of those systems can be considered a base CoAp protocol
and supported officially, in the not too distant future, by the energy
industry, it would be a real benefit to how this technology evolves in
general.

On Sat, Oct 31, 2009 at 7:22 PM, Don Sturek <[email-masked]> wrote:

>  Hi Shidan,
>
>
>
> All of this sounds fantastic, however:
>
> 1)       The Smart Metering work is not going to wait while we sort out
> all of this and then figure out what standards we need.
>
>
>
> The reality is that early smart metering deployments need to start next
> year.  We need to figure out how to supply a “Generation 1” solution that
> allows scalability.
>
>
>
> I have provided what we (the ZigBee and utility team) think is
> possible/practical for us to deploy in the short term.  If what is proposed
> (RESTfull HTTP, Extensions to SLP for tokenization, W3C EXi, etc.) is not a
> good starting point, let’s discuss. If what you wrote below  builds on what
> is proposed for the near term then we are in alignment.   If we have to wait
> an extended time to finalize a series of new standards to redefine HAN
> automation, then we will miss our window of relevance (at least in my
> opinion).
>
>
> Don
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Shidan
> *Sent:* Saturday, October 31, 2009 3:42 PM
> *To:* Cullen Jennings
> *Cc:* [email-masked]
> *Subject:* Re: [6lowapp] Architecture Sketch in Charter
>
>
>
> Hi Fluffy,
>
>
>
> I definitely agree with your overall sentiment, but one thing that I always
> find dissapointing is when people give me the "turn on and off" garage
> doors, thermostats, etc as the only examples of what a HAN should be about.
> I think this is part of the reason some, specially me, are a little confused
> by the WG.
>
>
>
> The truth is, I'm personally not looking for a X10, legacy 802.15.4, KNX,
> etc replacement; they do a fine job of turning things on and off. Let me
> list a few things I would like in my HAN:
>
>
>
> 1) I want a network that goes beyond enabling me to discover and control a
> device to one that enables devices to discover, control and communicate with
> each other and mixed groups of devices and people.
>
>
>
> 2) I want devices to do things based on time and other arbitrary policies
> as part of the network
>
>
>
> 3) I want mobile & secure smart objects to take advantage of pervasive
> global networks and objects that are location aware.
>
>
>
> 4) I want a system that can evolve so that when it makes economic sense,
> the physical components of a smart appliance are "smart components"
> themselves. I also see a day when people will be upgrading the features and
> functionality of their washing machine through a
>
> firmware upgrade.The last two are probably sound silly now, but they're
> real considerations of how things can evolve.
>
>
>
> The truth of the matter is that even with X10 and gateways, except for
> device mobility, most of this is possible. It's further true that the most
> difficult challenge of HANs is not the networking but end user
> programmability and moving intelligence to the network will help in
> developing these systems.
>
>
>
> Right now, the difficulty I'm having is that it almost seems, and this
> could be a wrong interpretation I hope, that this working group is saying
> "let's forget about addressing the greater problem of HANs through network
> intelligence and let's just focus on satisfying the bare minimum needs of
> the energy industry so they can move to IP" and "then we will let the system
> evolve."
>
>
>
> Another approach could be that this working group could start by
> considering the HAN application layers like UPnP and see how they need to
> evolve for pervasive access, where they have gone wrong for developers and
> so on and then see how much of this better system you define can be brought
> down to LoPANs. This is something I think can be done in the time frames
> this WG has proposed and anything that comes out of it would work great for
> the energy industry as well.
>
>
>
> Of course, even better would be a general application layer framework for
> LoPANS, but since this is technological limitation, I think looking at
> requirements is absolutely necessary.
>
>
>
> A side note, I definitely think SIP and XMPP are relevant in this field
> Cullen, there is a reason why so many M2M applications are using XMPP,
> specially in BRIC countries. There is also a reason why the leading demand
> response provider is using XMPP today, if you can take this all the way to
> the home and on AMI networks then why not? There is also a reason why the
> few MSOs and incumbents that I know of who are offering home media
> management  and media delivery to connected devices are switching to
> SIP-DLNA gateways. Again, this is not even the real issue, who really cares
> what you name a protocol as long as it works and the proper requirements
> have been considered. My concern above is much more important.
>
>
>
> Shidan Gouran
>
>
>
> On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings <[email-masked]> wrote:
>
>
> Right now the draft charter has a sketch of some of the key parts of the
> architecture. I'd like to talk about the pro's and cons of putting this in a
> charter. Typically charters don't have this. Many BOFs fail when all the
> people in the room don't lave having a common idea of what the group will
> do. Typically  the architecture is developed in a draft and often can take
> considerable time however there's nothing stopping this type of information
> form being in a charter. Now this effort is a bit different from your
> typically BOF. Let me list some differences:
>
> 1) This is not meant to run on normal networks. We've told the transport
> folks, yah, we are going to have to make different assumptions than normal
> application protocols make because there some special stuff going on here.
> That makes the Transport and INT people very nervous.
>
> 2) We told the security people, none of your off the shelf security
> approaches will work for us because we have special requirements. We are not
> even 100% sure it is feasibly to simultaneously satisfy all the
> requirements. That makes the Security people, uh, prickly.
>
> 3) Some people have suggest that SIP might be just the thing to build on
> over for things like controlling a garage door opener.  Many (but not all)
> SIP folks feel that SIP is for User to User communications and often use SIP
> to control the garage door and the prototypical example of what should *not*
> be done with SIP. This makes the RAI people want to come and say "hi". I'm
> not saying we could not use SIP but I am saying the SIP people would want to
> come and talk about the issues before that decision got made. Hopefully they
> won't ask if any of this has any real time application properties or
> infrastructure they could help with.
>
> 4) The OAM folks must be thinking, so how is this different from what we do
> every single day?
>
> 5) The INT and Routing guys want to know how this related to work they are
> doing.
>
> 6) I've had a few questions that loosely translated to "so what feature of
> IPv6 are you using to guarantee that this will only work on a v6 network".
>
> If we told the DNS guys we were consider doing all our senor reading use
> DNS so we could leverage the DNS caching we would have pretty much every
> area "concerned".
>
> People have questions. Lots of questions. The challenge for a successful
> BOF like this is to put together a coherent story of what the big picture
> looks like and how it all hangs together. I believe we have a reasonable
> chance of having a WG approved if we can show that there is a group of
> people that have
>
> 1) a clear idea of what they want to build
>
> 2) the same common idea of what it is
>
> 3) it is an engineering project, and not science project requiring
> invention of new techniques
>
> 4) it meets the type of requirements the IETF has for standards track work
>
> The quickest way to do this would be to have in some document that we take
> into the BOF use cases, requirements, and a high level architecture. We have
> drafts with use case and requirements and we can refine theses int he slides
> used in the BOF. If we can agree on an architecture, we can stuff that in
> the charter.
>
> I'm probably a bit naive to think we can come up with a sketch of an
> architecture and agree to it in the BOF. But if we do, we have a chance at
> having the a protocol document finished before 2011.
>
> A more tried and true approach to this would be to work on the requirement,
> use case, and architecture in some ad-hoc meetings then go for a BOF. The
> P2PSIP WG had problems similar to this WG in that they were going to have
> some harder than average transport and security issues. They meant for
> multiple hours at every IETF for multiple years *before* the WG was
> approved. Lots of the meetings had around 100 people with pretty substantial
> effort.
>
> Another approach would be to charter just to do requirements then recharter
> to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottle
> of scotch that would not finish before 2011 and even odds on a bottle of
> scotch it would not finish before 2012.
>
> Many people have expressed that time is of the essence on this work and
> something that delivers in 2012 will be of very little deployment value. I'm
> not in a good position to evaluate how quickly something is needed here but
> I'm happy to take everything people tell m at when this is needed at face
> value.
>
> The sponsoring AD has read me the riot act on scope for the initial set of
> work, make this a small bite size chunk that meets a reasonable set of needs
> and we can complete quickly. As that completes, I'm sure there would be no
> problem re-charting to expand the scope for more things or forming other WG
> to take on related work.
>
> So bottom line, I'm trying to drive this to figure out what is small bite
> size chunk that everyone could live with for the initial stuff to be worked
> on. If we are lucky, we can end up agreeing on requirements, uses cases, and
> a high level sketch of the architecture without a long drawn out process.
>  If this fails, and I admit it very well could, well then we can just move
> back to some other way of dealing with this.
>
> A good charter is a plan for work as well as something that constrains the
> number of possibilities a WG has to consider. Now clearly we can't constrain
> things beyond what is needed. If we can mange to agree on a tight charter,
> the WG will be able to progress work very rapidly. If we fail to do this in
> the next few week, having tried will not set back the work in any
> significant way.
>
> I hope this explains, I'm not  trying to convince anyone the architecture
> in the draft is the right one.  I'm just trying to convince people to fix it
> before the BOF.
>
> Sorry for such a long email,
> Cullen
>
>
>
>
>
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Nov 2009 22:47:15 -0700

All these things sound great, but pealing away the excitement how do  
we find some protocols, that if we define them, would enable the type  
of exciting intelligent network you are are thinking about. For  
example, much of what made things like gmail and facebook possible are  
a handful of technologies: JavaScript, HTML, HTTP, TLS, TCP, DNS, IP  
and routing. How can we find a few simple technologies that when  
implemented in standardized ways between vendors would enable the  
stuff you are talking about. What's missing? What do we need. I'm  
trying to drag this back to an engineering task.

PS - On topic of XMPP and SIP. No argument from me that these are not  
important protocols for real time applications. I'm perfectly happy to  
see them includes as things to consider.

On Oct 31, 2009, at 4:41 PM, Shidan wrote:

> Hi Fluffy,
>
> I definitely agree with your overall sentiment, but one thing that I  
> always find dissapointing is when people give me the "turn on and  
> off" garage doors, thermostats, etc as the only examples of what a  
> HAN should be about. I think this is part of the reason some,  
> specially me, are a little confused by the WG.
>
> The truth is, I'm personally not looking for a X10, legacy 802.15.4,  
> KNX, etc replacement; they do a fine job of turning things on and  
> off. Let me list a few things I would like in my HAN:
>
> 1) I want a network that goes beyond enabling me to discover and  
> control a device to one that enables devices to discover, control  
> and communicate with each other and mixed groups of devices and  
> people.
>
> 2) I want devices to do things based on time and other arbitrary  
> policies as part of the network
>
> 3) I want mobile & secure smart objects to take advantage of  
> pervasive global networks and objects that are location aware.
>
> 4) I want a system that can evolve so that when it makes economic  
> sense, the physical components of a smart appliance are "smart  
> components" themselves. I also see a day when people will be  
> upgrading the features and functionality of their washing machine  
> through a
> firmware upgrade.The last two are probably sound silly now, but  
> they're real considerations of how things can evolve.
>
> The truth of the matter is that even with X10 and gateways, except  
> for device mobility, most of this is possible. It's further true  
> that the most difficult challenge of HANs is not the networking but  
> end user programmability and moving intelligence to the network will  
> help in developing these systems.
>
> Right now, the difficulty I'm having is that it almost seems, and  
> this could be a wrong interpretation I hope, that this working group  
> is saying "let's forget about addressing the greater problem of HANs  
> through network intelligence and let's just focus on satisfying the  
> bare minimum needs of the energy industry so they can move to IP"  
> and "then we will let the system evolve."
>
> considering the HAN application layers like UPnP and see how they  
> need to evolve for pervasive access, where they have gone wrong for  
> developers and so on and then see how much of this better system you  
> define can be brought down to LoPANs. This is something I think can  
> be done in the time frames this WG has proposed and anything that  
> comes out of it would work great for the energy industry as well.
>
> Of course, even better would be a general application layer  
> framework for LoPANS, but since this is technological limitation, I  
> think looking at requirements is absolutely necessary.
>
> A side note, I definitely think SIP and XMPP are relevant in this  
> field Cullen, there is a reason why so many M2M applications are  
> using XMPP, specially in BRIC countries. There is also a reason why  
> the leading demand response provider is using XMPP today, if you can  
> take this all the way to the home and on AMI networks then why not?  
> There is also a reason why the few MSOs and incumbents that I know  
> of who are offering home media management  and media delivery to  
> connected devices are switching to SIP-DLNA gateways. Again, this is  
> not even the real issue, who really cares what you name a protocol  
> as long as it works and the proper requirements have been  
> considered. My concern above is much more important.
>
> Shidan Gouran
>
> Right now the draft charter has a sketch of some of the key parts of  
> the architecture. I'd like to talk about the pro's and cons of  
> putting this in a charter. Typically charters don't have this. Many  
> BOFs fail when all the people in the room don't lave having a common  
> idea of what the group will do. Typically  the architecture is  
> developed in a draft and often can take considerable time however  
> there's nothing stopping this type of information form being in a  
> charter. Now this effort is a bit different from your typically BOF.  
> Let me list some differences:
>
> 1) This is not meant to run on normal networks. We've told the  
> transport folks, yah, we are going to have to make different  
> assumptions than normal application protocols make because there  
> some special stuff going on here. That makes the Transport and INT  
> people very nervous.
>
> approaches will work for us because we have special requirements. We  
> are not even 100% sure it is feasibly to simultaneously satisfy all  
> the requirements. That makes the Security people, uh, prickly.
>
> 3) Some people have suggest that SIP might be just the thing to  
> build on over for things like controlling a garage door opener.   
> Many (but not all) SIP folks feel that SIP is for User to User  
> communications and often use SIP to control the garage door and the  
> prototypical example of what should *not* be done with SIP. This  
> makes the RAI people want to come and say "hi". I'm not saying we  
> could not use SIP but I am saying the SIP people would want to come  
> and talk about the issues before that decision got made. Hopefully  
> they won't ask if any of this has any real time application  
> properties or infrastructure they could help with.
>
> 4) The OAM folks must be thinking, so how is this different from  
> what we do every single day?
>
> 5) The INT and Routing guys want to know how this related to work  
> they are doing.
>
> 6) I've had a few questions that loosely translated to "so what  
> feature of IPv6 are you using to guarantee that this will only work  
> on a v6 network".
>
> If we told the DNS guys we were consider doing all our senor reading  
> use DNS so we could leverage the DNS caching we would have pretty  
> much every area "concerned".
>
> People have questions. Lots of questions. The challenge for a  
> successful BOF like this is to put together a coherent story of what  
> the big picture looks like and how it all hangs together. I believe  
> we have a reasonable chance of having a WG approved if we can show  
> that there is a group of people that have
>
> The quickest way to do this would be to have in some document that  
> we take into the BOF use cases, requirements, and a high level  
> architecture. We have drafts with use case and requirements and we  
> can refine theses int he slides used in the BOF. If we can agree on  
> an architecture, we can stuff that in the charter.
>
> architecture and agree to it in the BOF. But if we do, we have a  
> chance at having the a protocol document finished before 2011.
>
> A more tried and true approach to this would be to work on the  
> requirement, use case, and architecture in some ad-hoc meetings then  
> go for a BOF. The P2PSIP WG had problems similar to this WG in that  
> they were going to have some harder than average transport and  
> security issues. They meant for multiple hours at every IETF for  
> multiple years *before* the WG was approved. Lots of the meetings  
> had around 100 people with pretty substantial effort.
>
> Another approach would be to charter just to do requirements then  
> recharter to do the protocols. I'd bet anyone on odds of a bottle of  
> beer to a bottle of scotch that would not finish before 2011 and  
> even odds on a bottle of scotch it would not finish before 2012.
>
> Many people have expressed that time is of the essence on this work  
> and something that delivers in 2012 will be of very little  
> deployment value. I'm not in a good position to evaluate how quickly  
> something is needed here but I'm happy to take everything people  
> tell m at when this is needed at face value.
>
> The sponsoring AD has read me the riot act on scope for the initial  
> set of work, make this a small bite size chunk that meets a  
> reasonable set of needs and we can complete quickly. As that  
> completes, I'm sure there would be no problem re-charting to expand  
> the scope for more things or forming other WG to take on related work.
>
> So bottom line, I'm trying to drive this to figure out what is small  
> bite size chunk that everyone could live with for the initial stuff  
> to be worked on. If we are lucky, we can end up agreeing on  
> requirements, uses cases, and a high level sketch of the  
> architecture without a long drawn out process.  If this fails, and I  
> admit it very well could, well then we can just move back to some  
> other way of dealing with this.
>
> A good charter is a plan for work as well as something that  
> constrains the number of possibilities a WG has to consider. Now  
> clearly we can't constrain things beyond what is needed. If we can  
> mange to agree on a tight charter, the WG will be able to progress  
> work very rapidly. If we fail to do this in the next few week,  
> having tried will not set back the work in any significant way.
>
> I hope this explains, I'm not  trying to convince anyone the  
> architecture in the draft is the right one.  I'm just trying to  
> convince people to fix it before the BOF.
>

---

From: Shidan <[email-masked]>
Date: Tue, 3 Nov 2009 16:48:49 -0500

Hi Cullen, this is actually part of my point.

HTML,  HTTP and DNS make a great distributed database. On the other
hand web browsers are evolving beyond this and web patterns are
emerging to meet the needs of a standardized OS. But, using Gmail as
an example, if we could have avoided compiling Java to JavaScript and
HTML(GWT), three layers of virtual machines and expanding the
underlying technologies of the web just to make a network accessible
email client possible, we would have seen much more exciting products
by now. Don't get me wrong, given the circumstances, it's great that
people have been able to innovate and that the browser is evolving to
meet the need for a standardized OS.

Now that we have a clean slate and since no one is encumbered by
product decisions based on business competition and politics, and
lessons learned from those same web applications you mention, I think
these are some things we want implemented in a standardized manner in
CoApp:

1) Everything the Web and HTTP offers for a distributed database / linked data
2) Presence
3) Addressing groups & forking
4) Pub/Sub
5) Offer/Answer Exchange
6) Rendevouz
7) Everything the Web has to offer for messaging & extensibility

I think this sort of HTTP+ or RESTfull+ would be a better start to
meet the needs of things like home automation, energy management and
home health care and as I mentioned we are working on a more detailed
paper for this.

On Tue, Nov 3, 2009 at 12:47 AM, Cullen Jennings <[email-masked]> wrote:
>
> All these things sound great, but pealing away the excitement how do we find some protocols, that if we define them, would enable the type of exciting intelligent network you are are thinking about. For example, much of what made things like gmail and facebook possible are a handful of technologies: JavaScript, HTML, HTTP, TLS, TCP, DNS, IP and routing. How can we find a few simple technologies that when implemented in standardized ways between vendors would enable the stuff you are talking about. What's missing? What do we need. I'm trying to drag this back to an engineering task.
>
> PS - On topic of XMPP and SIP. No argument from me that these are not important protocols for real time applications. I'm perfectly happy to see them includes as things to consider.
>
>> I definitely agree with your overall sentiment, but one thing that I always find dissapointing is when people give me the "turn on and off" garage doors, thermostats, etc as the only examples of what a HAN should be about. I think this is part of the reason some, specially me, are a little confused by the WG.
>>
>> The truth is, I'm personally not looking for a X10, legacy 802.15.4, KNX, etc replacement; they do a fine job of turning things on and off. Let me list a few things I would like in my HAN:
>>
>> 1) I want a network that goes beyond enabling me to discover and control a device to one that enables devices to discover, control and communicate with each other and mixed groups of devices and people.
>>
>> 2) I want devices to do things based on time and other arbitrary policies as part of the network
>>
>> 3) I want mobile & secure smart objects to take advantage of pervasive global networks and objects that are location aware.
>>
>> 4) I want a system that can evolve so that when it makes economic sense, the physical components of a smart appliance are "smart components" themselves. I also see a day when people will be upgrading the features and functionality of their washing machine through a
>> firmware upgrade.The last two are probably sound silly now, but they're real considerations of how things can evolve.
>>
>> The truth of the matter is that even with X10 and gateways, except for device mobility, most of this is possible. It's further true that the most difficult challenge of HANs is not the networking but end user programmability and moving intelligence to the network will help in developing these systems.
>>
>> Right now, the difficulty I'm having is that it almost seems, and this could be a wrong interpretation I hope, that this working group is saying "let's forget about addressing the greater problem of HANs through network intelligence and let's just focus on satisfying the bare minimum needs of the energy industry so they can move to IP" and "then we will let the system evolve."
>>
>> Another approach could be that this working group could start by considering the HAN application layers like UPnP and see how they need to evolve for pervasive access, where they have gone wrong for developers and so on and then see how much of this better system you define can be brought down to LoPANs. This is something I think can be done in the time frames this WG has proposed and anything that comes out of it would work great for the energy industry as well.
>>
>> Of course, even better would be a general application layer framework for LoPANS, but since this is technological limitation, I think looking at requirements is absolutely necessary.
>>
>> A side note, I definitely think SIP and XMPP are relevant in this field Cullen, there is a reason why so many M2M applications are using XMPP, specially in BRIC countries. There is also a reason why the leading demand response provider is using XMPP today, if you can take this all the way to the home and on AMI networks then why not? There is also a reason why the few MSOs and incumbents that I know of who are offering home media management  and media delivery to connected devices are switching to SIP-DLNA gateways. Again, this is not even the real issue, who really cares what you name a protocol as long as it works and the proper requirements have been considered. My concern above is much more important.
>>
>> Shidan Gouran
>>
>> Right now the draft charter has a sketch of some of the key parts of the architecture. I'd like to talk about the pro's and cons of putting this in a charter. Typically charters don't have this. Many BOFs fail when all the people in the room don't lave having a common idea of what the group will do. Typically  the architecture is developed in a draft and often can take considerable time however there's nothing stopping this type of information form being in a charter. Now this effort is a bit different from your typically BOF. Let me list some differences:
>>
>> 1) This is not meant to run on normal networks. We've told the transport folks, yah, we are going to have to make different assumptions than normal application protocols make because there some special stuff going on here. That makes the Transport and INT people very nervous.
>>
>> 2) We told the security people, none of your off the shelf security approaches will work for us because we have special requirements. We are not even 100% sure it is feasibly to simultaneously satisfy all the requirements. That makes the Security people, uh, prickly.
>>
>> 3) Some people have suggest that SIP might be just the thing to build on over for things like controlling a garage door opener.  Many (but not all) SIP folks feel that SIP is for User to User communications and often use SIP to control the garage door and the prototypical example of what should *not* be done with SIP. This makes the RAI people want to come and say "hi". I'm not saying we could not use SIP but I am saying the SIP people would want to come and talk about the issues before that decision got made. Hopefully they won't ask if any of this has any real time application properties or infrastructure they could help with.
>>
>> 4) The OAM folks must be thinking, so how is this different from what we do every single day?
>>
>> 5) The INT and Routing guys want to know how this related to work they are doing.
>>
>> 6) I've had a few questions that loosely translated to "so what feature of IPv6 are you using to guarantee that this will only work on a v6 network".
>>
>> If we told the DNS guys we were consider doing all our senor reading use DNS so we could leverage the DNS caching we would have pretty much every area "concerned".
>>
>> People have questions. Lots of questions. The challenge for a successful BOF like this is to put together a coherent story of what the big picture looks like and how it all hangs together. I believe we have a reasonable chance of having a WG approved if we can show that there is a group of people that have
>>
>> 3) it is an engineering project, and not science project requiring invention of new techniques
>>
>> The quickest way to do this would be to have in some document that we take into the BOF use cases, requirements, and a high level architecture. We have drafts with use case and requirements and we can refine theses int he slides used in the BOF. If we can agree on an architecture, we can stuff that in the charter.
>>
>> I'm probably a bit naive to think we can come up with a sketch of an architecture and agree to it in the BOF. But if we do, we have a chance at having the a protocol document finished before 2011.
>>
>> A more tried and true approach to this would be to work on the requirement, use case, and architecture in some ad-hoc meetings then go for a BOF. The P2PSIP WG had problems similar to this WG in that they were going to have some harder than average transport and security issues. They meant for multiple hours at every IETF for multiple years *before* the WG was approved. Lots of the meetings had around 100 people with pretty substantial effort.
>>
>> Another approach would be to charter just to do requirements then recharter to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottle of scotch that would not finish before 2011 and even odds on a bottle of scotch it would not finish before 2012.
>>
>> Many people have expressed that time is of the essence on this work and something that delivers in 2012 will be of very little deployment value. I'm not in a good position to evaluate how quickly something is needed here but I'm happy to take everything people tell m at when this is needed at face value.
>>
>> The sponsoring AD has read me the riot act on scope for the initial set of work, make this a small bite size chunk that meets a reasonable set of needs and we can complete quickly. As that completes, I'm sure there would be no problem re-charting to expand the scope for more things or forming other WG to take on related work.
>>
>> So bottom line, I'm trying to drive this to figure out what is small bite size chunk that everyone could live with for the initial stuff to be worked on. If we are lucky, we can end up agreeing on requirements, uses cases, and a high level sketch of the architecture without a long drawn out process.  If this fails, and I admit it very well could, well then we can just move back to some other way of dealing with this.
>>
>> A good charter is a plan for work as well as something that constrains the number of possibilities a WG has to consider. Now clearly we can't constrain things beyond what is needed. If we can mange to agree on a tight charter, the WG will be able to progress work very rapidly. If we fail to do this in the next few week, having tried will not set back the work in any significant way.
>>
>> I hope this explains, I'm not  trying to convince anyone the architecture in the draft is the right one.  I'm just trying to convince people to fix it before the BOF.
>>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 Nov 2009 23:18:27 +0100

On Nov 3, 2009, at 22:48, Shidan wrote:

> Everything

The idea behind CoAP (Constrained-node/network Application Protocol)  
is to have something very simple, very basic, that can be used to run  
applications that involve constrained IP nodes on constrained  
networks.  "Everything" is not the first word that comes to my mind  
here.  I'd prefer "Do the simplest thing that could possibly work".   
(That is actually a googleable phrase.)

Gruesse, Carsten

---

From: Shidan <[email-masked]>
Date: Tue, 3 Nov 2009 17:56:07 -0500

Hi Carsten, I definitely agree and thats an interesting Google search. But
we should do no less than is required as well. Also, if we can avoid
creating something from scratch, that in itself is doing the simplest thing
that could possibly work.

Shidan Gouran

On Tue, Nov 3, 2009 at 5:18 PM, Carsten Bormann <[email-masked]> wrote:

> The idea behind CoAP (Constrained-node/network Application Protocol) is to
> have something very simple, very basic, that can be used to run applications
> that involve constrained IP nodes on constrained networks.  "Everything" is
> not the first word that comes to my mind here.  I'd prefer "Do the simplest
> thing that could possibly work".  (That is actually a googleable phrase.)
>
> Gruesse, Carsten
>
>

---

From: Shidan <[email-masked]>
Date: Tue, 3 Nov 2009 17:58:12 -0500

"Also, if we can avoid creating something from scratch, that in itself is
doing the simplest thing that could possibly work."

Or I should say could be, not is.