Re: [NGO] external module properties

["David Harrington" <[e-mail]>]

Hi,

It is important for an NMS to be able to tell which version of a data
model is supported by a managed element, so when it makes changes to a
configuration, it can make changes appropriate to the version
supported.

On a side note, keep in mind that some managed elements may have
multiple components, such as blades in a chassis, and the versions
supported might differ, so a Netconf server might also need to know
which version to use to perform validation.

dbh

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Andy Bierman
> Sent: Monday, April 28, 2008 10:02 AM
> To: Andy Bierman; Jon Saperia; NETCONF Goes On
> Subject: 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ngo
> 

_______________________________________________
NGO mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ngo