I can see how that could potentially be useful, but can a client really be
written in a way that it is truly dependant on receiving those fields? I think
maybe clients have to be able to handle not getting state fields.
What you're describing could also potentially be done using "mandatory
“Must” statements on opstate usefully helps clients know when certain values
will always appear, enabling better optimization and usability.
E.g., for Syslog messages, there must always be a timestamp, severity, and a
message. It would be unhelpful for the server to not declare its intention
+1 on what Jurgen and Rob are pointing out here.
I'm not sure it makes a ton of sense to actually have a lot of "must"
statements in state models. We could consider discouraging them? (but we need
to continue *allowing* them).
Jason
> -Original Message-
> From: netmod On Behalf Of
Hi all,
The weekly YANG Versioning call on Nov 7th is cancelled. See you on the NETMOD
IETF118 session tomorrow.
Jason (he/him)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Hello NETMOD,
This is a new draft about filling the gap of Design time schema mount
identified in RFC8528.
This work was triggered by the difficulties we had to reuse existing modules in
the model for
https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/02/.
Best,
Jean
