Subject: [MIB-DOCTORS] http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-10.txt and RFC 4560

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 11 Aug 2008 14:50:09 +0200

The Internet-Draft
http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-10.
txt is on the agenda of the IESG telechat this week for approval as
Proposed Standard. The document proposes an Information Model and an
XML-based data model that reuse or try to be compatible with some of the
objects defined in the DISMAN-TRACEROUTE-MIB in RRFC4560. It would be
good for the authors of RFC4560 and other to have a look at this
document and comment if they see any problem. 

Thanks and Regards,

Dan
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "David Harrington" <[email-masked]>
Date: Mon, 11 Aug 2008 10:53:31 -0400

Hi,

In MIB-land, we have naming conventions, documented in RFC4181, that
recommend objects and TCs be preceded by a prefix derived from the MIB
module name to help ensure global uniqueness.

The existing standard InetAddress datatype is from the
INET-ADDRESS-MIB.

I recommend the module defined in this document be given a unique name
(e.g., ippm), and the datatypes defined in this module be named using
a prefix derived from the module name, so the ippmInetAddress does not
conflict with the yangInetAddress or the xsdmiInetAddress and so on,
and neither definition is confused with the existing standard
InetAddress datatype from the INET-ADDRESS-MIB.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Monday, August 11, 2008 8:50 AM
> To: Juergen Quittek; [email-masked]
> Cc: [email-masked]; MIB Doctors (E-mail); 
> [email-masked]
> Subject: 
> [OPS-DIR]http://www.ietf.org/internet-drafts/draft-ietf-ippm-s
> toretraceroutes-10.txtand RFC 4560
> 
> The Internet-Draft
> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 11 Aug 2008 16:59:44 +0200

David,

Are you referring to types definitions or to schema names as in 

<xs:complexType name="inetAddress">

Dan

> From: David Harrington [mailto:[email-masked]] 
> Sent: Monday, August 11, 2008 5:54 PM
> To: Romascanu, Dan (Dan); 'Juergen Quittek'; [email-masked]
> Cc: [email-masked]; 'MIB Doctors (E-mail)'; 
> [email-masked]
> Subject: RE: 
> In MIB-land, we have naming conventions, documented in 
> RFC4181, that recommend objects and TCs be preceded by a 
> prefix derived from the MIB module name to help ensure global 
> uniqueness.
> 
> I recommend the module defined in this document be given a 
> unique name (e.g., ippm), and the datatypes defined in this 
> module be named using a prefix derived from the module name, 
> so the ippmInetAddress does not conflict with the 
> yangInetAddress or the xsdmiInetAddress and so on, and 
> neither definition is confused with the existing standard 
> > XML-based data model that reuse or try to be compatible 
> with some of 
> > the objects defined in the DISMAN-TRACEROUTE-MIB in 
> RRFC4560. It would
> be

---

From: "David Harrington" <[email-masked]>
Date: Mon, 11 Aug 2008 13:38:26 -0400

Hi,

I don't understand your question. I "refer" to both type definitions
and schemas.

I am concerned that XML modules are defining their own "equivalents"
for existing SMIv2 datatypes and textual conventions, and then calling
them by the same names as are used in SMIv2 modules. And it is unclear
whether the "equivalents" accurately represent the same semantics as
the SMIv2 modules, and whether the different "equivalents" are
consistent with each other.

I think we need to either publish a standard that says "here is the
IETF standard for representing SMIv2 datatypes accurately in XSD" or
we need to make sure that each "equivalent" is uniquely identified by
using different datatype names (possibly following the rfc4181 naming
conventions), or we need to make sure each "equivalent" is uniquely
identified by always scoping the datatype by the XML namespace in
which the datatype is defined, so there is no confusion about
**which** InetAddress is being used.

Obviously, re-using an IETF standard "InetAddress" XSD datatype would
be best, but it is a problem importing an XSD InetAddress datatype,
since no XSD definition of InetAddress has been declared Proposed
Standard yet, so there would be an unresolved normative reference
stopping the IPPM draft from publication/advancement.

The traceroute schema identifies a namespace "tr". If they want to
define a datatype for representing InetAddress, since they cannot
import an IETF standard XSD datatype, I suggest they pay attention to
the rfc4181 conventions for SMIv2 naming, and call it trInetAddress,
so there is no confusion about which InetAddress datatype definition
is being used. 

dbh

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, August 11, 2008 11:00 AM
> To: David Harrington; Juergen Quittek; [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Aug 2008 07:30:49 +0200

> InetAddress datatype from the INET-ADDRESS-MIB.

The XML module has a namespace and a prefix for the namespace. Is
that not sufficient?

/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/>
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Rob Austein <[email-masked]>
Date: Mon, 11 Aug 2008 19:24:59 -0400

At Mon, 11 Aug 2008 13:38:26 -0400, David Harrington wrote:
> ...

IIRC the xmlns attribute just defines a local tag for the namespace
URI within a XML particular document, so the real name of the type in
your example is "{urn:ietf:params:xml:ns:traceroute-1.0}inetAddress",
which seems adaquately unique.
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Aug 2008 10:08:27 +0200

See in-line. 

Regards,

Dan

> Sent: Monday, August 11, 2008 8:38 PM
> [email-masked]; [email-masked]
> Subject: RE: 
> I don't understand your question. I "refer" to both type 
> definitions and schemas.

The document defines InetAdress both as information element as well as
object in the schema. 

> for existing SMIv2 datatypes and textual conventions, and 
> then calling them by the same names as are used in SMIv2 
> modules. And it is unclear whether the "equivalents" 
> accurately represent the same semantics as the SMIv2 modules, 
> and whether the different "equivalents" are consistent with 
> each other.
> 
> I think we need to either publish a standard that says "here 
> is the IETF standard for representing SMIv2 datatypes 
> accurately in XSD" or we need to make sure that each 
> "equivalent" is uniquely identified by using different 
> datatype names (possibly following the rfc4181 naming 
> conventions), or we need to make sure each "equivalent" is 
> uniquely identified by always scoping the datatype by the XML 
> namespace in which the datatype is defined, so there is no 
> confusion about

I think that scoping is necessary, and inevitable. 

> 
> Obviously, re-using an IETF standard "InetAddress" XSD 
> datatype would be best, but it is a problem importing an XSD 
> InetAddress datatype, since no XSD definition of InetAddress 
> has been declared Proposed Standard yet, so there would be an 
> unresolved normative reference stopping the IPPM draft from 
> publication/advancement.

One more reason to try to accelerate the work for the definition of
standard datatypes in OPSAWG and NETMOD which we can later point other
IETF WGs to. But I agree, we should not try to stop the IPPM draft from
publication in wait for this. 

> 
> The traceroute schema identifies a namespace "tr". If they 
> want to define a datatype for representing InetAddress, since 
> they cannot import an IETF standard XSD datatype, I suggest 
> they pay attention to the rfc4181 conventions for SMIv2 
> naming, and call it trInetAddress, so there is no confusion 
> about which InetAddress datatype definition is being used. 

Would you consider this a blocking comment? 

> RFC4181, that 
> > > recommend objects and TCs be preceded by a prefix derived 
> from the 
> > > MIB module name to help ensure global uniqueness.
> > > 
> > > I recommend the module defined in this document be given a unique 
> > > name (e.g., ippm), and the datatypes defined in this 
> module be named 
> > > using a prefix derived from the module name, so the 
> ippmInetAddress 
> > > does not conflict with the yangInetAddress or the 
> xsdmiInetAddress 
> > > and so on, and neither definition is confused with the existing 
> > > standard InetAddress datatype from the INET-ADDRESS-MIB.
> > > 
> > > dbh
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Aug 2008 10:25:19 +0200

On Wed, Aug 13, 2008 at 09:11:15AM +0200, tom.petch wrote:
 
> And which delightfully points out a fundamental difference between
> SMIv2 and XML, that the former has a namespace, the latter has
> infinite namespaces, so we can have as many InetAddress as we want
> in XML, and doubtless will.

In SMIv2, you can have as many InetAddress definitions as you want as
long as they are all defined in separate modules. Every SMIv2 module
has in fact its own namespace.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 13 Aug 2008 11:05:35 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, August 13, 2008 11:25 AM
> To: tom.petch
> Cc: 'MIB Doctors (E-mail)'; [email-masked]; Rob Austein; 
> [email-masked]
> Subject: Re: [OPSAWG][OPS-DIR] 
> http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetrace
> routes -10.txtandRFC4560
> 
> > infinite namespaces, so we can have as many InetAddress as 
> we want in 
> > XML, and doubtless will.
> 
> In SMIv2, you can have as many InetAddress definitions as you 
> want as long as they are all defined in separate modules. 
> Every SMIv2 module has in fact its own namespace.
> 
> /js
> 

Are you sure? RFC2579 makes an assumption of uniqueness for TCs in
standard space by saying that all names used for the textual conventions
defined in all "standard" information modules shall be unique. This
tells me that we cannot have more than one TC named InetAddress in
SMIv2, while in XML we can have as many InetAddress as we want in
different namespaces. 

Dan

---

From: "tom.petch" <[email-masked]>
Date: Wed, 13 Aug 2008 09:11:15 +0200

----- Original Message -----
From: "Rob Austein" <[email-masked]>
Cc: <[email-masked]>; "'MIB Doctors (E-mail)'" <[email-masked]>
Sent: Tuesday, August 12, 2008 1:24 AM
Subject: Re: [OPSAWG][OPS-DIR]
http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-10.txtand
RFC4560

> which seems adaquately unique.

And which delightfully points out a fundamental difference between SMIv2 and
XML, that the former has a namespace, the latter has infinite namespaces, so we
can have as many InetAddress as we want in XML, and doubtless will.

What is needed is an IETF standard namespace with a well-known, ideally
reserved, prefix containing best practice for common datatypes.  And yes, we
might not get the pattern of an IPv6 address right first time.

Tom Petch

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Aug 2008 12:59:54 +0200

> SMIv2, while in XML we can have as many InetAddress as we want in

Problems can only arise if I have a definition of InetAddress in the
modules A-MIB and B-MIB and I have to import both in modules in module
C-MIB. In this case, I have to disambiguate things. RFC 2578 says:

   [...] As such, if different objects with the same descriptor
   are IMPORTed, then this ambiguity is resolved by prefixing the
   descriptor with the name of the information module and a dot ("."),
   i.e.,

        "module.descriptor"

   (All descriptors must be unique within any information module.)

You are correct in the sense that this text talks about 'objects', so
this might not apply to TCs. Anyway, since we do not really have a
mechanism to enforce uniqueness (there is no IANA registration for
prefixes or TC names), I guess sooner or later collisions will occur
and then the A-MIB.InetAddress notation will be the only reasonable
way out, practically speaking.

The problem with some of the SMIv2 language is that it is often
unclear whether a CLR has a technical foundation or reflects an
attempt to enforce good usage guidelines (TC names should be unique to
reduce ambiguity when cutting and pasting just names).

/js

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 13 Aug 2008 09:27:29 -0400

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
[...]
> reduce ambiguity when cutting and pasting just names).

Some CLRs are based on a solid technical foundation, and strive to
provide interoperable usage guidelines, such as the "clarifying
language rule" that all IETF standard MIB descriptors should be unique
within the IETF.

Tom saya, "What is needed is an IETF standard namespace with a
well-known, ideally
reserved, prefix containing best practice for common datatypes." MIB-I
was an IETF standard namespace, and it proved unwieldy. A modular
approach is easier to work with in our standard development
environment. 

What we found effective in the MIB community is a centralized
registration system (IANA) with hierarchical namespaces, in which the
centralized authority can delegate management of modular namespaces to
standards efforts (usually WGs) and to enterprises, for registering
descriptors and registrations within the hierarchical namspace, plus a
rule that all descriptors and registrations within the
standards-effort portion of the registration system MUST be unique.
The MIB system has been working quite well for twenty years.

I think we would benefit from such a hierarchical approach to managing
IETF standard XML namespaces and descriptors (minus the OID syntax, of
course).

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Aug 2008 15:45:30 +0200

> The MIB system has been working quite well for twenty years.

Sorry, I can't follow. There is nothing delegated to WGs as far as I
can tell. And I am not aware of any IANA registration systems for
module names or global TC names.

> I think we would benefit from such a hierarchical approach to
> managing IETF standard XML namespaces and descriptors (minus the OID
> syntax, of course).

XML namespaces are not the same as YANG namespaces. There are specific
IETF rules how to allocate XML namespaces and I think we should just
use them. What precisely is the problem to be solved?

/js

---

From: "tom.petch" <[email-masked]>
Date: Wed, 13 Aug 2008 16:39:38 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: "'Romascanu, Dan (Dan)'" <[email-masked]>; "'tom.petch'"
<[email-masked]>; "'MIB Doctors (E-mail)'" <[email-masked]>;
<[email-masked]>; "'Rob Austein'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 13, 2008 3:45 PM
Subject: Re:
[MIB-DOCTORS][OPSAWG][OPS-DIR]http://www.ietf.org/internet-drafts/draft-ietf-ipp
m-storetraceroutes-10.txtandRFC4560

> XML namespaces are not the same as YANG namespaces.

This puzzles me; to quote the I-D

   All YANG definitions are specified within a particular XML Namespace.
   Each module defines an XML namespace as a globally unique URI
   [RFC3986].  A NETCONF client or server uses the namespace during XML
   encoding of data.

so a YANG namespace and the URI are fairly tightly bound.  What I want is for
the IETF standard YANG type definitions, where SMI has TCs, to appear in a small
number of I-Ds in a small number of YANG modules, small ideally being one.  And
for a suggested prefix for everyone to use in every IETF standards track RFC
when referring to that one module.  Of course, if the YANG type definitions are
spread across many YANG modules they will perforce have multiple namespaces and
multiple prefixes.

Tom Petch

                                                                There are
specific

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Aug 2008 18:51:14 +0200

On Wed, Aug 13, 2008 at 04:39:38PM +0200, tom.petch wrote:

> so a YANG namespace and the URI are fairly tightly bound.

I am probably not communcating cleary enough. We deal with many
namespaces, namespaces within the YANG language and namespace within
instance XML documents and namespaces within translations of YANG
modules to XSD/DSDL.  An example might help to make this clearer:

module A {

  namespace urn:something:longish;

  typedef b { type uint8; }

  leaf b { type b; }

  notification b { ... }

  operation b { ... }

}

Within the YANG module A, there are several separate namespaces for
types, leafs (containers, leaf-lists, lists, ...), notifications or
operations (called rpcs to confuse people ;-).

An XML instance document does not carry typedef information and thus
the typedef namespace is not mapped to instance documents. The leaf
etc. definitions map into the XML namespace identified by the YANG
namespace statement.

XSD/DSDL translations of course do carry typedefs and such things and
the translation rules must ensure that the mapping of the YANG
namespaces to the XSD/DSDL namespaces work correctly when there are
conflicts like shown above.

> What I want is for the IETF standard YANG type definitions, where
> SMI has TCs, to appear in a small number of I-Ds in a small number
> of YANG modules, small ideally being one.  

We currently have three on the table and as long as you accept this as
small enough we are in good shape.

> And for a suggested prefix for everyone to use in every IETF
> standards track RFC when referring to that one module.  

If a YANG module refers to these modules, we are talking about YANG
namespace references. If you have XSD/DSDL translations in your head,
then we talk about the reference to the XSD/DSDL namespace generated
by the translation rules.

> Of course, if the YANG type definitions are spread across many YANG
> modules they will perforce have multiple namespaces and multiple
> prefixes.

Yep.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Aug 2008 10:37:03 -0700

Hi -

> Cc: <[email-masked]>; "'Rob Austein'" <[email-masked]>; "'MIB Doctors (E-mail)'" <[email-masked]>; "'tom.petch'"
<[email-masked]>; <[email-masked]>
> Sent: Wednesday, August 13, 2008 6:45 AM
> Subject: Re: [MIB-DOCTORS][OPSAWG][OPS-DIR] http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes -10.txtandRFC4560
>
...

The CLR that IETF descriptors should be unique isn't a necessary
property of the SMI.  The CLR was added for two reasons:
  (1) *humans* generally don't qualify descriptors with module names,
        and are easily confused in ways that a properly implemented
        MIB compiler would not be confused.
  (2) back then, some MIB compilers didn't distinguish descriptors
       coming from different modules.  This is clearly a bug, but a very
       common and wide-spread one.

So Juergen's quite right about the technical non-need for descriptor
uniqueness in SMI.  Though reason (1) might be worth considering
as a basis for a possible similar CLR in XML-based work, I do hope
that we can avoid (2), which is ultimately much more pernicious.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Aug 2008 10:43:26 -0700

Hi -

> From: "Natale, Bob" <[email-masked]>
> To: <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>; <[email-masked]>; "Rob Austein" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, August 13, 2008 10:31 AM
> Subject: Re: [OPSAWG][OPS-DIR] http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes -10.txtandRFC4560
>
> Hi Juergen,
> 
> I would just like to note that the portion of RFC 2578 that you omitted
> with "[...]" says this:
> 
> "Note that when symbols from 'enterprise-specific' information modules
> are referenced  (e.g., a descriptor), there is the possibility of
> collision."
> 
> Dan's text -- to which you were replying -- specifically referred to
> "TCs defined in standard space" and the uniqueness rule for rule for
> the TCs "defined in all 'standard' information modules". 
> 
> I read that as saying that there can be only one IETF standard TC for
> "InetAddress", or whatever, even though there could be any number of
> enterprise-specific TCs with that descriptor that might even refer to
> vastly different things.  So, there need be only one logical namespace
> for all IETF standard TCs (despite the fact that they might be defined
> in multiple physical modules.
...

That's an interesting reading, but I think it's clearly contradicted by the
fact that any IMPORTS statements referencing these descriptors must
use the actual module name of the module in which they were defined,
not some hypothetical IETF-SMI-namespace-module.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 Aug 2008 14:29:18 +0200

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Wednesday, August 13, 2008 8:43 PM
> To: MIB Doctors (E-mail); [email-masked]; [email-masked]
> > Cc: "MIB Doctors (E-mail)" <[email-masked]>; 
> <[email-masked]>; 
> > "Rob Austein" <[email-masked]>; <[email-masked]>
> http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes 
> > -10.txtandRFC4560
> >
> > Hi Juergen,
> > 
> > I would just like to note that the portion of RFC 2578 that you 
> > omitted with "[...]" says this:
> > 
> That's an interesting reading, but I think it's clearly 
> contradicted by the fact that any IMPORTS statements 
> referencing these descriptors must use the actual module name 
> of the module in which they were defined, not some 
> hypothetical IETF-SMI-namespace-module.
> 
> Randy
> 

Randy,

Can you explain what other reading can be given from the following
phrase in section 3 of RFC 2579? 

'Further, all names used for the textual conventions
   defined in all "standard" information modules shall be unique.'

IMO the fact that IMPORTS statements referencing these descriptors must
use the actual module name does not contradict in any way the
requirement for uniqueness of TC descriptor names in SMIv2, but rather
is just a linkage necessity derived from the fact that there is no
single module that includes all standard TCs. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Aug 2008 19:43:10 +0200

> single module that includes all standard TCs. 

I believe the sentence in question is a policy rule and has no sound
technical basis. If the rule does have a technical basis, then the
SMIv2 has (i) a technical defect since TC name collisions can happen
in non-"standard" modules and (ii) there is no mechanism in place to
actually guarantee unique TC names in all "standard" information
modules. (And I am not asking the question what "standard" in quotes
means. ;-)

In the future and the concrete case of YANG, we should try hard to
properly separate policy from mechanisms.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 15 Aug 2008 11:52:52 +0200

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, August 14, 2008 8:43 PM
> To: Romascanu, Dan (Dan)
> Cc: Randy Presuhn; MIB Doctors (E-mail); [email-masked]; 
> [email-masked]
> Subject: Re: [OPSAWG] 
> toretraceroutes-10.txtandRFC4560
> 
> > IMO the fact that IMPORTS statements referencing these descriptors 
> > must use the actual module name does not contradict in any way the 
> I believe the sentence in question is a policy rule and has 
> no sound technical basis. If the rule does have a technical 
> basis, then the
> SMIv2 has (i) a technical defect since TC name collisions can 
> happen in non-"standard" modules and (ii) there is no 
> mechanism in place to actually guarantee unique TC names in 
> all "standard" information modules. (And I am not asking the 
> question what "standard" in quotes means. ;-)
> 
> In the future and the concrete case of YANG, we should try 
> hard to properly separate policy from mechanisms.
> 
> /js
> 

I hope indeed that YANG will make a better job in making clear the
status of its statements. Standards are not written only for the close
circle of the participants in the process but for broad implementation
that can happen many years later and be done by very different people.
What seems to be a very clear and obvious statement in a Full Standards
document should not be in the situation to be interpreted so differently
years later.  

Dan

---

From: "tom.petch" <[email-masked]>
Date: Fri, 15 Aug 2008 10:41:33 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: "MIB Doctors (E-mail)" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, August 14, 2008 7:43 PM
Subject: Re: [OPSAWG][OPS-DIR]
http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes -10.txtandR
FC4560

> properly separate policy from mechanisms.

As one who spends a lot of time consuming modules, I do not mind whether it is
policy or mechanism but I do care about the result.  Were I a producer of
modules (SMI, XSD, YANG), then I might choose namespace names and prefixes that
were easy for me in the narrow field in which I were involved, since they would
soon become second nature to me and no barrier to understanding.

As a consumer, I have to handle everything and know how much harder XSD is to
understand compared to SMI because of its approach to namespaces and prefixes.
I want YANG to be as prefix-free as possible, in the namespaces of types,
objects and so on and a set of constraints now would make that more likely.
Else we will have standard types incorporated from many different sources, each
with a different namespace, and with each document author opting for a different
prefix for the same namespace, a nightmare for me.

I did ask, many years ago on the MIB list, where there was a registry of TCs and
if there wasn't one, then how did they keep their uniqueness.  To which the
answer was it just happened, aided by Unix string handling tools which scanned
every RFC and I-D in existence.  But I think that that is to underrate the group
of expert(i)s(e) that grew up with SMI and made it so.  Nowadays, I think we
need something more formal to recreate the simplicity of SMI(:-) in YANG.

Tom Petch