Draft: draft-ietf-netconf-prot-10 Reviewer: Joel M. Halpern [joel@stevecrocker.com] Review Date: Saturday 12/17/2005 2:48 PM CST LC Date: 12/07/2005 Summary: This document is nearly ready for publication as a proposed standard. It has some issues that should be considered. moderate: I can not find an actual description of the content of a element. I am not refering to the question of what data elements are to be used (that is for the data model I believe.) Rather, I am referring to the absence of a description of how the element actually selects an element to configure, and what attributes are legal on config elements. Reading between the lines, it appears that parallels except that it can have the operation attribute, which is not matched with the underlying data model. And for merge / replace operations seems to assume that the engine has a keying model which will allow it to determine which elements are keys and which elements are replacement values to go with the keys. Such knowledge is not unreasoanble. But it does not appear to be stated anywhere. minor: I believe the more recent XML RFCs have deprecated the distinction between URI and URN. If so, the second sentence of 3.1 about "MUST be URIs, and SHOULD be URNs" may not be particularly helpful. The NETCONF document sometimes uses the phrase "application protocol" for the transport protocol (SSH, TLS, BEEP, ...) This is used for example in 2.1 and 2.2. In other places (including 4.3) "application level" is used to mean the application running over the NETCONF protocol. There, "transport" is used for the supporting protocol. The filtering description starts using a path (file or XPATH like) terminology without providing any explanation of what "path" exactly means. 6.1 talks about the conceptual tree. While 6.2.2 talks about the "absolute path". Some descriptive text would be helpful. (I am guessing this is a reference to the applicable portion of the XPATH terminology, but the text does not seem to say.) is introduced in the example of getting a configuration in a given format. appears to be used to hold the requisite xmlns parameter. I suspect that the intent is that the xmlns parameter can be put on whatever the known top level element (document element) is of the configuration. If so, a little more wording before the example would be helpful. (If something else is intended, then significantly more wording is required.) The description of at the beginning of 7.2 states that this operation "allows the new configuration to be expressing several ways, such as using a local file, a remote file, or inline." However, there is no explanation in the parameters or related text of how one would specify a local file or a remote file. That should not be left purely to the schema. (I note that there is text about this in the section 7.3. Either similar text should be in 7.2, or the wording in the intro of 7.2 should be removed.) It probably would be helpful to explain in 8.3.4.1 the difference between a from candidate to running as compared to a operation. A simple forward reference to the Confirmed Commit capability may suffice. It is odd (not wrong, just odd) that in describing :candidate, the ability to use candidate as a source or target is described in the text, not in the modifications to operations section. But the modifications to lock and unlock, which use the element are described in the modifications section (6.2.5.1.) It is unclear whether the support of the :startup capabilities implies the ability to perform an on the configuration. As written, the text implies that such is not permitted. However, it would be better if this were stated explicitly. (And if this is not the intent, then more words are clearly required. In section 8.8 describing the :url capability, there is reference to various protocols being supported. I suspect that what is intended is actually support for different url schemes (after all, file: is not a protocol.) Down in appendix D (D.1.2, etc.) there is an assumption that the support of the :url capability implies support for named files. Probably, what is need here is that the sentence reference the :url capability should refer to the :url scheme with the file scheme supported. editorial: In the initial description of capabilities in 1.2, it says The capability definition may name one or more dependent capabilities. To support a capability, the server MUST support any capabilities upon which it depends. I presume that the first sentence is trying to say that a capability definition may name one or more capabilities upon which it depends, or upon which it is dependent. The common usage for "dependent capabilites" would mean that it names the capabilities which depend upon it, making extension difficult.