notes go here!
\nhttps://notes.ietf.org/notes-ietf-117-opsawg
Joe is correct that this is not specific to digital twin
", "time": "2023-07-26T20:20:37Z"}, {"author": "Vishnu Beeram", "text": "Is draft-havel-opsawg-digital-map intended to be an informational document (is the current intended status an oversight)?
", "time": "2023-07-26T20:22:20Z"}, {"author": "Beno\u00eet Claise", "text": "Vishnu, it depends whether we want to specify some of the solutions in that document. With the actual content, informational seems more appropriate.
", "time": "2023-07-26T20:24:41Z"}, {"author": "Jan Lindblad", "text": "Note that removing/deviating out the source and destination containers, then augmenting them back in will not give you compatible JSON (nor XML) representations, contrary to what was stated in the presentation.
", "time": "2023-07-26T20:29:33Z"}, {"author": "Robert Wilton", "text": "Not trying to send this somewhere else, but there may be enough overall work here to have a separate WG. But it would be good to present in RTGWG and LSR just to ensure that those folks are aware of what you are doing, and they may want to help
", "time": "2023-07-26T20:51:27Z"}, {"author": "Dan Voyer", "text": "guys, Im new to this working group, so am I at the right place to ask the following:
\nwhat's the state and momentum of openconfig vs IETF YANG - and are or is there someone that is pushing to \"standardize any work on openconfig\" ?
right place, but we have a packed agenda. maybe there is some aob/open mic time in the end
", "time": "2023-07-26T21:03:25Z"}, {"author": "Robert Wilton", "text": "@Dan, in my experience, OC is currently getting more traction, particularly with web players. I can't really see any realistic path to standardize OC models (e.g., within the IETF). Happy to chat at some point.
", "time": "2023-07-26T21:03:47Z"}, {"author": "Robert Wilton", "text": "Should clarify: Some web players and some operators.
", "time": "2023-07-26T21:04:20Z"}, {"author": "Beno\u00eet Claise", "text": "Dan, you should speak to Oscar (Telefonica). This topic was mentioned in the side meeting he coordinated
", "time": "2023-07-26T21:04:34Z"}, {"author": "Dan Voyer", "text": "ok thanks for comment and open mind. Bell we are pushing for OC btw .. but, as I see all presentation going in this session, I see YANG IETF here and there. Is it because its more practical to build the work that way or because this is the church of IETF (and I don't know enough to realized that yet) or whenever someone say IETF YANG it is equivalent to OC ?
\nHappy to discuss offline
I think probably \"church of IETF\". All work on OC models is being done as part of the OC forum which is operator driven, but vendors and others can participate as well. I can provide details if needed
", "time": "2023-07-26T21:14:30Z"}, {"author": "Robert Wilton", "text": "But worth saying that the approach to models and the goals is somewhat different between the IETF and OC (e.g., move fast on core functionality, vs stability and more complete protocol coverage)
", "time": "2023-07-26T21:16:35Z"}, {"author": "Jean Quilbeuf", "text": "I wonder if OC models also cover the controller/network-level models as opposed to device models?
", "time": "2023-07-26T21:17:17Z"}, {"author": "Robert Wilton", "text": "AFAIK, OC is only device models at this time. I'm not aware of any efforts to do network or service level OC YANG.
", "time": "2023-07-26T21:17:54Z"}, {"author": "Randy Bush", "text": "there are vendors forced to mix oc and yang
", "time": "2023-07-26T21:18:19Z"}, {"author": "Dan Voyer", "text": "@Randy, this is also the reality on the operator side. a mix of OC + IETF YANG + Vendors specific YANG. a little nightmare if you ask me
", "time": "2023-07-26T21:19:48Z"}, {"author": "Mohamed Boucadair", "text": "Indeed, Dan.
", "time": "2023-07-26T21:20:39Z"}, {"author": "Mohamed Boucadair", "text": "Things are better at the service/network models as the ones provided by the IETF are well installed.
", "time": "2023-07-26T21:21:10Z"}, {"author": "Juan Cardona", "text": "Static mount, please
", "time": "2023-07-26T21:34:09Z"}, {"author": "Dan Voyer", "text": "@Robert - your point about OC = device only and so far no effort on network or service for OC - does this means that todays reality is we have multiple set of YANG (IETF + Vendors) for network topology and services and no uniformity there either ? or this time IETF is more advance and no issue there ?
\n(apologies for teenage text conversation style here ..)
(and a tutorial in how to use yang tools to work with run time schema mount would be nice too)
", "time": "2023-07-26T21:41:20Z"}, {"author": "Per Andersson", "text": "I missed the queue on the yang data provenance but would be interesting to have multiple signatures for the data with e.g. COSE_Sign instead of COSE_Sign1, for e.g. endorsements as Diego mentioned or for approvals of changes before application to a datastore as Diego mentioned.
", "time": "2023-07-26T21:43:53Z"}, {"author": "Per Andersson", "text": "it is interesting work
", "time": "2023-07-26T21:45:15Z"}, {"author": "Robert Wilton", "text": "Regarding Randy's work, I missed part of the presentation, but flicking through the slides I think that this looks like a relatively minor enhancement and I'm keen that we update docs/guidance to improve them based on operational experience, after all, we are in the OPS area :-)
", "time": "2023-07-26T21:49:31Z"}]