Subject: [netmod] Prelimary Meeting Minutes from IETF 74

From: David Partain <[email-masked]>
Date: Thu, 16 Apr 2009 08:30:22 +0200

Hi,

Please find the preliminary meeting minutes below for both sessions.  Please 
send me any corrections.

Cheers,

David

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IETF 74, NETMOD WG  Monday, March 23, 2009  17:40-19:40
David Kessens, David Partain    About 25 attendees

WG status and Agenda Bashing (David Partain)

  The working group will have two sessions so there will be lots
  of time to address any issues and to make good progress. Drafts
  are available for all work items, but not quite following the
  proposed time line. The NETMOD architecture draft is rather
  late so that one needs to get special attention.

Notes: Phil Shafer, Alan Luchuk, David Reid, and Balazs Lengyel
Jabber: Will Ivancic

-------------------------------------------------------------

NETMOD architecture document discussion: Phil Shafer

  David Kessens: Who read architecture? 15 hands.
  Ca. 1/2 the attendees have read the draft.

  Phil Shafer: Comments mainly to remove stuff. Is this good
  enough?

  Andy Bierman: Happy with the document. I am missing a NETCONF
  architecture, but for current scope fine.  It doesn't say
  things that are out of scope.  No unreasonable assumptions.

  Balazs Lengyel: It is in good condition.

  Mehmet Ersue: looks good.

  General consensus is that the new document is much improved.

  General consensus is that the new doc is ready for last call,
  after minor edits.

  Balazs Lengyel, David Partain, and Dan Romascanu have comments
  on the draft.

  Several people asked for a NETCONF architecture document also.
  David Harrington would like to petition the NETCONF WG for such
  a document.

  ?? (sorry, missed the name): I am interested in writing NETCONF
  architecture. This is fine for NETMOD, but would like something
  with a wider scope.

  David Harrington: NETCONF WG should write NETCONF architecture.

  Dan Romascanu: NETCONF architecture should be done in the
  NETCONF working group. NETMOD architecture is needed to show
  why YANG is needed and how YANG should work together the other
  components. We can start discussions for a bigger document in
  NETCONF WG.

  David Partain: How many people who read it think it is OK to go
  to WG last call. Most of them. (13?)

----------------------------------------------------------------

Common YANG Data Types document discussion: Martin Björklund for
Jürgen Schönwälder (who was on jabber)

  How many have read the document: about 10

  Summary of changes was presented.

---------------------------

  Discussion of XPATH type and versioning

  Ladislav Lhotka suggested xpath1, matter a preference; suspects
  there will not be more than 2 versions for quite a long time.

  Wes Hardaker suggested xpath1.0 because it is easier to extract
  and compare numerically.

  Ladislav Lhotka: There won't be any XPath 1.1 so there is need
  for xpath1.0.

  David Harrington: How does XPath define version number Martin
  Björklund: 1.0 David Harrington suggested following an existing
  standard numbering scheme

  Consensus: Show of hands 6/4 for Xpath1.0

  --------------------------------------------------------------

  Canonical form of an XPATH expression?

  Proposal:  Don't define a canonical form.  Some concern about
  whether the lack of a canonical form will result in
  interoperability issues. Several people did not think it would
  be a problem.

  Phil Shafer: When is this needed?  What does canonical mean for
  xpath?  Rewriting axis?

  Martin Björklund: namespaces.  Martin Björklund: Filtering,
  keys in the database - problem is with prefixes, dependent on
  context.

  Andy Bierman: no axis in our uses of xpath (?).  No win in
  canonicalization.  The reason to canonicalize it is the agent
  needs to resolve the namespaces in the context of the config.

  David Harrington: If we don't have a canonical form, what about
  interoperability?  Can't depend on the agent and manager coming
  from the same vendor.  Could define crappy little rules that
  everyone should follow.

  David Harrington: XPath might be used for access control. If we
  don't have a canonical format will access control work?

  Ladislav Lhotka: It is not an interoperability problem. The
  XPath spec guarantees interoperability.

  Martin Björklund: Filtering keys, might not work?

  Andy Bierman: What about whitespace normalisation, tokens, self
  or descendant?

  Phil Shafer: is there a real use case?

  Martin Björklund: It is used mostly in protocol RPCs not in
  configuration datastore.  In the PDU context.

  Andy Bierman: NETCONF monitoring uses it.  This is no different
  than string identifiers.  The problem is not worse than a
  simple string.

  Phil Shafer: Namespace mappings should be explicit, not
  contained in the context.

  David Partain: we have a use case, since it's in documents that
  are already written.

  Martin Björklund: could be generated differently on each <get>.
  In theory you could generate different prefixes for every call.

  Ladislav Lhotka: Prefixes are not stable, they should not be
  used.

  Martin: Yes, but this datatype is better than nothing.

  Balazs Lengyel: could we specify/suggest prefixes that aren't
  100% but will help in many cases?  We need to explicitly say
  the prefix mappings (the prefix strings themselves) may
  changed.

  Ladislav Lhotka: the prefix means nothing, just represents the
  URI string.  Against prescribing a fixed prefix.

  Wes Hardaker: make two different datatypes, one for string and
  one where canonicalization matters.  Datatypes are cheap.

  David Harrington: can xpath expressions be interpreted
  differently?

  Martin Björklund: nope

  Ladislav Lhotka: discussion is moot because the xpath datatype
  is derived from string so there's no difference between xpath
  and string.

  David Partain: An engine can do something smart if it knows it
  is an XPath.

  Andy Bierman: Disagrees.  It helped in implementation.  The
  type is needed because trying to guess if it's xpath is
  expensive.

  Andy Bierman: The context and prefixes are a problem, and so
  canonical form is not needed/possible.

  Wes Hardaker: WG should not define canonical XPath, but if
  there is a definition use it. Most of the time we don't care
  for the exact match.  A search for 'canonical xpath' yields
  multiple matches. Proposed looking for a canonical XPATH
  definition, and reuse if possible, otherwise we cannot solve
  the problem.

  David Partain: Anyone for working on a canonical form?  None.

  Consensus in the room:  Look for an existing canonical XPATH
  definition and reuse it if such exists.  Otherwise, we do
  nothing.  Put the canonical form (if found) in a separate data
  type.

  --------------------------------------------------------------

  IPv6 Address Pattern?  Which pattern should be used?  Do we
  need a pattern at all?

  Ladislav Lhotka/Jürgen Schönwälder came up with a pattern that
  seems to work.

  Ladislav Lhotka: new revision works in Ladislav Lhotka and
  Jürgen Schönwälder tests; others should test it also.

  --------------------------------------------------------------

  Do we have to support all IPv6 address writing styles, or can
  we just use the canonical IPv6 address format?  (Slide 5)

  Ladislav Lhotka: If we allow it for IP address we should allow
  it here.  Ladislav Lhotka referred to an RFC standard.

  David Harrington: how does it affect interoperability?

  Martin Björklund: should have the same rules for addresses and
  prefixes.

  Ladislav Lhotka: allow both

  David Kessens as contributor: suggested a single format makes
  for simpler, more interoperable code.

  Martin: We are not inventing it here.

  Phil Shafer: Should be just as flexible for prefixes as for
  addresses. People use the shorthand, so we should support them.

  Jürgen Schönwalder: would like the flexibility.

  Hands for supporting all: 8 against: 1

  Rough consensus:  Support all IPv6 writing styles.

  --------------------------------------------------------------

  DNS expert advice is needed so we get the restrictions on the
  DNS label right and future proof.  People already discussing
  this.

  Once the DNS experts have had their say, Jürgen will propose
  the relevant change.

  --------------------------------------------------------------

  URI expert advice is needed to answer the question if it is
  safe to use the regular expression from RFC 3986.  Currently
  the uri type is defined as a string with restrictions in the
  description clause only

  David Partain will ask for expert review from apps area.
  (Editor note: This process is underway.)

  Jürgen Schönwälder: question is whether the regular expression
  in Appendix B of RFC 3986 can be used?

  Ladislav Lhotka: Using it in his code, and it seems to work.

  --------------------------------------------------------------

  IEEE Port List (slide 8) Suggestion to add a port list type
  (Jürgen Schönwälder)

  Suggestion to use a comma separated list of port ranges: e.g.
  1-5,8,10-22.  Ranges may not overlap and may not be
  consecutive.

  Andy Bierman: do not add type right now

  Martin Björklund: also do not add too much stuff

  Dan Romascanu: did not see a reason to add

  David Harrington remembers textual conventions for SMI to use
  standard formats.  Suggested defining a type consistent with
  other definitions, such as IEEE or SNMP to promote
  standardization.

  David Harrington: came from TC; don't know where it came from;
  people were defining VLAN lists and came up with multiple
  alternatives.

  Jürgen Schönwälder: TC is in the qbridge MIB but the TC uses a
  binary stream, each bit representing a port.

  David Harrington: a great deal of work was done; we should be
  consistent with that work; don't recall the bit stream stuff,
  but we can always add it later.

  David Partain: doesn't mind adding it as long as there is not
  extensive debate.

  Phil Shafer: This opens a lot of other issues, integer ranges,
  number of ranges.

  David Harrington: remembers a lot of effort and
  interoperability problems due to the lack of something defined
  for SNMP. Lobbied for adding this to YANG, but could come
  later.

  Dan Romascanu: discussion of bridge MIBs. Suggested defining
  later in YANG bridge modules.

  Dan Romascanu: some confusion, because this is trying to mirror
  work in bridge MIB but that MIB uses these as an index for
  tables.  More general concern: we are trying to sync with ietf
  MIBs but IEEE has extended those.  This should be postponed to
  bridge YANG basic module.  I see bridge as an early customer
  for YANG, but we can do more work then.

  Jürgen Schönwälder: Phil's questions are easy to address.
  Qbridge MIB. no definition, should be deferred, can define
  using port list TCs

  David Partain: consensus: defer until needed

  --------------------------------------------------------------

  Add Other VLAN types  (Slide 9)

  Jürgen Schönwälder: defer David Partain: consensus: defer until
  needed

  --------------------------------------------------------------

  Other comments/questions

  Phil Shafer: do not leave room until all open issues resolved,
  not all issues resolved.

  David Partain: two issues are open for expert review: 1. URI
  (uri datatype) (editor: underway) 2. DNS (domain-name datatype)
  (editor: underway) Also XPath canonicalization standards; if we
  find one we like, we'll define a new type "xpath-canonicalized"
  ((editor: discussion already on mailing list)

  Balazs Lengyel: customers want a port number of 0, meaning
  "wildcard".  Change explanation of port type, or define a new
  type?

  Phil Shafer: isn't this a perfect use for unions?

  Jürgen Schönwälder: port number 0 is not valid, a union might
  be a good solution.

YANG draft: Martin Björklund

  How many people have read -04: 10

  Summary of changes since draft 02

  --------------------------------------------------------------

  Order of XML elements

  Currently the draft specifies that all XML elements are encoded
  in the same order as specified in the YANG model

  Proposal:  remove this restriction, and specify that XML
  elements can encoded in any order.  This maps nicely nicely in
  RelaxNG.

  Andy Bierman: in NETMOD only, or in also in NETCONF?  NETCONF
  keeps the same ordering.

  Martin Björklund: perhaps only for application or layer 4.

  David Reid: why make the change?

  Martin Björklund: allow any order unless there is a good reason
  for the order to be specified

  David Harrington: why allow any way?  Why not require a
  specified order?  How will it affect interoperability.

  Andy Bierman: it's harder to enforce the order than to ignore
  it.

  Martin Björklund: single agent, multiple NETMOD modules, each
  has top level, why require forced order?

  Jürgen Schönwälder: most XML servers do not enforce an order,
  why should NETMOD?

  Phil Shafer: RPC input?

  Martin Björklund: Andy Bierman pointed out that it only matters
  at the "content" layer, not the "operation" layer.

  David Partain: consensus. do not enforce order (10 for, 0
  against)
  --------------------------------------------------------------

  Float vs. decimal

  A number of problems with the floating point datatypes have
  been identified on the mailing list.  Specifically, how are
  they handled by XPath, and the canonical type.

  Proposal:  Replace the float types with a (fixed point) decimal
  type.

  Examples/alternatives shown on slide

  David Partain:  Should we have floats or this other alternative
  (or both)?

  Wes Hardaker: If not needed now, why define it now?  Integer
  operations are always faster.  Jeff Case liked doing things
  this way.  But datatypes are cheap, so adding it now may be
  cheap.  But if there are no use cases, we could delay it.

  Andy Bierman: supports having integer type only, did not see a
  need for floating point.

  David Partain: question:  omit float for now?

  David Reid: Drop both?  1 for, 8 against.

  David Partain: consensus. Use decimal64 (10 to 0)

  Martin Björklund  - what should canonical form be?

  David Harrington: is the proposed canonical form standard
  Xpath?

  David Partain: vote : consensus (9 to 0): must be one digit on
  both sides of the decimal point.

  David Harrington: Is the 3.0 standard XSD/XPath

  Martin Björklund: 3.0 is standard

  --------------------------------------------------------------

  Other open issues?

  Andy Bierman: canonical version XML applies to Xpath (comment
  on Xpath discussion).

  David Reid: list with "foo", augmented with "foo" is clearly
  illegal. But if augmented with something from another module,
  this is in a separate module, and so is OK.  Martin Björklund
  proposed a rule which is fine.

  Andy Bierman: My code up to date with draft 04.

  Ladislav Lhotka: reserve "augment" to augmenting other modules

  Martin Björklund: discussion with use cases.  Submodules can
  augment submodules. Useful for distributed software
  development.

  Balazs Lengyel: We have use cases for submodules augmenting
  other submodules. We need the modularity without the
  namespaces.

  Ladislav Lhotka: another comment about augmenting

  David Reid: why wouldn't you want to augment something in the
  same module?

  Ladislav Lhotka: there are simpler ways, can't imagine a use
  case; becomes unreadable.

  Martin Björklund: submodules are to allow distributed
  authorship.

  Ladislav Lhotka: limit augments to something from another
  module.

  Balazs Lengyel: we put parts into different submodules and use
  augment to connect them.

  Andy Bierman: I sympathize with Ladislav, on the complexity
  side, but limiting augment didn't change the complexity.

  David Partain: vote: rough consensus: keep as is

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IETF 74, NETMOD WG  Wednesday, March 25, 2009, 0900 - 1130

Agenda Reviewed

------------------------------------------------------------------

YANG Types (revisited)

  Jürgen Schönwälder suggestion: Remove IEEE types from the
  documents, doesn't make sense to standardize a small set of
  types.

  Dan Romascanu: agrees with Jürgen

  Balazs Lengyel:  The MAC address is needed immediately Dan
  Romascanu: move mac address to another document?

  Consensus: (unanimous) move mac address to different document
  and stop working on ieee-types.yang for now.

------------------------------------------------------------------

Mapping YANG to DSDL: Ladislav Lhotka

Notes on recent publications

  00 in Feb, 01 on mar 8, many changes

  David Partain: How many people have read the draft?
  note taker missed the count; David Partain: 5-6

  Presentation on the draft (see slides)

  Open Issues:

  1) if-feature

  Martin Björklund: Question: couldn't the features be supplied
  as arguments as an alternative way of doing this?

  Ladislav Lhotka: put as annocation to the conceptual tree
  schema.

  Martin Björklund: I thought that would be simplier, it wouldn't
  generate nodes for features not available.

  Ladislav Lhotka: it could be done also.

  Martin Björklund: In the first step you specify modules a
  device implements and you know which features a device
  implements.

  David Partain: are you trying to create something that is
  useful across multiple systems?

  Ladislav Lhotka: Features will be fixed; same set of input
  modules that are transformed via the schema.

  David Partain: input is at second stage rather than the first.

  2) deviations

  Martin Björklund: I agree with Ladislav.

  David Partain: anyone else have opinions?  (no response)

  David Partain: consensus is then called as being what Martin
  Björklund and Ladislav want.

  Andy Bierman:  has questions about naming, but will send mail.

  3) instance-identifier type

  Ladislav Lhotka: options: EXSLT or XPATH 2.0, proposes EXSLT

  Martin Björklund: in xpath you can define your own functions,
  can you do that in EXSLT?

  Ladislav Lhotka: yes you can, but it only makes sense if the
  validator supports the functions.  I have to check the EXSLT
  specification but it is also supported by the libxml tools.

  4) Other targets for validation

  Ladislav Lhotka: certain document types can be validated; are
  there other types to be validated for the DSDL schemas?

  Martin Björklund: I think edit-config is a missing one in the
  list and possibly copy-config; copy config is difficult because
  there is no standard way of what the copy-config would be so
  unless we define one. It will be hard to define a schema for
  it.

  Ladislav Lhotka: discusses biggest thing to validate is output
  from get-reply.

  Phil Shafer: when you say data store I think configuration
  data.

  Ladislav Lhotka: get-config means config data, get means all.

  David Partain: anyone else want something other than
  edit-config/copy-config?

  (silence)

  Ladislav Lhotka: change in order of elements in data from
  Monday's meeting needs to be added to draft. Next version of
  draft will be complete and resolved all open issues.

  Martin Björklund: require-instance and instance identifier
  missing.

  David Partain: you're writing and implementing at the same
  time; excellent!  Your plan is getting a new rev during April?

  Ladislav Lhotka: yes

  David Partain: plenty of time for people to read by Stockholm.
  Perhaps we can even do a last-call about then.

  Andy Bierman: how are you doing naming?  you're putting module
  name as a type name or element name.  Is that really needed?

  Ladislav Lhotka: yes.  multiple reasons talked about (including
  "you can have clashes between different modules")

  Andy Bierman: is that why there is a top container and a
  container for notifications?  Why all the extra containers?  do
  you just like that better?

  Ladislav Lhotka: It's just easy to translate between schemas
  and is easier to implement in the tool.

  Andy Bierman: what about local typedefs embedded inside lists,
  etc.

  Ladislav Lhotka: these types defs have both the module name and
  the name of the container nodes.

  Andy Bierman: keep registry of names used and then add a new
  one (like a .1) to deal with conflicts

  Ladislav Lhotka: that could be used too.

------------------------------------------------------------------

netmod-usage-guidelines: Andy Bierman

  Documents guidelines for writing YANG modules intended for IETF
  usage.  Proposing writing a YANG usage guidelines to improve
  quality of YANG documents, and result in quicker passage of
  YANG modules.  To avoid issues at "Last Call".

  David Partain: How many have read it?  7-8

  Minor issues: the language is not constrained in places it may
  be helpful for tool support (e.g., identifier length).

  Andy Bierman: Options: 1) do nothing 2) published as a BCP

  Dan Romascanu: what "Last Call" issues are you thinking about
  when dealing with issues raised?

  Andy Bierman: there are lots of things (stated examples)

  Dan Romascanu: I'm very much in favor of this document.
  Suggest start by doing as Informational.  Come back after 1-2
  years of operational experience and revise it as a BCP.

  Andy Bierman: my approach was to include guidelines that had
  strong consensus.

  Dan Romascanu: we may get to the point to revise them because
  we may learn things down the road, certainly.

  Andy Bierman: we have experience to draw on from SMIv2 that
  will make some of these back by experience now.

  Phil Shafer: is the 63 chars really an issue?  Should that be
  solved in YANG, or is it ietf specific?

  Andy Bierman: you run the risk that the YANG module won't be
  accepted by the tools.  YANG says that 63 must be accepted,
  which means more can be dropped.

  Phil Shafer: but what about vendor module.  Let's fix in the
  YANG module.

  Andy Bierman: I want a fixed length identifier.

  Phil Shafer: I'd rather fix it in YANG.

  Andy Bierman: my fix is that it must be 63 chars or less.

  Martin Björklund: is your proposal to add to the main doc?

  Andy Bierman: I don't have a problem with YANG docs; I want
  this to deal with interop with the IETF documents not globally.

  Phil Shafer: does there need to be a bound?

  Andy Bierman: yes, so tools can be written that will work.

  Phil Shafer: what's the issue?

  Andy Bierman: buffering and memory.

  Wes Hardaker: tries to clarify discussion and agrees with Andy.
  Language should not be constrained, but should IETF have more
  tight restrictions within IETF for all tool writers.

  Phil Shafer: would this be something willing to do in an
  extension (eg: strict: true).

  Andy Bierman: I would rather not; I'd rather have a set that
  defines what the lower bound is.

  Phil Shafer: What about adding a YANG extension to add
  restrictions?

  David Partain: first step is to decide if we're going to have
  the rules, standardize the rules.

  Sharon Chisholm: (on jabber) I'm voting not to bake into YANG a
  length restriction and I don't like Phil's suggestion.  Whether
  we do an IETF-module practice of shorter length that we can
  change in 5 years is different. I don't mind that.  The
  extension just seemed to complicated than we needed.

  Andy Bierman: to my knowledge the 63 char limit is SMIv2 isn't
  a problem.

  David Partain: how many think we should work on this document?
  *count:* many hands for yes, none for no.

  David Partain: How do we do this?  recharter?

  Andy Bierman: what is the IESG going to do with a 50 page YANG
  document?  Skip it?  Create a yang-doctors group?

  Dan Romascanu: probably create a experts group

  Dan Romascanu: To issue of recharter: I'm not sure you need to
  recharter, especially if you go for Informational.

  David Partain: should this be a WG document straight away:
  *count:* many hands for yes, none for no We'll talk to Dan
  Romascanu about how to do it (informational vs ...) Andy will
  continue editing; anyone else can offer to help.

  Martin Björklund: There is a section called YANG registry
  section, do you want to keep that?

  Andy Bierman: no, I'm going to drop it.  The top level module
  needs a RFC number for each revision.

  Martin Björklund: does the top need to be published in an RFC
  or can it be IANA contained?

  Andy Bierman: no, conformance is tied to an RFC number not to a
  dynamic IANA registry.

------------------------------------------------------------------

netconf-module-00

(Editor's note:  This discussion was started in a previous
NETCONF WG meeting, but was continued with the consent of both
NETCONF WG chairs.)

  David Partain: Do we want to consider talking about YANG
  NETCONF module?  Andy ran out of time yesterday, can we
  consider discussing it now?

  NETCONF Chairs: Yes, that's fine.

  David Partain: last slide of NETCONF agenda.
  (http://www.ietf.org/proceedings/09mar/slides/netconf-6.pdf)

  Andy Bierman: surprised to see consensus for normative YANG
  going forward.

  Phil Shafer: I was suggesting adding an extension that says
  "this element supports these two attributes" and that's the
  meaning of this extension statement.
  YANG:this-container-supports-these-two-attributes:true

  Andy Bierman: I only want to support it for RPC elements and
  not in the data at all.  So that would be acceptable to me.

  David Partain: 3 options: use XSD, use YANG with attributes
  (change YANG to support XML attributes), use YANG with an
  extension for 2 specific attributes.

  Bert Wijnen: would there be a 4th option to remove it from the
  base spec?

  Andy Bierman: you're the code chair, it might open the box of
  other non-compatible changes.  I've got a ton of them.

  Bert Wijnen: how seriously would it get existing
  implementations in trouble?

  Martin Björklund: I'd rather not change it because it would
  affect existing implementations.

  Balazs Lengyel: we have a statement that any other elements can
  be added to an attribute.

  Andy Bierman: the proposal is this would only be used for

  Balazs Lengyel: But we keep the XSD for the RPC layer?

  Andy Bierman: that needs to be looked at, what happens to the
  XSD?

  Mehmet Ersue: I think we need to keep the attributes in NETCONF
  and we can not skip them.

  David Partain: what are the options we're taking to the mailing
  list?

  Ladislav Lhotka: I think the schema can't be used by any tools.
  It will claim a number of things are valid that aren't (gives
  examples).  Some of the problems can't be solved in XSD.
  (RelaxNG is better)

  Martin Björklund: if we do YANG, we have a standard mapping to
  DSDL so we get DSDL as well.

  Ladislav Lhotka: yes of course.  Long explanation followed by I
  don't think it's appropriate to use YANG for

  David Partain: unless we have an extension for the relevant
  attributes.

  Martin Björklund: it is appropriate to use for operations
  layer.

  Ladislav Lhotka: I see it as a natural way of using NETCONF
  modeling language for definition for NETCONF base module.
  that's better than introducing a third modeling language.

  Andy Bierman: if we don't have a YANG module, we can't augment
  it with YANG.  [stuff missed]

  David Partain: someone needs to write down what the options are
  and send to list.

  Bert Wijnen: Yes that's what we want; Andy will do it.  If we
  want to use it for RPC layer and not operations layer then make
  that clear.  Make clear that we will not do YANG for RPC layer.

  Andy Bierman summary: if RPC element is in YANG module then all
  elements are mirrored back.  For the agent it's not used at
  all.  Having a particular attribute called msgid in the PDU is
  a CLR.

  Martin Björklund: I really think we should not do the RPC layer
  in the YANG module.

  Andy Bierman: You're right. I do that with an extension.  it'll
  be removed in the next version and add an extension for the
  filter-element-thing.

  Phil Shafer: what's left in the XSD?  barely anything?  (yep)

  David Partain: do we want to do choices now?

  Phil Shafer: YANG will have all the guts.  XSD or RelaxNG will
  just have an element that will contain everything.  can we just
  write it as text?  The XSD is so small and has no value.

  Martin Björklund: it's easy to write and has a small value, so
  do it.

  Ladislav Lhotka: XSD is generic but RelaxNG can be much more
  helpful.

  Sharon Chisholm (jabber): considering this is a normative
  update, then keeping this as an XSD will help us determine what
  has changed.

  Phil Shafer: one of the things that has changed has is that we
  have YANG.

  Martin Björklund: we're not doing it for the fun of it, we're
  doing it because the original XSD has problems.

  Phil Shafer: one of the problems with XSD is that we didn't
  know what it did.  I have an issue with RelaxNG as well, I
  couldn't tell if it was right or not?

  Bert Wijnen: should we consider RelaxNG as a 4th or 5th option?
  Only two hands.

  Mehmet Ersue: we should think of future NETCONF modules that
  are trying to augment.

  Phil Shafer: which means that YANG has to own it.

  David Partain: how many think YANG has to be normative, or how
  many thing XSD has to be normative:

  YANG: 10 XSD: 1

  Andy Bierman: we need to think in a new way.  We need to
  understand that people pull these documents out of documents
  and use them in applications in new ways.

  Phil Shafer: will the YANG module be part of 4741bis?

  Andy Bierman and Martin Björklund: yes

------------------------------------------------------------------

Plans after this IETF?

  David Partain: Are we ready for WG last call on YANG/YANG data
  types?  Seems things are stable and believe we'll do a WG last
  call.

  Martin Björklund will publish a -05 in the next few weeks.

  Jürgen Schönwälder will publish types documents as well.

  Usage guidelines will be added as a WG document.

  David Partain: do people use XSD produced from YANG?  Two tools
  do that, should we have a document that defines that?

  Andy Bierman: Martin Björklund and I have been converging on a
  similar solution.

  David Partain: is there a chance of people actually writing
  that down?

  Andy Bierman: if we have enough people to work on it, it would
  be valuable.  I can't do it myself (there is a lot to write
  down).

  Ladislav Lhotka: also option of using auto-translation of
  RelaxNG to XSD, which would save cycles for this work.  It
  would be valuable for customers that want to do validation.

  David Partain: the mapping isn't standardized but there are
  tools that are industry standardized.

  Ladislav Lhotka: there are WWW tools that use RelaxNG

  Martin Björklund: I'd prefer that as well.

  Andy Bierman: the use case would be xmlspy that would construct
  the PDU contents based on the schema?  but xmlspy already uses
  RelaxNG, so...

  Martin Björklund: most people that want to do validation don't
  care which they have.  The DSDL schema is much more precise
  than the XSD.

  David Partain: so we don't need to do this (audience fails to
  say otherwise).

------------------------------------------------------------------

Open Microphone:

SMIv2 to YANG

  David Reid: previous agenda had it on it.  can we talk about
  it?

  David Partain: yes, but Jürgen Schönwälder isn't here.

  Andy Bierman: I read the draft and really support it as at
  least an informational RFC.

  David Partain: how many have read it?  *Count: 8-people*

  David Partain: how many think we should consider publishing it
  and work on it *Count: 10-people yes, 0-no*

  David Partain: anything for today?

  David Reid: there are a number of issues, maybe the mailing
  list would be better?

  David Reid: one particular topic of interest: In mapping a MIB
  table, he translates the entry to a list and drops the table
  (the "extra" container).  What I do is translate the list and
  put the list in a container.

  Andy Bierman: we should keep the "extra" container due to least
  astonishment.

  David Reid: I don't know of reasons beyond that, but there
  could be more.

  Ladislav Lhotka: I think list items should always be in a
  container and not loose.

  David Partain: David Reid, please send comments to the list.

  David Reid: what I do is similar so there aren't huge issues.

Floats revisited

  David Perkins: wants floats discussed

  Wes Hardaker: tries to summarize why David Perkins wants floats
  (+/- inf and NaN).

  Andy Bierman: doesn't like +/- inf and would rather return an
  error anyway.

  David Partain: bring it up on the list at this point after the
  minutes are posted.

Meeting concluded

------------------------------------------------------

---

From: David Partain <[email-masked]>
Date: Mon, 20 Apr 2009 13:18:21 +0200

On Thursday 16 April 2009 08.30.22 David Partain wrote:
> Hi,
>
> Please find the preliminary meeting minutes below for both sessions. 
> Please send me any corrections.

Greetings,

As I've received no comments, I assume that these minutes are accurate 
according to the collective wisdom of this working group.

Cheers,

David