Subject: Re: [6lowapp] the role of gateway nodes

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 4 Dec 2009 15:50:13 -0500

On Mon, Nov 30, 2009 at 8:24 AM, Zach Shelby <[email-masked]> wrote:

>
>
> We can probably get away with CoRE and CoAP being the only acronyms used
> here. CoRE describes the WG and the general set of requirements, but is not
> any particular network. CoAP makes sense as the name for a protocol.
>
> The simplification of the charter suggested in the Hiroshima BOF hints that
> we probably don't need to talk about CoGIIs at all, just that there is an
> HTTP mapping. And I don't see a need for CE, CoNet and CoNode all that. We
> can just talk about CoRE or write it out as constrained environments?
>

ARC> I'd much rather that CoGII be retained as an 'abstract concept'. In
some cases, it may be a stateful protocol mapping, some cases stateless
mapping and in some cases a null function (i.e. smart appliances that can
directly talk "Internet protocols" as Carsten's email indicates. This
architecturally separates the concept of the need for protocol conversion
and the fact that HTTP is one of may protocols that may need interworking.
Even if the focus of the core group (whatever it is called in 6lowapp) is
just to map HTTP, it should make it clear that this is a CoGII function and
in future, this may change depending on the device in question and the
network in question.

>
> Zach
>
> > Thanks.
> >
> > JP.
> >
> >> Gruesse, Carsten
> >>
> >> _______________________________________________
> >> 6lowapp mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/6lowapp
> >
> > _______________________________________________
> > 6lowapp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/6lowapp
>
> --
> http://www.sensinode.com
> http://zachshelby.org - My blog "On the Internet of Things"
> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
> Zach Shelby
> Head of Research
> Sensinode Ltd.
> Kidekuja 2
> 88610 Vuokatti, FINLAND
>
> This e-mail and all attached material are confidential and may contain
> legally privileged information. If you are not the intended recipient,
> please contact the sender and delete the e-mail from your system without
> producing, distributing or retaining copies thereof.
>
>
>
>
> _______________________________________________
> 6lowapp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>
>
>
>
>
>
> *********************************************DISCLAIMER*********************************************
> The email is subject to Disclaimer as per -
> http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer
>
>
>

-- 
Arjun Roychowdhury

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 4 Dec 2009 15:56:58 -0500

On Fri, Nov 27, 2009 at 10:00 AM, Carsten Bormann <[email-masked]> wrote:

> On Nov 27, 2009, at 15:37, Xavi Vilajosana Guillen wrote:
>
> > what's the approach at 6LowApp? anyone knows ongoing work on that issue?
>
> I would summarize the thinking that went into the BOF as follows:
>
> Some nodes in a CE (constrained environment) may actually be not that
> constrained (as nodes and with respect to their network).  These can
> directly speak the appropriate application protocol (HTTP, SNMP, XMPP, SIP)
> to some correspondent node outside (or inside) the CE.  (We didn't put this
> on the slides because that is nothing new.)
>

ARC> This may be just my opinion but I think thats an important point to put
in even if its not new. To some of us, the assertions being made in the
group about network bandwidth and device constrained are not coupled with
concrete proof and makes us wonder why such stringent constraints are being
laid out. It goes back to Henning Schulzrinne's points made in these
threads:
http://www.ietf.org/mail-archive/web/6lowapp/current/msg00266.html
http://www.ietf.org/mail-archive/web/6lowapp/current/msg00257.html
http://www.ietf.org/mail-archive/web/6lowapp/current/msg00215.html

If this group were to make this classification clear that there will be
devices that adhere to stringent needs and those that can accommodate richer
protocols, even in what is called a 'LowPAN' network, then it completes the
story better.

Arjun Roychowdhury