ASDF at IETF123, Madrid

• Thursday Session I 09:30-11:00 (1:30 hours)
• Room Name: Patio 3

Notes being taken by: Jan Roman (thank you)

Admin and update on WG documents…………………………[5m]

MCR:

• (Welcomes the session participants, highlights that it is Lorenzo's
  first on-site chairing)
• Going to talk primarily about digital-twin today
• There has also been a lot of work on NIPC
• (Notices that Meetecho is actually pronounced mi.ti.ko)

Lorenzo:

• (presents the agenda)
• first Carsten will give an architectural overview, then discuss the
  digital twin discussion and nonAffordance drafts, before Carsten
  will present on instance-information
• Then we will discuss NIPC and sdf-relations

MCR:

• Any changes to the agenda?
• (None)

Lorenzo:

• (Mentions the Notewell)
• (gives updates on the current working group documents)

MCR:

• Titles of call for adoption and candicates for WG adoption are
  swapped in the slides, but it does not matter

---

non-Affordance architecture slides [5m]

Carsten:

• Asked to present first so that we can have an architectural
  discussion first before going into the details
• Quickly structure the discussion, there is a draft, that has been
  heavily worked on, but that it is not the point
• Wanted to show one example that highlights the problem
• We have to find out once more what the underlying architecture is
  going to be

• What is instance information then?

  • Could be related to the purpose of life of a device (e.g., I am
    a temperature sensor, but I don't know my physical location)
  • Devices may not know the context they are embedded into
  • This is the problem we have to solve, wanted to be a little more
    general before we go into the details

• What is new then?

  • In SDF we do not have a way to interchange data, we are leaving
    that to the ecosystems
  • Since we are now getting into a situation we are modelling
    concrete interactions, we may also want to model instance
    information itself
  • So we have the NIPC protocolMap for example

• Draft I am not talking about has a number of new concepts, such as
  proofshots, proofshot deltas, event histories etc.

  • Shot in the dark, need to work out whether these work
  • But need to think about the architecture first
  • What we need to decide is whether we want a representation
    format for instances
  • Model-based approach -- could leave the models to ecosystems,
    similar to protocol bindings, would be the OneDM way (e.g.,
    there is no OneDM temperature sensor)

  • Let's talk about this, since the ecosystems that created this
    problem are not the ones that created the model libraries

    • Is something we could do here to kickstart the discussion

  • Data types and units could also be standardized without
    standardizing the whole model

    • Not the only thing that goes into instance information
    • There has been some previous work on this (e.g. , wgs84)

• Keep this in mind as a categorization of information we want to
  standardize, could also include these as examples

draft-hong-asdf-sdf-nonaffordance………………………[20m]

Jungha:

• This presentation is about the SDF extension for Non-Affordance
  Information
• Thank you, Carsten, for the instance-information presentation
• This is about draft -02
• Goal is to create a structured way to describe metadata within SDF
  models without overloading affordances
• Is related to ..

• Therefore, we propose extending the SDF model with the
  sdfNonAffordance class

  • Is for static and non-actionable information
  • Enables tooling support and interoperability

• Is a lightweight extension, does not break the existing the SDF
  model, fits into the models without disturbing existing ones

• There was a discussion about why we are not using the sdfProperty

  • Discussed this during the last interim meeting, but wanted to
    pick it up again here
  • Might lead developers to implement unnecessary runtime
    interfaces
  • Is better to keep it separate

• We propose a runtime format for messages

  • Three types of messages

    • contextSnapshot

      • Sends a snapshot of all the non-affordance information

    • identityManifest

    • contextSnapshot

• Current status: is under WG adoption call until next Monday

  • For this draft, we have updated section 3 and explained why we
    are not using sdfProperty
  • Revised the sections on use cases and static metadata(?)

• There are two issues I want to discuss with you

  • At the moment, we are using sdfNonAffordance, but maybe we can
    change it, might not be the proper way

    • We were thinking about context, annotation or manifest
      instead, would like to hear about your opinion

  • The second issue is how to deal with the instance-information
    draft

    • Looked at the draft, I think we have the same goal, but a
      different focus
    • Provided a slide with the differences
      • I think we have a different scope, model-level vs
        runtime instance messages
      • Decoupling from the model in instance-information,
        useful for a representation of the state over time

MCR:

• We will go through the other draft first and then start the
  discussion

draft-lee-asdf-digital-twin………………………………………[20m]

Hyunjeong:

• Today I will present our work on the digital-twin draft

• We started at the IETF meeting in Prague

  • Over the course of the last versions, we have gradually improved
    the draft, in the latest version we have added ?? and are now in
    the state of WG adoption

• We have added the owner as an example of an sdfNonAffordance

• (Shows an example of an SDF mappign for digital twin)

  • Uses sdfNonAffordance
  • Can be used to model a digital
  • Example have been changed in the latest draft version

• There are different semantic relationships we can model for digital
  twins using sdfRelation

  • For example, we can express that a lightbulb
  • Can use this information to make the workspace more intelligent
    and safer

• During the implementation, the first step of identifying physical
  assets we want to model is very important

• As next steps we want to add more examples

Discussion

MCR:

• I am going to show a slide with information from the differnt
  slides, but we can start the conversion now

Ari:

• Draft has improved a lot, thanks for that
• The draft says that the draft is standards track, but I think we
  discussed that we want to make it informational, is that still your
  plan?

Hyunjeong:

• ?

Ari:

• For prescriptive documents that is a bit more difficult, would not
  recommend expanding the scope to the protocols, focus more on
  mapping to other standards (from ISO, for instance)

MCR:

• Have not been thinking too strongly about the track of the document,
  but informational makes sense

Carsten:

• Important observation is that there is an elephant in the room and
  we are standing on different sides of the elephant, but it is the
  same one
• The comparison table in the slides showed that there are different
  perspectives on the same problem that we should both cover
• We are still in the process of working out our approach, so adopting
  is too early, should come up with a common approach eventually
  instead of deciding between the two columns of the table

MCR:

• It is an open discussion, so I do not want to impose my views until
  I have heard yours

Ari:

• Agree with Carsten, need to figure out what are the components
• Thank you for the suggestions, much better than the current one, but
  we need to figure out what the information should be
• Need more examples, also Jan did a lot of work on that how the
  information should be structured, need to have more discussion on
  that on the mailing list, has been more in the OneDM context so far

MCR:

• Wanted to share examples from the two approaches, a lot of
  similarities (both model the boat), need to find out what the
  differences are
• Could do this during interims, but the meeting should be used also
  due to the timezone differences
• Disagree with Carsten, would prefer an early adoption of documents

Bart:

• Wanted to comment as someone who has not seen an elephant
• Both drafts are doing similar things, but the instance-information
  draft is adding information to an existing model (?)
• For the record: I like sdfContext

MCR:

• Is that $context in the information-instance draft?

Carsten:

• Yes, indicates that the boundary between instance and model might
  not be that clear
• There is information that the device might not be aware of that it
  exists

• Finding a name for "this" does not work since we do not know what
  "this" is

  • So there is more work needed, need a common working group
    understanding
  • We use the $context to capture that kind of information

• As Ari mentioned, the sdf-relation document also fits into this
  problem space since it provides some of the semantic information
  that we would otherwise have trouble capturing

• We are trying to capture information that is beyond the SDF base
  circle, if we do more work then we might be able to get it done
  during the next three or four months

Ari:

• NIPC has contributed a lot to stimulate thinking about topics like
  this
• We might need a little bit more of whiteboarding to work out ideas

MCR:

• Yes, please use the time we have here
• We can schedule an interim, though (that will be during the night
  for some participants)
• Want to capture the differences and find out the commonalities
  • Not A vs. B, but A and B

Ari:

• Would love to hear more opinions
• Had the concern whether we are becoming too specific
• Need to figure out whether we have other domains with similar
  requirements that we can cover with SDF

Carsten:

• This is a model
• In the instance-information draft, we have something that looks very
  similar to this, but have split the information into a model and a
  proofshot, so there are definitely differences

Daniel:

• I have an example
• Contextual integrity, determines whether a data flow is consistent,
  could be expressed with this type of modeling
• Take this with a grain of salt

MCR:

• Is that a hint that we should do some reading on this topic?

Daniel:

• Exactly, will paste it to the chat
  (https://datatracker.ietf.org/doc/html/draft-dsmullen-ppd-architecture)

Daniel Smullen:
https://datatracker.ietf.org/doc/html/draft-dsmullen-ppd-architecture
Daniel Smullen:
https://datatracker.ietf.org/doc/draft-dsmullen-ppd-taxonomy/

• Could be something like a taxonomy
• Subclassing is very important to differentiate whether data is
  allowed to be sent to a certain recipient

Carsten:

• Nice, now we have two meanings for context
• Contextual integrity is interesting because we have data that will
  be provided by someone else, so sdfRelation and sdfType link might
  be useful here
• Would be interested in reading about this topic

MCR:

• Might also solve some of our wording problems

Ari:

• Would be very useful

Junghu:

• Wanted to hightlight that I do not want to compete
  • Want to summarize or converge with the group, so therefore it is
    important to discuss how to merge or harmonize in a good way,
    that is something I wanted to clarify

draft-bormann-asdf-instance-information………[20m]

Carsten:

• I quickly went through the first two slides already

• At the hackathon, we wanted to bring out work together with NIPC

  • NIPC's protocolMap is something we probably want to generalize
  • Interesting observation: protocolMap contains model-related
    information
  • Also need instance-related information, such as the MAC address

• Constructors as an interesting concept

  • After construction, you get a different model, since the device
    has changed

• The other interesting structure is a proofshot

  • People are always wondering how to get information about the
    status of the device
  • Not sure how it is going to fit into the architecture, but we
    wanted to make sure that we can express it

  • Examples show how we have to think about instance and model
    information

    • Interesting question: Who generates the proofshot?

  • Proofshot deltas are another concept

• Instantiation looks a lot like an sdfAction

  • Latest examples model this aspect of lifecycle management
    • Question: How to identify constructors?

• Tons of questions related to constructors

  • ...

sdf-mapping

• instance-information is designed to be used with the sdf-mapping
  draft (which is not on the agenda for today)
• Different mappings for different ecosystems
• Augmentation process is now described in the draft

• Also want to understand provenance

  • Problem is that we cannot identify mapping files at the moment,
    need to specify namespacing for mapping files

• Another document you want to read

Questions

MCR:

• What is a "proofshot"? Cannot find it in the dictionary

Carsten:

• Was originally called snapshot, but is not accurate, since the state
  of different affordances might not be synchronized(?)
• So it is more like a proof

Ari:

• Question about constructors:
  • So far has been done in the ecosystems
  • I guess the initialization could be triggered by interacting
    with the constructor, is that correct?

Carsten:

• We are now looking at devices in the context of digital twins, NIPC
  gateways, etc.
• Might need to specify what to do to initialize the devices (?)

draft-ietf-asdf-nipc…………………………………………………………[20m]

Bart:

• We have an agenda:

  • Status
  • Hackathon
  • Couple of issues that need discussion

• Status:

  • We just released version -10
  • Changes are mostly based on the Hackathon
    • protocol mapping naming
    • registration collection naming
    • problem types
    • editorial issues
    • This draft solves most of the issues from the hackathon

Rohit:

• Same drafts as during the hackathon

  • Have been creating and resolving issues
  • Wanted to do interoperability testing with our gateway

• Three Gateway implementations, one from Ercisson, one from Cisco,
  one Open source

• A lot of insights during the hackathon
• Thanks to everyone that participated in the hackathon

Bart:

• Can recommend doing a hackathon project for resolving the three
  drafts we discussed earlier
• Issues that require WG consensus
  • Query parameters instead of path parameters was discussed during
    the hackathon
  • Using path parameters is prohibited by a lot of server
    implementations
    • Causing a lot of discussion when trying to deploy NIPC
    • Support for % encoding is turned off by a lot of servers by
      default
    • Using query parameters has the main advantage of not
      requiring % encoding
    • Wanted to get WG consensus to do so

MCR:

• Do not understand the examples, they look the same
• First unworkable example should be:
• https://localhost/nipc/devices/12345678-1234-5678-1234-
  56789abcdef4/properties/https%3A%2F%2Fexample
  .com%2Fheartrate%23%2FsdfObject%2Fthermostat%2FsdfProperty%2Ftemperature

Bart:

• this is incorrect in the example

Carsten:

• Quick comment: This is sad -- but necessary

Ari:

• Have to agree with Carsten
• Looked into the RFCs during the hackathon, but the implementation
  state indicated that this might be the right solution
• But others might have a better opinion on this in the longterm

Orie:

• I am not following this enough to make a detailed comment, but you
  need to be careful when using query parameters for identifying
  resources, there was an example from OAuth
• Need to be extremely careful

Eliot:

• This is sort of a bigger issue that is hiding for URI processing in
  general
• WHATWG has made a mess in 3986, and it needs to fix it, or the IETF
  has to take this back...
  • asks that WIT or ART or ??? take a look
  • library developers need to included and avoid the security
    issues
  • and it's limiting our ability to pick it up.
    Orie (as AD):
  • ART/WIT are now different area.
  • happy to talk to WIT ADs... but we need to start with an I-D
  • and it's wide ranging impact.
    Eliot:
  • seems like a third rail issue, and we are having to work around
    it.
  • and we are running into this late in the process.
  • please help us discuss this.
  • (Can the people who think they own the URL world, what is their
    answer?)

MCR:

• Sounds like you are talking about a new BCP document (lessons from
  ASDF)

Ari:

• We are probably not the first ones running into this issue
• Does someone know how this has been resolved before? For example in
  OAuth?
• Would be great if we could avoid query parameters, but we do not
  want to harm progress
• Could also use SDF-specific encoding, but that would also not be
  great

MCR:

• Could send out a two-paragraph email asking for help

Eliot:
?

Carsten:

• We should adress this in the T2TRG and release a status report on
  this topic

MCR:

• Could go into draft-irtf-t2trg-rest-iot-16 (Guidance on RESTful
  Design for Internet of Things Systems)

  • https://datatracker.ietf.org/doc/html/rfc9728#section-1.2 note,
    SHOULD NOT
  • Bart:

• Another issue was the naming of the protocolMap, which is now called
  sdfProtocolMap

• Realized that we could use that for IP-based protocols as well
• Were noodling during the hackathon that we could also use the
  sdfProtocolMap to link to an OpenAPI specification, linking to a
  certain parameter
• Seems like we could also use this for any kind of protocol mapping
  that also includes IP-based protocols
• Now have in the draft, not sure whether it stays there
• Were already considering changing the name

Carsten:

• Could still come up with a retronym
• Regarding the question on the slide on on spinning it out into a
  separate document: Yes, we should to that
• When you split out a part of an already adopted document, adoption
  will be much faster
• Regarding the term map:
  • There are a lot of usages of "map", so we should do some more
    offline linking on how we can reduce the number of map usages

Ari:

• Regarding the naming: I was also thinking about "protocol"
• For instance, if we have something like OMA, that is not a protocol
• We were thinking about that during the hackathon, we have come
  closer but did not find a solution yet
• Regarding separate draft: Also in favor of that?

Bart:

• Anyone interested in collaborating on the second draft? (Positive
  feedback from the audience)

  • Lorenzo Corneo has volunteered

• Leveage HTTP problem types, but our proposal is that we are going to
  use our own registry for NIPC-related problem types

Rohit:

• On Content types:

  • Defined a new approach for structuring the data using query
    parameters and a new media type application/nipc+json
  • Other media types would still work as is

• Explicit connection management

  • Turned some of the terms into plural form
  • Looking for suggestions for making the connection management API
    for consistent

Ari:

• /devices/{id}/manage/connection would be the natural way of doing
  this (?)

Rohit:

• SCIM SDF extension
  • Considering doing the mapping of the instance in SCIM instead of
    SDF
  • Since the models do not contain any instance information
  • Could spin this into a separate draft

Bart:

• A separate draft seems to be the preferred option here

Ari:

• Agree
• Question is whether it will be normative(?)

Bart:

• Yes, it would have to be
• There are a number of issues that we considered closed, but we will
  discuss these during the interim
• We have more issues to close, we are also still open for reviews,
  please open issues on GitHub
• We will also have Cisco hardware supporting WiFi 7 in Montreal, so
  we will probably be able to do some live-testing there

MCR notes that maybe we have to discuss .well-known vs /devices on the
mailing list. ACTION MCR.

Finding more Authors…………………………………………………………[10m]

MCR:

• some drafts have a small set of authors, so if you want to become an
  author of an IETF document, it would be a good opportunity

Carsten:

• The sdf-relation also has the instance-vs-model-problem
• Similar problem with the sdf-type link draft (?)

Ari:

• These are very critical drafts, so great if someone wants to pick
  them up

MCR:

• Lorenzo has volunteered, but also please consider doing so
• Think we need at least three more authors that are not Ari or
  Carsten, in order to have more communication across documents

Scheduling for virtual interim meetings………[10m]

MCR:

• A lot of authors are from Europe or Asia
• (A couple of WG members are also based on the west cost of America )

The group is agreeing on August 21 and September ???, 4 PM UTC, as the
slot for the next interim meeting.
There will also be a physical meeting in Montreal.

MCR:

• Hope that we will be able to continue working on NIPC and other
  topics the way we did during the Hackathon