Subject: Re: [OPSAWG] XSDMI

From: Ron Bonica <[email-masked]>
Date: Thu, 01 Nov 2007 15:35:26 -0400

Hi David,

The following is a possible compromise:

David progresses the XSDMI work in the OPS Area WG. Although the XSD
produced by XSDMI is made available to everyone, there is no mandate to
use it. This means that it the NETCONF community decides that XSDMI does
not fulfill their requirements, they will be free to specify something else.

All drafts progressed as XSDMI will be submitted for publication as
INFORMATIONAL.

Comments?

                              Ron

David Harrington wrote:
> Hi,
> 
> Juergen has raised the issue that the XSD produced by the XDMI effort
> and the XSD produced by the YANG effort might be different, and having
> two different XSD equivalents for MIB datatypes would be suboptimal. I
> agree.
> 
> However, I have the concern that while vendors wait for YANG to be
> completed, they will need to develop proprietary data models for use
> with netconf. Some vendors will want to reuse datatypes found in the
> 15 year compilation of IETF NM experience found in the standard MIB
> modules, and supported by existing implementation code. If they need
> to develop their own translations of existing SMI datatypes and
> textual conventions into XSD and XML, we could wind up with a variety
> of competing XSD specifications. 
> 
> The XSDMI work would provide reusable XSD equivalents of SMI datatypes
> and textual conventions. If vendors use these consistent XSD
> translations, then later work to derive standards from the proprietary
> information/data models would be easier because there would be
> increased commonality in the datatypes and textual conventions and
> semantics used to model the information.
> 
> In addition to proprietary data models, there are multiple IETF
> efforts to translate existing information models (often from
> ASN.1-based formats) into XML formats.
> draft-frascone-xml-dictionary-00 describes the Diameter "dictionary"
> in XML format; draft-legg-xed-roadmap-06.txt describes translating
> LDAP and X.509 directory information models into semantically
> equivalent XML renditions of existing directory protocols; IPPM is
> working on an information model in XML for traceroute measurements. So
> a MIB-related translation to XML is not unique.
> 
> The XSDMI effort is about taking the MIB, which operators have
> complained is not well suited to configuration, and translating
> aspects of the MIB into equivalent XSD. The fact that the MIB
> datatypes can be translated into XSD will not make the MIB more
> suitable for configuration; it will simply make reusable dataypes
> available in an XML-compatible format.
> 
> The netconf community should be focused on defining a data modeling
> language and data models for configuration. The YANG approach for
> netconf focuses not only on configuration, but also on developing an
> information modeling language which can then be used by tools to
> generate syntax-specific data models for a variety of purposes, such
> as Netconf-suitable XSD data models, SNMP-suitable MIB modules, plus
> data models for other modeling systems. I have a concern that the SNMP
> community has not been asking for this approach, and the IETF failed
> to reach consensus on the need for the information-modeling approach
> when it was presented to the SMING WG. If the
> information-model-generates-data-models approach is adopted by the
> IETF, then does that mean that efforts to use XML-based data models
> for ipfix, Diameter, IPPM, and LDAP should not be permitted until YANG
> can determine how to generate those data models as well?
> 
> Just to be clear, I support the YANG effort because I believe it could
> lead to better consistency of data modeling across protocols, but it
> has yet to be proven to be viable, and other efforts to converge or
> harmonize data models have had mixed success at best. We should not
> put all our eggs into one basket. If the YANG approach proves to be
> viable, then the XSDMI translations can be modified as needed to work
> with YANG in the future. But XSDMI could give us XSD datatypes to
> develop data models, possibly years before consensus on YANG will be
> achieved.
> 
> I believe the XSDMI effort should be an OPS-area effort (indeed an
> IETF-wide effort), focused in the OPSAWG, to allow the representation
> and translation into XML idiom of the existing datatypes, textual
> conventions, and semantic models defined in 15 years of work by
> multiple working groups and multiple areas of the IETF. 
> 
> David Harrington
> [email-masked]
> [email-masked]
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/opsawg
> 

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsawg

---

From: "David Harrington" <[email-masked]>
Date: Thu, 1 Nov 2007 16:22:08 -0700

Hi,

The goal of XSDMI is to provide a standard translation of SMI
datatypes, textual conventions, and macros into XML family formats,
such as XSD.

I have said this over and over: There has never been any intention on
my part to mandate that any XML-based protocol, including Netconf,
MUST use the XSD output from the XSDMI translations. These
translatinos are being provided to **enable and encourage** reuse of
SMIv2 datatypes and textual conventions in XML-based protocols, and to
provide XML-based support for SMIv2 macros to encourage reuse of the
MIB data models (schemas) in XML-capable management applications and
databases.

It is purely a Netconf decision whether to reuse these datatype
translations, just as it would be purely a "foo" protocol decision
whether the datatypes were appropriate for reuse in the "foo"
environment. The XSDMI work is totally independent of the work being
done by and for the Netconf community.

Perasnally, I expect that the data modeling needed for configuration
will require things that SMIv2 does not have - the ability to
distinguish config data from state data, the ability to specify data
from the candidate datastore vs that from the running or startup
datastores, nested data structures, standardized methods, etc. SMIv2
MIBs and the XSD equivalents cannot do this! 

I think it unlikely that the XSD output from a Netconf-specific
effort, such as YANG, will match the XSD output from the XSDMI effort,
because if it did then it could be argued that there is no need to
move to a new data modeling language, only the need to translate SMIv2
into XML-based formats. XML and XSD do not enable better
configuration; a configuration-focused protocol and
configuration-focused data models will do that. I consider it
appropriate that the data models from the SMIv2 MIB and the data
models designed for Netcof configuration not match because they are
designed to serve different purposes. 

The data models that already exist for SNMP and syslog and RADIUS and
Diameter and IPFIX do not match, because they serve different purposes
and contain different modeling information, even though they are all
related to network management. The data model encodings used for MIBs
and LDAP search filters and X.509 certificates differ because they
serve different purposes, even though they all use ASN.1 encoding. The
netconf data models and their encodings SHOULD differ from the
SNMP/MIB data models because the information that we need to model and
to encode on the wire for these different purposes and different
protocols is different.

I do not feel that publishing the XSDMI translations as Informational
is called for. This work is **independent** of Netconf.

The goal of XSDMI is to provide a **standard** translation of SMI
datatypes, textual conventions, and macros into XML family formats,
such as XSD, so other protocols can **choose** to use compatible
datatypes, and have a standard interoperable translation already
available so they don't have to do the translation themselves, and so
the standard translations can be done by people who really understand
the purpose and constraints of the SMIv2 datatypes and textual
conventions and macros.

It has **never** been my intention that people should be **forced** to
use these translated datatypes, textual conventions, and macros with
other protocols, only that we would make it easier for them to do so
if they wanted to, and to promote interoperability by giving them
standard translations they could use.

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 12:35 PM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [OPSAWG] XSDMI
> 
> Hi David,
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 01 Nov 2007 21:41:13 -0400

David,

Are there any aspects of the proposal that you would like to change? Or
are we in violent agreement?

                                Ron

David Harrington wrote:
>>>Juergen has raised the issue that the XSD produced by the 
>>
>>XDMI effort
>>
>>>and the XSD produced by the YANG effort might be different, 
>>
>>and having
>>
>>>two different XSD equivalents for MIB datatypes would be 
>>
>>suboptimal. I
>>
>>>agree.
>>>
>>>completed, they will need to develop proprietary data models for
> 
> use
> 
>>>with netconf. Some vendors will want to reuse datatypes found in
> 
> the
> 
>>>15 year compilation of IETF NM experience found in the standard
> 
> MIB
> 
>>>modules, and supported by existing implementation code. If they
> 
> need
> 
>>>textual conventions into XSD and XML, we could wind up with 
>>
>>a variety
>>
>>>The XSDMI work would provide reusable XSD equivalents of 
>>
>>SMI datatypes
>>
>>>translations, then later work to derive standards from the 
>>
>>proprietary
>>
>>>draft-frascone-xml-dictionary-00 describes the Diameter
> 
> "dictionary"
> 
>>>working on an information model in XML for traceroute 
>>
>>measurements. So
>>
>>>The netconf community should be focused on defining a data
> 
> modeling
> 
>>>netconf focuses not only on configuration, but also on developing
> 
> an
> 
>>>generate syntax-specific data models for a variety of purposes,
> 
> such
> 
>>>as Netconf-suitable XSD data models, SNMP-suitable MIB modules,
> 
> plus
> 
>>>data models for other modeling systems. I have a concern 
>>
>>that the SNMP
>>
>>>community has not been asking for this approach, and the IETF
> 
> failed
> 
>>>to reach consensus on the need for the information-modeling
> 
> approach
> 
>>>IETF, then does that mean that efforts to use XML-based data
> 
> models
> 
>>>for ipfix, Diameter, IPPM, and LDAP should not be permitted 
>>
>>until YANG
>>
>>>Just to be clear, I support the YANG effort because I 
>>
>>believe it could
>>
>>>lead to better consistency of data modeling across protocols, but
> 
> it
> 
>>>has yet to be proven to be viable, and other efforts to converge
> 
> or
> 
>>>harmonize data models have had mixed success at best. We should
> 
> not
> 
>>>put all our eggs into one basket. If the YANG approach proves to
> 
> be
> 
>>>viable, then the XSDMI translations can be modified as 
>>
>>needed to work
>>
>>>develop data models, possibly years before consensus on YANG will
> 
> be
> 
>>>achieved.
>>>
>>>IETF-wide effort), focused in the OPSAWG, to allow the 
>>
>>representation
>>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 2 Nov 2007 01:00:06 -0700

I believe XSDMI should generate standards-track documents, not
Informational documents.

dbh 

> Sent: Thursday, November 01, 2007 6:41 PM
> To: David Harrington
> Cc: [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 Nov 2007 10:13:32 +0100

As a contributor I agree with David's point - providing a
'standards-track' mapping and XSDMI translation would better serve the
goal of translating the current SMI-based data models and with the right
wording in the charter and documents we can make very clear that the
effort is independent of NETCONF and does not mandate anything for
NETCONF or other protocols. However, I do not believe that we should
make a determination of the final status of the documents now, or get
blocked in the discussion about this item that early. Let us present the
revised version of documents to the OPSAWG meeting in Vancouver with the
proposal to re-charter OPSAWG to include as a generic area work items.
If OPSAWG accepts these two documents as work items in its charter the
discussion should anyway happen here and be subject to consensus of the
WG.  

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Friday, November 02, 2007 10:00 AM
> To: 'Ron Bonica'
> Cc: [email-masked]
> Subject: RE: [OPSAWG] XSDMI
> 
> I believe XSDMI should generate standards-track documents, 
> not Informational documents.
> 
> dbh 
> 
> > Are there any aspects of the proposal that you would like 
> to change? 
> > Or are we in violent agreement?
> > 
> >                                 Ron
> > 
> > 
> > David Harrington wrote:
> > > Hi,
> > > 
> > >>produced by XSDMI is made available to everyone, there is 
> no mandate 
> > >>to use it. This means that it the NETCONF community decides that 
> > >>XSDMI does not fulfill their requirements, they will be free to 
> > >>specify something else.
> > >>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Nov 2007 10:54:36 +0100

On Fri, Nov 02, 2007 at 10:13:32AM +0100, Romascanu, Dan (Dan) wrote:

> 'standards-track' mapping and XSDMI translation would better serve
> the goal of translating the current SMI-based data models and with
> the right wording in the charter and documents we can make very
> clear that the effort is independent of NETCONF and does not mandate
> anything for NETCONF or other protocols.

So which protocol is going to use this XSDMI mapping?
I always wonder what these "other protocols" are...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 2 Nov 2007 07:25:09 -0700

Hi Juergen,

The whole point is that this WG should not be authorized to make the
decision about which other protocols or which applications will use
these mappings. No protocols or applications should be required to use
the XSDMI mappings, and the decision about the applicability of these
mappings should rest with the developers of any current or future
protocols or applications that could benefit from their reuse.

The mappings should be done in the OPS area, where SMIv2 experts are
available to ensure the semantics of the SMIv2 constructs are
maintained in the mappings. The mappings would then be available to
make it easier for developers of protocols and network management
applications, current and future, inside and outside the IETF, to use
the standardized, vendor-neutral, interoperable XML-based mapping for
SMIv2 constructs if they choose to do so. The documents should also
identify which SMIv2 constructs are NOT RECOMMENDED for use by new
protocols, and which mappings are provided for backwards compatibility
and should be used only when accessing or modeling SMIv2 MIB data
models.

Relying on the developers of future protocols and applications to do
the mappings themselves as needed, could result in a proliferation of
incompatible, non-interoperable, vendor-specific, protocol-biased, and
potentially incorrect mappings of SMIv2 constructs. 

dbh 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, November 02, 2007 2:55 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Ron Bonica; [email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Fri, 02 Nov 2007 11:03:25 -0400

Why?

  Doesn't the existence of a standards track RFC mandate that people use
the XSDMI mappings? Isn't that exactly the mandate that we are trying to
avoid?

                                    Ron

David Harrington wrote:
>>>datatypes, textual conventions, and macros into XML family
> 
> formats,
> 
>>>such as XSD.
>>>
>>>I have said this over and over: There has never been any 
>>
>>intention on
>>
>>>translatinos are being provided to **enable and encourage** reuse
> 
> of
> 
>>>SMIv2 datatypes and textual conventions in XML-based 
>>
>>protocols, and to
>>
>>>provide XML-based support for SMIv2 macros to encourage reuse of
> 
> the
> 
>>>MIB data models (schemas) in XML-capable management applications
> 
> and
> 
>>>databases.
>>>
>>>environment. The XSDMI work is totally independent of the work
> 
> being
> 
>>>Perasnally, I expect that the data modeling needed for
> 
> configuration
> 
>>>distinguish config data from state data, the ability to specify
> 
> data
> 
>>>datastores, nested data structures, standardized methods, etc.
> 
> SMIv2
> 
>>>effort, such as YANG, will match the XSD output from the 
>>
>>XSDMI effort,
>>
>>>move to a new data modeling language, only the need to 
>>
>>translate SMIv2
>>
>>>models designed for Netcof configuration not match because they
> 
> are
> 
>>>The data models that already exist for SNMP and syslog and 
>>
>>RADIUS and
>>
>>>Diameter and IPFIX do not match, because they serve 
>>
>>different purposes
>>
>>>and contain different modeling information, even though they are
> 
> all
> 
>>>related to network management. The data model encodings 
>>
>>used for MIBs
>>
>>>serve different purposes, even though they all use ASN.1 
>>
>>encoding. The
>>
>>>SNMP/MIB data models because the information that we need 
>>
>>to model and
>>
>>>I do not feel that publishing the XSDMI translations as 
>>
>>Informational
>>
>>>datatypes, textual conventions, and macros into XML family
> 
> formats,
> 
>>>available so they don't have to do the translation 
>>
>>themselves, and so
>>
>>>the standard translations can be done by people who really 
>>
>>understand
>>
>>>It has **never** been my intention that people should be 
>>
>>**forced** to
>>
>>>use these translated datatypes, textual conventions, and macros
> 
> with
> 
>>>other protocols, only that we would make it easier for them to do
> 
> so
> 
>>>>David progresses the XSDMI work in the OPS Area WG. Although the
> 
> XSD
> 
>>>>All drafts progressed as XSDMI will be submitted for publication
> 
> as
> 
>>>>INFORMATIONAL.
>>>>
>>>>Comments?
>>>>
>>>>                             Ron
>>>>
>>>>
>>>>David Harrington wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>However, I have the concern that while vendors wait for YANG to
> 
> be
> 
>>>>>increased commonality in the datatypes and textual conventions
> 
> and
> 
>>>>>in XML format; draft-legg-xed-roadmap-06.txt describes
> 
> translating
> 
>>>>>equivalent XML renditions of existing directory protocols; IPPM
> 
> is
> 
>>>>>information-model-generates-data-models approach is adopted by
> 
> the
> 
>>>>>I believe the XSDMI effort should be an OPS-area effort (indeed
> 
> an
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 Nov 2007 16:22:56 +0100

The standards track RFC should be clear about its applicability. In this
case the applicability should be clearly limited to the translation
between existing SMIv2 data types and TCs  in into XML data models
expressed in XSD. It does not mandate usage of a certain protocol,
protocols using XML can use anything else than XSD, and even when using
XSD they can define their own data structures using other tools. 

In other words, the standard should be about 'how to translate from A to
B', it's not about mandating the usage of B. 

Dan

> Sent: Friday, November 02, 2007 5:03 PM
> To: David Harrington
> Cc: [email-masked]
>   Doesn't the existence of a standards track RFC mandate that 
> people use the XSDMI mappings? Isn't that exactly the mandate 
> that we are trying to avoid?
> 
>                                     Ron
> 
> 
> David Harrington wrote:

---

From: "David Harrington" <[email-masked]>
Date: Fri, 2 Nov 2007 09:55:32 -0700

Hi,

Sure, I think an applicability statement is a good idea. Note that the
document is not allowed to mention anything about being a standard, or
imply being a standard: 

"  The Internet-Draft should neither state nor imply that it has any
   standards status; to do so conflicts with the role of the RFC
Editor
   and the IESG.  The title of the document should not imply a status.
   Avoid the use of the terms Standard, Proposed, Draft, Experimental,
   Historic, Required, Recommended, Elective, or Restricted in the
title
   of the Internet-Draft.  Indicating what status the document is
aimed
   for is OK, but should be done with the words "Intended status:
   <status>".

So, is the following text acceptable, or does this imply standards
status?

"This memo describes how to translate from SMIv2 constructs to
XML-based formats. This memo does not mandate the use of this
translation by any particular protocol or application."

dbh

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Friday, November 02, 2007 8:23 AM
> To: Ron Bonica; David Harrington
> Cc: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Nov 2007 10:24:39 -0700

> B', it's not about mandating the usage of B. 

I think an SDO can do better than this.
There is disagreement between the way YANG encodes some SMIv2
data types and the way draft-romascanu does it, particularly
related to IPv4 and IPv6 addresses, duration, and dateTime.
These technical issues should be worked out in the opsawg.

It is important to get alignment on fundamental data types
like these, which will show up over and over in standard
data models.

I want a well-constrained set of standard data types
(encoded in XSD for now), such that if a standards-track
XML data model of any kind uses the data type 'InetAddress'
or any of the other standard named types, that the
standard syntax and semantics will apply.

This problem has nothing to do with SMIv2.
It has to do with standards, and whether or not
we have any for XML data models in the IETF.

> Dan

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Nov 2007 19:45:28 +0100

> protocols or applications that could benefit from their reuse.

I am still wondering how useful is it to develop standards-track
protocol neutral feel free to ignore SMIv2 translations to XSD. It is
unclear to me how this helps to "make the Internet work better"
[BCP95].

If we are really concerned about the proliferation of incompatible
data models, then what really needs to be done is to define a common
way to write up NETCONF data models since proprietary incompatible
languages are already around. Trying to move towards interoperable
standardized configuration was the direction taken a few years ago
after the IAB workshop and so far I believed this goal is still on the
table.

I find it quite irritating that the IETF does not seen ti have the
stamina to address the NETCONF data modeling issue and to complete the
work they have started a few years ago towards XML-based standardized
(configuration) management. And if we talk at the same time about
spending resources on standards-track protocol neutral feel free to
ignore SMIv2 translations to XSD, then this increases my irritation
even more. Perhaps the IETF network management "area" has lost
direction.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Nov 2007 12:17:37 -0700

> unclear to me how this helps to "make the Internet work better"

In the general sense I agree with you.
But in this case, a set of protocol-neutral data types
is useful and possible.

IMO, if an XML data model uses a data type called Counter32,
it should be the same Counter32 we already know in the IETF.
I never said the data model must use Counter32 instead of MyCounter
or whatever.

There is a set of protocol neutral data types within draft-romascanu,
plus some SNMP-centric stuff that could be separated out.
There is nothing NETCONF-specific about an IP address.

> even more. Perhaps the IETF network management "area" has lost

I think the area is proceeding slowly, that's all.

I would like these core data types to be in alignment
with the YANG versions (pick one or the other), decided
on a case-by-base basis.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 2 Nov 2007 12:25:17 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "David Harrington" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, November 02, 2007 10:45 AM
...
> even more. Perhaps the IETF network management "area" has lost
...

Perhaps I've misunderstood what has been said in WG meetings (it's
been a while since I've attended a face-to-face meeting) and on the
mailing lists.  My impression has been that, despite everything said in
the IAB workshop, the IETF direction for new work has been to
abandon any kind of common modeling approach in favor of CLI
masquerading as XML, and that, consequently, any attempt to provide
real data modeling standardization with any "teeth" in its applicability
won't get anywhere.  The current situation seems to be to favor the least
"threatening" of the proposals.  Perhaps the tacit assumption is that once
it's in place, it will prevent the others from taking hold.  But perhaps I've
been away too long and have merely become overly cynical.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 Nov 2007 20:49:26 +0100

> From: Andy Bierman [mailto:[email-masked]] 
> 
> I would like these core data types to be in alignment with 
> the YANG versions (pick one or the other), decided on a 
> case-by-base basis.
> 

Yes, but we need to have the yang data types published as Internet-Draft
to be able to entertain this discussion. Until then it is not clear to
me what is the degree of (mis)-alignment that we are talking about. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 Nov 2007 20:54:24 +0100

> Sent: Friday, November 02, 2007 8:45 PM
> To: David Harrington
> Cc: Romascanu, Dan (Dan); 'Ron Bonica'; [email-masked]
> I am still wondering how useful is it to develop 
> standards-track protocol neutral feel free to ignore SMIv2 
> translations to XSD. It is unclear to me how this helps to 
> "make the Internet work better"
> [BCP95].
> 

It's not about ignoring but about not mandating. Isn't this the same
architectural principle of not coupling tightly the protocol and the
data modeling language that is in place with SNMP as well? Even SMIv2 is
supposed to be able to work with protocols other than SNMP. 

Dan

---

From: Ron Bonica <[email-masked]>
Date: Mon, 05 Nov 2007 15:12:06 -0500

Hi David,

It seems to mee that PS status is at odds with this applicability
statement. If the memo does not mandate use, why does the memo need to
be PS?

                                  Ron

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 5 Nov 2007 22:04:39 +0100

> Sent: Monday, November 05, 2007 10:12 PM
> To: David Harrington
> Cc: Romascanu, Dan (Dan); [email-masked]
> It seems to mee that PS status is at odds with this 
> applicability statement. If the memo does not mandate use, 
> why does the memo need to be PS?
> 
> 
>                                   Ron
> 
> 

Because what is standardized is the method of translation, not the usage
of the result of the translation. 

Dan

---

From: Ron Bonica <[email-masked]>
Date: Tue, 06 Nov 2007 11:43:15 -0500

Dan,

I don't think that I am convinced. But rather than occupying the WG with
this debate, why don't we just proceed with the work. When the memo is
ready for publication, we can revisit the document status issue with the
benefit of some additional experience under our belts.

At that time, we should be able to make a more informed decision because
we will know what the output will look like and we will know whether it
is acceptable to any protocol folks.

                                Ron

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Nov 2007 20:10:22 +0100

Sounds good. I believe that Scott and Tim include XSDMI on the agenda
for the OPSAWG meeting in Vancouver. 

Thanks, 

Dan

> Sent: Tuesday, November 06, 2007 6:43 PM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; [email-masked]
> I don't think that I am convinced. But rather than occupying 
> the WG with this debate, why don't we just proceed with the 
> work. When the memo is ready for publication, we can revisit 
> the document status issue with the benefit of some additional 
> experience under our belts.
> 
> At that time, we should be able to make a more informed 
> decision because we will know what the output will look like 
> and we will know whether it is acceptable to any protocol folks.
> 
>                                 Ron
> 
> 
> > Because what is standardized is the method of translation, not the 
> > usage of the result of the translation.
> > 
> > Dan
> > 
>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 6 Nov 2007 14:18:57 -0500

I agree with making the decision on PS vs Informational later, as long
as the work is allowed to continue in the meantime. 

That will give the YANG team time to produce internet-drafts, so we
can compare the formats and hopefully end up with one consistent
format.

dbh

> Sent: Tuesday, November 06, 2007 2:10 PM
> To: Ron Bonica
applicability