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

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.