Subject: Re: [apps-review] apps-team review of draft-ietf-netconf-4741bis-07
From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: "Joshua Bell" <[email-masked]>, <[email-masked]>
Cc: Netconf <[email-masked]>
Date: Tue, 8 Feb 2011 11:04:37 +0100
List-Id: Apps Area Review List <apps-review.ietf.org>

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: "SM" <[email-masked]>
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 <?xml
> 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. "<elem/><elem/><elem/>") 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 <get/> or <get-config/>
> 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:
>
>           <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 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 <data> element first appears but only in examples;
> unlike 4.3 which explicitly calls out <rpc-error> and 4.4 which explicitly
> calls out <ok>; <data> is also not identified in the XML Schema in Appendix
> B. This leads to the impression that <data> 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
> 

Date: Tue, 08 Feb 2011 08:19:25 +0100 (CET)
To: [email-masked]
From: Martin Bjorklund <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [apps-review] apps-team review of draft-ietf-netconf-4741bis-07

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 <[email-masked]> 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.:

  <interfaces xmlns="A">...</interfaces>
  <system xmlns="B">...</system>

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:
> 
>            <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 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

Date: Mon, 7 Feb 2011 10:03:06 -0800
From: Joshua Bell <[email-masked]>
To: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: [apps-review] apps-team review of draft-ietf-netconf-4741bis-07

--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
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. "<elem/><elem/><elem/>") 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 <get/> or <get-config/>
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:

           <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 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 <data> element first appears but only in examples;
unlike 4.3 which explicitly calls out <rpc-error> and 4.4 which explicitly
calls out <ok>; <data> is also not identified in the XML Schema in Appendix
B. This leads to the impression that <data> 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

<div>=3D=3D Boilerplate =3D=3D</div><div><br></div><div>I have been selecte=
d as the Applications Area Review Team reviewer for this draft (for backgro=
und on apps-review, please see <a href=3D"http://www.apps.ietf.org/content/=
applications-area-review-team" target=3D"_blank">http://www.apps.ietf.org/c=
ontent/applications-area-review-team</a>).=C2=A0</div>

<div><br></div><div>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.</div><div>
<br>
</div><div>Document: draft-ietf-netconf-4741bis-07</div><div>Title: Network=
 Configuration Protocol (NETCONF)</div><div>Reviewer: Joshua Bell</div><div=
>Review Date: 2011-02-04</div><div>IETF Last Call Date: 2011-02-07</div>

<div><br></div><div>=3D=3D Summary =3D=3D</div><div><br></div><div>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.</div>
<div><br></div><div>The I-D is an update to RFC 4741 and has therefore &quo=
t;stood the test of time&quot;. I was not familiar with the previous RFC an=
d thus reviewed the document as &quot;new to me&quot;, then went back and d=
id a cursory review of my feedback to see what applied to the previous docu=
ment as well.</div>

<div><br></div><div>=3D=3D Major Issues =3D=3D</div><div><br></div><div>non=
e</div><div><br></div>
<div><div>=3D=3D Minor Issues unique to the I-D =3D=3D</div><div><br></div>=
<div>Section 3 XML Considerations includes:</div><div><br></div><div><span =
style=3D"font-family:arial, helvetica, clean, sans-serif;font-size:13px;lin=
e-height:16px"><pre style=3D"font-family:monospace;line-height:1.2em;margin=
-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">
   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.  If a
   peer receives an &#39;rpc&#39; message that is not well-formed XML, it S=
HOULD
   reply with an &#39;operation-failed&#39; error.  If a reply cannot be se=
nt
   for any reason, the server MUST close the session.
</pre><div><br></div></span></div><div>The behavior when an &#39;rpc&#39; 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<span style=3D"font-fami=
ly:monospace;white-space:pre-wrap;font-size:medium">&lt;?xml version=3D&quo=
t;1.0&quot; encoding=3D&quot;EUC-JP&quot; ?&gt; </span>(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 &#39;operation-failed&#39; error, if this is the expected behavior.</=
div>
</div><div><br></div><div>Section 8.9.1 XPath Capability Description includ=
es:</div><div><br></div><div><span style=3D"font-family:arial, helvetica, c=
lean, sans-serif;font-size:13px;line-height:16px"><pre style=3D"font-family=
:monospace;line-height:1.2em;margin-top:0px;margin-right:0px;margin-bottom:=
0px;margin-left:0px">
   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.
</pre><div><br></div></span></div><div><div>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. &quot;&lt;elem/&gt;=
&lt;elem/&gt;&lt;elem/&gt;&quot;) 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 &lt;get/&gt; or &lt;get-config/&gt=
; operation, it should be stated separately from the description of the XPa=
th data model.</div>

<div><br></div><div>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:</div></div><div><br></div><div><pre style=3D"font-fam=
ily:monospace;line-height:1.2em;margin-top:0px;margin-right:0px;margin-bott=
om:0px;margin-left:0px;font-size:13px">
   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.
</pre><div style=3D"font-family:arial, helvetica, clean, sans-serif;font-si=
ze:13px;line-height:16px"><br></div><div style=3D"font-family:arial, helvet=
ica, clean, sans-serif;font-size:13px;line-height:16px">
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<s=
pan style=3D"font-family:arial;font-size:small;line-height:normal">(simplif=
ied relative to the examples in the I-D).=C2=A0</span>given the filter:</di=
v>

<div style=3D"font-family:arial, helvetica, clean, sans-serif;font-size:13p=
x;line-height:16px"><br></div><div><span style=3D"line-height:16px"><font f=
ace=3D"&#39;courier new&#39;, monospace">=C2=A0=C2=A0 select=3D&quot;/users=
/user[name=3D&#39;fred&#39; or name=3D&#39;barney&#39;]</font></span></div>

<div style=3D"font-family:arial, helvetica, clean, sans-serif;font-size:13p=
x;line-height:16px"><br></div></div><div>Would this yield:</div>
<div><br></div><div><span style=3D"font-family:arial, helvetica, clean, san=
s-serif;font-size:13px;line-height:16px"><pre style=3D"font-family:monospac=
e;line-height:1.2em;margin-top:0px;margin-right:0px;margin-bottom:0px;margi=
n-left:0px">
           &lt;users&gt;
<span style=3D"font-family:arial, helvetica, clean, sans-serif;line-height:=
16px;white-space:normal"><pre style=3D"font-family:monospace;line-height:1.=
2em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px">    =
         &lt;user&gt;
               &lt;name&gt;fred&lt;/name&gt;
             &lt;/user&gt;
</pre></span><span style=3D"font-family:arial, helvetica, clean, sans-serif=
;line-height:16px;white-space:normal"><pre style=3D"font-family:monospace;l=
ine-height:1.2em;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-l=
eft:0px">
             &lt;user&gt;
               &lt;name&gt;barney&lt;/name&gt;
             &lt;/user&gt;
</pre></span>            &lt;/users&gt;
</pre><div><br></div><div>or:</div><div><br></div><div><pre style=3D"font-f=
amily:monospace;line-height:1.2em;margin-top:0px;margin-right:0px;margin-bo=
ttom:0px;margin-left:0px"><span style=3D"font-family:arial, helvetica, clea=
n, sans-serif;line-height:16px;white-space:normal"><div>

<pre style=3D"font-family:monospace;line-height:1.2em;margin-top:0px;margin=
-right:0px;margin-bottom:0px;margin-left:0px">           &lt;users&gt;
             &lt;user&gt;
               &lt;name&gt;fred&lt;/name&gt;
             &lt;/user&gt;
           &lt;/users&gt;
</pre></div><div><div><pre style=3D"font-family:monospace;line-height:1.2em=
;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><br></p=
re><pre style=3D"font-family:monospace;line-height:1.2em;margin-top:0px;mar=
gin-right:0px;margin-bottom:0px;margin-left:0px">
           &lt;users&gt;
             &lt;user&gt;
               &lt;name&gt;barney&lt;/name&gt;
             &lt;/user&gt;
           &lt;/users&gt;
</pre></div></div><div><br></div></span></pre></div></span></div><div>The f=
ormer is strongly implied by the non-XPath-based filter logic defined in se=
ction 6 (i.e. the text &quot;<span style=3D"font-family:monospace;font-size=
:13px;line-height:15px;white-space:pre-wrap">Specific </span><span style=3D=
"font-family:monospace;font-size:13px;line-height:15px;white-space:pre-wrap=
">data instances are not duplicated in the response in the event that </spa=
n><span style=3D"font-family:monospace;font-size:13px;line-height:15px;whit=
e-space:pre-wrap">the request contains multiple filter subtree expressions =
that select </span><span style=3D"font-family:monospace;font-size:13px;line=
-height:15px;white-space:pre-wrap">the same data.&quot;)</span>, but the la=
tter is hinted at by the note about the &quot;XSLT extension for root node =
children&quot; called out above. In either case, more clarity in the normat=
ive text would be worthwhile, as well as an example.</div>

<div><br></div><div><br></div><div>=3D=3D Minor Issues in common with RFC 4=
741 =3D=3D</div><div><br></div><div>Section 4.1 and 4.2 define the usage of=
 the &quot;message-id&quot; 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: <a href=3D"http://www.=
w3.org/TR/2008/REC-xml-20081126/#AVNormalize" target=3D"_blank">http://www.=
w3.org/TR/2008/REC-xml-20081126/#AVNormalize</a> - 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.</div>

<div><br></div><div>Section 4.2 is where the &lt;data&gt; element first app=
ears but only in examples; unlike 4.3 which explicitly calls out &lt;rpc-er=
ror&gt; and 4.4 which explicitly calls out &lt;ok&gt;; &lt;data&gt; is also=
 not identified in the XML Schema in Appendix B. This leads to the impressi=
on that &lt;data&gt; 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</div>

<div><br></div><div><br></div><div>=3D=3D Nits in common with RFC 4741 =3D=
=3D</div><div><br></div><div>Section 5.1 has odd bulleting around the parag=
raph for &quot;Running&quot; (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.)</div>

<div><br></div><div><div>Attribute names are called out inconsistently with=
in the document. E.g. &quot;... the select attribute...&quot;, &quot;contai=
ning a &#39;type&#39; attribute...&quot;, &quot;... a &quot;message-id&quot=
; attribute...&quot;. For improved readability this should be standardized.=
</div>

</div><div><br></div><div>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.</div>

<div><br></div><div>-- Josh</div><div><br></div>

--00032557635a38a7f0049bb50b1d--

Date: Fri, 04 Feb 2011 17:39:25 -0800
To: [email-masked]
From: SM <[email-masked]>
Cc: Glenn Parsons <[email-masked]>
Subject: [apps-review] Assignments sent on February 1

Hello,

Joshua Bell pointed out a mistake in the assignments I sent out on 
February 1st.  Please ignore the suggestion to copy the [email-masked] 
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

Date: Tue, 01 Feb 2011 15:59:55 -0800
To: Eliot Lear <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-hokey-ldn-discovery

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 [email-masked] 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

Date: Tue, 01 Feb 2011 15:58:50 -0800
To: Martin =?iso-8859-1?Q?D=FCrst?= <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-holsten-about-uri-scheme

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 [email-masked] 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

Date: Tue, 01 Feb 2011 15:45:09 -0800
To: Glenn Parsons <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-meadors-multiple-attachments-ediint

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 [email-masked] 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

Date: Tue, 01 Feb 2011 15:48:09 -0800
To: Joe Hildebrand <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-mraihi-totp-timebased

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 [email-masked] 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

Date: Tue, 01 Feb 2011 15:39:32 -0800
To: Joshua Bell <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-ietf-netconf-4741bis

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 [email-masked] 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