* 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: Robert Wilton, Warren Kumari | 2008-Apr-29 —  
Chairs
 
 
 


IETF-113 netmod minutes


Minutes

minutes-113-netmod-00 minute



          Draft Minutes inclusive of the agenda.
          
          # 1) Introduction
          
             Chairs (10 minutes)
             Session Intro & WG Status
          
          Charles Eckel In-room cooordinator.
          
          Lou Berger speaking for intro
          
          Mahesh Jethanandani: I will work with Rob on his (ethernet) documents.
          
          # Chartered items:
          
          ##  YANG Versioning Update (45 min)
          
          ### 2) Title: YANG Versioning Update - Overview
          https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-05
            Discussion Leader: Joe Clarke
          
            :09
            Joe Clarke speaking
          
            Lou Berger - based on the update we'll decide if there needs to  be
            a second last call.
          
            No questions.
          
          ### 3) Title: Yang Packages
           https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-06
            https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages-03
            Discussion Leader: Jan Lindblad
          
          :21
          Jan Lindblad speaking
          
          Charles Eckel: how do you envision -bis versions working? When changes
          look like a deviation.
          
          Jan Lindblad: deviations is not a way to communicate version changes. An
          update is just a BC or NBC version update.
          
          Slide 9: (API vs Implementation packages)
          
          Lou Berger asks if the question regards the concept or realization.
          
          Jan Lindblad: concept
          
          Benoit Claise: I can see how the implementation option would be most
          useful. Let's see if it gets used before spending too much time on
          it. (:38)
          
          Tom Hill: exatly the opposite of Benoit I prefer API package so I can
          tell what they support across vendors.
          
          Lou Berger (as contributor): Agree with Tom that from a provider/user
          perspective would like to specify what is desired (via API packages) and
          then have vendors state what they support via an implementation package.
          
          Scott Mansfield: (from chat) Was the point about listing conformance as
          part of the package?
          
          Benoit Claise: Going back to slide 8, API says what user/customer wants;
          the implementation package says what the vendor is doing. Is this the
          right way do represent this?
          
          Tom Hill: it doesn't help if vendors use different APIs, need to be more
          proscriptive.  Rather than query router "what can you do?", I want to say
          "do this".
          
          Rob Wilton (contributor): API package is giving the specification,
          Implementation package says what the server is doing.
          
          Jeff Haas: (missed it: 39) Would like to focus API package on
          dependencies.
          
          Balazs Lengyel: it would be nice if a tool would enable discovery of
          what API packages a module/package implements.
          
          Jan Lindblad: The question was really whether making a distinction between
          API and implementation packages is useful. I think we struck a cord here,
          based on all the discussions spurred. Clearly the distinction between API
          and implementation modules is a meaningful one to most people. Thank you.
          
          ## 4) Title: Self Describing Data Object Tags (10 min)
            https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-06
            Presenter: Qin Wu
          
          Qin Wu speaking: :53
          
          Lou Berger (as contributor): On "Tag Managment Conflict Resolving" slide,
          not sure why tags are any different than any other rw information.  So I
          don't believe there is any unique issue here. The text change is fine,
          but unneeded.
          
          Qin Wu: agree
          
          Rob Wilton (as contributor): The module uses NACMs:instance-identifier
          typedef which allows tags to either be for a specific data instance,
          or more generically cover multiple instances (e.g., all instances of
          an MTU leaf).  I think that this is the right thing to do, but it might
          be helpful if there was some extra descriptive text to make this clear
          (if it isn't already there).
          
          Lou Berger: chairs will discuss Last Call after the meeting.  Don't see
          any reason not to.
          
          # Non-Chartered items:
          
          ## 5) Title: System-Defined Configuration (15 min)
             https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-02
             Presenter: Qiufang Ma
          
          Quifang presenting (1:04)
          
          Kent Watsen: On Slide 2, perhaps the WG should discuss if we should
          support in  first, not shy away from it just because there is a "when"
          expresssion somewhere, especially as the update to the "when" expresssion
          would because it expand the its scope and so wouldn't break existing
          models and we can decide if it's worthing updating the other rfc
          
          Rob Wilton (as a contributor): I have some concerns about whether
          running configuration should always be required to be complete, or
          whether an incomplete configuration should be mergable with system
          configuration before validation.  An example is creating an interface
          with a default interface type - should a client always have to specify
          this, or can a server use a system value without injecting it into the
          running configuration?
          
          Balazs Lengyel: Some SDOs specifify what must be created by the system,
          so would be a problem if we restricted this in any way
          
          Jan Lindblad: would like to ensure that existing clients don't break
          (Quifang concurs).
          
          Balazs Lengyel:
          
          Jan Lindblad:
          
          Balazs Lengyel: it would kill 3GPP YANG modeling
          Jan Lindblad: Not at all. All you need to do is to make sure 3GPP clients
          and servers implement flags to control this.
          
          Balazs Lengyel:
          
          Jan Lindblad:
          
          Balazs Lengyel:
          
          Rob Wilton (contributor): do you think it there should be a parameter
          (like "resolve-system") to enable system-aware clients can ask the server
          pull-in whatever  config needed?
          
          Quifang Ma: yes, will present next.
          
          Balazs Lengyel (on Slide 4): this is a show-stopper
          
          Kent Watsen (contributor): this is a not approved approach, there was
          a vigorous discussion on the mailing list, the system can act like a
          client to avoid the server make changes.
          
          Lou Berger: there's no RFC that precludes something automatically;
          this would be a change in allowed behavior which we have to take into
          consideration
          
          Balazs Lengyel: (in chat, after meeting ended?) I don't seem to be
          able to modify the notes, so here are some comments also stated
          in voice:System:Balazs: Other SDOs like 3GPP and O-RAN are using
          system-created data nodes. Their design depends on them in some
          cases. Clients are not allowed to create these list entries. Until now
          the system is allowed to modify the running configuration. If we would
          prohibit this that would be a major non-backwards-comptible change. I
          object to that. It would also need a YANG 2.0 revision. Even if we would
          prohibit the system to modify running, it would be possible to work
          around it. The system instantiates an onboard client to do the changes
          AND the system prohibits the change for other clients. However this is
          just a more complicated way of stating that the system itself modifies
          running; we gain nothing but make the world more complicated. While I
          agree that system-created data nodes can be problematic sometimes it is
          a fact of life, so we should not remove it.
          
          ## 6)  Title: Immutable Metadata Annotation (15 min)
             https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-00
             Presenter: Qiufang Ma
          
          Qiufang presenting (1:32)
          
          Rob Wilton (contributor) on Slide 5, has concern if servers decide some
          things are immutable may break existing clients.  Having a parameter
          is a better choice that always returning the data might be better.
          Having this is as annotation to indicate where immutable data exists,
          without encouraging it might be a good solution.  Should also consider
          config-replace like operations.
          
          Jan Linblad: agrees with Rob, restirctions make life difficult for
          clients, but RFCs say already that rejection can happen already.
          
          Qiufang Ma (to Rob and Jan): not introduce new restriction, just want
          to make the information visible.
          
          Balazs Lengyel: Generally supports work.  Some SDOs use invarient to
          represent a similar concept. Some use immuable rules to say once created,
          cannot be removed.
          
          Rob Wilton: shouldn't encourage?
          
          Balazs Lengyel: would like to agree
          Balazs Lengyal: sometimes "immutable" can be specified in schema (YANG),
          i.e., don't need annotation.
          
          Balazs Lengyel (in chat, after meeting ended?) Immutable:3 potential
          use-cases for immutable: - invariant: once a leaf is created it cannot
          be changed - capabilities that are created by the systems and client
          cannot modify them. Is this better served by immutable or system data? -
          Immutable NACM rules that must stay in place to protect some parts of
          the configuration from any modification
          
          ## 7)  Title: Updated Common YANG Data Types for Traffic Engineering
          (10 min)
             https://datatracker.ietf.org/doc/html/draft-busi-teas-te-types-update-01
             Presenter: Italo Busi
          
          Italo presenting (1:50)
          
          Jeff Hass (from meetecho chat)- I can expand at mic, but BFD has had
          a similar issue for RFC 9127-bis. Trivial change, painful process:
          https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-02.
          Short form is process is too heavy weight.
          
          Mahesh Jethanandani: provides BFD-bis experience (importance of the
          problem).
          
          Rob Wilton (AD) could be a separate draft the "updates" this draft and
          only updating the specific module.  Not supportive of putting diffs into
          the Apendix.
          
          Italo Busi: (missed it)
          
          Rob Wilton: could add a comment to RFC Editor and enables annecdotal
          text to be removed before publication.
          
          Jeff Haas: Some concern regarding how to handle other modules that
          "imports" the updated module.  Issue being discussed on BFD list.
          
          Lou Berger (as chair): Rob gave solution.  Separately, don't rely
          on tooling.
          
          done at 2:03
          
          ### Note takers:
          
          JJ = joel jaeggli
          JS = Jürgen Schönwälder
          MJ = Mahesh Jethanandani
          
          



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