Subject: [Asdf] Robert Wilton's Block on charter-ietf-asdf-00-01: (with BLOCK)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 10 Sep 2020 07:39:17 -0700

Robert Wilton has entered the following ballot position for
charter-ietf-asdf-00-01: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-asdf/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I think that it would be useful to have a brief discussion on whether this
charter should make any mention of YANG, or OneDM's relationship to YANG, at
all?

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 10 Sep 2020 15:41:07 +0000

To expand on this since I had posted my block late.

I might be mistaken, but I regard OneDM and the YANG language to be similar in their goals, but targeted towards different market segments:
 - OneDM has more of an emphasis on RPC operations (e.g. toggle the state of the light switch)
 - YANG has more emphasis on configuration (e.g. change the desired state of the light switch so that it is on) and operational data, but also supports RPC operations.

YANG also seems to be a more rich (and hence complex) language than OneDM, but that might just be because OneDM is a younger language and overtime perhaps it will gain some of the complexities in YANG.

Further, I would personally be interested to know how feasible it is to map between YANG data models and OneDM data models, although I would not suggest adding this to the charter unless that were individuals in ASDF who are specifically interested in this.

Hence, my question is whether it is right for the OneDM charter to be entirely silent on YANG, or whether it should be mentioned in some way?  Or alternatively, whether it would make sense to say seek reviews from the Netmod WG community at various stages of the OneDM evolution.

Regards,
Rob

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Robert Wilton via
> Datatracker
> Sent: 10 September 2020 15:39
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Robert Wilton's Block on charter-ietf-asdf-00-01: (with BLOCK)
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 10 Sep 2020 15:56:42 +0000

For what it is worth: I had a quick look[1] at a couple of OneDM 'models' and they appears to me as very simple and mostly atomic (i.e., a single 'leaf' to speak YANG) per model.

Getting a mapping OneDM -> YANG document (i.e., a set of rules) should be doable (the other way is not possible due to YANG flexibility and extensibility)

Back to the charter, I would not object having a work item for the above in the ASDF charter

-éric

[1] from the OneDM github and selecting 5 models

-----Original Message-----
From: iesg <[email-masked]> on behalf of "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Date: Thursday, 10 September 2020 at 17:41
To: "Rob Wilton (rwilton)" <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Robert Wilton's Block on charter-ietf-asdf-00-01: (with BLOCK)

    Regards,
    Rob

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Sep 2020 19:43:22 +0200

> Further, I would personally be interested to know how feasible it is to map between YANG data models and OneDM data models, although I would not suggest adding this to the charter unless that were…

Indeed, we’d need to find people who would want to work on this.

From an SDF point of view, YANG is one more ecosystem.
So far, the ecosystems did the work on converting back and forth between their specification systems and SDF.
Typically, this work takes the form of a piece of software that does the conversions, maintained as part of the toolset that belongs to the ecosystem.
Just describing this in a document would be possible, but less useful.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 15:53:47 -0400

Rob Wilton \(rwilton\) <rwilton=[email-masked]> wrote:
    > I might be mistaken, but I regard OneDM and the YANG language to be
    > similar in their goals, but targeted towards different market segments:
    > - YANG has more emphasis on configuration (e.g. change the desired
    > state of the light switch so that it is on) and operational data, but
    > also supports RPC operations.

This was covered during the BOF.
   https://youtu.be/PhVu1K6m-eM?t=1310

I would put it as:
* YANG is intended to be the one truth, and RPC mechanisms are derived from it.
* SDF is intended to be an intermediate truth, and the RPC mechanisms remain
  part of the relevant organizations.
  So, yes, we could figure out how to translate a YANG description into OCF's
  RPC mechanism, but it isn't clear to me how we'd translate OCF into YANG,
  and then into something that OMA can use.  I think that it could be done,
  but we'd wind up making up so many custom extensions to YANG in order not
  lose the relevant metadata, that it would hardly be YANG anymore.

I say this being slightly clueful about YANG, and not as yet very clueful
about SDF.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 14 Sep 2020 14:59:40 +0000

Hi Cartsen,

> From: iesg <[email-masked]> On Behalf Of Carsten Bormann
> Sent: 10 September 2020 18:43
> To: Rob Wilton (rwilton) <rwilton=[email-masked]>
> Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
> Subject: Re: [Asdf] Robert Wilton's Block on charter-ietf-asdf-00-01:
> (with BLOCK)
> 
> On 2020-09-10, at 17:41, Rob Wilton (rwilton)
> <rwilton=[email-masked]> wrote:
> >
> > Further, I would personally be interested to know how feasible it is to
> map between YANG data models and OneDM data models, although I would not
> suggest adding this to the charter unless that were individuals in ASDF
> who are specifically interested in this.
> 
[RW] 

Okay.  There is one difference here in that IETF is also responsible for YANG, whereas I presume that the other ecosystems are all outside of IETF.

> Typically, this work takes the form of a piece of software that does the
> conversions, maintained as part of the toolset that belongs to the
> ecosystem.
[RW] 

Completely agree that having actual software that does the conversion is what would really be useful here, and a paper specification is less helpful on its own.

However, one possible benefit of having a draft relating the two being developed alongside is that it might increase the interoperability between YANG and OneDM.  Whether this has particular value is unclear.

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 14 Sep 2020 15:01:37 +0000

Hi Eric,

> From: Eric Vyncke (evyncke) <[email-masked]>
> Sent: 10 September 2020 16:57
> To: Rob Wilton (rwilton) <rwilton=[email-masked]>; Rob Wilton
> (rwilton) <[email-masked]>; The IESG <[email-masked]>
> Subject: Re: Robert Wilton's Block on charter-ietf-asdf-00-01: (with
> BLOCK)
> 
> For what it is worth: I had a quick look[1] at a couple of OneDM 'models'
> and they appears to me as very simple and mostly atomic (i.e., a single
> 'leaf' to speak YANG) per model.
> 
> Getting a mapping OneDM -> YANG document (i.e., a set of rules) should be
> doable (the other way is not possible due to YANG flexibility and
> extensibility)
[RW] 

In terms of OneDM -> YANG Document, I agree that it a simpler translation, and would potentially allow controllers that are designed to manage devices using YANG & related protocols to also be able to manage IOT devices with their models specified in OneDM.

Going the other way round could also potentially be specified by restricting it to just the subset of YANG that can be cleanly converted to OneDM.

Thanks,
Rob

> state of the light switch so that it is on) and operational data, but also
> supports RPC operations.
> 
>     YANG also seems to be a more rich (and hence complex) language than
> OneDM, but that might just be because OneDM is a younger language and
> overtime perhaps it will gain some of the complexities in YANG.
> 
>     Further, I would personally be interested to know how feasible it is
> to map between YANG data models and OneDM data models, although I would
> not suggest adding this to the charter unless that were individuals in
> ASDF who are specifically interested in this.
> 
>     Hence, my question is whether it is right for the OneDM charter to be
> entirely silent on YANG, or whether it should be mentioned in some way?
> Or alternatively, whether it would make sense to say seek reviews from the
> Netmod WG community at various stages of the OneDM evolution.
> 
>     Regards,
>     Rob
> 
> 
>     > charter should make any mention of YANG, or OneDM's relationship to
> YANG,
>     > at
>     > all?
>     >
>     >
>     >
>     >
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 14 Sep 2020 17:10:11 +0200

> Okay.  There is one difference here in that IETF is also responsible for YANG, whereas I presume that the other ecosystems are all outside of IETF.

The other difference is that “the YANG people” (sorry for the wishy term) haven’t actually started developing interest for this.  I think they might at some point (see below), and we certainly want to advertise SDF in netmod etc., but it is too early to say what we’d do with YANG and SDF.

Note that, to make YANG more useful for describing Thing data models, there might be a need to do work on the YANG side.  An obvious example is number systems (specifically floating-point support (*)).

> Completely agree that having actual software that does the conversion is what would really be useful here, and a paper specification is less helpful on its own.

In the OneDM call today, we actually discussed potentially having first Proof-of-Concept software available for the IETF109 hackathon.

I see two immediate items of interest:

— short-term: using YANG models as a quarry for useful data types etc.
— medium-term: discussing how to translate between SDF and YANG and what kind of “binding template” or “mapping file” might be needed.

I think these would be good items for the WISHI activity of T2TRG, probably starting with the IETF109 hackathon.

> However, one possible benefit of having a draft relating the two being developed alongside is that it might increase the interoperability between YANG and OneDM.  Whether this has particular value…

I think that, if there is interest, we might work on elements of such a draft in T2TRG — not as a normative specification for now, but as a record of the considerations that went into the software being developed.

What part of this should be in the charter?

Grüße, Carsten

(*) I don’t know about the status of https://github.com/netmod-wg/yang-next/issues/34

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 14 Sep 2020 16:26:18 +0000

Hi Carsten,

> From: Carsten Bormann <[email-masked]>
> Sent: 14 September 2020 16:10
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: [email-masked]; The IESG <[email-masked]>; [email-masked]
> >> So far, the ecosystems did the work on converting back and forth
> between
> >> their specification systems and SDF.
> > [RW]
> >
> > Okay.  There is one difference here in that IETF is also responsible for
> YANG, whereas I presume that the other ecosystems are all outside of IETF.
> 
> The other difference is that “the YANG people” (sorry for the wishy term)
> haven’t actually started developing interest for this.
[RW] 

I agree.

  I think they might
> at some point (see below), and we certainly want to advertise SDF in
> netmod etc., but it is too early to say what we’d do with YANG and SDF.
[RW] 

I also agree on this.

> 
> Note that, to make YANG more useful for describing Thing data models,
> there might be a need to do work on the YANG side.  An obvious example is
> number systems (specifically floating-point support (*)).
[RW] 

Yes.

Note, some of the YANG proponents (Lada in particular) has pushed for YANG to become a more generalized data modelling language.  The YANG data structure extension (RFC 8791) arguably heads in this same direction.

I would also like YANG to support floating-point numbers, and that might happen in a future version of YANG.  But realistically, I can't really see a new version of YANG materializing in anything less than 2 years, and I appreciate that the requirement for SDF is something much sooner than that!

> > Completely agree that having actual software that does the conversion is
> what would really be useful here, and a paper specification is less
> helpful on its own.
> 
> In the OneDM call today, we actually discussed potentially having first
> Proof-of-Concept software available for the IETF109 hackathon.
> 
> — medium-term: discussing how to translate between SDF and YANG and what
> kind of “binding template” or “mapping file” might be needed.
> 
> I think these would be good items for the WISHI activity of T2TRG,
> probably starting with the IETF109 hackathon.
> 
> > However, one possible benefit of having a draft relating the two being
> developed alongside is that it might increase the interoperability between
> YANG and OneDM.  Whether this has particular value is unclear.
> 
> I think that, if there is interest, we might work on elements of such a
> draft in T2TRG — not as a normative specification for now, but as a record
> of the considerations that went into the software being developed.
> 
[RW] 

I'm not sure.

One choice could be to add this as an optional second item to the charter?  So, if there was interest in working on such a mapping then it would be in scope, but if there isn't interest, or if the interest is for the work to be done elsewhere then that would also be okay.

Whatever we decide on the point above, I also think that it would probably be useful to have a short paragraph in the background section that acknowledges the existence of YANG and very briefly explains how the SDF effort is different.  I would see that the purpose of such text would be to help someone who is less familiar with YANG/SDF understand the differences.

E.g., perhaps something along the lines of:

IETF also defines the YANG data modelling language (RFC 7950).  YANG has 
a strong focus on modelling the management interface for network devices,
using a fairly small set of network management protocols,
whereas SDF is designed to ... <fill in the blank>

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 14 Sep 2020 16:28:56 +0000

Hi Michael,

Please see inline ...

> From: iesg <[email-masked]> On Behalf Of Michael Richardson
> Sent: 10 September 2020 20:54
> To: Rob Wilton (rwilton) <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]
[RW] 

Thanks.  Unfortunately, I missed the BOF due to a conflict with a NETMOD or NETCONF.

[RW] 

I sort of get where you are coming from, but I'm not sure whether YANG is really the one truth.  Certainly, I'm aware of vendors who convert internal data models to/from YANG models and YANG data.

Although YANG has a strong emphasis on network configuration, it is mostly a fairly generic data modelling language:
 - Various encodings of the instance data exist: XML, JSON, CBOR (with/without SIDs), GPB (generic), GPB (model specific encodings)
 - Various network protocols use YANG (and each support a subset of the encodings): NETCONF, RESTCONF, COMI, gNMI.

Controllers, such as Cisco's NSO will convert between say RESTCONF+JSON at a Northbound Service API, and into different devices in a Southbound device API (E.g. NETCONF, or proprietary vendor CLI).

So, in terms of what service it is providing then it doesn't seem to me that SDF and YANG are particularly different, although I do agree that they have some strong differences about how they structure the model, and what emphasis they place on particular elements.  As an example, it looks like SDF can group different objects together into a compound object (a fridge-freezer was the cited example).  YANG also has mechanism for achieving this, but arguably they don't work as well for this use case.  Groupings are not quite right, and schema-mount is too heavy weight.

[RW] 

So, I suspect that this is probably the real key here.  SDF is being designed specifically to work well with the existing data models being defined by (e.g. OCF, OMA) with buy in from those communities that they are willing to work with the common SDF format, presuming that it stays reasonably aligned to its current structure.

Note, I am not at all opposed to IETF standardizing SDF, but personally I don't think that IETF would be standardizing something significantly different to YANG, but more something that is somewhat similar to YANG but optimized for a slightly different part of the network.  But I'm also not that familiar with SDF so it is possible that there are some further nuances to SDF that I don't understand or appreciate.

Regards,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2020 16:35:07 -0400

> whereas SDF is designed to ... <fill in the blank>

my take is at:
  https://github.com/one-data-model/ietf108/pull/8
it is possible that I've mis-characteristize something.  If so, that's good,
because someone else will also have misunderstood, and I should be corrected :-)

  The IETF also defines the YANG data modelling language (RFC 7950).
  YANG has a strong focus on modelling the management interface for network devices,
  using a fairly small set of network management protocols,
  whereas SDF is designed to span (and transitively unify) many existing
  interaction models already present.

  While YANG can be serialized to a variety of wire formats (XML, JSON, CBOR, ...),
  the serialization is driven directly by the structure of the YANG.

  YANG also has an opinionated way in which the RPC is done.
  This is necessary in order to get the kind of cross-vendor interoperability
  needed for efforts in the Software Defined Networking.
  On the other hand, SDF does not deal directly with serialization, dealing
  only in semantics of content, and leaving the existing IoT SDOs to do their
  own serialization.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 16 Sep 2020 16:38:25 +0000

Hi Michael,

Thank you for putting this together.  I've got some suggestions, and some tweaked text below, but certainly I think that your extra text helps pinpoint a key difference between SDF and YANG.

I don't think that it should mention the YANG RPC behaviour because arguably that is the domain of the network management protocols rather than the language used to model the data.

Please see inline ...

> Sent: 15 September 2020 21:35
> Cc: Carsten Bormann <[email-masked]>; [email-masked]; The IESG
[RW] 

Okay.

>   the serialization is driven directly by the structure of the YANG.
[RW] 
Suggested alternative:

   While data associated with a YANG schema can be serialized to a variety
   of wire formats (e.g., XML, JSON, CBOR, and others), the serialization is
   driven directly by the structure of the data models defined in YANG.

>   only in semantics of content, and leaving the existing IoT SDOs to do
[RW]
Suggested alternative:
 
   Conversely, SDF does not deal directly with serialization at all,
   modelling only the semantics of the content, hence leaving data
   serialization (and RPC semantics) to other standards, most likely defined
   by existing IoT SDOs.

Thoughts?

Rob

---

From: David Kemp <[email-masked]>
Date: Wed, 16 Sep 2020 14:53:16 -0400

>
> [RW] Suggested alternative:

>    serialization (and RPC semantics) to other standards, most likely

The suggested text looks great - very precise and clear.

A while back Bruce Nordman said:
>
> I had assumed from the start that ODM would define a reference semantic
> model that any protocol could be translated into, or out of, which
> necessarily requires picking some existing model to use directly or to
> adapt, or creating a new one.  From the ODM call today I take it that this
> is a topic which ODM has not yet settled on an approach to.
> While standardizing on things like the naming and meaning of individual
> element is needed, in some cases information is represented in ways which
> is just different.  I have worked for many years on the concept of 'power
> state' (and aided in our move from a 2 power state world - on/off - to one
> with 3 - on/sleep/off). In some cases, models combine power state with a
> functional state of device (e.g. if a printer/MFD is printing, scanning,
> neither, etc.) into one enumeration.

In UML it is common to successively refine a system design from conceptual
(messages) to logical (messages with named fields) to physical (messages
with strongly-typed named fields).  A YANG schema is a physical model that
defines syntax.  SDF is a logical model that needs to define structured
elements and "the naming and meaning of individual elements" of those
structured elements.

Semantics covers meaning. Does it also unambiguously include standardized
names and relationships?  Or would:
       "modelling only the semantics *and structure* of the content"
be better?

Regards,
Dave

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Sep 2020 18:57:11 -0400

Rob Wilton \(rwilton\) <rwilton=[email-masked]> wrote:
    > Thank you for putting this together.  I've got some suggestions, and
    > some tweaked text below, but certainly I think that your extra text
    > helps pinpoint a key difference between SDF and YANG.

okay, I'l put that into the Pull Request in a minute.

    > I don't think that it should mention the YANG RPC behaviour because
    > arguably that is the domain of the network management protocols rather
    > than the language used to model the data.

Okay, but the reason I mentioned it is because the various SDOs that SDF
seeks to establish interoperability with *ALSO* have their own RPCs, and one
of the reasons I think that YANG would be a problem is because it would
establish the YANG RPCs as having primacy.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Sep 2020 06:46:39 +0200

On 2020-09-17, at 00:57, Michael Richardson <[email-masked]> wrote:
> 
> the various SDOs that SDF
> seeks to establish interoperability with *ALSO* have their own RPCs

I’m not sure what “RPC” is a code word for here.
While HTTP transactions could be thought of as RPCs if you squint really hard, CoAP's Observe extends that model, and protocols like AMQP or MQTT certainly get by with a lot of things that aren’t RPCs at all.

Maybe the word “interaction pattern” is what you are looking for.
YANG has two groups of these: data store (~ SDF properties) and RPC (~ SDF actions).  Add YANG push for ~ SDF events.  (Note that, while SDF’s current three interaction patterns seem to cover a lot of ground, it is not certain that we will stick with exactly those three.)

I put in a couple of smaller comments in https://github.com/one-data-model/ietf108/pull/8/files for your kind attention.

Grüße, Carsten

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Sep 2020 10:02:07 +0000

> Sent: 16 September 2020 23:57
[RW] 

Possibly "RPCs" are a rathole that we probably don't need to go down, and perhaps it is better to just not mention this is in the charter at all?

The conversation is also slightly confusing to me if that for YANG + associated network protocols, RPCs exist at two levels:

(1) Within the YANG language RPC like operations can also be defined (e.g., using the "rpc" or "action" keyword).

(2) You have the RPCs associated network management protocols, e.g., an "edit-config" operation, or "get-data" request.  YANG doesn't really specify any strict rules(*) for these protocols (although some NETCONF protocol behaviour is defined within the YANG RFC). Arguably there are some implicit rules that exist in terms of consistency of the data and serializing operations that apply (or should apply) to all the network management protocols.

NETCONF aims to define its protocol RPC operations using the YANG language, e.g., see "rpc get-data" in RFC 8526.  However, RESTCONF defines its protocol RPC operations explicitly as HTTP operations.  E.g., section 3.2 of RFC 8527.

But I'm still not really seeing how the RPC behaviour for SDF is fundamentally different from YANG.  In particular, I think that there will probably need to be some common expectations about general RPC behaviour to facilitate allowing protocols to be able to interoperate in some way, unless this is not a goal at all?

(*) As an aside, arguably it would have been good if YANG, or an associated document, did define the minimal requirements for protocol operations or encodings.  E.g., in YANG it is unclear in models whether or not there should be a container above a list and also whether that list should named in the singular or plural.  E.g., should it be "/interfaces/interface" or just "/interfaces" or just "interface".  Possibly something to consider when specifying SDF ...

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Sep 2020 10:13:36 +0000

Hi David,

“Semantics and structure” would be okay with me, although I wonder whether “structure” might end up being too rigid.  E.g. I see that the structure  of the data tree that is defined by YANG to be very rigid, but I had got the impression that SDF might be intended to be more flexible than that.   Hence, “semantics and organization” could be a possible alternative that might be a bit softer, but I don’t feel strongly on this …

Regards,
Rob

From: iesg <[email-masked]> On Behalf Of David Kemp
Sent: 16 September 2020 19:53
To: [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Asdf] Robert Wilton's Block on charter-ietf-asdf-00-01: (with BLOCK)

A while back Bruce Nordman said:
I had assumed from the start that ODM would define a reference semantic model that any protocol could be translated into, or out of, which necessarily requires picking some existing model to use directly or to adapt, or creating a new one.  From the ODM call today I take it that this is a topic which ODM has not yet settled on an approach to.
While standardizing on things like the naming and meaning of individual element is needed, in some cases information is represented in ways which is just different.  I have worked for many years on the concept of 'power state' (and aided in our move from a 2 power state world - on/off - to one with 3 - on/sleep/off). In some cases, models combine power state with a functional state of device (e.g. if a printer/MFD is printing, scanning, neither, etc.) into one enumeration.

In UML it is common to successively refine a system design from conceptual (messages) to logical (messages with named fields) to physical (messages with strongly-typed named fields).  A YANG schema is a physical model that defines syntax.  SDF is a logical model that needs to define structured elements and "the naming and meaning of individual elements" of those structured elements.

Semantics covers meaning. Does it also unambiguously include standardized names and relationships?  Or would:
       "modelling only the semantics and structure of the content"
be better?

Regards,
Dave

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Sep 2020 12:21:24 +0200

> “Semantics and structure” would be okay with me, although I wonder whether “structure” might end up being too rigid.  E.g. I see that the structure  of the data tree that is defined by YANG to be v…

I like that — “structural interoperability” usually is at the data model level, and SDF really is about the information model level (even if it looks like a data model at a first glance).

Grüße, Carsten

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Sep 2020 10:41:34 +0000

Hi Carsten, all,

Sorry if I have missed a possible reply, but did you have any further thoughts on this point?

> One choice could be to add this as an optional second item to the charter?
> So, if there was interest in working on such a mapping then it would be in
> scope, but if there isn't interest, or if the interest is for the work to
> be done elsewhere then that would also be okay.

Regards,
Rob

> From: Rob Wilton (rwilton)
> Sent: 14 September 2020 17:26
> To: Carsten Bormann <[email-masked]>
> Subject: RE: [Asdf] Robert Wilton's Block on charter-ietf-asdf-00-01:
> (with BLOCK)
> 
> Hi Carsten,
> 
> Note, some of the YANG proponents (Lada in particular) has pushed for YANG
> to become a more generalized data modelling language.  The YANG data
> structure extension (RFC 8791) arguably heads in this same direction.
> 
> I would also like YANG to support floating-point numbers, and that might
> happen in a future version of YANG.  But realistically, I can't really see
> a new version of YANG materializing in anything less than 2 years, and I
> appreciate that the requirement for SDF is something much sooner than
> that!
> 
> 
> >
> One choice could be to add this as an optional second item to the charter?
> So, if there was interest in working on such a mapping then it would be in
> scope, but if there isn't interest, or if the interest is for the work to
> be done elsewhere then that would also be okay.
> 
> Whatever we decide on the point above, I also think that it would probably
> be useful to have a short paragraph in the background section that
> acknowledges the existence of YANG and very briefly explains how the SDF
> effort is different.  I would see that the purpose of such text would be
> to help someone who is less familiar with YANG/SDF understand the
> differences.
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Sep 2020 14:26:45 +0200

>> be done elsewhere then that would also be okay.

Since I don’t see YANG people lining up for doing an ecosystem document for SDF, I don’t think this should be on the charter (if and when that energy happens, we can easily recharter).

I think that maybe the sentence…

> The Thing-to-Thing Research Group (T2TRG) and its WISHI program can be instrumental in engaging researchers and other SDOs in this space, for instance W3C WoT, which is working on Thing Description Templates and related specifications.

…could be expanded to include internal relationships in the IETF as well.
We are already looking at using YANG for describing register-oriented data models (think Modbus), and it doesn’t look far-fetched to include YANG-SDF in the above picture.

Grüße, Carsten

---

From: David Kemp <[email-masked]>
Date: Thu, 17 Sep 2020 09:42:09 -0400

If SDF is to provide interoperability at the information model level, what
is the maximum flexibility it can have while achieving that goal?

Just thinking aloud about graph theory (since FDT is mentioned in the
charter), a tree is a singly-connected graph.  Picking a root turns a tree
into a DAG, which has the kind of structure that "structural
interoperability" evokes.  Going the other way and removing the
directedness of a structured specification gives a topological view.
That's too geeky a word to put in a charter, but is that (defining
topologically equivalent relationships) an appropriate metric for
interoperability at the information model level?

Either way, "semantics and organization" sounds good to me.

Regards,
Dave

On Thu, Sep 17, 2020 at 6:21 AM Carsten Bormann <[email-masked]> wrote:

> > “Semantics and structure” would be okay with me, although I wonder
> whether “structure” might end up being too rigid.  E.g. I see that the
> structure  of the data tree that is defined by YANG to be very rigid, but I
> had got the impression that SDF might be intended to be more flexible than
> that.   Hence, “semantics and organization” could be a possible alternative
> that might be a bit softer, but I don’t feel strongly on this …
>
> I like that — “structural interoperability” usually is at the data model
> level, and SDF really is about the information model level (even if it
> looks like a data model at a first glance).
>
> Grüße, Carsten
>
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Sep 2020 13:50:32 +0000

> Sent: 17 September 2020 13:27
> Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>
> On 2020-09-17, at 12:41, Rob Wilton (rwilton)
> Since I don’t see YANG people lining up for doing an ecosystem document
> for SDF, I don’t think this should be on the charter (if and when that
> energy happens, we can easily recharter).
[RW] 

Okay.

When this charter goes for external review, I'll highlight it to the YANG folks to see if they have any interest.

> > The Thing-to-Thing Research Group (T2TRG) and its WISHI program can be
> instrumental in engaging researchers and other SDOs in this space, for
> instance W3C WoT, which is working on Thing Description Templates and
> related specifications.
> 
> We are already looking at using YANG for describing register-oriented data
> models (think Modbus), and it doesn’t look far-fetched to include YANG-SDF
> in the above picture.
[RW] 

I don't mind either way.  I'll leave it to the ASDF proponents to decide whether to change this text.

Regards,
Rob

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 17 Sep 2020 16:58:05 +0200

Dear Rob, all,

Indeed, we did some work that allows for YANG to be used for various
purposes on the IOT landscape, including doing semantic model definitions
(e.g. https://tools.ietf.org/html/draft-petrov-t2trg-youpi-01 + a Resource
Directory/Thing Description integration at one of the Hackathons).

So, it *could* be done, but I think it will require a wider interest from
the YANG community. That's something we encountered with the CORECONF work
as well.. At some point, you want people to say explicitly - IOT is
something we care about and we'd like to include it as a first-class
citizen at the YANG/*CONF design considerations.

Maybe a work item of the future charter could point at a YANG-SDF
interoperability? So, whatever SDF turns out to be at the end, there is a
mapping to YANG, which is one of the goals of SDF anyways.
> That one will need contributors and people from the wider YANG community
willing to do the work.

Cheers,
Alexander

On Thu, Sep 17, 2020 at 3:52 PM Rob Wilton (rwilton) <rwilton=
[email-masked]> wrote:

> > >> So, if there was interest in working on such a mapping then it would
> be
> > in
> ASDF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/asdf
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Sep 2020 11:38:31 -0400

Are we at a point now where Michael can send me updated charter text,
and we can see if Rob can clear his block ballot on that?

Barry

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Sep 2020 15:42:50 +0000

Yes, I think so.

Rob

> From: iesg <[email-masked]> On Behalf Of Barry Leiba
> Sent: 17 September 2020 16:39
> To: Rob Wilton (rwilton) <rwilton=[email-masked]>; Michael
> Richardson <[email-masked]>
> > > > Sorry if I have missed a possible reply, but did you have any
> further
> > > thoughts on this point?
> > > >
> > > >> So, if there was interest in working on such a mapping then it
> would be
> > > in
> > > >> scope, but if there isn't interest, or if the interest is for the
> work
> > > to
> > When this charter goes for external review, I'll highlight it to the
> YANG folks to see if they have any interest.
> >
> >
> > >

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Sep 2020 17:55:49 +0200

On 2020-09-17, at 15:42, David Kemp <[email-masked]> wrote:
> 
> If SDF is to provide interoperability at the information model level, what is the maximum flexibility it can have while achieving that goal?

Hi David,

this is actually the heart of the interesting issues that come up when building translation tools.  There is more than one valid answer to this question, which is one of the reasons why I think tool building is more productive at this point than mere document writing (where a tool of course always includes documentation).

There are also tons of small things.  Random example: I just talked to a master student who is looking at attacking this problem, and we briefly dived into the regex issue — both YANG and SDF have a “pattern” statement/quality, but they happen to use two very distinct regex specifications (XSD regex vs. ECMA-262 regex, where the specific dialect isn’t even defined in sufficient detail in the spec from which SDF is borrowing the regexes).  Another random example is number systems.  I don’t think we want to *solve* all these problems right away, but I think it would be a good piece of work to *list* them so we know about them.  Hence my interest in getting work on this done in T2TRG.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 16:39:12 -0400

> I’m not sure what “RPC” is a code word for here.

Remote proceedure call.  The network transaction mechanism.
I feel that the term is sufficiently abstract as to encompass pretty much all
the various models.

    > Maybe the word “interaction pattern” is what you are looking for.  YANG
    > has two groups of these: data store (~ SDF properties) and RPC (~ SDF
    > actions).  Add YANG push for ~ SDF events.  (Note that, while SDF’s
    > current three interaction patterns seem to cover a lot of ground, it is
    > not certain that we will stick with exactly those three.)

Will SDF actions translate directly to actual bits on the wire?
I didn't think so.  I thought it would always involve a translation to some
other SDO mechanism, who already do bits on the wire.

    > I put in a couple of smaller comments in
    > https://github.com/one-data-model/ietf108/pull/8/files for your kind
    > attention.

Thank you.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 16:50:29 -0400

Rob Wilton (rwilton) <[email-masked]> wrote:
    > But I'm still not really seeing how the RPC behaviour for SDF is
    > fundamentally different from YANG.  In particular, I think that there
    > will probably need to be some common expectations about general RPC
    > behaviour to facilitate allowing protocols to be able to interoperate
    > in some way, unless this is not a goal at all?

My understanding is that it is not a goal at all.

That the point is to have semantic interoperability, rather than
bits-on-the-wire interoperability.

So a gateway system (one of the smart speaker systems with skills, or that
project Marshall Rose spearheaded. Dang I can't find it...) can speak four or
five protocols to the devices involved.
It can make sense of temperature coming back via different paths, such that
not all of your temperature sensors have to be from the same ecosystem.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 17:02:02 -0400

> and we can see if Rob can clear his block ballot on that?

Yes.
I didn't manage to edit things on Thursday, as I was unwell, but if Rob and
Carsten and the rest of the list could visit:

https://github.com/one-data-model/ietf108/pull/8#pullrequestreview-491767750

to make sure that I interpreted your suggestions correctly.

I edited the suggestions into the github suggestion process, but I think that
given timezones, I'll just accept them all and generate a new diff, which is
at: https://github.com/one-data-model/ietf108/pull/8/files?short_path=778830d#diff-778830d439b70bb644e57dac072da3e6
below

+  The IETF also defines the YANG data modelling language (RFC 7950).
+  YANG has a strong focus on modelling the management interface for network devices,
+  using a fairly small set of network management protocols,
+  whereas SDF is designed to span (and transitively unify) many existing
+  interaction models already present. 
+  While data associated with a YANG schema can be serialized to a variety
+  of wire formats (e.g., XML, JSON, CBOR, and others), the serialization is
+  driven directly by the structure of the data models defined in YANG; there
+  is no separate "protocol binding" step as in the use of SDF. 

+  YANG also has an opinionated way in which the RPC is done.
+  This is necessary in order to get the kind of cross-vendor
+  interoperability needed for efforts in the Software Defined Networking. 
+  Conversely, SDF does not deal directly with serialization at all,
+   modelling only the structure and semantics of the data being interchanged, hence leaving data
+   serialization (and RPC semantics) to other standards, most likely defined
+   by existing IoT SDOs.

If this satisfies Rob, Carsten and the other reviewers then I'll accept the
pull request, and update the DT with the new text.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Sep 2020 23:06:11 +0200

> +  interoperability needed for efforts in the Software Defined Networking. 

If you strike these three lines (which I don’t see any purpose for, and which will take a while to fix), I’d approve.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 18:04:23 -0400

> If you strike these three lines (which I don’t see any purpose for, and
    > which will take a while to fix), I’d approve.

done.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Sep 2020 07:45:59 +0200

>> which will take a while to fix), I’d approve.

Merged #8.

So I think this is the version we can reflect back to Rob to see whether he can clear his block.

Grüße, Carsten

---

From: Barry Leiba <[email-masked]>
Date: Sat, 19 Sep 2020 15:21:29 -0400

OK, the charter has been updated in the datatracker.  Rob?

Barry

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Sep 2020 18:03:16 -0400

The proposed ASDF charter now reads.
(I thought I could update the DT copy, but apparently not)

# Charter proposal for an ASDF WG

- Name: A Semantic Definition Format for Data and Interactions of Things (ASDF)
- Revision: 1.0.0

## Background

  Data and interaction models of IoT devices today exhibit unneeded
  diversity between different industry ecosystem standards development
  organizations (SDOs), hindering interoperability across these
  ecosystems with little discernible benefit from the diversity.
  Early 2019, [One Data Model (OneDM)][2] was started to bring several
  IoT SDOs and IoT device and platform vendors together under a broad,
  multi-party liaison agreement, with a goal of arriving at a common
  set of data and interaction models that describe IoT
  devices. Ideally, for every class of IoT device, there is just a
  single model selected/created by the participating organizations,
  which everyone can adopt.

  As a common language for writing down these models, the Semantic
  Definition Format (SDF) was created, which can represent IoT Things,
  their composition from reusable Objects, their Interaction
  Affordances (Properties, Actions, Events), and the data models
  relevant to describe these Affordances.  SDF is representing these
  models in JSON, enabling re-use of specification formats such as
  CDDL (RFC8610) and the formats proposed at json-schema.org and their
  tooling, for describing both the SDF format itself and the structure
  of the data to be modelled in SDF.

  Some 200 models in SDF format have been contributed by participating
  ecosystems; new models are being submitted continually.  Version 1.0
  of the SDF specification was published on the OneDM github
  repository and as an [Internet-Draft][1].  OneDM is now focusing on
  [consolidating the body of submitted models][3] and developing processes
  for arriving at harmonized models that span different industry
  ecosystems in a common way; they look towards the IETF for
  developing SDF 1.0 further into a high-quality specification.

  While data associated with a YANG schema can be serialized to a variety
  of wire formats (e.g., XML, JSON, CBOR, and others), the serialization is
  driven directly by the structure of the data models defined in YANG; there
  is no separate "protocol binding" step as in the use of SDF.

  Conversely, SDF does not deal directly with serialization at all,
  modelling only the structure and semantics of the data being interchanged,
  hence leaving data serialization (and RPC semantics) to other standards,
  most likely defined by existing IoT SDOs.

## ASDF

  The objective of the ASDF WG is to develop SDF to an IETF-quality
  specification for Thing Interaction and Data Modelling, working with
  experts from OneDM and its contributing organizations.  On the way
  to that specification, further functionality requirements will be
  addressed that emerge in the usage of SDF for model harmonization.

  The ASDF WG will work closely with the CBOR WG, home of the CDDL
  specification.  It will also engage the still active mailing list of
  the dormant JSON WG.  Recent proposals to form an IRTF formal
  description techniques (FDT) Research Group may lead to another
  collaboration partner.  The Thing-to-Thing Research Group (T2TRG)
  and its WISHI program can be instrumental in engaging researchers
  and other SDOs in this space, for instance W3C WoT, which is working
  on Thing Description Templates and related specifications.

[1]: https://www.ietf.org/id/draft-onedm-t2trg-sdf-00.html
[2]: https://onedm.org
[3]: https://onedm.org/faq

## Initial Milestones

There is only one deliverable, the SDF specification.
It is not currently foreseen that this will be split into multiple
documents, but that is also not excluded.
The plan is to evolve the specification in a regular rhythm, with a
new Implementation Draft available about bi-monthly.

* SDF specification ("SDF 1.0"), WG document adopted, September 2020
* SDF specification ("SDF 1.1"), Implementation Draft, November 2020
* SDF specification ("SDF 1.2"), Implementation Draft, February 2020
* (continuing in the rhythm...)
* SDF specification ("SDF 1.n"), PS to IESG, September 2021

---

From: Barry Leiba <[email-masked]>
Date: Sat, 19 Sep 2020 18:25:40 -0400

I’m confused: are you telling me you want other changes to the charter,
beyond what I just updated in the datatracker (which comes from the github
link in your earlier email)?

Barry

---

From: David Kemp <[email-masked]>
Date: Sat, 19 Sep 2020 18:45:41 -0400

>
> Michael Richardson wrote:

RFC 8477 says:

> [SDOs] have done a tremendous amount of work to standardize new protocols
> and profile existing protocols.
> At the application layer and at the level of solution frameworks,
> interoperability is not yet mature.  Particularly, the work on data formats
> (in the form of data models and information models) has not seen the same
> level of consistency throughout SDOs.

One common problem is the lack of an encoding-independent standardization
> of the information, the so-called information model.

The question is will SDOs translate to bits on the wire from a common
information model, or are those bits more ad-hoc and difficult to
translate? The purpose of SDF is(?) to enable deterministic translation of
data across standard formats.  Perhaps SDF actions translate directly to
bits on the wire using algorithms defined by the SDOs?

Regards,
Dave

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Sep 2020 01:14:41 +0200

On 2020-09-20, at 00:25, Barry Leiba <[email-masked]> wrote:
> 
> I’m confused: are you telling me you want other changes to the charter, beyond what I just updated in the datatracker (which comes from the github link in your earlier email)?

I don’t think so.

It may not have been obvious that the datatracker version has some (small) editorial changes; these did not make it back to the charter that MCR copied, but otherwise charter-ietf-asdf-00-02 and the github text are identical.

It probably doesn’t make lot of sense to merge these editorial changes back into the github version.  In case we need to make more changes there on github, I have copied the datatracker text to 
https://github.com/one-data-model/ietf108/blob/master/dt-charter.txt
and updated the README accordingly.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 20 Sep 2020 01:28:13 +0200

On 2020-09-20, at 00:45, David Kemp <[email-masked]> wrote:
> 
> The question is will SDOs translate to bits on the wire from a common information model, or are those bits more ad-hoc and difficult to translate?

That actually depends a lot on the details.

Some SDOs will move over to using SDF for developing new data models.
The SDO-specific protocol information can be usually be added in the form of protocol bindings.
(One issue that we need to find out is whether we can come up with a method to synchronize the revision management of data models and protocol bindings in such a way that there isn’t continual confusion but the development can still move forward without a tight coupling of a common data model to a dozen protocol bindings.)
For older data models being maintained by an SDO, moving to an SDF-centric development model may or may not entail more work.
Some other SDOs will keep (entirely or for their established models) translating their existing models to SDF, but probably also want to create SDO-specific models from SDF models.

Note that there is also a need for a “protocol binding” to database or interchange formats; e.g., at some point we may want to have a spec for how SenML is best used to interchange SDF-modeled data.  YANG has also been brought up.

> The purpose of SDF is(?) to enable deterministic translation of data across standard formats.  Perhaps SDF actions translate directly to bits on the wire using algorithms defined by the SDOs?

Yes, and these algorithms need to be fed by some ancillary information (e.g., what is the number that has been allocated to the Bluetooth characteristic, or to the OMA/LWM2M object/resource, etc.).  For SDF 1.0, we decided we didn’t want to keep this information in the model, because that would mean that a common model needs to change when another SDO picks it up.  But see synchronization issue above.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Sep 2020 19:46:30 -0400

> link in your earlier email)?

No, I think we are done.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 21 Sep 2020 08:41:30 +0000

Looks good.  I've cleared.

Thanks all for the updates/discussion.

Regards,
Rob

> Sent: 19 September 2020 20:21
> > at: https://github.com/one-data-
> model/ietf108/pull/8/files?short_path=778830d#diff-
> 778830d439b70bb644e57dac072da3e6
> > below
> >

---

From: Barry Leiba <[email-masked]>
Date: Mon, 21 Sep 2020 09:46:58 -0400

Thanks, Rob!  And thanks, everyone, for the work on this.  I’ll proceed
with it, and it should be back on 8 Oct for final approval.

Barry

On Mon, Sep 21, 2020 at 4:41 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> > >     > Are we at a point now where Michael can send me updated charter
>
> > text,
>
> > > I didn't manage to edit things on Thursday, as I was unwell, but if Rob
>
> > and
>
> > > https://github.com/one-data-model/ietf108/pull/8#pullrequestreview-
>
> > 491767750
>
> > >
>
> > > I edited the suggestions into the github suggestion process, but I
> think
>
> > that
>
> > > given timezones, I'll just accept them all and generate a new diff,
>
> > which is
>
> > > +  YANG has a strong focus on modelling the management interface for
>
> > network devices,
>
> > > +  whereas SDF is designed to span (and transitively unify) many
>
> > existing
>
> > > +  While data associated with a YANG schema can be serialized to a
>
> > variety
>
> > > +  of wire formats (e.g., XML, JSON, CBOR, and others), the
>
> > serialization is
>
> > > +  driven directly by the structure of the data models defined in YANG;
>
> > there
>
> > > +  interoperability needed for efforts in the Software Defined
>
> > Networking.
>
> > > +   modelling only the structure and semantics of the data being
>
> > interchanged, hence leaving data
>
> > > +   serialization (and RPC semantics) to other standards, most likely
>
> > defined
>
> > > +   by existing IoT SDOs.
>
> > >
>
> > >
>
> > > If this satisfies Rob, Carsten and the other reviewers then I'll accept
>
> > the
>
> > > ]               Never tell me the odds!                 | ipv6 mesh
>
> > networks [
>
> > > ]   Michael Richardson, Sandelman Software Works        | network
>
> > architect  [
>
> > > ]     [email-masked]  http://www.sandelman.ca/        |   ruby on
>
> > rails    [
>
> > >
>
>
>
>