Re: [netmod] js review of draft-ietf-netmod-arch-05.txt

[Andy Bierman <[e-mail]>]

On 06/16/2010 02:42 PM, Juergen Schoenwaelder wrote:
> On Wed, Jun 16, 2010 at 09:40:16PM +0200, Phil Shafer wrote:
>   
>> Juergen Schoenwaelder writes:
>>     
>>> this is my WG last call review of <draft-ietf-netmod-arch-05.txt>.
>>>       
>> Many thanks for the comments.  All have been made except the following:
>>
>>     
>>> d) p4: Did operators really ask for "low implementation costs"? I
>>>       would understand if they ask for "low deployment costs" - low
>>>       implementation costs is something vendors usually worry about.
>>>       
>> The term "implementation costs" is used in rfc3535, so assumably
>> the workshoppers were comfortable with this term:
>>     
>   
>>   5. Consolidated Observations
>>    ...
>>    16. The implementation costs have to be low on devices.
>>    17. The implementation costs have to be low on managers.
>>     
>  
> The workshop was not just attended by operators, see RFC 3535 for the
> details. The sentence in question talks about operators, not the
> workshop attendees and thus my question remains valid.
>
>   
>>> W) p19: Should the section describing the device modeler not mention
>>>        that the developer should write deviation statements in cases
>>>        where his implementation puts restrictions on the data model?
>>>       
>> I'm iffy here, since we want to discourage deviations.
>>     
> I thought we introduced the deviation statement since we believe a
> honest description of what an implementation does is worth to have.
> So if there are deviations, I think they should be documented. Or
> are you saying that it is better to not document them?
>
>   
>>> 5) p27: Add the following section:
>>>
>>>   4.3.3.4 Introduction of Meta-Data Tags
>>>
>>>      The NETCONF protocol might be extended to carry meta-data tags
>>>      (for example encoded in XML attributes) that identify whether an
>>>      XML element carries configuration data, operational state data,
>>>      or statistical data. This approach allows responses to <get>
>>>      operations to contain mixed data, making it easy for clients to
>>>      separate configuration data from operational state data. Servers
>>>      may be allowed to skip over any non-config data supplied by
>>>      clients in <edit-config> or <copy-config> operations.
>>>       
>> I do not want to add this text, since this not a workable solution
>> in the current YANG/NETCONF world.  We certainly don't want to
>> encourage modelers to step in this direction at this time.
>>     
> We do exactly this now to identify defaults in explicit config
> implementations - so if this is not workable, we should remove the
> attributes from with-defaults.
>
>   
>>> 6) p27: Does section 4.3 belong into this document? Unfortunately, as
>>>        long as the WGs have not converged to a solution, I believe it
>>>        is necessary to keep this text since we right now leave it to
>>>        the data modelers to figure out what to do. I believe this is
>>>        actually a bad idea but lets be honest about it.
>>>       
>> Section 4.3 was added at your request.  I am not happy with it,
>> since it doesn't contain any useful direction to modelers other
>> than "we don't know either".  I'd be happy to remove it, if that
>> is the concensus of the WG.
>>     
> My preference would be that 4.3 is not needed. However, since we do
> not seem to move into the direction of answering the question how we
> prefer to represent operational state, the second best choice for me
> still is to make the problem clear and to describe the solution space.
> This will help data modelers to understand the issue and pick one of
> the solutions.
>
>   

I do not think the NETCONF WG or the NETMOD WG has agreed
on any standard classifications for data nodes other than
the YANG config-stmt (=T/F).   If people think the NETCONF
operation set is wrong they should post comments on 4741bis.

As it stands, if the operator is allowed to alter the value
of a data node, it better be config=true.  If the operator
is never allowed to alter the value of operational data,
then it really is config=false, and it has to be returned
in a <get> operation.  We have known for years that
there is stuff that falls in between, and have always
decided not to bother doing anything about it.
Why it this the time, especially since YANG considered
this and rejected it, insisting that config-state is a boolean.

I don't think sec. 4.3 belongs in this Informational document.
If  any standard NETCONF behavior related to operational state
is ever done, then these definitions can be added then.


> /js
>
>   

Andy