Subject: [cuss] Reminder: WGLC in progress for draft-ietf-cuss-sip-uui-reqs-02

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Jun 2011 08:35:08 -0500

Folks: This is a reminder that we are in the middle of WGLC [1]
for draft-ietf-cuss-sip-uui-reqs-02.

The WGLC ends on June 17, 2011; so please get in your comments
and feedback before that.  I note that a fair number of people
have already provided feedback.

If you have not already done so, please do take a couple of
minutes of your time to look over the draft [2].

Thanks,

[1] http://www.ietf.org/mail-archive/web/cuss/current/msg00190.html
[2] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Jun 2011 11:10:06 -0400

> minutes of your time to look over the draft [2].

OK, I just did a fresh review of the document. Its been awhile since I 
read it, and so the fresh view may have allowed me to see some things I 
hadn't seen before:

3.3.  Redirection

    In this scenario, UUI is inserted by an application which utilizes a
    SIP redirect server.  The UUI is then included in the INVITE sent by
    the Originator to the Terminator.  In this case, the Originator does
    not necessarily need to support the UUI mechanism but does need to
    support the SIP redirection mechanism used to include the UUI
    information.  Two examples of UUI with redirection (transfer and
    diversion) are defined in [ANSII] and [ETSI].

The statement "In this case, the Originator does not necessarily need to 
support the UUI mechanism" is dubious at best. It either must understand 
the mechanism in order to make an informed choice of whether to pass the 
UUI information from the 3xx to the new INVITE, or else it must blindly 
pass all URI header parameters that it receives. (If that is what the 
mechanism uses. If not, its even more of a problem.) Doing *that* is 
very unwise and not advocated by 3261. But it is the only way the 
Originator doesn't need to understand the mechanism.

Or is this intended to mean that the *Originating application" need not 
know about the mechanism as long as the originating UA understands it 
and believes it to be sufficiently benign to allow passing from 3xx to 
resulting INVITE?

    REQ-9: The mechanism will allow proxies to remove a particular type
    of UUI information from a request or response.

    REQ-10: The mechanism will provide the ability for a UA to discover
    which types or application usages of UUI another UA understands or
    supports.

       The creation of a registry of application usages for the SIP UUI
       mechanism is implied by this requirement.  For the ISDN Service,
       there could be value in utilizing the protocol discriminator,
       which is the first octet of the ISDN UUI information, for this
       purpose.

I find no definition of any notion of "types" of UUI. Without such a 
definition this requirement is meaningless.

Is it assumed that "type" and "application usage" are synonyms? Is it 
assumed that there is a relationship between types and/or application 
usages and protocol discriminators?

IMO this needs to be nailed down to finalize the requirements.

I *think* the intent is that "types" and "application usages" refer to 
the same thing, and we should use one term rather than two. (I'd prefer 
application usage.)

And IMO ("based" on a very limited understanding of the use in ISDN) is 
that we ought to consider the various ISDN protocol discriminators to 
map onto *some* of the possible "application usages".

	Thanks,
	Paul

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 15 Jun 2011 10:58:19 +0200

Hi,

after minor clarifications and adjustments, the draft should be ready
for publication.

Best Regards
Christian

General comment to the figures:
UUI information is mentioned only sporadic, it should be mentioned in
every message where UUI may be included.
Examples: 200 OK in all figures or INVITE (F1) in figure 3.

Figure 4: The flow sequence seems to be wrong. I would propose: F1, F2,
F5, F3, F4, F6, F8, F9, F7. E.g. Notify trying F3 should not be sent
before INVITE F5.

Redirection:
   "If the Redirect Server is not in the same administrative domain as
   the Terminator, the Redirect Server must not remove or replace any
   UUI in the initial INVITE.  In Figure 3, this means that if F1
   included UUI, the Redirect Server could not modify or replace the UUI
   in F2.  However, if the Redirect Server and the Terminator are part
   of the same administrative domain, they may have a policy allowing
   the Redirect Server to modify or rewrite UUI information.  In fact,
   many UUI uses within an Enterprise rely on this feature to work today
   in ISDN."

This section is somehow confusing. 
What should the Redirect Server do with the UUI? Remove? Replace?
Rewrite? Modify?
What is the influence to REQ-12? Should there be 2 entries, one entry
for the entity that inserted the UUI and one entry for the entity that
modify/rewrite/replace the UUI?
If this section is relevant for the requirements, please extend them
accordingly, e.g. REQ-12.
If this section is not relevant for the requirements, I would propose to
delete the section. It seems not to be relevant for the understanding of
the use case.

REQ-1:
      "SIP messages covered by this include INVITE requests and end-to-
      end responses to the INVITE, which includes 18x and 200
responses."

What about the 302 Moved Reply in the Redirection use case? Should we
mention this
Response here as well?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Vijay K. Gurbani
Sent: Monday, June 13, 2011 3:35 PM
To: [email-masked]
Subject: [cuss] Reminder: WGLC in progress
fordraft-ietf-cuss-sip-uui-reqs-02

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Jun 2011 10:25:47 -0500

Paul,

Thanks for your review.  See my comments below.

- Alan -

On Mon, Jun 13, 2011 at 10:10 AM, Paul Kyzivat <[email-masked]> wrote:
> OK, I just did a fresh review of the document. Its been awhile since I read
> it, and so the fresh view may have allowed me to see some things I hadn't
> seen before:
>
> 3.3.  Redirection
>
> support the UUI mechanism" is dubious at best. It either must understand the
> mechanism in order to make an informed choice of whether to pass the UUI
> information from the 3xx to the new INVITE, or else it must blindly pass all
> URI header parameters that it receives. (If that is what the mechanism uses.
> If not, its even more of a problem.) Doing *that* is very unwise and not
> advocated by 3261. But it is the only way the Originator doesn't need to
> understand the mechanism.

Agreed, and this exact point is made in Section 3 of
draft-ietf-cuss-sip-uui, which I think is the right place for that
text.

>
> Or is this intended to mean that the *Originating application" need not know
> about the mechanism as long as the originating UA understands it and
> believes it to be sufficiently benign to allow passing from 3xx to resulting
> INVITE?

No, this was not the intended meaning.

> assumed that there is a relationship between types and/or application usages
> and protocol discriminators?
>
> I *think* the intent is that "types" and "application usages" refer to the
> same thing, and we should use one term rather than two. (I'd prefer
> application usage.)

Yes, they are the same thing, so we should use one term.  I propose
'application usage'.

>
> And IMO ("based" on a very limited understanding of the use in ISDN) is that
> we ought to consider the various ISDN protocol discriminators to map onto
> *some* of the possible "application usages".

This will be  a matter for our ISDN interworking draft.  I do not
think that ISDN protocol discriminators have any meaning outside of
ISDN and provide no value in being mapped to SIP.

---

From: Alan Johnston <[email-masked]>
Date: Tue, 21 Jun 2011 11:58:36 -0500

Christian,

Thanks for your comments on the draft.  See my comments below.

- Alan -

On Wed, Jun 15, 2011 at 3:58 AM, Schmidt, Christian 1. (NSN -
> Examples: 200 OK in all figures or INVITE (F1) in figure 3.

You are suggesting that that the figures show UUI in every place where
it could be present?  I'm not sure that will make things clearer.

> F5, F3, F4, F6, F8, F9, F7. E.g. Notify trying F3 should not be sent

It doesn't really matter - F3 and F5 can be sent at the same time.
I'm using the sequence that is usually used - see the figures in RFC
3515  for example.

> delete the section. It seems not to be relevant for the understanding of

I will move this text to the mechanism draft and clarify it.

> What about the 302 Moved Reply in the Redirection use case? Should we

Good catch!  I will add in 3xx here.