Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: > On Thu, Oct 15, 2015 at 10:37:49PM +0200, Martin Bjorklund wrote:
> > > * p67 > > > > > > Similar to the comment for p63. Perhaps the right way is to phrase > > > this in such a way that is simply says leaf nodes containing a > > > default value may not be present in the XML encoding. Simply remove > > > NETCONF <get> or <get-config> specifics. > > > > Or maybe we should simply remove the last paragraph completely? For > > NETCONF, RFC 6243 details how leafs with defaults are handled. > > Well, yes, but then readers may not know about RFC 6243. Perhaps state > that leaf nodes containing a default value may not be present in the > XML encoding and point to RFC 6243 for further details how NETCONF > handles leafs with defaults (and I think the reference to RFC 6243 > would be informative). In some sense I think it is weird to talk about default values here. This text describes how leafs and their values are encoded. The default value is defined as the value being used if the leaf doesn't exist in the data tree, so why should we mention defaults here? > > > * p100 > > > > > > The XML encoding text starts with detailing NETCONF specifics. > > > Would it make sense to separate the XML encoding of the rpc and its > > > input/output from the specifics how the RPCs fit into NETCONF's > > > <rpc> system? > > > > > > Hmm. NETCONF and RESTCONF use quite different encodings of rpcs and > > their output. > > > > NETCONF: > > > > <rpc message-id="101" > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > <rock-the-house xmlns="http://example.net/rock";> > > <zip-code>27606-0100</zip-code> > > </rock-the-house> > > </rpc> > > > > <rpc-reply message-id="101" > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > <ok/> > > </rpc-reply> > > > > RESTCONF: > > > > POST to .../rock-the-house > > > > <input xmlns="http://example.net/rock";> > > <zip-code>27606-0100</zip-code> > > </input> > > > > result: 204 no content > > > > > > Maybe it would have been better to have a common encoding, like: > > > > <rock-the-house xmlns="http://example.net/rock";> > > <input>...</input> > > </rock-the-house> > > > > and > > > > <rock-the-house xmlns="http://example.net/rock";> > > <output>...</output> > > </rock-the-house> > > > > but this cannot be done now. > > > > So, maybe the simplest solution would be to rename the section to > > "NETCONF XML Encoding"? > > You mean section 7.14.4? Well, OK... Yes. > Too bad these RPC encodings are > actually different. Out of curiosity, was there a specific reason not > to use > > <rock-the-house xmlns="http://example.net/rock";> > <zip-code>27606-0100</zip-code> > </rock-the-house> > > in the RESTCONF POST or did this "just happen"? The reason is that we can't do output in the same way as NETCONF, and the current RESTCONF encoding of input is consistent with how we do output. But it is not too late to change this. This should be discussed in netconf though. > > > * p105 > > > > > > Again, the proposal is to separate the XML encoding of notifications > > > from the details how notifications work with RFC 5277. > > > > Also notifications are encoded differently in RESTCONF and NETCONF. > > Hm. > > > > * p120 > > > > > > The text in section 7.21.1 talks about NETCONF specific operations. > > > Is this actually necessary? Can the purpose of the config statement > > > not be described by referring to general concepts such as > > > configuration datastores instead of using protocol specific > > > operations? > > > > Yes, maybe we can just say: > > > > Data nodes representing configuration are part of configuration > > datastores. > > Yes. > > > > * p123 > > > > > > "All leaf data values MUST match the type constraints..." may be > > > read as 'all data nodes that contain values' or 'all instantiations > > > of nodes defined by the leaf statement'. > > > > I don't really see what you mean. Can you suggest new text? > > See above, I think 'leaf' sometimes means an instance of a leaf schema > node and sometimes it means all leaf instances of the data tree. Or I > am confused. I think here you mean 'all leaf instances of the data > tree' and not the subset of all 'instances of a leaf schema nodes'. Right; this is what the current text says: The following properties are true in all data trees: o All leaf data values MUST match the type constraints for the leaf, including those defined in the type's "range", "length", and "pattern" properties. Note the sentence before the bullet where it says that this is for the data tree. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
