Attached are draft minutes from the NETMOD WG sessions at IETF 96 (Berlin).
Lou and I scrubbed the minutes from the session recordings. Please review
them and send any corrections you’d like to see to us before a week from
tomorrow (Sep 2nd).
Thanks,
Kent (and Lou)
Minutes for NETMOD WG Sessions at IETF 96 (Berlin)
==================================================
Session 1: MONDAY, July 18, 2016
1540-1740 Afternoon Session II
Room: Schoeneberg
Video:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_NETCONF&chapter=chapter_1
Audio:
https://www.ietf.org/audio/ietf96/ietf96-schoeneberg-20160718-1540.mp3
Session 2: TUESDAY, July 19, 2016
1620-1820 Afternoon Session II
Room: Tiergarten
Video: https://www.youtube.com/watch?v=lp_NrYAQT10
Audio:
https://www.ietf.org/audio/ietf96/ietf96-tiergarten-20160719-1620_04.mp3
Session 1: (Monday 2-hours)
===========================
* 10 Min: #0 Intro & WG Status (Chairs)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-0.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-0.pdf
Benoit Claise presenting:
Been working on yang 1.1. ietf-library. opstate.
We have been working on the opstate document. Difference between intended and
applied.
"Solved" in yang module design. Discussing revised datastore concepts.
Issue in this SDO is we don't publish the work as RFCs fast enough.
We've been waiting on opstate (document)
No explicit support to support applied configuration.
What do we do with counters? -state or not. Should not leave room until we
have guidelines for all of IETF. This is a primary achievement for today.
What do we do with counters - into state or an open branch? Open issue.
Shouldn't leave room until we get guidance to give the rest of IETF.This is a
primary achievement for today.
# of yang modules in RFCs. We're hitting an inflection point. Need to have in
a year from now many modules in RFC. If not,
Should just stop doing yang modules in ietf - if we don't publish them as RFCs.
Declare victory on protocols and encodings; it'd happen elsewhere if we didn't.
Timelines (where we should spend our resources):
- schema mount down as fast as possible.
- Need solution by the next IETF. (this is 2nd highest priority)
- Must also progress ietf rtg module. 40 different modules depending on that.
- Progress all yang models that do not depend on mount.
Q&A for Benoit:
Rob Shakir: Push out all those RFCs. From user perspective, do they work
together? We need to be able to interact and configure things. Would be
happier with a few RFCs that work together.
Benoit Claise: Changed procedure with yang doctors. Asking all chairs in ietf
to proactively review modules; should be working together. Primary place this
needs to be fixed is routing. That's what the RT design team is for. Find it
unlikely we'll have perfect data models on day 1. Must think about how we
iterate the models.
Rob Shakir: need to focus on versioning and how things work together (e.g.
model-catalog). From OC modules, we're about to hit v3. Making backward
*in*compatible issues on a regular basis.
Benoit Claise: We've been receiving yang modules from other places.
Michael Abrahamsson: Trying to reconcile among 4 vendors what the common
elements are to go into a model. As a vendor want to standard models that can
map to many vendors equipment.
Lou Berger: Important and helpful for users to stand up to say what belongs in
the model.
Dean Bogdanovic: We should be classifying modules and not models. Can be
classified many different ways in models. If we focus on modules, it'll be
clearer.
Andy Bierman: Wrote a yang conformance document. Unit of conformance of a
module isn't that useful. Want to identify modules that work together. Need to
rethink rather ... conformance model in yang? Especially when we're not
following the rules. His concept of yang pakcages of things known to work
together. Thus you can move to things that need to change all together.
Ladislav Lhotka: Been pushing progress in rtg modules for a while. Now that
yang 1.1 is looming, do we want to change existing modules to conform to 1.1,
or do we stick with 1.0 for these modules?
Benoit Claise: What do operators in room think?
Dean Bogdanovic: Last time we discussed this and agreed that drafts not in pub
queue should move to 1.1
Benoit Claise: This is what I remember as well.
Ladislav Lhotka: If we're trying to publish stuff asap, then moving to 1.1 may
further delay things.
Benoit Claise: confused, because I thought we discussed this
Lou Berger: Expected you (BC) to say that we took this decision before and that
YANG doctors will enforce it (all YANG modules to now be 1.1)
Benoit Claise: Thought this was already decided.
Ladislav Lhotka: Expect moving to 1.1 will likely break the checking tools we
have deployed.
Benoit Claise: first, we already check 1.1. If there's a tooling issue, that's
a different issue than the modules
Ladislav Lhotka: Conclusion go for 1.1.
Andy Bierman: We previously said we wouldn't upgrade module, just the version.
Lada is asking about 1.1 language features. We're keeping yang 1.0 as current
RFC. (6020bis doesn't obsolete 6020)
Benoit Claise: let's check the minutes from 95
Andy Bierman: sounds new to me...
Rob Shakir: sounds like a tooling issue, agrees with Andy
Benoit Claise: how does this impact your tooling?
Rob Shakir: there is an impact to developing a 1.1 ingest tool
Lou Berger: Should have some off and on-list discussion about this and
specifically include the yang doctors.
Benoit Claise: I want the guidelines *today*.
Lou Berger: From the checking tool standpoint, should be easy to upgrade the
modules, issue is breaking the tools.
Benoit Claise: If I'm not using 1.1 features, do I need to bump the version?
Ladislav Lhotka: One of the things that should be added/changed is the use of
xpath. Right now we utilize the textual comparison in xpath. If we provide
changes, we may break things.
Lou Berger: Ask users of models: (customers) Who objects to yang 1.1? ... how
many people didn't understand question?
Chris Hopps: The problem with the question is, what does this imply? Whatever
gets it out there the fastest is important.
Dean Bogdanovic: Is the requirement to move everything to 1.1, or is there a
choice?
Lou Berger: Requirement to 1.1 even if you didn't need this as a feature.
Andy Bierman: Do you think you're going to get more mature tools from rfc
that's been out for 4 years or something in I-D state? There are plenty of
things that are in 1.1 you shouldn't barf on.
Lou Berger: Vendors, Same question (who objects to to yang 1.1?)
Dean Bogdanovic: If you have something already implement to 1.0, leave it to
1.0. In yocta draft, Had to move one thing because it needed 1.1. In that
case it made sense.
Rob Shakir: Can you ask how many people are implementing (lot of hands
raised...)
Lou Berger: Thinks Dean has a good way forward, if you hve a model that needs
1.1 feature, go ahead an use it. Also ok to stay and 1.0.
Kent Watsen: Also Andy's point as well.
Lou Berger: see a nod of "yes" from AD
Vladimir Vassilev: 1.1 to 1.2, will be same question?
Lou Berger: We have that issue whenever we rev techs.
Kent Watsen: If there's a feature in 1.2 you want to use, go for it. Otherwise
you'd stay at whatever the current draft has.
Juergen Schoenwaelder: Would like to add that yang doctors should push modules
to take advantage of YANG 1.1 features, if they see a yang module that would
benefit from 1.1.
Phil Shafer: If you have important modules that use 1.0, and you have to
support it, changes will force you to cascade your upgrades.
Kent Watsen: so the need to update to 1.1 will quickly cascade, good point.
* 5 Min: #1 OpState direction recap (Chairs)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-1.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-1.pdf
Lou Berger: assumption that modules will adopt the 7223 approach (e.g.
interfaces-state). If that's not the case, please bring it up on the list
Benoit Claise: We should not leave room until we have agreement where to put
the counters.
Lou Berger: Would like to move 6987bis to last call. Believe it reflects
consensus. Does anyone believe that 6087bis does not reflect their position?
Chris Hopps: This seems severe, that we can't leave the room until this is
settled. Don't think this should be a blocker. Module consumers can determine
how to consume each module based on its documentation, no set rule is needed.
Think we're ready to move forward (standardize models in the IETF)/ continue to
work on things in IETF.
Lou Berger: Don't want to enforce this; leave it as a convention, and
conventions can be broken
Chris Hopps: Yes.
Lou Berger: note the text says "SHOULD", so it is just a recommendation
Rob Shakir: Where state is located is important. If models are sprinkled
throughout model, it's an issue for people accessing it. For the record, don't
think this is the right decision. We've been working on this for 18 months. We
have running code. Back in Dallas, we'll let you know how it goes. I think
this is a premature decision.
Lou Berger: Objecting to direction from applied vs. intended.
Rob Shakir: A bad decision would be to give no guidance.
Rob Wilson: ... Is it worth asking this question again after we see the
solution presentations?
Lou Berger: okay
* 10 Min: #2 draft-ietf-i2rs-ephemeral-state-14 (Susan Hares)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-2.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-2.pdf
Susan Hares presenting "Yang Feature" slide: must be a way for yang schema
nodes to be flagged as only for ephemeral state...
Dean Bogdanovic: Writeable operational state is dangerous to dabble in. E.g.
in OSPF. You should only be allowed to update the state for RIB entries that
you put in (not state your peers put in), otherwise you'll be in a constant
state of convergence.
Kent Watsen: let's not debate I2RS requirements in this meeting, take it to the
I2RS list...
Andy Bierman: Problem with this wording. What does this new statement actually
do? YANG only has config true and config false. Shouldn't this be only with
the protocol?
Susan Hares: need a way to say a certain model, or parts of a model are
ephemeral only.
Jeff Hass: it needs to be possible to indicate that some config=true nodes are
ephemeral while other config=true nodes should not be allowed to be ephemeral.
Lou Berger: Please ensure that the requirements to NETMOD include this phrasing
of the requirement that Jeff just articulated.
Susan Hares: Have solicited feedback multiple times from yang doctors to arrive
at the text we have. Frustrating that this text isn't clear to this group.
Please ensure that any update to this text is reviewed by all and only one
answer is provided.
* 15 Min: #3 draft-schoenw-netmod-revised-datastores-01 (Juergen
Schoenwaelder)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-3.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-3.pdf
Juergen Schoenwaelder presenting: need more architecetural guidance.
Datastores are such a fundamental concept. Need separation between conceptual
model and what protocols do.
Dean Bogdanovic: do we all agree on the definitions and differences between
intended and applied - Lou: yes, Juergen: no ;)
Chris Hopps: is the issue with the definition of intended vs applied?
Juergen Schoenwaelder: no the issue comes much earlier in the definition of
configuration
Lou Berger: would be worthwhile to understand better your proposal
Mehmet Ersue: as netconf co-chair, agree with Juergen that the opstate solution
is a fundamental arch concept. Would like the datastore discussion to move to
NETCONF WG
Benoit Claise: yes, there is NETCONF impact, but don't care where it happens,
as the same people are going to work on it.
Balazs Lengyel: interfaces/interfaces-state resolution much more important than
the intended/applied resolution. Enabling operational DS to have same
structure as running datastore greatly simplifies things; supports datastore
based approaches over branches.
Eric Voit: is ACL config or opstate when 802.1x(?) is in play?
Juergen Schoenwaelder: I believe that ACLs can come from multiple sources.
Eric Voit: so they could be operational state? (Juergen nods)
Norm Strahle: What about CLI, is it covered by intended?
Juergen Schoenwaelder: Ideally all access mechanisms (NETCONF, CLI, etc.),
typically CLI is integrated
Susan Hares: BGP passes control state as part of its protocol, is it control
state or operational state?
Juergen Schoenwaelder: I believe that it would target the operational state
datastore.
* 10 Min: #4 draft-wilton-netmod-refined-datastores-01 (Robert Wilton)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-4.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-4.pdf
Robert Wilton presenting:
Dean Bogdanovic: when do I get confirmation that might commit was applied?
Robert Wilton: with current model, it's not defined
Kent Watsen: opstate-reqs defined a/synch config operations
Ladislav Lhotka: Where would actual MTU be represented (slide 7)
Robert Wilton: In a model defined config false node
Ladislav Lhotka: an extra data node
Robert Wilton: yes, for the specific case on MTU
Andy Bierman: Seems complicated interaction model to just indicate single bit
(is the leaf applied). Are there more use-cases because, alternately, I could
just ask the box if it's applied yet. Is there more use-cases than just this?
Robert Wilton: no I don't think so [EDITOR: not true, telemetry needs this to]
Dean Bogdanovic: would like to understand how to map the commit process in the
protocol context
Vladimir Vassilev: concur with Andy. It's solving a very narrow problem. Time
to commit is one thing, but, for example, NTP may take time to resolve. This
seems like a lot of complication, NETCONF/YANG used to be simple, now getting
scary
Robert Wilton: Applied configuration is intended to tell an operator exactly
wheat the system is doing, as opposed to today where it's not clear
Rob Shakir: a subscription system is more likely to just subscribe to the
applied information, so is more than just one bit [EDITOR: yes, see comment
above]
Susan Hares: same q I asked Juergen, assume that there is an ACL that is
configured, and BGP flow state, how do they interact in your solution?
Robert Wilton: probably same answer as Juergen's (i.e. BGP is operational state)
Eric Voit: same question about ACL and 802.1x
Robert Wilton: same answer as Juergen's
Rick Taylor: surprised that opstate datastore didn't already exist, so this
work is long overdue
Chris Hopps: diagram looks complex only because it is a complex topic, but when
thinking about implementation, it doesn't seem so complex
* 10 Min: #5 draft-wilton-netconf-opstate-metadata-00 (Robert Wilton)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-5.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-5.pdf
Dean Bogdanovic: regarding there being a way to describe that a value has been
overwritten by ephemeral, you will have a problem there with lawful intercept
Robert Wilton: let's discuss offline
Dean Bogdanovic: -- <no time for questions -- to list or Wed discussion.>
* 20 Min: #6 Open discussion on revised datastores (Open Mic)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-6.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-6.pdf
Chairs: This block of time had to be clipped - folks should come to Wed's
breakout opstate session
* 20 Min: #7 draft-ietf-netmod-schema-mount-02 (Ladislav
Lhotka)
slides:
https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pptx
slides:
https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pdf
Andy Bierman: Use case is a server that wants to compose structure out of
multiple. Don't understand how this relates to standards, or to routig-cfg
module
Ladislav Lhotka: it's related because we changed the routing-instances approach
to depend on a TBD schema-mount solution
Andy Bierman: seems like a presentation issue, YANG tools don't care.
Lou Berger: This is to support the shift in routing area and is used to support
logical network element and network instance
Kent Watsen: this is intended to be used by module-designers (this is not the
same as peer-mount)
Chris Hopps: <explains motivation from the routing DT perspective>
Eric Voit: can peer-mount be built on top of this?
Ladislav Lhotka: yes, that is what the slide says (the "is this what we want?"
slide)
Chris Hopps: regarding 2 slides back, what did you mean, only useful at on
level?
Ladislav Lhotka: not so easy for recursive issue (nested VMs)
Chris Hopps: don't understand DSDL thing, does it presume you know what models
will be there beforehand
Ladislav Lhotka: yes
Chris Hopps: that's a big problem
Balazs Lengyel: need a way to do schema-mount in YANG module using programmatic
statement (not description statement)
Andy Bierman: regarding validation, I see many incorrect must and when
statements. Sounds like this will make things even harder, less likely model
designers will get it right
Ladislav Lhotka: i don't believe this makes anything harder
Chris Hopps: regarding anydata, does that mean anything goes, or is it
restricted or a free-for-all
Lou Berger: sorry, we're overtime, we have to take this offline
Session 2:(Tuesday, 2-hours)
============================
* 5 Min: #0 Intro (Chairs)
* 10 Min: #9 Routing Area DT Update (Christian
Hopps)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-9.pdf
<moved from previous session>
Common Naming an issue
Schema mount / opstate drafts followed/needed
New idea of tagging modules/branches instead of containment hierarchies
Lou Berger: Comments on hash tag idea?
Dean Bogdanovic: hashtags might become a mess. Limit the number of htags. Small
set of standard tags + rules for private tags
Christian Hopps: Idea to keep them loosely coupled. Let it develop organically.
Dean Bogdanovic: At least provide conventions, Classification draft might
include htag rules
Christian Hopps: We should decide if a good idea
Rob Wilton: perhaps use a standard prefix
Lou Berger: Agreed. I think that's already been mentioned, e.g., "IANA" (by
Chris)
Andy Bierman: Like the idea. Suggest having conventions to avoid all the
possible permutations.
Andy Bierman: htag nice idea, but rules needed otherwise rout/routing/routes
Kent Watsen: perhaps the classifications could be namespaced? e.g.,
#ietf:<foo>, #<vendor>:<bar>
Dean Bogdanovic: As author of classifications, perhaps take this into account
Lou Berger: Do you want this on the offline catalog or on the device to
Christian Hopps: This was on the slide
* 10 Min: #8 draft-ietf-netmod-routing-cfg (Acee Lindem)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-8.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-8.pdf
Acee Lindem: Question should new applied state impact this document
Lou Berger: We would like to move to LC, any reservations on LC?
Dean Bogdanovic: Should move to LC.
Lou Berger: How many have read this version <a few>
How many have read any version <many>
Acee Lindem: Have two changes would like to discuss:
Acee Lindem: Metric could actually use protocol specific extension,
route tag and unequal cost multi path as features, can be an
augmentation. Also need to make change in interface and next hop
identification.
Ladislav Lhotka: believes that we had route metric before, okay to move forward
Lou Berger:
Are there any reservations for moving forward with this document after the
discussed changes are made <none>
Lou Berger: Once change is made, will LC on the mailing list.
* 10 Min: #10 draft-ietf-netmod-acl-model-08 (Dean
Bogdanovic)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-10.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-10.pdf
Mahesh Jethanandani: did you address the YANG Doctors comments
Dean Bogdanovic: yes
Sam Aldrin: can a single rule cover both L2 and L3?
Dean Bogdanovic: need to chain multiple matches. Other options were
discussed in the WG and rejected.
Elliot Lear: it was a factual question: if I read the model, it's a
choice, correct?
Dean Bogdanovic: yes
Lou Berger:
How many have read the latest version <few>
How many have read any number <a good number>
Any additional issues to discuss <none>
How many think the draft is ready for (another) last call <less, but a
reasonable number>
Lou Berger: Will issue another LC
* 10 Min: #11 draft-ietf-netmod-rfc6087bis (Andy Bierman)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-11.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-11.pdf
Andy presents
Updates/changes
Code extraction Tools need to be improve to only extract <code begin ends> parts
Benoit Claise: agrees that need to cover case of examples in documents and have
tools do the right thing (Slide 4)
Kent Watsen: would it make sense to different between YANG examples vs
instance document examples, so as to further facilitate draft validation?
Andy Bierman: could do anything, but need to decide what is
covered. Perhaps discuss on list.
Andy Bierman: <slide 5 - no comments, will take to list>
Andy Bierman: When to use YANG 1.1? Use when 1.1 features are needed now, but
you MAY use 1.0 if you don't need them. Updating just to be current will be
expensive.
Rob Wilton: Is YANG 1.1. a MUST/SHOULD MAY
Andy Bierman: MAY
Rob Wilton: clarification. Mark the model as YANG 1.1 even though it does not
use YANG 1.1 feature?
Andy Bierman: yes, e.g., to support import of a 1.1 module's definitions
Lou Berger: From yesterday, MAY is as strong as WG supports
Lionel Morand: Marking the model as YANG 1.1 would mean that it complies with
clarifications made in YANG 1.1
Andy Bierman: Perhaps worth adding more guidelines on when 1.1 is
appropriate beyond syntax changes. E.g. string definition and imports
Balazs Lengyel: (re: slide 7) Tool too weak to classify foo and foo-state.
Andy Bierman: I'd much prefer having deterministic tags vs overloading names
Rob Wilton: prefer it recommends one way rather than allowing choice
Andy Bierman: not sure we have consensus on this, current text does not
put a stake in the ground
Kent Watkins: Should we drop the section (5.23) for now
Lou Berger: we should be precise about terminology, and the title of the
section doesn't match the title of the slide. Is the slide making a
general statement on containers or something specific about operational
data (e.g., counters)
Andy Bierman: the latter. Information should be contained based on
information lifetime. E.g., the number of times an ACL is accessed (matched)
should be stored with the ACL. If/if-state is also based on
pre-provisioning and it may not be the answer for everything. Like the
suggestion that opstate handle that (this)
Juergen Schoenwaelder: would like to keep the text in, even if it is week. We
make them aware of the
problem.
Kent Watsen: you mean that it lays out the options and background around why
they might matter
Lou Berger: but that isn't a guideline
Rob Shakir: It is, having a common convention is useful
Benoit Claise: don't want to delay guideline. As contributor, need to
get the tooling right.
Juergen Schoenwaelder: would like a slight modification, i.e., show relationship
between trees, even if using same hierarchy.
Balazs Lengyel: require identical hierarchy / tree structure.
Benoit Claise: whatever works with tooling
Lou Berger: current text uses description at times to provide
relationships, does this match tooling requirement
Andy Bierman: We can make the text state that same tree structure is
recommended
Rob Shakir: Please do.
Benoit Claise: we have the guideline the not model the applied in the
tree, do we need to say this too?
Andy Bierman: opstate/applied state is a different topic.
Lou Berger: Suggest this isn't the right document for the recommendation
on modeling applied state.
Benoit Claise: We will have a wiki for YANG doctors, but this isn't the
right place for this
Lou Berger: if putting into Wiki is not sufficient, can you propose text?
Benoit Claise: yes
Lou Berger: Changes have been discussed in slides and discussion. Are
there any other changes left (pending)?
Andy Bierman: No.
Lou Berger: How many have read this version <a few>
How many have ready any version <a good number>
Are there any technical objections that have not yet been raised/discussed
<none>
Lou Berger: Wait till we have updated draft and then we can go to LC.
* 10 Min: #12 draft-ietf-netmod-intf-ext-yang-01 (Robert Wilton)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-12.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-12.pdf
Dan Romascanu: ieee proposed to do this draft. it configures ieee functions.
Work is right, but close cooperation needed with ieee (wrt ensuring we don't
break IEEE rules)
Tim Carey: Is there divergence between this draft and IEEE and BBF, and
current
Robert Wilton: Yes, IEEE is more limited and BBF is wider scope, trying
to understand and cover both in parallel
Anton ? (Brocade): Why using 802.1Q and not AD and why limiting tag
length to two
Lou Berger: (overtime) please discuss on list
* 10 Min: #13 draft-ietf-netmod-model-entity-01 (Andy Bierman)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-13.pdf
Kent Watsen: BBF depending on this module, articulated a willingness to
become more involved
Balazs Lengyel: if we put notifications all over the place, we loss
important features. (e.g., dampening) Should reuse not redefine.
Andy Bierman: that's right, notifications may fall out for free.
Dan Romascanu: The conformance related section needs edits
Dan Romascanu: Again, sees this as pieces being replicated in a
proprietary way as well as in other SDOs. So us useful.
Kent Watsen: Need another rev before LC
Lou Berger: Do you have an ETA?
Andy Bierman: Update in ~ 3 weeks
* 10 Min: #15 draft-ietf-netmod-yang-model-classification (Carl Moberg)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-15.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-15.pdf
Lou Berger: WRT SDOs, the IETF has formal relationships with other SDOs
and organizations and we can leverage in the document definitions
Dean Bogdanovic: Could use this draft as foundation for Chris'/Rtg DT (#tags)
discussed earlier
Rob Wilton: Are Openconfig standard models?
Carl Moberg: Open source organization
Lou Berger: Do you have changes planned
Carl Moberg: only small changes
Dean Bogdanovic: We could add hashtags to this
Carl Moberg: or handle in separate draft
Lou Berger: What changes are need for classifications/hashtags
Dean Bogdanovic: Donât yet know
Lou Berger: come back with a proposal for classifications/hashtags
Lou Berger: Are there any objections that haven't been discussed <none>
How read version? <reasonable, not large>
How read some version? <about the same>
* 10 Min: #14 draft-ietf-netmod-syslog-model-09 (Clyde Wildes/
Mahesh Jethanandani presenting)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-14.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-14.pdf
Mahesh Jethanandani presents
Kent Watsen: is this blocked by TLS client
Mahesh Jethanandani: Yes (Clyde confirms via Jabber)
Lou Berger: Question to Clyde, are there changes to this document that
are likely based on changes to TLS document?
Clyde Wildes: via Jabber, probably not
Lou Berger: Should the document progress and be blocked by reference
Mahesh Jethanandani: Yes
Kent Watsen: TLS client is too immature yet
Juergen Schoenwaelde: If the document is blocked, what does it matter
where its blocked
Lou Berger: in general, its better to progress the draft once the WG 's
work on it is done to allow publication process to occur
Juergen Schoenwaelder: as assigned YANG Doctor, will review in the next couple
weeks
Lou Berger: Chairs will discuss whether to wait for reference or run LC
process and have document sit in REF WAIT state. In general its better
to progress the draft
* 10 Min: #16 draft-openconfig-netmod-model-catalog (Rob Shakir)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-16.pdf
Andy Bierman: this is very similar to my yang-packages from long ago
Andy Bierman: is this meant to be read from device or offline?
Rob Shakir: offline
Andy Bierman: like RPMs, needed for the next generation compliance. What would
work together can not be contained in a module
Kent Watsen: if offline, does it make sense for the IETF to standardize it?
Rob Shakir: could be something else
Benoit Claise: in favor of it being in the IETF
Balazs Lengyel: also in favor of describing how modules work together
Lou Berger: who thinks this functionality is important (a good number)
Lou Berger: who thinks this WG should work on it? (basically the same)
Lou Berger: Chairs will talk re WG adoption/next steps
* 10 Min: #17 draft-asechoud-netmod-qos (Norm Strahle)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-17.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-17.pdf
Overlap with draft in routing area, cooperating
Work is likely to be move to RTG or TSV
Kent Watsen: Followup presentation in RTG WG. (for those who are interested.)
* 10 Min: #18 draft-agv-netmod-yang-compiler-metadata (Vinod Kumar S
and Gaurav Agrawal)
draft-agv-netmod-yang-annotation-ds-and-derived
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-18.pdf
<no comments>
* 10 Min: #19 draft-sharma-netmod-fault-model-00 (Anurag Sharma)
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-19.pptx
slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-19.pdf
Dan Romascanu: coauthor of RFC3877 where we reused ITU definitions
Carl Moberg: is the IETF the right place for this? concern regarding taking
source data from other SDOs (e.g., XL33)
Anurag Sharma: this is pulling from and building on RFC3877
Dan Romascanu: as author of that RFC, this is good and external
references are okay
Alex Clemm: how different from alarms
Carl Moberg: there was some prior work that you should look at
if interested in earlier work
Anurag Sharma: yes, let's talk
Balazs Lengyel: if we do work, should be based on x733
Lou Berger: if we do this work, should be consistent across data planes
Anurag Sharma: yes
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
