Re: [netmod] A review of draft-ietf-netmod-node-tags
Hi, Adrian:
>-邮件原件-
>发件人: Adrian Farrel [mailto:adr...@olddog.co.uk]
>发送时间: 2022年1月19日 22:29
>收件人: Qin Wu ; draft-ietf-netmod-node-t...@ietf.org
>抄送: netmod@ietf.org
>主题: RE: A review of draft-ietf-netmod-node-tags
>Hi again, Qin.
>Just closing on the one remaining point.
>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.
>Maybe just a sentence. I know that my confusion is not indicative of the state
>of the average reader, but maybe there are others who would be just as
>confused.
[Qin Wu] Okay, I will add a sentence in section 3.4. Thank for all these good
suggestions.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] A review of draft-ietf-netmod-node-tags
Hi again, Qin.
Just closing on the one remaining point.
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.
Maybe just a sentence. I know that my confusion is not indicative of the
state of the average reader, but maybe there are others who would be just as
confused.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] A review of draft-ietf-netmod-node-tags
Hi, Chris: Adrian and I talk about user tag management during his review of draft-ietf-netmod-node-tags. One issue raised by Adrian is about whether we will face a situation where one user want to add a user tag while the other user intends to remove such tag. So the question related to RFC8819 is: Has RFC8819 missed to talk about the risks associated with an attacker adding or removing tags so that a requester gets the wrong data? See more details below. -Qin >>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." ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] A review of draft-ietf-netmod-node-tags
Hi, Adrian:
Please see follow up reply below.
>-邮件原件-
>发件人: Adrian Farrel [mailto:adr...@olddog.co.uk]
>发送时间: 2022年1月19日 1:13
>收件人: Qin Wu ; draft-ietf-netmod-node-t...@ietf.org
>抄送: netmod@ietf.org
>主题: 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
Re: [netmod] 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.
---
>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?
[Qi
Re: [netmod] A review of draft-ietf-netmod-node-tags
Thanks Adrian for valuable review, please see rely inline below.
-Qin
-邮件原件-
发件人: Adrian Farrel [mailto:adr...@olddog.co.uk]
发送时间: 2022年1月16日 20:23
收件人: draft-ietf-netmod-node-t...@ietf.org
抄送: netmod@ietf.org
主题: A review of draft-ietf-netmod-node-tags
>Hi,
>Thanks for this document which I found clear and easy to read. I think you
>have defined a small, but particularly valuable feature.
>I have a few comments and a large number of nits (sorry).
>Best,
>Adrian
>== Major ==
>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 day 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.
>3. Section 4.4 could usefully point at Section 9.1 and say that
> "further tags may be assigned by future specifications".
[Qin Wu] :Useful to add reference to Section9.1 and thanks.
---
>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.
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.
Hope this address your comment.
>== Minor ==
>
>The Abstract need to explicitly call out "This document updates RFC 8407 by
>
[Qin Wu] I think it is by " providing guidance to future model writers ", this
require update to RFC8407, I will make this clear in the text.
>The Introduction should repeat that statement and add some detail. In fact we
>don't even find a mention of 8407 until Section 8, and even then there is no
>hint about what the "update" is. Although, in Section 1 you have
[Qin Wu] Will update introduction to add text about RFC8407 update.
Section 8 provides guidelines for authors of YANG data models.
>That would be the ideal place to describe the update.
[Qin Wu] Agree. Thanks.
---
>Figure 1 and its text are a little confusing.
>1. It would help to lift the top Object Tag one line so there is a pipe
> ('|') to separate it from Data Object 1
[Qin Wu] Fixed.
>2. The term "have" is not explained. Given the direction of the arrow,
> I think this means "is contained by".
[Qin Wu] I proposed to change have to contain since a parent data object can
contain multiple child data objects.
>3. The text says "In Figure 1, data objects can contain other data
> objects called subobjects." That's fine, but it would be easier to
> read the figure is data objects 2, 3, and 4 were marked as
> sub-objects.
[Qin Wu] Good point, will update to reflect your comment.
>4. The text has:
> A data object may contain one single object tag, or one single
> property tag, or one single metric tag. In many cases, a data object
> only contains one single metric tag.
> That's a bit odd. I mean, the first sentence says, "A, B, or C", and
> the second sentence says "In many cases C". How does the second
> sentence add anything?
[Qin Wu] Agree, I will remove the second sentence.
>5. The text has:
> the data object tagged
> with the metric tag also can have one or multiple MetricType tags
> and/or one single multi-source tag.
> These additional tags are not shown on the figure.
[Qin Wu] Good catch, will update the figure with
[netmod] A review of draft-ietf-netmod-node-tags
Hi,
Thanks for this document which I found clear and easy to read. I think
you have defined a small, but particularly valuable feature.
I have a few comments and a large number of nits (sorry).
Best,
Adrian
== Major ==
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 day 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:"
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:"?
3. Section 4.4 could usefully point at Section 9.1 and say that
"further tags may be assigned by future specifications".
---
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.
== Minor ==
The Abstract need to explicitly call out "This document updates RFC 8407
by
The Introduction should repeat that statement and add some detail. In fact
we don't even find a mention of 8407 until Section 8, and even then there
is no hint about what the "update" is. Although, in Section 1 you have
Section 8 provides guidelines for authors of YANG data models.
That would be the ideal place to describe the update.
---
Figure 1 and its text are a little confusing.
1. It would help to lift the top Object Tag one line so there is a pipe
('|') to separate it from Data Object 1
2. The term "have" is not explained. Given the direction of the arrow,
I think this means "is contained by".
3. The text says "In Figure 1, data objects can contain other data
objects called subobjects." That's fine, but it would be easier to
read the figure is data objects 2, 3, and 4 were marked as
sub-objects.
4. The text has:
A data object may contain one single object tag, or one single
property tag, or one single metric tag. In many cases, a data object
only contains one single metric tag.
That's a bit odd. I mean, the first sentence says, "A, B, or C", and
the second sentence says "In many cases C". How does the second
sentence add anything?
5. The text has:
the data object tagged
with the metric tag also can have one or multiple MetricType tags
and/or one single multi-source tag.
These additional tags are not shown on the figure.
---
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.
(See also section 5.3)
...Reading the YANG module itself, I wonder whether "add" and "remove"
are ambiguous. Sometimes you may mean adding or removing a tag to/from
a data object. Sometimes you may mean adding or removing to/from a
filter.
---
9.1
OLD
Other standards organizations (SDOs) wishing to allocate their own
set of tags should allocate a prefix from this registry.
NEW
Other standards organizations (SDOs) wishing to allocate their own
set of tags should request the allocation of a prefix from this
registry.
END
---
9.2
Each YANG data object can have one 'opm' tag, zero or one metric-type
tag, zero or one multi-source tag.
Is this an instruction for IANA for the management of the registry? I
don't think it is, and so it should be removed from this section.
---
9.3 and 9.4
These sections include the text "the following registration has been
made:", but it hasn't been (yet). You just need to phrase this text as a
request.
---
Should section 10 talk about the risks associated with an attacker
adding or removing tags so that a requester gets the wrong data?
Should the section also talk about how the presence of tags may reveal
information about
