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

[<[e-mail]>]

Hi Jean,

Thanks for your suggestions. I have updated the draft (v-05) to take them on board.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/

Best regards,
Marianne

-----Message d'origine-----
De : A. Jean Mahoney [mailto:[e-mail]] 
Envoyé : mercredi 10 octobre 2018 18:20
À : MOHALI Marianne IMT/OLN; [e-mail]; [e-mail]
Cc : Ben Campbell
Objet : Re: New version (-04) of draft-ietf-sipcore-originating-cdiv-parameter

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.
> 

_________________________________________________________________________________________________________________________

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.