# ASDF -- AGENDA for IETF 109 meeting ## Info Meeting: ASDF WG, IETF 109, 0900-1100 UTC, Nov 17th, 2020 Location: Virtual Bangkok/Meetecho Note taker: Ari Keränen Chairs: Michael Richardson and Niklas Widell Meetecho: https://meetings.conf.meetecho.com/ietf109/?group=asdf&short=&item=1 Slides: https://datatracker.ietf.org/meeting/109/session/asdf and https://datatracker.ietf.org/meeting/109/materials/slides-109-asdf-consolidated-slides-asdf-109-00 Etherpad/CodiMD: https://codimd.ietf.org/notes-ietf-109-asdf jabber: xmpp:asdf@jabber.ietf.org These notes at: https://github.com/ietf-wg-asdf/asdf-working-group-notes.git 48 people listed in meetecho, at least ~4 duplicates =========================== ### SDF tutorial SDF overview (from virtual interim) https://youtu.be/_8i6X4AxuOk (17 minutes) (mandatory preparation if you want to sit in first row...) =========================== ## Agenda ### 1. Note Well. https://www.ietf.org/about/note-well/ ### 2. Logistics for Meeting. Agenda bash: no comments. #### 2a. CodiMD for notes https://codimd.ietf.org/notes-ietf-109-asdf #### 2b. Meetecho for speaking. https://meetings.conf.meetecho.com/ietf109/?group=asdf&short=&item=1 #### 2c. Roll call/Blue sheet ### 3. WG status update (Chairs - 10 min) #### 3a. Welcome and discussion of WG proceedures Michael Richardson (MCR): one interim and have adopted SDF draft 1.0. Working now on 1.1. Hackathon last week very number of issues were discussed and solutions found. Will plan for virtual interim roughly once a month, starting December. Discussion in Github issues. Weekly summary on Github discussions coming to the mailing list. Substantial issues are brought to the list. Planning to have "implementation drafts" before the RFC. Niklas Widell (NW) gave brief overview of SDF. Currently there's high intergration cost to work across many existing data models. Develoved neutral format, SDF, to facilitate translation between models in OneDM liaison group. Now SDF standardization in IETF. In OneDM still work on tools, harmonized models, etc. This meeting will be about SDF. Want to reach out to additional orgnizations from the initial set in OneDM. So far presented ASDF to DMSE (LwM2M) group and ISO/IEC JTC1 SC41 group. If your org works with IoT data models and you're not yet involved, please talk to us and we can help to loop you in. MCR: relays from jabber, Eve Schooler: what kind of response from LwM2M and SC41? NW: for DMSE looks interesting for them and seems good fit. Need to do some translation. ISO will be discussed tomorrow. New work item proposal from Swedish standards unit that includes SDF has been submitted. ### 4. SDF 1.1 Carsten Bormann (CB): got dragged to OneDM work year ago, working to make the document something people can use and get standardized. Planning to have a few upcoming versions as "implementation drafts". Not final products but expectation that will evolve from them. If 1.1 will be -02 or 03, we can have small WG LC and label that version as "SDF 1.1". Will probably have 1.2, .3 and .4 before we submit to IESG for standards track RFC. When talking about 1.1, would recon we're half way towards IESG submission. Have number of open issues in Github. Not necessarily the final set of issues but these seem to get most interest for converint ecosystem models. #### 4a. Issues 3 and 7 https://github.com/ietf-wg-asdf/SDF/issues/3 and https://github.com/ietf-wg-asdf/SDF/issues/7 Issue #3(?) is in SDF 1.0 but needs more validations. Issue #4 we punted composition from 1.0 but now understand what we want to do -- result from hackathon. One big area expression disjunction, choice between alternatives. Two alternatives, one on enums and another JSO enums. Will have proposal for that coming later. In hackathon tested our view on #3. Came up with curie usage that's slightly surprising. ... CB: Issue #3, we can have references in model, based on JSON pointers. Not sure if how space was managed was good. And needed testing. And not yet done in referencing other things. Example of length. Cable length can give us something like a length but modifies description to have minimum. Do we want to allow this kind of overriding? Need to manage namespace. URIs not necessarily resolvable. Name declared in yellow part can be refenced in white part with sdfRef. Names can differ if they use different names for the namespace. Updated example since last month; moved hashmark down to reference. Leads to uniform reference. Local item looks the same as item in ... In exploratory OneDM part have a few examples. Want to use also in other context than data types. Christian Amsüss (CA) from jabber: the semantics of curies are still plain concatenation, right? CB: yes, the path part gives you the uniqueness and part after hash is JSON fragment ID that takes form of JSON pointer. NW: issue #3 can be closed? CB: not quite, slide 14 has question on can we import entire affordances. MCR: can't point to type but e.g. length? CB: that's what proposing. Can write JSON pointer for anything, but question is what pointers are valid for sdfRef. Also sdfRequired that may have different requirements. Should decide for both what are valid. #### 4b. Issue 4 https://github.com/ietf-wg-asdf/SDF/issues/4 CB: aggregation or compound. Constructing something of multiple parts. Punted for 1.0 but could not completely punt so have something awkward for parameter list. Going out for real composition. Second to last bullet (slide 21) has what inheritance means. Example of new syntax. ... Desire to use same syntax JSO (json-schema.org) uses for JSON objects is slightly confusing. Using data model language to represent info model, normal to use one way to represent things to stand in for what we want to represent in information model. Bit clumsy way to exrpress what is required, but wanted to have least suprise for JSO users. Can use same to build parameter lists for actions. In 1.0 had arrays but could not point to them. In the new structure need to write a bit more JSON but can put in names. In 1.0 there as data type with the info but works only when they are sufficiently different. But ran into cases where types are similar, like RGB values. Before close #4, should think if there are other kinds of aggeration we need. Parameter lists now taken care of. #### 4c. Issues 2 and 5 https://github.com/ietf-wg-asdf/SDF/issues/2 and https://github.com/ietf-wg-asdf/SDF/issues/5 These issues are essentially same. #2 was using JSO enum for choice, but doesn't let you define what the values mean. No space in JSO to annotate them with semantic tags. Had various proposals like sdfEnum that were almost the same but with semantic tags. JSO has also anyOf operator for type union. In 1.0 didn't include that. Were hesitant since had not expore alternatives. There's not much difference between the two: lack capabilities to put more info in. Convenience of JSO is when you put just text strings, you know what they mean, but not allways that clear and also small things like typos bring problems. Example (slide 26). On and Off, want explicit names and descriptions. Labels redundant here. Would be nice to have pointer to RDF. Could also be other things like ecosystem translation hints. Example of startup levels. Enum as part of anyOf that has "min value" and "set to previous value". Here difference of anyOf and sdfEnum makes us to do nesting that may not be what we want to do. Also question if numbers are really info model content or not. ... In the github issue example of mapping file. Choice mechanism might be used to give further semantics. Need to make choice is "choice" just type union, if value is in many branches it has the same meaning. In YANG translation this was the most expensive choice. Alternatively choice is named alternatives, labeling the graph. Could also have RDF links. Proposing to go always for named. State example replaces sdfEnum with choice. Example with both kinds of alternatives included (slide 33). Don't need additional nesting. Discussion on this resolution? MCR: anyOf... CB: different since map, and giving here values instead of types(?) (MJK) This also seems to resolve the oneOf/anyOf dilemma with json-schema.org. Also comment that looking at trying to express things from Bluetooth and other ecosystems, really natural pattern. Developers are not experts in languages, want to express a model. Seems to provide good way to do that. Ari: a bit of background, we are now combining the Enum and the choice. Back to slide 27, and here we could have either a "static type", or an enum. CABO: Any type of thing, or Enum. cabo: Trying to represent the choice between the actual setting (which has no name), and the instructions for deriving a setting (minimum, previous value). Ari: so it's the same value interpreted in two different ways. 0, 1..254, 255. discussion about representation way. MK: if you had out of band mechanisms, then one could have more values, and one of them is "current value". These could be mapped in a different way. Ari says that this seems quite natural. MK: one can put the constraints in, but they could be mapped in a natural way. CABO: if you arranged the branches in an array, then one could use the arrangements as the labels. So "choice" could be an array instead of an map. But don't have an example. There is some benefit to using the implicit ordering in the "map"? But it could be very brittle. Ari: using the ordering means that we don't have to assign IDs, but it is brittle. Ari: maybe object IDs and resource IDs do not belong in the information model, but when it comes to enums, they are rather tightly scoped. There is a good chance that the same values would be across multiple ecosystems.... then just use the values in the information on the wire, otherwise all the ecosystems would have create the same mappings. cabo: two cases where what you are saying makes sense. a) some ecosystem does all their work in SDF, so why do their numbering in another file? For them, it would be nice to include ID (labeled for their ecosystems), b) in some converged industrial situation, it would just work (R:0, G:1, B:2, because all the ecosystems use the same mapping) Needs to have a naming scheme that avoids collisions. Ari: When an ecosystems adopts a converted model into a greenfield, then they could just use the previously established/default mapping. MK: we resolved that relying on an array index is a bad idea. Fortunately, we have a way, "default", which already exists in json-schema. Also "constant". Does this meet the needs here? cabo: I think that default is the wrong way. default means that the entire range is available, but if the value is not present, then it uses the value. Does not think that this is intended in this example? Ari: a good way forward, if we can do a three-ecosystem example might reveal the way it would work out. MK: but don't use the numbering to establish the numbering. cabo: most system that can auto-number let one jump to a particular number in the system jumped to: https://github.com/ietf-wg-asdf/SDF/issues/2, comments by WAvdBeek. cabo: if I was writing the code, I would look to see if any of the branches were singletons, and then insert that code. Ari: maybe developing the tooling would help with WAvdBeek concerns. MJK: json-schema.org anyOf and enum can be transformed into each other Ari: the JSO enum does not work because it lacks ability to add description MJK: a uri that contains array index is difficult to keep stable as the array is refactored when adding new elements MCR: mapping to 3 ecosystems a key; if hits a conflict could help pick the right choice CB: question we need to find out: can we make any progress on the actual mappings. Everyone has some form of mapping file in their tools but can we achieve some commonalities in the mappings. Could standardize overall structure of the mappings. If yes, something to aim for for 1.1? Or first thing for 1.2? ACTION: **Ari: wants to ask people from different ecosystems, how do you do enums? can you contribute more diversity of views?** #### 4d. SDF 1.1 next steps CB: people can still propose new issues. Issue #7 needs more examples. We should go into time boxed release process. Given upcoming holidays, maybe Dec 8th final draft for WG to have a look. Could have comments on that and have SDF -03 implementation draft for Christmas. NW: will time virtual interim accordinly CB: could be week before the 27th. NW: mid-December for example. Any objections/concerns on the plan? (none expressed) CB: For 1.2 we should review our success factors. Have translated a set of ecosystems but need to keep track of ecosystems we can't translate yet. Other part is to make attractive for new ecosystems. Imagine IPSO or OCF might go ahead and write SDF in their ecosystem models and translate to ecosystem formats -- main point to have SDF attractive as ecosystem language. Actual stress testing will happen at the ecosystems, people there testing if this is useful. Will need ecosystems to try this and have good feedback links back. Should focus on in 2021. For timeboxing should aim for 1.2 draft completed before IETF 110. Little more than two months to do this. Would be personal goal; will have to see if realistic. NW: two monts not long time and will need to revisit when we get experience but could go forward as proposed. MJK: More SDF pressure test involving developers could be done in the context of OneDM but we really need them to participate in ASDF ### 5. AOB? MCR: Virtual interim in 14-18 Dec week? Some interest in using the slot on Monday OneDM has used. If that's wrong, we can fix it. NW: not very good for folks in Pacific time. But can have that tentative. Can do Doodle; not so many dates but time. MCR: could be 14 and 15th different times. Out of the 50 people here how many would come? How many expect? (Please use raise-hand feature). Seems 6-7 CB: also Wouter MCR: any other comments from people; do you understand the work and where it's going? David Navarro (from jabber): Still catching up but very promissing Mihail Zverev(from jabber): I haven't read the document, but I think I understood the importance of this work. I am going to share this with my teammates working in IoT. Nigel Davis (ND): seems to make sense. Involved in ONF(?). Using UML and have found it useful. Some tooling to generate YANG from UML. Interested to see how you see UML. Talked about different bodies generating models in language. What think of generating tooling for language translation. Found very challenging. MCR: what do you serialize YANG? ND: JSON NW: large part of the work around tooling to enable machine translation. Initial point to translate models from different ecosystems. All kinds of translations interesting. In hackathon had activity to translate to/from YANG. This work is domain specific to IoT devices so some limitation on generality. But when looking at other ecosystems that use UML like OPC UA will deal with this. ND: UML is more rich than YANG in some aspects so lose some. Also need to make more hierarchical than classic network model. May have overdone that. We seem to go for single tree. We found challenges in mapping. NW: we have now tooling for SDF to OCF and IPSO and back. Have looked at Bluetooth. Even with limited application creates some headache. CB: can ND send pointer to the UML models and generated YANG? ND: can do that. Can send links to models and documentation. Github repositories are open, don't need password to get them. Have tooling and docs and models in git. CB: examples of what you think are good for us ND: want to get more involved here, very relevant for us. NW: (for everyone) if part of org that could find this useful, please reach out to us MCR: created Doodle. CB: will be OneDM meeting on Monday. One hour synch on Tuesday-Friday might be good. NW: if anyone wants to be involved in hacking these, very welcome to join the hackathon (meeting adjourned) =========================== ## Documents: draft-ietf-asdf-sdf https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf/