Subject: Re: [netconf] Overview of the various "capabilities" drafts

From: "maqiufang (A)" <[email-masked]>
Date: Tue, 17 Aug 2021 04:01:38 +0000

Hi, Kent, all
As a coauthor of data-export-capabilities and adaptive-subscription draft:

1. I would like to clarify that adaptive-subscription augments the "update-trigger" choice defined in "ietf-yang-push" module(RFC 8641). Although it also provides an optimum data collection mechanism, this draft doesn't advocate the capabilities exposure, but provides another way of subscription trigger in addition to periodic and on-change subscription.
It allows a publisher to switch to different period intervals automatically according to the xpath evaluation results.
The adaptive-subscription related capabilities is discovered through adaptive-interval-support parameter defined in draft-tao-netconf-data-export-capabilities, but it does not need to depend on the data export capability if the client has heuristic knowledge about the server supports multiple update interval.
So I think maybe adaptive-subscription should be excluded from our "capabilities discussion".

2. Draft-claise-netconf-metadata-for-collection augments "system-capabilities"  data model and provides per-node metadata information for optimum data collection. I think it is designed for service assurance use case defined in I-D.ietf-opsawg-service-assurance-yang but could also be applied to other telemetry use cases;
And draft-tao-netconf-data-export-capabilities augments "system-capabilities" data model to provide transport specific system-level capabilities and some per-node support capabilities(such as message-bundling-support, adaptive-interval-support, etc). It is designed for YANG push use case, adaptive subscription use case, UDP-notif use case and message bundling use case.

3. Regarding compliment and/or overlap of data-export-capabilities and metadata-for-collection, I think it would be good to combine these two drafts and we can also review if there are any other capabilities needed to support the closed-loop automation beyond ones already defined in this two drafts.
after thinking about it, I think there are 3 combination options:
Option A: Merge data export capability draft and meta data collection draft into one but still define two different models, one for data export, one for metadata collection
                    Pro: Scope for "system-capability" extension is clear
Option B: Merge data export capability draft and meta data collection draft into one, consolidate data export capability model into meta data collection model
                   Con: Scope for "system-capability" extension is not clear since different system capabilities are mixed together.
Option C: Keep two drafts separate, move some of metadata related per-node parameters(message-bundling-support, adaptive-interval-support, etc) from data export draft to meta data collection draft, and keep the transport specific parameters(transport-protocol, encoding-format, etc) in the data-export-capabilities draft.
                  Pro: Scope for both per-node metadata capability and transport specific system-level capability are clear

Any thoughts?

Best Regards,
Qiufang Ma

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Tuesday, August 10, 2021 7:30 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Overview of the various "capabilities" drafts

Draft-authors in the “To” line,

During the 111 session I made the statement that all these drafts are augmenting the new “system capabilities” data tree and wondered to what extent these efforts compliment and/or overlap each other.  Could you please discuss this?

Kent (no hat)

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Aug 2021 11:36:47 +0000

One quick response, would it be okay for me to CC the list on a bigger response later?   - as this is exactly the kind of conversation I was hoping to happen there…

K. 

Sent from my iPhone

> On Aug 17, 2021, at 12:07 AM, maqiufang (A) <[email-masked]> wrote:
> 
> Hi, Kent, all

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Aug 2021 11:41:29 +0000

Ooops, it appears that I need to drink coffee before using email first thing in the morning  ;)

> On Aug 17, 2021, at 7:43 AM, Kent Watsen <[email-masked]> wrote:
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Aug 2021 17:54:10 +0000

Hi Qiufang,

> So I think maybe adaptive-subscription should be excluded from our "capabilities discussion".

Okay.  And thank-you for the great explanation.

> And draft-tao-netconf-data-export-capabilities augments "system-capabilities" data model to provide transport specific system-level capabilities and some per-node support capabilities(such as messa…

So maybe some overlap…

>                  Pro: Scope for both per-node metadata capability and transport specific system-level capability are clear

Also:

D. Merge data export capability draft and meta data collection draft into one and move some of metadata related per-node parameters(message-bundling-support, adaptive-interval-support, etc) from data export model to meta data collection model, and keep the transport specific parameters(transport-protocol, encoding-format, etc) in the data-export-capabilities model.

‘D’ is a combination of ‘A’ and ‘C’…does it mean we'd get the best (the Pro’s) from both?

I hope that the authors of the “metadata-for-collection" draft will chime in.

> Qiufang Ma

Thanks,
Kent