Hi,
While looking at the diff between base-12 and 13, I spotted couple simple
problems:
1) Section 5.5.1.2, the following sentence should get its own "o" bullet. There
should be altogether 4 bullets:
o If the peer is overloaded or detects some other kind of error, it
MAY generate an error instead of an AttachReqAns.
Also, in my proposed language for this section, I have one sentence right before
the "*" bullets that is not included in base-13:
+ The tie-breaker heuristic is to compare the Node-IDs of both
+ peers as unsigned integers, and
No where in this draft talks about one Node-ID "smaller" or "larger" than
another Node-ID. I thought this language or something similar can help
implementors understand the heuristic better. Wrong implementation of this
comparison defeats the heuristic completely.
2) Please remove the extra "x" letter in my name in paragraph right above
Section 15.
Thanks
Michael Chen
On 3/14/2011 4:43 PM, Cullen Jennings wrote:
There are a few things that did not get fixed in the -13 draft. Some due to
just not sure how to fix them yet and some due to lack of time. The remanning
open items are
We need to update a few things to clarify usage when certificates have multiple
node-id. Proposal is to say that, in cases other than when signaling a
bootstrap peer, the first message is an Attach. The node-id used in the
SignerIdentity of the Attach would indicate the node-id that this connection
represented. The SignerIdentity still has to be one of the node-is in the
certificate or the message is rejected. The same approach works for the non
certificate based security modes. I realize this paragraph is clear as mud - we
will work on better text. I may have misunderstood some of the email on this
but I think this is the proposal from Marc, Bruce, and EKR.
In section 6.3.4, it is not specified how to encode i into the hash. I'm
proposing treating it as a uint32 and hashing that.
A.39. Section 6.2.2
I am not really sure to understand how the "exists=False" are synthesized when
doing a Fetch on an array. For example if a Store was made for an object with
an index of 0xfffffffe, and the Fetch requests the whole array, will the answer
contains 4294967294 "exists=False" objects?
Proposal: Yes
Also how are this synthesized elements signed?
Proposal:
The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary blog
and be encoded per normal.
A.40. Section 6.4.3.2
If exist is False, should the hash_value be the hash value of an empty byte
array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be omitted?
Proposal:
empty byte array ... keep the code path all the same with no special rules for exists ==
False. Keep in mind that you need to "sign" a delete of an entry and have that
interact properly when a partitioned overlay merges"
A.43. Section 10.1 Element signature
What certificate should be used to compute (and verify) the signature for the
whole configuration file?
Proposal:
Add a<config-signer> to the configuration that is much like the<kind-signer>
but says who can sing the configuration file. IN the case of the first time you get a
configuration file, that could come at same time as enrollment and be secured that way.
A.47. Section 6.3
The four policies defined in p2psip-base consistently says that "[a] given value
MUST be written (or overwritten) if and only if the request is signed ..."
Additional access control policies defined elsewhere use similar wording.
But should not the StoredData signature be used instead of the request
signature? When replicating the data, the signer of the StoreRequest will be
different from the signer of the original request and so the test will no longer
work. Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element is
signed by a credential which is authorized to write this kind at this
Resource-ID.", which seems to confirm that this is the element's signature that
must be checked, not the request's.
So the elements sig need to be checked for sure. The questions is should the
request sig also be checked before that. Unless we can say how to check it,
seems like bad idea. Proposal: remove this or clarify.
A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and rel-port
productions. Only present for type "relay".'
In ICE, the rel address and port are also present for srflx and prflx
candidates.
my brain hurts. Proposal: go for beer
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
