Minutes for NETMOD at IETF-93
minutes-93-netmod-1

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.