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

From: David Partain <[email-masked]>
Date: Thu, 31 Jan 2008 07:47:49 +0100

Hi,

For your info, the modeling language requirements draft has been updated.  
You'll find the new version at 
http://www.ietf.org/internet-drafts/draft-presuhn-rcdml-01.txt

Cheers,

David

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 31 Jan 2008 09:22:10 +0100

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?  

Thanks and Regards,

Dan

> -----Original Message-----
> From: David Partain [mailto:[email-masked]] 
> Sent: Thursday, January 31, 2008 8:48 AM
> To: [email-masked]
> Subject: [NGO] FYI: draft-presuhn-rcdml-01.txt
> 
> Hi,
> 
> This email was protected during delivery to Avaya with TLS encryption
> 
>

---

From: David Partain <[email-masked]>
Date: Thu, 31 Jan 2008 09:51:24 +0100

> 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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 31 Jan 2008 14:58:42 -0500

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

> 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
>