Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Diego R. Lopez]

Hi,

I support the adoption, as a contributor.

While it is true previous attempts have ended in awkward approaches to the 
general problem of policy-based management, I believe there are new elements at 
hand in what relates to data flows (with proposals such as model-based 
telemetry and dynamic probes), decision mechanisms (with all the AI/ML variants 
you can think of) and action flows (with any SDN mechanism you prefer) to 
explore a model-based solution.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Mobile:  +34 682 051 091
--

On 7/12/2020, 17:27, Lou Berger  wrote:

To: NETMOD Group 
Cc: NetMod WG Chairs 
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

This email begins a 2-week adoption poll for:

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10

Please voice your support or technical objections on list before the end of 
December 21, any time zone.

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all 
indicated that no IPR exists.  The draft will not be formally adopted until 
both the IPR and WG polls are complete.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod




Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Randy Presuhn]

Hi -

On 2020-12-29 12:31 PM, Andy Bierman wrote:
...

I am not that interested in lessons from the past because it just sounds
like an old-timer's negativity.  But I am not interested in boiling the 
ocean either.


There is an invalid assumption with ECA that the current client 
development logic
(which is completely unbounded in its complexity, purpose, side effects, 
design,
or server interaction model) can somehow be replaced with a highly 
constrained

YANG model abstraction.

IMO a script-language-based solution is needed.
The ECA framework is good progress, but Programming in YANG is not.
However the IETF is not well-suited for standardizing programming languages
Open-Source is a much better solution path for this approach.

The solution also has to do a great job of gluing the model components to
the ECA logic and actions so there is maximum reusability and scalability.

Most importantly, it has to be easy for an operator to program and debug 
ECA.

There aren't going to be any magic tools to hide the complexity.


There's a tension between the convenience of scripting languages and the
desire to be able to reason about how policies interact, particularly if
one is approaching the problem from a perspective of goal-oriented
management.  To me that suggests that more structured (than mere
scripting) mechanisms are needed to to identify what aspects of what
resources are inputs or outputs in the operation of a given policy.
(That also has the nice side-effect of making policy formulations
vastly more re-usable.)

For the ISO/ITU work, my recollection is that the direction in which
it was headed was to use facilities of the management information
model and protocol (e.g. scoping, filtering, allomorphism, attribute
re-use, etc.) for the parameterization, but to use scripting for the
policy's "body".  I don't know if that's how things ultimately turned
out; I've been away from the work for decades.

If all the semantics, including specification of applicability,
are embodied in the script itself, one ends up with something
like the script MIB.  A potentially useful thing, but not particularly
helpful if one's goal is to be able to reason about policy interaction
or to formulate things in terms of goals.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Adrian Farrel]

Thanks Juergen and Randy,

There's plenty here to chew on. Happy New Year's Eve reading 😊

Cheers,
Adrian

-Original Message-
From: Juergen Schoenwaelder  
Sent: 29 December 2020 18:56
To: Adrian Farrel 
Cc: 'NETMOD Group' 
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Adrian,

some key issues when it comes to policy-based management systems:

 - What is an adequate abstraction level to express policies and intent?

   This question has no simple answer. I believe policies need to be
   readable and hence they need to be expressed at a high level of
   abstraction and in a suitable _language_. High-level policy
   expression may be compiled down into more verbose primitive
   representations that are closer to an execution abstraction. A
   common pitfall is to start somewhere in the middle of several
   layers of abstraction and then getting stuck with something awkward
   to put a clean higher layer abstract onto and to compile things
   down to _efficient_ instrumentations.

 - Where are policies executed?

   This can range from a logically centralized policy execution
   engine, which is part of what people call an orchestrator these
   days, to fully distributed policy execution models. In reality, you
   likely want to distribute functions dynamically but this makes
   solutions technically much more complicated. Given today's scalable
   computing and networking capabilities, logically centralized
   solutions are on the rise and have replaced the distributed
   approaches of the 90s.

 - When to detect and resolve policy conflicts?

   Detecting and resolving conflicts in larger collections of policies
   is non-trivial. This includes problems ranging from micro timescale
   atomicity issues to larger timescale stability issues (interacting
   policy control loops). If policy execution is distributed (or the
   event / information sources are distributed), this ultimately
   resolves to problems such as taking consistent snapshots or finding
   ways to work with inconsistent observations of a distributed system
   that are guaranteed to converge to stable states (self-stabilizing
   algorithms).

 - Who is interested in interoperable policy representations / languages?

   The IETF is about interoperability. What are the business models
   that push for interoperable policy based management standards? Who
   benefits from having an interoperable standard and how much effort
   are organizations willing to invest into engineering a reasonable
   solution addressing the other (non-trivial) questions raised above?
   Will they be implementing the solution in their products?

My position is that there are way too many difficult technical issues
to resolve for this work to be viable for the IETF. Instead, I suggest
that people go and work out solutions and once the silver bullet has
been found, bring it to the IETF. (Historically, all attempts to cast
policies into existing data models such as MIB modules or LDAP schema
led to something awkward and unusable. I believe YANG modules are no
different.)

/js

Some relevant RFCs (there may be more):

3052 Service Management Architectures Issues and Review. M. Eder, S. Nag.
 January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI:
 10.17487/RFC3052)

3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson,
 D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R.
 Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status:
 HISTORIC) (DOI: 10.17487/RFC3084)

3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie,
 M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F.
 Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC)
 (DOI: 10.17487/RFC3159)

3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan,
 K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC)
 (DOI: 10.17487/RFC3318)

3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed..
 January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status:
 PROPOSED STANDARD) (DOI: 10.17487/RFC3460)

3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y.
 Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format:
 TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644)

3198 Terminology for Policy-Based Management. A. Westerinen, J.
 Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A.
 Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format:
 TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198)

4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal.
 March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:
 10.17487/RFC4011)

4104 Policy Core Extension Lightweight Directory Access Protocol Schema
 (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.
 June 2005. (Format: TXT, HTML) (Updates RFC3703) (S

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Andy Bierman]

On Tue, Dec 29, 2020 at 8:26 AM Adrian Farrel  wrote:

> Hi Juergen,
>
> What you say about learning lessons from the past is wise and valuable.
>
> Sadly (well, it's a good thing, really) we have new people in the IETF and
> the memory of events over the last 20 years are not immediately accessible
> to them. Others, who are old and grey, have been around that long but were
> not necessarily involved in previous ECA discussions.
>
> Since "intent-based networking" is a big thing once again (see recent
> reports of acquisitions in this sector) the excitement about ECA may be
> forgiven, but it would help to ground the discussions if those who can
> remember previous efforts would share their experiences or at least some
> pointers.
>
>
I am not that interested in lessons from the past because it just sounds
like an old-timer's negativity.  But I am not interested in boiling the
ocean either.

There is an invalid assumption with ECA that the current client development
logic
(which is completely unbounded in its complexity, purpose, side effects,
design,
or server interaction model) can somehow be replaced with a highly
constrained
YANG model abstraction.

IMO a script-language-based solution is needed.
The ECA framework is good progress, but Programming in YANG is not.
However the IETF is not well-suited for standardizing programming languages
Open-Source is a much better solution path for this approach.

The solution also has to do a great job of gluing the model components to
the ECA logic and actions so there is maximum reusability and scalability.

Most importantly, it has to be easy for an operator to program and debug
ECA.
There aren't going to be any magic tools to hide the complexity.


Best,
> Adrian
>


Andy


>
> -Original Message-
> From: netmod  On Behalf Of Juergen Schoenwaelder
> Sent: 23 December 2020 18:09
> To: Andy Bierman 
> Cc: NetMod WG Chairs ; NETMOD Group
> 
> Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
>
> On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote:
> > On Wed, Dec 23, 2020 at 3:14 AM tom petch  wrote:
> >
> > > From: netmod  on behalf of Dhruv Dhody <
> > > dhruv.i...@gmail.com>
> > > Sent: 21 December 2020 17:12
> > >
> > > Hi Lou, WG,
> > >
> > > I find the motivation in the Introduction to be focused on ECA at the
> > > network devices (with all the talk about issues with Centralized
> > > network management).
> > >
> > > I see the value of ECA on the controller as well, say a customer
> > > network controller or an orchestrator can set the ECA on a central
> > > controller (reference ACTN in TEAS WG). Perhaps you would consider
> > > adding a sentence to describe this as well. The client-server
> > > terminology in the rest of the document covers it already.
> > >
> > > And I do see value in this and support adoption.
> > >
> > > 
> > > My take is that the I-D is unclear on what ECA is.
> > >
> > > ECA has been worked on in at least two IETF WG AFAICT.  It cropped up
> in
> > > I2RS but as I recall, it was along the lines of 'This is ECA'  'No It
> is
> > > not'  'Yes it is' which gave me the impression that ECA is not a
> > > well-defined, or well-understood, term.
> > >
> > > More recently, I2NSF have produced a YANG capability-data-model which
> is
> > > 55 pages of ECA.  Lacking a definition in this netmod I-D, I am unclear
> > > what the relationship is between the I2NSF I-D and the netmod I-D,
> whether
> > > or not they are using ECA in the same sense.
> > >
> > >
> > Hi Tom,
> >
> > It usually helps to agree on the problem-space before focusing on the
> > solution-space.
> > ECA seems like a methodology (ala MVC) more than anything else.
> > The problem statement seems to be that some client tasks need to be
> handled
> > on the
> > server using ECA methodology, instead of on the client.
> > Which tasks? Seems to be any task of arbitrary purpose or complexity.
> > And now the scope is supposed to include controllers (just another
> client),
> > so the problem-stmt
> > is even less clear.
> >
> > The traditional approach is to pick specific client tasks to move to the
> > server.
> > The example of detecting and reporting route-flaps has been used.
> > (No ECA example of this complexity has been provided yet).
> > The traditional approach would be to write a route-flap-detection YANG
> > module with some
> > configuration, monitoring data, and notification events.
> >
> > The generalized approach is likely to be extremely complex to standardize
> > and implement.
> >
>
> ECA work has a long 20+ year tradition in the IETF and several
> specifications have been published over the years by various working
> groups. As far as I can tell, none of them got traction in terms of
> signifiant deployment of interoperable implementations.
>
> I would have hoped that the next iteration of ECA work would have
> started with a deep reflection about why all the previous attempts
> failed to gain traction and some genuine insights ho

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Juergen Schoenwaelder]

Adrian,

some key issues when it comes to policy-based management systems:

 - What is an adequate abstraction level to express policies and intent?

   This question has no simple answer. I believe policies need to be
   readable and hence they need to be expressed at a high level of
   abstraction and in a suitable _language_. High-level policy
   expression may be compiled down into more verbose primitive
   representations that are closer to an execution abstraction. A
   common pitfall is to start somewhere in the middle of several
   layers of abstraction and then getting stuck with something awkward
   to put a clean higher layer abstract onto and to compile things
   down to _efficient_ instrumentations.

 - Where are policies executed?

   This can range from a logically centralized policy execution
   engine, which is part of what people call an orchestrator these
   days, to fully distributed policy execution models. In reality, you
   likely want to distribute functions dynamically but this makes
   solutions technically much more complicated. Given today's scalable
   computing and networking capabilities, logically centralized
   solutions are on the rise and have replaced the distributed
   approaches of the 90s.

 - When to detect and resolve policy conflicts?

   Detecting and resolving conflicts in larger collections of policies
   is non-trivial. This includes problems ranging from micro timescale
   atomicity issues to larger timescale stability issues (interacting
   policy control loops). If policy execution is distributed (or the
   event / information sources are distributed), this ultimately
   resolves to problems such as taking consistent snapshots or finding
   ways to work with inconsistent observations of a distributed system
   that are guaranteed to converge to stable states (self-stabilizing
   algorithms).

 - Who is interested in interoperable policy representations / languages?

   The IETF is about interoperability. What are the business models
   that push for interoperable policy based management standards? Who
   benefits from having an interoperable standard and how much effort
   are organizations willing to invest into engineering a reasonable
   solution addressing the other (non-trivial) questions raised above?
   Will they be implementing the solution in their products?

My position is that there are way too many difficult technical issues
to resolve for this work to be viable for the IETF. Instead, I suggest
that people go and work out solutions and once the silver bullet has
been found, bring it to the IETF. (Historically, all attempts to cast
policies into existing data models such as MIB modules or LDAP schema
led to something awkward and unusable. I believe YANG modules are no
different.)

/js

Some relevant RFCs (there may be more):

3052 Service Management Architectures Issues and Review. M. Eder, S. Nag.
 January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI:
 10.17487/RFC3052)

3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson,
 D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R.
 Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status:
 HISTORIC) (DOI: 10.17487/RFC3084)

3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie,
 M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F.
 Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC)
 (DOI: 10.17487/RFC3159)

3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan,
 K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC)
 (DOI: 10.17487/RFC3318)

3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed..
 January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status:
 PROPOSED STANDARD) (DOI: 10.17487/RFC3460)

3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y.
 Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format:
 TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644)

3198 Terminology for Policy-Based Management. A. Westerinen, J.
 Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A.
 Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format:
 TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198)

4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal.
 March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI:
 10.17487/RFC4011)

4104 Policy Core Extension Lightweight Directory Access Protocol Schema
 (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner.
 June 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED
 STANDARD) (DOI: 10.17487/RFC4104)

8328 Policy-Based Management Framework for the Simplified Use of Policy
 Abstractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis,
 M. Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML)
 (Status: INFORMATIONAL) (

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Randy Presuhn]

Hi -

On 2020-12-29 8:26 AM, Adrian Farrel wrote:
...

Since "intent-based networking" is a big thing once again (see recent
reports of acquisitions in this sector) the excitement about ECA may be
forgiven, but it would help to ground the discussions if those who can
remember previous efforts would share their experiences or at least some
pointers.

...

E.g. ISO/IEC 10164-19 (ITU-T X.749) immediately springs to mind.  A
cursory look at my files shows that it was under active development
in 1992, but I'm sure the underlying work was older.

A few memorable concepts from that work (from my perspective) were:

  - the need to be able to specify the set of things to
which a policy might apply both intensionally and
extensionally

  - distinguishing the formulation of a policy from the
formulation of its domain of applicability
(in the mathematical sense) and from its configured
realm of applicability (jurisdiction) and from the
set of instances to which it actually applies at a
given moment

  - recognition that the problem of finding policy conflicts
is ultimately equivalent to the halting problem if policies
can affect the managed resources, but that conflict detection
is still of great practical value

I'm sure there's lots more, I've had plenty of time to forget stuff.

Randy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

[Adrian Farrel]

Hi Juergen,

What you say about learning lessons from the past is wise and valuable.

Sadly (well, it's a good thing, really) we have new people in the IETF and
the memory of events over the last 20 years are not immediately accessible
to them. Others, who are old and grey, have been around that long but were
not necessarily involved in previous ECA discussions.

Since "intent-based networking" is a big thing once again (see recent
reports of acquisitions in this sector) the excitement about ECA may be
forgiven, but it would help to ground the discussions if those who can
remember previous efforts would share their experiences or at least some
pointers.

Best,
Adrian

-Original Message-
From: netmod  On Behalf Of Juergen Schoenwaelder
Sent: 23 December 2020 18:09
To: Andy Bierman 
Cc: NetMod WG Chairs ; NETMOD Group

Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote:
> On Wed, Dec 23, 2020 at 3:14 AM tom petch  wrote:
> 
> > From: netmod  on behalf of Dhruv Dhody <
> > dhruv.i...@gmail.com>
> > Sent: 21 December 2020 17:12
> >
> > Hi Lou, WG,
> >
> > I find the motivation in the Introduction to be focused on ECA at the
> > network devices (with all the talk about issues with Centralized
> > network management).
> >
> > I see the value of ECA on the controller as well, say a customer
> > network controller or an orchestrator can set the ECA on a central
> > controller (reference ACTN in TEAS WG). Perhaps you would consider
> > adding a sentence to describe this as well. The client-server
> > terminology in the rest of the document covers it already.
> >
> > And I do see value in this and support adoption.
> >
> > 
> > My take is that the I-D is unclear on what ECA is.
> >
> > ECA has been worked on in at least two IETF WG AFAICT.  It cropped up in
> > I2RS but as I recall, it was along the lines of 'This is ECA'  'No It is
> > not'  'Yes it is' which gave me the impression that ECA is not a
> > well-defined, or well-understood, term.
> >
> > More recently, I2NSF have produced a YANG capability-data-model which is
> > 55 pages of ECA.  Lacking a definition in this netmod I-D, I am unclear
> > what the relationship is between the I2NSF I-D and the netmod I-D,
whether
> > or not they are using ECA in the same sense.
> >
> >
> Hi Tom,
> 
> It usually helps to agree on the problem-space before focusing on the
> solution-space.
> ECA seems like a methodology (ala MVC) more than anything else.
> The problem statement seems to be that some client tasks need to be
handled
> on the
> server using ECA methodology, instead of on the client.
> Which tasks? Seems to be any task of arbitrary purpose or complexity.
> And now the scope is supposed to include controllers (just another
client),
> so the problem-stmt
> is even less clear.
> 
> The traditional approach is to pick specific client tasks to move to the
> server.
> The example of detecting and reporting route-flaps has been used.
> (No ECA example of this complexity has been provided yet).
> The traditional approach would be to write a route-flap-detection YANG
> module with some
> configuration, monitoring data, and notification events.
> 
> The generalized approach is likely to be extremely complex to standardize
> and implement.
>

ECA work has a long 20+ year tradition in the IETF and several
specifications have been published over the years by various working
groups. As far as I can tell, none of them got traction in terms of
signifiant deployment of interoperable implementations.

I would have hoped that the next iteration of ECA work would have
started with a deep reflection about why all the previous attempts
failed to gain traction and some genuine insights how to design things
differently in order to improve the likelihood to have impact.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-node-tags-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Self Describing Data Object Tags
Authors : Qin Wu
  Benoit Claise
  Liang Geng
  Zongpeng Du
  Mohamed Boucadair
Filename: draft-ietf-netmod-node-tags-00.txt
Pages   : 26
Date: 2020-12-28

Abstract:
   This document defines a method to tag data objects associated with
   operation and management data in YANG Modules.  This YANG data object
   tagging method can be used to classify data objects from different
   YANG modules and identify characteristics data.  It also can provide
   input, instruction, indication to selection filter and filter queries
   of operational state on a server during a "pub/sub" service for YANG
   datastore updates.  When the state of all subscriptions of a
   particular Subscriber to be fetched is huge, the amount of data to be
   streamed out to the destination can be greatly reduced and only
   targeted to the characteristics data.  These data object tags may be
   registered as well as assigned during the module definition; assigned
   by implementations; or dynamically defined and set by users.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-node-tags-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod