* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Netmod Status Pages

Network Modeling (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2008-Apr-29 —  

IETF-102 netmod minutes

Session 2018-07-17 1330-1530: Place du Canada - Audio stream - netmod chatroom
Session 2018-07-20 0930-1130: Laurier - Audio stream - netmod chatroom


minutes-102-netmod-00 minute

          > NetMod Minutes For IETF 102
          > Session 1:
          > TUESDAY, July 17, 2018
          > 1330-1530 Afternoon Session I
          > Place du Canada
          > Audio stream:
          > Session 2:
          > FRIDAY, July 20, 2018
          > 0930-1130 Morning Session I
          > Laurier
          > Audio stream:
          > Etherpad:
          > Meetecho:        http://www.meetecho.com/ietf102/netmod
          > Jabber:        xmpp:netmod@jabber.ietf.org?join
          > Available post session:
          > Recording:        https://www.ietf.org/audio/ietf102/
          > YouTube:
          > TUESDAY, July 17, 2018
          > 1330-1530 Afternoon Session I
          > Place du Canada
          > Audio stream:
          > Presentation                Start Time        Duration
          > 1                13:30        10        Title:        Intro, Charter &
          WG Status
          > Presenter:        Chairs
          > Draft:        N/A
          Joel Jaeggli presenting
          > 2                13:40        15        Title:        Interface
          > Presenter:        Rob Wilton
          > Draft:
          > https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model
          Rob presenting
          Lada (Ladislav Lhotka): These are very good drafts, but IEEE models are
          difficult to implement for simple devices. Is there an options or liason
          to provide review of their modules?
          Rob: It's too late as their models are quite mature. IEEE have their own
          configuration model already for those devices. I would have liked to see
          them reusing like the sub-interface constructs and things that doesn't
          actually necessarily work with their model. And I've given examples of
          how to use sub-interfaces with the LTL TPM model. That allows you to do
          transparent bridging.
          Lada: Really need something simpler (from IEEE)
          Scott Mansfield: Issue of YANG coordination is being taken serriously
          by IEEE and already working with ITU. .1Q document is "done" there
          are other modules proceeding in IEEE. There are opportinities for
          collaboration: monthly meetings, etc.  IEEE is using YANG Catalog. Put
          comments there. there is also meeting of a yang group in the IEEE the
          last Wednesday of every month and there is an ITU call last the third
          Monday of every month
          Lou Berger: Scott, what do you think about Lada's liaison suggestion.
          Scott: Liasons are useful but better to raise on an individual level
          Rob: there are 2 fundamental issues, IEEE and IETF being done in parallel
          Scott: talking now would be good, future models should be more module
          Lou: does this issue is enough of an an that it rises to the level of
          having a coordination for next meeting
          Scott: Suggest coordination with a subgroup would be worthwhile
          Rob: there is already some discussion taking place
          Lou: We (chairs) will follow up offline
          Rob: I will draft a liaison that can be used to inform IEEE of status.
          > 3                13:55        10        Title:        YANG Module Tags
          > Presenter:        Chris Hopps
          > Draft:        https://tools.ietf.org/html/draft-ietf-netmod-module-tags
          Chris presenting
          Joel: who has read it (this or prev): a healthy number
          Joel: who thinks it's ready: a good percentage who have read
          Joel: who thinks it is not ready: none
          Joel: We will take it to the list
          > 4                14:05        20        Title:        YANG Data
          > Presenter:        Kent Watsen
          > Draft:
          Lada: It¡¯s really something that's needed and it's very convenient that
          you can define some scheme of independent of encoding. But concern as
          proposing it at a standard implying that it is a normal way of using
          YANG, when it really isn't.  Slippery slope, if we want to do this,
          then should continue to RFC 8040.
          Kent: Your concerns apply to RFC 8040.
          Lada: In restconf RFC8040, there are some rational way. This seem to be
          making it more official.
          Lou: Why do you think that it isn't a standard before (in RFC 8040)
          Lada: Because it make the community more aware of it.
          Kent: Your concern really is about extensions, would it help if there
          was an applicability statement.
          Lada: If it a proposed standard then expect folks would use it.
          Lou: Is it that you don't like extensions of the specific YANG data
          Lada: I don't like an extensions that change yang semantics. Question
          of scope about what is being done in extensions.  As soon as we change
          what it is in RFC 7950 then it is a problem.
          Lou: Since this is already an extension in RFC 8040.  Perhaps it would
          be good to do a draft to explain how extensions should be allowed.
          Lada: Now have YANG data augment, which wasn't in RFC 8040.  Undermines
          the value of YANG in a standard.
          Rob: Would you be happy if this was done as part of a Yang 1.2 or Yang
          2.0, or do you object to idea of YANG data?
          Lada: I would be happy if it was done in the a new YANG specification.
          Could be done in a small draft (to define yang independent of data
          Kent: To clarify, if a new version of YANG, then it could be a top
          level statement.
          Lada: I'd prefer YANG be generic and be usable to model data without
          being tied to datatores/restconf/netconf
          How to proceed:
          #1 define both "yang-data" and "augment-yang-data" (a few)
          #2 only define "augment-yang-data" (no one)
          #3 un-adopt draft (almost same to #1)
          Joel: who can not live with #1 (no one)
          option 1 selected: mostly because no one said that they could not live
          with it
          Lada: I can use #1 even though I don't like it
          WRT slide 6: Some felt it could be legal, most felt that it should not
          be legal
          Rob/Lou: would be good to define a statement (draft?) that clarifies our
          [mis-]use of the extension statement here.
          > 5                14:25        65        Title:        YANG Model
          Versioning Design Team
          > Presenter:        Rob Wilton
          > Draft:
          Rob presenting
          Chris Hopps: Fan of using namespace to indicate non-backwards compatable
          revisions, but Req1.2 states the namespace must be the same.
          Rob Wilton: It depends on how well people are play to the code to the
          clients, and whether people are using fixed paths.
          Tim Carey: About rq1.2: As a client, I don't know that this is not
          backward-compatible, that data node I'm using right.
          Rob Wilton: (Rq 1.2 ) It's not the intention to be saying the clients
          can find out that there's something's changing in non-backward compatible
          Italo Busi: What about clinets that are upgraded talking to an old
          server? One use case could be a hierarchical controller talking with
          multiple domain controllers, some of which are not updgraded to support
          the new model version.
          Rob: Thinks that this is a request to what is being offered instead
          (of not having forever backwards compatibility)
          Igor Bryskin: If you have a model that is not backwards compatible.
          There are cases where one client can talk with multiple servers: if
          there is no common ground you have an issue.
          Balazs Lengyel: (responding to Igor/Italo) You can just obsolete or
          deprecated something nodes. I think a client has to check the revision
          of all modules before really working.
          Alex Clemm: Why limit data nodes, or also includes rpcs, notifications,
          Rob Wilton: Could be more generically stated as "schame nodes"
          Kent Watsen(contributor): existing clients *today* clients or some future
          existing clients
          Rob Wilton: Mean today clients
          Kent: Okay, so this speaks to the migration/transition strategy
          Chris Hopps: This is a requirement that actually pops out, because of
          you saying that you need to be able to have multiple modules without
          different namespace names.
          Rob Wilton: Yes.
          Chris Hopps: We're creating problems that didn't exist before. You can
          have multiple modules if they have different namespaces
          Lou B: If you have an idea, it's worth discussing
          Chris Hoops: I'm just I'm making comments
          Gert Grammel: Want definition of what is/is not backwards compatible
          Rob: Using RFC definition
          Vladimir Vassilev: Be careful of over engineering and overly complex
          Chris H: Stating that the namespace cannot change limits solution space
          Balazs L: Disagrees, chaning namespace causes too many other changes
          Chris H: Maybe restate Req1.[1/2] to indicate goal without suggesting
          a solution
          Lada L: The option of changing the name of whom are already here. It is
          not a not good way to do this. If we want to change module names that
          we can.
          Lou B:How many people are comfortable w/ req as modified by today's
          discussion (Req1.2, and flexibility): a reasonable number
          Lou B: How many people are uncomfortable: one (already stated issue at
          Lou B: Home many think that we should not be talking about this? no one
          Lou: We will poll the list soon
          Kent (contributor): Any requirement needs to be added to support
          Rob/Lou: Sounds more like a yang-data problem
          Lou: What's the best way for folks to bring ideas to the Design Team?
          Rob: Just drop an email (netmod-ver-dt@ietf.org)
          > Adjourn                15:30
          > Session 2:
          > FRIDAY, July 20, 2018
          > 0930-1130 Morning Session I
          > Laurier
          > Audio stream:
          > Presentation                Start Time        Duration
          > 1                9:30        5        Title:        Intro
          > Presenter:        Chairs
          > Draft:        N/A
          > 6                9:35        15        Title:        Comparison of
          NMDA datastores
          > Presenter:        Alex Clemm
          > Draft:        https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff
          Alex presenting
          Qin: Compare different datastore or same datastore at different time. When
          will start?
          Alex: There is no time option and state aspect. RPC is performed when
          it be requested.
          Rob: Agree with Qin's comment that the doc should mention what happens
          when the schema differs between two datastore.  You might want to have an
          option to exclude nodes that are present in the schema in one datastore
          but not the other.  It would also be useful to have an option to decide
          whether on original metadata is part of the operation.
          Lada:Support! And one use case could be connected with restconf
          transactions document - emerging the staging repository into .
          Balazs Lengyel: Will the patch always use create or merge.  Just have
          one way to parse the difference (e.g. don't sometimes report as creates,
          other times as deletes).
          Alex: There is a choice here or where it is just reporting the difference
          Balazs: Agree that it is enough to just know the difference.
          Reshad Rahman: Question about why the draft has moved from NETCONF WG
          to NETMOD WG.
          Alex: The recommendation of the chairs was to move from NETCONF WG to
          NETMOD WG.
          Kent: It is closely related to NMDA work, so it seemed to make sense to
          move it here.
          Lou: how many think we should be working on this problem? (a really good
          Lou: How many have read this document.  £¨Also a really good number£©
          Lou: How many think we should adopt this document (also a really good
          Kent: How many think we should NOT adopt (None)
          We will confirm on list
          > 7                9:50        15        Title:        YANG Instance
          Data Files
          > Presenter:        Balazs Lengyel
          > Draft:
          Balazs presenting
          Open Issue 1 : Shall we recommend as a general practice: Servers SHOULD
          document their capabilities using instance data?
          Rob: I prefer there is not in this document. Suggest to keep this draft
          more abstract in terms of how to define the instance data.
          Kent: How to publish the instance document?
          Joel: I think we need a method there. I don¡¯t think it need to be done
          in this draft, but this problem should be solved in a particular way.
          Jugern (On Jabber):This is misplaced a file format specification in a
          file format specification.
          Lada: This should not be in this document because this data format is
          quite generic and can be used for any number of other proposes.
          Tim: Some other drafts talk about factory datastore, is there different?
          Balazs : This is about getting information before you actually have the
          network nodes available.
          Rob: The factory datastore is the default configuration where the device
          comes up.
          Balazs: This give the way for ¡°factory datastore¡± but doesn¡¯t prescribe
          Tim: Just want to figure out that what the connection of ¡°instance
          data¡± and ¡°factory datastore¡±.
          Rob: I don't think you get the interoperability if you need to publish
          this data.
          Lou: It's OK to have a draft to introduce that you implementation
          like report some information, but how to report it should outside the
          Adrian: it's not directly related but this could intersect with mud in
          the future, should take a look at that work.
          Balazs: Support defining a separated document to introduce how to report
          capability? (a few)
          Open issue 2 : Should we use yang-data-ext to define the instance data
          Kent: Any data is not a part of datastore.
          Lada: Lada: Without yang data extension, it just defined some schema,
          so if a server decides to implement it, I don¡¯t see anything wrong.
          Xufeng Liu:You not try to redefine the datastore, right? -- Balazs: No.
          Balazs:Support using yang-data-ext: (a reasonable number / few)
              Against using yang-data-ext: (very few)
          Joel: (To Lada) You cannot define the metadata that one might want to
          include your instance data. some solution for augmenting to be able to
          say I want to add this metadata. I think we need for something for that.
          open issue 2(second bullet): Shall we add a datastore parameter for
          config=true data?
          Rob: I think if the dates approach was included, it would be an optional
          thing.  And you least need a flag to say it is configuration data or
          operation data. I think you need more indication as what the data is.
          Lou:It seems like we're mixing some concepts which are really the data
          representation focused on build a representation and the other concepts
          items that are focused on how we are moving that representation or
          restoring that representation.
          open issue 3: Allow mulitple instance-data-sets in one file?
          Lada: In your document it said that this data is stored in the file then
          the file name should encode the version. I think this is a really bad
          Lou: How many people think this document should  be adopted now --
          current version? (a few)
             How many people would like to see an updated based on today's
             discussion and then adoption? (less)
             How many people oppose this document? (none)
          Chairs will discuss off-line then send something to the list
          > 8                10:05        15        Title:        Handling Long
          Lines in Artwork in Drafts
          > Presenter:        Qin Wu / Kent Watsen
          > Draft:
          Qin presenting..
          Rob: Maybe also be used in yang tree.
          Igor Bryskin:Auto extraction better
          Lou:How many people think this should be done in this WG (a good
          Dean Bogdanovic: Opsawg WG may be a better pleace.
          Adrian Farrel: if a graphical artworks cannot fit the 68 character width,
          folding it would be it even worse
          Kent: the draf says that it is NOT RECOMMENDED to use this solution for
          graphical artwork, you would like this to be changed to a MUST NOT use
          Adrian: yes
          > 9                10:20        15        Title:        Generalized
          Network Control Automation YANG Model
          > Presenter:        Xufeng Liu / Igor Bryskin
          > Draft:
          Xufeng Presenting...
          Interesting in this work (a few)
          Not interesting in this work (a few)
          Andy like the idea but not all the solutions.(Jabber)
          Tim:We know we have the problem but I think there is a finite state
          document. Suggest you guys get together and see if you can come in with
          a decent solution.
          Lou: Do you discuss with the author of FSM?
          Xufeng: Not yet.
          Lou:You need spend some more time with FSM document to figuring out
          where there's overlap or there's not.
          Igors: Implement or experimanet? If it can implement, it more valuable
          to do.
          > 10                10:35        10        Title:        YANG model for
          finite state machine
          > Presenter:        Nicola Sambo
          > Draft:        https://tools.ietf.org/html/draft-sambo-netmod-yang-fsm-03
          Nicola Sambo remote presenting..
          Lou: Do you think it need to discuss with ECA draft?
          Nicola: Yes, ECA is more generic.
          > 11                10:45        15        Title:        Yang data model
          for Terminal Access Controller Access Control System
          > Presenter:        Bo Wu / Zitao Wang
          > Draft:        https://tools.ietf.org/html/draft-zheng-netmod-tacacs-yang
          Michael presenting..
          Joel: Back when I was ops-AD: We started work to document how tacacs+
          is implemented today in the industry, we are not looking to add more
          to that draft (extensions would go in new drafts). This work would seem
          fit in OPSAWG.
          Ignas: Current tacacs+ works not looking to add more feature. A module for
          tacacs+ seems to be needed. If you talk about system, those two protocols
          can be selected by the choice. So it may be a good idea to try to work
          on AAA system framework and then have tacacs and radius put into that.
          > Adjourn                11:00

Generated from PyHt script /wg/netmod/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -