Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 13 Nov 2013 13:11:07 -0600

Folks: Enrico and I will like to announce a WGLC for the ISDN draft [1].

The WGLC will run from Wed, Nov 13 2013 to Fri, Nov 29 2013.

We will appreciate your comments on the draft, posted to the list.  All
comments are appreciated, even if it is a simple one-liner saying that
you believe the draft is ready, or conversely, that it is not ready (and
why).

As you review the draft, as part of your WGLC review, please identify
any issues that may exist in regard to compatibility with
draft-ietf-cuss-uui (the mechanism draft).

Thank you.

[1] http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-isdn/

Vijay K. Gurbani and Enrico Marocco

---

From: Atle Monrad <[email-masked]>
Date: Fri, 22 Nov 2013 19:04:15 +0000

G'day

I have reviewed the draft again and have a couple of nits.

1.
Abstract

   The motivation and use cases for interworking and transporting ITU-T
   DSS1 User-user information element data in SIP are described in the
   "Problem Statement and Requirements for Transporting User to User
   Call Control Information in SIP" document.  As networks move to SIP
   it is important that applications requiring this data can continue to
   function in SIP networks as well as the ability to interwork with
   this ISDN service for end-to- end transparency.

Remove space:   this ISDN service for end-to-end transparency.

2.
3.2.  Impacts of the ISDN service on SIP operation

   The ISDN service has the following impacts that need to be understood
   within the SIP environment.

   Call transfer  ISDN call transfer cancels all user-to-user
      supplementary services.  In the ISDN, if user-to-user data is
      required after call transfer, then UUS3 has to be renegotiated,
      which is not provided by this SIP extension.  The impact of this
      restriction on the SIP environment is that UUI header fields
      cannot be exchanged in transactions clearing down the SIP dialog
      after call transfer has occurred.

   Conference  ISDN conferencing allows the user to still exchange user-
      to-user data after the conference is created.  As far as UUS1 is
      concerned, it is not permitted.

      The ISDN three-party supplementary service is similar in many ways
      to conferencing, but is signalled using a different mechanism.
      This means that on clearing, the controller using UUS1 implicit
      does have the choice of sending data to either or both remote
      users.  Because SIP conferencing cannot completely emulate the
      ISDN three-party supplementary service at the served user, UUS1
      implicit is not possible.

   Diversion  When ISDN diversion occurs, any UUS1 user-to-user data is
      sent to the forwarded-to-user (assuming that the call meets
      requirements for providing the service - this is impacted by the
      explicit service only).  If the type of diversion is such that the
      call is also delivered to the forwarding user, they will also
      receive any UUS1 user-to-user data.

Would it make sense to add some NLs and/or :s after the three "ISDN SSs" to split the text and improve readability??

e.g. like
   Call transfer:
      ISDN call transfer cancels all user-to-user
      supplementary services.  In the ISDN, if user-to-user data is
      required after call transfer, then UUS3 has to be renegotiated,
      which is not provided by this SIP extension.  The impact of this
      restriction on the SIP environment is that UUI header fields
      cannot be exchanged in transactions clearing down the SIP dialog
      after call transfer has occurred.
Or
   Call transfer:  ISDN call transfer cancels all user-to-user
      supplementary services.  In the ISDN, if user-to-user data is
      required after call transfer, then UUS3 has to be renegotiated,
      which is not provided by this SIP extension.  The impact of this
      restriction on the SIP environment is that UUI header fields
      cannot be exchanged in transactions clearing down the SIP dialog
      after call transfer has occurred.

----
I hope the draft can progress soon

Cheers
/atle

________________________________ 

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
Sent: 13. november 2013 20:11
To: [email-masked]
Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

We will appreciate your comments on the draft, posted to the list.  All comments are appreciated, even if it is a simple one-liner saying that you believe the draft is ready, or conversely, that it is not ready (and why).

As you review the draft, as part of your WGLC review, please identify any issues that may exist in regard to compatibility with draft-ietf-cuss-uui (the mechanism draft).

Thank you.

Vijay K. Gurbani and Enrico Marocco
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: <[email-masked]>
Date: Thu, 28 Nov 2013 16:01:23 +0000

Hello,

Please find below some comments:

1/ About "isdn-interwork" versus "isdn-uui" purpose parameter value: 

The discussions on the "[cuss] "isdn-uui" versus "isdn-network"" email thread confirmed that there is still support from other cuss participants for addressing the use of the "isdn-network" parameter value. So, we don't think the document can be published without addressing this issue. We also understand that at least one company would not accept replacing "RECOMMEND" with "MUST", so we propose to stick to the initial approach (cf http://www.ietf.org/mail-archive/web/cuss/current/msg00509.html ) and add the following text in section 11:

"The 'isdn-interwork' value for purpose parameter was used in Internet-Drafts that have led to the publication of the present RFC. Although these documents had no other status than "work in progress", this value is implemented by some vendors. Therefore, it is RECOMMENDED to support parsing and interpreting 'isdn-interwork' the same way as 'isdn-uui' when receiving."

2/ About UAC and UAS procedures:

After having compared the UAC and UAS procedures in sections 7 and 8, I noticed that 2 UAC procedures could be replicated as UAS procedures as well, so I would suggest to add in section 7:
"When receiving UUI, when a User-to-User header field is received in a response that is not from the originating user with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, the UAS MUST discard this header field."
(this procedure seems not present for UAS)

And to add in section 8:
"When sending UUI for the ISDN package, if the "purpose" header field is included, the UAS MUST set the User-to-User "purpose" header field parameter to "isdn-uui"."
(this procedure is present for UAS but not so explicitly written)

It could be worthwhile to add them in order to be symmetric when a procedure is common to both UAC and UAS, otherwise people could wonder if it means that they are just missing or if it means that they are not applicable.

We would like these 1/ and 2/ comments to be taken into account before the ISDN draft becomes a RFC.
Thank you in advance.

Best regards

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Vijay K. Gurbani
Envoyé : mercredi 13 novembre 2013 20:11
À : [email-masked]
Objet : [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

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.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 29 Nov 2013 01:17:01 +0000

With regard to your point 1), you are specifying normative language - for this as defined as follows by RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

That means exactly the same in 3GPP and therefore any references from 3GPP carry this as a should level requirement - unless you are saying that the general 3GPP architecture provides a reason for the 3GPP specification overriding this.

It means essentially for any general purpose implementation in IETF or 3GPP that this becomes "MUST" or "shall", because the implications cannot be understood unless applied to a specific content usage.

As far as I am aware your organisation is the only one that has been supporting statements at this level.

My read of Roland's last comment was that he would not support a requirement, but I leave him to speak.

Regards

Keith 

> From: cuss [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 28 November 2013 16:01
> To: Gurbani, Vijay K (Vijay); [email-masked]
> Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn
> 
> Hello,
> 
> The discussions on the "[cuss] "isdn-uui" versus 
> "isdn-network"" email thread confirmed that there is still 
> support from other cuss participants for addressing the use 
> of the "isdn-network" parameter value. So, we don't think the 
> document can be published without addressing this issue. We 
> also understand that at least one company would not accept 
> replacing "RECOMMEND" with "MUST", so we propose to stick to 
> the initial approach (cf 
> http://www.ietf.org/mail-archive/web/cuss/current/msg00509.htm
> l ) and add the following text in section 11:
> 
> "The 'isdn-interwork' value for purpose parameter was used in 
> Internet-Drafts that have led to the publication of the 
> present RFC. Although these documents had no other status 
> than "work in progress", this value is implemented by some 
> vendors. Therefore, it is RECOMMENDED to support parsing and 
> interpreting 'isdn-interwork' the same way as 'isdn-uui' when 
> receiving."
> 
> After having compared the UAC and UAS procedures in sections 
> 7 and 8, I noticed that 2 UAC procedures could be replicated 
> as UAS procedures as well, so I would suggest to add in section 7:
> "When receiving UUI, when a User-to-User header field is 
> received in a response that is not from the originating user 
> with the "purpose" header field parameter to "isdn-uui", or 
> with no "purpose" header field parameter, the UAS MUST 
> discard this header field."
> "When sending UUI for the ISDN package, if the "purpose" 
> header field is included, the UAS MUST set the User-to-User 
> "purpose" header field parameter to "isdn-uui"."
> It could be worthwhile to add them in order to be symmetric 
> when a procedure is common to both UAC and UAS, otherwise 
> people could wonder if it means that they are just missing or 
> if it means that they are not applicable.
> 
> 
> We would like these 1/ and 2/ comments to be taken into 
> account before the ISDN draft becomes a RFC.
> Thank you in advance.
> 
> Best regards
> 
> Celine Serrut-Valette
> Orange Labs
> 
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Vijay K. Gurbani Envoyé : mercredi 13 novembre 
> 2013 20:11 À : [email-masked] Objet : [cuss] WGLC for 
> draft-ietf-cuss-sip-uui-isdn
> 
> We will appreciate your comments on the draft, posted to the 
> list.  All comments are appreciated, even if it is a simple 
> one-liner saying that you believe the draft is ready, or 
> conversely, that it is not ready (and why).
> 
> As you review the draft, as part of your WGLC review, please 
> identify any issues that may exist in regard to compatibility 
> with draft-ietf-cuss-uui (the mechanism draft).
> 
> 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.
>

---

From: <[email-masked]>
Date: Fri, 29 Nov 2013 10:14:30 +0100

Hi,
when we discussed this approach, everybody was OK with a note since this was agreed on a pragmatic approach.

This was not based on a pedantic interpretation of editorial rules. Going along the rules the wording was not RECOMMENDED it was recommended.

I have nothing against such note written with a lower case recommended. The future RFC will still be understood by people reading it. And if the RFC will be implemented it will work (with or without the Note).

So goal reached.

What will I say. I can go along the PRAGMATIC compromise reached one year ago and I can life without a note. But I cannot accept any normative changes to ABNF.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: cuss [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Freitag, 29. November 2013 02:17
An: [email-masked]; Gurbani, Vijay K (Vijay); [email-masked]
Betreff: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Regards

Keith 

> The discussions on the "[cuss] "isdn-uui" versus "isdn-network"" email 
> thread confirmed that there is still support from other cuss 
> participants for addressing the use of the "isdn-network" parameter 
> value. So, we don't think the document can be published without 
> addressing this issue. We also understand that at least one company 
> would not accept replacing "RECOMMEND" with "MUST", so we propose to 
> stick to the initial approach (cf 
> Internet-Drafts that have led to the publication of the present RFC. 
> Although these documents had no other status than "work in progress", 
> this value is implemented by some vendors. Therefore, it is 
> RECOMMENDED to support parsing and interpreting 'isdn-interwork' the 
> same way as 'isdn-uui' when receiving."
> 
> 7 and 8, I noticed that 2 UAC procedures could be replicated as UAS 
> procedures as well, so I would suggest to add in section 7:
> "When receiving UUI, when a User-to-User header field is received in a 
> response that is not from the originating user with the "purpose" 
> header field parameter to "isdn-uui", or with no "purpose" header 
> field parameter, the UAS MUST discard this header field."
> header field is included, the UAS MUST set the User-to-User "purpose" 
> header field parameter to "isdn-uui"."
> It could be worthwhile to add them in order to be symmetric when a 
> procedure is common to both UAC and UAS, otherwise people could wonder 
> if it means that they are just missing or if it means that they are 
> not applicable.
> 
> 
> De : [email-masked] [mailto:[email-masked]] De la part 
> de Vijay K. Gurbani Envoyé : mercredi 13 novembre
> We will appreciate your comments on the draft, posted to the list.  
> All comments are appreciated, even if it is a simple one-liner saying 
> that you believe the draft is ready, or conversely, that it is not 
> ready (and why).
> 
> 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.
> 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Fri, 29 Nov 2013 13:24:43 +0000

Hello,

We agree for such a note written with a lower case recommended.

Best regards

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : vendredi 29 novembre 2013 10:15
À : [email-masked]; SERRUT VALETTE Celine IMT/OLN; [email-masked]; [email-masked]
Objet : AW: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Hi,

So goal reached.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: cuss [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Freitag, 29. November 2013 02:17
An: [email-masked]; Gurbani, Vijay K (Vijay); [email-masked]
Betreff: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Regards

Keith