Re: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Juergen:

Hi!

WFM.  Thanks!

Alvaro.

On January 10, 2018 at 11:07:04 AM, Juergen Schoenwaelder (
[e-mail]) wrote:

> On Tue, Jan 09, 2018 at 07:10:23PM -0800, Alvaro Retana wrote:
>
> Alvaro Retana has entered the following ballot position for
> draft-ietf-netmod-revised-datastores-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) Please add a sentence to the Introduction explaining how this document
> updates rfc7950. I know that a couple of sections explicitly indicate what
> part of rfc7950 they update, but having a short summary at the beginning
> would
> be nice.
>
> (2) Section 3 says: “It is expected that the revised definitions provided
> in
> this section will replace the definitions in [RFC6241] and [RFC7950] when
> these
> documents are revised.” Why not formally Update those documents here? [See
> my
> note above about the Update to rfc7950.]
>
>
> The formal 'update of RFC 7950' is driven by the sections 6.1 and 6.2
> and not so much to the terminology section. While we expect that the
> terminology wording will be harmonized in a future revision of RFC
> 7950, this does not seem to require a formal update of RFC 7950 at
> this point in time (since the definitions are semantically
> equivalent).
>
> So back to the abstract: We could be more explicit by saying:
>
> This document updates the definition of the XPath context and the
> invocation context of operations in RFC 7950.
>
> Personally, I think this makes the abstract harder to read. Perhaps a
> better solution is to leave the abstract as is and to add this one
> sentence paragraph to the Introduction (before the key words
> boilerplate text).
>
> This document updates RFC 7950 by refining the definition of the
> accessible tree for some XPath context (see Section 6.1) and the
> invocation context of operations (see Section 6.2).
>
> (3) s/Section 4.4 of this document/Section 4.4 of rfc6244
>
>
> Yes, this is better.
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: [phone] Campus Ring 1 | 28759 Bremen | Germany
> Fax: [phone] <http://www.jacobs-university.de/>
>