I have reviewed this document 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. Document: draft-mohali-dispatch-cause-for-service-number-12 Category: Informational Update RFC4458 Summary: This document creates a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance for using the "cause" URI parameter within the History-Info header field since this use is mandatory in some IP networks' implementations. Main feedback: This document is ready for publication with some comments. The main purpose of the document is to create a new "Cause" value, which is straightforward. However, to be able to correctly use this new value, it is also required to clarify existing issues/ambiguities in RFC4458 regarding the handling of the "cause" URI parameter in the History-Info header. For this recommendations, there is no normative wording used. And the "RFC 4458 update" part of this document is a little bit hidden in the structure of the document. If a new version of the draft is required, it would be useful to fix these issues. Detailed comment below. ************************************** Abstract RFC4458 defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. [LM] could be useful in the abstract to indicate the title of the RFC instead of only the RFC number. This document also answers a need expressed by the 3rd-Generation Partnership Project (3GPP) [TS.3GPP.24.229]. [LM] I think it is the same need than described in the introduction of this document but could be good to state it. 2. Solution A new value for the "cause" URI parameter of the 'sip:' or 'sips:' URI schemes is defined. This value may be used in a 'sip:' or 'sips:' URI inserted in the Request-URI and in the History-Info header field [RFC7044] when the URI is issued from a retargeting or a service access number translation by a specific service similar to PSTN/ISDN IN services that is not a call forwarding service. [LM] It would be better to introduce the new value ("Service number translation") right after the first sentence. It will be then easier to identify what is referred by "This value" afterward. [LM] On section 2.1 and 2.2: I think that these sections are not directly linked to the definition of the new cause value. It would be clearer to address these points in a separate clause e.g. Section 3. Moreover, section 2.1 is the one providing new recommendations/guidances on the use of the "cause" URI parameter within the History-Info header. It could be also highlighted by addressing them in a distinct section. 2.1. Interaction with Request History Information The implications of this are further discussed in section Section 2.2 [LM] I think that the consequences on "this" refers to the consequences on the proposed solution. Could be clarified. The "cause" header field parameter of the Reason header field should be added to a History-Info entry only when the retargeting is due to a received SIP response. [LM] is this "should" part of the new recommendation? If yes, it should be "SHOULD", I guess. 2.2. Handling and Processing the Service Number Translation "cause" URI parameter value At the Application Server: When an application receiving a request that is addressed to a service access number changes the Request-URI into a routable number it should insert within this new Request-URI a "cause" URI parameter value set to 380. [LM] add a coma after "changes the Request-URI into a routable number" [LM] Could be good to indicate the name corresponding to the value, e.g. set to 380 "Service Number Translation". [LM] What about the use of "SHOULD"? [LM] s/application/application server Following the process described in [RFC7044], the application must add a new History-Info header field entry including the new Request-URI value including the "cause" URI parameter. [LM] If it is described in RFC7044, the "must" should be removed to have "Following the process described in [RFC7044], the application adds. [LM] s/application/application server It is also possible for an application to add a "target" URI parameter as defined in [RFC4458] with the initial value of the Request-URI received by the application. [LM] s/application/application server requested would be lost. Thus, it is strongly recommended to support the History-Info header field all along the signaling path. [LM] what about using "SHOULD" or "is RECOMMENDED" [LM] by the way, there is no section describing the use of key words "MUST", etc. as described in RFC2119. At the UAS: When the UAS receiving the request wants to retrieve the service access number by which it has been reached, first it should look for the "cause" URI parameter value 380 in the History-Info header field. [LM] "should" --> "SHOULD"? This History-Info entry should also contain an "mp" or "rc" header field parameter and then the UAS can find the requested service number in the History-Info entry having an index parameter value that match this "mp" or "rc" header field parameter value. [LM] "should" by "SHOULD"? 4. IANA Considerations This document requests IANA to modify the existing row for the "cause" parameter to add a reference to this document under the "SIP/ SIPS URI Parameters" subregistry within the "Session Initiation Protocols" registry: [LM] Only one document was defining the cause value i.e. RFC4458. Now that there is more than one, would it be simpler to create a specific registry listing the existong causes with the appropriated references? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.