Re: [NGO] external module properties

[Andy Bierman <ietf at andybierman.com>]

Ladislav Lhotka wrote:
> Andy Bierman píše v Út 29. 04. 2008 v 11:00 -0700:
> 
>> We should do what we can within the XML sandbox.
>> I agree with your comment about using the namespace URI instead
>> of a long string for the module name.  There are enough static
>> mappings to deal with already.  However, these URIs will
>> not be very easy to memorize, unlike module names.
> 
> Given the way how NETCONF works, the capability URIs are supposed to be
> the identifiers that are communicated between the parties. Then each
> party can have its own catalog that maps this URI to a local file name
> (that even needn't be globally unique) or an URL in general. This way,
> the file name of the module is a non-issue and search path can be
> handled as well.
> 

Excellent point.
I am envisioning a system which includes a mandatory standard
'schema-discovery' mechanism.  The <hello> exchange is a bad
place for all this versioned module to namespace mapping info
(even though that's exactly what I have implemented now ;-)

> I would also prefer to encode version numbers (if there are any) to the
> URI rather than invent yet another meta-parameter of YANG models.
> 

We wrapped around the axle once before on this topic.
IMO:

The namespace URI should be stable.  It is assigned in
the first version of the module.  It can never change.
If the module is obsolete, the namespace is still 'used up',
and can never be reused in another module.

In XSD, the <schema> 'version' attribute should be used in addition
to the targetNamespace, to determine the exact schema content.
In YANG, each new version of a module (std:MUST/vendor:SHOULD)
include a new revision-stmt, which has a date string which becomes
the new version identifier.


> Lada
> 

Andy

_______________________________________________
NGO mailing list
NGO at ietf.org
https://www.ietf.org/mailman/listinfo/ngo