On Tue, Nov 4, 2008 at 12:36 PM, Roni Even <[EMAIL PROTECTED]> wrote: > Bruce, > Thanks see inline > Roni > -----Original Message----- > From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 04, 2008 4:20 PM > To: Roni Even > Cc: [EMAIL PROTECTED] > Subject: Re: [P2PSIP] comments on draft-ietf-p2psip-base-00 > > Hi Roni. Thanks for the comments and questions. > > On Tue, Nov 4, 2008 at 3:47 AM, Roni Even <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I read the updated draft and have some initial feedback >> >> >> >> 1. In section 5.1.3 it says " it MUST construct the destination list >> by reversing the order of the entries on the via list." I suggest to relax >> the MUST to SHOULD enabling other routing algorithms. >> > > Good comment. I would probably rather leave the MUST but qualify it > with something like "If using the default symmetric recursive > routing..." > > RE - qualifying a MUST is a SHOULD according to the IETF terminology >
SHOULD means "may exist valid reasons in particular circumstances to ignore a particular item". Not doing symmetric routing isn't a particular circumstance, it's following an entirely different spec. If you're doing symmetric recursion, the via list MUST be reversed to generate the destination list. The current structure of the document simply doesn't allow for other routing modes. As indicated in the sentence at the end of that paragraph, there is an issue that if different routing algorithms need to be supported, some of that text needs to be relaxed or restructured. I think about half of 5.1 would be general and the other half would need to be moved into a section covering only symmetric recursive routing. But this particular aspect of the symmetric recursive algorithm is a MUST. > >> 5. I am a bit unsure how does the destination peer know who what is >> the node-id of the source of a request. >> > > Should always learn the source of the request through the message > signature (5.2.4). > > RE - The identity type is not always the node-id according to 5.2.4 it can be > the certificate > " > identity > The identity or certificate used to form the signature > > signature_value > > The value of the signature > > A number of possible identity formats are permitted. The current > possibilities are: a Node-ID, a user name, and a certificate. > > For signatures over messages the input to the signature is computed > over: > > overlay + transaction_id + MessageContents + SignerIdentity > > Where overlay and transaction_id come from the forwarding header and > + indicates concatenation. > " Maybe it would be better to discuss what you're trying to accomplish. The general principle is that the message is signed by the appropriate identity that you would need to validate the message. In the case of overlay maintenance, this would be either the node-id or the certificate granting the node-id (there should be an open issue in the draft about defining when to do each). In other cases, you're right, the message can be signed by a user name. There's no reason in the protocol that you would need something else there. Bruce > > > Bruce > > > >> >> >> Thanks >> >> Roni Even >> >> ________________________________ >> _______________________________________________ >> P2PSIP mailing list >> [EMAIL PROTECTED] >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > > _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
