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?




 




 




Regards,




Will (Shucheng LIU)




----------------------------------------------------------------------------------------------




Shucheng LIU (Will), Ph.D.




Senior Researcher & Standard Representative, Project Manager





Huawei Technologies Co.,Ltd




liushucheng at huawei.com




http://www.linkedin.com/in/shucheng




----------------------------------------------------------------------------------------------