Hi, Adrian:
Please see follow up reply below.
>-----邮件原件-----
>发件人: Adrian Farrel [mailto:[email protected]]
>发送时间: 2022年1月19日 1:13
>收件人: Qin Wu <[email protected]>; [email protected]
>抄送: [email protected]
>主题: 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.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
