Re: [netmod] AD review of draft-ietf-netmod-arch-07

[Phil Shafer <[e-mail]>]

"Romascanu, Dan (Dan)" writes:
>Please find below the AD review of draft-ietf-netmod-arch-07.txt

Thank you for the review.

>> Existing data modeling
>   languages such as XSD and Relax NG were considered, but were rejected
>   because the problem domains have little natural overlap.
>
>I do not understand this - what 'problem domains'? As I remember XSD and
>Relax NG were not considered sufficient because they did not meet a
>number of specific requirements for network device modeling, as well as
>some of the format needs. 

The next sentence discusses the normal use for existing schema
languages (text documents), but I've added some more explanatory
text.

>T2. Section 3.2:
>>  Network-wide configuration: NETCONF supports robust network-wide
>configuration transactions via the confirmed-commit capability
>This claim sounds a little 'marketing' - why is confirmed-commit
>necessarily related to network-wide configuration? Is it sufficient? 

I don't see this as marketing, but I've added some additional text
to back up the claim.

>T3. 
>
>> Implementation costs: Significant effort has been made to keep
>implementation costs as low as possible.
>
>Maybe. What are the results of these efforts? Do we have any information
>about implementation costs at this stage? How are they measured? 

Not sure what to do with this comment.  The claim is that we
worked to keep implementation costs down, which is true.  I
do not have proof that implementation costs are lower that any
competitive design, but that doesn't invalidate the claim that
we tried to be conscious of the costs and worked to reduce them.

>T4. Section 3.3.4.1 - I believe that we need to discuss here the
>implications of the non-compliant servers on hard-coded applications.
>How can a developer avoid that they break? Would the deviations
>mechanism help in preventing at least some cases of non-compliance that
>can be anticipated? 

We have no firm guidance in this area, since this is something
only experience can provide.  The need to violate contracts are
typically overly specific and implementation-specific details
appearing in modules that are supposed to run on a variety of
implementations.  Also the attitude of "well, heck, everyone
will do it the way I did it!  Shucks, why wouldn't they?".
Are you looking for this sort of additional text?

>E1. idnits complains of several things among which the following need to
>be addressed: 
>
>Miscellaneous warnings:
> 
>------------------------------------------------------------------------
>----
>
>  -- The document has a disclaimer for pre-RFC5378 work, but was first
>     submitted on or after 10 November 2008.  Does it really need the
>     disclaimer?

This change was something xml2rfc required.


>  == Outdated reference: A later version (-06) exists of
>  == Outdated reference: A later version (-09) exists of

Fixed.

>E2. Section 1.1 - 
>> The NETCONF specification defines a small set of operations
>a reference to 4741 seems to be in place at this point. 

Fixed.

>E3. same - 
>> In 2008 and 2009, the NETMOD working group produced a specification
>Well, we are beyond mid-2010 and the RFC is not yet approved. We should
>say 2008-1010 and hopefully we'll stay with this. 

The work was done in 2008 and 2009.  Most of 2010 was spent in
intense discussion about what "default value" means.

>E4. Section 2.1 - what does the list of operations in the table in page
>8 include 'commit' and does not include 'delete-config', 'close-session'
>and 'kill-session'? 

I added delete-config, but not the *-session, since they are more
self-management that real operations.  No one is looking for a
network management protocol that knows how to kill a session.

>E5. Section 2.3.2 
>> DSDL is considered to be the best choice for the given purpose
>What purpose?

Fixed.

>E6. Section 3.1: 
>> The sequence of events for the typical client/server interaction is
>   as follows:
>...
>   Note that there is no requirement for the client or server to process
>   the YANG modules in this way. 
>The two statements seem contradictory. If the second statement is true
>than in the first s/is as follows/may be as follows/

Fixed.

>E7. Section 3.2
>> YANG addresses many of the issues raised in the IAB NM workshop.
>s/YANG addresses/NETCONF and YANG address/

Fixed.

>E8.
>> Post-processing: Use of XML will maximize the opportunities for
>post-processing of data, possibly using XML-based technologies like
>XPath, XQuery, and XSLT.

Fixed.

A new version should be out by Monday.

Thanks,
 Phil