sdf-Protocol-Mapping:
ACTION: sdf-Protocol-Map needs to progress quickly so it does not block
NIPC
ACTION: go ahead with current document. - with a couple of real,
non-controversial examples
ACTION: we can non-normatively give openapi example, but not specify it
in this document.
NIPC:
ACTION: Being able to bind events across technologies is really
important
ACTION: another virtual interim meeting for NIPC.

ASDF meeting 1, IETF124, Montreal.
12:00

Logistics:

1. https://meetecho-or.ietf.org/client/?group=asdf
2. https://notes.ietf.org/notes-ietf-124-asdf

Notes: Michael Richardson, Jan Romann, YOUR-NAME-HERE

Agenda:

1. Admin/Note Well
   2a. ASDF-SDF-PROTOCOL-MAPPING: Rohit
   2b. ASDF-SDF-PROTOCOL-MAPPING: Carsten

2. draft-ietf-asdf-nipc-14.

3. AoB

1 Admin/Note Well

• MCR:
  • Second meeting on Wednesday
  • First protocol mapping, then the rest of the session will be on
    NIPC
  • (points to the note well)

2 SDF-Protocol-Mapping

Presentation by Rohit

• RM:

  • Slides on the SDF Protocol Mapping are part of the NIPC slides

  • Since the last IETF, the draft has been adopted, published a -01
    version

    • updated and fixed the CDDL
    • added a SCIM extension, as discussed during the last IETF
    • added an IANA registration for the SCIM extension

  • (shows the SCIM extension on slide 3)

    • the extension contains a list of SDF names
    • we added the registration and the schema

  • Should we continue with this topic or should we go to NIPC?

• MCR:

  • We are going to stay on this topic and Carsten is going to
    present something related to it

Presentation by Carsten

• CB:

  • (Date needs to be updated)
  • Objective of the two slides: remind ourselves why we are
    designing the model-level
  • Should start thinking about the instance level as well
  • Slide 1 shows an example of an sdfObject containing a
    temperatureSensor with a single sdfProperty "temperature" with
    an sdfProtocolMap for coap
  • I think we understand that, so how should instance information
    look like?
  • (Slide 2)
  • To make use of the model, you need to know the context, for
    example the IP address
  • Somewhere, we should say what IP addresses look like, so far we
    did not have the need to define IP addresses at the class level,
    this is important for this example, since we want to be able to
    provide an IP address at the instance level
  • Apart from the model information, we have information coming in
    from the instance and both types of information are needed to
    perform an interaction
  • What is still open is the question of how to link the context
    information with the information from the sdfProtocolMap
  • That is all I want to say for now

• AP:

  • Follow-up question: What happens if the IP addresses or if you
    run CoAP over a non-IP-based transport or use an identifier

• CB:

  • There is an identity manifest
  • Indeed a good question
  • One protocol in the draft is BLE, which uses MAC addresses
  • This is another example for the need to link the context
    information with the protocol mapping

• MCR:

  • I think Alex also raised the question that you do not want to
    replicate the IP address multiple times

• CB:

  • I think he didn't, but that is certainly something you want to
    avoid
  • Putting it in the context is a way to avoid this but we still
    have not figured out how to do the linking

• MCR:

  • Is there other meta information that needs to included here?

• CB:

  • ??
  • There are many ways to solve this problem, I just wanted to
    remind you that we need to think about this problem

• MCR:

  • Is there another radical proposal? I think this sounds good,
    should we go ahead with it?

• AK:

  • I think the proposal looks good
  • Was beginning to think about this offDevice/onDevice, since the
    device probably knows about its IP address
  • Since the proposal won't affect sdfProtocolMap, we can go ahead
    with this

• CB:

  • Depends on whether the context information is reaching into the
    sdfProtocolMap or vice versa

• RM:

  • I think this will not affect what we currently have in the draft
  • But the aspect with the MAC address is relevant(?)
  • MAC address is available via SCIM, so the sdfProtocolMap is
    independent of that

• CB:

  • Raises the question how to combine instance information from
    different sources

• LC:

  • ACTION: sdf-Protocol-Map needs to progress quickly so it does
    not block NIPC

  • ACTION: go ahead with current document.

    • with a couple of real, non-controversial examples

  • ACTION: we can non-normatively give openapi example, but not
    specify it in this document.

  • Touches the question how to move forward as quickly as possible
    we the draft, since there is a dependency between NIPC and
    sdf-protocol-Map
  • Have additional protocols, BLE and Zigbee, but also other
    potential additions such as open-api, CoAP, HTTP
  • Would be a possible to strip everything out except the registry
    definition

• CB:

  • ..

• BB:

  • I think it would be very useful to have a few examples in the
    draft
  • So I think we could leave these in and then move forward with
    the current state

• CB:

  • Not examples in the narrower sense, but initial registrations
    useful for real life

• MCR:

  • Does it need to go into another document (e.g., NIPC)

• CB:

  • I think we want to go ahead as is and create the two initial
    entries and call it done

• RM:

  • We also have openapi
  • Should definitely keep BLE and ZigBee

• CB:

  • Referencing OpenAPI opens another can of worms, that we should
    not open

• RM:

  • Could leave it in as an example

• CB:

  • Yeah, that sounds good

• AK:

  • Was useful to have these as exercise to ensure the mechanism
    extends nicely, but don't need to have more than the actually
    used ones in the RFC

• CB:

  • Need to be prepared that people will think that the examples are
    registrations, but we can leave them in as examples

• AK:

  • Question regarding the SCIM extension: Had some discussion on
    that on moving it to the appendix, I would suggest moving it to
    the core document

• RM:

  • Was a suggestion by Eliot
  • Moved to the appendix since it does not refer to the
    sdf-protocol-map itself

• AK:

  • For referencing in other documents, the informal language in an
    appendix seems a bit too "casual". Better have it in the
    normative part of the doc and with normative language.

• RM:

  • Will reconsider it (?)

NIPC

• BB:

  • Release draft 14 yesterday
  • Focused on fixing items
  • 9 items need discussion, will focus on that today
  • (shows the fixed items)
  • Most items have been raised by Ari and Michael
  • Please give feedback on whether the issues have been fixed to
    your liking
  • If there are not additional comments, we will close the issues
    by November 17

  • (slide 7)

    • changes that required discussion were those that required
      API updates
    • improved the API for interacting with groups
      • now the IDs of the respective devices is being included
        in the resource that reports the events that have
        occurred

  • (slide 8)

    • There was some criticism regarding our use of the term
      "onboarding"
    • We define what onbarding is the NIPC sense, onbarding is
      happening via SCIM, additional information comes from a
      device context
    • We are open to other proposals, but we are believing
      strongly that "onbarding" should be continued to be used as
      this is the term SCIM uses

• MCR:

  • I understand your reasoning, maybe SCIM should reconsider its
    use of the term then

• AK:

  • Agree with your reasoning
  • Referring to SCIM for the usage of the term makes sense
  • Could also update the T2TRG IoT sec document to include this
    term from SCIM

• BB:

  • (slide 9)
  • There was also a discussion on the use of the registration term
  • Is currently being used for both data-app and SDF models
  • Wondering if using a different term in the API (e.g.,
    /authorizations) makes it clearer
  • Would prefer to leave it as is
  • Did not have the time to address this, so hearing other people's
    feedback would be great

• MCR:

  • ..

• BB:

  • (slide 10)
  • Michael brought up that it would be interesting for a NIPC
    gateway to map one protocol to another, e.g. use Zigbee to turn
    on a BLE light
  • Did not think about it initially, but it is interesting
  • Question whether we could implement features cross-technology
  • Interesting idea and I think we should look into it
  • bindings would refer to instances of devices and not classes
  • So it would rather be part of the sdfContext

  • bindings would probably always bind events to an action

    • Question on cardinalities, 1 to 1 or 1 to n for example

  • Could be an interesting concept for NIPC, should investigate
    that

• CB:

  • ACTION: Being able to bind events across technologies is
    really important
  • Have been working on this in the CoRE working group

  • In SDF there was a draft regarding sdfType links, doing exactly
    this

    • QUESTION: draft-ietf-asdf-sdftype-link-00 ? core-dynlink?

  • Provides a way to specify that there is information that points
    to something else

  • Uses the web linking approach, might need to extended for NIPC,
    but could exactly address this problem
  • Should could come up with examples, should see whether using the
    link concept could solve this problem

• BB:

  • I do not see yet why this be defined at the class level
  • Linking is rather instance-specific, linking two particular
    actions together

• CB:

  • Whole point of the class is to define the information about the
    linking, the instance-level would then provide the exact values
  • model should define, for example, that a switch needs a link (to
    a light or a dimmer, ...) to be useful
  • Just need an indication that the other thing exists
    • draft-ietf-core-dynlink-14 maybe
    • draft-ietf-asdf-sdftype-link

• BB:

  • Thought that this might be something we want to include in the
    NIPC draft as well
  • Providing a way to specify that you need to link two devices
    together
  • Probably not in this revision
  • (slide 11)
    • Naming is another issue that needs discussion, as NIPC could
      also be used with IP-based devices
    • Also touches the question whether NIPC is relevant for
      IP-based devices in the first place

• AK:

  • As I mentioned before, I think the answer is "yes"
  • Question whether you want to have a different infrastructure for
    IP-based devices or reuse the existing one
  • I would suggest using the retronym

• CB:

  • Apparently, we do not want the acronym to restrict what we want
    to do
  • That suggests using a retronym
  • Something I wanted to point out is that we have a gateway
    function here and that we do not care whether we are using IP or
    not
  • I think we need to capture that part and then just go ahead and
    retronym NIPC

• MCR:

  • My comment: Let's do it and then say that it could be
    non-IPv4-connected or non-IPv6-connected, also have BLE devices
    on a different radio
  • Other thought: could have two gateways that are tunneling BLE
    via ...

• BB:

  • Many reasons for the retronym
  • (slide 12)
    • Implementation section: Have a section, do we need to
      mention anything else here

• MCR:

  • Implementation Status/Report will get removed by RPC anyway, so
    links do not need to be long-term stable.

• BB:

  • Do we need both OpenAPI and CDDL in the final document? Do not
    want to make the document unnecessarily long

• CB:

  • Important observation: There are multiple data definition
    languages, for example SDF uses CDDL and json-schema.org
  • Important aspect is that you have extension points defined

• CE:

  • Regarding implementations: I think it is important that you are
    very clear with your specification (?)

• BB:

  • ACTION: another virtual interim meeting for NIPC.
  • (slide 13)
    • Still things that are work-in-progress, can discuss them in
      another interim
    • need to do something proofreading and another round of
      working group reviews, then we should be in good shape

AOB

• MCR:
  • Enjoy your lunch

Session 2 (2025-11-05)

1 Admin/Note Well

• MCR:
  • Please be nice to each other

  • When should there be the next interim?

    • We will go on with first Wednesday of December, 7 AM UTC

      • 2025-12-03, 09:00 Helsinki
      • 2026-01-07, 09:00 Helsinki

    • Will send a message over the mailing list

2 sdf-non-affordance

• JH:

  • Presenting the draft SDF extension for non-affordance
    information

  • (slide 2)

    • Let me summarize what happened since the last meeting in
      Madrid
    • Document was adopted, changed the keyword name from
      sdfNonAffordance to sdfContext
    • Document was adopted, in August an updated version was
      posted, we did not present the document yet, since besides
      the keyword name there were no significant changes
    • In the most recent version, we added some use cases
    • Besides that, we had a number of discussions between us and
      the authors of the instance-information draft, Carsten and
      Jan
    • Four meetings of the "design team" besides two face-to-face
      meetings in Madrid and Montreal
    • Made good progess harmonizing the concepts of our two drafts

  • (slide 3)

    • sdfContext is supposed to be a new keyword at the same level
      as sdfProperty, sdfAction, and sdfEvent
      • Can be used to describe information such as location,
        manufacturer, calibration, ...
      • Structure is similar but the purpose is different
      • As you can see in the example, it is rather about
        descriptive information, such as serial number,
        installation information

  • (slide 4)

    • Thought about having a litmus test for deciding between the
      two keywords
    • We are working on it within the design team
    • We are also working on harmonizing the different message
      types within the design team
      • e.g. identity manifest vs construction message

  • (slide 5)

    • As an example, we are trying to create a common message
      format
    • For example, for the context snapshot, we are trying to move
      the contents to the common message format
    • We are going to define a formal schema of sdfContext using a
      CDDL definition

  • (slides 6)

    • The rest of the slides are the same as the ones from the
      interim to show what the difference between the message
      types are
    • For example, the contextSnapshot is only giving the
      descriptive identity and context, while the proofshot also
      reports the current state of the device, so the messages are
      different

  • (slide 7)

    • contextPatch and deltas:

      • contextPatch is performing an update and only changes
        the keys since the last contextSnapshot
      • Deltas are reporting the result of the state change

    • So there is a difference of the two messages

  • (slide 8)

    • identityManifest declares an immutable identity and
      certification metadata, answers who I permanently am
    • Construction message provides the initial parameters for the
      construction, answers "How am I created in the system"
    • We explained the differences, hope that this has been a
      clarification

• MCR:

  • We need more reviewers (of course the chairs are included)
  • Anybody else? Okay, let's move on

3 instance-information

• CB:

  • (slide 1)

    • Want to talk about essentially the same things
    • We are not a formal design team, but we act as one
    • In our discussions we seem to have some convergence
    • In our presentations, you will hear similar things, but with
      different emphasis
    • In the meeting on Monday, you already heard something about
      sdfProtocolMap and sdfContext
    • In computer science, we are always talking about state, with
      sdfProperty and sdfContext we have different versions of
      that
    • I am going to talk about the relationship between
      sdfProtocolMap and sdfContext again, but I am going to skip
      two slides
    • We need to think about when to complement the class
      information via instance information, that, however, needs
      to be controlled by the model

  • (slide 2)

    • sdfProtocolMap is interesting because it is instance-related
      information that is defined at the class level, in this case
      we have a CoAP protocol map

  • (slide 3 + 4)

    • Then of course the question is, if we can put the rest of
      the information into the instance message, for example the
      IP address
    • One problem of course that if you have mulitple properties
      then you will of course have a lot of redundancy
    • Question is where to put this information
    • We can definitely think about putting this information in
      the sdfContext that can be shared across affordances
    • Problem is of course that while the ipAdress is defined in
      the sdfObject the relationship is currently implicit which
      is not good
    • So we need to think how to be more explicit here

  • (slide 5)

    • This is a context snapshot
    • In this example, we have a model of temperature sensor being
      referenced that is accompanied by an IP address
    • With this information, another device can perform an
      information
    • It is a context information in the sense that it only
      contains context information

  • (slide 6)

    • As I mentioned, context information needs to be more
      explicitly

    • Also security should be describable

      • Marco actually told me that you do not need anything to
        describe OSCORE since the devices are negotiating its
        usage among themselves
      • But there might something we want to say about that

    • Similar considerations apply to transport-layer security

  • (slide 7)

    • Good to talk about this in terms of examples
    • Here we are saying that we want to use EDHOC and OSCORE

    • Other people are already modelling something like this in
      YANG

      • So we may want to think about model harmonization and
        synchronization

    • EL:

      • Has this been validated? Would be nice to have a valid
        example
      • CB:
        • Syntax error regarding the missing name of the
          sdfObject, apologies
        • This example has two qualities, an sdfProtocolMap
          and sdfSecurty

  • (slide 8)

    • This is essentially the same thing regarding DTLS

• AP:

  • Very interesting examples
  • Can you express that you want to use, e.g., OSCORE with a
    certain IP address?

• CB:

  • Important to keep in mind: We are describing the device, what
    we describe is overridden by the (D)TLS protocol flow
  • So it is important to keep this in mind and not compromise our
    security protocols

• RM:

  • Do we need to repeat the security map for everything in the
    object?

• CB:

  • This raises the same question whether we need to repeat
    everything again, but I hope not

  • (slide 9)

    • Much of this work is currently speculative
    • Reminds me of 2019, when we started to work on SDF, where
      not all of the ideas made it into the final document

    • Already talked about that we do not want to interfere with
      the protocol flow

      • Need to think which pieces of information we want to
        include

    • Second bullet point points to the fact that we have
      different audiences here

      • Want to "shield" the implemeters from all of the
        details, points to sdfContext

    • Access control itself needs to be access-controlled

• ??:

  • Want to ask about the question whether we want to model
    information that is only relevant for implementers
  • ??

• CB:

  • If we have a temperature sensor, then it is pretty clear that
    the temperature is instance information
  • If we have multiple manufacturers, we do not necessarily want to
    include all of the information in the model and move it to the
    instance

• ??:

  • What separates an instance from a class?

• CB:

  • Instance is a very small class
  • Instance information often takes a very abbreviated form,
    someone else has already said how the information has to look
    like
  • There was a way proposed to "cheat" by using the const
    keyword, but that was very confusing, should not use class-level
    concepts to describe instances
  • We are not yet entirely done with how instance information is
    going to look like, but are trying to come up with as many
    examples as possible and try to extract the concepts
  • At some point we need to stop working on examples and need to
    work on the actual specification

3 Digital Twin Draft

• HL:

  • Going to present our latest updates for modelling digital twins
  • Was presenting last week already, so this update is going to be
    relatively brief

  • (slide 2)

    • Since the last update in August, we added sdfProtocolMap and
      changed the structure of the document

  • (slide 3 + 4)

    • This is the outline
    • Main changes is a reshuffling of the structure, moving ...
      to section 3

  • (slide 5)

    • Have two examples, the first is a marine example with a boat
    • Indicates the advantages for implementers, improving
      interoperability

  • (slide 6)

    • The table shows the relationship between the different
      components

  • (slide 7)

    • In the healthcare examples, we are showing how to use
      sdfRelation

  • (slide 8-10)

    • Reflects Ari's comment
    • Shows how we are also aligning our results with other SDOs,
      in this case ITU-T

4 SDF Protocol Mapping & NIPC Wrap Up

• BB:

  • Tailend of the last meeting
  • Reports what happened when Lorenzo, Rohit, and I met regarding
    IP-based protocol maps
  • Included some of the slides I only talked about briefly on
    Monday
  • Do you want to present this, Rohit?

• RM:

  • Sure

  • (slide 2)

    • What came up was that we do not really need to have openapi,
      so what we proposed where integrating openapi into an http
      object
    • And we would make it non-normative(?)

    • BB:

      • Idea is to have an optional type field and then in
        this case say that the type is openapi
      • Any objections to that?

    • RM:

      • We would move this to the appendix and make it
        non-normative

    • EL:

      • Not sure whether I am objecting to that or not
      • What is the top-level object we are operating on?
      • I understand what you mean, but I need a little more
        time to digest this
      • Need a couple of additional weeks to process this, it is
        definitly is an interesting approach

    • CB:

      • You are now separating what protocol to use and how to
        access it, which is good
      • OpenAPI itself might include descriptions of how to use
        additional protocols, so I am not sure whether it is
        good to preempt that

    • EL:

      • If we go this route, we would to say various things
        regarding how to use OpenAPI, which might open a can of
        worms

    • BB:

      • I think the argument on Monday was that OpenAPI is not a
        protocol

    • EL:

      • Could see OpenAPI as its own protocol map
      • Would flip back to OpenAPI, would not like to tamper
        with that

    • CB:

      • ...
      • I think in this case the case is totally different,
        since it is only an example
      • So just leave it as this and say if we had something
        like openapi then you could use it like that

    • RM:

      • Oh, we also have an updated CDDL definition

    • MCR:

      • Is there an issue already open for that?

    • BB:

      • There is no issue yet, but I will create one

    • MCR:

      • Seems to be like one of the main issues we need to
        resolve before WGLC
      • But also not that big of an issue
      • Just need to think whether we want to include it

    • BB:

      • Just wanted to have an example for an IP-based approach
        in addition to non-IP-based approaches
      • Will open an issue for that and then wait for Eliot's
        feedback in a week

• BB:

  • (slide 3)
    • Still need to add documentation
    • Still need to get feedback from the problem types experts
    • Need an example for how to leverage contentFormat and text
      around that
    • Need more details on data applications and connection
      management
    • The CDDL for the API schemas still requires some more work,
      will go into the appendix
    • Will try to tackle this over the course of the next weeks
    • Please also have a look at the issues and the PRs in the
      meantime and check whether they are addressing your feedback
    • A few issues were also raised as the result of the session
      on Monday
    • Need to proofread the whole document again
    • Then I hope we will be able conclude the work
    • We are in a similar state as the sdfProtocolMap draft,
      should be able to go forward

5 AOB

• MCR:

  • Posted the interim meeting dates

• DS:

  • Shameless plug for iotops later today
  • draft on defining an architecture for dataflows
    • that was why was asking regarding instances earlier,
      interesting to see which dataflows and for which purpose

• MCR:

  • Seems like another non-affordance to me
  • We have two virtual interims planned
  • Need to make more obvious progress, integrate with the digital
    twin draft
  • Enjoy your lunch