Hi Jeff,
On 11/21/2024 9:45 PM, Jeffrey Haas wrote:
Benoit,
On Nov 21, 2024, at 12:22 PM, Benoit Claise
<benoit.claise=40huawei....@dmarc.ietf.org> wrote:
Jeff, at the microphone during the OPSAWG meeting, mentioned the
issue of evolving/maintaining information models before going to a
data model. We are not too sure how publishing an information model
as RFC (as opposed to a WIKI or something similar) is actually
helping out.
To clarify what I intended to say, there's roughly two points.
I listened again to your intervention at the microphone and updated the
meeting minutes accordingly.
IM versioning and incentives to be generic:
At the end of the day, if you have the same information that will
manifest more than one way in an implementation, you have a versioning
problem.
If the informational model is the source of truth, each manifestation
of the changes from one revision of the IM to the next have clear
traceability in the implementations.
You can clearly do the same thing by picking one of your
implementations, like a data model, and using that as your source of
truth. However, since data models may manifest rules that are not
generic across manifestations, it becomes slightly more challenging to
make sure that an update to the DM source of truth doesn't result in a
second implementation with different rules from having issues. As a
more concrete example, if you do something in a YANG DM that you can't
model in a similarly useful enough way in IPFIX, it's a "problem".
Does a stable IM prohibit such issues? Not necessarily. It means
that you have an incentive in your IM work to ensure you can implement
it appropriately.
Traceability/Comparability:
Knowing that elements in implementations are the same or at least
comparable is useful. You can likely annotate > 1 implementation with
something that documents comparability, but then you have "source of
truth" conversations.
As an example, think of how many things leveraged ifIndex from the
IF-MIB. The MIB effectively became the source of truth for that semantic.
Do we truly need to have an RFC for the IM? No. My desire is that we
have practice that accommodates for the properties, above.
And concretely, what do you suggest? Except stabilizing the IM in github
or a WIKI, I don't see a good solution.
And if the (different) DMs change as a consequence of the IM change, we
are back to a versioning issue ... unless you do both IM & DM in github
or WIKI.
Regards, Benoit
-- Jeff
Regards, Joe and Benoit
On 11/13/2024 11:19 PM, Joe Clarke (jclarke) wrote:
As a contributor, I think a data model approach would be far more
useful. That said, I haven’t seen these proprietary implementations
based on your draft info model to understand how they deviate or
what data modeling approach they take. I still think that starting
with a YANG data model wouldn’t preclude future drafts standardizing
IPFIX-based approaches to packet discard reporting (just as we’ve
seen MIBs move to YANG).
As a chair, I think it would be/easier/from a process standpoint if
this was a data model. There just isn’t a lot (any?) info models in
the IETF developed in YANG. That said, things don’t always have to
be easy, and Med has already commented having a YANG info model is
not an insolvable problem.
I know Benoît is a bit busy, and I’m sure he’ll want to weigh in
next week.
Joe
*From:*Evans, John<jevan...@amazon.co.uk>
*Date:*Wednesday, November 13, 2024 at 06:53
*To:*opsawg@ietf.org<opsawg@ietf.org>,opsawg-cha...@ietf.org<opsawg-cha...@ietf.org>
*Cc:*Pylypenko, Oleksandr<o...@amazon.com>, Jeff
Haas<jh...@juniper.net>,mohamed.boucad...@orange.com<mohamed.boucad...@orange.com>,
Aviran Kadosh (akadosh)<akad...@cisco.com>
*Subject:*draft-ietf-opsawg-discardmodel
Hi All,
Following last week's discussion in Dublin regarding
draft-ietf-opsawg-discardmodel, we would appreciate feedback from
the working group and chairs on how to proceed.
To provide context, we initially defined an information model to
establish a common framework for discard reporting that could be
implemented across different data models, such as YANG and IPFIX.
We selected YANG to define the information model for three key
reasons: 1) the RFC8791 extensions enable the model to be decoupled
from specific implementations; 2) this approach allows for lossless
translation to a YANG-based data model; 3) the community has
extensive experience with YANG.
During the discussion, two main perspectives emerged: continue with
the current approach of defining an information model; redefine the
draft as a data model.
Given that the information model is already in YANG, creating data
models for interface, device, and control-plane would be
straightforward. This could also serve as a reference for a future
IPFIX-based discard reporting data model.
Hence, we would appreciate feedback on whether the best path forward
is to continue with the current information model approach or to
refocus on developing data models instead?
thanks
John
Amazon Data Services UK Limited. Registered in England and Wales
with registration number 09959151 with its registered office at 1
Principal Place, Worship Street, London, EC2A 2FA, United Kingdom.
_______________________________________________
OPSAWG mailing list --opsawg@ietf.org
To unsubscribe send an email toopsawg-le...@ietf.org
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
