Re: [Gen-art] Assignment: draft-ietf-netconf-prot-11.txt

Joel M. Halpern wrote:
> This looks very close.
> There is one thing that I think needs to be handled, and one question.
>
> Firstly, the text refers to "the <url> element can appear as the 
> <config> parameter..."  As such, there appears to be a requirement 
> that whatever the data model defines <config> to be, it must be 
> allowed to have a URL as its contents.  Can we say this somehow in 7.2?

No.
<url> appears instead of the <config> element.
It is not part of any data model.

>
> Secondly, the examples all seem to assume an outer <top> element in 
> the config.  I can not actually tell if this is required.  If it is, 
> should we say something about that in 7.2?

The <top> element is just an example.
I guess the document could stress that the examples
are not normative.
Data model content is not in any way constrained by the
examples in this draft.

>
> Thanks for taking the time to address this,
> Joel

Andy

>
> At 03:15 PM 2/24/2006, Rob Enns wrote:
>> Hi Joel,
>>
>> Netconf is content agnostic.  .....
>>
>> You are right that we never connect this back to the contents
>> of the <config> element, and we should.  How about adding the
>> following to section 5.2:
>>
>>
>>     NETCONF carries configuration data inside the <config> element
>>     that is specific to device's data model.  The protocol treats the
>>     contents of that element as opaque data.  The device uses
>>     capabilities to announce the set of data models which the
>>     device implements.  The capability definition details the
>>     operation and constraints imposed by data model.
>>
>>     Devices and managers may support multiple data models,
>>     including both standard and proprietary data models.
>>
>> The discussion of the <config> element in section 7.2 should also be
>> expanded.  How about the following?
>>
>>       config:
>>
>>         A hierarchy of configuration data as defined by one of the
>>         device's data models.  The contents MUST be placed in an
>>         appropriate namespace, to allow the device to detect the
>>         appropriate data model, and the contents MUST follow the
>>         constraints of that data model, as defined by its capability
>>         definition.  Capabilities are discussed in section XXX.
>
>
>

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art