Subject: [cuss] Draft minutes for Virtual II

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 22 Dec 2010 09:48:29 -0600

Folks: Here are the processed draft minutes for the virtual meeting
we held on Tue, Dec-21-2010.  Please go through these and let me
and Enrico know of any errors in summarizing the raw notes.

The raw minutes from Enrico and Leon (thanks!) are at the end of
the draft minutes.

Thank you.
=================================================================

IETF CUSS WG Virtual Meeting II
Tuesday, Dec 21, 2010
9:00 AM - 10:20 AM CHICAGO

Note takers: Enrico Marocco and Leon Portman

Agenda bashed, no changes.
Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim-2/agenda.pdf

Problem statement and requirements, Alan Johnston
Slides:
 
http://www.standardstrack.com/ietf/cuss/cuss-interim-2/pres-cuss-reqs-01.pdf
Internet-Draft: 
http://datatracker.ietf.org/doc/draft-ietf-cuss-sip-uui-reqs/
--------------------------------------------------------------------------------
Went through substantive changes in the current version of the document.
The following records the specific slides where discussion occurred.
An absence of a slide discussing requirements implies that the
meeting participants did not have any comments on it.

Slide 4: Keith stated that REQ-13 and REQ-14 may not be supported over
PSTN.  Alan to clarify this in the next revision by stating that these
requirements are only pertinent when used between two SIP UAs.

Slide 6: REQ-3 changed to include UUI insertion and retrieval in referrals.
Keith noted that in ISDN, insertion by intermediaries is not supported
and that the UUI is inserted and consumed by endpoints.  Alan agreed to
clarify in next revision.

Slide 7: Proposed change involved changing "dialog" to a "call".  Discussion
ensued on what exactly the definition of a "call" is.  If it is an
association between two endpoints, then a SUBS request will satisfy that
requirement as well.  Alan will clarify by replacing "call" with text that
states the UUI will go only in INVITE, 2xx and BYE.

Slide 9:  There was much discussion on slide 9, the result of which was
the following: Alan will propose a new requirement for carrying multiple
UUIs that can be distinguished (i.e., when they were inserted).  In 
addition,
REQ-3 will be clarified.

Slide 10: Discussions ensued, but no changes were proposed to the
requirement.  However, there was an understanding that authentication
needs to be further discussed in the mechanism draft, especially in cases
where redirection is done in trusted domains.

Slide 11: Discussion ensued about the response growing bigger if multiple
UUIs are inserted in a response to the point that the response cannot
be sent over UDP (and conversely, cannot use TCP since the request came
over UDP).  Option tags are a way to mitigate this.  Alan agreed to add
some text in the mechanism draft discussing UUI in response.

Slide 12: Discussion ensued on discovery aspects of UUI (i.e., REQ-10
through the use of OPTIONS).  A decision was made that UUI does not
apply to OPTIONS.

Next steps from the chair's perspective: The document is scheduled to go
to IESG in Dec-2010.  If Alan can revise the document and there is list
consensus that the revision satisfies the WG, then a WGLC can be scheduled.
If the revised document raises other concerns, it may be best to deal
with these concerns by getting related parties on a conference bridge
and present the outcome of the discussions to the WG and produce a
revision that can subsequently be WGLC'd.

UUI Mechanism, Alan Johnston
Slides:
 
http://www.standardstrack.com/ietf/cuss/cuss-interim-2/pres-ccus-mech-01.pdf
Internet-Draft: http://tools.ietf.org/html/draft-johnston-cuss-sip-uui-01
--------------------------------------------------------------------------------
Went through substantive changes in current version of the document.

Slide 7 triggered a discussion on the specific mechanism that the WG
should come up with.  Question asked of chairs on selecting a
solution.  The chairs polled the meeting participants on whether anyone
had an objection to going with the header field approach.  No one had
any objections.  A decision was made to ratify the header approach on
the list.  Chairs will send an email on the list asking for
ratification.

Closing remarks, Vijay K. Gurbani (as chair)
--------------------------------------------------------------------------------
Currently, we do not see a need for a f2f meeting in Prague.
To move the work forward quickly, we can facilitate conference calls
among the key motivators of the work and fill the WG in with the
results of these conference calls.  If there is a need to have a third
virtual meeting, we can do so before Prague.  There is one more draft
to be adopted  --- the Interworking ISDN call control draft --- after
we have reached consensus on the mechanism draft.  Keith noted that we
need to have a mechanism draft to drive useful work forward.

Meeting adjourned at 10:20 AM CHICAGO TIME.

================================================================================
Raw notes from Enrico:
CUSS WG Virtual Interim Meeting
===============================

Agenda
------

Vijay presents the agenda.

   No questions nor comments.

Problem statement and requirements
----------------------------------

Alan Jonsthon presents the updated version of the document.

Slide 4.

   Keith: any integrity protection mechanism will not survive in the
   PSTN network. Alan: will clarify.

Slide 7.

   Keith: how do you define what call is? We must be very carefull, ITU
   definition may be different. Alan: we can clarify that UUI will go
   only in INVITE, 2xx and BYE. Will replace "call".

Slide 9.

   John: do not think we need any requirement stating that you need to
   distinguish UUI preserved in redirection and UUI inserted in
   redirection. Alan: maybe just a requirement for the ability to carry
   multiple UUI? [Some discussion between Keith, Paul and Alan] Alan: the
   requirement will say that there may be multiple UUI and there is a
   mechanism that tells when it was inserted.

   Alan: going to propose a new req about carrying multiple UUI and
   will extend Req-3.

Slide 10.

   Paul: there may be mixed cases where identity cannot be
   asserted. Alan: we definitely need to discuss this in the mechanism.

   No changes to the requirement.

Slide 11.

   Keith: problem with multiple UUI is that response can grow bigger
   than the request and exceede MTU. Alan: we'll point people to 3261,
   the part that deals with big responses.

   Keith: in ISDN you cannot put UUI in the response if it's not in the
   request. Alan: option tag? Paul: supported tag in the request. Alan:
   we'll need some text in the mechanism draft discussing UUI in the
   response.

Slide 12.

   Alan: one more revision is needed, then? How far are we from WGLC?
   Vijay: list discussion based on what's been discussed today,
   revision and then either one more call or LC.

   Keith: still not really happy with the requirement for a discovery
   mechanism. Alan: requirement not needed or overkill? Keith: do not
   want a mechanism for discoverying everything. Alan: right now PSTN
   is the only user for UUI, but if we do a good job, other
   applications may use it.

--------------------------------------------------------------------------------
Raw notes from Leon Portman:

Vijay: agenda is to go over requirements, go over open items and reach
consensus. Any questions on agenda

No agenda updates

Alan:

requirements document. Talking about problem statement and requirements
New security requirements, modification to req 3. And some additional minor
requirememnts
Rewrote security considerations, and added overview for call control UUI and
why INFO is not used

Slide 4: new security requirements. for req-13 UUI over SIP and req-14
for privacy

Keith: we need to be very carefully about these requirements because it can
no be supported over ISDN

Alan: Yes, we need to state that it is only between two SIP UAs.

Slide 5: New security consideration slide. References to req-12, 13, 14.
Not that security is jointly done on app level and sip level.

No comments

Slide 6:

Req-3 - modification to add referrals. Was presented in the use cases

Keith: in ISDN we do not intend to support intermediates ([leon] not
sure about this one). Alan agreed to add this comment

Slide 7:

Req-2 add "call" terminating and not dialog.

Keith: How do we define what is "call" is. We need to be carefull because in
ITU call is also refered to SUBSCRIBE.

Alan: we should probably state specific requests examples. And say that
it is related to INVITE dialog.
  Ok we dont use "call" in any normative statements

Slide 8: redirection issue. Proposed new text. Was too specific and did
not allow redirection cases

No comments

Slide 9: Redirection issue. Important point. We should discuss it in 
mechanism
draft. We need to decide if it is UUI type specific or generic

John: I agree to have it in mechanism draft however not quite convinced that
we dont need to have it in requirements draft.

Keith: We can find ourself with two co-existings UUIs. For ISDN we can not
override ISDN override.

Alan: we could use requirements for carrying multiple UUIs, each of the
separately identifiers

Keith: not specially identifiable but at least to separate ISDN UUI

Paul: additional one can be optional. Any language should allow that one
can get there that it is better that the first one will survive

Keith: May be

Keith: may be preserve it in history-info?

Alan: Whatevet req that we need to identify inserter of the UUI

Keith: HI can be messy

Paul: It will get messy anyway

Alan: HI is the place where this type of info is collected, seems to
be a right place

Paul: And it is part of the mechanism

Alan: So it seems to be req to carry and distinguish of multiple UUI
that inserted by multiple points. I will propose it to the list

Keith: most important to survive redirection.

Alan: We can extend req-3 with appropriate indication

Paul: Or alternative we can extend if it is not already there (for 
rediction)

Alan: And for not ISDN case. do we want also to support it?

Keith: It is depends on the use case

Alan: Yes, we should to define how to implement req-3 and 4. Req-3 is
to make it allow to happen and iteratively

Keith: For ISDN call forwarding scenarios it just allows to access to
the first one and last one

Alan: So we should clarify req-3

Summary:
Discussion for interaction between req-3 and 4. I will propose a new req
for multiple UUI that can be distinguished. And clarify req-3 for
supporting iteratively redirection etc.

Slide 10: Req 12. added authentication by reusing existing mechanisms

Keith: authentication will be done by end user.

John: will be implications. We should state authentication

Paul: Seems to be issues with most auth mechanism. How do we will support
by anybody else except the caller? We will lose the identity by using HI

Alan: Usualy redirection will be done in trusted domain.

Paul: I agree that is common.

Alan: We should discuss it the mechanism

Slide 11 Multiple UUIs. Following John comments, we should talk about it
in mechanism draft.

John: I had in mind multiple applications even on the same end point.

Alan: Yes, we should think about carefully

Keith: Response size can be problematic and grow

John: we have solution: tcp

Alan: we should point to 3261 how to deal with large requests

Paul: we can not use tcp in response if request started with udp

Keith: in ISDN, UUI should exist in request before response

Alan: May be use feature tag for discovery. We definitely need some text 
about
it

Slide 12: Next steps. One additional review is needed. And then WGLC

Vijay: we should have a list discussion, document and conference call

Alan: Ok

Vijay: we will wait for the revision and then decide on the call

Keith: I am not really happy about requirements about the discovery 
problems.
Why do we need identifiers?

Alan: The big user is ISDN. However there will be other users as well.
In a future probably will be lot of new apps that will need it.
We shoud have a discovery mechanism.

Paul: ISDN is a transport and not application. Call Centers for example uses
it via ISDN

Alan. Please send comment about issue with discovery requirements

John: we have requirement to support INVITE and BYE. why do we need to
support Options?

Keith: We should state that we dont want to support OPTIONS because it
can simulate INVITE request.

John: we agree that dont want to support it in OPTIONS

Alan: I will put the statement that it does not apply to OPTIONS

===============================================================================

A mechanism

Alan presenting

===============================================================================
Slide 2:

Revised draft based on discussions in Beijing. Added text for supporting
History-Info for req-12
Discovery mechanism apply to all transport

Slide 3: list discussions

Slide 4: Use of History-Info for source identification. Deatils will be
in the next draft. Referral part is incorrect

Keith: where it is in the draft?

Alan: it is in header field section

John: new header field for UUI can include new mark: inserted-by

Alan: HI does not only option. Other mechanism can be used

Keith: Using mark will get us to use some numbering like in HI.

Slide 5: Secuirity of the header

using S/MIME. Additional body - known issues with bodies.

Forestier: Using S/MIME for req 13-14? Alan: yes, potentially

Slide 6: Referral identity

HI can not be used. Reffered-BY could be used
No comments

Slide 7 requirement comparison: body vs header field

Both mechanism meet the majority. Req-12 likely. Req-9 is not met by body

No comments

Slide 8: Next steps

John: Need clarification. Do you see this draft to get adopted by WG?
But it does not have any normative parts only comparison. Or separate
draft for the mechanism.

Alan: Yes, this can be a good starting point

Keith: Most of the document will be appendix
Alan: It has start of body and header fields and also discovery mechanism

Keith: So it is adoption of the mechanism and not the draft.

Jonn: if we decide that header field is the solution, that draft should
be adopted and extended

Keith: I am not object adoption but we should select the solution

John: yes, this is the main questions

Paul: I am not sure agree if other solutions will be in the appendix

Keith: My question to the chair is to select the solution and which 
mechanism
to adopt?

Vijay: We need to do it in serialized way: requirements first. We should
pick the solution draft after identifying all requirements. There is no
other requirements

John: We should ask if there is any objection for header field option.

Vijay: Ok, from the people on the call, is it reasonable to provide a 
feedback
on other alternatives?

No objections

John: if people on the call, do not object, lets take it to the list

Vijay: do we want to take it on the list

No objections on the list

Vijay: We will post suggestion on the list that header field option will
be the solution.
And then we will start the adoption of the mechanism drafts

Alan. Sound good

===========================================================
Vijay: next steps

===========================================================

We should have 1-2 call before Prague. Currently no need for face2face 
meeting
in Prague.

Other drafts. Interworking ISDN call control UUI with SIP

Keith: Are we really need the mechanism to have a usefull work. We
need the mechanism.

Vijay: Yes, so everything is depends on the list post.
Any comments?

End of the call

---

From: Alan Johnston <[email-masked]>
Date: Wed, 22 Dec 2010 10:01:36 -0600

Everything looks good in the minutes.  Thanks to everyone who
participated on the call - the discussion was very useful and
definitely helped move the work forward.

- Alan -

On Wed, Dec 22, 2010 at 9:48 AM, Vijay K. Gurbani <[email-masked]> wrote:
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>