Last Call Review of draft-mohali-dispatch-cause-for-service-number-12
review-mohali-dispatch-cause-for-service-number-12-opsdir-lc-morand-2017-01-25-00

Request Review of draft-mohali-dispatch-cause-for-service-number
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-18
Requested 2016-12-14
Authors Marianne Mohali, Mary Barnes
Draft last updated 2017-01-25
Completed reviews Secdir Last Call review of -12 by Robert Sparks (diff)
Genart Last Call review of -12 by Joel Halpern (diff)
Opsdir Last Call review of -12 by Lionel Morand (diff)
Assignment Reviewer Lionel Morand
State Completed
Review review-mohali-dispatch-cause-for-service-number-12-opsdir-lc-morand-2017-01-25
Reviewed rev. 12 (document currently at 14)
Review result Has Issues
Review completed: 2017-01-25

Review
review-mohali-dispatch-cause-for-service-number-12-opsdir-lc-morand-2017-01-25

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.