Re: [NGO] external module properties

I think we have to define two ways of changing the module:
1) Where only the version changes, the module name and its URI stays the same, I would call 
this a compatible change (whatever that means :-)
Ericsson's definition for such a "compatible change" is that if a newer node is handled ONLY(!) 
by an older management system it will still work.
2) Where the module name and URI changes as well, any change is allowed. This really means 
writing a new module.

Balazs

Andy Bierman wrote:
> Martin Bjorklund wrote:
>> Hi,
>>
>> While I agree with Juergen about the general idea that YANG should not
>> try to enforce arbitrary rules on the user, in the case of 'revision'
>> I think it falls into the same category as 'namespace' and 'prefix'.
>> Neither is strictly speaking not required in all cases - a namespace
>> is not needed if the module is a type library such as yang-types; a
>> prefix is not needed if there are no local references in the module.
>>
>> And I also agree that the revision might be needed for proper schema
>> discovery.
>>
>> I think I'd rather see all three mandatory than all three optional.
>>
> 
> agreed.
AGREED !!!
> 
> The easy part (if there is one) is having a standard version ID.
> 
> The hard part is determining what changes are allowed without
> updating the version, and what changes are never allowed, even
> if the version is updated.
> 
> This is where MUST for standards and SHOULD for vendors is needed.
> 
>> /martin
> 
> Andy
> 
> _______________________________________________
> NGO mailing list
> NGO@ietf.org
> https://www.ietf.org/mailman/listinfo/ngo

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo