Re: [NGO] external module properties

Juergen Schoenwaelder wrote:
> On Sun, Apr 27, 2008 at 08:49:53AM -0700, Andy Bierman wrote:
> 
>> My point is that we need to thinking more holistically about the
>> entire management system, which includes problems such as human factors
>> and module life-cycle.
> 
> A data modeling language specification is the wrong place to address
> human factors.

Really?  I thought YANG existed to provide the human-friendly data modeling
interface that XSD and DSDL cannot provide.  It seems to me human factors
are critical to CM.  Configuration errors are a big problem in real
networks.  Providing an API and operational environment which is
resistant to human-introduced errors is a very high priority to me.

> 
>> We tried the 'blinders-on' approach with SMING/EOS and that didn't
>> work out so well.  Focusing on the DML and ignoring the protocol (or
>> vice versa) leads to incomplete or broken solutions.
> 
> YANG is NETCONF very specific; it is by its very design a domain
> specific language for NETCONF data models and not comparable to
> SMING/EOS.

I think there are plenty of similarities and lessons to be learned
from SMING and EOS.  I believe you wrote an RFC on the subject. ;-)
The YANG and 'Why YANG?' drafts cite the SMIng language
as the starting point for YANG.

> 
>> Of course the namespace URI is mandatory, because it is needed
>> to properly implement the NETCONF protocol.  The 'YANG philosphy'
>> (whatever that is) has nothing to do with it.  Likewise, the
>> revision date is needed to properly implement NETCONF applications.
> 
> There is a fine distinction here between a language definition their
> implementations and the usage of a language in a larger context. For
> me, a missing revision statement is something I like to generate a
> warning for but it is not an error since NETCONF continues to function
> without the revision information.
> 
> Note that I am not concerned about this particular case so much; I am
> concerned the logic behind. The SMI has been full of CLRs in order to
> make this a better world and with YANG we tried to get over this and
> we tried to reduce CLRs to a minimum, leaving the specification of
> CLRs to CLR documents (called coding styles in the software world and
> guidelines in this space).
> 

I disagree.
This is a known problem in XML and CM, which needs to be addressed.
Should we standardize on the namespace URI as the version ID?
I hope not.  IMO, we need a standard version field that can be
retrieved with the the schema-discovery DM, and is deterministically
derived from the YANG module (or explicitly entered, like LAST-UPDATED).

IMO, it is a bad idea to mix modules with and without versions.
The namespace-stmt is mandatory because YANG is forcing good XML usage.
Forcing the use of a version ID for good XML usage is no different.

>> YANG is not decoupled from NETCONF, and NETCONF is not decoupled
>> from the actual CM problem space.  One needs to consider that sometimes
>> CLRs are really CBRs, and important for real interoperability.
> 
> Which one of <http://en.wikipedia.org/wiki/CBR> do you mean? I guess
> you mean the "Comic_Book_Resources". ;-)
> 

Not Constant Bit Rate either.

Crappy Big Rule.

> /js
> 

Andy

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