Subject: RE: RFC Editor edit list for approved netconf drafts

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 15 Jun 2006 15:33:44 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Friday, June 09, 2006 12:22 AM
> To: Netconf (E-mail)
> Subject: RFC Editor edit list for approved netconf drafts
> 
> Hi,
> 
> Somebody asked for this edit list earlier.
> It is available from the ID-Tracker as well.
> 

Just a matter of clarification. 

The list in the tracker is the ONLY list that the RFC Editor knows. The
documents are in the RFC Editor queue, and may progress quicker than you
believe based upon what is available in the tracker. It is not a common
practice to insert anything but formatting or typos fixes in AUTH48, so
if you believe that one or more of the documents will need further
edits, we should ask for them to be frozen, and if the changes are
consistent we may want to generate new versions to replace the one
currently in the queue. This needs not generate a new IESG approval
cycle, but the IESG should be informed about the changes so that
somebody who has any doubts about the new variant being too far from the
one that was approved has a chance to express his/her opinions. 

Dan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Jun 2006 09:00:02 -0700

> one that was approved has a chance to express his/her opinions. 

I will put together an RFC Editor note for you and the WG to
approve this weekend.

There is a fix in the XSD related to empty <config>
and <filter> elements (current XSD does not allow this
but it is definitely legal in NETCONF).

The text for the subtree filter clarification is more difficult
to write, but it should be done soon.

> Dan

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 16 Jun 2006 21:13:55 -0700

Hi,

IMO, there is no need for any edit wrt/ subtree processing.
I finally found the sentence that covers this (I wrote about
4 years ago!).

 From prot-12:

6.3.  Subtree Filter Processing

    The filter output (the set of selected nodes) is initially empty.

    Each subtree filter can contain one or more data model fragments,
    which represent portions of the data model that should be selected
    (with all child nodes) in the filter output.

    Each subtree data fragment is compared by the server to the internal
    data models supported by the server.  If the entire subtree data-
    fragment filter (starting from the root to the innermost element
    specified in the filter) exactly matches a corresponding portion of
    the supported data model, then that node and all its children are
    included in the result data.

    The server processes all nodes with the same parent node (sibling
    set) together, starting from the root to the leaf nodes.  The root
    elements in the filter are considered to be in the same sibling set
    (assuming they are in the same namespace), even though they do not
    have a common parent.

Note the 2nd sentence in para 3, and sentence 1 of para 4.
This is normative text.  The agent is clearly supposed
to process the filter from root to the leaves.
The phrase "entire subtree" applies recursively,
starting from the child nodes of <filter>.

IMO, this issue is closed, without any need for an RFC Edit.

Andy

>>> From: [email-masked] [mailto:[email-masked]] 
>>> On Behalf Of Andy Bierman