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

[Qin Wu <[e-mail]>]

Hi, Adrian:
Please see follow up reply below.

>-----邮件原件-----
>发件人: Adrian Farrel [mailto:[e-mail]] 
>发送时间: 2022年1月19日 1:13
>收件人: Qin Wu <[e-mail]>; [e-mail]
>抄送: [e-mail]
>主题: RE: A review of draft-ietf-netmod-node-tags

>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. 
[Qin Wu] Your understanding is correct, if you think I should add some text to make this more clear, I am happy to do so.

---

>>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 Wu] Okay, this will make Designated Expert's life easy a lot,:-), I will add your suggested text, thanks.

> [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 ...."
[Qin Wu] Okay, thanks.
>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."
[Qin Wu] Reasonable, will add it. Thanks.

>>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?
[Qin Wu] I am not sure about this and maybe I should poke Christian (Leading Editor of RFc8819)for this in the separate email.
>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."
[Qin Wu] Make sense to me, thank for proposed text.


>>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
[Qin Wu] Thanks.