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

[Ben Campbell <[e-mail]>]

I think this version is ready for IETF Last call. I will request that shortly.

Thanks!

Ben.

> On Oct 11, 2018, at 2:34 AM, <[e-mail]> <[e-mail]> wrote:
> 
> 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.
>