Subject: [Stackevo] updating the stack evolution program descrption

From: Brian Trammell <[email-masked]>
Date: Thu, 20 Aug 2015 10:18:04 +0100

hi Cindy,

Ralph and Erik have put together some text to describe program work on stack evolution and interoperability in protocol stacks for constrained devices. Please update the program description on the webpage as follows:

New paragraph to follow the 2nd paragraph (which ends with "provides
an opportunity to re-evaluate and reverse this trend."):

At the same time, the IETF has undertaken the extension of the IP
protocols to operate in constrained networks.  Applying IETF protocols
in networks with constraints on a wide range of resources has led to
the development of new IETF protocols at every layer of the IP
protocol suite.  These new protocols present network devices different
and larger configuration space than the traditional IP over
Ethernet-like link layer stack.  All of these choices impede
interoperability by requiring the implementation of multiple protocols
and the development of new control protocols.

Replace current work list item 5 with the following:

(5) Definition of guidelines for that encourage future stack evolution
while maintaining interoperability.  Particularly in the constrained
network space, the variety of possible configurations is already
leading to issues with protocol stack brittleness. For example, a
device using 6LoWPAN and IEEE802.15.4 has to choose a radio channel or
a channel hopping sequence, a dictionary of prefixes to use for header
address compression, a method for joining the network, a style of
neighbor discovery and an application protocol (which may incorporate
a transport mechanism). This work will focus initially on identifying
current impediments to interoperability resulting from this evolution
of IETF protocols.

Many thanks, best regards,

Brian (stackevo lead hat)

---

From: Dave Thaler <[email-masked]>
Date: Wed, 26 Aug 2015 14:52:30 +0000

Brian Trammell wrote:
> Ralph and Erik have put together some text to describe program work on stack evolution 
> and interoperability in protocol stacks for constrained devices. Please update the program
> description on the webpage as follows:
>
>
> New paragraph to follow the 2nd paragraph (which ends with "provides an opportunity to re-evaluate and reverse this trend."):
>
> At the same time, the IETF has undertaken the extension of the IP protocols to operate
> in constrained networks.  Applying IETF protocols in networks with constraints on a wide
>  range of resources has led to the development of new IETF protocols at every layer of
>  the IP protocol suite.  These new protocols present network devices different and larger
> configuration space than the traditional IP over Ethernet-like link layer stack.  All of these

I can't parse the grammar of the sentence above.  Perhaps "a" different and larger
configuration space?    But I'm still not quite sure what that means.

Furthermore, I think the IETF isn't the only source of the competing protocols and the
program should really look at the overall problem not just the IETF portion of it, since
part of the IAB's job is to facilitate cross-SDO cooperation/liaisons.

> choices impede interoperability by requiring the implementation of multiple protocols
> (5) Definition of guidelines for that encourage future stack evolution while maintaining
> interoperability.  Particularly in the constrained network space, the variety of possible
> configurations is already leading to issues with protocol stack brittleness. For example,
> a device using 6LoWPAN and IEEE802.15.4 has to choose a radio channel or a channel
> hopping sequence, a dictionary of prefixes to use for header address compression, a
> method for joining the network, a style of neighbor discovery and an application
> protocol (which may incorporate a transport mechanism). This work will focus initially
> on identifying current impediments to interoperability resulting from this evolution of
> IETF protocols.

Again I think "IETF" protocols is too narrow a scope although it may be the first task.

Dave

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Aug 2015 08:19:21 -0700

> configuration space?    But I'm still not quite sure what that means.
The intent is to capture the type of things in (5) (channel hopping, 
compression, joining), but I agree the text can do a better way to 
explain that.

> part of the IAB's job is to facilitate cross-SDO cooperation/liaisons.
Good point; we should capture that.

    Erik

> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 27 Aug 2015 17:10:24 +0200

Hi, all,

Continuing a conversation the IAB had on the call yesterday, working to refine this point on the

First, the minimal set of edits to scope *this* description correctly would seem to leave us with the following:

New para after 2nd:

At the same time, the IETF has undertaken the extension of the IP protocols to operate
in constrained networks.  Applying IETF protocols in networks with constraints on a wide
range of resources has led to the development of new protocols at every layer of
the IP protocol suite.  These new protocols present network devices different and larger
configuration spaces than the traditional IP over Ethernet-like link layer stack.  All of these
choices impede interoperability by requiring the implementation of multiple protocols
and the development of new control protocols.

New item 5:

However, it is clear that this scope only covers part of the looming interoperability problem in this space:

(1) Protocols are layered on top of each other in mutually incompatible ways. This is the scope this text attempts to address, and, as implementation and deployment of patchy hacks and hacky patches to get around this mutual incompatibility, where the threat this problem presents to future evolvability of the stack lies.

(2) The data models used by these protocols are mutually incompatible, and are defined and built in ways that may exacerbate this mutual incompatibility. So even if we make progress on (1) there's still a big mess here. On point (2), Dave, Jari, and Hannes are working on putting together a potential IAB workshop on data sharing in the IoT space; hopefully the outcome there will be some clarity on the depth of the problem and some coordination to begin untangling it.

My main question to the program here would be: are both of these aspects of the problem of interest to / within scope for the program; which I guess reduces to, do we understand the separation here well enough to draw this line for the purposes of the program description?

Thanks, cheers,

Brian

> On 26 Aug 2015, at 17:19, Erik Nordmark <[email-masked]> wrote:
> 
> The intent is to capture the type of things in (5) (channel hopping, compression, joining), but I agree the text can do a better way to explain that.
> 
>>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 28 Aug 2015 00:36:01 +0000

[...]
> (1) Protocols are layered on top of each other in mutually incompatible ways. This is the scope this text attempts
> to address, and, as implementation and deployment of patchy hacks and hacky patches to get around this
> mutual incompatibility, where the threat this problem presents to future evolvability of the stack lies.

> (2) The data models used by these protocols are mutually incompatible, and are defined and built in ways that
> may exacerbate this mutual incompatibility. So even if we make progress on (1) there's still a big mess here.
> On point (2), Dave, Jari, and Hannes are working on putting together a potential IAB workshop on data sharing
> in the IoT space; hopefully the outcome there will be some clarity on the depth of the problem and some
> coordination to begin untangling it.
>
> My main question to the program here would be: are both of these aspects of the problem of interest to /
> within scope for the program; which I guess reduces to, do we understand the separation here well enough
> to draw this line for the purposes of the program description?

My opinion: yes and yes :)

Dave

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 28 Aug 2015 11:14:14 -0400

> My opinion: yes and yes :)

Mine: yes to Dave's :-)

Suzanne

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 31 Aug 2015 15:18:59 +0000

> On Aug 27, 2015, at 11:10 AM 8/27/15, Brian Trammell <[email-masked]> wrote:
> 
> Hi, all,
> 

I agree; revised text expresses the original point Erik and I aimed to address.

> My main question to the program here would be: are both of these aspects of the problem of interest to / within scope for the program;

Yes.

> which I guess reduces to, do we understand the separation here well enough to draw this line for the purposes of the program description?

I might quibble with the details of the descriptive text for (1) and (2), but I think we understand the separation well enough.

- Ralph

---

From: Brian Trammell <[email-masked]>
Date: Mon, 31 Aug 2015 23:52:33 +0200

hi Ralph, all,

more on this later, but for now, one point inline...

> On 31 Aug 2015, at 17:18, Ralph Droms (rdroms) <[email-masked]> wrote:
> 
> 

hearing no objection to the scope, let's quibble then. :)

I think the text we have *now* is pretty good for (1), but my (not really meant as a starting point for the description, but why not) text for (2) needs some work.

*architectural abstractionist hat on*

We haven't talked a lot about data models and data model incompatibility in the program (since its 2014 reboot, anyway) -- this is probably because there's not a lot of separation between data model and protocol mechanism in the transport space: your signaling mechanism comes with a data model, and usually with a fairly small space of things you can do in response to each signal. The success of SPUD or a SPUDlike thing would change this, though.

I'm not sure we want to be *so* general in the description though.

Cheers,

Brian