Subject: [P2PSIP] comments on draft-ietf-p2psip-base-00

From: "Roni Even" <[email-masked]>
Date: Tue, 4 Nov 2008 10:47:13 +0200

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.

2.       In section 5.3.2.5.1 " The ProbeReq message contains a list
(potentially empty) of the pieces of status information that the requester
would like the  responder to provide.". What is the difference between empty
list and PING request.

3.       In section 5.4.2 " Three methods are defined" should be four.

4.       In section 10.5 the draft suggests using probe to populate the
routing table. Why probe and not Ping and if probe which information should
be requested, it also relates to comment 2 about empty probe.

5.       I am a bit unsure how does the destination peer know who what is
the node-id of the source of a request.

Thanks

Roni Even

  _____  

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 4 Nov 2008 09:19:47 -0500

Hi Roni.  Thanks for the comments and questions.

> 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..."

> 3.       In section 5.4.2 " Three methods are defined" should be four.

Good catch.

> would like the  responder to provide.". What is the difference between empty

Previous revisions had only PING.  Numerous people pointed out that
for many uses of PING, the overlay data is not required and PING was
being used both for connectivity checks and for overlay maintenance.
So in Dublin the wg voted to split out the overlay functionality into
a new PROBE method.

> be requested, it also relates to comment 2 about empty probe.

Interesting question.  I think that section was switched wholesale
from ping to probe.  Quite a few of those should probably be PING.
Will make a note to review those.

That chord algorithm is based on push (UPDATE) data rather than pull
(PROBE), so additional data is not required in PROBE.

> the node-id of the source of a request.

Should always learn the source of the request through the message
signature (5.2.4).

Bruce

>
>
> Thanks
>
> Roni Even
>
> ________________________________

---

From: "Roni Even" <[email-masked]>
Date: Tue, 4 Nov 2008 18:36:24 +0200

Bruce,
Thanks see inline
Roni
-----Original Message-----
From: Bruce Lowekamp [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2008 4:20 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [P2PSIP] comments on draft-ietf-p2psip-base-00

RE - qualifying a MUST is a SHOULD according to the IETF terminology

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.
"

Bruce

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 4 Nov 2008 15:25:37 -0500

> 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.

>   + 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