https://datatracker.ietf.org/meeting/126/materials/agenda-126-netconf
Session:
Tuesday, July 21, 2026
Session III (14:00 - 16:00)
Room Name: Park Suite 8
WG Chairs:
Kent Watsen (kent plus ietf at watsen dot net)
Per Andersson (per dot ietf at ionio dot se)
WG Secretary:
Fan Zhang (fanzhang dot ietf at gmail dot com)
Available Now:
ICS: https://datatracker.ietf.org/meeting/126/sessions/netconf.ics
Available During Session: (pick one)
Onsite Tool: https://meetings.conf.meetecho.com/onsite126/?group=netconf
Remote Tool: https://meetings.conf.meetecho.com/ietf126/?group=netconf
Audio Only: https://mp3.conf.meetecho.com/ietf126/netconf/1.m3u
Chat Only: https://zulip.ietf.org/#narrow/stream/netconf
Available During and After Session:
Notes: https://notes.ietf.org/notes-ietf-126-netconf
Slides: https://datatracker.ietf.org/meeting/126/session/netconf
Drafts (PDF):
https://datatracker.ietf.org/meeting/126/agenda/netconf-drafts.pdf
Drafts (TGZ):
https://datatracker.ietf.org/meeting/126/agenda/netconf-drafts.tgz
Available After Session:
Recording: https://www.meetecho.com/ietf126/recordings#NETCONF
YouTube: https://www.youtube.com/watch?v=vLHOiRLrxlM
Attendees:
https://datatracker.ietf.org/meeting/126/session/35129/attendance
Automatic Minutes: https://ietfminutes.org/minutes/ietf126/netconf.html
Discussions about the agenda [14:07 - 14:08]
Robert Wilton: A comment on the UDP-Notif draft. The spec is past WGLC,
but we've just implemented this (the DTLS part) but don't conform to the
spec related to an extra length header, but think that it may be that
the spec is wrong and should be updated. The authors are aware.
Pierre Francois (chat): @Robert ok no problem, we'll change asap.
Discussions about "yang-library-augmentedby" [14:10 - 14:12]
Thomas Graf: My understanding of deprecated is that it should not be
augmented. However, I would have expected in RFC 9907 that there's some
guidance on whether deprecated it can be augmented or should be
augmented in which cases, but I couldn't find any. So I think that would
be worth clarifying also for the future.
Robert Wilton: I think augmenting into a deprecated space is fine. I
think this is a bug in the interpretation of deprecated in YANG. I know
there's sort of been two different views as to whether it hierarchically
bubbles down or not. Hopefully in YANG 2 will fix this and do the
sensible thing, because it feels to me like the original definition was
nicer, that it deprecates everything underneath. If this makes people
happy, I've got no objections to this either.
Per Andersson: So it's actually YANG-next Issue 27, which asks to
clarify the inheritance of status.
Mahesh Jethanandani: Since the document is passed to IANA approval, do
you want me to recall it from the RFC editor queue to make the change.
Per Andersson: As a contributor, I don't mind either way raising this
complaint. Instead of recalling the document to the WG, make the changes
unrolling the grouping which doesn't change the semantics of the YANG
module; OR remove the augment of modules-state which was suggested on
list. I suggest to do whatever is fastest to publish the document.
Mahesh Jethanandani: If it's not semantically changing the model in any
way, maybe then we can handle that at the RFC editor level where we will
recommend to them the changes they need to make to the model.
Mahesh Jethanandani (as presenter): We believe we have addressed most of
the issues and need a quick WGLC to make sure we have addressed all the
issues.
Kent Watsen: There is a review from Alex that was sent to the list. It
can be considered as a WGLC comment.
Qiufang Ma: As the shepherd of this draft, I will also review the update
and update the write-up accordingly before sending to IESG.
Chair Action:
Comment 1: Relationship to the shared candidate (Quifang)
Qiufang Ma: Are you referring to that for the client that does not
support the private candidate, the server will still provide the shared
candidate for the client to use it?
James Cumming: A lot of the RPCs today are protected by the candidate
feature flag. In order to get some of those RPCs, you need to have
candidate turned on. We can't add another feature flag to the same
statement in an "or" situation, so it ends up being an "and" in 1.0
only. That was fixed in 1.1. We could rewrite the entire ietf-netconf to
1.1 and add those things, but we were trying to not be impacted to the
main NETCONF spec, particularly as we know there's another NETCONF
coming along at some point.
Robert Wilton: I think this is pragmatically the right path for now. And
then when YANG 2 comes along and NETCONF next comes along, that'd be a
nice time maybe to get rid of shared candidates and to decouple these or
something. But for the moment, I think this is sort of almost the only
thing you can do that works.
James Cumming: It's the solution right now with the least impact to the
rest of the infrastructure.
Qiufang Ma: When you say about the limitation on if-feature, would the
if-feature candidate also apply to the private candidate data store?
James Cumming: At the request of the working group, there was no private
candidate data store. That was removed from the draft some while ago in
replacement for the candidate data store being reused with the
capability. That change was requested by the working group a few
releases back now. The very first draft had a private candidate separate
data store, but we migrated away following the working group's
direction. The candidate data store is now the only reference data
store, and whether a session is in private candidate mode or shared
candidate mode is defined by the capability you negotiate or send.
Qiufang Ma: I think that makes more sense.
Kent Watsen: I heard no objections.
Comment 2: Checkpoint/recovery model (Qin from OPSDIR on -06
version)
Qin Wu: Originally, I thought adding update timestamps introduced some
kind of state mechanism. I agree this adds complexity. You can support
stateless operation, so I agree with this approach.
Comment 3: Metadata for in-conflict marker (Qin from OPSDIR on -06
version)
Qin Wu: I think that both comments actually really motivated, provide a
better observability. I have no strong opinion about this. I think you
consider this out of scope should make it explicit in the documents.
Robert Wilton: Is there a middle ground alternative here of actually
specifying the metadata annotation but not requiring it to be used? One
thing I'm concerned about is the failure path. One of my comments is
that it is not very clear how errors are returned in the failure path.
It feels to me that the specification is a bit underspecified in places,
and you're not going to get the interoperability you need.
James Cumming: We will consider that.
Comment 4: Conflict resolution (Rob Wilton)
Robert Wilton: Two separate thoughts. If you've got auto <update>,
possibly you have to mandate that the resolution mode is one of the
other two. But if you've got auto <update>, the <update> that you do
at this point has to be a no-op because you've already done the update
whenever the last change was made, so there's no update that'll ever
occur here. It might make sense that you don't ever have the explicit
failure mode that you force this auto <update>, you're forcing it to
resolve one way or the other. But for this one, it's specific for
<commit>. I think it's always a no-op, and the draft could be clearer
on that in the auto <update> mode.
James Cumming: We can make that clearer.
Comment 5: <delete-config> operation (Michal Vasko)
Michal Vasko is absent.
James Cumming: We will deal with this one on the list.
-
Robert Wilton: Will have a chat about the new review during this week.
James Cumming: Question to chairs, any other blocking items?
Per Andersson: If you address the comment from Michal and the new
comments from Rob, you are good to go.
Kent Watsen: Please take a summary of the chat to the list.
Robert Wilton: You've had one review on the list and one private review
(from Robert Varga). I'm wondering whether it's worth trying to get some
more reviews because otherwise it feels a bit weak.
Per Andersson: I agree. Please do another review. The WG LC is still
open.
Mahesh Jethanandani: For the the private review, did it reveal anything
that the authors agreed with?
Per Andersson: I didn't disclose it not because it's sensitive, but
because it was forwarded from a review of HTTPS-notif, making it
difficult to parse what applied to QUIC-client-server. It suggested not
having the enumerations from the QUIC transport but put whatever bytes
you want there. I don't think that was what the WG decided on.
Kent Watsen: We did ask him to repost his review on the list, but he
didn't.
Mahesh Jethanandani: Ok. Without exposing the review, if the comments
are not something the WG agrees with, we can move forward.
Per Andersson: I'll reach out to Robert Varga again.
Marc Blanchet: I did the review. It would be good to have QUIC experts
to review since we're touching the state of QUIC stack.
Kent Watsen: Do an early TSVART review.
Mahesh Jethanandani (chat): An early TSVART review would be great.
Per Andersson: And a YANGDOCTORS review maybe?
CHAIR ACTIONS:
Kent Watsen: As a contributor, just to rephrase, when NETCONF was first
published, there was the NETCONF specification, the SSH binding, and the
TLS binding. RFC 8071 (Call Home) came later. The idea is to first
define the QUIC binding specification, and then perhaps have an RFC
8071bis or a separate document explaining how Call Home can be
implemented over QUIC. Correct?
Weiqiang Cheng: Yes.
Kent Watsen: Secondly, I've been talking to QUIC folks, and to be
honest, there is no light at the end of the tunnel for reverse QUIC.
It's probably years away, so if we hold this document waiting for that,
we could be waiting for a long time.
Mahesh Jethanandani: If there is no reverse QUIC option, then we don't
have Option 2 and are only left with Option 1. The advantage is that if
reverse QUIC is ever implemented, this work can be picked up then.
Robert Wilton: Based on Kent's comments and your comments that we can't
deploy this now, I think Option 1 seems the obvious choice. So I support
it.
Per Andersson: As a co-author, there are no well-defined options to do
the connection in one way and then do the reverse authentication. There
are several options and guesses as to whether they can work, or you can
do the authentication in the NETCONF layer. It's software, so it's
possible to make it work, but I'm also starting to lean towards doing a
proper solution later when it's available. So defer the Call Home work
and publish this as it's useful now.
Mahesh Jethanandani: Let us make a decision either ways and move
forward. This document has been stuck in this state for more than two
IETF meetings.
Kent Watsen: As a individual contributor, the NETCONF client-server and
RESTCONF client-server drafts, currently with the RFC Editor, both
define mechanisms for configuring Call Home. However, I don't think they
apply to NETCONF or RESTCONF over QUIC. Although the YANG models suggest
that Call Home over QUIC can be configured, that's probably not true.
Some sort of errata may be needed later. It may be something we could
look to do in those documents. For instance, we could specify the
NETCONF version or the transport being used, and only allow
configuration of the Call Home mechanism if it's not using a QUIC
transport.
Robert Wilton: My suggestion is don't touch them. I would just ignore it
for the moment, pretend that you didn't know about it in a sense, and
then spend the time to come up with a proper solution. I wouldn't try to
preempt it.
Kent Watsen: There is light at the end of tunnel for doing RESTCONF Call
Home over QUIC. There is a PTTH BOF earlier yesterday. PTTH is reverse
of HTTP, and you can see where that goes.
Chair Action:
Discussions about WGLC & cursor embedding page sizes
Kent Watsen: Per and I, both authors, have to recuse ourselves. So
Mahesh has to make the judgment call of whether a secondary WGLC has to
occur. Be aware that there's some substantive changes that have been
made, and you may want to have another round of WGLC.
As a contributor, with cursors, typically, you have a where, a sort, and
the direactionality of the sort, and get back a cursor. When you create
that cursor, you might also pass the page size. Then, when you say next,
you automatically get the next of that size. You don't actually pass the
limit parameter again and again. That's one possibility, the never
option. But in other implementations, the cursor doesn't embed or encode
the page size, thus enabling dynamic changing of the page size. We're
unclear what is the best. I asked Gemini AI, and it seems to suggest
that the dynamic paging is more common. But then Per did some follow-up
investigation, and it became unclear.
Per Andersson: I checked the database documentation for SQL. They seem
to suport both. But it's software, so you can do whatever you want in
the database layer. My personal experience is that I've always been able
to put the limit in subsequent requests. Does anyone have a strong
opinion on this?
Robert Wilton: No strong opinion. I think the whole solution has a fair
amount of complexity in it. So I would urge going towards simpler bits,
choosing one rther than having both options.
Per Andersson: Cursor-based pagination for SCIM (RFC 9865) includes the
limit that you have to send it and it has to match the initial query. So
if you initial query says that count is 10, then you have to always
produce it in every query that you make and it has to match 10.
Robert Wilton: So if you don't include it, does that mean that you have
to maintain some context? Whereas you do include it, you can be context
free?
Per Andersson: Yes.
Robert Wilton: Then in my mind, having the context free one gives you
more flexibility as a small amount of pain for the client to include the
extra fields. You don't have to check it's the same as the original one.
Per Andersson: It's a different use case. With offset and limit, you
have an easy way to paginate and support random access. Cursor-based
pagination is instead a sequential loading of paging.
Robert Wilton: To Mahesh, if another WGLC comes up, I would review it
again with fresh eyes.
Per Andersson: So your suggestion was to not include the limit in the
cursor because that will put context on the server, but instead keep it
for the client. Who should keep the state, client or server?
Robert Wilton: I have to think about the draft and how the cursors would
be implemented. I don't know whether the server has to maintain state
for the cursor, or whether the cursor itself carries enough context for
the server to continue processing the next request, as in, it internally
holds a reference to the next item.
Per Andersson: There are next and previous cursors to the next cursor.
In SCIM pagination, I think there is also the item count in the result
set, for this as well.
Robert Wilton: I have to look at the draft and think about it. I can't
give you a useful answer here.
Kent Watsen: (As an author) When we talk about server containing the
state, it's the persistence layer inside the server that create the
curesor. Some databases remember what the initial limit was. If any
implementation uses that database, then they have no choice. It's a
server bound limit.
Robert Wilton: For us, there's no separate formal SQL data to the back
end, just a data store storing the state information. I don't know
whether we would create and store states for the cursors and have a
timer to clean them up periodically if they become stale, or whether you
can effectively have the cursor state as part of the request, like HTTP,
where you get the extra context each time and don't have to maintain any
session state for a particular cursor.
Kent Watsen: (As an author) I know a database expert and can ask her
about this. Unfortunately, she is only an expert in SQL-based databases.
If anyone wants to use a non-SQL database for the backend persistence
layer, I wouldn't be able to provide guidance on that decision.
Robert Wilton: I don't think we should rely on it being SQL back end.
Mahesh Jethanandani (chat): Just to confirm that for the list pagination
drafts, I will run another WGLC once the authors have made the changes
and Rob has reviewed the document.
Discussions about adding a feature statement to both offset and
cursor
Kent Watsen: The idea of a feature statement on cursor came up a few
sessions back. At that time, the WG felt that we should not have that
since both cursor and offset should be equally viable and implementable
by the server. However, given the complexity around defining and
implementing cursors, it may be better to only expose the ability to do
cursors when a server actually supports it.
The current YANG module in list pagination draft has a choice between
cursor and offset at the top level. So it's mutually exclusive.
Currently, I don't believe the choice is mandatory true. But we could
put a feature statement on both those two options, cursor and offset,
and make the choice be mandatory true. So the server has to support at
least one.
The trade-off is either a server that wants to support cursors does not
have to support offsets, which give the server more flexibility. Cursors
are more performant, which means we should guide implementations towards
doing cursors, but they're complex. If a server does do cursor, then it
does so on the hope that the clients will use it because it's the most
performant and would not want clients to fall back to offset. Then on
the flip side, if we force all servers to implement offset, which is
maximum interoperability, then no client will implement cursor. The
trade-off B is that all clients would have to support both cursor and
offset.
Two authors have different opionion on whether put the onus on the
server or the client? I think we should put the onus on the client
because it's really not hard for the client to do the math to use offset
or cursor. It's better to skew that way and allow servers that want
maximum performance to have that ability in the future.
Per Andersson: I have the opposing view. I think every implementation
should support offset, since it is almost trivial to include and
implement. I was also of the opinion a few meetings ago that cursor
should be mandatory as well.
Robert Wilton: You said the offset is less performant for our database
because we would have to iterate through and count. So if you make
offsets mandatory everywhere and cursor is optional, you're sort of
encouraging clients to do the thing that's much worse for servers. So I
guess cursor without the offset should be the mandatory thing.
Per Andersson: I think Robert is favoring Kent's solution.
Robert Wilton: I'm also concerned that there's a lot of options, extra
flags, and limits. We might implement some of them but not others, and
become non-conformant with spec where it says you have to implement all
these options.
Kent Watsen: Back to the performance thing, cursors are more performant
it can be viewed as a stream and the persistency layer that creates a
cursor knows what's the sort and the where. So when you pull on the next
page of data, it streams all the inforamtion up and only returns that
chunk. Offset has to recalculate the full where and the full sort, and
then it does the offset jump, and it throws away the whole result set.
Robert Wilton: It depends. The offset could cache that result set and do
it efficiently. We've implemented something close to a cursor that when
you iterating over these back end data structures, you give it the name
of last thing and retrive for the next thing, rather than iterating
through number.So I think the offset is expensive whereas the cursor is
pretty closer to what we want to do.
Per Andersson: Yes, I think so. Another question. You mentioned that
there's a lot of things and might not implement everything. I have been
against more feature flags because I think you should implement all of
it. Do you suggest that we should have more feature flags? If so, could
you please send it to the mailing list what you would like to be able to
toggle support for.
Robert Wilton: My last review comments might have said some of these
things. But I can tell you off-list on which features we would implement
and which we probably would not.
Per Andersson: That would be valuable.
CHAIR ACTIONS:
Mahesh Jethanandani: Is there anything materially left to do in this
document? If not, then any reason to wait?
Meher: Nothing in the document so far. Everything is updated.
Alex Huang Feng: I already sent my comments to the list for HTTPS-Notif,
that we should unbind the message namespace from the transport. This
would allow HTTPS-Notif to be used in other protocols, such as YPv2 or
notif-envelope. It may be a good idea to perform a WGLC of
https-notif-cbor and HTTPS-Notif together to threat these documents as a
cluster.
Kent Watsen: We could go ahead and do the WGLC for this draft together
with HTTPS-Notif.
The augmentations defined in HTTPS-Notif draft only make sense for YPv1
and disappears in YPv2 because it's part of that data model. But YPv2
still need to reference this HTTPS-Notif draft to pick up the protocol.
Speaking to Rob, would you reference the part of the HTTPS-Notif draft,
or do you think we should factor out that part and make it isolated and
easier to reference?
Robert Wilton: UDP-Notif has a similar requirement as it augments YPv1.
I was expecting that once UDP-Notif gets pulished, we publish
HTTPS-Notif. Then we updates both documents to augment YPv2. So still
keep the independence of the transports.
Kent Watsen: It makes perfect sense.
Vojtěch Vilímek: Authors need to edit the examples because the usage of
YANG SID is invalid. They are using allocated SIDs that are not theirs.
Bharadwaja Chittapragada: We did mention that we're using an example
allocation and not the actual allocated SIDs, but we'll take a look
again and try to revisit it. Thank you.
Kent Watsen: We can always ask IANA for early allocation.
Alex Huang Feng: I discussed with the YANG-SID experts in regards to SID
allocation, and they encourage authors of documents that are using SID
files and are adopted by working groups to go to IANA and pre-allocate
the SIDs.
Thomas Graf (chat): @Meher, many thanks to the CBOR named identifier
contribution to libyang. This is very well received.
Bharadwaja Chittapragada (chat): Thanks @Mahesh @Kent and @Alex Huang
Feng and @Thomas for the upstream updates, reviews, suggestions and
guidance. We'll also take at a look at the .sid file and its allocation
Thomas Graf: YPath is probably not only something we need to consider
for YANG PUSH itself, but also for NETCONF and RESTCONF. So it should be
a generic way of filtering data.
Robert Wilton: Yes. My vision is that we can get something that replaces
XPath completely. It might be a YANG 2.0 or 3.0 thing. The YPath our
draft talk about is a subset of it. A complete YPath should do as a
separate extension and then bring it in future when it's got more
traction in the industry.
Thomas Graf: Just check on the yang 2.0 and didn't see anything about
YPath.
Robert Wilton: There's a issue for tracking this in YANG 2.0 issue
tracker. But my suggestion is to defer it.
James Cumming: We are looking to put YPath into a separate draft so that
it can be reused in multiple drafts/places. The work has started on the
draft.
Robert Wilton: YANG Packages has the same requirement, where it would
prefer a YPath and not an XPath.
Alex Huang Feng (chat): I agree with Thomas, I would welcome to use
YPath widely in the YANG environment. So I welcome having this in a
different document.
-
Balázs Lengyel: Some similar debates in 3GPP. With merge, it is
difficult to indicate that I added three items and also removed one.
Robert Wilton: You also have a delete flag, so you can send a separate
delete for the deleted item. In our implementation today, unchanged
notifications include the changed fields together with additional
unchanged data. But discussions among the authors, as well as feedback
from operators, favored stripping unchanged notifications down to only
the fields that have changed.
Balázs Lengyel: The JSON community uses null indicating that somthing
removed. Did you consider something like that? It could be part of a
merge with an explicit statement that the change is actually a delete.
Robert Wilton: We didn't discuss the idea. One consideration is that we
are trying to make the messages behave as closely as possible to how
message brokers expect them to work. The semantics often have the merge
semantics separated with the delete messages. If the merges and deletes
are in the same thing, the consumer has to split them into separate
updates to go into the message bus. Another reason is to align more with
gNMI. We're trying not to have too many different options.
Balázs Lengyel: At least this delete by merge is what I got from other
community that they would like it. Another comment is in 3GPP I alwasys
get depth parameter for filtering so that don't have to go through the
full tree. Wouldn't that be useful for YPath?
Robert Wilton: I don't think that will be part of YPath itself. It might
a separate field as part of the subscription. There's an issue tracking
about subscribing to the subtree of data but prune out other subtrees
underneath. I think it's a balance between producer performant and
complexity. About the depth, I worry whether implementations will pull
all data and filter last, which reduces the load on the network and
consumer, but do a lot of hidden expensive operations.
Balázs Lengyel: If the comsumer is not interested in the deeper level,
then sending it out and let consumer prune the extra data doesn't not
help.
Robert Wilton: But they could just ask those fields that they want.
Thomas Graf: It's not only about the message broker consumers, because
message broker is also kind of a database. In general, we want to make
it as easy consumable as possible. So that's why the merge and replaced.
-
Per Andersson: Regarding on change on statistics, do you remove
dampening period?
Robert Wilton: Yes.
Per Andersson: So are you circling back to including it?
Robert Wilton: What the document says is the server is allowed to dampen
these values and choose what it does. So what we would do is dampen it
to the interval that we read the statistics from the hardware or the
components. So it ends up being we'll read them every 10 or 30 seconds
and then notify the values changed.
Per Andersson: But you don't want the client to tune that?
Robert Wilton: No.
Per Andersson: You don't want to show how often it is done? It's
implicit from when you get the update.
Robert Wilton: I think the capability model that Thomas has been talking
about is a better way to advertise it. In terms of letting clients
control it, I think it's too much complexity. Clients could potentially
request a lower cadence, but that would probably make it harder for the
routers to manage.
Per Andersson: Another question. Do you distinguish between the delivery
guarantees for statistics and operational states? or alarms and
counters.
Robert Wilton: No. You take whatever the semantics for the subscripiton
is. Maybe that's something we should discuss. I think it's more between
an on-change subscription that needs more guarantees, versus a periodic
subscription where the losing data will be sent next time.
Per Andersson: In draft-netana-opsawg-telemetry-over-quic they state
that the server should send e.g. alarms on QUIC STREAM and send e.g.
counters on QUIC DATAGRAM.
Robert Wilton: I think we want to tighten that into the specification.
This draft also allows, unlike YANG PUSH, to have a subsciption
on-change and periodic, e.g. an on-change notification by a period of
one hour.
Thomas Graf: About the dampening, it should be advertised through the
capabilities and visible to the client. I think it's not necessary to be
configurable because dampening is primarily intended to protect the
router itself from being overloaded. Making it configurable would mainly
serve the client side for a notification frequency they want, which I
don't think is really a requirement.
Robert Wilton: One thing I'm thinking about is if the implementation
start generating notifications at high cadence, then that might dos the
client. My resoning is the server should choose should a sensible
period. Like interface flaps, you want to quickly dampen those
internally rather than generating every event. I think it's the same
here, ensuring that we don't pull this too quickly.
Holger Keller (chat): @rob if you create a message for flapping (instead
of sending 10000 times the new state), there is also a message needed,
that flapping is not not occuring anymore. at least traditional
event-systems need these messages to be able correlate against the flap
start.
-
Alex Huang Feng: I read the document and it is well-written. Thanks to
the work. I have some detailed comments, may not be super important.
Should I wait for new iterations to send out to the list?
Robert Wilton: Please send them now.
Robert Wilton: I think it's useful and we should do this. It's a nice
way to manage these things.
Poll: Do you think the Error Registry document should be adopted?
total participants:52
yes:23
no:0
no opinion:3
Mahesh Jethanandani (chat): I also agree that the error registries
document is useful and should be adopted.
Balazs Lengyel: Are you saying that you will create IANA registries or
IANA maintained YANG modules.
Per Andersson: I would say both. Leveraging the IANA registry to create
a YANG module is the idea.
Mahesh Jethanandani (chat): @Per, I am not sure I understood the comment
on YANG module/IANA registry. Are you saying it will be a IANA YANG
module with an IANA registry backing it to record all errors?
Per Andersson (chat): @Mahesh: Yes, both. We create IANA registries to
be able to generate IANA maintained YANG modules. In my view it seems
like a simple mode of operation for IANA to maintain everything.
CHAIR ACTIONS:
Kent Watsen: I struggle to understand how it's part of the NETCONF WG?
Mingzhe Xing: I think our draft is more related to the telemetry
protocol management. We use the exisiting protocols to collect data. In
the agent-assisted network management era, we need a status management
layer to process this data and give bounded data for agents to perform
better reasoning. I think it's necessary for the existing protocols.
Mahesh Jethanandani: Similar question because the draft name mentions
NMOP. As an information drive, a presentation is fine. But I would agree
with Kent that I am struggling to understand why NETCONF would adopt
this document.
Thomas Graf: I have a different opinion. We had discussion about YPath
and discussion about merge / replace in YANG Push. This document
explains some requirements and use cases, which is the reasons why we
needs these functions. But what would have been good in the presentation
is to actually bring this up towards the NETCONF protocol and that would
have been useful.
Robert Wilton: I think it's good to do this as an experiment. Personally
I'm not very keen on requirement documents. I'm not sure these
requirements are much more than generic requirements for AI systems and
LLMs, or how tied they are to this particular thing. I'm also not sure
with LLMs you need to have that standarized package information. I'm not
sure I see the value in terms of an RFC, particularly as how quickly
LLMs move forward in their capabilities.
Reshad Rahman: Did you ask to present this in NMOP?
Mingzhe Xing: Yes.
Time Remaining: 0 minutes