Subject: Re: [NGO] FYI: draft-presuhn-rcdml-01.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 3 Feb 2008 18:50:21 +0100

I agree that a list of use cases is a very well structured way to
conduct the discussion. I would like to see this pursued for the
upcoming discussions. I did not make my mind whether it can completely
replace a detailed list of requirements, but it can provide a shorter
and concatenated list to refer to. 

Dan

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, January 31, 2008 9:59 PM
> To: 'David Partain'; Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [NGO] FYI: draft-presuhn-rcdml-01.txt
> 
> Hi,
> 
> I think the proposers should not spend time debating whether 
> their solution meets the requirements listed in rcdml. 
> 
> I think it would be a  better use of time to discuss whether 
> use cases related to interoperability **cannot** be met by a 
> specific data model designed using a proposed DML. And I 
> think the baseline should be the use cases already able to be 
> supported by the existing IETF Standard Structure of 
> Management Information, and existing standard MIB modules 
> (currently in combination with SNMP).
> 
> Use cases for SMI and MIB modules:
> 1) agreement on a set of standard knobs (or proprietary knobs 
> in a proprietary MIB module). These knobs can be defined in a 
> clear and unambiguous manner including the restrictions that 
> apply to the knobs, such as range, character set, what gets 
> counted in a counter, and so on. Ideally, Netconf knobs would 
> support all the types of management object properties already 
> supported by MIB modules, unless it can be shown that such 
> properties do not apply to configuration.
>  
> 2) clear specification in the schema of what 
> MUST/SHOULD/MAY/MUST NOT/SHOULD NOT be supported to claim 
> compliance to the standard, to support vendor-neutral interoperability
> 
> 3) modular documents that can be formally validated using 
> tools such as smilint
> 
> 4) enough information for implementers to implement, with 
> internal engineering choices being implementer-dependent, but 
> with vendor-neutral formats on-the-wire
> 
> 5) enough human-readable description/qualities that operators 
> can read the raw schema to understand the meaning of a managed object
> 
> 6) enough machine-readability that applications can 
> effectively parse (and compare/contrast/utilize) the 
> information across multiple vendor implementations, and 
> across multiple vendor implementation releases.
> 
> 7) the document can be used by network management 
> applications to programmatically create corresponding 
> databases of information (i.e.
> an NMS can IMPORT a MIB module to create corresponding record 
> formats in a database)
> 
> 8) each managed object is clearly instance-addressable such 
> that a sender can label the object instance being sent in a message
> 
> 9) the receiver of a message can clearly identify the 
> instance of any object contained in a message, and can 
> validate the data types and values (such as range, character 
> set, etc.) of objects being passed in a message
> 
> 10) a protocol-dependent message MAY contain a very small 
> subset of the managed objects defined in a schema (e.g., one 
> object from a
> schema) and still meet the previous requirements
> 
> 11) a protocol-dependent message MAY contain a mixture of 
> managed objects defined in different modules/schemas, and 
> still meet the previous requirements
> 
> In my eyes, if you cannot support these use cases, which can 
> be currently met using SMI and MIB modules (with SNMP 
> messages), then you have not met the baseline requirements 
> for a next-generation Structure of Management Information 
> suitable for Netconf configuration management.
> 
> dbh
> 
> > -----Original Message-----
> > From: David Partain [mailto:[email-masked]]
> > Sent: Thursday, January 31, 2008 3:51 AM
> > To: Romascanu, Dan (Dan)
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [NGO] FYI: draft-presuhn-rcdml-01.txt
> > 
> > On Thursday 31 January 2008 09.22.10 Romascanu, Dan (Dan) wrote:
> > > I have a question for the members of the design team and
> > other people
> > > who follow closely this work, which can help the IAB and IESG in
> the
> > > discussion about the BOF. I counted (roughly) 90 requirements in
> the
> > > I-D, 50 are marked Agreed, 36 Not Agreed, 4 of them do not
> > have anything
> > > mentioned. I understand that the design team has another
> > couple of weeks
> > > of work, and this represents a snapshot of the level of
> > consensus today.
> > > Are the Not Agreed requirements things the team just did
> > not get to the
> > > point of discussing, or have major differences been identified,
> and
> > > these have good chances to remain open?
> > 
> > Greetings,
> > 
> > My take: Not Agreed means we've talked about it in the 
> design team and 
> > will not be able to reach internal agreement in the design team 
> > whether this is a requirement for a data modeling language for 
> > NETCONF.
> > 
> > Through our discussions, many have gone from "Not agreed" 
> to "Agreed", 
> > but I don't think very many more will.
> > 
> > The idea is that proposals will make a case for the ones they care 
> > about during the BOF presentation (should we get a BOF).
> > 
> > Cheers,
> > 
> > David
> > 
> > 
> > _______________________________________________
> > NGO mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ngo
> > 
> 
> 
> 
_______________________________________________
NGO mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ngo