Implementation of -base::chapter 7 Data Storage Protocol

Hi,

We have recently implemented chapter 7 and we have another list of 
questions.

The questions are sorted by the protocol message, being sent.

For the convenience, we also included the questions about chapter 7, 
that we have sent in our LastCall comments. These issues are marked with 
a star: '[issue ###]*'.

1. Store
======================================================================

Before describing the issues, we will cite the checklist from section 
7.4.1.1. It is the same list in exactly the same order, except that it 
is numbered. The 2 additional items - * and ** appear in section 
7.4.1.1. after describing StoreReq structure (it is last paragraph on 
page 101).

[*]  If the replica number is zero, then the peer MUST check that it is 
responsible for the resource and, if not, reject the request.
[**] If the replica number is nonzero, then the peer MUST check that it 
expects to be a replica for the resource and that the request sender is 
consistent with being the responsible node (i.e., that the receiving 
peer does not know of a better node) and, if not, reject the request.

1.  The Kind-ID is known and supported.
2.  The signatures over each individual data element (if any) are valid. 
If this check fails, the request MUST be rejected with an 

WGLC for draft-ietf-p2psip-sip-09

Hi,

Hereby we are issuing a WGLC for draft-ietf-p2psip-sip-09. 

The WGLC will be open till the 20th of May. We kindly ask the WG to
review the document and provide comments.

If you have no comments and think the document is ready to be submitted 
to IESG, please do send a note stating that to the WG ML.

Additional information about the document is below:

        Title           : A SIP Usage for RELOAD
        Author(s)       : Cullen Jennings
                          Bruce B. Lowekamp
                          Eric Rescorla
                          Salman A. Baset
                          Henning Schulzrinne
                          Thomas C. Schmidt
        Filename        : draft-ietf-p2psip-sip-09.txt
        Pages           : 19
        Date            : 2013-02-25

Abstract:
   This document defines a SIP Usage for REsource LOcation And Discovery
   (RELOAD).  The SIP Usage provides the functionality of a SIP proxy or
   registrar in a fully-distributed system and includes a lookup service
   for Address of Records (AORs) stored in the overlay.  It also defines
   Globally Routable User Agent Uris (GRUUs) that allow the
   registrations to map an AOR to a specific node reachable through the

Review of revised DRR and RPR documents

Hi,

I've just gone through the revised documents authors provided after my
first round of comments. I'm happy to see that most of the comments have
been now introduced. I have now only a few minor editorial ones, that
can be dealt with in parallel with the next steps. My reviews are
attached to this e-mail (I added comments to the PDF version of each
draft). Authors, please check the attachments!! :D

Thanks for the nice job.

Thanks,

Carlos

_______________________________________________
P2PSIP mailing list
P2PSIP@...
https://www.ietf.org/mailman/listinfo/p2psip

RELOAD Interoperability Testing Event in Berlin

This is the last call for participation for a RELOAD Interoperability Testing
event in Berlin, Germany on July 27 and 28.

On the Saturday, the event will be held at the Freie Universitaet Berlin.  On
the Sunday the event will be held at the venue of IETF 87.  Many thanks to the
Freie Universitaet Berlin and the IETF for providing the resources for this.

If you have a RELOAD implementation, complete or partial, and want to
participate, please send an email to reloadit-registration@...,
with the following information:

Implementation name
Contact email
Number of persons attending.

Note that the event will be canceled if there is not at least 4 different
implementations registered by end of May, so please register as soon as
possible.  You do not need a complete implementation to participate and be
assured that the name of the participants will be kept confidential.

Remember that all participants can have one or more RELOAD configuration &
enrollment services provisioned for free to simplify the participation in
local or remote interoperability testing.  Please send me an email directly to
provision this service.

Thanks.

--

-- 
Marc Petit-Huguenin

Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 

Certificates with multiple NodeIds

Hi,

I have several questions regarding certificates with multiple NodeIDs.
It seems that different parts in the draft contradict each other.

First, section 6.6.1 defines requirements for future overlay link
protocols. I suppose, that current overlay link  protocol must meet
these requirements.
>Endpoint authentication When a node forms an association with another
>endpoint, it MUST be possible to cryptographically verify that the
>endpoint has a given Node-ID.

Certificates with multiple NodeIDs sometimes violate this requirement.
Unless a connection was formed as a result of exchanging Attach
messages, it is impossible to associate an endpoint and its NodeID,
which is the case when new node connects to BootstrapPeer.
As a consequence several reload requirements are hard or even impossible
to implement IMHO.

The first requirement is that ConnectionTable SHOULD use some indexes
instead of mapping NodeIds to (D)TLS Connections.

The second requirement is in section 6.1.2
>If a node with a certificate with multiple Node-IDs attempts to route
>a message other than a Ping or Attach through a node without performing
>an Attach, the receiving node MUST reject the request with an
>Error_Forbidden error. The node MUST implement support for returning
>responses to a Ping or Attach request made by a joiningnode Attaching to
>its responsible peer.

I-D ACTION:draft-ietf-p2psip-rpr-05.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF.

    Title         : An extension to RELOAD to support Relay Peer Routing
    Author(s)     : N. Zong, et al
    Filename      : draft-ietf-p2psip-rpr
    Pages         : 15 
    Date          : April 16, 2013 

   This document proposes an optional extension to RELOAD to support
   relay peer routing mode.  RELOAD recommends symmetric recursive
   routing for routing messages.  The new optional extension provides a
   shorter route for responses reducing the overhead on intermediate
   peers and describes the potential use cases where this extension can
   be used.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
P2PSIP mailing list

RELOAD Interoperability Testing Event in Berlin

This is a call for participation for a RELOAD Interoperability Testing event
in Berlin, Germany on July 27 and 28.

On the Saturday, the event will be held at the Freie Universitaet Berlin.  On
the Sunday the event will be held at the venue of IETF 87.  Many thanks to the
Freie Universitaet Berlin and the IETF for providing the resources for this.

If you have a RELOAD implementation, complete or partial, and want to
participate, please send an email to reloadit-registration@...,
with the following information:

Implementation name
Contact email
Number of persons attending.

Note that the event will be canceled if there is not at least 4 different
implementations registered by end of May, so please register as soon as
possible.  You do not need a complete implementation to participate and be
assured that the name of the participants will be kept confidential.

Remember that all participants can have one or more RELOAD configuration &
enrollment services provisioned for free to simplify the participation in
local or remote interoperability testing.  Please send me an email directly to
provision this service.

Thanks.

--

-- 
Marc Petit-Huguenin

I-D Action: draft-ietf-p2psip-drr-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF.

	Title           : An extension to RELOAD to support Direct Response Routing
	Author(s)       : Ning Zong
                          Xingfeng Jiang
                          Roni Even
                          Yunfei Zhang
	Filename        : draft-ietf-p2psip-drr-05.txt
	Pages           : 17
	Date            : 2013-04-08

Abstract:
   This document proposes an optional extension to RELOAD to support
   direct response routing mode.  RELOAD recommends symmetric recursive
   routing for routing messages.  The new optional extension provides a
   shorter route for responses reducing the overhead on intermediate
   peers and describes the potential cases where this extension can be
   used.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-drr

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-p2psip-drr-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-drr-05

A Model to Quantify the Success of a Sybil Attack Targeting RELOAD/Chord Resources

If you are interested in this type of thing, I highly recommend reading

"A Model to Quantify the Success of a Sybil Attack Targeting RELOAD/Chord Resources",  by Uruena, M. ;
Cuevas, R. ; Cuevas, A. ; Banchs, A.  in Communications Letters, IEEE Volume: 17, Issue: 2

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6412682&tag=1

I-D Action: draft-ietf-p2psip-diagnostics-11.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF.

	Title           : P2P Overlay Diagnostics
	Author(s)       : Haibin Song
                          Jiang Xingfeng
                          Roni Even
                          David A. Bryan
	Filename        : draft-ietf-p2psip-diagnostics-11.txt
	Pages           : 30
	Date            : 2013-03-24

Abstract:
   This document describes mechanisms for P2P overlay diagnostics.  It
   defines extensions to the RELOAD P2PSIP base protocol RELOAD
   [I-D.ietf-p2psip-base] to collect diagnostic information, and details
   the protocol specifications for these extensions.  Useful diagnostic
   information for connection and node status monitoring is also
   defined.  The document also describes the usage scenarios and
   provides examples of how these methods are used to perform
   diagnostics in a P2PSIP overlay networks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-11

A diff from the previous version is available at: