Agenda:
https://datatracker.ietf.org/meeting/121/materials/agenda-121-netconf
Materials: https://datatracker.ietf.org/meeting/121/session/netconf
Friday, 8 November 2024
Session II 1300-1500 Europe/Dublin
Room Name: Liffey A (size: 250)
Kent Watsen (kent plus ietf at watsen dot net)
Per Andersson (per dot ietf at ionio dot se)
Reshad Rahman (reshad at yahoo dot com)
Notes: https://notes.ietf.org/notes-ietf-121-netconf
Slides: https://datatracker.ietf.org/meeting/121/session/netconf
Drafts (PDF):
https://datatracker.ietf.org/meeting/121/agenda/netconf-drafts.pdf
Drafts (TGZ):
https://datatracker.ietf.org/meeting/121/agenda/netconf-drafts.tgz
ICS: https://datatracker.ietf.org/meeting/121/sessions/netconf.ics
Zulip (chat): https://zulip.ietf.org/#narrow/stream/netconf
Recording: https://www.meetecho.com/ietf121/recordings#NETCONF
Youtube: https://www.youtube.com/watch?v=fs0j8E0CZtY
Presenter: chairs
Per Andersson: we encourage participation from the community.
Per Andersson: Post WG documentation status:
Per Andersson: Other WG work:
Per Andersson: Going through the agenda: intesresting thing for list
pagination is that both WG chairs are co-authors. We will need the AD to
conclude WGLC for these documents and for someone else to be the
document shepherd.
Mahesh Jethanandani (current AD): for the list-pagination documents, I
will drive the WGLC I will ask Reshad Rahman to be the document shepherd
Other question, {NET,REST}CONF-next same question as for YANG-next. Is
it worth doing a NETCONF 1.2, instead of NETCONF 2.0, for more
short-term work? Maybe more people would be interested if the scope is
smaller.
Per Andersson: work identified was extension to the current protocols,
minor protocol change, major protocol overhaul needing YANG-next
Kent Watsen: RFC 9640 was missing on the list of new RFCs
Kent Watsen: The http/netconf/restconf client-server documents are
blocked by a DISCUSS from Francesca on client-server drafts, we had chat
this morning and this should be resolved
Mahesh Jethanandani (on chat): I do not know if it would help to clarify
what netconf-next and restconf-next entails. What you, Per, said on the
mic.
Per Andersson (on chat): I can clarify it if we have time for open mic
at the end. And I'll be sure to post an update to the list about
NC/RC-next
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-quic-01
Discussion Leader: Marc Blanchet
Needed for deepspace. Changes in -01 mostly editorial. See GIT repo.
Remaining comments: issues 6 and 7. Issues 18 and 19 are just in, they
haven't been discussed yet.
We have a POC implementation from Adolfo Ochagavia.
Remaining questions:
We intend to address remaining issues before next IETF. Please comment.
Per Andersson: I see there are people in the queue but we neeed to move
on because the agenda is packed. Please take questions to the mailing
list.
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-privcand-05
Discussion Leader: James Cumming Robert Wills
Since IETF120, draft has been simplified: we removed the NMDA datastore
approach and instead we reuse the candidate datastore in private mode.
This mechanism existed for non-NMDA clients, we just removed the
NMDA-specific solution.
Outstanding issue: should resolution-mode be available as an option to
?
The authors believe that we should not add this, main reason is
orthogonality.
Minor updates coming (editorial changes only).
Next steps: publish -06 and we'd like WGLC.
No questions
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-transaction-id-07
Discussion Leader: Jan Lindblad
Author believes new version -07 addresses all received comments.
No questions
Per Andersson: probably we will need to conclude the WGLC
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-05
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-05
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-05
Discussion Leader: Qin Wu
3 documents: common list-pagination mechanism, NETCONF extensions and
RESTCONF extensions.
All previous outstanding issues have been addressed by the design team.
We would like to request WGLC.
Kent Watsen (as contributor): if-feature is usually used to constrain
the data-tree and capabilities are actually protocol capabilities, is
there inconsistency to using if-feature for RESTCONF and capabilities
for NETCONF? For NETCONF we are using capabilities and for RESTCONF we
are using feature statements.
Per Andersson (as co-author): I don’t know, let’s discuss on the mailing
list
Kent Watsen (as contributor): updates done in local copy, need to upload
to datatracker, should be ready for WGLC then
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-client-server-05
Discussion Leader: Alex Huang Feng
Kept default port 0 on the client local-port. Other default port 0 have
been removed (client remote-port and server local-port).
We also made editorial changes to adress comments from the mailing list.
Open point is whether we move UDP-DTLS groupings from
draft-andersson-netconf-quic-client-server to this document.
Question to the WG is whether we should do the move. My opinion is that
we should not, because we have dependency on use-cases.
Kent Watsen (as contributor): I agree, this document should only do UDP
groupings. But we should we have a DTLS client-server document?
Per Andersson: QUIC does not use DTLS (to my understanding).
draft-andersson-netconf-quic-client-server also has QUIC protocol
settings
Alex Huang Feng: QUIC client-server would add on top of UDP groupings
some extra parameters for QUIC. How do we move forward?
Mahesh Jethanandani: Was also going to ask how do you want to move
forward? WG should make a decision, can we have a poll?
Poll: should the UDP-client-server draft only focus on the UDP layer?
(44 attendees)
Yes: 22
No: 0
No opinion: 1
Alex Huang Feng: since we have no open issue, we would like to ask for
WGLC
Kent Watsen: no reason to delay WGLC, does anyone feel otherwise (no-one
spoke up)?
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-15
Discussion Leader: Alex Huang Feng
This is UDP transport for configured subscriptions with YANG-Push. Only
editorial changes between -15 and -16.
Open issue #1: Default port for UDP-notif. Responses on mailing list
stated that it is not needed. Joe Touch (TSVART) concurred that it is
not required. I believe we can close this issue.
Kent Watsen: I will concede that there is consensus. But I would have
thought WG would push for default-port and that TSVART would have said
no, and then we'd push harder. IMO, we capitualatd too early, but that's
ok.
Open issue #2: This was brought up by Kent, how does a client discover
that the server supports UDP-notif. Adding notif capabilities in a
different draft might address this holistically.
Authors believe there are no remaining issues, document is stable and
ready for WGLC.
Per Andersson: Chairs believe transport review is not really concluded
and should wait for it to complete fully because it might have some
impact on the draft
Alex Huang Feng: how should we address this?
Per Andersson: I believe you should respond to latest
Thomas Graf: on behalf on implementers, we are currently implementing,
if we could do the WGLC in parallel with the transport review
Kent Watsen: chairs will discuss on how to proceed
Mahesh Jethanandani: what is the blocking issue, is it that we are not
getting a response from TSVART or have we not addressed their comments?
Per Andersson: my opinion is that there are outstanding issues from the
transport review, need to re-check
Kent Watsen: ball is in our court to respond to Joe Touch one more time
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-10
Discussion Leader: Alex Huang Feng
No changes recently, would like to request WGLC.
Per Andersson: anyone in the WG disagrees? No response.
Kent Watsen: my hesitation with WGLC is that there hasn't been lots of
discussions on that document recently, it could happen via WGLC.
Alex Huang Feng: we want WGLC to trigger those discussions
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-configuration-tracing-03
Discussion Leader: Jean Quilbeuf
Updates:
Closed issue: should we make a more general solution? We decided to
remain focused on configuration tracing, solution is simpler than a
generic solution.
No open issues left. Draft is ready for WGLC.
Kent Watsen (as contributor): is the draft applicable to both RESTCONF
and NETCONF? I see the examples mentioned are NETCONF specific.
Jean Quilbeuf: Yes. RESTCONF is supported natively as trace context is
defined on top of HTTP. In that case, the trace context is passed as a
HTTP header.
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-library-augmentedby-01
Discussion Leader: Zhuoyao Lin
Background and motivation: reverse dependency between YANG modules is a
bottleneck
Updates: corrected examples and deleted section on evaluation of
RFC8525bis (authors think this is too big of a task)
Authors believe there are no open issues and ask for WGLC.
Kent Watsen: any concerns/comments about WGLC (the document was adopted
very recently)?
No response or concerns. Chairs will initiate a WGLC.
https://datatracker.ietf.org/doc/html/draft-andersson-netconf-quic-client-server-01
Discussion Leader: Per Andersson
We are defining reusable YANG groupings for the QUIC protocol. And
reusing tls-client-server and udp-client-server.
Augment of netconf-client-server is in this document (as an experiement
since it was faster) but should probbaly go to the NETCONF over QUIC
document.
Kent Watsen (as contributor): be aware that there's a COMMENT from Zahed
on http-client-server (the server grouping will be changed a bit)
Per Andersson: asking for WG adoption
Mahesh Jethanandani: poll whether there's interest in adopting the
document?
Mahesh Jethanandani: You’re defining a grouping for the QUIC server but
restricting to TLS1.3, is that ok?
Per Andersson: QUIC requires TLS1.3, that is why the restriction is
there.
Is the WG interested in adopting this document? (49 participants)
Yes: 22
No: 0
No Opinion: 0
Kent Watsen: we will run the adoption call after the meeting
https://datatracker.ietf.org/doc/html/draft-netana-netconf-yp-transport-capabilities-00
Discussion Leader: Thomas Graf
New document, inspired by Kent's comments on UDP-notif. This document
defines 3 new properties: transport protocol, security protocol
properties and the encoding format.
Request WG adoption.
Kent Watsen (as contributor): On slide 4, module implemented by
publisher?
Thomas Graf: Correct.
Kent Watsen (as contributor): So goal is for the publisher to discover
the capabilities of the collector?
Thomas Graf: It is for the client to know what the publisher
capabilities are, before it does the subscription. It’s built on top on
RFC9196. Needed for configured subscriptions.
Kent Watsen: https-notif draft should use this?
Thomas Graf: Yes. In this draft, there are two mechanisms to discover
capabilities 1) NETCONF capabilities 2)YANG capabilities (RFC9196), this
is what we are extending.
Robert Wilton: I think this is useful work. We are implementing this as
part of our YANG-push implementation.
Andy Bierman: I am also implementing a lot of these drafts. This a very
expensive way to keep adding one leaf at the time, I would prefer 2
RFCs. That is under the umbrella of YANG-push. Having a lot of RFCs to
track is complicated. Can we streamline this work (1 RFC for transport
layer and 1 RFC for application layer) and adopt it quickly?
Kent Watsen: YANG-Push lite, which comes later, should address Andy's
comments.
Diego: I entered the queue by mistake
Benoit Claise: This document is required
Thomas Graf: 9196 was designed for that purpose of plugiing in system
capabilities, this is what we are doing here.
Kent Watsen: I think we need more discussions on the list to do adoption
call before IETF122
Per Andersson: at the interim this was what was discussed and now is the
time to have the WG discussion
https://datatracker.ietf.org/doc/html/draft-netana-netconf-notif-envelope-00
Discussion Leader: Alex Huang Feng
This work came out of last WG interim meeting (Sept 2024). Need to
bypass RFC5277 hdr (XML-specific). Opt-in for new header.
Looking for feedback from WG, is this the way to go?
Open issues:
Per Andersson (as contributor): Subscription on slide 4 or 5, you can
configure to use it per subscription for dynamic subscriptions, for
configured is it global configuration?
Alex Huang Feng: right now all the configuration is per subscription
Joe Clarke: this work is useful. I'd say don’t allow each metadata to be
configurable, i.e. if the functionality is enabled you get what the
device supports for meta-data. Nit: do you need the capability
notification envelope or could you just use a container instead of a
notification?
Alex Huang Feng: on this we are pretty aligned, all extensions (enabled)
or no extension (disabled).
Robert Wilton: slide 11, I think it has to be defined as an
"sx:structure". It’s not a notification, it's something that will hold
the notification
Robert Wilton: In our implementation, we wouldn't support enabling per
subscription.
Robert Wilton: It is useful and we are implementing it.
Andy Bierman: I am also implementing, reviewed this draft and it also
fixes the concerns I had, as long as a new element is sent it will not
confuse with the previous version. Multiple subscriptions could be sent
to the same receiver, it will work. I think it's ready for WGLC.
Reshad Rahman: +1 to what Rob said regarding global config. What did you
envision as being useful to have per subscription?
Alex Huang Feng: I just started at subscription level, no problem to
make it global, whatever the WG decides.
Mahesh Jethanandani: plenty of interest, and implementation. Can we
start the adoption process and get to WGLC?
Kent Watsen: I was going to conclude on that same point.
Thomas Graf: Yes, let’s move forward, we have several implementors.
Per Andersson (as contributor): sx:structure vs notification, issue with
yanglint which skips sx:structure. Generic behavior with YANG tools, if
the extension is not supported.
Alex Huang Feng: I don't have the answer, maybe we should push for the
extension to be supported in tooling. That's why I started with
notification.
Dan Voyer: I like the direction of this draft and I will probably be
implementing it.
Kent Watsen: robust discussion and great to see the result of the
interim. Thank you. We should start the adoption call soon.
https://datatracker.ietf.org/doc/html/draft-wilton-netconf-yp-observability-00
Discussion Leader: Rob Wilton
Make YANG-Push easier to implement and consume. It started as extensions
but it's going towards YANG-Push lite. Striving for Minimal Viable Push,
not specifying a new protocol. Take out some existing bells and whistles
from existing YANG-Push.
Some options:
1) Extend RFCs8639/8641
2) Copy key parts from RFC8639/8641 into a new RFC
3) Small RFC that defines new functionality and references existing ones
Reshad Rahman: slide 6 mentions RFC (singular), is that a mistake or on
purpose?
Robert Wilton: it is a mistake
Reshad Rahman: with choice 2 if you copy key parts, I am worried on the
speed of progressing these documents.
Robert Wilton: we would reuse text that hass been vetted and approved,
we'd have appendix which references the text. I do appreciate the
comment
Mahesh Jethanandani (as contributor): +1 for making YANG-Push simpler.
One way to simplify, for instance filtering, is don’t do it, leave it to
the collector since collectors have more horse-power
Robert Wilton: in some use cases can drastically reduce the number of
nodes returned, if there is conflict between simplicity and feature,
we’ll go to the simplicity
Robert Wilton: that's the direction we're going but there are use-cases
where server-side filtering is useful. Need to find a balance.
Kent Watsen (as contributor): very happy to see this work. https-notif
went out of its way to not use RFC8639 to push configured subscriptions.
Options 2 or 3 look good. Ideally we'd deprecate RFC8639 later on.
Robert Wilton: we'd pull https-notif for the receiver portions.
Benoit Claise: Yes we have to do this work. We spend too much time in
the process. We need to align with vendors and operators to see what we
want. Let’s agree. Let's not spend too much time on the process (wrt
documents).
Robert Wilton: That’s my fear that this document is going to be too big,
will people review it?
Benoit Claise: at some point, we have a lot of implementors in the room,
if they agree, this is a done deal. We have to find the balance between
implementation and process
Maria Matejka: starting to jump on the YANG-Push boat. Please avoid
fragmenting into several drafts, and don’t copy (option #2) because it’s
a nightmare for implementation.
Robert Wilton: have you implemented YANG-push?
Maria Matejka: not yet, we are trying to catch up.
Robert Wilton: if we do copy the text, we’ll have a reference saying
this is what we have done
Weiqiang Chang: this document is very important, if possible we would
like to join the effort
Thomas Graf: important that we move on quickly, implementations are
going on
Robert Wilton: YANG-push discussion we had was happening in NMOP WG we
have various vendors and implementors working on that and we don’t want
to derail that effort
Dan Voyer: great news for the operator side. Can’t wait to see it get
more traction.
Holger Keller: Regarding the copying of other RFCs, maybe start with
references to existing sections and then move on
Robert Wilton: we discussed this earlier, maybe 3 as first step and 2
down the line
Joe Clarke: as someone who is trying to debug based on RFCs, please be
very explicit for implementors about how the different RFCs should
coexist. Notably what and why to implement
Robert Wilton: we’ll try to make that explicit in the document as an
appendix
Qin Wu: More in favor in option 3 (smallish RFC). Bring this work to
NEMOPS workshop?
Robert Wilton: I thought NEMOPS was more for long term.
Kent Watsen: a lot of support for option 2 in the chat
https://github.com/Sidhub723/https-notif-c-collector-fork/
https://github.com/MeherRushi/https-notif-servers/
Discussion Leader: Bharadwaja MeherRushi Chittapragada
Robert Wilton: Thank you for bringing this to the WG. Great to see
people implementing. Slide 16 about challenges, we should learn from
this example. For instance RFC7950 is fairly well written. Was it
NETCONF or XML?
Meher: YANG, we could understand. Difficulty was knowing what module was
being used and why. The XML namespaces were different from YANG
namespaces. Hard to make the link.