Re: [Rats] draft-birkholz-rats-network-device-subscription-00

["Eric Voit (evoit)" <[e-mail]>]

Hi Dave,

> From: Dave Thaler,  August 12, 2020 5:43 PM
> 
> Eric Voit wrote:
> > > I asked in the meeting how a subscriber knows who to subscribe to,
> > > and I believe the answer was that CHARRA answers that.
> >
> > The answer I gave was that the problem was the same as Charra.  I
> > believe I also said the problem itself is generic to any YANG based
network
> element (I don't remember if that came out).
> > Generalizing more from there, Network Operators have diverse set
> > embedded management systems which include discovery, addressability,
> inventory, etc. of the network devices they manage.
> >
> > Moving back to YANG, these network management systems don't include all
> YANG info about a device.
> > So once you have found that a device exists, the device capabilities
> > it supports can be acquired via a variety of mechanisms like:
> > - NETCONF RFC 6241, Section 7 (and RFC6470)
> > - YANG Library RFC 8525
> >
> > > Well I looked in draft-
> > > ietf-rats-yang-tpm-charra-02 and it does not contain any mention of
> > > the subject.  I think one or the other of the two drafts needs to
> > > address this issue.
> >
> > This topic has not been within the scope of the many other YANG
drafts/RFC
> > which exist.   This is reasonable as there is a huge breadth of topology
> > discovery protocols available and in-use for routers and switches.
> 
> The topic being discussed here is about *timing* (and windows of how long
> things can be out of date for,
> etc.)   I expect that most other YANG drafts/RFCs do not cover that topic,
> whereas Figure 1 of
> draft-birkholz-rats-network-device-subscription specifically *does*.
That's
> what brings it in scope and why I believe it must be mentioned, even if
it's by
> reference to another document where the topic is covered.

There are a YANG nodes relevant to such timings.  For YANG datastores the
best place to start is: 
https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilitie
s/ 
and look through definitions like:
 
       +--ro subscription-capabilities
          +--ro max-nodes-per-update?               uint32
          +--ro periodic-notifications-supported?   notification-support
          +--ro (update-period)?
          |  +--:(minimum-update-period)
          |  |  +--ro minimum-update-period?        uint32
          |  +--:(supported-update-period)
          |     +--ro supported-update-period*      uint32
          +--ro on-change-supported?                notification-support
          |       {yp:on-change}?
          +--ro minimum-dampening-period?           uint32
          |       {yp:on-change}?
          +--ro supported-excluded-change-type*     union
                  {yp:on-change}?

However it is important to note that these capabilities above are for
reporting on changes YANG datastore nodes.  This is not the same thing as
the placement of YANG notifications into event streams.  Therefore for this
event subscription draft, look to the definition of the "marshalling-period"
leaf.   This leaf attempts to define the problem from the perspective of the
maximum amount of time from when an event extends a PCR to when the
notification leaves the Attester.

Eric


> Dave