Interim 05

Webex https://ietf.webex.com/ietf/j.php?MTID=m296df2f64b965a80b3531fdbd0d053b1

HedgeDoc: https://notes.ietf.org/notes-ietf-interim-2022-asdf-01-asdf

Combined Slides:

Present:
1. Michael Richardson
2. Niklas Widdel     (ASDF Working Group)
3. Carsten Bormann
4. Klaus Hartke
5. Michael Koster  ("OCF Staff")
6. Ari Keränen 

Administrativia out of the way.
Will discuss IETF113 meeting at the 00:40 point.

# ASDF Next Steps

Three pull requests pending: #45, #36, (#49,#50), #52, 

## PR45 - single in/out
    * partially revert SDF 1.1 single-in/out.  
    * Recommendation: WONTFIX.
    * Pro: we would get SDF names for all things, out to individual parameters.

AK: Do we need this feature? Is there a way to get this feature without the type:object construct?
MK: JSON pointer does go through the properties. It is possible we could have it both ways, and when there is a single parameter, it could be simpler.
        Does not think it matters that much, and does not have a good use case. Agreeing with wontfix.

AK: Let's go with wontfix, but let's write down what these pointers look like. 
ACTION: Write a few examples.

## PR 36 - sdfRef Clarifications

Do the clarifications, but do not do sdfRefFrom.
Use another definition as a template with a way to override it, only requires one keyword (with some rules)

An extension, then not in this document. In a future document (extension or revision to this)

_It's a form of "isA"_
    _mightBeA_ instead of _isA_
    _isARefinementOf_
 
ACTION: But, the sdfRef process needs to be clarified in this (1.x) document.
 
## PR 49, 50.  "sdfProduct"

An additional _quality_ is that it's a completed product.... 
People have asked for an sdfSKU...

* believed that sdfThing could do all of this, and we added sdfSKU to this for that reason.
* _how do I compose a bunch of IPSO smart objects into a product?_ 
* it got written in when it was easy to do, but now makes less sense, and should be removed. MK does not think it needs to be a language feature.

ACTION: accept these PRs to remove sdfProduct.

## PR 52. dataqualities, r/w/o

These really describe interactions, not the data!
Suggest moving up to affordance level, but not so easy.

YANG has configTrue/configFalse. Separate constructs for actions (rpc), and events (notifications).
AK: probably easier to later add it, rather than to remove it.  So only have it for properties now.
* proposed to adopt PR.
ACTION: document what is the potential downside.

# plan for SDF2 

* extension points needs to be documented in SDF1
    * adding qualities
* deeper extensions... newer namespaces.


ACTION: WGLC version by the end of January.
ACTION: post -11 with all lines wrapped

# IETF113

No meeting at IETF113 (Vienna), as most participants are not travelling.
    * further virtual interim meetings,