On Mar 30, 2011, at 9:05 PM, Michael Chen wrote: > 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. >
Fixed > 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. fixed > > 2) Please remove the extra "x" letter in my name in paragraph right above > Section 15. > > Thanks > fixed > 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
