Re: [P2PSIP] WGLC for draft-ietf-p2psip-sip-13

[Roland Bless <[e-mail]>]

Hi,

> The WGLC will be open till the 8th of September, so we have time enough
> even there is August in the middle. We kindly ask the WG to review the
> document and provide comments.

That was a good decision due to vacation time in August:-)

I carefully read the document and didn't find any real show stoppers,
but IMHO the document would benefit from some clarifications
as indicated below.

Major:
- Normally a SIP registration times out after some period
  (usually given in the REGISTER message)
  I guess that the mechanism is replaced in P2PSIP by the
  lifetime parameter in the StoredData. If this is the case
  I'd like to see it mentioned explicitly.

- It is unclear how SIP and SIPS should be realized, because
  AppAttach only allows to create DTLS/UDP or TLS/TCP connections
  (cf. OverlayLinkType in IceCandidate).
  "Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted
  SIP messages over the connection as in normal SIP."
  Sending "plain" (I guess non-secured) SIP message is not possible
  if AppAttach doesn't allow for UDP-only connections.

- I guess that the destination list should contain only
  NodeIDs, or are ResourceIds and OpaqueIDs also permitted?
  If not, then the calling/initiating peer should check
  that condition and some action must be defined if the
  destination list is non-conforming (maybe discard
  this destination list)

- The Draft should clearly specify how to map AORs
  to Resource-IDs as required by RFC6940, sec. 5.2:
   o  Define how the Resource Name is used to form the Resource-ID where
      each Kind is stored.
  I guess that the AOR is mapped by using the overlay hash function
  after stripping the scheme (like sip:, sips:) from it. But that
  should be defined explicitly.

Minor:
Sec. 1:
- Several different notations like 'Node-ID "1234"', Node-ID 1234
  or ID 1234 are used in this section.

Sec. 2:
OLD:    include the scheme (e.g sip:) as the AOR needs to match the
NEW:    include the scheme (e.g. sip:) as the AOR needs to match the

Sec. 3.3:

   o  A Store is permitted only for AORs with domain names that fall
      into the namespaces supported by the RELOAD overlay instance.

   and then

   Before issuing a Store request to the overlay, any peer SHOULD verify
   that the AOR of the request is a valid Resource Name with respect to
   its domain name and the namespaces defined in the overlay
   configuration document (see Section 3.4).

the first formulation suggests that the latter quotation should use
rather MUST than SHOULD (the Storing Peer MUST also verify this).

   Before a Store is permitted, the storing peer MUST check that:

   o  The AOR of the request is a valid Resource Name with respect to
      the namespaces defined in the overlay configuration document.

What would be the proper reaction if this condition is not fulfilled?
I guess a StoreAns with Error_Forbidden, but that could/should also be
mentioned.

Sec. 5.1:

   the responding peer MUST present a certificate with a Node-ID
   matching the terminal entry in the route list.

route list wasn't introduced before and I guess destination list
would be the right term here. Moreover, what is the reaction if
there is a certificate mismatch, i.e., the Node-ID doesn't match
the one in the certificate? Should the connection be torn down?

Sec. 5.2:
typo
OLD:   that want to assure maintanance of sessions individually need to
NEW:   that want to assure maintenance of sessions individually need to

Sec. 6:
   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?!

Sec. 7:


   sip_registration_route

      a destination list which can be used to reach the user's peer.

if there are any restrictions like only Node-IDs allowed or the
last entry must be a Node-ID, no Resource-IDs allowed, that could
be mentioned here, too.

Sec. 8:

What about destination lists that contain back and forth routes
like 1234 5678 1234 5678 1234 4444 5678 1234 7777?
This may be used for traffic amplification as mentioned in
sec. 13.6.5. of the RELOAD spec. Therefore, an additional
check at the StoreReq receiving node may be useful, even
if destination lists are checked by RELOAD.

Regards,
 Roland