Subject: RE: [NGO] DM alignment

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 23 Nov 2006 12:02:01 +0200

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Thursday, November 23, 2006 12:27 AM
> To: NETCONF Goes On
> Subject: [NGO] DM alignment
> 
> Hi,
> 
> Although it is not clear what objectives actually will be 
> worked on, one of my objectives is to find the right balance 
> of SMI reuse, CLI friendliness, and OOA/SOA usability.
> 
> For example, the SMIv2 range clause cannot be represented in 
> RelaxNG or XSD.
> IMPORTS and tables are much simpler in SMIv2.
> Augmentation, lifecycle, access control, conformance, and 
> documentation mechanisms are much better in SMIv2 than anything else. 
> 
> There are obviously many more things that RelaxNG and XSD can 
> do that SMIv2 cannot, like attributes (metadata) attached to 
> data, arbitrarily complex nested data, comprehensive 
> extension and restriction mechanisms, appinfo, etc.
> 
> I think the point of the "DIFFSERV Info Model Challenge" is 
> to compare how we would model something complicated in 
> RelaxNG (and XSD?), using NETCONF verbs, to compare it to the 
> DIFFSERV MIB and source info model.
> IMO, this will require more DIFFSERV domain knowledge than 
> NETMOD domain knowledge to execute, but we'll see.
> 
> The reason the SMIv2 standard MIB modules cannot be ignored 
> is a matter of domain WG priority -- if a WG has spent a lot 
> of time already to agree on the MIB to manage their protocol, 
> that WG will not be highly motivated to start over and agree 
> on the standard knobs all over again to create a NETCONF data 
> model, regardless of the DM language we use.
> 
> IMO, a phased approach (independent of the DM language we 
> use) is needed:
> 
>  0) Create a standard XSD for SMIv2 data types and core TCs
> 
>  1) Automatic translation at the PDU layer
>     Special RPC (e.g., snmp-getnext) provides peek/poke 
> varbind-based API
> 
>  2) Direct, automatic data model translation
>     Algorithmically convert SMIv2 to XSD and access the converted MIB
>     with any NETCONF RPC method.  Access SMIv2 XML separately 
> from 'new'
>     and 'vendor' XML (e.g., separate namespace or separate branch
>     in data org tree).  Not clear if full edit-config is 
> possible or even needed.
> 
>  3) Creation of new modules, or manual conversion of existing 
> SMIv2 modules,
>     into 'deep models' (i.e., uses the full DM feature set)
>     These models may include new RPC methods, config data, 
> monitoring data,
>     notifications, etc.
> 
> Step (1) and (2) can be done at the same time as (3), or 
> skipped entirely.
> It's not clear to me what the IETF wants to do here.
> 
> 
> Andy
> 

The IETF is us. 

The issue is that need to reach consensus on what is best to be done
here. 

Dan

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Nov 2006 07:16:53 -0800

> The issue is that need to reach consensus on what is best to be done

I understand that.
I'm asking the people on this list what they think
we need to do to be successful in this standardization effort.
The first step should be to understand the problem space,
and realize that our bar for standardization and multi-vendor
interoperability
is much higher that getting a chunk of XML defined efficiently.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Nov 2006 07:16:05 -0800

I understand that.

Andy