https://datatracker.ietf.org/meeting/120/materials/agenda-120-netmod
https://datatracker.ietf.org/meeting/120/session/netmod
Monday, 22, July 13:00-15:00 PDT (20:00-22:00 UTC)
Lou Berger (lberger at labs dot net)
Kent Watsen (kent plus ietf at watsen dot net)
James Cumming (james.cumming at nokia dot com)
Notes: https://notes.ietf.org/notes-ietf-120-netmod?both
Slides: https://datatracker.ietf.org/meeting/120/session/netmod
Zulip (chat): https://zulip.ietf.org/#narrow/stream/netmod
Drafts (TGZ):
https://datatracker.ietf.org/meeting/120/agenda/netmod-drafts.tgz
Drafts (PDF):
https://datatracker.ietf.org/meeting/120/agenda/netmod-drafts.pdf
Datatracker: https://datatracker.ietf.org/group/netmod/about/
ICS: https://datatracker.ietf.org/meeting/120/session/33074.ics
Recording: http://www.meetecho.com/ietf120/recordings#NETMOD
YouTube: https://www.youtube.com/watch?v=Eif38uoHynA
Jabber Logs: https://www.ietf.org/jabber/logs/netmod
Presenter: Chairs
Slight agenda reordering: The authors of the Common Interface Extenstion
and Subinterface VLAN YANG have asked to defer this presentation.
Additionally the YANG module file naming draft is moved up in the agenda
as it is a spin-off from the YANG versioning work.
The Common YANG datatypes draft (draft-ietf-netmod-rfc6991-bis) has been
stale for some time and we would appreciate someone from the WG
assisting with progressing this one. If you are interested in helping
out as an editor please contact us.
Mahesh Jethanandani: This has been on the AD queue for some time (400+
days) and I would appreciate some help from someone to progress this. It
think that a lot of the comments made on the document seem to have been
resolved so this should be a fairly easy process to get this over the
line. Additionally regarding common interface extension and sub
interface VLAN YANG draft is stale, what is the status.
Scott Mansfield: The plan is to refresh these. There are almost no
comments and so I believe this should not be much work. I'm hoping to
find more time during this next month.
Chairs: Do you think it would be possible have last call in September?
Scott Mansfield: I believe so.
Lou Berger: There is a list of post last call documents. I have one
document that is now ready for publication and sometime this week I hope
to submit that one. There are a couple of others that are waiting on
authors. One of our favourites is the syslog draft. Kent would you like
to comment on this draft?
Kent Watsen: I believe the dependency is resolved. It's a matter of
regenerating the examples and tree diagram.
Joe Clarke: We updated it after the latest update to the TLS client
server drafts in March so it should be ready to go.
Lou Berger: We have one incoming liaison. We will hear about this on the
agenda.
Lou Berger: We have a process change. At the time of the ID cut-off, we
would like all authors to provide either a status update to the list or
a meeting slot request. We would like not to wait until the meeting for
that update so we give time to the WG to consider the status and decide
whether they want to contribute.
Lou Berger: Does anyone have anything to bring up that was not on the
agenda?
Tim Carey: What is the update for the best practices document and
node-tags document
Lou Berger: Best practices - I do not recall and will have to come back.
Node tags, the document had tepid reception and we asked for more
feedback and asked for last call and heard nothing. The chairs believe
there isn't sufficient interest therefore. If more interest comes we can
bring it back.
Presenter: Joe Clarke
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-12
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver-17
Joe Clarke: On behalf of the authors and contributors who get on a call
every Tuesday to discuss YANG versioning. We are making good practice
towards a new version. We presented back in IETF 119 and got some
feedback specifically from the chairs. We consolidated the documents
back and brought a new versions and updated the list with a summary of
the changes. We asked the chairs to call a new WG last call. We had text
re file naming in the document and we decided to pull this out due to
lack of concensus but it has been split out into a separate draft which
Per will present today. What did we change? In YANG module versioning
-12 we did minor clarifications and changes, specifically we explicitly
states that this work is for YANG 1.0 and 1.1. For the semver draft (in
versions -16 and -17), we clarified how you might change the versioning
in a sub-module in relation to the main module and we added some text
that explains the reason why people may wish to skip versions. We sync'd
the text in the YANG models themselves with the text in the draft. There
were a lot of editorial changes around the document but we think it adds
a lot of clarity. We would like to kick off a (last) WG last call and
hopefully address these comments.
Presenter: Per Andersson
Draft:
https://datatracker.ietf.org/doc/draft-andersson-netmod-yang-module-filename-02
Per Andersson: We have brought file naming back from the versioning work
as an experimental draft to investigate if this is a good standrda to
have and to document existing industry usage as this is used already in
some proprietary tooling already. The solution is to allow the current
schema with an @ and the date and to allow a new schema with # as a
semver delimeter. This draft is as a result of the WG requesting that we
address this specific issue. There was a successful hackathon project in
IETF119 to add this support to pyang. Next steps are to adopt the draft.
Lou Berger: A couple of things. Our reading of the document is this is a
spin-out of the semver document. Is this correct?
Per Andersson: Yes
Lou Berger: We don't believe adoption is necessary as this was spun out
from an already adopted document. The more substantive question is can
you explain why this is experimental rather than standards track?
Per Andersson: This was discussed and decided to show how this could be
used as there was some contention around changing the YANG filename as
said from RFC7950 and it would update this document. That hit some
obstacles.
Lou Berger: Is this a negotiated extension, correct? It won't cause a
compatibility issue because it's a negotiated extension is that correct?
Per Andersson: It's up to the server or the tools to read the file. The
big issue is to evolve all the tools in the industry. If I were to
publish with this filename maybe half the industry can't consume them
with their tools. This is the big issue I believe.
Lou Berger: We should hear from the list but one thing to keep in mind,
an experiment has a defined process, a specific duration and a set of
expected results. By the definition of how an experiment is defined
today this is not a candidate for an experimental draft.
Per Andersson: The experimental process is new to me. I tried reading up
on it and I thought it fit the bill. This was discussed in the
versioning group.
Lou Berger: My view as one co-chair (I haven't asked Kent this) take
this to proposed standard and last call it and see where this ships
fall. Lets have a discussion but experimental is not the right place.
Mahesh Jethanandani: I had the same question as Lou. Why experimental
and not a proposed standard. To cover a question, Andy Bierman asked on
list, is this the name of the file or another verisoning scheme and is
this backwards compatible with YANG 1.0 and YANG 1.1 specifications. Is
it the name of the file or another versioning scheme inside the file.
Per Andersson: Its the filename only
Lou Berger: Is it backward compatible?
Per Andersson: It depends on the tooling.
Kent Watsen: It is backwards compatible as it maintains the existing
file naming strategy. It is still supported right?
Per Andersson: Yes
Rob Wilton: If I remember correctly the reason we spun this out is that
there was reticence when we were doing WG last call of the other
documents as to whether this was acceptable or not as there is opinions
on whether this is backwards compatible or not. I can see two views. The
one being expressed here is that we're keeping the old naming scheme and
introducing a new one so no existing tools break but by introducing the
new naming format tools that are using versioning might start exporting
files in this new format and provide them to client rather than using
the revision dates they were using before. This could break tools
(although a fix would be trivial) and therefore we pulled this out into
a separate document. It could be part of YANG-next but that might be
some way off. The reason we picked the experimental flag is that this
would be showing where the industry would be going. Also I think it
should go WG LC and see where it goes as standards track.
Reshad Rahman: Are we going to do LC for the three docs together then?
Kent Watsen: Yes
Italo Busi: I am also in favour of experimental because having two
naming rules can be a source of confusion. How can I say that two files
with different names are the same model. I think an experimental helps
us understand which are the names we're experimenting with and which are
the main names. This is an experimentation as we could test it ahead of
YANG next and adopt this as the only naming scheme for the new YANG.
Per Andersson: It is recommended not to use the same YANG Module with
multiple filenames - use either old @ or the new #
Italo Busi: Yes, but you have different repositories and different
implementations and this is where you get confused.
Andy Bierman: I suggested this should be experimental. The YANG 1.1 RFC
says this MUST be the way the filename looks. I am concerned about
putting new standards out there that say forget what that standard says,
now do it this way. If you say this MAY be done another way you force
all tools to accept that as well. There are complexities with seeing
many filenames together in search paths. There is issues there. I think
this is fine for YANG or experimental where it's definately not
overwriting YANG 1.1
Kent Watsen: Is there a way for this document to conform to the
experimental rules?
Lou Berger: If we go with experimental we may as well abandon this work?
I don't think experimental is a viable path for it.
Kent Watsen: Are we able to make the document conform to experimental
Lou Berger: Looking for AD support but I believe the experimental is
design to define what the experiment is (and what success looks like)
Per Andersson: The experiment was also successful last IETF hackathon
Rob Wilton: I agree you may struggle to have the IESG agree that this is
experimental. You could potentially go informational as another choice.
It's tricky and I do get Andy's point about existing tooling. We should
do this standards track or wait until YANG next. Anything else is just
muddying the waters.
Lou Berger: What occurred to me when looking at the ABNF you could make
the revision date required so you MUST have the date and MAY have the
semver
Rob Wilton: Tools would still do a regex match on the file and would
still fail. The tooling would have to change
Lou Berger: The way forward is make it a proposed standard, WG document
and go to last call [for all three documents] and see what happens.
Presenter: Qiufang Ma (remote)
Draft name:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-08
Qiufang Ma: Proposal from the authors is that the entire referenced
system node (the entire list entry) into the running configuration with
all descendants. The second issue is to do with things like user-ordered
lists and leaf lists when merging. The authors believe we shouldn't
define what merge means. The last issue is the impact of resolve-system
parameter on the candidate/private-candidate datastore a client may add
it without expecting it to be valid. The resolve-system parameter may be
used in edits to candidates/private-candidate, in validate and in
commit. Next steps, request the WG to review the updates. Given a lot of
change the authors are unsure whether this needs another WG last call.
Rob Wilton: I reviewed in last call. I will re-review. I don't know if
the document should say what the merge requirement is but we cannot
leave it vague. It may be that this picks up the behaviour from NETCONF
or it may need to be defined here but we can't leave any ambiguity.
Lou Berger: Our intent is to do another WG LC
Presenter: Qiufang Ma (remote)
Draft name:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-02
Quifang Ma: Requirements for this draft come from the TVR working group.
Next steps, would like to request WF review and would like to ask for
early yangdoctor review. We would like to target last call before the
next IETF meeting. We wish to move forward fast so as not to block
consumer drafts.
Kent Watsen: Chairs requested YANG doctor review this morning.
Mahesh Jethanandani: This might be a process question. Is TVR WG
chartered to define the YANG module for timing? This draft defines the
YANG grouping. Why are these not merged? Is there a reason to keep them
separate?
Quifang Ma: The TVR working group is chartered to define the scheduled
change of the network attributes. This is specific to the change of
network properties but there are other use-cases. There are a number of
documents that would use this due to different scheduling use-cases.
This is why we wanted to split this into common groupings to use as
building blocks so other usecases can build on top of these groupings.
Presenter: Qiufang Ma (remote)
Draft:
https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag-01
Mahesh Jethanandani: There was a joint meeting between 3GPP and IETF
today. This draft was discussed. 3GPP would like to know when this
reaches a level of maturity that a 3GPP liaison be sent. I'm asking the
chairs for this.
Lou Berger: We can issue one immediately to say this work is underway.
Saying 'this work is done' will require us waiting until at least WG
last call. Which one do you feel is more valuable from an inter-SDO
perspective?
Mahesh Jethanandani: I think once WG consensus is reach this would be
the right time
Charles Eckel: This came up in the coordination call because the liaison
statement was received in March of 2023. They provided some
requirements. If IETF are covering their requirements then perhaps the
liaison isn't needed? It might be good in parallel when going to WG last
call it might be good to send them a liaison to ask if this is meeting
their needs before going to RFC.
Lou Berger: Typically we have not taken specific requirements/actions
from liaiasons. We would expect contributions inside our process. I'm
not sure we would want to send a liaison saying 'have we taken your
requirements into consideration'? This seems like an IAB issue and a
little different from our normal process.
Mahesh Jethanandani: I would agree that this approach is rather
undefiend. If 3GPP need to provide comments to the draft they should do
it now. If they are looking to provide comments they should come to IETF
or comment on the list. My idea is that we would give them a liaison
with a status update when the draft is mature.
Lou Berger: If we're really looking for their input we send it now and
say that if they would like to provide input they should provide using
the standard IETF contribution approaches
Rob Wilton: There was a similar approach in another WG and the liaison
said "the IETF last call has started it will end on this date and you
need to provide comments using the normal IETF mechianisms and here is a
link to the list".
Lou Berger: Looking for a volunteer to draft a liaison statement
Mahesh Jethanandani: I'm not volunteering but are you looking to send it
WG last call or now?
Lou Berger: We should have the text ready to go no matter whether we
send it now or at WG LC. When we draft the liaison text we make the
decision then whether to send it immediately or at last call. Rob are
you volunteering? Rob is definately going to volunteer.
Quifang Ma: The authors of this draft will help as well.
Presenter: Jean Quilbeuf
Draft:
https://datatracker.ietf.org/doc/draft-jouqui-netmod-yang-full-include-02
Rob Wilton: This feels like this is a major change to the YANG language
so I think I would prefer to see this in YANG next. More general
concern: are we making YANG language too complex? When we were doing the
YANG packages work we were looking at something like schema mount to
define something similar. One complexity that might be glossed over here
is that if those modules may have other
augmentations/deviations/features defined. Perhaps YANG packages could
define a package which resolves to a schema and then embed the package,
this might resolve these issues? Last comment, using a sub-tree could be
helpful/useful particularly thinking around YANG push use case.
Jean Quilbeuf: For augments and deviations, they should be specified in
the embedding point.
Rob Wilton: In case of features? Would you be allowed to have different
augmentations/deviations for it mounted below rather than when defined
elsewhere?
Jean Quilbeuf: Yes, they would be in your YANG library and you could
even use different revisions from the main root import, you could have a
completely different YANG library for the embedded part for the runtime.
For the design time the exact set of modules is what you would have in
the mounting point.
Olga Havel: This think this is quite useful. I think for your use-case
not having the finer granularity is great but I can see some use-cases
where the sub-tree would be useful.
Deepak Rajaram: Interesting presentation. Wanted to highlight that the
usecases required by BBF will be covered by upcoming presentation. In
IETF 119 there was a question about having more granularity in embedding
modules beyond prefixes. Is this still being looked at? Is this part of
the module or can we customise them? Can we refine certain data nodes.
Jean Quilbeuf: It is still considered, it is a nice to have feature. I
would like to do the implementation with the whole module before going
to the finer granularity.
Deepak Rajaram: Including the refinements of nodes or is it just
sub-trees?
Jean Quilbeuf: Perhaps we should separate the features but I can see a
use for this
Reshad Rahman: +1 to what Rob said. I think YANG next might be the right
place. You mentioned augmentations would need to be specified
explicitly, what about deviations, is this automatic?
Jean Quilbeuf: I would say the same. Perhaps deviations should only show
up in the YANG library part rather than in the YANG module. You could
put a deviation into your set of modules but thats a little weird.
Reshad Rahman: I found it off that the deviation would be automatic in
the normal path but not in the embedded
Lou Berger: Rob mentioned YANG packages might be used to solve this.
YANG packages is an adopted draft and has broader utility. If it is
possible to combine these we should explore this. As chair, I'd like to
ask that before you present this again and before the next meeting if
you can work offline with the YANG packages authors to see if you can
combine this or use this. This would help the group if you could help
move that draft forward.
Jean Quilbeuf: Yes, I will look into it
Presenter: Oscar Gonzalez de Dios
Draft: https://datatracker.ietf.org/doc/draft-ovmd-netmod-dmanm-00
Italo Busi: Have you thought about how to merge potential conflicts
between the configuration done to the network model and configuration
done to the device model and you may configure two things that are
incompatible from each other
Oscar Gonzalez de Dios: It is the controller who will be responsible. I
am not exposing the model in the device outside just which device model
there is
Italo: What if the configuration on the device is not compatible with
the network.
Oscar Gonzalez de Dios: You will reject
Italo Busi: There is two intents?
Oscar Gonzalez de Dios: No there is one intent. If you change later with
another intent it will be out of sync and fail. That is common to any
network device model.
Italo Busi: On the same interface here you have two ways to configure
the same thing. For example I configure a tunnel at the network level
saying this is my path the tunnel implements a static LSP and you go to
the device and you change the path of the LSP which is the path of the
tunnel.
Kent Watsen: Can we take this to the list
Alexander Clemm: Why is this not part of network inventory
Oscar Gonzalez de Dios: This is even for network inventory
Alex Clemm: Why not? You want to group the devices in your network, this
is what network inventory does?
Oscar Gonzalez de Dios: It could be. The main point of this draft is to
be able to configure something in a group of devices and this something
is defined in a device model. This is the main point of the draft, The
inventory input could be a group of devices
Alex Clemm: OK - I will reread it
Lou Berger: There is good opportunity for discussion on the list
Joe Clarke: I will take it on list because I don't really understand the
use-case. Why do you need this, can the controller not figure this out?
Oscar Gonzalez de Dios: In the controller you need some structure. You
just need the deployment structure
Joe Clarke: Will follow up on the list
Olga Havel: Is there any other mismatches between northbound and
southbound keys (such as NE-ID)
Oscar Gonzalez de Dios: Southbound I don't care
Olga Havel: Yes but at design time there are different keys and IDs
Lou Berger: We should discuss more on the list. I don't know if there is
interest, but there is confusion.
Ali Tizghadam (Zulip chat): What is the differentiator between this
draft and open-config?
Quifang Ma (Zulip chat): +1 to align with inventory ne-id
Jan Lindblad (Zulip chat): @ali, this work is for the controller/network
level, not device level
Mahesh Jethanandani (Zulip chat): My take on Oscar's presentation is
that there is an operator requirement of exposing device level config at
a network level. Let us help him in by understanding the use-case and
let the experts in YANG come up with a solution.
Qin Wu (Zulip chat): @Ali, are you referring to device model, IETF used
to have similar work in rtgwg,
https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-device-model-02
Presenter: Kent Watsen
Draft: https://datatracker.ietf.org/doc/draft-yn-netmod-rfc7950bis-00
Draft: https://datatracker.ietf.org/doc/draft-yn-netmod-yang-xml-00
Kent Watsen: YANG-next presentation
Jeff Haas: For the design team question, a middle model. DT driven by
the WG. Delegating out designated pieces of work to individual
contributors.
Mahesh Jethanandani: You indicated your preference for YANG 2.0. Some of
this work seemed to be YANG 1.2 such as stripping out XML. My other
comment is that we could give Github a try.
Kent Watsen: I think GitHub isn't a first for the IETF. I believe QUIC
tried it NETMOD hasn't.
Mahesh Jethanandani: Was the feedback positive/negative from QUIC?
Kent Watsen: Positive I believe
Lou Berger: For YANG 1.2, to clean up a document we don't need to change
the revision number. We can make editorial changes. There might still be
room for 1.2
Rob Wilton: To comment on the github process. The outcomes were some of
the best I've seen on the IESG as they had many contributors being able
to work together. Thanks for starting this work. It is important that we
sort out a documentation set to start with. I think making YANG 1.1
updates are worthwhile. We might want to do YANG 1.2 as well as YANG 2.0
as well. Last comment, we should use the issues to work out the scope to
see if this is a YANG 1.2 or YANG 2.0. We should have a vision of where
we're heading for either YANG 1.2 or 2.0.
Kent Watsen: For YANG 1.2 I haddn't thought about this. For YANG 2.0 my
thinking is this is driven by individual interest. Once all the PRs on
GitHub are complete we could then bring it to the WG. We could bring
each pull request to the WG. If say 25% of the issues didn't get
resolved then the WG might request that 10% more get resolved then the
question is who is volunteering to do the work.
Rob Wilton: What I'm thinking is a what is YANG 2.0 architectural
agreement of what YANG is trying to achieve. What features/markets is it
going to address.
Kent Watsen: If we are to move forward we could put together a paragraph
on the motivation of it.
Reshad Rahman: Would YANG versioning work be part of YANG next
Kent Watsen: Yes. It would be an attempt to consolidate the specified
requirements.
Lou Berger: Kent is not saying we stop the ongoing work though. This
work would be rolled forward as well, it is not an alternative.
Reshad Rahman: The design team vs. GitHub seems to be an either or? We
used GitHub to identify what work needed to be done. The DT used it. I
don't understand why it is one vs. the other rather than a combination
of the two?
Kent Watsen: The design team could certinaly use GitHub as a tool. Are
we going to archiect everything upfront and workout the requirements up
front or is this going to be more of a waterfall approach.
Thomas Graf: This is good work, dividing XML and YANG into different
documents. I think YANG 1.2 being smaller changes and 2.0 being larger
changes is a good proposal. About requirements, where would these come
from.... Do these come from the IAB workshop?
Kent Watsen: Great question. We may need to talk about which working
group this would be covered in. NETCONF would cover the protocol
requirements. Perhaps the AD has a comment on this.
Jeff Haas: Has there been a triage activity to try to put these items
into buckets.
Kent Watsen: Yes, there is a github project but we didn't get through
them all.
Jeff Hass: Great - I will look at the existing work. If you can come up
with some common rules, for example, if I want a new datatype what
should it look like and what rules should it follow. This is another way
to ease the workflow.
Andy Bierman: I don't see a lot of end user value in republishing YANG
1.1 and I hear nothing from customers on this. We should work on getting
a DT up and running. If we cannot get consensus on what new features
we're doing then we shouldn't bother. Redoing YANG 1.1 doesn't serve the
community at large, only the IETF. We should go through the list to
identify consensus. I don't like the idea of changing the working group
consensus approach to an opensource project model. There hasn't been
enough energy to go through the current issues list.
Kent Watsen: I volunteered to review this both in GitHub and in side
meetings. I have lost energy. There was pushback and concern that any
change would be detrimental to the industry. I believe now is a good
time and I have renewed energy so I think we should address this.
Mahesh Jethanandani: People are missing the list of issues, perhaps a
reference to the GitHub location would be helpful. We have lots of
requirements, I don't know if we need any more or a meet up to discuss
any further.
Kent Watsen: I agree that we have a good list and this is I believe this
is the distinction of the two approaches. With the other approach we
don't have to create lists. If people want to submit a pull request they
can. The intent back there was to categorise things on backwards
compatibility, complexity and importance but if we go to the bizarre
approach it actually doesn't matter, it's up to the individual to see
what they want to self-prioritise.
Lou Berger: To close (We're out of time). There is interest in talking
about YANG next. There isn't clarity on what the group would like to
achieve on this. Kent, can you put together a list of motivation and
objectives and we can discuss whether we need YANG 1.1, 1.2 or 2.0. We
do not need to change our consensus process to use Git. We can be more
agile and just bring resulting documents back to the WG for review.
Qin Wu (Zulip chat): synergize with IAB workshop and get requirements
input from there will be great.
Thomas Graf (Zulip chat): I asume it is this:
https://github.com/netmod-wg/yang-next/issues correct?
Mohamed Boucadair (Zulip chat): I guess
https://github.com/netmod-wg/yang-next/projects/2
Jan Lindblad (Zulip chat): @thomas, @med, the issues list pointed to by
Thomas I think we can consider current. The project board is from 2019.
Presenter: Xueyan Song and Deepak Rajaram
Draft: https://datatracker.ietf.org/liaison/1935/
Deepak Rajaram: There is a problem configuraing ONUs and ONTs with
something like 30,000 interfaces. Problems with validation time and size
of configurations. Templates might be a solution as many configurations
are identical.
Lou Berger: We are out of time but thank you for sending the liaison and
thank you for the slides. It sounds like you have some recommendations.
Please can you submit a draft on how we should structure YANG models
than can you put this in a document and we can progress this in the
IETF.
Time remaining: 0 minutes
15:03hrs Close
Note Takers:
James Cumming