[P2PSIP] I-D Action: draft-ietf-p2psip-sip-15.txt

[i***@ietf.org]

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 : A SIP Usage for RELOAD
Authors : Cullen Jennings
Bruce B. Lowekamp
Eric Rescorla
Salman A. Baset
Henning Schulzrinne
Thomas C. Schmidt
Filename : draft-ietf-p2psip-sip-15.txt
Pages : 20
Date : 2015-07-04

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
overlay. After such initial contact of a peer, the AppAttach method
is used to establish a direct connection between nodes through which
SIP messages are exchanged.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-p2psip-sip-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-sip-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

[Bless, Roland (TM)]

Hi,

I reviewed the latest version -15 now:
Sec. 3.1:

"Note that
the registration lifetime known from the regular SIP REGISTER method
is inherited from the lifetime attribute of the basic RELOAD
StoredData structure (see Section 7 in [RFC6940])."

Not sure that it's expressed in the right order. Maybe better:
Note that the lifetime attribute of the basic RELOAD
StoredData structure (see Section 7 in [RFC6940]) now corresponds
to the registration lifetime given by a regular SIP REGISTER method
in the "expires:" parameter.

Sec. 5.1.
"Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted
SIP messages over the connection as in normal SIP."

I find this still confusing as there is no way to send "plain"
SIP messages via RELOAD, they will always be sent via an encrypted
(D)TLS transport from end-to-end.
Maybe:
Once the AppAttach succeeds, the peer sends SIP messages (for SIP
and SIPS sessions) over the connection as in normal SIP. It is
noteworthy that according to [RFC6940] all overlay links built
by AppAttach are utilizing (D)TLS secured transport.

(then delete the redundant:
It is noteworthy that according to
[RFC6940] all overlay links are built on (D)TLS secured transport.)

Similarly:
"While hop-wise encrypted paths do not prevent the use of plain SIP,
SIPS requires end-to-end protection that may include client links and
endpoint certificates."
Since every AppAttach Link will be end-to-end protected by (D)TLS,
I think this statement is superfluous.

GRUUs in RELOAD are constructed by embedding a
base64-encoded destination list in the gr URI parameter of the GRUU.
I guess that the destination list is encoded in the same way as
described in section 6.3.2.2. of RFC 6940. Simply a list of
Destination entries without any preceding length field?!

Well yes, we're using the RELOAD destination list (term and definition) here. The above encoding describes the URI-encoding, not the representation of the data structure in the overlay.

That at least caused an ambiguous interpretation on my side. I thought
that I need to build the binary representation of the destination list
data structure first and then encode it in base64. This is obviously
wrong and should be clarified.

Regards,
Roland