Please provide comments/corrections on the attached draft minutes.
The updated minutes will be uploaded next Thursday - August 20.
Huge thanks to scribes Carl Moberg and Jason Sterne!
Kent
NETMOD WG Agenda for IETF 93 (Prague)
Chairs: Tom Nadeau, Kent Watsen, and Juergen Schoenwaelder
[AC] Aseem Choudhary
[AL] Acee Lindem
[BC] Benoit Claise
[BF] Bill Fenner
[CM] Carl Moberg
[DB] Dean Bogdanovic
[GH] Giles Heron
[GP] Glen Parsons
[JJ] Joel Jaeggli
[JS] Juergen Schoenwaelder
[JS2] Jason Sterne
[KW] Kent Watsen
[LL] Ladislav Lhotka
[L?] Lucy ?
[L?2] Loukas ?
[MA] Michael Abrams
[NS] Norm Strahle
[RE] RFC Editor
[RK] Radek Krejci
[RW] Rob Wilton
[PG] Pravin Gohite
[S?] Sam ?
[TN] Tom Nadeau
[X?] Xien (from Huawei)
MONDAY, July 20, 2015
1850-1950 Afternoon Session IV
Grand Hilton Ballroom
60 minutes on NETMOD Models
===========================
5 min: Blue sheets, Note well, Scribes, Agenda Bashing (Chairs)
Chartered items:
15 min: draft-ietf-netmod-routing-cfg-19 (Ladislav Lhotka)
----------------------------------------------------------
[LL] suggests the WG to focus on stabilizing and publishing the model
[AL] agrees that the WG should focus on getting the spec published
[BC] suggests that we hold the specification short of last call to
get some early feedback from implementation experience
[LL] comments that stabilizing the draft will also stabilize the
namespace for the other (9 and counting) drafts that reference
this draft and it's data definitions
[AL] comments that there are some features (e.g. ECMP and recursive
next hops) that are not in the specification yet
[DB] comments that if we keep waiting for support for more advanced
features, we will never be able to publish it
[TN] comments that the more models we build that need this, the harder
it will be to make changes, need to think of a different plan to
approach this
[LL] comments that the YANG versioning models as they are right now
is hard to honor as the complex interdependencies grow
[TN] comments that the IESG may need to go back and consider the
complexity of the current situation
[AL] comments that if we don't need IPv4 and IPv6 to reference
routing instances, that would be a benefit, so RFC 7277 wouldn't
need to change.
10 min: draft-ietf-netmod-syslog-model-04 (Pravin Gohite)
---------------------------------------------------------
[CM] asks if there are any known implementations, Pravin doesn't know any
[PG] suggests that we take the draft to WG last call
[TN] asked Pravin to take the last call question to the mailing list
10 min: draft-ietf-netmod-acl-model-03 (Dean Bogdanovic)
--------------------------------------------------------
[TN] commented that questions needs to be asked also on the mailing list
[JS2] commented that we need more robust discussion on the mailing list as
there are alternatives to the current proposals
[JS2] wants to propose a separate container per address family
[JS2] commented that there is value in operator input on this (e.g. the
openconfig team or other operations people)
[DB] commented that there was some input from operators during the
Dallas meeting
Non-Chartered items:
10 min: draft-asechoud-netmod-diffserv-model-03 (Aseem Choudhary)
-----------------------------------------------------------------
[NS] says that there are still some fundamental issues to be worked out,
e.g. different architectures represented in the same model
[AC] comments that it's perhaps not so much the underlying architecture,
but different use cases
[??] (mic at back of room) isn't this a job for two models, a model where
you express the limitations and a generic model
[AC] comments that this can be approached using if-feature
[TN] suggests to carry this question and discussion to the mailing list
5 min: draft-wilton-netmod-intf-ext-yang-00 (Rob Wilton)
5 min: draft-wilton-netmod-intf-vlan-yang-00 (Rob Wilton)
----------------------------------------------------------
[GP] comments that it is good that the draft is labeled as complementary
to IEEE, but the content seems to suggest otherwise.
[GP] comments that further interaction across e.g. IETF, MEF and IEEE
would be good
TUESDAY, July 21, 2015
1520-1720 Afternoon Session II
Grand Hilton Ballroom
120 minutes on NETMOD Language
==============================
5 min: Blue sheets, Note well, Scribes, Agenda Bashing (Chairs)
Chartered items:
20 min: draft-ietf-netmod-rfc6020bis-06 (Juergen Schoenwaelder)
----------------------------------------------------------------
[AB] comments that the assumption that 1.1 can import 1.0 needs to be
clarified in terms of the validation rules applied to the modes.
[JS] comments that Andy should provide examples on the mailing list to
push this forward
[LL] suggests that any trailing issues for 1.0 can be covered by 1.0 Errata
[DB] Obsoleting 6020 will mean drafts based on 1.0 may need to be reworked.
What should we do with draft models that are written as 1.0 currently?
[DB] comments that he agrees with author to not obsolete 1.0. We have many
models in 1.0 heading towards, or in last call
[JS] comments that we need to distinguish between non-published modules and
published modules. How painful is it really to "upgrade" modules that
are not published?
[TN] asks AD (Benoit) for additional clarification on whether to park
existing pre-WG modules waiting for 1.1 and then bump them up.
Bring to mailing list.
[JS] how many changes will actually be required ?
[JJ] we shouldn't have to go and update RFCs. We are not likely to revise
a large set of drafts to reference 1.1.
[GH] comments that he supports removing the term "NETCONF" from the title
as there are several activities, e.g. I2RS working on YANG
[AB] comments that taking "NETCONF" out of the title will not help since
much of content refer NETCONF including examples
[AB] should we really take NETCONF examples out of the doc ? That will
hurt interoperability.
[TN] how about we leave them in but clarify they are just NC examples and
the doc isn't purely for NC
[BC] what are we going to do with the current 6020 ? Leave it there ?
Obsolete it ? - depends on if 6020 will remain active
[JS] since amount of YANG modules is relatively small, there is a chance
that all will move to 1.1, this means that we could retire 6020
[JS] We should carry forward the IANA considerations section into 6020bis
[JJ] comments that the consideration is solely for IANA instructions, so
not important that there are live (non-historical) documents with
the considerations in them.
[JJ] asks if conclusion is to remove IANA consideration text, and Tom
comments that it sounds like we have agreement on that
[AB] asks if we really should go through existing RFCs and update them,
is there really value in that?
[KW] comments that, to Andy's point, we can import 1.0 modules from 1.1
modules, which says that we may not require sweeping upgrades of
existing documents
[TN] if you don't have the ID it is 1.0
[L?] (RFC editor?) comments that in order to protect RFC editor resources,
see if we can avoid multi-document updates
[RE] (Lucy?) don't make changes in all these docs, if there turns out to
be a transition issue then write a transition draft.
[RW] asks if a YANG module can declare support for "don't care",
i.e. valid as both 1.1 and 1.0?
[DB] asks if the reference to "new modules" applies to all non-published
drafts, or if published, perhaps late-version drafts, should also be
updated
[LL] comments that work on his drafts will be updated to 1.1 to leverage
the new features
[TN] checks the room for objections on the WGs insisting on YANG 1.1 to
progress documents
[TN] does anyone object to saying that all new modules must be 1.1 ?
[AB] comments that this requirement will have significant impact on the
tooling, as e.g. parsers and validators may not be ready for 1.1
[BF] comments that this comment is fine for IETF modules, but how about
vendor modules that may reference e.g. interface-module. will vendor
models need to update to yang 1.1 ?
[BF] comments that he supports decision to require 1.1 to progress modules
[GH] asks if 6087bis references 1.1, room answers yes, it has been updated
[JS] note that you can pull in by revision so if you want an older version
you can use it
[JS] asks room who is in favor of online meetings vs normal mailing list
traffic. Slightly higher interest in webex-meetings
15 min: draft-ietf-netmod-yang-json-04 (Ladislav Lhotka)
--------------------------------------------------------
[JS] I support the proposal about Xpath (to rely on 6020bis)
[JS] Comments that there might be a little hole to plug regarding
the XPath expressions evaluated over I-JSON data
[RK] I think we can use the RFC2119 text.
[RK] Comments that the suggested text change regarding namespace
encoding rules works better
15 min: draft-ietf-netmod-yang-metadata-01 (Ladislav Lhotka)
------------------------------------------------------------
[AB] the intent of the annotation statements (related to issue #1) means
you can't write an extension statement that undoes anything that
basic yang statements do. That is, that are limited to things that
do not change or extend existing YANG statements.
[JS] suggests that we may be mixing things up, compilers ignore
non-compliant/supported keywords but the meaning of extensions is
related to the protocol, not as part of the module statements. A
client & server need to agree/negotiate whether an extension is
supported
[TN] wasn't Andy saying that an annotation can't undo functionality in
the base yang spec
[AB] What Juergen said is correct. The client should be able to skip
over attributes it doesn't know (or if it is something defined like
this then they can parse it but not use it).
[AB] we don't return metadata that the client didn't explicitly request
[LL] won't a client that doesn't understand ... (missed the rest)
[JS] how do clients ask for certain annotations
[AB] we add leaf params to the RPC (with-owners). In your case you would
have to ask for the disabled nodes (by default they are hidden to a
normal client).
[LD] we need to know that both client & server understand the annotations
[AB] we should charter conditional enablement
[JS] Juergen comments that for finishing up this document we should
document that there is no protocol negotiation and people should
proceed with care
[KW] (re annotate entire list): does this mean JSON can't annotate an
entire list either ?
[LL] correct
[JS] comments (on issue #3, co-exist with data nodes) that he agrees with
the author that annotations in separate modules should be a guideline
in a guidelines document, and not enforced
5 min: draft-ietf-netmod-rfc6087bis-04 (Andy Bierman)
------------------------------------------------------
[BC] we may need a section with guidelines for external entities
(e.g. SDOs, open source projects) around best practices to
publish YANG models
[DB] we need guidelines on how to encode examples in drafts, Andy
needs more input on details
Non-Chartered items:
15 min: YANG Model Coordination Group (Benoit Claise)
-----------------------------------------------------
[MA] where do we submit a draft for a model where there isn't a clear WG?
[TN] it is NETMOD if there really is no other place
[BC] regardless of where it is done we need to right experts
[L?2] asked if there was overlap between the IETF and ODL YANG modules
[BC] responds that data is not normalized and correlated, so there may
be duplicates. This is the type of data that we need. I will come
back to you on this.
[KW] number of models isn't always relevant. Some vendors have a single
model that is very large.
[??] What will we do about OpenDaylight models that aren't coming to IETF
[BC] we shouldn't really do much. If ODL people want to submit models to
IETF then great. Otherwise there isn't really an answer. We have
interest in coordinating to avoid duplication
[JS] the IETF is us, so if people want it to be worked through by IETF,
they should bring it in and be ready to work on it
[DB] regarding having different organizations producing different models
for the same thing. The end user can chose which model they want
to use. Community model, vendor model or IETF model.
[??] if there is a model in ODL that someone wants to bring to the IETF,
they should be encouraged to do so
[TN] the IETF is not going to go out and mine models. There is no
restriction on bringing a model to the IETF when there already exists
an ODL model for the same thing (although it would be good to bring
that ODL model to the IETF if that works instead of creating a new
one when one exists).
15 min: draft-bogdanovic-netmod-yang-model-classification-03 (Dean Bogdanovic)
------------------------------------------------------------------------------
[DB] who read the draft? (about 10 people raised hands)
[KW] in the zerotouch draft we present a southbound model to devices
so they can bootstrap. How is that classified ? It isn't really
a "service" but it sits in a controller (and is used to interface
with a device).
[CM] we do address that in the draft
[X?] can a YANG model be classified both as a service model and a
device model
[CM] yes - that can be possible. The same data structure can be both a
service model and a device model (e.g. topology).
[??] how does topology model fit into this classification ?
[DB] please take that to the list
[??] we may have a disconnect. There is a disconnect here. Some devices
have service-like objects.
[MA] can the network service models also have the same mix of std,
std-extensions and proprietary ?
[DB] yes. Will be clarified in next draft.
[S?] How does this draft overlap with the OpenConfig model-structure draft?
[DB] They are different things. This one defines std vs proprietary.
The OpenConfig is a layout of how models fit together (e.g. taxonomy,
overall data model structure, etc.)
10 min: draft-mansfield-uml-to-yang-00 (Scott Mansfield)
--------------------------------------------------------
[CM] here's my worry: my experience is that this is a difficult task
combining different viewpoints. Maybe we should also look in the
other direction. There is a UML output plugin in pyang.
[JS] what is your end-goal ? Totally automated tool system to feed a UML
model and spit out a YANG module ? Just a set of informal guidelines
for humans to translate. I don't believe in the first one (tool).
My experience is that UML models don't have all the information
needed for a data model.
[??] there is use in this. It is to share information models across
data models. What metadata will be required to make the generation
possible ?
draft-bjorklund-netmod-openconfig-reply-00 (Benoit Claise)
----------------------------------------------------------
[JS] how to continue & conclude this discussion ?
[TN] we will continue with interims until this is solved
[S?] I find it odd to convert responses to a draft. 2nd point: all the
concerns raised were also discussed in section 7. 3rd point: please
put an alternate proposal on the table.
[JS] it is quite common to have drafts for discussion. It captures
discussions and arguments. It is an individual draft that anyone
can create.
[TN] using drafts almost like an issue tracker
[JS] we included alternate proposals.
[S?] for all the questions raised, in section #7 discusses all the concerns
raised by the presentation
[S?] if there is to be a meaningful proposal, we need to hear concrete
proposals to move the discussion forward
[TN] we encourage using the points in the presentation to move the
discussion forward, there is nothing more to it. No resolution
expected today.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
