Subject: Re: [Stackevo] [IAB] updating the stack evolution program descrption

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 1 Sep 2015 20:01:46 +0000

> On Aug 31, 2015, at 5:52 PM 8/31/15, Brian Trammell <[email-masked]> wrote:
> 
> 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:
>> 
>> 
>>> On Aug 27, 2015, at 11:10 AM 8/27/15, Brian Trammell <[email-masked]> wrote:
>>> 
>>> 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:
>> 
>> I agree; revised text expresses the original point Erik and I aimed to address.
>> 
>>> 
>>> 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:
>>> 
>>> (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.
>>> 
>>> 
>>> 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;
>> 
>> 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.
> 
> hearing no objection to the scope, let's quibble then. :)

OK...

> 
> 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*

Hope it fits comfortably...I'll try to find mine, too.

> 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.

Now I realize I may be confused.  Are we talking about data models for operating and managing the protocols, or data models for operating and managing the devices, or data models for the bits generated by the devices?

Seems these categories have varying (increasing?) separation from the issues raised by (1).

- Ralph

> 
> Cheers,
> 
> Brian
> 
>> - Ralph
>> 
>>> 
>>> Thanks, cheers,
>>> 
>>> Brian
>>> 
>>> 
>>>> On 26 Aug 2015, at 17:19, Erik Nordmark <[email-masked]> wrote:
>>>> 
>>>> On 8/26/15 7:52 AM, Dave Thaler wrote:
>>>>> 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.
>>>> 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.
>>>> 
>>>>> 
>>>>> 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.
>>>> Good point; we should capture that.
>>>> 
>>>> Erik
>>>> 
>>>>> 
>>>>>> 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.
>>>>> Again I think "IETF" protocols is too narrow a scope although it may be the first task.
>>>>> 
>>>>> Dave
>>>>> 
>>>>> _______________________________________________
>>>>> Stackevo mailing list
>>>>> [email-masked]
>>>>> https://www.iab.org/mailman/listinfo/stackevo
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Stackevo mailing list
>>> [email-masked]
>>> https://www.iab.org/mailman/listinfo/stackevo
>> 
>> _______________________________________________
>> Stackevo mailing list
>> [email-masked]
>> https://www.iab.org/mailman/listinfo/stackevo

---

From: Brian Trammell <[email-masked]>
Date: Wed, 2 Sep 2015 00:56:45 +0200

hi Ralph,

> On 01 Sep 2015, at 22:01, Ralph Droms (rdroms) <[email-masked]> wrote:
> 
> 

So my understanding is that the problem in the IoT space is a little of all three, but the issue we'd be concerned with is primarily the final one: protocol interop for lightbulbs is meaningless if there's no agreement on the way to talk about light. Of course, this separation of the problem space is confounded slightly by the fact that if you're talking about "things" that have sensors and actuators, "operating the devices" and "bits generated (/accepted) by the devices" are much more closely related to each other than is the case with, say, routers.

> Seems these categories have varying (increasing?) separation from the issues raised by (1).

Since I say the above with very little expertise about the situation in the IoT space, it's entirely possible I'm confused too.

Cheers,

Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 2 Sep 2015 04:27:11 +0000

Ralph Droms wrote:
> Now I realize I may be confused.  Are we talking about data models for operating
> and managing the protocols, or data models for operating and managing the devices,
> or data models for the bits generated by the devices?

The 2nd and 3rd ones in your list.  That is, a light switch has on/off
(and perhaps dimming in between on/off), which is the 2nd thing in your list.
A temperature sensor has a temperature it exposes, which is the 3rd thing in your list.
One is read/write and one is read-only but both are part of the data model for the
device.

The protocol it speaks is largely irrelevant to the information model.  Of course
some protocols constrain the syntax of how you can express the abstract information
model in terms of a concrete data model (XML, JSON, CBOR, MIB, MOF,
YANG, RPC IDL, or whatever else), but that's more of a side effect than the root issue.

Dave

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 8 Sep 2015 21:55:44 +0000

> On Sep 2, 2015, at 12:27 AM 9/2/15, Dave Thaler <[email-masked]> wrote:
> 
> Ralph Droms wrote:

OK, got it.

> YANG, RPC IDL, or whatever else), but that's more of a side effect than the root issue.

Yes, I agree.  Feels like almost two orthogonal issues to me.  We have the same information and data model problems in lots of places.  Is there something specific about the constrained network area that would cause us to call it out as opposed to the same problem in network management, SDN, application management, ???

- Ralph

---

From: Dave Thaler <[email-masked]>
Date: Wed, 9 Sep 2015 14:59:01 +0000

Ralph Droms wrote:
>> The protocol it speaks is largely irrelevant to the information model.  
>> Of course some protocols constrain the syntax of how you can express 
>> the abstract information model in terms of a concrete data model (XML, 
>> JSON, CBOR, MIB, MOF, YANG, RPC IDL, or whatever else), but that's
>> more of a side effect than the root issue.
>
> Yes, I agree.  Feels like almost two orthogonal issues to me.  We have
> the same information and data model problems in lots of places.  Is there
> something specific about the constrained network area that would cause
> us to call it out as opposed to the same problem in network management,
> SDN, application management, ???

There is much in common, but I think there are 1 or 2 key differences:
1) In the IoT space, it is common for other orgs to define data models
that are constrained to *non-IP* protocols.  (E.g., Bluetooth profiles,
zigbee profiles, etc.)   This means that they hamper or delay migration to IP,
and introduce requirements for IP to non-IP gateways.

2) The IETF pretty much doesn't do any information models or data models
today for such things.  The IETF only does models for protocols.  IETF people
(e.g. in IPSO) do do some however.   So in our role as overseers of Internet
goodness, we must look to provide guidance outside the IETF, rather than
focusing inwards.

Dave

---

From: "Black, David" <[email-masked]>
Date: Sun, 13 Sep 2015 21:01:01 +0000

I must've missed something when this discussion somehow moved from
discussion of core protocols to data and information models for light
bulbs (and by extension, refrigerators, toasters, etc.).  Those seem
well beyond the first paragraph of the program description
(https://www.iab.org/activities/programs/ip-stack-evolution-program/):

The IP Stack Evolution program covers various topics in the evolution of IPv4 and IPv6, the transport protocols running over IP, and the overall protocol stack architecture. The program addresses challenges that affect the stack in some way and where the IETF community requires architectural guidance, responding to community requests as well as actively monitoring work within IETF WGs which touch on relevant topics.

In particular, I would have thought that this would be the relevance of data
models to the IP Stack Evolution Program:

> Are we talking about data models for operating and managing the protocols

as opposed to these two:

> or data models for operating and managing the devices, or data models
> for the bits generated by the devices?

Thanks,
--David

> -----Original Message-----
> From: Stackevo [mailto:[email-masked]] On Behalf Of Dave Thaler
> Sent: Wednesday, September 09, 2015 10:59 AM
> To: Ralph Droms (rdroms)
> Cc: Stackevo; Brian Trammell; IAB
> Subject: Re: [Stackevo] [IAB] updating the stack evolution program descrption
> 
> Ralph Droms wrote:

---

From: Brian Trammell <[email-masked]>
Date: Sat, 19 Sep 2015 08:38:39 +0200

hi David, all

I've been thinking about this, and I tend to agree. 

I can see a relatively clear separation between the two sides of the problem in IoT interop here -- mutually-exclusive choices about how the layers interact with each other (in an environment in which there are often constraint-based reasons to ignore layer boundaries altogether) on one side, just-plain-incompatible content on the application layer on the other.

I see one of the criteria for the scope of the program "is there a diagram you can draw o the problem with more than one layer in it?", because one of the things that makes evolving a stack hard is the coordinated effort required to move those layer boundaries about. The first problem looks like SPUD -- there are multiple arrangements of layer boundaries and interfaces in both cases. The second problem looks more like standardizing HTTP header definitions and header compression schemes: nontrivial problems, but nicely tucked away inside a single layer.

It may be that in the IoT space itself, these two problems are inseparable (or seen thereas), and there may be some special aspect of this in the IoT space that I'm missing here, but I can't really see how the second one is a *stack* evolution problem as opposed to just a standard problem of layer 7 protocol design and standardization in a market space that hasn't started to settle yet, where the protocols aren't yet mature. It's also not clear how discussions on one aspect can inform solutions for the other.

Which is not to say that both aren't important. I think the first step of any way forward here is organizing an IAB workshop on the *larger* problem and use that as input to next steps. An IoT Architecture (hmm, iota?) program might be an outcome thereof. 

With respect to the question at hand (updating the stack evolution program description), though, I'd like to propose we rewind back to the last edits of Ralph's description as a basis for adding the first part of the problem to the program's scope, and defer organizational questions on the second part of the problem to the workshop.

Thoughts?

Thanks, cheers,

Brian

> On 13 Sep 2015, at 23:01, Black, David <[email-masked]> wrote:
>