Review of status:

 - One document that's close to finished 
 - A couple more documents are going to WGLC some time soon after
   this meeting.

Sharon Chisholm asked specifically about here draft on this regard.  


David Harrington on "Guidelines for Considering Operations and Management of New
Protocols"
 - Still needs help with the document to clarify text.
 - Dan: push back on the mailing list to get feedback.  This is
   one of the most important documents in this particular working
   group.

David Harrington about the XSDMI work...

  Some people think we need it, some people don't think we do.
  The question is whether there should be two different XSD
  formats for SMI-based data types.  Since NETMOD is focusing
  solely for NETCONF, that doesn't make YANG a good choice for
  the work here, which is supposed to be generic for management
  purposes, not just for NETCONF.

  Dan Romascanu: both the XSDMI and the YANG work are chartered
  items in the IETF.  So, that they might end up with two things
  may be a fact of life.  One shouldn't slow down the other.
  Getting to one standard representation is a very desirable
  goal.

  David Partain:  this document covers only the base types in
  RFC2578 and I see no problem.  If we are talking about the
  TEXTUAL-CONVENTIONs, it's going to be a much trickier thing.

  Jurgen Schonwalder: I don't see in the charter what it is we're
  supposed to be doing.

  Chairs: we'll talk about the charter later.

Loa Andersson: oam-acronym-soup-00.txt

  There is no draft.  Loa has started working on MPLS-TP (transport
  profile).  When you start looking at all of the documents, you
  get a very large number of acronyms.  Just the use of OAM, you
  get a bunch, and it's not clear that all of them encompass the
  same thing.  We need something that is more precise.  It has to
  cross at least the IETF and the ITU.  We will write a short
  draft that tries to clarify this.

  Scott Bradner:  the issue wasn't only what it meant in a
  literal sense, but also what does it mean in a practical sense,
  the work that actually gets done and the tools that get used.

  Ron Bonica:  there's something more subtle than the acronym.
  In the internet world, OAM means one thing and in the MPLS
  world it means something else.  Very different animals.  The
  MPLS world can tell what's happening with the MPLS LSP before
  the users even know about it.  

  Loa Andersson: target is to get something useful for MPLS-TP.
  If it gets wider acceptance, that's fine.  Dan suggested it be
  done in this working group, which Loa thinks is good given
  the workload they already have in the MPLS-TP work.

  Scott: timetable for first draft?

  Loa: half way to Minneapolis.  We have a harder deadline where
  this is one piece.  Study Group 15 will have a meeting in Oct
  2009 where a certain set of documents is completed.

  Scott: how are we going to ensure that what's in the document
  works for both organizations.

  Loa: the agreement with the MPLS people is to use the IETF
  process 100%.  When we accept the document as a WG document, we
  tell the ITU-T.  When we go to last call, we'll tell the ITU-T
  as well.  There will be a required response from the ITU-T.

  Scott: the pen is here, and the process is here.

  Dan: If we want to include this document, we probably need to
  understand the process you describe as well?  Do we tell them
  that this document is now underway?

  Scott: we can certainly publish it on the relevant mailing
  list.

  Loa: my collegue from the ITU-T will be co-author, so there's
  no way that they won't know that the document is underway.

  Loa: about chartering... there is a standard paragraph we've
  used elsewhere that you can just plug into your charter if
  you'd like to.

  Scott: asked the question whether the group thought this was
  reasonable work to take on.  Several hands for "yes", none
  (that the minute taker saw) for "no".

  Scott: we'll work with the ADs to get the charter updated.

Jurgen Schonwalder:  SNMP Notifications <-> SYSLOG

  Ron Bonica: generally, access to SYSLOG is much more tightly
  controlled than access to SNMP-based data.  What do we do with
  that?  

  Jurgen: SNMP has access control as well.

  Ron Bonica: so the caveat will have to be that SNMP has to be
  secured.

  Dan: all of our MIB documents have standard words that say you
  have to be careful.

  Wes Hardaker:  the MIB looks a lot like the Notification Log
  MIB.  Will it be logged in both places?  

  Jurgen: This is not a log MIB.  The reason there is a table is that
  we assume that some notifications might be missed, so we want
  to make it possible to retrieve the information you missed.

  Wes Hardaker: I assume the rolling of the table is handled.  

  Scott: Should we take this on?
  
  Lots of hands (more than half the room), no "no"s.

Chairs: charter discussion

  The charter is not very explicit about what can / cannot be
  done.  The goals & milestones are added after due consideration
  by the WG and the IESG.

  The Charter doesn't even mention the XSDMI work as a
  deliverable, so we need to fix that.  That addition should be
  careful about what we are to do now and what we going to add.

  Jurgen Schonwalder:  we need to know what the scope of XSDMI
  work is.

  David Harrington:  I believe that the dicussion in the BOF
  included 2578 and 2579.  Want this 

  Jurgen Schonwalder:  wants to think in terms of how it's
  useful.  Operators aren't served well by having multiple
  definitions.

  David Harrington:  one of the authors thought that they could
  "improve" the definitions in the SMIv2.  That was shot down.

  Dan Romascanu: disagrees with Jurgen S. and Dave Partain, and states we have a
  history of creating new things over time and deprecating the
  old definition. 

  Scott Bradner: Are there things in YANG that are stable enough
  to use now?

  Dan Romascanu: My feeling is that there are not.

  Ron Bonica: who is clamoring for this?

  David Harrington: we want access to SNMP-based information using
  XML.  Company (reference to his employer) has implemented the MIBs, and they want to access
  the information using XML-based access.

  Sharon Chisholm: this has come up in the NETCONF WG where we
  needed things like IpAddress.  Doesn't think that they have the
  requirement.  

  Ron: so, David H wants to be able to use NETCONF without YANG
  and Sharon thinks it's fine but is not particularly important
  to have compatibility with the SMIv2.

  Balazs Lengyel: I don't see who wants to stick to strict
  translations of SMI?  Perhaps the NETMOD data types draft could
  be used.

  Dan Romascanu: suggest that we add "Represent SMIv2 base types
  and TEXTUAL-CONVENTIONs in XSD." to the charter.

  David Harrington: we have to have everything, not just the base
  types and the TCs.  So we need to do all of the documents that
  cover SMIv2.  Believes that there can be two tracks.

  Jurgen Schonwalder: there is no way to do hand-crafted
  translation of MIBs or TCs; it needs to be automated.  There
  are some things that are very difficult, such as handling the
  DISPLAY-HINTs.  There is a lot of common core.  We should have
  a plan on how we're doing it.

  Sharon Chisholm: if we are talking about translation from A to
  B, we have to know what translation 

  Phil: Does it make sense to delay until we know where YANG is
  going with this?

  David Harrington: we want to be able to write models now.  We
  can't delay.  He doesn't think we should delay at all.

  Ron Bonica: after all the discussion, it appears to be a
  discussion of scheduling.  So we need to hammer out a
  compromise.  When can the NETMOD work be used?

  David Partain: we could start now.

  Jurgen S.: it's much more complicated.  We have to have the
  translation rules.

  Ron Bonica: if the XSDMI effort used to the output of the
  tools, would that solve the problem?

  David Harrington: that's exactly what the first revision of the
  document did: document what libsmi does.  We're trying to keep
  track of what's happening with YANG.  We haven't touched the
  TCs or the structure.  I believe that Jurgen S. said that if you
  translate from SMI to XSD, you get one result.  If you go from
  SMI -> YANG -> XSD, you get a different one.  

  Jurgen S.: are we really trying to specify the whole translation rule
  set from SMI to XSD?  That's a very large effort.

  Ron: what about handing the document to a translation tool, if
  the translation is ok, we're done.  He doesn't care what tools
  are used, only about the result.

  Dan Romascanu: Why not let them run here in the OPSAWG and then
  publish as experimental, then hand that to NETMOD and hope that
  they can stick to it.  Any changes then get back to OPSAWG and
  perhaps it can be updated.

There was discussion and decision/direction from ADs to update draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt as experimental, provide that document to YANG as input for their TCs.  Wen the YANG work is complete, incorporate that into a new version of Bob Natale's doc and move that forward as the proposed standard.  The discussion also acknowledged that this approach may require more the one update to Bob's draft.  Bob was not there to comment on this discussion.)    

  Dan Romascanu: Wants to add this to the charter, go ahead, if
  it turns out that YANG is getting finished within the same time
  frame, then we harmonize and adjust.

  David Partain: I'm fine with that.

  Ron: and what if we get to the end of this and they're
  different?

  Dan Romascanu: we don't approve the RFCs until they're
  harmonized.

  Ron: ok, good.

  David Harrington: if we get to the point where we have two
  options, do we choose the one that offers strict translation or
  improvements.

  Jurgen S.: a translation is a translation.  

  Jurgen S.: clarification: So full translation of SMIv2 to XSD will now
  be added to go to experimental.

  Scott: clarification: the NETMOD working group has no document
  to produce that "competes" with this work.


Meeting adjourned