Telechat Review of draft-ietf-p2psip-sip-18

Request Review of draft-ietf-p2psip-sip
Requested rev. no specific revision (document currently at 21)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2016-04-19
Requested 2016-04-10
Authors Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, Thomas Schmidt
Draft last updated 2016-04-23
Completed reviews Genart Last Call review of -17 by Meral Shirazipour (diff)
Genart Telechat review of -18 by Meral Shirazipour (diff)
Opsdir Telechat review of -18 by Will LIU (diff)
Assignment Reviewer Will LIU
State Completed
Review review-ietf-p2psip-sip-18-opsdir-telechat-liu-2016-04-23
Reviewed rev. 18 (document currently at 21)
Review result Has Issues
Review completed: 2016-04-23


Hi all,


I have reviewed draft-ietf-p2psip-sip-19 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the
 operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.


This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD).


Summary: Ready with issues.


* Section 2, page 5:

This section should probably look more like a dictionary: e.g., bulleted list for the definition of terms.


Some terms are used throughout this document, but not listed here. I suggest that you explicitly list them here.



* Section 3.3:

>    o  The certificate contains a username that is a SIP AOR which hashes

>       to the Resource-ID it is being stored at.


This is the first time you mention "Resource-ID". It would be great if this term could be defined/explained in the Terminology section.

Otherwise, a non-expert doesn't know what you're referring to.



* Section 4.1, page 10:

>    A RELOAD user, member of an overlay, who wishes to call another user

>    with given AOR SHALL proceed in the following way.


While "SHALL" is a RFC2119 term, I'd probably use an equivalent form (MUST?). (I'd probably have to lookup "SHALL" to double-check that it's equivalent to "MUST")



* Section 5.1, page 11:

> If certificate-based authentication is in

>    use, the responding peer MUST present a certificate with a Node-ID

>    matching the terminal entry in the destination list.


Please clarify what you mean by "terminal entry".



* Section 5.1, page 12:

>    Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted

>    SIP messages over the connection as in normal SIP.  A caller MAY

>    choose to contact the callee using SIP or secure SIPS, but SHOULD

>    follow a preference indicated by the callee in its contact_prefs

>    attribute (see Section 3.2). 


Is "secure SIPS" correct? Should it just be "SIPS"?



* Section 5.1, page 12:

>  However, a UA

>    can redirect its communication path by setting an alternate Contact

>    header field like in ordinary SIP.


What do you mean by "redirect its communication path"?



* Section 5.2, page 12:

> Applications

>    that want to assure maintenance of sessions individually need to

>    follow regular SIP means. 


What do you mean by "regular SIP means"?



* Section 6, page 13:


You talk about the "enrollment server". Where is it defined/specified/described?




Will (Shucheng LIU)


Shucheng LIU (Will), Ph.D.

Senior Researcher & Standard Representative, Project Manager

Huawei Technologies Co.,Ltd

liushucheng at