:clap:
", "time": "2026-03-18T01:05:36.000Z"}, {"author": "Robert Wilton", "text": "Scott and I will try and sync up this week or next week if we can't get times to match.
", "time": "2026-03-18T01:09:19.000Z"}, {"author": "Lou Berger", "text": "Thanks!
", "time": "2026-03-18T01:09:28.000Z"}, {"author": "Scott Mansfield", "text": "Sounds good to me!
", "time": "2026-03-18T01:09:52.000Z"}, {"author": "Robert Wilton", "text": "I've just lost audio!
", "time": "2026-03-18T01:10:51.000Z"}, {"author": "Jean Mahoney", "text": "I still have audio
", "time": "2026-03-18T01:11:25.000Z"}, {"author": "Christian Hopps", "text": "still have audio here
", "time": "2026-03-18T01:11:48.000Z"}, {"author": "James Cumming", "text": "Anyone else? Or is it just Rob?
", "time": "2026-03-18T01:11:54.000Z"}, {"author": "Per Andersson", "text": "It drops intermittently for me
", "time": "2026-03-18T01:12:08.000Z"}, {"author": "Jean Mahoney", "text": "@meetecho - some audio issues here
", "time": "2026-03-18T01:12:21.000Z"}, {"author": "Robert Wilton", "text": "Back (for the moment) ...
", "time": "2026-03-18T01:12:57.000Z"}, {"author": "Lorenzo Miniero", "text": "If audio is lost and doesn't come back on its own (we have automated reconnect mechanisms for streams) you can try refreshing/rejoining
", "time": "2026-03-18T01:13:15.000Z"}, {"author": "Reshad Rahman", "text": "Rob, get some wine. It worked for me last time
", "time": "2026-03-18T01:13:16.000Z"}, {"author": "Lou Berger", "text": "we have some time
", "time": "2026-03-18T01:19:02.000Z"}, {"author": "Reshad Rahman", "text": "For issue 4 , keeping examples is fine as long as it's clear that semver is the normative reference
", "time": "2026-03-18T01:21:03.000Z"}, {"author": "Amanda Baber", "text": "We can do both
", "time": "2026-03-18T01:21:54.000Z"}, {"author": "Joe Clarke", "text": "@Reshad and moreover, the tooling examples will use YANG Semver, using the rules.
", "time": "2026-03-18T01:23:33.000Z"}, {"author": "Reshad Rahman", "text": "Sure Rob
", "time": "2026-03-18T01:31:58.000Z"}, {"author": "Vojt\u011bch Vil\u00edmek", "text": "What is the state of the tooling? Are the implementations ready to work with the semver?
", "time": "2026-03-18T01:33:20.000Z"}, {"author": "Mahesh Jethanandani", "text": "I was going to ask the same question as @Vojtech.
", "time": "2026-03-18T01:33:54.000Z"}, {"author": "Reshad Rahman", "text": ":clap: @Joe
", "time": "2026-03-18T01:35:03.000Z"}, {"author": "Mahesh Jethanandani", "text": "Thanks Joe.
", "time": "2026-03-18T01:35:19.000Z"}, {"author": "Vojt\u011bch Vil\u00edmek", "text": "Nice!
", "time": "2026-03-18T01:35:22.000Z"}, {"author": "Joe Clarke", "text": "Have a look at https://github.com/xorrkaz/pyang/
", "time": "2026-03-18T01:35:42.000Z"}, {"author": "Per Andersson", "text": "@Joe Nice work!
", "time": "2026-03-18T01:36:07.000Z"}, {"author": "Scott Mansfield", "text": "Thanks. I need to get IEEE 802 and ITU-T to move to SEMVER now.
", "time": "2026-03-18T01:36:17.000Z"}, {"author": "Joe Clarke", "text": "Here's an example:
\npyang --check-update-semver --check-update-from iana-ssh-mac-algs@2024-10-16.yang iana-ssh-mac-algs@2026-03-06.yang
\nSUGGESTED-NEXT-YANG-SEMVER: 2.0.0
\nNBC-CHANGE(S):
\niana-ssh-mac-algs@2026-03-06.yang:40: error: rev:non-backwards-compatible is required for this revision
\niana-ssh-mac-algs@2026-03-06.yang:57: error: new status obsolete is not valid since the old status was (implicit) current
@scott - that would be awesome!
", "time": "2026-03-18T01:36:43.000Z"}, {"author": "Joe Clarke", "text": "And:
\npyang --check-update-semver --check-update-from ietf-ospf-sr-mpls@2025-12-09.yang ietf-ospf-sr-mpls@2026-01-14.yang
\nSUGGESTED-NEXT-YANG-SEMVER: 1.0.1
\nPOSSIBLE-NBC-CHANGE(S):
\nConsult document authors and YANG Doctors.
\nietf-ospf-sr-mpls@2026-01-14.yang:778: warning: the description change may have changed the semantics of the node
What was the conclusion on the discussion around the use of _COMPAT flag as it relates to IETF? Are we adding any text around it?
", "time": "2026-03-18T01:37:17.000Z"}, {"author": "Joe Clarke", "text": "Yes, I think I did clarify some of the text.
", "time": "2026-03-18T01:37:46.000Z"}, {"author": "Joe Clarke", "text": "I'm in an odd state here in SZ, but when I get home I can do an update.
", "time": "2026-03-18T01:38:07.000Z"}, {"author": "Mahesh Jethanandani", "text": ":+1:
", "time": "2026-03-18T01:38:13.000Z"}, {"author": "Joe Clarke", "text": "Mahesh, I did look back in my email, and I could use a follow up to the last YANG Semver response. But again, this could wait until next week.
", "time": "2026-03-18T01:44:34.000Z"}, {"author": "Robert Wilton", "text": "@Mahesh, the iana-yang-guidelines draft states that _COMPAT isn't needed or used for IETF/IANA YANG modules.
", "time": "2026-03-18T01:49:46.000Z"}, {"author": "Kent Watsen", "text": "@david
\nfor the prior instance when IANA published a module due to an Errata, search for the string \u201cerrata\u201d on this page:
\nhttps://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
\nDiffing between @2022-06-06 and @ @2019-09-11 gives this:
\n$ diff ietf-alarms@2019-09-11.yang ietf-alarms@2022-06-06.yang
\n122a123,129
\n\nrevision 2022-06-06 {
\n
\n description
\n \"Updated text per RFC Errata 6866.\";
\n reference
\n \"RFC Errata 6866\";
\n }768c775
\n
\n< \"Matches the 'last-status-change' leaf in the alarm.\";
\n\n\n\n"Matches the 'last-changed' leaf in the alarm.";\n
Note that both a new \"revision\" statement was added and the new file posted with the new/correct filename.
", "time": "2026-03-18T01:51:51.000Z"}, {"author": "Per Andersson", "text": "@meetecho please turn the camera to the speaker if possible
", "time": "2026-03-18T01:57:27.000Z"}, {"author": "Per Andersson", "text": "thanks!
", "time": "2026-03-18T01:57:48.000Z"}, {"author": "Robert Wilton", "text": "Really we need one type rather than two here.
", "time": "2026-03-18T02:02:58.000Z"}, {"author": "Robert Wilton", "text": "Note Linux uses the IETF format, which matches what was in the MIBs. Windows uses the IEEE format (which obviously owns MAC addresses).
", "time": "2026-03-18T02:04:30.000Z"}, {"author": "Vojt\u011bch Vil\u00edmek", "text": "Just a note here, it seems that YangModels/yang IETF YANG module extraction CI is broken
", "time": "2026-03-18T02:04:46.000Z"}, {"author": "Joe Clarke", "text": "Yeah, yeah I know. It's on my todo list.
", "time": "2026-03-18T02:06:47.000Z"}, {"author": "James Cumming", "text": "Robert Wilton said:
\n\n\nNote Linux uses the IETF format, which matches what was in the MIBs. Windows uses the IEEE format (which obviously owns MAC addresses).
\n
It's almost a units statement (but not quite)
+1 to Qiufang's comment. Running is implicitly valid if Intended is valid (where the actual validation is done).
", "time": "2026-03-18T02:17:34.000Z"}, {"author": "Robert Wilton", "text": "I wonder if this is the same as RFC 8342 (NMDA) when talking about operational:
\nI.e., Only semantic constraints MAY be violated. These are the YANG
\n \"when\", \"must\", \"mandatory\", \"unique\", \"min-elements\", and
\n \"max-elements\" statements; and the uniqueness of key values.
Syntactic constraints MUST NOT be violated, including hierarchical
\n organization, identifiers, and type-based constraints. If a node in
\n <operational> does not meet the syntactic constraints, then it
\n MUST NOT be returned, and some other mechanism should be used to flag
\n the error.
anydata sounds right to me. The lack of validation, is potentially a good YANG Next issue.
", "time": "2026-03-18T02:23:56.000Z"}, {"author": "Reshad Rahman", "text": "\n\nReally we need one type rather than two here.
\n
Hasn't that ship sailed?
", "time": "2026-03-18T02:24:00.000Z"}, {"author": "Robert Wilton", "text": "Yes, that ship has sailed. Perhaps the pragmatic answer is that the description of the types should both say that they are equivalent to the other and should be normalised by the server for comparison purposes.
", "time": "2026-03-18T02:25:33.000Z"}, {"author": "Reshad Rahman", "text": "Makes sense
", "time": "2026-03-18T02:26:08.000Z"}, {"author": "Alex Huang Feng", "text": "Would draft-ietf-netmod-yang-anydata-validation-00 help?
", "time": "2026-03-18T02:26:42.000Z"}, {"author": "Robert Wilton", "text": "I'm virtually nodding my head :-)
", "time": "2026-03-18T02:30:58.000Z"}, {"author": "Robert Wilton", "text": "Note there is nothing stopping the server working out the right schema to validate the anydata, which it would do in other cases anyway.
", "time": "2026-03-18T02:32:35.000Z"}, {"author": "Christian Hopps", "text": "@meetecho are you able to measure volume diff between local and remote audio? For me remote audio is blasting loud if I adjust to be able to hear local audio (i.e., they seem very different)
", "time": "2026-03-18T02:35:52.000Z"}, {"author": "Lorenzo Miniero", "text": "Unfortunately remote volume is unpredictable. When we do our tests, also in the venue, this is not usually an issue, but some people come louder thatn others. We have some form of audio compression in the plans for the future, to try and \"normalize\" this a bit
", "time": "2026-03-18T02:37:47.000Z"}, {"author": "James Cumming", "text": "Is remote still working for people? I'm getting unstable connection errors
", "time": "2026-03-18T02:39:02.000Z"}, {"author": "Robert Wilton", "text": "Remote is working fine for me.
", "time": "2026-03-18T02:39:13.000Z"}, {"author": "James Cumming", "text": "Thanks Rob
", "time": "2026-03-18T02:39:20.000Z"}, {"author": "Per Andersson", "text": "I have nominal audio. hearability 9/9
", "time": "2026-03-18T02:39:50.000Z"}, {"author": "Robert Wilton", "text": "I seem to have lost chat ability.
", "time": "2026-03-18T02:46:44.000Z"}, {"author": "James Cumming", "text": "Voice chat or type chat?
\nI see your typed message
I wanted to say thanks to Kent for doing this XML work. It isn't that exciting but it is really useful/important.
", "time": "2026-03-18T02:47:29.000Z"}, {"author": "James Cumming", "text": "I can add you comment to the minutes Rob
", "time": "2026-03-18T02:47:46.000Z"}, {"author": "Robert Wilton", "text": "Thanks! It swallowed my previous effort at that comment!
", "time": "2026-03-18T02:48:03.000Z"}, {"author": "Lou Berger", "text": "@rob \"The lack of validation, is potentially a good YANG Next issue.\"
\nWhy wait?
@Lou, I think it depends on what the solution looks like - i.e., whether it ends up affecting the core of YANG.
", "time": "2026-03-18T02:51:11.000Z"}, {"author": "James Cumming", "text": "Lou Berger said:
\n\n\n@rob \"The lack of validation, is potentially a good YANG Next issue.\"
\n
\nWhy wait?
Actually I think waiting on this solution whilst considering moving forward with templates might be an issue
", "time": "2026-03-18T02:51:27.000Z"}, {"author": "Qiufang Ma", "text": "+1 to thanks for this effort.
", "time": "2026-03-18T02:51:30.000Z"}, {"author": "Lou Berger", "text": "@james +1
", "time": "2026-03-18T02:51:56.000Z"}, {"author": "Robert Wilton", "text": "But I think that YANG 2.0 should support critical extensions, and that we should try and not make the core YANG too big, and use extensions/extra drafts where necessary.
", "time": "2026-03-18T02:52:22.000Z"}, {"author": "Robert Wilton", "text": "I also think that writing up more complex things in separate drafts makes sense, i.e., wait for them to become stable before merging them into a future version of YANG.
", "time": "2026-03-18T02:53:03.000Z"}, {"author": "Robert Wilton", "text": "So, in conclusion, I'm not opposed to trying to fix anydata validation now, but need to understand what the full solution looks like. IIRC, I thought that the solution in the current draft might be too limited.
", "time": "2026-03-18T02:53:57.000Z"}, {"author": "Lou Berger", "text": "@rob then why not start brining in new features 1.1 extensions, e.g. anydata validation
", "time": "2026-03-18T02:54:10.000Z"}, {"author": "Robert Wilton", "text": "I previously sent comments to the list.
", "time": "2026-03-18T02:54:11.000Z"}, {"author": "Robert Wilton", "text": "@Lou, we can, I think.
", "time": "2026-03-18T02:54:28.000Z"}, {"author": "Qiufang Ma", "text": "Agree with Rob, the solution looks rather rough in the current draft.
", "time": "2026-03-18T02:54:46.000Z"}, {"author": "Lou Berger", "text": "I do think we should generally consider how many of the 2.0 issues can/should be done as 1.1 extensions (I think I've said this before too)
", "time": "2026-03-18T02:55:22.000Z"}, {"author": "Robert Wilton", "text": "But if the solution requires changes to YANG then we need to be more careful.
", "time": "2026-03-18T02:55:26.000Z"}, {"author": "James Cumming", "text": "IMHO the anydata validation change should change the underlying typedef of anydata to allow an optional validatable selection is a fairly discrete stand-alone change
", "time": "2026-03-18T02:55:35.000Z"}, {"author": "Robert Wilton", "text": "I think (as per my document that I sent to the list) that we need to agree which issues will get merged in.
", "time": "2026-03-18T03:00:17.000Z"}, {"author": "Robert Wilton", "text": "I generally, I think that this process sounds good.
", "time": "2026-03-18T03:01:08.000Z"}, {"author": "Reshad Rahman", "text": "\n\nthen why not start brining in new features 1.1 extensions, e.g. anydata validation
\n
I support adding some extensions, e.g. semver :-)
", "time": "2026-03-18T03:01:20.000Z"}, {"author": "Joe Clarke", "text": "+1 Reshad
", "time": "2026-03-18T03:01:51.000Z"}, {"author": "Joe Clarke", "text": ":grinning:
", "time": "2026-03-18T03:02:13.000Z"}, {"author": "Robert Wilton", "text": "+1 Joe :-)
", "time": "2026-03-18T03:02:28.000Z"}, {"author": "Per Andersson", "text": "you will need a github account to comment on a PR on github
", "time": "2026-03-18T03:03:25.000Z"}, {"author": "Vojt\u011bch Vil\u00edmek", "text": "And also to create a PR, or?
", "time": "2026-03-18T03:03:58.000Z"}, {"author": "Per Andersson", "text": "indeed
", "time": "2026-03-18T03:04:04.000Z"}, {"author": "Joe Clarke", "text": "Yes. PR and issue, not just to read.
", "time": "2026-03-18T03:04:10.000Z"}, {"author": "Reshad Rahman", "text": ":wave:
", "time": "2026-03-18T03:06:30.000Z"}, {"author": "Per Andersson", "text": "bye
", "time": "2026-03-18T03:06:45.000Z"}]