[P2PSIP] Ben Campbell's No Objection on

[Thomas C. Schmidt]

Hi Ben,

thanks for your comments. Please see inline.

Ben Campbell has entered the following ballot position for
draft-ietf-p2psip-share-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/
----------------------------------------------------------------------
----------------------------------------------------------------------
I have a one set of substantive comments/questions, and some editorial
- I'm confused about the validation procedure. In step one, is this the
user name of the user attempting to write the resource? In step 5, I do
not understand how this terminates. Which ACL item is the "previously
selected" one. If that refers to the one selected in the last iteration
of steps 3 and 4, how do you know there are not more ACL items to iterate
through?

You are referring to 6.3 "validating writ access"?

In this case, you receive a store request along with a certificate. In
step 1, you resolve the user name of the requester, i.e., the user name
that corresponds to the certificate in the request.

... then you identify the user in the ACL and walk up the delegation
chain.

In step 5, you have arrived at the root of the delegation tree. This is
the case, when the to_user equals the signer equals the owner of the
resources (see see Figure 1). This is also how it terminates - the owner
of the resource is the root of the trust chain.

-1, first paragraph, first sentence: s/that/, which
-- recurring singular plural mismatch "resources with a variable name".

Thanks, fixed.

-1, 2nd paragraphs: "It transfers the authorization..."
What is the antecedent for "it"?

We meant the "trust delegation mechanism" - but it's ambiguous, you're
right. Changed to "...based on a trust delegation mechanism that
transfers the authorization .."

missing article.

Thanks, fixed.

-3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user
actually required to access the array in the first place?

It says "If the data model of the Shared Resource is an array, each
Authorized..".

So the user is not required to use an array for sharing, but if an array
is used, write conflicts MUST not be produced.

- 6.5, first paragraph: Does the MAY grant permission, or is it a
statement of fact?

Good point. The actual statement means that users are enabled to do so.
So we replace the may by a "can".

-6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not other
(perhaps application specific) reasons one might choose not to write the
value?

I believe the MUST is correct: we're in a section that describes the
behavior of the storing peer. When receiving a store request, this peer
should not behave according to its own application semantic, but to the
common overlay rule.

-- 2nd paragraph from end: The MUST seems more like a statement of fact.
(E.g. "The resulting ... integer is used...")

Mhmm, I don't think so. These are all iterative decision steps: try
(a), then write ... otherwise try (b), then write ... +++ ... otherwise
refuse.

- 4.1, last paragraph: s/implementations/implementors

Thanks, fixed.

- 4.2, definition of res_name_ext: The sentence starting with "This name
serves..." is hard to parse.

O.K., changed to "This name is used by the storing peer for validating..."

-5.1, 4th paragraph (paragraph after example) : s/witch/which

Yep, this document was full of witches, but they have been banned now.

Cheers,
Thomas

[Ben Campbell]

Hi, thanks for the response. Also see inline. I removed text that
doesn't seem to need further discussion.

Ben.

Post by Thomas C. Schmidt
Hi Ben,
thanks for your comments. Please see inline.

[...]

Post by Thomas C. Schmidt

----------------------------------------------------------------------
----------------------------------------------------------------------
I have a one set of substantive comments/questions, and some
editorial
- I'm confused about the validation procedure. In step one, is this the
user name of the user attempting to write the resource? In step 5, I do
not understand how this terminates. Which ACL item is the "previously
selected" one. If that refers to the one selected in the last
iteration
of steps 3 and 4, how do you know there are not more ACL items to iterate
through?

You are referring to 6.3 "validating writ access"?
In this case, you receive a store request along with a certificate. In
step 1, you resolve the user name of the requester, i.e., the user
name that corresponds to the certificate in the request.

Adding something to the effect of "This is the user requesting the write
operation" would be helpful.

Post by Thomas C. Schmidt
... then you identify the user in the ACL and walk up the delegation
chain.
In step 5, you have arrived at the root of the delegation tree. This
is the case, when the to_user equals the signer equals the owner of
the resources (see see Figure 1). This is also how it terminates - the
owner of the resource is the root of the trust chain.

I'm probably being dense here, but my confusion is in the phrasing of
"the "to_user" value user name of the signer of the previously selected
ACL item". Won't that always be true for every ACL item up the chain
after the first?

As an example, Lets say I have a delegation chain of A,B,C,D, where A is
the owner. Would the ACL chain look like the following (in leave-to-root
order )?

signer to_user
1 C D
2 B C
3 A B
4 A A

If so, then ACL 2 seems to have a to_user that matches the signer of ACL
1 (the previously selected ACL), which seems to terminate early.

Again, I'm sure I'm missing something.


[...]

Post by Thomas C. Schmidt

-3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user
actually required to access the array in the first place?

It says "If the data model of the Shared Resource is an array, each
Authorized..".
So the user is not required to use an array for sharing, but if an
array is used, write conflicts MUST not be produced.

This is pedantic, but my issue is that the SHALL does not leave the
authorized peer the opportunity to choose not to write anything at all.
Being granted permission to write does not imply a decision to write.
Perhaps something like "...each Authorized Peer that chooses to write
data SHALL..."

Post by Thomas C. Schmidt

-6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not other
(perhaps application specific) reasons one might choose not to write the
value?

I believe the MUST is correct: we're in a section that describes the
behavior of the storing peer. When receiving a store request, this
peer should not behave according to its own application semantic, but
to the common overlay rule.

(pedantic again): So the storing peer couldn't have an application
policy that, for example, chooses not to honor a write that violates
some data validation rule? It seems to me that this section is saying
that you MUST deny the request unless one of the listed is true, which
is not the same as saying you MUST accept if one of the conditions is
true.

Post by Thomas C. Schmidt

-- 2nd paragraph from end: The MUST seems more like a statement of fact.
(E.g. "The resulting ... integer is used...")

Mhmm, I don't think so. These are all iterative decision steps: try
(a), then write ... otherwise try (b), then write ... +++ ...
otherwise refuse.

That was a cut and paste error on my part--I meant the 2nd to last
paragraph of 3.1.

[...]

[Thomas C. Schmidt]

Hi Ben,

please see inline.

Post by Ben Campbell

Post by Thomas C. Schmidt

----------------------------------------------------------------------
----------------------------------------------------------------------
I have a one set of substantive comments/questions, and some
editorial
- I'm confused about the validation procedure. In step one, is this the
user name of the user attempting to write the resource? In step 5, I do
not understand how this terminates. Which ACL item is the "previously
selected" one. If that refers to the one selected in the last iteration
of steps 3 and 4, how do you know there are not more ACL items to iterate
through?

You are referring to 6.3 "validating writ access"?
In this case, you receive a store request along with a certificate. In
step 1, you resolve the user name of the requester, i.e., the user
name that corresponds to the certificate in the request.

Adding something to the effect of "This is the user requesting the write
operation" would be helpful.

O.K., done.

Post by Ben Campbell

Post by Thomas C. Schmidt
... then you identify the user in the ACL and walk up the delegation
chain.
In step 5, you have arrived at the root of the delegation tree. This
is the case, when the to_user equals the signer equals the owner of
the resources (see see Figure 1). This is also how it terminates - the
owner of the resource is the root of the trust chain.

I'm probably being dense here, but my confusion is in the phrasing of
"the "to_user" value user name of the signer of the previously selected
ACL item". Won't that always be true for every ACL item up the chain
after the first?

No, the selected ACL item from the previous step is the row you are in.
It basically says that the "to_user" value equals the username of the
signer. This is the "A A" case in row 4 in your example below. This row
should be in an ACL only once and the user must be the owner of the
resource, which is requested to be verified separately.

Post by Ben Campbell
As an example, Lets say I have a delegation chain of A,B,C,D, where A is
the owner. Would the ACL chain look like the following (in leave-to-root
order )?
signer to_user
1 C D
2 B C
3 A B
4 A A
If so, then ACL 2 seems to have a to_user that matches the signer of ACL
1 (the previously selected ACL), which seems to terminate early.
Again, I'm sure I'm missing something.

I believe the confusion comes from the "previously" - this is meant to
refer to the "previous step" and the actual row. We changed "previously"
to "previous step" to avoid this confusion.

Post by Ben Campbell
[...]

Post by Thomas C. Schmidt

-3.1, 3rd paragraph: Is the SHALL appropriate? Is an authorized user
actually required to access the array in the first place?

It says "If the data model of the Shared Resource is an array, each
Authorized..".
So the user is not required to use an array for sharing, but if an
array is used, write conflicts MUST not be produced.

This is pedantic, but my issue is that the SHALL does not leave the
authorized peer the opportunity to choose not to write anything at all.
Being granted permission to write does not imply a decision to write.
Perhaps something like "...each Authorized Peer that chooses to write
data SHALL..."

O.K., done.

Post by Ben Campbell

Post by Thomas C. Schmidt

-6.6, paragraphs 3 and 4: Are the MUSTs appropriate? Are there not other
(perhaps application specific) reasons one might choose not to write the
value?

I believe the MUST is correct: we're in a section that describes the
behavior of the storing peer. When receiving a store request, this
peer should not behave according to its own application semantic, but
to the common overlay rule.

(pedantic again): So the storing peer couldn't have an application
policy that, for example, chooses not to honor a write that violates
some data validation rule? It seems to me that this section is saying
that you MUST deny the request unless one of the listed is true, which
is not the same as saying you MUST accept if one of the conditions is
true.

O.K., thanks: I got your point. Correspondingly, we reversed the order
to a logical chain of denials.

Post by Ben Campbell

Post by Thomas C. Schmidt

-- 2nd paragraph from end: The MUST seems more like a statement of fact.
(E.g. "The resulting ... integer is used...")

Mhmm, I don't think so. These are all iterative decision steps: try
(a), then write ... otherwise try (b), then write ... +++ ...
otherwise refuse.

That was a cut and paste error on my part--I meant the 2nd to last
paragraph of 3.1.

... still there it says: Do 1.-3. to obtain an integer, and then use
exactly this (and no other). This sounds to me like a normative MUST??


Currently we cannot update due to the cutoff. We'll do so in Seoul.

Thanks again
Thomas

[Ben Campbell]

Post by Thomas C. Schmidt
Hi Ben,
please see inline.

Post by Ben Campbell

Post by Thomas C. Schmidt

----------------------------------------------------------------------
----------------------------------------------------------------------
I have a one set of substantive comments/questions, and some editorial
- I'm confused about the validation procedure. In step one, is this the
user name of the user attempting to write the resource? In step 5,
I
do
not understand how this terminates. Which ACL item is the
"previously
selected" one. If that refers to the one selected in the last iteration
of steps 3 and 4, how do you know there are not more ACL items to iterate
through?

You are referring to 6.3 "validating writ access"?
In this case, you receive a store request along with a certificate. In
step 1, you resolve the user name of the requester, i.e., the user
name that corresponds to the certificate in the request.

Adding something to the effect of "This is the user requesting the write
operation" would be helpful.

O.K., done.

Post by Ben Campbell

Post by Thomas C. Schmidt
... then you identify the user in the ACL and walk up the
delegation
chain.
In step 5, you have arrived at the root of the delegation tree. This
is the case, when the to_user equals the signer equals the owner of
the resources (see see Figure 1). This is also how it terminates - the
owner of the resource is the root of the trust chain.

I'm probably being dense here, but my confusion is in the phrasing of
"the "to_user" value user name of the signer of the previously selected
ACL item". Won't that always be true for every ACL item up the chain
after the first?

No, the selected ACL item from the previous step is the row you are
in. It basically says that the "to_user" value equals the username of
the signer. This is the "A A" case in row 4 in your example below.
This row should be in an ACL only once and the user must be the owner
of the resource, which is requested to be verified separately.

Post by Ben Campbell
As an example, Lets say I have a delegation chain of A,B,C,D, where A is
the owner. Would the ACL chain look like the following (in
leave-to-root
order )?
signer to_user
1 C D
2 B C
3 A B
4 A A
If so, then ACL 2 seems to have a to_user that matches the signer of ACL
1 (the previously selected ACL), which seems to terminate early.
Again, I'm sure I'm missing something.

I believe the confusion comes from the "previously" - this is meant to
refer to the "previous step" and the actual row. We changed
"previously" to "previous step" to avoid this confusion.

I still think I'm confused. Step 5 basically says iterate over steps 3
and 4. If I'm currently looking at the ACL from the Nth iteration of 3
and 4, it seems to me that the "ACL from the previous step" is ACL N-1.

If the terminal condition is when you find an ACL where the signer and
the to_user are the same, then I you could say _that_ without getting
into "previous steps."

[...]

Post by Thomas C. Schmidt

Post by Ben Campbell

Post by Thomas C. Schmidt

-- 2nd paragraph from end: The MUST seems more like a statement of fact.
(E.g. "The resulting ... integer is used...")

Mhmm, I don't think so. These are all iterative decision steps: try
(a), then write ... otherwise try (b), then write ... +++ ...
otherwise refuse.

That was a cut and paste error on my part--I meant the 2nd to last
paragraph of 3.1.

... still there it says: Do 1.-3. to obtain an integer, and then use
exactly this (and no other). This sounds to me like a normative MUST??

Okay. ( That is, I still don't think it's necessary, but it also does
no harm, so I'll withdraw that concern.)


Thanks!

Ben.

[Thomas C. Schmidt]

HI Ben,

Post by Ben Campbell

Post by Thomas C. Schmidt

Post by Ben Campbell

Post by Thomas C. Schmidt

----------------------------------------------------------------------
----------------------------------------------------------------------

... then you identify the user in the ACL and walk up the
delegation
chain.
In step 5, you have arrived at the root of the delegation tree. This
is the case, when the to_user equals the signer equals the owner of
the resources (see see Figure 1). This is also how it terminates - the
owner of the resource is the root of the trust chain.

I'm probably being dense here, but my confusion is in the phrasing of
"the "to_user" value user name of the signer of the previously selected
ACL item". Won't that always be true for every ACL item up the chain
after the first?

No, the selected ACL item from the previous step is the row you are
in. It basically says that the "to_user" value equals the username of
the signer. This is the "A A" case in row 4 in your example below.
This row should be in an ACL only once and the user must be the owner
of the resource, which is requested to be verified separately.

Post by Ben Campbell
As an example, Lets say I have a delegation chain of A,B,C,D, where A is
the owner. Would the ACL chain look like the following (in
leave-to-root
order )?
signer to_user
1 C D
2 B C
3 A B
4 A A
If so, then ACL 2 seems to have a to_user that matches the signer of ACL
1 (the previously selected ACL), which seems to terminate early.
Again, I'm sure I'm missing something.

I believe the confusion comes from the "previously" - this is meant to
refer to the "previous step" and the actual row. We changed
"previously" to "previous step" to avoid this confusion.

I still think I'm confused. Step 5 basically says iterate over steps 3
and 4. If I'm currently looking at the ACL from the Nth iteration of 3
and 4, it seems to me that the "ACL from the previous step" is ACL N-1.

The delegation is a tree - so it's not a linear chain.

Post by Ben Campbell
If the terminal condition is when you find an ACL where the signer and
the to_user are the same, then I you could say _that_ without getting
into "previous steps."

Guess you are right. Why don't we simplify the sentence to

"Repeat steps 3 and 4 until the "to_user" value is equal to the user
name of the signer of the ACL in the selected item." ?

Thanks,
thomas

[Ben Campbell]

Post by Thomas C. Schmidt
HI Ben,

Post by Ben Campbell

Post by Thomas C. Schmidt

Post by Ben Campbell

Post by Thomas C. Schmidt

----------------------------------------------------------------------
----------------------------------------------------------------------

... then you identify the user in the ACL and walk up the
delegation
chain.
In step 5, you have arrived at the root of the delegation tree. This
is the case, when the to_user equals the signer equals the owner of
the resources (see see Figure 1). This is also how it terminates - the
owner of the resource is the root of the trust chain.

I'm probably being dense here, but my confusion is in the phrasing of
"the "to_user" value user name of the signer of the previously selected
ACL item". Won't that always be true for every ACL item up the chain
after the first?

No, the selected ACL item from the previous step is the row you are
in. It basically says that the "to_user" value equals the username of
the signer. This is the "A A" case in row 4 in your example below.
This row should be in an ACL only once and the user must be the owner
of the resource, which is requested to be verified separately.

Post by Ben Campbell
As an example, Lets say I have a delegation chain of A,B,C,D, where
A
is
the owner. Would the ACL chain look like the following (in
leave-to-root
order )?
signer to_user
1 C D
2 B C
3 A B
4 A A
If so, then ACL 2 seems to have a to_user that matches the signer
of
ACL
1 (the previously selected ACL), which seems to terminate early.
Again, I'm sure I'm missing something.

I believe the confusion comes from the "previously" - this is meant to
refer to the "previous step" and the actual row. We changed
"previously" to "previous step" to avoid this confusion.

I still think I'm confused. Step 5 basically says iterate over steps 3
and 4. If I'm currently looking at the ACL from the Nth iteration of 3
and 4, it seems to me that the "ACL from the previous step" is ACL N-1.

The delegation is a tree - so it's not a linear chain.

Post by Ben Campbell
If the terminal condition is when you find an ACL where the signer and
the to_user are the same, then I you could say _that_ without getting
into "previous steps."

Guess you are right. Why don't we simplify the sentence to
"Repeat steps 3 and 4 until the "to_user" value is equal to the user
name of the signer of the ACL in the selected item." ?

Assuming that gives the right results (I'll leave that to you to
decide), I think it would be easier to understand.

Thanks!

Ben.

Post by Thomas C. Schmidt
Thanks,
thomas
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
[phone] °
[phone] °