Subject: [netmod] Preliminary IETF73 meeting minutes

From: David Partain <[email-masked]>
Date: Fri, 19 Dec 2008 14:52:52 +0100

Hi,

I realize these are late (and they have to be submitted today ...) but here 
are the minutes.  I will give the list a few hours to look through them 
before submitting them to the Secretariat.

Cheers,

David
---------------------------------------------------------------------------------------------------------------
NETMOD WG 
IETF 73, Minneapolis MN
  WG Chairs: 
  David Partain ([email-masked])
  David Harrington ([email-masked]) 

THURSDAY, Nov 20, 2008 1520-1720
MP3 recording at ftp://videolab.uoregon.edu/pub/videolab/media/ietf73 
file:ietf73-ch5-thurs-noon2.mp3
Jabber: http://jabber.ietf.org/logs/netmod/2008-11-20.txt

Session goal: Conformation of consensus reached at interim
meeting and on ML.

0. WG status review (15 minutes) (David Partain)
   - "Darn good shape"
   - YANG draft published
   - Common data types moving along
   - DSDL and architecture drafts needed
   - Dan Romascanu
     * isn't concerned about the architecture
     * is concerned about the DSDL document being late.  Charter
       included DSDL, that is part of the work.  DSDL should be
       approved together with YANG document, not delayed.
   - David Partain: Not too worried, DSDL must wait for YANG
     itself anyway.

1. NETMOD Architecture (Phil Shafer (15 min))
   http://tools.ietf.org/html/draft-shafer-netmod-arch-00         

   - Consensus to become WG doc at interim, but waiting to become official
   - Feedback needed
   - Poll: 3/4 of room have read it
   - 10 people believe it should be the starting point of the
     architecture for the WG and 1 person opposed.
   - Mehmet Ersue: would be happy for it to become the WG
     architecture, but wants to wait for the next version to fix problems.
   - David Partain response: the WG document versions can
     address issues.  David Harrington: We only are deciding if
     this is suitable as a starting point.
   - Mehmet Ersue: it should be more formal (less John Wayne comments)
   - David Harrington: Too many informal comment (e.g., John
     Wayne). Make it more formal/official.  (For the record, no
     one asked Phil to remove the John Wayne comment.)
   - Significant list of comments have not been addressed yet.
   - Consensus to accept as WG draft, with required changes.
     Phil will publish as NETMOD draft ASAP.

2. Common YANG Data Types 
   M. Björklund  (5 min)       
   http://tools.ietf.org/html/draft-ietf-netmod-yang-types-01
   slides: http://www.ietf.org/proceedings/08nov/slides/netmod-4.pdf

   - Summary of changes since last shown
     * Fixed a missing backslash escape
     * Identified the type definitions needed of a normalization
        discussion
     * Generated XSD and RNG using a newer version of pyang
     * Editorial changes
   - No discussion

3. YANG - A data modelling language for NETCONF 
   M. Björklund (40 min)
   http://tools.ietf.org/html/draft-ietf-netmod-yang-02
   This presentation will include YIN and XML deliverables (40 min)
   slides: http://www.ietf.org/proceedings/08nov/slides/netmod-3.pdf

   - Discussion of changes to document since last version.

   - Status
      * draft -02 available
      * interim was in October

   - Canonical form of data-types
      * issues with 42 and +42 needing to be comparatively equal
      * especially important for indexes
        - don't want to create two list entries for 42 and +42
      * Wes Hardaker: what is sent back: the straight copy or
        the canonical form?
        - the canonical form can be sent back
      * Must the canonical form be sent back for a get-config?
        - there is consensus that it's likely this was consensus
        - David Harrington. Discussion was about the many
          different representation of IPV6 addresses.  Looking up
          the interim it seems that we did have consensus.
        - Jürgen Schönwälder: Is pretty sure interim consensus
          was devices must return canonical (as are David
          Partain, Balázs Lengyel).
        - Consensus in this meeting to return the canonical form
          to allow comparisons.
      * Bernd Linowski: Is this a complete solution?
        - Martin Björklund: Yes it is used in keys, and all other
          comparisons.
        - Bernd Linowski: What is the problem we are solving?
        - Martin Björklund: Is the key "42" and "+42" the same?
          We need a device independent answer.

   - Refine, when and augment
      * newer augment, refine, when syntax and structures
      * Refinement, when, and augment: consensus to accept

   - Features
      * supported features are advertised in hello capabilities
      * Balázs Lengyel: if-capability seems to be needed
        - Martin Björklund: agreed it might be needed
        - No proposal at this time to bring about such a
          if-capability feature
      - David Harrington: would features be separated by commas, or?
        - Answer: commas
      - Andy Bierman: Are features exported to other modules? (no
        answer recorded.)
      - Consensus to accept this feature

   - Deviations
      * All devices cannot necessarily support everything
      * A deviation statement has been added.
      * EGs shown: not supported, or maximum supported is 3
      * Device deviations are shown in capabilities
      * Wes Hardaker: SNMP/SMI-v2's hated offline reference is
        being done again?
        - Answer: at least it can be done online via monitoring
          (Using the NETCONF monitoring model / schema discovery
          method)
        - Martin Björklund: SMIv2 deviations were added later and
          that was half the problem. If we have this from the
          beginning it might work.
        - David Partain: We know deviations didn't work in SNMP,
          but we should try. Better than nothing.
      Deviations: consensus to add this to document deviations
      from standard. AGENT-CAPABILITIES in SNMP failed, but
      adding this in the beginning might work.

   - Identity and identityref
      * need to distribute reusable enumerations
      * identity's are define and others can be derived from it

   - Update rules
      * long discussions about what you're allowed to do when
        updating rules
      * goals and resulting rules derived from:
        - Protect old clients
        - Protect importers
      * Draft contains long list of specific update rules 
      * Two basic rules: protect old clients, import by revision.

   - Import by revision
      * not yet in the draft
      * will be able to specify a "revision" token to indicate the
        exact version to import
      * Balázs Lengyel:: is this mandatory or optional?
        Answer: optional

4. Mapping of YANG to DSDL
   Ladislav Lhotka (15 min)
   http://tools.ietf.org/html/draft-lhotka-yang-dsdl-map-01 
   slides: http://www.ietf.org/proceedings/08nov/slides/netmod-0.pdf
   MP3: ~54 minutes into MP3

   - Strong consensus: DSDL mapping should be able to generate
     schemas for both the full datastore and particular PDUs
   - Rough consensus: mapping will be divided into two steps
     1. map one more YANG modules to a conceptual tree
     2. From conceptual tree generate full schemas

   Description of how DSDL fits in the architecture (Ladislav
   Lhotka):

   (Editor: overview of this whole discussion, details below)

   Single full output DSDL "super-model" (combination of all of
   the models on a system) or individual models supplemented
   with XSLT to generate validation rules

   The "super-model" will largely be dependent on device support.

   Translations of individual models (CF: single YANG models)
   don't make much sense.

   Extension mechanism is very different than YANG extension
   mechanism and cannot keep same modularity as in YANG.

   The expectation was that modularity would be the same,
   similar to MIB modules.

   The consensus is to build individual module translations, if
   possible Ladislav Lhotka will try to do this, and discuss
   further in the second session.

   If DSDL cannot do this, then maybe we should scrap DSDL.
   DSDL is designed to do validation, not data modelling.

   Positioning: charter calls for a mapping from YANG to DSDL
   YANG is normative; DSDL converts to machine-friendly format
   One way mapping from YANG to DSDL; no DSDL-to-YANG mapping

   The consensus is to adopt this as a WG draft, but this will
   be confirmed on the mailing list.

   Details:

   - Issues:
     1. DSDL is to be used as one of:
        a. a data modelling language
        b. ad-hoc DSDL schemas for specific mostly short-term
           purposes like PDU validation
     2. DSDL mapping will be developed as one of:
        a. mere convenience for those who don't understand YANG
        b. interim validation method before native YANG tools are
           written
        c. substantial component of the NETMOD box
   
   - Phil Shafer: Problems I see; the tree you're building is a
     combination of YANG modules for a box.  You can't reuse it
     to a different box.  Isn't there a way to do it in a
     per-YANG module way?
     - Answer: I don't see it as a benefit to publishing yet
       another language (in addition to the existing schemas).
   - David Partain: so you're saying you don't see the utility of a
     YANG module translated into DSDL by itself.
     - Answer: It depends on the situation
   - Phil Shafer: can't you create one DSDL file of the base
     stuff and import it into the second and combined they
     should be able to validate successfully?
     - Answer: it doesn't have that functionality [importing]
   - Phil Shafer: we were told this was possible in the
     bakeoff when we selected DSDL
     - Answer: you can do it, just not in the same way as you
       can in YANG modules.  This is intended for ad-hoc
       combinations of schemas.
   - Sharon Chisholm: I think it is possible because you could
     do it by hand; the question is how toolable it is.
   - David Partain: we need to make it work because people are
     assuming it.
   - Martin Björklund: can you take the hand crafted version
     of each and validate what comes from the box?  I don't
     think it's possible.
   - Andy Bierman: separate modules are possible in XSD
   - Ladislav Lhotka: we are not building a DSDL data modelling
     language so we need to cope with the language
     restrictions.
   - Phil Shafer: so you disagree it's possible in XSD?
   - Ladislav Lhotka: what would you do with the top level
     augment in XSD?
   - Martin Björklund: I think it does work in XSD
   - Phil Shafer: so if we assume it's possible XSD you're still not
     sure if it's possible in RelaxNG?
   - Ladislav Lhotka: It's explained in the draft why this was chosen
   - Sharon Chisholm: I hear consensus is that we should see
     if it's achievable and we should try unless we run into
     problems
   - Bernd Linowski: What does DSDL guarantee? Does it assure me that
     what's handled by DSDL will be accepted by the agent?
     - Ladislav Lhotka: Yes it should be; that's the goal.
     - Bernd Linowski: Is it the goal or guaranteed?
     - Ladislav Lhotka: The mapping is not finished so I can't
       promise; as far as I can tell it'll be possible
     - Balázs Lengyel: How can you achieve that validation?  I
       doubt that can be done without the knowledge of the current
       datastore.
     - Ladislav Lhotka: This has to be clarified for YANG itself
       too.
     - Sharon Chisholm: Client side conformance needs to be
       marked in the document.  There can be a first level check
       defining what the client must include in a request.
   - Ladislav Lhotka: I'd like to see [DSDL mapping] this as a
     long term component of YANG
   - Phil Shafer: I think the problem is that the mapping is a
     top-down system.  Maybe it's possible to translate a YANG
     module into a fixed set of patterns into a non-standalone
     RelaxNG file and then in a per-device sort of schema tree
     make a single top-level file that imports all the piece that
     that particular device implements (DSDL files).  Then the
     rules are put into the appropriate place in your schema
     tree.  IE, do a per-YANG module translation once but
     building the tree as needed based on each translation.
   - Ladislav Lhotka: I was not going to create a bunch of DSDL
     files to be done to be published to be reused.  You have to
     tell it in the schema what exists in the device.
   - David Partain: we have a fundamental decision we need to
     make.
     Is the target a union of all the YANG documents on the box,
     or create each YANG document and translate it into something
     that can be reused.  Or some hybrid.
   - David Harrington: in SNMP we have MIB modules.  putting them together
     into a DB is the job of an application.  Trying to build a
     "super-model" is the job of an app; we should be striving to
     do a translation of a YANG module into a dsdl module.
   - Bert Wijnen: same statement.  One module to one module and
     don't build a "super-model".  If we have 5 different boxes
     from 5 different vendors we need to build 5 different DSDL
     modules.
   - Phil Shafer: responding to David Harrington: the validator
     is the application.  We need to build this for it.
   - Balázs Lengyel: it would be nicer to have a 1-1 mapping,
     that's not the question.  The questions is can it be done?
   - Bert Wijnen: if it can't be done, then lets not waste our
     time on it.
   - David Partain: reads from the charter and declares the
     charter says it's a mapping item not a modelling item.
   - Phil Shafer: this all seems to be saying we don't know
     enough about relaxng
   - David Harrington: it was the intention of this working group
     to create a substantial component of the NETMOD tools.  DSDL
     is a data-modelling language actually.  We're trying to
     convert YANG to DSDL so apps can use it internally as a
     model.
   - Ladislav Lhotka:  We do modelling in YANG, after that DSDL
     can be used for validation and for this it is good. DSDL is
     not so good for modelling, we have YANG for modelling
   - David Harrington: so are you saying DSDL limits the choice of
     applications?  The data modelling has to be done in YANG;
     then the DSDL mapping can be used to translate things.  If
     you can use the schema then go ahead.
   - Sharon Chisholm: I've never understood defining this as a
     mapping.  If you just define DSDL as a verification method
     then you don't need to worry about readability.
   - David Partain: as long as you don't put anything into the
     DSDL stuff that isn't in YANG, then you're fine.
   - Sharon Chisholm: it's a real one way mapping and a
     theoretically bi-directional mapping
   - David Partain: I think that's the criteria that should be
     used.  If it's not in YANG, it doesn't go into the mapping
     work.

  - Technical issues
      * Identify parts of mapping that can be done quickly
      * Start WG discussion remaining parts
      * Pending changes to YANG will affect the results
      * RelaxNG syntax: XML vs compact
        - proposal is to use XML for specification
        - does not preclude compact from being used though
      * annotated RelaxNG vs standalone schema
      * Should all YANG module metadata (contact info) be copied
        to DSDL schemas.
        - Sharon Chisholm: copying multiple fields into a
          single core field?
        - Ladislav Lhotka: two options: put a reference or a
          straight copy
        - Sharon Chisholm: copying everything makes the
          most sense
        - David Partain: agree
        - Martin Björklund: should be done, but tools could
          turn it off

  - Consensus for adoption of DSDL as starting WG item

    - How many have read the DSDL draft: 11
    - How many believe it should be adopted: 8
    - Anyone oppose adopting this: 1
    - Abstain: 1
    - We have rough consensus in the room; verify on list.

  Open mic (30 minutes) 

    - David Harrington: I'm stepping down as co-chair due to
      day-job requirements. David Kessens will be the new chair
      which keeps the dave and dave chairs consistent and first
      names don't break.

    - Dan Romascanu: Interim meetings are being heavily discussed
      and there is a procedure for organizing future meetings.
      Interim in Malta: NETMOD not interested, but didn't matter
      since IESG cancelling Malta meeting.  Desire to improve
      virtual meeting support

    - Balázs Lengyel: There is a substantial change between -01
      and -02.  'must' and 'when' can't check state data.
      * Martin Björklund: this is an open issue for tomorrow

    - David Partain: there has been a lot of stuff on the list.
      But people are now saying that enough-is-enough.  It's time
      to stop adding stuff to YANG.  I think we can safely
      declare consensus that there won't be any more features
      added to YANG after this week.  we will instead focus on
      finishing the document after today and we will fix bugs and
      get the document out the door.

      - David Harrington: that doesn't mean you should get all
        your new features proposed by tomorrow.
      - David Partain: as things go right now we want WG last
        call after the next IETF.

      Feature freeze is in effect!

    - David Partain: Important things that need to happen with YANG:
       - Fresh eyes needed outside the core team
       - Hopefully without doing this through last call
       - We'd greatly appreciate full reviews of the YANG document
    - David Harrington: I'm disappointed in the decision to do it
      after the next IETF.  I'd rather see it go to last call
      before the next meeting.  If it's stable, it should go
      quickly.

FRIDAY, Nov 21, 2008 0900-1130 
MP3 recording at ftp://videolab.uoregon.edu/pub/videolab/media/ietf73 
file:ietf73-ch4-fri-am.mp3
Jabber: http://jabber.ietf.org/logs/netmod/2008-11-21.txt

Session goal: Open Issues in NETMOD, and proposals for added functionality

  Open issues and questions for YANG/YIN/XML/LIB - Martin (60 min)
  slides: http://www.ietf.org/proceedings/08nov/slides/netmod-5.pdf

  1. How do we represent canonical form?
  
  - David Harrington:  concern that all the patterns don't
    clarify which format is returned; prefer is just a single
    pattern.
  - Suggestion that in a standard a single form should be goal, not
    flexibility
  - The more patterns supported the more likely a mismatch between
    lenient/non-lenient implementations
    Dan Romascanu agrees.
  - Jürgen Schönwälder:  there are no IETF standards for
    canonical forms of some of these data types today
  - Bernd Linowski:  prefers alternative 3 (see slides), since it
    can be more easily checked; reduces redundant definitions of
    the patterns.
  - Andy Bierman:  what is the pattern for accepting mixed case
    DNS names when canonical is all lower-case?
    - Answer:  both would have to be specified  (Jürgen
      Schönwälder: 'complicated')
  - Wes Hardaker:  we should limit what we want to allow to what
    is known to work, however if we want operators to be able to
    edit the XML you have to allow multiple patterns.
  - Phil Shafer:  suggest adding 'canonical = true' under one
    pattern, rather than repeating the pattern (addresses
    Bernd's concern above)
     - <Martin Björklund shook his head - seemingly in disagreement>
     - this would impact previous decision that patterns are 'ANDed'
  - Jürgen Schönwälder:  order of prefs:  1, 3, 2
  - David Partain: leaning towards 1, since the text in the
    description clause is clearer; concern that errors will still
    occur anyway.
  - Bernd Linowski:  concern that the canonical reference won't
    be clear

  Votes:
  Alternative 1:  2
  Alternative 2:  4
  Alternative 3:  7   (general preference)
  Alternative 4:  1
  Alternative 5:      (suggestion to add 'canonical' to the
                      pattern; but validates the 'and'ing)

  Action (Martin): take it to the mailing list, suggesting a
  syntax leaning towards 3

  2. Keyref vs. leafref

  - Phil Shafer:  there was a problem yesterday about must
    expressions on config data, does this address this?
     - No
  - Balázs Lengyel:  Question:  can you require instance true on
    state data?
     - Yes, in a grouping
  - Andy Bierman:  when are 'must' statements in non-config data
    evaluated (there is no commit performed)
  - Balázs Lengyel:  Question:  can we allow constraints on state
    data that would make the config invalidate?
     - No, the state data must point to instance data in the
       running datastore

  Hum result:  in favour.  Conclusion:  moving forward with this
  idea.

  3. Conformance statement

  - Balázs Lengyel:  concern that YANG is adding too many levels
    of optionality (already have features, when, capabilities, ...);
    can we just use feature instead of conformance?  Martin
    Björklund agrees.
  - Andy Bierman:  feels a complete view of conformance is
    needed, in one place;  but that a solution can wait until
    later.
  - Sharon Chisholm:  doesn't see value, only complexity
  - Jürgen Schönwälder:  feature can handle, this can wait (if
    needed later)

  Vote:
  Proceed:  0
  Don't proceed:  All votes

  Conclusion:  will take recommendation to the mailing list to
  table this for now.

  4. schema discovery  (YANG monitoring usage definition)

  - Andy Bierman:  doesn't think submodule is needed since it's
    contained in the parent module
     - Do need it, to advertise where the submodules are located.
  - Mark Scott:  suggest adding 'location' to the YANG
    description for completeness (and to better explain why YANG
    needs to explicitly define this - as the means to
    locate/retrieve the schema files).
     - It is part of the monitoring data
  - Phil Shafer/Andy Bierman:  do we want to explicitly identify
    module/submodule in the schema list entries
      - No, a parser will have to figure out dependencies itself
         anyway
  - Andy Bierman:  YANG must specify how the capabilities will be
    advertised

  Vote:
  In favour:  9
  More work:  0

  Conclusion:  Accepted as is.  The YANG draft must say how
  and what to advertise in the hello message.

  5. Inline <rpc-error> in <data>

  - Wes Hardaker:  prefers option 2, easier to parse top level
    looking for error tags
  - Balázs Lengyel:  ensure this applies to all RPCs, not just
    base RPCs
  - Phil Shafer:  option 2 (see slides) preferred, simpler to
    write scripts since nodes in error will be missing in top
    level parsing
  - Chris Elliot:  see some benefit in both, but prefer it to be
    taken to mailing list
  - Balázs Lengyel:  will this impact NETCONF or is it purely
    YANG matter?  This likely belongs in NETCONF spec.
     - It will be addressed in the RFC update.  Currently is
       not clear.
     - Needs to be done in YANG (clarity for YANG), NETCONF
       and likely other DMs

  Vote:
  Option 1:  0
  Option 2:  7 (consensus)

  Action (Martin):  take it to ML for further discussion

  6. assigned-by

  - Andy Bierman:  what if there are complex conditions that
    cause system to decide to create or not?
     - you wouldn't use this, you would specify in the
       description clause
  - Phil Shafer:  you wouldn't turn this on, even if an option
    that it will be assigned.  SO what is this for?
     - for a leaf with 'assigned by system' what is the client
       behaviour expected?  Client will know that the server will
       assign it, and is expected to re-fetch it (to determine
       the value)
  - Balázs Lengyel:  you don't have to re-fetch it, you just need
    to know that the system will assign it - Balázs Lengyel: this
    should be applied to keys as well?
     - A:  No, otherwise it complicates knowing which key was
       assigned
     - counter:  there are systems which assign keys for clients,
       without client knowing (suggest discuss offline)
  - Andy Bierman:  must be filled in, or may be filled in?
     - A:  may
  - David Partain:  concern that this is ambiguous?  Does this
    get filled in on reported information?
     - A: (none)
  - Sharon Chisholm:  thinks this aligns to the client side
    conformance ('must use' clause) to allow clients to know what
    must be specified and what does not need to be
     - A:  mark the leaf as mandatory to achieve this;
  - Andy Bierman:  this problem goes away when 'with-defaults' is
    added to NETCONF
     - comments in room that it does not go away
  - Sharon Chisholm:  there are 2 types of defaults:  sparing,
    system-defined
  - Balázs Lengyel:  supports the feature, but thinks it requires
    more discussion

  Vote:
  In favour: 6 (consensus)
  Not in favour:  0

  Action:  Take it to the mailing list, suggesting text and rules
  for this.

  7. create-only for leafs

  - Sharon Chisholm:  suggested different way to do this;
    over-ride max-access as an alternative?
  - Phil Shafer:  Is there a concrete example of why this is
    needed?
     - doesn't seem to be one
  - Balázs Lengyel:  Supported this be added:  ATM or SDH data
    where the termination point cannot be changed once created?
     - Cases where editing resulted in an implicit
       delete/recreate, which you wanted to prevent
  - Bernd Linowski:  there are cases where delete and recreate
    must be performed, and would like to use this to indicate
    those cases
  - Phil Shafer:  thinks this cannot work
  - David Harrington:  concerned that we are adding little
    features that are maybe not needed; i.e., couldn't this be
    added in a description clause
  - David Partain:  table this until we get concrete examples,
    then consider for a 1.1

  No vote.

  Conclusion:  Exclude from 1.0.  Those who want it can table for
  1.1 list.

  8. Actions/RPC in list

  - David Harrington:  clarified this doesn't 'simply access
    control' but it 'aligns with access control YANG has in mind'
  - Andy Bierman:  this is too complicated and can wait until 1.1
  - David Partain:  this should be in 1.0
  - Balázs Lengyel:  needed for current models
  - David Harrington:  concern that this would impact the system,
    and that is hasn't been discussed sufficiently
  - Wes Hardaker:  likes the idea, but concerned it will take a
    while to get it right;  thinks it can be deferred to 1.1 and
    can be solved with hierarchical definitions today
  - Mehmet:  useful feature and makes it possible to map to XSD,
    and sees no problem with it;  thinks it should be added
  - Andy Bierman:  Q:  can an action change the candidate,
    running or startup config?  A: Yes, acts like a normal RPC
  - Wes Hardaker:  concern it impacts readability
    - Balázs Lengyel:  thinks the YANG is more readable and takes
      priority over the XML readability
  - Jürgen Schönwälder:  this needs a new NETCONF capability,
    should not be part of YANG, and should be deferred
  - Phil Shafer:  this doesn't add value, it's just another way
    to do RPCs;  concern it is less readable, args are repeated
  - David Partain:  does increase readability but there are orgs
    who work this way right now; in interest of having them adopt
    YANG it should be included now
  - Balázs Lengyel:  you can most (all?) of the things with RPCS,
    but want we want here is hierarchical representation;  don't
    see the other concerns
  - Chris Newman:  looks like a mix of controller and model;  why
    not define as DM refs in the RPCs, rather than mix the
    control and data
  - Phil Shafer: this works for trivial cases.  In cases where a
    operation affects multiple things this doesn't work?  A:  why
    not. the operation can impact other things without being
    explicitly defined for each - no?
    - suggest top-level RPCs be used in those cases
  - Andy Bierman:  is action allowed to be nested within
    containers?  etc., i.e. highlighting there are questions to be
    answered.

  Vote:
  In favour:  4
  Not in favour:  7

  Conclusion:  No consensus for feature, not considered for 1.0.

  9. Remove some CLRs
  
  - This needs to be taken to the mailing list.

  10. typed extensions

  - Jürgen Schönwälder:  Not needed in 1.0
  - Martin Björklund:  this is needed and not a significant item
    to develop
  - Phil Shafer:  doesn't think this is needed;  Q: if you don't
    understand the extension do you care about it being defined?
    - A:  saves documentation associated with each extension type
  - Phil Shafer:  argues it's the semantics more than the syntax
    that matters
  - Andy Bierman:  Q: what about extensions that are containers
    and expect other extensions as leafs?
    - A:  answered in another set of slides
  - Phil Shafer:  Q:  who is helped by this?  those who implement
    the extension, or those that do not?
    - A:  those who implement since it explicitly defines the
      args
  - Andy Bierman/Jürgen Schönwälder:  extension args as strings
    are OK

  Vote:
  In favour for 1.0:  5.5
  Not in favour for 1.0:  4

  - David Partain:  concern that the second slide (and additional
    content) is too much (use-in, substatement, occurrence)
  - Mehmet Ersue:  proposal is to have minimal content (first
    slide) in 1.0; rest can wait
  - Ladislav Lhotka:  this should not be in YANG, but should be
    in the meta language

  Vote:
  In favour for 1.0:  3
  Not in favour for 1.0:  7

  Consensus - not in 1.0

  Open issues and questions for DSDL (30 min)
  slides: http://www.ietf.org/proceedings/08nov/slides/netmod-2.pdf

  "Super-model" versus individual mapping
  
  - Ladislav Lhotka: Modularity of YANG can be emulated. It is
    complex, probably 1 YANG model goes to many dsdl. It will be
    complicated.
  - Martin Björklund: It will not be so complicated.
  - Sharon Chisholm:  based on how we expect these to be used, the
    super-model/super-schema might not be used

  Action: Lada will discuss his thoughts on the mailing list.

  - Phil Shafer:  text has already been added to the arch draft
    for validation (raised at interim)
  - Andy Bierman/Jürgen Schönwälder:  the agent validates, not
    the manager (that's implementation detail)
    - Phil:  disagree, manager must also validate
  - Jürgen Schönwälder:  Q:  how does DSDL help with a
    non-yet-present interface?
    - A:  it doesn't.  (though please clarify question)

  Compact versus XML syntax: XML syntax accepted

  - Sharon Chisholm:  XML syntax is preferred, and better suited
    to more informative error messages

  Copy all meta data into DSDL schema agreed (as documented in
  first session notes).

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: David Partain <[email-masked]>
Date: Fri, 19 Dec 2008 22:12:14 +0100

Hi,

I've now submitted these.  Thanks to all of the notetakers!

Cheers,

David