minutes-122-netconf-202503180600-00

Kent Watsen (as a contributor): A previous slide said client/server
identity, do you mean server authentication? How you authenticate a
server is server authentication and how you authenticate yourself to the
server is client authentication.

Kent Watsen (as a chair): There has not been much discussion. github is
not the place for official ietf discussions. please bring the discussion
to the list. there was a request for reviews but no comments, pretty
quiet not good. If people could review the next version of the draft.

Mahesh Jethanandani (as an AD): I looked at the last IETF minutes and
found that Per told you to take the comments to the list in order to
keep the meeting time. There was no discussion on the list, nothing. To
the github point, there were issues #5, #6, #18, and #19; they were
closed with a comment and no notification to the mailing list. Please
bring discussions/decisions to list before closing issues on e.g.
github.

Joe Clarke: The document feels underspecified. You talk about the
bidirectional and unidirectional streams, and messages like this message
type should be set with these bits in QUIC. It would help make this
draft look more like a standard document instead of suggestions. Some
more concrete text would help make it more implementable.

Jinyou Dai: We want to keep order of data amongst sessions and
effectively we want to make full use of QUIC.

Kent Watsen (as a chair): Take that discussion to the list.

YANG Groupings for QUIC clients and QUIC servers (5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-quic-client-server-01

Discussion Leader: Per Andersson

Per Andersson (as an author): I will take no question and will take the
discussion to the list.

Kent Watsen (as a chair): Why don't we have a RESTCONF over QUIC draft?
Because we don't need to! Already RESTCONF is on top of HTTP, which
supports QUIC. No updates needed, to support QUIC. The
http-client-server allows for QUIC to be used as a transport.

Rob Wilton (chat): I'll put my comment here, I think that a IANA module
for the QUIC versions would make sense, i.e., whenever a new version of
QUIC is updated.

List Pagination for YANG-driven Protocols (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-06

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-06

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-07

Discussion Leader: Qin Wu

Mahesh Jethanandani (as an AD): Do we need a second WGLC? The idea was
that the WG LC have been submitted.

Qin Wu: No, that is not necessary.

Mahesh Jethanandani (as an AD): Per, have all the comments been
addressed?

Per Andersson (as an author): Yes, we have addressed all the comments
raised by the reviewers. Maybe not exactly to their content. For
instance "sort" feature and minimal profile are mutually exclusive.

Mahesh Jethanandani (as an AD): Andy had a comment, have that been
resolved?

Kent Watsen (as an author): The response to Andy was that
"sublist-limit" is different to "depth", he didn't respond to that. It
is not believed to currently be a blocker.

Mahesh Jethanandani (as an AD): I did officially close the WGLC, is a
revised I-D needed? Or has all the comments been incorporated?

Qin Wu: We believe all issues are resolved and that we are confident in
this draft moving forward.

Per Andersson (as an author): One point, we have implementation of
"sublist-limit" so Andy's comment is addressed. We need to remove DELETE
so a revised I-D is needed for the RESTCONF draft. Other than that it is
done.

Augmented-by Addition into the IETF-YANG-Library (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-library-augmentedby-01

Discussion Leader: Zhuoyau Lin

Rob Wilton: You don't need the revision date. I think you don't, because
the augmentations only matter for implemented modules and you don't
implement a given single version of a module so you don't need the
revision date. You can loose the revision date and keep it simple.

External Trace ID for Configuration Tracing (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-configuration-tracing-03

Discussion Leader: Jean Quilbeuf

Mahesh Jethanandani (as AD): The template for Security Considerations
you are following is slightly old. Look at 8407bis for your security
considerations. The first paragraph looks old according to that
template.
Jean Quilbeuf: I'll update it.

CHAIR ACTION: WGLC

Adaptive Subscription to YANG Notification (5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-07

Discussion Leader: Quifang Ma

Kent Watsen (as a chair): The chairs agree that this document can move
into WGLC.

Benoît Claise: Mahesh, do you recommend to use the security template
from 8407bis even though it is still a draft?

Mahesh Jethanandani (as AD): Yes, that is what I have been recommending
since there is a typo in the current document.

Mahesh Jethanandani (chat) (as AD): @Benoit, is the concern about using
the template have to do anything with a MISSREF?
I hope not, because I am assuming that 8407bis is being referenced
informatively.

Quifang Ma (chat): Agree, 8407bis mentions to be referenced as
informatively.

Benoît Claise (chat): @mahesh, not with MISSREF but mainly: the IESG
might want to improve the security considerations template from 8407bis.
Maybe I am a little paranoid. :-) If this happens, we will have to
remind ourselves to update all current YANG-related documents, before
publishing.

Mahesh Jethanandani (chat) (as AD): Good point. There is always a chance
that some AD might want to update the Security Considerations template.
In fact, there is some feedback coming from Sec ADs.
The reason to use the latest template is that the reference to SSH was
incorrect in the existing template. They should be referring to SSH
[RFC4252]. Not to mention, it lacks the mention of QUIC.

CHAIR ACTION: WGLC

UDP-based Transport for Configured Subscriptions (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-19
Discussion Leader: Alex Huang Feng

Kent Watsen (as chair): There is a volunteer for a shepherd, the chairs
will discuss it.

Kent Watsen (as contributor): How does the subscribers know if they
should accept the lossy subscriptions or not? If the message needs to be
delivered, the guidance is to use the https-notif draft. The expectation
is that the subscriber will know what should be used for reliable and
unreliable transport. It puts the honus on the subscriber to be able to
look at the data model and what data is ok to be lossy and not lossy.
How do they come to know this? Should the WG discuss the creation of
some annotation or metadata that can tag information in the data model
so subscribers can be aware of what data is ok to be lossy or not lossy?
Somehow guide the subscribers to make the right kind of subscriptions.

Alex Huang Feng: It is out of scope for udp-notif. Now, it is up to the
operator who deploys it if the information can be lossy or not.

Kent Watsen (as contributor): I agree it is not specific for this draft,
but I'm being cognizant of a looming issue.

Rob Wilton: Seems to be unecessary complexity to indicate lossiness.
With configured subscriptions, the users setting up the subscription
will know what they want to do with the data and how to process it. They
have the choice of using a reliable transport or not. I don't think
annotating the data is needed.

Thomas Graf: We have an applicability section and refer to "accounting",
accounting refers to periodical subscriptions.

Mahesh Jethanandani (as a contributor): Don't need annotations
necessarily. One thing we have done is if the container is a counter
container and we know that it will be sent at a regular interval (it can
go over unreliable transport), whereas state information (i.e.
on-change) it has to go on a reliable. It can truly be resolved by
modelling the data correctly.

Kent Watsen (as contributor): Sounds like a convention. Maybe we can
have a best practice, e.g. using a container called "counters" if that
is the intended use. Perhaps we can look forward to such a draft with
best practices.

YANG Groupings for UDP Clients and UDP Servers (5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-client-server-06

Discussion Leader: Alex Huang Feng

Kent Watsen (as a contributor): What scenario is it that a server would
want to have more than one port open on the same IP address. My thinking
is that, normally, a server would listen on a well known port. If it is
TCP, it could accept any number of connections on that port, each of
which would be assigned sockets. If UDP, it can be multiplexed. Does
anyone know how common is it for servers to need multiple ports for the
same address?

Joe Clarke: From an appliance perspective, it really isn't, but can
imagine wanting to run multiple instances of a webserver on a device,
each of which would need to be on a separate port. Or two RADIUS servers
each serving a different purpose, one listening on 1812 and 1645.

Kent Watsen (as a contributor): Quick follow up, those two purposes,
would they differ in higher-layer processing? For instance, one
TCP-cleartext and the other TLS?

Joe Clarke: I might, for instance, one for production and the other for
debugging.

Kent Watsen (as a contributor): Right, and the reason I ask is because,
in that case, there would be two endpoints: one endpoint for TCP, the
other for TLS. Both could have the same IP address, but they're
different endpoints. The case at hand regards the same endpoint having
more than one port on the same IP, so both ports would have to have the
same protocol stack. When would that be?

Joe Clarke: I see your point.

Rob Wilton: There's a possible case where this might be needed to
support a migration. It may be worth checking what Linux , does it allow
it or not, as it would give indication if this matters. Even having said
that, I think that it might make sense to do the same as TCP and, even
if it's wrong, it's easy enough for someone to define a different
grouping, so it's an easy fix. Wouldn't rat-hole on this. I don't think
it matters that much.

Benoit Claise: The question we have to ask ourselves, when defining a
grouping, do we have to think about every possible use-case for the
future, or we grouping for the majority of what we want to do now. I
think this is somehow the latter. If someone has an exceptional case in
the future, maybe they just don't use the grouping, and that's okay.

POLL: Should We Leave The Model As Is (With A Single Port Per Ip
Address)?
About 1/3 members present participated in the poll. Of those, the
majority thinks that we should leave it as is. Though some wanting
option 'b', about 4x more wanting to leave as is.

Kent Watsen (as a chair): If choosing "leave as is", that means the
draft is ready to be published:

Alex Huang Feng: Exactly.

Kent Watsen (as a chair): Perfect. So we will be needing a Shepherd for
this...

Rob Wilton: Can I quickly ask, for those that said "no", it might be
worth asking why and get reasons for that. Have people cases here that
need to be discussed?

Kent Watsen (as a chair): Normally when there's a disagreement we ask
why. But in this case, "no" isn't so much a negative as a positive for
the other preference. Still, if anyone that voted "no" would like to
share why, could you do that now?

No one came to the mic.

Kent Watsen (as a chair): We will progress it as quickly as possible.

CHAIR ACTION: find shepherd and publish.

Subscription to Distributed Notifications (5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-13

Discussion Leader: Thomas Graf

There was no discussion.

Kent Watsen (as a chair): We will progress it as quickly as possible.

CHAIR ACTION: find shepherd and publish.

Non-Chartered items:

YANG Notification Transport Capabilities (5 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yp-transport-capabilities-01

Discussion Leader: Thomas Graf

Per Andersson (as contributor): I read the document and saw in the YANG
model it says that TLS 1.2 is obsolete in the identity. I have not found
any support for this. It might be a nit, but TLS 1.2 is very much
supported still. There is no plan for obsoleting or deprecating it yet.

Thomas Graf: Absolutely correct about TLS 1.2, will fix.

Per Andersson (as contributor): And one more in this example you have.
The prefix "idx" is used in the example presented for two different
namespaces. I would assume that for ietf-subscribed-notifications its
prefix ("sn") would be used and analogous for ietf-udp-notif-transport
prefix.

Thomas Graf: I was just copy/pasting from the hackathon. Will need to
look at it.

Rob Wilton: Per, can you send me an email with the details and I'll
check it. It is in our implementation rather than what is in the model.

Kent Watsen (as chair): At this end of your first slide you said that
you felt that it was ready for adoption already. As the WG may recall,
this draft was just adopted, so this is moving very quickly. This is
possible because this document has been implemented by a number of
vendors and service providers. Running code is the ultimate litmus test,
allowing for the acceleration of the progress of documents thru the IETF
process. It is recommended for authors to try to have their work
implemented in order to acceleration their progression thru the IETF
process.

CHAIR ACTION: Start WGLC (IPR poll uneeded since just polled before
adoption)

Extensible YANG model for YANG-Push Notifications (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-01

Discussion Leader: Alex Huang Feng

Rob Wilton: On slide 8, you had a "SHOULD". "The 'contents' element
SHOULD be located at the end of notif envelope structure." I would make
this a "MUST". Otherwise clients have to cope with the header coming at
the end of the message.

Alex Feng: I'm okay with changing it.

Thomas Graf: Just a comment on the Hackathon. We now have two
implmentations on the envelop and look forward to a third one.

Alex Feng: And these are added to the draft.

Thomas Graf: Yes.

Kent Watsen (as chair): So this will be another draft that we can move
quickly thru the process, because it is being facilitated by
implmentation.

YANG-Push Operational Data Observability Enhancements (15 min)
https://datatracker.ietf.org/doc/html/draft-wilton-netconf-yp-observability-01

Discussion Leader: Rob Wilton

Balázs Lengyel: 3GPP defined a JSON expression, an XPath like expression
but for JSON. You might be interested in having a look at that.

Rob Wilton: Yes, I would be interested into looking at what you have
there. I've mentioned "YPath" in the presentation. It is possible that
I'll try to splut it out of this draft and have a separate draft that is
simply on YPath. But for YPath, there are two different use-cases. For
YANG Push and YANG Packages, we want a really simple path expression
where you might bind the keys to a simple value or to a regex. But there
is also a broader idea of YPath being more like a full version of XPath,
but JSON-ified and YANG-ified. So there are two different variants of
it. What we want here is the simple version and don't want this work to
get stuck on a long discussion. But, yes, thank you for the suggestion.

Alex Feng (chat): I'd rather have a keep it simple approach, supportive
of just support one Xpath at a time

Thomas Graf (chat): @Alex +1

Kent Watsen (as a contributor): You write "Simplified NACM Conformance"
and said so that it's not in the fast-path of trying to get the packets
out. But that doesn't seem right to me, as NACM would be evaluated at
the time the subscription is being configured, and once accepted by
access control, when going out the Eastbound interface, there should be
no extra checking at that time.

Rob Wilton: That's what we want to get to, but with YANG Push, that is
not where we are today. For instance, if the user policies change on the
fly, the server is oblidged to restrict the data. So that the thing, for
dynamic subscription, we want to simplify. We want to do as much of the
checks at subscription-creation time and then assume that it is going to
be okay. And when it comes to configured subscriptions, mostly they
don't need any of this at all, because all the checks can occur at time
of configuration. Original YANG Push was over specified.

Per Andersson (as a contributor): How would you handle active
subscriptions if the user policies change, would you just shut them
down?

Rob Wilton: TBD. Don't know yet. One choice is that you do nothing to
them and force the client or user to make that choice to shut them down
and the second choice is to notice the change and turn (tune?) them down
automatically. We haven't dicussed/debated that point yet.

Per Andersson (as a contributor): Suggest not having a hole where data
can be leaked.

Rob Wilton: it depends. I think it is valid, but must look at this
pragmatically. There are other cases where the device needs to be
proactive. Don't know if we need to over engineer this, if this is a
case that already has to be handled elsewhere.

Rob Wilton: have talked with Kent about having an interim just before
IETF 123, so it can be adopted just after IETF 123.

Kent Watsen (as chair): Please send a request to the chairs when ready
for an interim.

Joe Clarke: I really like this work. Minor thing, there is a new RFC
9535 on JSONPath. I don't know if you saw that. It has regex support,
maybe too complex for what you want to do. Bigger comment, after
listening to Dhruv yesterday about a plethora of choices in this area
regarding protocals, transport, encodings. I like that you are engaging
operators, and Thomas may be the unicorn in the room in how must he is
using model-driven management. Is there a consideration for a migration
path? How would you provide tooling for operators to make use of this to
move, e.g., from a fledgling YANG Push implmentation to YANG Psuh Lite.
Your goal of simplicity is great, but is adding yet another thing
without consideration of operational impact the right answer?

Rob Wilton: To you first question regarding JSONPath, I'm aware of it
but haven't read the spec, but am nervous of going down the JSONPath
path as I'm afraid we'll end up in a simlar situation as we are in now
with XPath. I think that we want something that is tied to YANG, rather
than a given encoding. And, in terms of migration, yes, we're not trying
to change too much. We (Cisco) have a YP implementation and expect to
migrate to YP Lite, so I have a vested interest in not creating too much
churn.

Joe Clarke: Some hackathon projects for tooling to port implementations
would be interesting.

Rob Wilton: Yes, yes.

Per Andersson (as contributor): You don't have the "subscriptions"
container anymore, you call it "datastore-telemetry" where you have the
bookkeeping. That is "config true", so how will you solve it for dynamic
subscriptions, which would be operational data? That is the trouble in
our implementation.

Rob Wilton: You would use NMDA's "operational" datastore and that list
would be for both configured and dynamic.

Thomas Graf (chat): @Joe, we have a website:
https://www.network-analytics.org/yp/ . Its still early but there we
want to engage the implementators and the operators.

HTTPS-Notif-Draft implementation, Kafka integration and Bandwidth
Analysis (5 min)
Discussion Leader: Siddharth Bhat

Applause

Rob Wilton: I was going to repeat the thank you. I think that it is
great to have students implementing the drafts and bringing the results
to the IETF. I suggest using GZIP compression across JSON, XML, and CBOR
(both with and without SIDs), to look at the overhead on processing and
over the wire, because there is some data suggesting that
JSON+compression is as good as CBOR. It would be good to get some actual
figures to see what comes out of that.

Kent Watsen (as a contributor): I have both a question and a comment.
With the Kafka implmentation, was TLS encryption turned on between the
publisher and the collector?

Presenter-1 (unsure which one): Yes

Kent Watsen (as contributor): and the comment, to Rob's point about
increasing your test matrix with compression on and off, it would be
interesting try various versions of HTTP: HTTP/1, HTTP/2, HTTP/3, being
QUIC.

Per Andersson (as a contributor): thank you for the awesome presentation
and implementation of the draft. I validate XML with libyang2, with
'yanglint', so I'm surprised that you had issues.

Presenter-1 (unsure which one): We'll look into that. XML/JSON isn't so
much the issue, CBOR is where it gets hard.

Per Andersson (as contributor): that I can understand.

Kent Watsen (as a contributor): you mentioned difficultly validating
sx:structures, one trick is to, in the YANG, where it says "structure",
make it a "container", and then validate it.

Presenter-2 (unsure which one): we did that, but since it required
modifying the YANG, it did not seem right.

Per Andersson (as a contributor and Yanger dev): Yanger has support for
augmenting structures, but I don't know if we've pushed it yet.

CBOR Encoding for HTTPS-based Transport for YANG Notifications (5 min)
https://datatracker.ietf.org/doc/html/draft-chittapragada-netconf-https-notif-cbor-00

Discussion Leaders: Bharadwaja Chittapragada, Vartika Rao, and Hayyan
Arshad

Presenter-2 (unsure which one): I think there is support for structure
in Yangkit, which is in Java, but we're using Python and C. So it's all
spread out. There should be one proper thing.

No Time Remaining