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

["Bless, Roland (TM)" <[e-mail]>]

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.


>> 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?!
>>
> 
> 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