[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notes from Offline Netconf Data Model Discussion
hi
Here are my notes from the offline netconf data model discussion from
the Monday in Paris. We also talked about some of the other
specifications, but I will send some thoughts on of that separately.
1. It was noted we may want to reorganize the document. The current
division into 'considerations for ...' is more geared towards someone
writing the specification rather than someone trying to implement it.
2. There are typos in the examples in section 2.2.2
3. There was discussion about whether we really needed the element
status described in section 2.2.3. Maybe. Maybe not.
4. It was noted that the schema-level conformance defined in section
2.2.4, while machine readable without requiring an superfluous construct
did not cover conditional conformance. If this is BGP, then this object
is mandatory, for example. Is this a requirement?
5. Section 2.3 describes access control and it was noted there is a
proposal to spin this out as a separate work item. It was observed that
the concept of a resource category was powerful. It was suggested that
people read about SAML.
6. There was a lot of discussion around what was required for backwards
compatibility.
6.1 Here is the use case discussed.
V3 (upgrade)
V3 V2 V1
[NE-1] [NE-2] [NE-3]
\------------- ------------------/
\-----/
|
Manager/Operator
The scenarios depicted are a management application being able to
communicate with and configure different versions of a schema on
different network elements. In addition, at some point NE-2 upgrades its
version and now supports V3.
6.2 It was suggested that whether or not one could write an XSLT
function to transform from one version to the next was an interesting
test for backwards compatibility.
6.3 The 'isRequired' flag used in some XML-based solutions could be used
to flag when a version 3 of a Schema cannot accept version 2 of a schema
and auto-fill in a particular field. This way either defaults can be
provided or the request can fail in a predictable way. It would get
added to those elements that are can't be defaulted.
6.4 It was observed that enumerated lists are sometimes just lists that
one can add new values to but other times they are state machines which
some felt should not be changed between versions. This is a case of the
same syntax with two different semantics? Can 'isRequired' be applied to
enumerated lists to solve this so we can tell the difference?
7. There was discussion about whether version information should also be
available in other languages or whether the header of the XML Schema
should identify the language used within the Schema.
8. There was discussion about IANA namespace management. It was
suggested that the 'no document required' method with one big namespace
was one option. There was not general agreement on that though.
9. It was suggested that we work with w3C to address any gaps we see in
what they have produced.
10. There was a lot of discussion around the recommendation on
containers for lists in section 4.5. Consider the following content on a
bookshelf
shelf 1: book, book, book, book
shelf 2: book, book, cd, book, book, cd, cd, snow globe
In both cases the shelves themselves act as a natural container for the
content. The suggestion to wrap plural books with a <books> tag is in
the first case superfluous
<shelf><books><book/><book/><book/><book/></books></shelf>
in the second case, it actually provides a couple of options
<shelf><books><book/><book/><book/><book/></books><cds><cd/><cd/><cd/></
cds><snow globe/></shelf>
which loses the order of the items on the shelf or
<shelf><books><book/><book/></books><cd/><books><book/><book/></books><c
ds><cd/><cd/></cds><snow globe/></shelf>
Which has the singular cd not wrapped and the plural one wrapped and
puts more emphasis on the grouping of items than likely makes sense for
items sitting on a bookshelf.
Note that the shelf is a naturally occurring item in system, while the
wrappers of <books> and <cds> are mere artefacts of modeling. While
these artefacts are useful in some cases, in this one, they seem to be
getting in the way.
Some ways to improve this section, would be to suggest that the
artificial wrapper is only recommended when no natural wrapper exists.
Also, an attribute that indicates when something is only a container
could help. We could also not talk about naming of these wrappers, which
would allow the <shelf> to become the wrapper for all the books, cds and
snow globes.
The idea of a 'compound document' might be applicable here. TBD.
11. The document needs to discuss accessing instance information.
12. Proper tag names as described in section 5.2.1 was discussed. The
current text, which had its beginnings in the netconf protocol
specification, indicates only ASCII (7-bit). It would be good to
understand why that is. While this would be necessary for IETF published
Schema, it potentially does not need to be the case for proprietary
Schema and those published by other organizations. It was noted that a
better explanation of 'lower Camel' is needed since while this is what
SNMP used for naming, not everyone is familiar with the term.
13. Error messages as defined in section 5.3 were discussed. While there
was some wish for more format for the error messages, the framework we
shall need to fit into has already been defined by the netconf protocol.
There was discussion on whether the error messages were static, or
contained instance information. For example, does the error message say
'Unable to read book' or does it say 'unable to read 'War and Peace''?
Does this instance information require something like syslog SD-params
or is something more like C printf statements sufficient?
Option 1. "I can't read this book"
Option 2. "I can't read ", <keyref for book title> ->
"I can't read 'War and Peace'";
"I can't read 'Ulysses'"
Option 3: "I can't read this book" ->
"I can't read this book <info>
<title>War and Peace</title> <language>English</language><type>Very
Small</type></info>
"I can't read this book <info>
<title>Ulysses</title> <readingLevel>Very Hard</readingLevel></info>
Note that in option 3 I have shown no predefinition of what additional
information would be supplied. An option 4 could be a combination of
option 2 where the information is predefined and option 3 where the
information is formatted in xml. This might run into some problems with
the fact that technically the tag we are cramming all this into is
expecting a string. The syntax for option 3 and 4 could also be more
syslog-like, creating I guess option 5 and 6.
14. In discussion of item 5.5 'Granularity of a data model', Dan has
agreed to provide some explanation and examples.
15. In section 6.1 and 6.2, it was noted that we still need examples and
to confirm that keyref is useable for us.
16. For section 7.1 which talks about Schema Identity, it was suggested
that we should look at Dublin Core and use that instead.
Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>