Draft Minutes for the NETMOD 122 WG Session

https://datatracker.ietf.org/meeting/122/materials/agenda-122-netmod
https://datatracker.ietf.org/meeting/122/session/netmod

WG Chairs:
Lou Berger (lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)

WG Secretary:
James Cumming (james.cumming at nokia dot com)

Session 1 Information (There is no session 2?)

Wednesday, March 19, 2025
13:00-15:00 (meeting local) / 06:00-08:00 (UTC)
Chitlada 2

Available During and After Session:
Notes: https://notes.ietf.org/notes-ietf-122-netmod?both
Slides: https://datatracker.ietf.org/meeting/122/session/netmod
Zulip (chat): https://zulip.ietf.org/#narrow/stream/netmod
Video/Meetecho:
https://meetings.conf.meetecho.com/ietf122/?session=33945
Onsite tool:
https://meetings.conf.meetecho.com/onsite122/?session=33945
Drafts (TGZ):
https://datatracker.ietf.org/meeting/122/agenda/netmod-drafts.tgz
Drafts (PDF):
https://datatracker.ietf.org/meeting/122/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about
ICS: https://datatracker.ietf.org/meeting/122/session/33945.ics

Available After Session:
Recording: http://www.meetecho.com/ietf122/recordings#NETMOD
YouTube: TBD
Jabber Logs: https://www.ietf.org/jabber/logs/netmod

Chairs items:

01) Session Intro & WG Status

Duration: 10 mins (start: 13:00 timer 00:00)
Discussion Leaders: WG Chairs

(03:23) Document updates delivered by chairs.

(05:07) There are a number of documents that have been judged by the
shepherd to need updates due to validation failures with the tools. We
are aware that the tool is returning errors/warnings when perhaps it
should not.

Scott Mansfield (06:36): Thank you. I have two comments. The
draft-interface-ext-yang is -15 not -13. -13 has errors. When I upload
and run the tooling I get warnings in the draft but when I put the YANG
lcoally and run it against my local version of YANG lint I do not get
warnings. Is an older version running in the tools? The errors I am
getting is from an included YANG model. We import and IEEE YANG model
that has some deprecated groupings but doesn't propograte the
deprecation all throughout the tree. This is going to be my rationale
back to the shepherd saying I cannot fix it because it's not in my draft
anyway.

Lou Berger: I hope that we can either have this fixed by the tools team
or a caveat saying we know there are warnings and thats OK, but, we are
the NETMOD group so we should know all of this stuff.

Scott Mansfield: I don't think a liaison back to the IEEE is required
but I can work to try to fix their process as well.

Mahesh Jethanandani (AD): Speaking as an AD, the request to the tools
team to update things comes at a good time as I am now the IESG
interface with the tools team. Scott, can you send me the details.

Balazs Lengyel: I doubt that this inheritance warning is valid. Is it
documented, the principle that deprecated in groups isn't inherited.

Lou Berger: Thank you. Lets discuss this on the list.

(12:27)

Last Call Updates:

02) RFC 6991 Post Last Call Update

Duration: 30 min (start: 12:44)
Discussion Leader: Mahesh Jethanandani
Drafts:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/17
Email:
https://mailarchive.ietf.org/arch/browse/netmod/?q=draft-ietf-netmod-rfc6991

Mahesh Jethanandani: There were some DISCUSS items brought up in IESG
review. There were also some comments brought up but these are
non-binding.

The first covers the typedef mac-address which the regex is potentially
incorrect for. Mahesh proposed two solutions, either fix the regex (or
use typedef phys-address) or clarify it in the address.

Lou Berger: I believe this is an inherited definition form SMIv2 we
shoulld review this. It says 802.1a and 802.5.

Scott Mansfield: These are old. MAC address is an interesting discussion
as in my opinion in YANG this is broken being defined as a string. There
will be a version of the 802 which will be a better reference to point
to for MAC addresses. I don't believe this is going to change MAC
address definitions.

Lou Berger: Is there a good YANG definition that we should be
referencing.

Scott Mansfield: No. There is a MAC address YANG definition in IETF and
IEEE and they are different.

Rob Wilton: It would be nice if we could use the IEEE definition but
this would cause us lots of issues. I think we should just clarify that
the MAC address is 6-bytes in this definition as that is what everyone
expects. Perhaps we can add a new 16-64 bit MAC address type in future.
I don't know how phy address is used vs. MAC address.

Balazs Lengyel: To me this looks like the IP address and the date. We
have IP address with range but no-one wants that or the date with a
zone. Perhaps we should concentrate on the main use-case.

Kent Watsen: We have run into patterns that are too restrictive in the
past. I am thinking for example, an email address. Ultimately we ended
up with somestring@somestring. The current pattern says that there is 6
colon separated tuples and maybe we make it n number of colon separated
tuples, less restrictive or we can come up with a union type of
mac-address-12, mac-address-64 etc and create a union type of these.

Rob Wilton: I think this was Balazs' point. This would make other types
that no-one wants to use. The reality is that no-one uses zoned IP
addresses. OpenConfig fix it, they made the change and moved on. In IETF
I tried to change it and there was concerns regarding backwards
compatability. I am opposed to making this less constrained.

Carsten Bormann: It is important to acknowledge that the names in the
YANG model are not the source of the meaning. Just because it's called
MAC address doesn't mean its a MAC address. It means that its a MAC
address as was defined in RFC2547 and we continue to use the name but if
we want to remain backwards compatible we have to accept that the name
is wrong.

Mahesh Jethanandani (AD): Can we have a poll here

Lou Berger: We are looking at keeping the same regex, changing the
description that says this is not a general type for all MAC addresses
but that this is specific for this use-case and means our normal 6 octet
MAC address.

Rob Wilton: We can reference that this is EUI48

(26:21) Poll 1: Can you accept if we just clarify the description
statement for mac-address?

Results: Good participation with majority Yes responses

Lou Berger: Reasonable participation, no objections --> Agreed to
clarify in description

Mahesh Jethanandani (AD): The second DISCUSS point from Orie is that in
the uri typedef we state "all unnecessary percent encoding is removed"
and the question is what is "unnecessary percent encoding"

Kent Watsen: I looked into this. It is really wrong/bad encoding or
double encoding. We should just delete this statement. It doesn't add
any value as it is expected that if we're encoding then this is done
correctly.

Rob Wilton: Are you allowed to write A as %65? Does that parse?

Mahesh Jethanandani (AD): I don't know, but let me talk about the
possible solutions. Orie provided some suggested text from RFC6531 that
says something about converting to A-labels and removing all U-labels.
The second option is just remove the text.

Rob Wilton: Are we trying to get a canonical URI. As in, are you allowed
to percent encode every single character in the URL or is that
unnecessary encoding or should we be using standard encoding unless it
is not possible.

Mahesh Jethanandani (AD): I don't know but the IESG reviewer is happy
with either approach.

Rob Wilton: My concern is that by removing the text you don't want to
remove that constraint.

Kent Watsen: I take that example as a security concern. Why would you
percent encode this anyway unless you were trying to hack it.

Rob Wilton: Generally in coding you are allowed to send the encoded form
of anything so this isn't necessarily an attack.

Lou Berger: I'd like to ask the shepherd and the AD whether they have a
recommendation on which approach to take.

(32:17) Mahesh Jethanandani (AD): My recommendation would be to remove
the text based on my discussion with Orie.

Cartson Bormann: This is about syntax based normalization of UIs. The
reference RFC6531 is misleading as that is about DNS names. I have no
opinion on whether this is needed but it is well defined.

Lou Berger: My personal view is, if this is valid then it is valid. It
is unimportant whether an implementation unnecessarily encodes, it's
still valid. This is not about this and therefore I am fine with
removing the text.

Rob Wilton: There are other examples in that file where it suggests
normalization of various types. I can't think of examples but IPv6
addresses are likely one. This is useful because if there is a key you
can compare them but if they have been normalized that may not work. If
there is a normalization concern here then I am against removing this
text. I think it should be expanded. If there is no normalization
concern then I'm happy for it to go.

Lou Berger: I think it's reasonable to say that the sense of the room is
that is it acceptable but if someone has some specific language (Rob?)
bring it to the list and evaluate it. Right now there temperature in the
room is that it's OK to remove this. If we hear nothing on the list that
is the way we'll go.

Rob Wilton: If we remove this text, are we going to remove the text that
says all case of characters is set to lower case.

Kent Watsen: That we'd keep for canonical format.

Rob Wilton: You will take out the bit about canonicalizing in one case
but remove this one. It's inconsistent.

Poll 2 conducted but not mentioned by voice so timing is unclear: Can
you accept removing the unnecessary encoding text?

Result: Reasonable participation. Approximate ratio of responses 2:1:5
NA:No:Yes.

(36:00) Mahesh Jethanandani (AD): This is the most contentious of all
the DISCUSS'. This is about backward compatibility of date-and-time. I
will not cover the discussion on the mailing list but please review it.
This draft states that the time offset is -00:00 which means it is UTC
and that the local timezone reference point is unknown. Later drafts
suggest using +00:00 offset and that Z is reported in UTC and that the
local time reference point is UTC. That is the background. We need to
debate the three options: 1. Do nothing, 2. Break backward compatibility
replacing -00:00 with Z and 3. keep the existing definition but
deprecate it and (optionally) create a new draft for all variation of
date-and-time with and without zones.

Lou Berger: If we choose option three and replace it, what do we replace
it with?

Mahesh Jethanandani: Nothing right now

Lou Berger: We usually leave it and replace it with a new draft that is
an update to this document that deprecates it at that point. This seems
confusing.

Mahesh Jethanandani (AD): I was taking the view that if you deprecate
it, you are not removing it and you're still able to use it.

Lou Berger: That seems to be confusing guideance. It would be be great
to fix it now but just deprecating something without replacing it is
confusing for people writing YANG models.

Carsten Bormann: There is a statement in the description that says this
is a profile of ISO 8601. This statement has not been true for 25 years.
You should at least remove this statement. If you decide to be backwards
compatible your would say this is different from the ISO standards.

Rob Wilton: I remember when I was an AD reviewing Carsten's document
when he was updating the date-and-time format. I raised some comments
about a NBC change to this format. Carsten's response was that we're
updating it to reflect what the rest of the world does and to make it
consistent with the OSI documentation. I think here we should do number
2, fix this and move on. You should still accept 00:00 but also accept
Z. We should treat this as a bug and move on.

Kent Watsen: I agree number 2 is the fix. Currently over the wire both
options are allowed it's just the canonical format. Do we dare to break
the backwards compatibility.

Rob Wilton: I brought this up earlier but OpenConfig just break
backwards compatibillity and move on and they are getting more adoption
of their models than the IETF.

Lou Berger: Shepherd and AD, how would you like to poll.

(43:49) Poll 3: Can you accept. Option 1 - no change?

Lou Berger: Very low participation. Fairly even split therefore there is
no consensus

Lou Berger: You are polling whether you can live with option 2. Not a
preference, can you live with it?

Rob Wilton: It is a bug. It's good to fix bugs.

(45:00) Poll 4: Can you accept option 2 - breaking backwards
compatibility

Lou Berger: Low participation. General sense of room is that it is
acceptable to break backwards compatibility in this case.

Chartered items:

03) YANG Versioning – Packages Update

Duration: 10 min (start: 46:56)
Discussion Leader: Rob Wilton
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/04

Rob Wilton: Update on the YANG packages draft. As a reminder there are 6
drafts in total. The first three drafts are in WGLC.

The next one is YANG packages. Presentation gives recap of decisions so
far.

Next steps proposed in presentaiont will write some example packages and
a package compiler to test them

Scott Mansfield: When you're doing this tooling, are you thinking that
you would provide a place to put instance data to help test this?

Rob Wilton: My plan is to write a compiler that you put a small
definition of what you want for the package and its dependencies and it
will generate a package file as JSON encoded using the file instance
data format that has been standardised. It should then be validatable
using standard tooling.

Oscar Gonzalez de Dios: I can volunteer, for the network service models,
to see if we can make a package out of them. Once you have this, what do
you plan to do with it?

Rob Wilton: Yes, I will do the network service models. I want to
understand what these look like. In terms of will they be published
somewhere, I don't know yet. In terms of doing and IETF packages
lifecycle draft this could be progressed. There is a lot more discussion
here first.

Balazs Lengyel: It would be very good if you could use a set of modules,
say from IETF YANG library, and use these to build a package definition.

Rob Wilton: Yes, this seems sensible.

Kent Watsen: I was thinking that Scott mean test vectors. I was looking
at the YANG package document, it has some examples, but not enough to
write tests against. Did I understand your point Scott?

Scott Mansfield: Yes. I just want to know how much work I need to do to
validate that the packages are doing what they are expected to do. If
there is extra stuff we want to add to the draft I would be willing to
assist.

Lou Berger: You were asking for encouragement. I encourage this work and
thank you.

Non-chartered items:

04) Report on Template Interims

Duration: 10 min (start: 58:48)
Presenter: Kent Watsen (as chair)
Reverence link: https://github.com/netmod-wg/template-reqs/issues

Kent Watsen: Provides update on YANG templates. Initial presentations
provided, requirements collected as GitHub issues.

Deepak Rajaram: Disagrees with the "strong support" response on
requirement 8.

Balazs Lengyel: Do you have other interims planned?

Kent Watsen: No, but we can if there is a desire for it.

05) Populating a list of YANG data nodes using templates

Duration: 15 mins (start: 1:09:02)
Presenter: Deepak Rajaram
Draft:
https://datatracker.ietf.org/doc/draft-rajaram-netmod-yang-cfg-template-framework/01

Deepak Rajaram: Before starting I would like to clarify what this
document is about given the interims and discussion on templates. This
document is not an alternative to the document detailed by Kent. It is
more of an information sharing item from the BBF.

Balazs Lengyel: As similar patterns are already in place in many places,
providing some guideance could be valuable.

Rob Wilton: I think we should not publish anything on this area but
instead should focus on the wider generic templates solution. I think
NETMOD should work on a single draft, a single generic solution.

Kent Watsen (Chair): The working group is not going to adopt this draft.

Deepak Rajaram: Are we going to get involved in doing the groupings.

Lou Berger: I'm sorry, I don't understand the question.

Deepak Rajaram: Are we going to create some groupings or let BBF do it.

Lou Berger: I heard from Rob and I agree that we should not be working
on this. I don't see the value of working on separate template work that
is not part of the template solution.

Deepak Rajaram: Do we (IETF) have a concern in BBF writing groupings?

Lou Berger: We cannot propose or stop them. If you think we should send
a liaison to BBF then we would ask for proposed text.

Kent Watsen: Your question was I think, do we have a concern and the
answer is we do not because they are a different SDO.

Xueyan Song (BBF lisison officer from ZTE): Thanks for the efforts of
NETMOD on progressing the scalable YANG definition to support large
scale network element management. For the BBF questions it was included
in the BBF liaison 666 so I agree with Lou that if there are other
questions or concerns from Nokia or other companies then it doesn't stem
from the BBF.

Robert Peschi: Co-author of the draft. I want to repeat that this
document just says what we are willing to do in BBF. We do not want to
compete. It is just giving you advice on how to use YANG to get better
scalability.

[out of original order to accomodate IANA representatives]

07) Adding Errata to IETF YANG Modules

Duration: 10 minutes (start: 1:24:22)
Presenter: Balazs Lengyel

Swapped agenda order because we have IANA in the room.

Balazs Lengyel: Details the issue that erratas correct issues in drafts
but the updates don't get pushed into the YANG model. IANA would like a
clear process for this and should we show only the latest updated YANG
model or all historic ones.

Mahesh Jethanandani: As part of trying to make updates to YANG models
there is an easier step and we should think about how to do it. I would
like some clarifications: the first step talks about verified errata,
that is two choices, technical and waiting for document update. Is the
ask that this be applied to both or just technical?

Kent Watsen: I spoke with the RFC editors yesterday. There is an idea of
adding a third button 'verified with WG consensus' which is not just the
AD deciding consensus but this would have to go through another poll or
something similar.

Mahesh Jethanandani: Relating to this I suspect there would be a link to
the consensus poll?

Lou Berger: To be clear, WG consensus would be owned by WG chairs not
AD?

Mahesh Jethanandani: Yes

Kent Watsen: Sometimes erratas happen when WGs no longer exist. There
needs to be a way to verify errata without WG consensus.

Lou Berger: I was assuming that verified with WG consensus is the only
way you would get the module updated. What happens when the WG is not
more?

Balazs Lengyel: You could use the OSAWG?

Lou Berger: You might want the AD of the area to make the decision. We
want the WG that is most knowledgable of the material that the YANG
module covers to own that.

Balazs Lengyel: In the erratas today we sometimes have the statement
saying to be corrected in the next RFC. If the change is major/technical
then the correct way capture this.

Mahesh Jethanandani: That is the reason I was a little hestiant. Where
do you draw the boundary between errata vs. document update but Kent
suggests the third button is the way to solve this.

Kent Watsen (Chair): I know you have slides to discuss the process but I
don't think we should discuss this right now. There is a request for it
to be an RFC. What we're discussing now, this extra buttons, all
previous AD's had concerns about verifying technical erratas so the
thinking is if you get WG consensus then the WG has signed off that this
is truly a bug. Also, the old YANG module is still available even though
it isn't linked on the page.

Mahesh Jethanandani: When you pull it down you get all the revisions of
all the YANG modules.

Benoit Claise: Who approves the model. I would say the AD, based on the
community feedback which could be YANG doctors, the WG, the other area,
whomever. Where to document this? Why don't we just trust the AD as
they're going to ask the right person anyway. There is common sense, if
there is a bug, the AD asks the right person and says yes. Is there
really a need for an RFC to get this done.

Lou Berger: Are you asking if we need an RFC for the process?

Benoit Claise: For the process.

Lou Berger: I strongly believe we do. We have had informal things get
lost in the past. I think we need an RFC for this. If we are giving
guideance to the whole IETF then we have to have an RFC.

Benoit Claise: Lets agree to disagree

Rob Wilton: I agree with Benoit, it should be the AD that approves the
errata. I think this idea is fine. I always held for document update
because I was always told that you shouldn't have two versions of a YANG
module with different content and the same revision date.

Kent Watsen: We're not taking away the AD doing the approval, we're just
trying to find the mechanisms the AD has at their exposure to confirm
consensus.

Rob Wilton: If you're trying to find a way to distribute the work then
I'm happy with it.

Lou Berger: The process you are envisioning is that the WG approval
woudldn't do anything until the AD approved it.

Kent Watsen: Right now, most erratas are being held for document
approval and we'd like to change that.

Mahesh Jethanandani: I would like to get to the tools question. Are we
going to give IANA a complete YANG module, I don't want them to have to
go through all of the edits to validate them all. The expectation is
that when the module goes to IANA it is complete.

Balazs Lengyel: You're saying that even minor updates would go through
the WG not IANA?

Mahesh Jethanandani: That is what I would like to discuss

Balazs Lengyel: Can we trust IANA to do trivial updates or give them a
full file?

(1:42:21) Dean Bogdanovic: If the text in the document is not changing
in the RFC and there is some change in the YANG implementation, having a
review by the YANG doctors saying the text is still matching the YANG
code should in my opinion be enough to approve the change for the AD.

Mahesh Jethanandani: I just talked to the IANA editors and their
preference is to always get a complete file.

Rob Wilton: I see this as a special process for YANG modules. Kent
mentioned that you would like to see this more broadly and I think this
is something for the IESG.

Kent Watsen: Yes, this is what I meant. I think the IETF should consider
it.

Balazs Lengyel: I am ready to work on this.

(1:44:38) Lou Berger: We look forward to seeing a draft on this.

06) DTNMA Application Data Model (ADM) YANG Syntax

Duration: 20 minutes (start: 1:45:07)
Presenter: Brian Sipos
Draft: https://datatracker.ietf.org/doc/draft-ietf-dtn-adm-yang/03

Brian Sipos: Presentation on Delay-Tolerant Network Management
Architecture (DTNMA) and creation of a new DTNMA-YANG.

Mahesh Jethanandani: You said that you're not asking NETMOD for anything
but you are telling us what your working group is going to do but there
seems to be a suggestion that you are planning on developing another
data modelling language within IETF for this use case, is that right?

Brian Sipos: Not a language no, there is a different domain and
different things in that domain and we'd like to use YANG as a modular
language to define those things. There are other approved uses of YANG
(examples on slide RFC8040 and RFC8791) and I don't see this as being
much different.

Lou Berger: I heard the answer as no, but we are. I don't think there is
a parallel between the NMDA and different datastores and what you are
doing. Here I see a fork of the language and very different usage and to
me it is outside of the scope of this working group.

Brian Sipos: I think it is outside of the scope in that there is nothing
for NETMOD to do. My question is, what alternative do we have? We would
like to leverage the definition and tooling we have.

Rob Wilton: Thank you for presenting here. I reviewed the DTNMA document
at the time and had some concerns at that time and this gives me more
concerns. I think if you look at RFC7950 it is explicit about what an
extension can be and cannot be. They cannot change the meaning of the
language. A compiler is allowed to completely ignore the extensions and
still have the same meaning as if the instructions weren't there. I do
feel that this doesn't relate the same way as the sx structure example,
that was extending the language to make it more useful by the
configuration protocols for YANG. What you're saying is we're taking
parts of YANG and adding/removing bits as appropriate which will lead to
a fork in the language which will cause confusion in the industry. We
need to be really careful before going down that route.

Brian Sipos: The feedback that would be really valuable would be what
things would make this more straight forward. Do we register a different
media type, do we have a different file extension?

Lou Berger (Chair): Speaking as chair, what would be most helpful is
what can you not do in the current language. What is the problem you are
trying to solve that cannot be solved with the current solution. If the
list is a long list then perhaps YANG isn't the right approach.

Brian Sipos: The original goal was to use SMI with ASN1 and modern
syntax and that is YANG.

Rob Wilton: Lou made a comment that this is out of scope for NETMOD but
I think in this WG we care about whether a fork of YANG is created
within the IETF space.

Lou Berger: Yes, we care very much about that

Ed Birrane (Chair of DTN working group): We presented this material once
before at NETMOD and had many requests for assistance over the years to
try to find the correct way forward. There is no intent in our WG to
create a fork of the YANG language or to create things that are
confusing. We eanted to present here to understand the concerns and to
request help. This sounds like the beginning of a good set of
conversations.

Lou Berger: I think this is the beginning of the conversation and the
next step is can you provide what is not solved by what you have in YANG
today.

Dean Bogdanovic: YANG is a structured language but the author is saying
I don't want to use that structure but I want the name. I fully agree
with Lou, if you have a long list of things we cannot solve then create
a new lanuage:

Lou Berger: Ed, if you or Brian can post to the NETMOD list the list of
things that cannot be solved today (not the list of solutions)?

Ed Birrane: Absolutely.

Adjourn: (timer 2:05:11)