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

From: Atle Monrad <[email-masked]>
Date: Mon, 6 Jan 2014 07:56:22 +0000

Folks

Personally I think that Keith has answered this in a previous mail, but for the record; can I assume that the comments from Celine need no further reply before the draft can continue its journey towards RFC?

I would also be happy to understand the timeline for the remaining steps of this draft.

On:
Note just an editorial comment: in section 16 about changes, "ISDNinterwork" purpose value should be replaced by "isdn-interwork".
As this section will be removed by the RFC editor, I am not really sure that a new version need to be produced to add this nit.

Cheers
/atle

________________________________ 

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation 
Ericsson

-----Original Message-----
From: cuss [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 16. desember 2013 15:57
To: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Hello,

Thank you for the update of the ISDN draft.
I have just some comments or questions below on your answers to my previous comments:

1/ The text about "isdn-interwork" is in section 8 "UAS requirements" but it is also applicable to other sections, for instance to section 7 "UAC requirements" (when UAC receives UUI in responses), so could it be replicated in section 7 "UAC requirements" or only put once in section 11 "Coding requirements" in order to be global, as you prefer?
Note just an editorial comment: in section 16 about changes, "ISDNinterwork" purpose value should be replaced by "isdn-interwork".

2/A/ I agree with your comment on "originating user". But I think it would be better to clarify the expected behavior by UAS [respectively by UAC] on reception of User-to-User that is not with the "purpose" parameter to "isdn-uui", or with no "purpose" parameter, in a request [respectively in a response], as follows:  

"When receiving UUI, when a User-to-User header field is received in a request that is not from the originating user with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, the UAC MUST discard this header field." => this sentence of the draft is ok but "UAC" should be replaced by "UAS", isn't it? Because it's the UAS that receives the request containing UUI sent by UAC (same comment for sentences beginning by "When receiving UUI, when multiple User-to-User header [...]", it seems to me that "UAS" and "UAC" are inverted).

"When receiving UUI, when a User-to-User header field is received in a response that is not with the "purpose" header field parameter to "isdn-uui", or with no "purpose" header field parameter, the UAC MUST discard this header field." => this sentence could be added in order to specify the UAC behavior when it receives unexpected UUI in a response from the UAS.

2/B/ Yes the sentence "When sending UUI for the ISDN package, the UAS SHOULD set the User-to-User "purpose" header field parameter to "isdn-uui".  Non-inclusion of the "purpose" [...]" is well present in both sections 7 and 8. 
But the sentence "When sending UUI for the ISDN package, if the "purpose" header field is included, the UAC MUST set the User-to-User "purpose" header field parameter to "isdn-uui"." is only present in section 7 but not in section 8, why? (first sentence aims at recommending to include a purpose parameter using a SHOULD whereas second sentence clarifies the required value using a MUST)  

Thank you for your clarifications.

Best regards
 
Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : DRAGE, Keith (Keith) [mailto:[email-masked]]
Envoyé : lundi 16 décembre 2013 04:25
À : SERRUT VALETTE Celine IMT/OLN; Gurbani, Vijay K (Vijay); [email-masked] Objet : RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

See below.

I will issue the version without the last two changes, but if the discussion identifies some other text with which the group agrees, a new version can always be issued.

Regards

Keith 

> -----Original Message-----
> 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,
> 
> 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.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."
> 
This one has been dealt with in a separate dialog, and the text agreed as a result of that dialog incorporated.

> 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)
> 
Section 7 is the UAC procedures, and therefore material will never be from the originating user.

This requirement was drafted because UUS1 in ISDN can only be originated from the originating user and therefore this is a unidirectional requirement.

Therefore I do not see the need for an equivalent procedure in clause 7.

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

Section 8 includes:

   The UAS MAY include the User-to-User header field in responses to the
   initial INVITE request, or the BYE requests or responses for the
   dialog, only where the original INVITE request included a User-to-
   User header field with the "purpose" header field parameter to "isdn-
   uui", or where no "purpose" header field parameter was included.
   When sending UUI for the ISDN package, the UAS SHOULD set the User-
   to-User "purpose" header field parameter to "isdn-uui".  Non-
   inclusion of the "purpose" header field parameter is permitted, but
   this is primarily to allow earlier implementations to support this
   package.  The UAS MUST NOT include more than one User-to-User header
   field for this package in any SIP request or response.

Does this not effectively say that.

> 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
> 
> 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
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
> 
> ______________________________________________________________
> ___________________________________________________________
> 
> 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.
> 
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
> 

_________________________________________________________________________________________________________________________

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.

_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: <[email-masked]>
Date: Tue, 7 Jan 2014 13:48:31 +0000

Hello and Happy New Year,

No, we would like to get answers to our questions or propositions of modifications (mail below of 16th Dec.).
OK with your comment on "ISDNinterwork". 
Best regards
 
Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : Atle Monrad [mailto:[email-masked]] 
Envoyé : lundi 6 janvier 2014 08:56
À : SERRUT VALETTE Celine IMT/OLN; DRAGE, Keith (Keith); [email-masked]
Objet : RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Folks

On:

Cheers
/atle

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation Ericsson

-----Original Message-----
From: cuss [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 16. desember 2013 15:57
To: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Hello,

Best regards
 
Celine Serrut-Valette
Orange Labs

-----Message d'origine-----

See below.

Regards

Keith 

Section 8 includes:

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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 08 Jan 2014 17:25:43 -0600

On 01/07/2014 07:48 AM, [email-masked] wrote:
> No, we would like to get answers to our questions or propositions of
> modifications (mail below of 16th Dec.). OK with your comment on
> "ISDNinterwork".  [...]

Keith, Celine: Can you please let us know what the status of this is.

Are the changes simple enough to be folded in an -07?

We need to finish this up so I can proceed with my shepherd writeup.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Atle Monrad <[email-masked]>
Date: Wed, 8 Jan 2014 23:37:34 +0000

Vijay

As said previously, in my view Keith has given his view on this on Dec 16th, and nobody have given any support in either way. 

Anyway,  if more text is needed I think this is not too complicated and can be done in -07.

I do hope that people find some minutes to answer so we don't lose the momentum but get the remaining work done. 

thanks
/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: 9. januar 2014 00:26
To: [email-masked]; DRAGE, Keith (Keith); [email-masked]
Cc: Atle Monrad
Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 09 Jan 2014 09:37:03 -0600

On 01/08/2014 05:37 PM, Atle Monrad wrote:
> Vijay
>
> As said previously, in my view Keith has given his view on this on
> Dec 16th, and nobody have given any support in either way.
>

Atle: Indeed, my impression is that Celine's changes are editorial
and can be incorporated in -07, however, I'd like the ISDN document
editor to confirm --- or refute --- this.

Keith, please let us know.

> I do hope that people find some minutes to answer so we don't lose
> the momentum but get the remaining work done.

I agree; I'd like to finish as soon as possible as well.

Cheers,

- vijay

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 24 Jan 2014 16:15:54 +0000

See below - changes are made to my working version, which I will submit in due course when this dialog is closed. 

Keith

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 16 December 2013 14:57
> Subject: RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn
> 
> Hello,
> 
> 1/ The text about "isdn-interwork" is in section 8 "UAS 
> requirements" but it is also applicable to other sections, 
> for instance to section 7 "UAC requirements" (when UAC 
> receives UUI in responses), so could it be replicated in 
> section 7 "UAC requirements" or only put once in section 11 
> "Coding requirements" in order to be global, as you prefer?
> Note just an editorial comment: in section 16 about changes, 
> "ISDNinterwork" purpose value should be replaced by "isdn-interwork".
> 
A conformant UAC (i.e. according to this version of the id package) generates "isdn-uui" as the purpose parameter as part of the header field that invokes the service. A non-conformant UAC will not have been implemented according to this specification.

A non-conformant UAS receiving a "isdn-uui" purpose parameter when it expects the "isdn-interwork" purpose parameter will not understand it and therefore presumably will discard. The only previous version that might respond is an implementation that was implemented before the purpose parameter was defined, which is going back a long way. The UAS cannot invoke the service but can only respond to what it receives from a conformant UAC.

Therefore I do not see how a conformant UAC can receive a purpose parameter set to "isdn-interwork".

Change made, but as this part will be discarded on publication not strictly necessary.

> 2/A/ I agree with your comment on "originating user". But I 
> think it would be better to clarify the expected behavior by 
> UAS [respectively by UAC] on reception of User-to-User that 
> is not with the "purpose" parameter to "isdn-uui", or with no 
> "purpose" parameter, in a request [respectively in a 
> response], as follows:  
> 
> "When receiving UUI, when a User-to-User header field is 
> received in a request that is not from the originating user 
> with the "purpose" header field parameter to "isdn-uui", or 
> with no "purpose" header field parameter, the UAC MUST 
> discard this header field." => this sentence of the draft is 
> ok but "UAC" should be replaced by "UAS", isn't it? Because 
> it's the UAS that receives the request containing UUI sent by 
> UAC (same comment for sentences beginning by "When receiving 
> UUI, when multiple User-to-User header [...]", it seems to me 
> that "UAS" and "UAC" are inverted).
> 
Two changes UAC to UAS made in section 8.

> "When receiving UUI, when a User-to-User header field is 
> received in a response that is not with the "purpose" header 
> field parameter to "isdn-uui", or with no "purpose" header 
> field parameter, the UAC MUST discard this header field." => 
> this sentence could be added in order to specify the UAC 
> behavior when it receives unexpected UUI in a response from the UAS.
> 
Difficult one this. For the non-inclusion, we have a "SHOULD" on the sending to allow for earlier implementations that do not understand the "purpose" header field parameter. On that basis, reception of the UUI header field without a "purpose" header field parameter should be permitted.

As regards the reception with a different header field parameter value, this could well be destined for a different, as yet undefined package.

In section 9 we say the following which was meant to cover this:

"   Processing for User-to-User header fields sent or received with
   values other than this value are outside the scope of this document,
   and the appropriate package document for that value applies."

On that basis I believe nothing is required to be changed.

> 2/B/ Yes the sentence "When sending UUI for the ISDN package, 
> the UAS SHOULD set the User-to-User "purpose" header field 
> parameter to "isdn-uui".  Non-inclusion of the "purpose" 
> [...]" is well present in both sections 7 and 8. 
> But the sentence "When sending UUI for the ISDN package, if 
> the "purpose" header field is included, the UAC MUST set the 
> User-to-User "purpose" header field parameter to "isdn-uui"." 
> is only present in section 7 but not in section 8, why? 
> (first sentence aims at recommending to include a purpose 
> parameter using a SHOULD whereas second sentence clarifies 
> the required value using a MUST)  
> 
Looks like this is correct. Added.

> À : SERRUT VALETTE Celine IMT/OLN; Gurbani, Vijay K (Vijay); 
> [email-masked] Objet : RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn
> 
> See below.
> 
> I will issue the version without the last two changes, but if 
> the discussion identifies some other text with which the 
> group agrees, a new version can always be issued.
> 
> Regards
> 
> Keith 
> 
> This one has been dealt with in a separate dialog, and the 
> text agreed as a result of that dialog incorporated.
> 
> This requirement was drafted because UUS1 in ISDN can only be 
> originated from the originating user and therefore this is a 
> unidirectional requirement.
> 
> 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.
> 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, 24 Jan 2014 17:45:15 +0100

Hello Celine,
Hello Keith,
Hopefully we can finalize these issues, and you are satisfied with the arguments from Keith.
I see the facts also as Keith it does.
UUS in PSTN is started with a IAM (See Q.737.1) and the backward direction is based on that "request".
So UUS will never be started within an answer. Pls. see the regarding itu-t specifications.
So seen from this fact I would like to see the same behavior within SIP. So I support the arguments from Keith.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: cuss [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Freitag, 24. Januar 2014 17:16
An: [email-masked]; [email-masked]
Betreff: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Keith

> 1/ The text about "isdn-interwork" is in section 8 "UAS requirements" 
> but it is also applicable to other sections, for instance to section 7 
> "UAC requirements" (when UAC receives UUI in responses), so could it 
> be replicated in section 7 "UAC requirements" or only put once in 
> section 11 "Coding requirements" in order to be global, as you prefer?

> 2/A/ I agree with your comment on "originating user". But I think it 
> would be better to clarify the expected behavior by UAS [respectively 
> by UAC] on reception of User-to-User that is not with the "purpose" 
> parameter to "isdn-uui", or with no "purpose" parameter, in a request 
> [respectively in a response], as follows:
> 
> request that is not from the originating user with the "purpose" 
> field parameter, the UAC MUST discard this header field." => this 
> sentence of the draft is ok but "UAC" should be replaced by "UAS", 
> isn't it? Because it's the UAS that receives the request containing 
> UUI sent by UAC (same comment for sentences beginning by "When 
> receiving UUI, when multiple User-to-User header [...]", it seems to 
> me that "UAS" and "UAC" are inverted).
> 

> response that is not with the "purpose" header field parameter to 
> "isdn-uui", or with no "purpose" header field parameter, the UAC MUST 
> discard this header field." => this sentence could be added in order 
> to specify the UAC behavior when it receives unexpected UUI in a 
> response from the UAS.
> 

> 2/B/ Yes the sentence "When sending UUI for the ISDN package, the UAS 
> SHOULD set the User-to-User "purpose" header field parameter to 
> "isdn-uui".  Non-inclusion of the "purpose"
> But the sentence "When sending UUI for the ISDN package, if the 
> "purpose" header field is included, the UAC MUST set the User-to-User 
> "purpose" header field parameter to "isdn-uui"."
> (first sentence aims at recommending to include a purpose parameter 
> using a SHOULD whereas second sentence clarifies the required value 
> using a MUST)
> 

> I will issue the version without the last two changes, but if the 
> discussion identifies some other text with which the group agrees, a 
> new version can always be issued.
> 
> Regards
> 
> Keith
> 
> received in a
> should not

---

From: <[email-masked]>
Date: Mon, 27 Jan 2014 10:50:30 +0000

Hello,

Thank you very much for your answers and the planned modifications, they are ok for me, we can close this dialog.

Best regards

Celine Serrut-Valette
Orange Labs

PS: Just a small question for my better understanding, but it does not really matter:
In 2/A/ (UAC behavior when it receives UUI in a response), you wrote "As regards the reception with a different header field parameter value, this could well be destined for a different, as yet undefined package." => is this not the same point for UAS when it receives UUI in requests (already in the draft)? What is the difference?  

-----Message d'origine-----
De : DRAGE, Keith (Keith) [mailto:[email-masked]] 
Envoyé : vendredi 24 janvier 2014 17:16
À : SERRUT VALETTE Celine IMT/OLN; [email-masked]
Objet : RE: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Keith

---

From: <[email-masked]>
Date: Mon, 27 Jan 2014 10:50:34 +0000

Hello,

Thank you for your answer, yes we can finalize these issues.
Just for information, the proposal in 1/ was not to address the case where UUS would start within an answer (as you said, not possible), but to address the following case:
a/ A conformant UAC sends in INVITE a UUI with "isdn-uui" purpose parameter value
b/ A non-conformant UAS receives it, either it discards it (as suggested by Keith below) or it accepts the UUI data regardless of the purpose parameter value (behavior not really specified in draft-johnston-sipping-cc-uui-09), let's suppose the latter
c/ The non-conformant UAS sends back in answer a UUI with "isdn-interwork" purpose parameter value 
d/ The conformant UAC will thus receive in answer a purpose parameter set to "isdn-interwork"

Best regards

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : vendredi 24 janvier 2014 17:45
À : [email-masked]; SERRUT VALETTE Celine IMT/OLN; [email-masked]
Objet : AW: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Hello Celine,
Hello Keith,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: cuss [mailto:[email-masked]] Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Freitag, 24. Januar 2014 17:16
An: [email-masked]; [email-masked]
Betreff: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-isdn

Keith

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 27 Jan 2014 09:05:35 -0600

On 01/27/2014 04:50 AM, [email-masked] wrote:
> Hello,
>
> Thank you very much for your answers and the planned modifications,
> they are ok for me, we can close this dialog.

Celine: Excellent.  Thank you for your attention to the draft.

Keith: Can you kindly review a version and submit it with the changes
agreed upon.

I will finish the shepherd writeup and move the draft ahead as soon as
a new version appears.

Cheers,

- vijay