Re: [sipcore] New version (-04) of draft-ietf-sipcore-originating-cdiv-parameter

["A. Jean Mahoney" <[e-mail]>]

Hi Marianne,

Thanks for incorporating Ben's feedback. I have some suggested wording 
improvements on the latest changes.

Section 1.1, p 1 -

Current:

                                                         A session
    case is an information indicating the status of the session in
    which the served user is involved (originating, terminating..).

Suggested:

                                                        A session
    case is metadata that captures the status of the session of a
    served user: whether the served user is registered or not, and
    whether the session originates or terminates with the served
    user.


Section 1.3, p 1 -

Current:
	                                                  A filter
    criteria is a user profile information that determines whether a
    particular initial request needs to be sent to a particular AS.


Suggested:

    Filter criteria is information in the user profile that
    determines whether an initial request is sent to a
    particular AS.


Section 5, bullet 2 -

Current:

    o  In [RFC5502], except for security reasons, it is not to clearly
       stated what to do with the received P-Served-User header field
       when a call is diverted to another destination.  This document
       dealing with this specific use case, highlights that several
       possibilities exist: the S-CSCF could store the previous
       "regstate" value and decide that the same value applies, or the
       "regstate" may not be relevant after a diverting service and
       removed, or the regstate could be combined with the orig-cdiv
       session case to provide different services if the served user is
       registered or unregistered.  These choices are implementation
       dependent.


Suggested:

    o  [RFC5502] does not clearly state what to do with the received
       P-Served-User header field when a call is diverted to another
       destination. This document highlights that there are several
       ways of handling the P-Served-User header field: the S-CSCF could
       store the previous "regstate" value and decide that the same value
       applies; or the "regstate" may no longer be relevant after a
       diverting service so the S-CSCF removes it; or the regstate could
       be combined with the orig-cdiv session case to provide different
       services depending on whether the served user is registered or
       unregistered. These choices are implementation dependent.


Thanks!

Jean



On 9/24/18 3:32 PM, [e-mail] wrote:
> Hi all,
> 
> I've submitted a new version of the draft after Ben's review.
> 
> Main changes between -03 and -04  are:
> 
> -Addition of short definitions for “session case” and “filter criteria”
> 
> -IANA considerations section is moved down.
> 
> -security section is completed with more explanations on the trust 
> domain aspect for the header.
> 
> -Editorials
> 
> The IETF datatracker status page for this draft is:
> 
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/
> 
> Best regards,
> 
> Marianne
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>