Re: [netmod] A review of draft-ietf-netmod-node-tags

[Adrian Farrel <[e-mail]>]

Thanks Qin,

Good convergence. Edited down to just the remaining points.

Best,
Adrian

>There is some contradiction between and within sections 4.3 and 4.4
>
>1. If a user tag is defined as any tag that has the prefix "user:"
>   how can you then say that users are not required to use the "user:"
>   prefix? That would mean that a user tag is any tag that does or
>   does not have the prefix "user:"
[Qin Wu] Correct.
>2. If any tag not starting with "ietf:", "vendor:", or "user:" is 
>   reserved, how can a user create a tag that doesn't start with
>   "user:"?
[Qin Wu] :I understand your concern, but my understanding on reserved tag,
upon such reserved tag is allocated, it should start with "xxx:",
         Therefore such reserved tag can not be seen as user tag. It seems
unlikely there is contraction if my understanding is correct.
         Correct me if I am wrong.

[AF] Ah, I missed the point!

A user tag is:
- any tag with the prefix "user" 
or
- any tag that has no prefix at all

Thus, and for the avoidance of confusion, the colon (":") when it appears
for the first time, is always assumed to be the separator between a prefix
and the rest of the tag. And so, when a user tag does not have a prefix, it
MUST NOT contain a colon. 

---

>Section 9.1 reasonably uses the "Specification Required" assignment policy.
But, according to 8126, that policy requires the appointment of a designated
expert. According to section 5.3 of 8126...

>   When a designated expert is used, the documentation should give clear
>   guidance to the designated expert, laying out criteria for performing
>   an evaluation and reasons for rejecting a request.

>So you need to add a section to cover this. It can be simple if the rule is
"read the specification, check it is permanent and readily available, and
watch for inappropriate use of language." Or it might be more complex if you
want the DE to check more stuff.
[Qin Wu] Thanks for the reference, I re-read section 5.3 of RFC8126, it also
said:
"
   In the case where
   there are no specific documented criteria, the presumption should be
   that a code point should be granted unless there is a compelling
   reason to the contrary (and see also Section 5.4).
"
My understanding is documented criteria is not mandatory, if you have code
point value (i.e., prefix value in section 9.1)that needs to be allocated
based on IANA request.
I think section 9.1 may fall into this case. 

[AF] I agree with your reading of 8126, but also that it is hard for someone
in 5 years' time to know whether you left out guidance for the DE by mistake
or intended that this "no specific criteria" clause should apply.

[AF] Therefore, if you have no specific criteria, I think it is good to say
so as...

    There is no specific guidance for the Designated Expert and there is a 
    presumption that a code point should be granted unless there is a
    compelling reason to the contrary.

[Qin] For section 9.2, I agree to add one rule, i.e., "IANA assigned tags
must conform to Net-Unicode as defined in [RFC5198], and they shall not need
normalization". I believe this is the guidance given to the designated
expert.

[AF] That's great. Can you make that...
"The Designated Expert is expected to verify that IANA assigned tags conform
to ...."

Hope this address your comment.

>Section 5 has
>   As the main consumer of
>   data object tags are users, users may also remove any tag from a live
>   server, no matter how the tag became associated with a data object
>   within a YANG module.
>
>Suppose there are two users accessing the same YANG data objects on a live
server. This doesn't seem unreasonable in the case of different users or
monitoring tools reading data about the network or devices.
>
>Doesn't this text lead to "warring tag removal" where one user adds a tag,
and another user removes it?
>
>Maybe this is limited to user tags so that each user may have their own
tags. But, in this case, it needs to be clearer what a user tag contains and
how it is used. 
>
>It would still be pretty annoying is Benoit added user:benoit to some data
objects, and I went and removed them.

[Qin Wu] Yes, I believe it is limited to user tags, since IETF tags are
design time tags, so does implementation tags. It is unlikely to face the
situation "warring tag removal".
But for user tag, your are right, user has its own tags and each user may
have different privilege therefore. User with low privilege can not remove
the tag owned by high privilege user.
But I am not sure this is the scope of this document, It seems to me
implementation specific and should not in the scope of this document, agree?
(See also section 5.3)

[AF] Agree about implementation. But maybe, "An implementation MAY include
mechanisms to stop users' removing each other's tags or to apply privilege
levels to different users."

>Should section 10 talk about the risks associated with an attacker adding
or removing tags so that a requester gets the wrong data?

[Qin Wu] User tag is not registered, how user tag is defined and removed is
not scope of this document, in my opinion. Take a look at RFC8819, RFC8819
also doesn't flag this as a issue, do you think we should do this?

[AF] Hmmm. Maybe 8819 missed this?
I agree this refers to the previous point.
Actually: 
1. Just go back and check that it is clear that only user tags can be
added/removed dynamically
2. Add a note to section 10 to say
   "Note that appropriate privilege and security levels need to be applied
to the addition and removal of user tags to ensure that a user receives the
correct data."

>1.
>
>   or some place where offline document are kept
>
>I don't think a "place" advertises. Maybe "an application or server where
offline documents are kept"
[Qin Wu]:I think somewhere can be a website, Maybe or websites where offline
documents are kept, make sense?

[AF] Yes