On 3/9/16 11:04 AM, Ladislav Lhotka wrote:
Hi Robert,
thanks for the review, I apologize for replying late, please see my responses inline:
Robert Sparks <rjsparks@xxxxxxxxxxx> writes:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-netmod-yang-metadata-04
Reviewer: Robert Sparks
Review Date: 1Mar2016
IETF LC End Date: 9Mar2016
IESG Telechat date: not yet scheduled
Summary: Ready with nits
1) I might be missing something obvious, but the introduction has two
statements that don't seem aligned:
" Values of annotations are not limited to strings; any YANG built-in or
derived type may be used for them"
and
"annotations are scalar values and cannot be further structured".
These two statements are not in conflict: YANG data types (built-in or
derived) apply to scalar values.
I don't know what it means for a data type to apply to a value. Can you
say that more simply?
I think this is just a language thing, and being precise in the text
will get past it.
Are you saying all YANG data types (built-in or derived) have only
scalar values?
If so, you could change the second point in the document to say
"Since annotations have only built-in or derived types, they can only
have scalar values."
But then, placing the point under "This document deliberately adopts
some restrictions" doesn't make sense, and I suggest restructuring the
discussion to only call out the restrictions (which appears to be to not
place annotations on lists or leaf-lists) below that sentence.
If I'm not missing something, that may be more of an open issue than a nit.
2) The shepherd writeup calls out the tension in figuring out whether to
make this an extension or a new built-in statement. Please consider
capturing the reasoning for the path you chose in the draft itself.
I will try, the main reason was that most people felt that introducing a
new built-in statement is too big a change for the upcoming maintenance
version of YANG (1.1) and YANG 2.0 is nowhere in sight.
Thanks, Lada