Hi Roland,
many thanks for your careful comments. We will need a few days to return
details / an updated version of the draft ...
Cheers,
Thomas
On 06.09.2014 01:46, Roland Bless wrote:
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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
