Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1413A70C1; Tue, 8 Feb 2011 02:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.442 X-Spam-Level: X-Spam-Status: No, score=-100.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-ZdWe6OhJ2j; Tue, 8 Feb 2011 02:06:05 -0800 (PST) Received: from relay.versatel.net (beverwijk.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id A52903A70AB; Tue, 8 Feb 2011 02:06:05 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1PmkSY-0007PZ-Ch; Tue, 08 Feb 2011 11:06:10 +0100 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Joshua Bell" , References: In-Reply-To: Date: Tue, 8 Feb 2011 11:04:37 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18263 X-Mailman-Approved-At: Thu, 10 Feb 2011 08:11:39 -0800 Cc: Netconf Subject: Re: [apps-review] apps-team review of draft-ietf-netconf-4741bis-07 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 10:06:07 -0000 Josh, thanks for your review and comments All comments together are being considered by the editors and possibly will result in a new revision. We'll keep you updated. Bert Wijnen Document Shepherd ----- Original Message ----- From: "Joshua Bell" To: ; ; ; ; Cc: "SM" Sent: Monday, February 07, 2011 7:03 PM Subject: apps-team review of draft-ietf-netconf-4741bis-07 > == Boilerplate == > > I have been selected as the Applications Area Review Team reviewer for this > draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-netconf-4741bis-07 > Title: Network Configuration Protocol (NETCONF) > Reviewer: Joshua Bell > Review Date: 2011-02-04 > IETF Last Call Date: 2011-02-07 > > == Summary == > > This draft is almost ready for publication but has a few issues that should > be fixed before publication. The issues I note are not significant > detractions from the overall high quality and readability of the I-D. > > The I-D is an update to RFC 4741 and has therefore "stood the test of time". > I was not familiar with the previous RFC and thus reviewed the document as > "new to me", then went back and did a cursory review of my feedback to see > what applied to the previous document as well. > > == Major Issues == > > none > > == Minor Issues unique to the I-D == > > Section 3 XML Considerations includes: > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a > peer receives an 'rpc' message that is not well-formed XML, it SHOULD > reply with an 'operation-failed' error. If a reply cannot be sent > for any reason, the server MUST close the session. > > > The behavior when an 'rpc' message is received that is well-formed XML but > specifies an encoding other than UTF-8 is not strictly defined. This could > occur where the encoding is defined via an XML declaration, such as version="1.0" encoding="EUC-JP" ?> (XML declarations are explicitly > permitted a few lines down in the I-D). I suggest that the I-D specify that > if a non-UTF-8 encoding is specified the peer SHOULD reply with an > 'operation-failed' error, if this is the expected behavior. > > Section 8.9.1 XPath Capability Description includes: > > The data model used in the XPath expression is the same as that used > in XPath 1.0 [2], with the same extension for root node children as > used by XSLT 1.0 [11] (section 3.1). Specifically, it means that the > root node may have any number of element nodes as its children. > > > It is unclear how this applies. My understanding is that in XSLT this > wording refers to the results tree of a transform, and allows for a > transform which e.g. outputs a non-well-formed XML document with multiple > top-level elements (e.g. "") rather than a well-formed > document with a single root element. However, this section of the I-D is > describing the input data model to the XPath filter expression, and which > explicitly yields a node-set as a result rather than a result tree. If this > text is intended to describe the XML returned by the or > operation, it should be stated separately from the description of the XPath > data model. > > On a possibly related note, the next bit which describes how the node-set > selected by the XPath expression yields the output tree seems > underspecified: > > The response message contains the subtrees selected by the filter > expression. For each such subtree, the path from the data model root > node down to the subtree, including any elements or attributes > necessary to uniquely identify the subtree, are included in the > response message. > > > It is unclear (to me) exactly what the output should be when the node-set > results of the XPath expression contains multiple nodes. For example > (simplified > relative to the examples in the I-D). given the filter: > > select="/users/user[name='fred' or name='barney'] > > Would this yield: > > > > > fred > > > > barney > > > > > > or: > > > > fred > > > > > > > barney > > > > > The former is strongly implied by the non-XPath-based filter logic defined > in section 6 (i.e. the text "Specific data instances are not duplicated in > the response in the event that the request contains multiple filter subtree > expressions that select the same data."), but the latter is hinted at by the > note about the "XSLT extension for root node children" called out above. In > either case, more clarity in the normative text would be worthwhile, as well > as an example. > > > == Minor Issues in common with RFC 4741 == > > Section 4.1 and 4.2 define the usage of the "message-id" attribute. Since > the value is an arbitrary string selected by the sender, it is possible that > XML processing would modify this value as part of attribute-value > normalization: http://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize - I > suggest adding the requirement that senders ensure that message-ids are > already normalized per these rules so that they round-trip cleanly. > > Section 4.2 is where the element first appears but only in examples; > unlike 4.3 which explicitly calls out and 4.4 which explicitly > calls out ; is also not identified in the XML Schema in Appendix > B. This leads to the impression that is just an example element, but > it is defined normatively as part of the positive response in sections 7.1 > and 7.7 > > > == Nits in common with RFC 4741 == > > Section 5.1 has odd bulleting around the paragraph for "Running" (a single > bullet point). (This looks like residue from an earlier revision where > multiple datastores were defined but then made optional via capabilities.) > > Attribute names are called out inconsistently within the document. E.g. "... > the select attribute...", "containing a 'type' attribute...", "... a > "message-id" attribute...". For improved readability this should be > standardized. > > Finally, I did not manually verify all of the filter examples in Section 6. > From a cursory inspection, the introduction of the namespace wildcarding > (Section 6.2.1) should not change the validity of the samples from RFC 4741. > If there is a sample dataset and utility that could be used to quickly > validate the filters in all cases it would be a good idea. > > -- Josh > Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEAF93A6C83 for ; Mon, 7 Feb 2011 23:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTMUMNxuprWC for ; Mon, 7 Feb 2011 23:19:21 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8FC1E3A6AE3 for ; Mon, 7 Feb 2011 23:19:21 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 76BC9616002; Tue, 8 Feb 2011 08:19:26 +0100 (CET) Date: Tue, 08 Feb 2011 08:19:25 +0100 (CET) Message-Id: <20110208.081925.894192697347847020.mbj@tail-f.com> To: josh@lindenlab.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Feb 2011 08:11:48 -0800 Cc: rpe@juniper.net, andy.bierman@brocade.com, j.schoenwaelder@jacobs-university.de, apps-review@ietf.org Subject: Re: [apps-review] apps-team review of draft-ietf-netconf-4741bis-07 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 07:19:22 -0000 Hi, Thanks for your review and comments! All comments together are being considered by the editors and possibly will result in a new revision. But I have some follow up comments inline: Joshua Bell wrote: > Section 8.9.1 XPath Capability Description includes: > > The data model used in the XPath expression is the same as that used > in XPath 1.0 [2], with the same extension for root node children as > used by XSLT 1.0 [11] (section 3.1). Specifically, it means that the > root node may have any number of element nodes as its children. > > > It is unclear how this applies. My understanding is that in XSLT this > wording refers to the results tree of a transform In XLST, it applies to both input and output. This is specified in the last paragraph in http://www.w3.org/TR/xslt#root-node-children, repeated here: When the source tree is created by parsing a well-formed XML document, the root node of the source tree will automatically satisfy the normal restrictions of having no text node children and exactly one element child. When the source tree is created in some other way, for example by using the DOM, the usual restrictions are relaxed for the source tree as for the result tree. In NETCONF's case, the data model available from a server is a set of data models, where (normally) each such data model has its own top-level node, e.g.: ... ... In the XPath filters, these nodes are refered to using: /interfaces/... /system/... So the root node has all these top-level nodes as children. > On a possibly related note, the next bit which describes how the node-set > selected by the XPath expression yields the output tree seems > underspecified: > > The response message contains the subtrees selected by the filter > expression. For each such subtree, the path from the data model root > node down to the subtree, including any elements or attributes > necessary to uniquely identify the subtree, are included in the > response message. > > > It is unclear (to me) exactly what the output should be when the node-set > results of the XPath expression contains multiple nodes. For example > (simplified > relative to the examples in the I-D). given the filter: > > select="/users/user[name='fred' or name='barney'] > > Would this yield: > > > > > fred > > > > barney > > > > > > or: > > > > fred > > > > > > > barney > > > > > The former is strongly implied by the non-XPath-based filter logic defined > in section 6 (i.e. the text "Specific data instances are not duplicated in > the response in the event that the request contains multiple filter subtree > expressions that select the same data."), but the latter is hinted at by the > note about the "XSLT extension for root node children" called out above. In > either case, more clarity in the normative text would be worthwhile, as well > as an example. It is supposed to be the former. Note that the XPath expression really returns just a node set. This is just a set of nodes in the tree, and the idea is that when these nodes are represented in XML, the server will generate elements representing each node from the top, and not generate duplicate elements. So maybe we can just add the sentence you quoted above: Specific data instances are not duplicated in the respone. /martin Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF703A6E57 for ; Mon, 7 Feb 2011 10:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.092 X-Spam-Level: X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ywz6pTbf8ge for ; Mon, 7 Feb 2011 10:03:02 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 33C6F3A6E5E for ; Mon, 7 Feb 2011 10:03:02 -0800 (PST) Received: by iwc10 with SMTP id 10so5334125iwc.31 for ; Mon, 07 Feb 2011 10:03:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.39.67 with SMTP id f3mr17814783ibe.42.1297101786490; Mon, 07 Feb 2011 10:03:06 -0800 (PST) Received: by 10.231.160.133 with HTTP; Mon, 7 Feb 2011 10:03:06 -0800 (PST) Date: Mon, 7 Feb 2011 10:03:06 -0800 Message-ID: From: Joshua Bell To: apps-review@ietf.org, rpe@juniper.net, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com Content-Type: multipart/alternative; boundary=00032557635a38a7f0049bb50b1d Subject: [apps-review] apps-team review of draft-ietf-netconf-4741bis-07 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:03:04 -0000 --00032557635a38a7f0049bb50b1d Content-Type: text/plain; charset=UTF-8 == Boilerplate == I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netconf-4741bis-07 Title: Network Configuration Protocol (NETCONF) Reviewer: Joshua Bell Review Date: 2011-02-04 IETF Last Call Date: 2011-02-07 == Summary == This draft is almost ready for publication but has a few issues that should be fixed before publication. The issues I note are not significant detractions from the overall high quality and readability of the I-D. The I-D is an update to RFC 4741 and has therefore "stood the test of time". I was not familiar with the previous RFC and thus reviewed the document as "new to me", then went back and did a cursory review of my feedback to see what applied to the previous document as well. == Major Issues == none == Minor Issues unique to the I-D == Section 3 XML Considerations includes: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives an 'rpc' message that is not well-formed XML, it SHOULD reply with an 'operation-failed' error. If a reply cannot be sent for any reason, the server MUST close the session. The behavior when an 'rpc' message is received that is well-formed XML but specifies an encoding other than UTF-8 is not strictly defined. This could occur where the encoding is defined via an XML declaration, such as (XML declarations are explicitly permitted a few lines down in the I-D). I suggest that the I-D specify that if a non-UTF-8 encoding is specified the peer SHOULD reply with an 'operation-failed' error, if this is the expected behavior. Section 8.9.1 XPath Capability Description includes: The data model used in the XPath expression is the same as that used in XPath 1.0 [2], with the same extension for root node children as used by XSLT 1.0 [11] (section 3.1). Specifically, it means that the root node may have any number of element nodes as its children. It is unclear how this applies. My understanding is that in XSLT this wording refers to the results tree of a transform, and allows for a transform which e.g. outputs a non-well-formed XML document with multiple top-level elements (e.g. "") rather than a well-formed document with a single root element. However, this section of the I-D is describing the input data model to the XPath filter expression, and which explicitly yields a node-set as a result rather than a result tree. If this text is intended to describe the XML returned by the or operation, it should be stated separately from the description of the XPath data model. On a possibly related note, the next bit which describes how the node-set selected by the XPath expression yields the output tree seems underspecified: The response message contains the subtrees selected by the filter expression. For each such subtree, the path from the data model root node down to the subtree, including any elements or attributes necessary to uniquely identify the subtree, are included in the response message. It is unclear (to me) exactly what the output should be when the node-set results of the XPath expression contains multiple nodes. For example (simplified relative to the examples in the I-D). given the filter: select="/users/user[name='fred' or name='barney'] Would this yield: fred barney or: fred barney The former is strongly implied by the non-XPath-based filter logic defined in section 6 (i.e. the text "Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data."), but the latter is hinted at by the note about the "XSLT extension for root node children" called out above. In either case, more clarity in the normative text would be worthwhile, as well as an example. == Minor Issues in common with RFC 4741 == Section 4.1 and 4.2 define the usage of the "message-id" attribute. Since the value is an arbitrary string selected by the sender, it is possible that XML processing would modify this value as part of attribute-value normalization: http://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize - I suggest adding the requirement that senders ensure that message-ids are already normalized per these rules so that they round-trip cleanly. Section 4.2 is where the element first appears but only in examples; unlike 4.3 which explicitly calls out and 4.4 which explicitly calls out ; is also not identified in the XML Schema in Appendix B. This leads to the impression that is just an example element, but it is defined normatively as part of the positive response in sections 7.1 and 7.7 == Nits in common with RFC 4741 == Section 5.1 has odd bulleting around the paragraph for "Running" (a single bullet point). (This looks like residue from an earlier revision where multiple datastores were defined but then made optional via capabilities.) Attribute names are called out inconsistently within the document. E.g. "... the select attribute...", "containing a 'type' attribute...", "... a "message-id" attribute...". For improved readability this should be standardized. Finally, I did not manually verify all of the filter examples in Section 6. >From a cursory inspection, the introduction of the namespace wildcarding (Section 6.2.1) should not change the validity of the samples from RFC 4741. If there is a sample dataset and utility that could be used to quickly validate the filters in all cases it would be a good idea. -- Josh --00032557635a38a7f0049bb50b1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=3D=3D Boilerplate =3D=3D

I have been selecte= d as the Applications Area Review Team reviewer for this draft (for backgro= und on apps-review, please see http://www.apps.ietf.org/c= ontent/applications-area-review-team).=C2=A0

Please resolve these comments along with any other Last= Call comments you may receive. Please wait for direction from your documen= t shepherd or AD before posting a new version of the draft.

Document: draft-ietf-netconf-4741bis-07
Title: Network= Configuration Protocol (NETCONF)
Reviewer: Joshua Bell
Review Date: 2011-02-04
IETF Last Call Date: 2011-02-07

=3D=3D Summary =3D=3D

This dra= ft is almost ready for publication but has a few issues that should be fixe= d before publication.=C2=A0The issues I note are not significant detraction= s from the overall high quality and readability of the I-D.

The I-D is an update to RFC 4741 and has therefore &quo= t;stood the test of time". I was not familiar with the previous RFC an= d thus reviewed the document as "new to me", then went back and d= id a cursory review of my feedback to see what applied to the previous docu= ment as well.

=3D=3D Major Issues =3D=3D

non= e

=3D=3D Minor Issues unique to the I-D =3D=3D

=
Section 3 XML Considerations includes:

   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.  If a
   peer receives an 'rpc' message that is not well-formed XML, it S=
HOULD
   reply with an 'operation-failed' error.  If a reply cannot be se=
nt
   for any reason, the server MUST close the session.

The behavior when an 'rpc' m= essage is received that is well-formed XML but specifies an encoding other = than UTF-8 is not strictly defined. This could occur where the encoding is= =C2=A0defined via an XML declaration, such as=C2=A0<?xml version=3D&quo= t;1.0" encoding=3D"EUC-JP" ?> (XML declarations ar= e explicitly permitted a few lines down in the I-D). I suggest that the I-D= specify that if a non-UTF-8 encoding is specified the peer SHOULD reply wi= th an 'operation-failed' error, if this is the expected behavior.

Section 8.9.1 XPath Capability Description includ= es:

   The data model used in the XPath expression is the same as that used
   in XPath 1.0 [2], with the same extension for root node children as
   used by XSLT 1.0 [11] (section 3.1).  Specifically, it means that the
   root node may have any number of element nodes as its children.

It is unclear how this applies.= My understanding is that in XSLT this wording refers to the results tree o= f a transform, and allows for a transform which e.g. outputs a non-well-for= med XML document with multiple top-level elements (e.g. "<elem/>= <elem/><elem/>") rather than a well-formed document with a= single root element. However, this section of the I-D is describing the in= put data model to the XPath filter expression, and which explicitly yields = a node-set as a result rather than a result tree.=C2=A0If this text is inte= nded to describe the XML returned by the <get/> or <get-config/>= ; operation, it should be stated separately from the description of the XPa= th data model.

On a possibly related note, the next bit which describe= s how the node-set selected by the XPath expression yields the output tree = seems underspecified:

   The response message contains the subtrees selected by the filter
   expression.  For each such subtree, the path from the data model root
   node down to the subtree, including any elements or attributes
   necessary to uniquely identify the subtree, are included in the
   response message.

It is unclear (to me) exactly what the output should be when the node-set r= esults of the XPath expression contains multiple nodes. For example=C2=A0(simplif= ied relative to the examples in the I-D).=C2=A0given the filter:

=C2=A0=C2=A0 select=3D"/users= /user[name=3D'fred' or name=3D'barney']

Would this yield:

           <users>

    =
         <user>
               <name>fred</name>
             </user>

             <user>
               <name>barney</name>
             </user>

            </users>

or:




           <users>
             <user>
               <name>fred</name>
             </user>
           </users>


           <users>
             <user>
               <name>barney</name>
             </user>
           </users>

The f= ormer is strongly implied by the non-XPath-based filter logic defined in se= ction 6 (i.e. the text "Specific the request contains multiple filter subtree expressions = that select the same data."), but the la= tter is hinted at by the note about the "XSLT extension for root node = children" called out above. In either case, more clarity in the normat= ive text would be worthwhile, as well as an example.


=3D=3D Minor Issues in common with RFC 4= 741 =3D=3D

Section 4.1 and 4.2 define the usage of= the "message-id" attribute. Since the value is an arbitrary stri= ng selected by the sender, it is possible that XML processing would modify = this value as part of attribute-value normalization: http://www.= w3.org/TR/2008/REC-xml-20081126/#AVNormalize - I suggest adding the req= uirement that senders ensure that message-ids are already normalized per th= ese rules so that they round-trip cleanly.

Section 4.2 is where the <data> element first app= ears but only in examples; unlike 4.3 which explicitly calls out <rpc-er= ror> and 4.4 which explicitly calls out <ok>; <data> is also= not identified in the XML Schema in Appendix B. This leads to the impressi= on that <data> is just an example element, but it is defined normativ= ely as part of the positive response in sections 7.1 and 7.7=C2=A0


=3D=3D Nits in common with RFC 4741 =3D= =3D

Section 5.1 has odd bulleting around the parag= raph for "Running" (a single bullet point). (This looks like resi= due from an earlier revision where multiple datastores were defined but the= n made optional via capabilities.)

Attribute names are called out inconsistently with= in the document. E.g. "... the select attribute...", "contai= ning a 'type' attribute...", "... a "message-id"= ; attribute...". For improved readability this should be standardized.=

Finally, I did not manually verify all of the fil= ter examples in Section 6. From a cursory inspection, the introduction of t= he namespace wildcarding (Section 6.2.1) should not change the validity of = the samples from RFC 4741. If there is a sample dataset and utility that co= uld be used to quickly validate the filters in all cases it would be a good= idea.

-- Josh

--00032557635a38a7f0049bb50b1d-- Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66993A68FD for ; Fri, 4 Feb 2011 17:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAGYd5ae60Uo for ; Fri, 4 Feb 2011 17:47:37 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 5651E3A687A for ; Fri, 4 Feb 2011 17:47:37 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.232.31]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p151opmJ013303; Fri, 4 Feb 2011 17:50:57 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1296870660; bh=DUsOEBXKx5/xUgbtSfvxhiRj2rY=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=jXmfIL7JWgL7mD9526aLTBpHXb08IWV06KWs0rh4LPGUOcuLUeT49NpAjYEP06X5A rYPoyxXdNXgb9V2YLLsw9Ek0IlD7bdbrTzZohqCCGpN4COHFWvYKPwpno4XfGZiHUL 4uFxhaHvqJhaTf1N6Sa2dkkLSn3fw+Wp2Fk1kM64= Message-Id: <6.2.5.6.2.20110204171820.07a76e78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 04 Feb 2011 17:39:25 -0800 To: apps-review@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Glenn Parsons Subject: [apps-review] Assignments sent on February 1 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 01:47:40 -0000 Hello, Joshua Bell pointed out a mistake in the assignments I sent out on February 1st. Please ignore the suggestion to copy the ietf@ietf.org mailing list as well. The wider discussion within the IETF comment was for an I-D that has already been reviewed. Please note that I will have intermittent connectivity over the next week. If you have any questions about the assignments, please email Alexey or Peter. Yves Lafon has been placed on leave until June. I am also placing myself on leave from Apps Area Team reviews for this month. As a reminder, if you are going on vacation or it is for any other appropriate reason, you can request to be put on leave. I would like to thank Larry Masinter for volunteering to be a member of the Apps Area Review Team. Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20123A6F7C for ; Tue, 1 Feb 2011 15:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1nezIiba8Iw for ; Tue, 1 Feb 2011 15:57:14 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id C77CA3A6C78 for ; Tue, 1 Feb 2011 15:57:14 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.186]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p12005A3025111; Tue, 1 Feb 2011 16:00:10 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1296604812; bh=vhBCdEK+wyq9QM53pHU/2OlofoE=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=hUqWP2ivomRzpP4tWnXWTBvuUFNlMN+PnlXKvo+cXkVit4NWe4FmkLL9i77OEx23v OAiKUHGg2z+ZqH6Yn5chVT0ZvVcltwNpyI+dI7XsG+RFM+/5ig4Hos1C6oUx+lCcnJ 9NRiNvYPw3oWHQPGyXZ0XHrySzlIMyzSXQYkxhZA= Message-Id: <6.2.5.6.2.20110201154817.0d42b800@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Feb 2011 15:59:55 -0800 To: Eliot Lear From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-hokey-ldn-discovery X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:57:15 -0000 Hi Eliot, Peter requested a review of draft-ietf-hokey-ldn-discovery-06. The review has been assigned to you and is due by February 8, 2010. If you need more time, please contact me. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author and the IESG. I suggest copying the ietf@ietf.org mailing list as well as the proposal requires wider discussion within the IETF. The subject of the email when submitting the review should be "apps-team review of draft-ietf-hokey-ldn-discovery-06". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71133A703B for ; Tue, 1 Feb 2011 15:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPXvYxAcS2QG for ; Tue, 1 Feb 2011 15:56:23 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id D99523A700F for ; Tue, 1 Feb 2011 15:56:23 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.186]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p11NxOaE025036; Tue, 1 Feb 2011 15:59:39 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1296604781; bh=+tl4LHCYPj1MCBRVeuQ7dSYr2Wg=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=26XPfuD6xMpJtM4HmRL7J4faexnlLGa0K+Z3RoOc3yoELu8O6DSXxUlCMgMEr8rT6 /dLLp+82DzB/ZCmfcDp+40kB/QGQUxy8CkTFTuMXaeQiuq5+lOdEehexmbOy5EdyV6 VsAvQRCronmT6Pjh5kjCb9Au0RTwv5G9Ja+XK+Fk= Message-Id: <6.2.5.6.2.20110201155424.0d42a9f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Feb 2011 15:58:50 -0800 To: Martin =?iso-8859-1?Q?D=FCrst?= From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-holsten-about-uri-scheme X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:56:24 -0000 Hi Martin, Peter requested a review of draft-holsten-about-uri-scheme-06. The review has been assigned to you and is due by February 8, 2010. If you need more time, please contact me. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-holsten-about-uri-scheme/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author and the IESG. I suggest copying the ietf@ietf.org mailing list as well as the proposal requires wider discussion within the IETF. The subject of the email when submitting the review should be "apps-team review of draft-holsten-about-uri-scheme-06". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021193A7006 for ; Tue, 1 Feb 2011 15:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAPEXN2loDNM for ; Tue, 1 Feb 2011 15:56:20 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 271AF3A7028 for ; Tue, 1 Feb 2011 15:56:20 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.186]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p11NxOa9025036; Tue, 1 Feb 2011 15:59:32 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1296604774; bh=KLBOSxZuI1giGH9BNHbK97dYlc0=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=TsltYo771GyMlfzaOuiHCUl7szuBnpWRUQicpk1m5VboxPng8uTp76Z/D6DPS4IOw N6lfCDNihtWICWnqjOHipGb4ZJo63VyABrY3eQfsJRWAR30QVtMj5zwJ/yYG7P2udZ fRcjX8Dcd45WrGBD2oWu5flZqrpJpyHL8Re2BdWo= Message-Id: <6.2.5.6.2.20110201153953.0d42b0f8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Feb 2011 15:45:09 -0800 To: Glenn Parsons From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-meadors-multiple-attachments-ediint X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:56:21 -0000 Hi Glenn, Peter requested a review of draft-meadors-multiple-attachments-ediint-10. The review has been assigned to you and is due by February 8, 2010. If you need more time, please contact me. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-meadors-multiple-attachments-ediint/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author and the IESG. I suggest copying the ietf@ietf.org mailing list as well as the proposal requires wider discussion within the IETF. The subject of the email when submitting the review should be "apps-team review of draft-meadors-multiple-attachments-ediint-10". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDAEE3A7033 for ; Tue, 1 Feb 2011 15:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTOAQkozLEyU for ; Tue, 1 Feb 2011 15:56:20 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 676D73A7006 for ; Tue, 1 Feb 2011 15:56:19 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.186]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p11NxOaB025036; Tue, 1 Feb 2011 15:59:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1296604777; bh=K5E9wsBZz+A1USmOPdiAXPOkiW8=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=b6Rn3AUtyzLssEfbFPOrkJ4XSwikXS4RK0WNYAlMIxlHasvrhVq/+i22J5BeLxgjm wOWFjFSl5hMw9l/GLQGRawRvPupbOr4j29+Q3FZdegXxwo/zQ3VvtvmUCDk5CTUcOj FJ2JAnKiEZhXgW/iCDu2ezaDTCOLaTAI3drjNkY8= Message-Id: <6.2.5.6.2.20110201154606.0d42b530@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Feb 2011 15:48:09 -0800 To: Joe Hildebrand From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-mraihi-totp-timebased X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:56:21 -0000 Hi Joe, Peter requested a review of draft-mraihi-totp-timebased-07. The review has been assigned to you and is due by February 8, 2010. If you need more time, please contact me. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-mraihi-totp-timebased/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author and the IESG. I suggest copying the ietf@ietf.org mailing list as well as the proposal requires wider discussion within the IETF. The subject of the email when submitting the review should be "apps-team review of draft-mraihi-totp-timebased-07". Best regards, -sm Return-Path: X-Original-To: apps-review@core3.amsl.com Delivered-To: apps-review@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C8A3A6C78 for ; Tue, 1 Feb 2011 15:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaJ8n6KNULb7 for ; Tue, 1 Feb 2011 15:56:13 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 9DED83A6B26 for ; Tue, 1 Feb 2011 15:56:13 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.186]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p11NxOa7025036; Tue, 1 Feb 2011 15:59:29 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1296604771; bh=y+RXgJWDYaVSBMH9Wz5Ve3EaDMM=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=y4+3oAWwzY3fDTc69qPsD18pwN0S3o8TJWnr64qXB4NS1NaUdfAFdH1IevbtiW2P9 p2xC/C5ASLElgtkPWEmt8527y+omXU2CNMpGCmI9JlTgsZwfpkca3zOeH/LPejdpq1 qM2mhLBr2y2iYqQXdlusS0zKNXICeFQubmVfJWcI= Message-Id: <6.2.5.6.2.20110201153522.0d42b260@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Feb 2011 15:39:32 -0800 To: Joshua Bell From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-netconf-4741bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 23:56:17 -0000 Hi Joshua, Peter requested a review of draft-ietf-netconf-4741bis-07. The review has been assigned to you and is due by February 8, 2010. If you need more time, please contact me. You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/doc/draft-ietf-netconf-4741bis/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the author and the IESG. I suggest copying the ietf@ietf.org mailing list as well as the proposal requires wider discussion within the IETF. The subject of the email when submitting the review should be "apps-team review of draft-ietf-netconf-4741bis-07". Best regards, -sm