Subject: [SPIRITS] IETF51 SPIRITS meeting notes

From: Alec Brusilovsky <[email-masked]>
Date: Tue, 04 Sep 2001 14:48:39 -0500

Ladies and Gentlemen,

Please take a look at the proposed notes form the 8/7/2001 London
meeting.

Kind regards,
Alec
51st. IETF SPIRITS Working Group Meeting Notes

Reported by Alec Brusilovsky.
Recorded by Vijay Gurbani, to whom both co-chairs express
their sincerest gratitude for the excellent job.

SPIRITS WG met in the afternoon of Tuesday, August 7,
2001.
There were 66 registered attendees. 
(Due to just one blue registration sheet available. 
Only left half of the room was able to sign in.)

Chairs: Steve Bellovin, Alec Brusilovsky

Agenda

1. Opening and goals of session - Alec Brusilovsky (5 min)
2. On collaboration with ITU-T - Hui-Lan Lu (5 min)
3. On the protocol requirements - Igor Faynberg (5 min)
4. Discussion of the needed components for the SPIRITS 
   protocol - Chairs, floor (35 min)
5. On selection of INAP parameters to be carried to be carried by 
   the SPIRITS protocol - Musa Unmehopa (10 min, if time permits).

Chair (A.B.) went through the agenda bashing; agenda was accepted 
without any changes or additions.

Agenda Item 1:
--------------
Hui-Lan Lu presented the updated work going on in SG 11 which 
is being done in cooperation with the IETF PINT and SPIRITS WGs. 
ITU-T SG 11, using a fast-track approval process, has recently 
approved these new Recommendations of relevance to SPIRITS:

- Q.1241 - Introduction to Intelligent Network Capability Set 4
- Q.1244 - Distributed Functional Plane for Intelligent Network Capability Set 4
- Q.1248.1-7 - Interface Recommendation for Intelligent Network Capability Set 4

These Recommendations include support for PINT and SPIRITS services. 
Specifically, the requirements and architecture are in alignment with 
those for PINT and SPIRITS.

Agenda Item 2:
--------------
Igor Faynberg presented a quick update on the SPIRITS protocol 
requirements. The I-D outlining the requirements has been sent 
to the IESG for consideration as an RFC. The WG have not heard 
from the IESG yet. Chairs proposed to ask ADs and the IESG about 
the destiny of the Protocol Requirements I-D, current Informational 
RFC candidate.

The SPIRITS architecture has passed scrutiny and has become an 
Informational RFC.  There was one issue raised (having to do with 
the SPIRITS/PINT joint architecture), which was successfully resolved.

Other issues confronting the WG are the selection of the right set 
of param-eters and propagating them.  

Issue: there is a question of why SPIRITS has chosen SIP as the 
protocol of choice.  
It is not a matter of jumping on the SIP bandwagon, but there are 
legitimate choices as to why SIP was chosen:

   (1) PINT, to which SPIRITS is intimately joined with, uses SIP.
   (2) RFC 2995 (Pre-SPIRITS Implementation of PSTN-initiated Services)
       strongly presents the case that all pre-existing ICW service 
       implementations used SIP.
   (3) SPIRITS will use the publisher/subscriber paradigm heavily, and SIP
       already has these extensions in the form of the SUBSCRIBE/NOTIFY
       messages.

Issue: Why CS3.  Why did we choose it?  
Not only because Frans Haerens said so.  But also because CS3 is a superset of CS2 
and CS3 has not added any new parameters beyond charging, which is not addressed by
SPIRITS.

Issue: (Frans Haerens): Additional functionality in CS3 did with management
of triggers.  Will INVITE handle triggers -- create/modify them?
Answer (Igor): Yes it will.  And, no additional SIP extensions are needed 
to accomplish this.

Agenda Item 3
-------------
Components of the SPIRITS protocol -- pre-protocol work has produced 2 RFCs:
RFC 2995 and RFC 3136 (The SPIRITS Architecture).  Current candidates for
RFC standard are the Spirits Protocol Requirement I-D.

Current I-Ds include carrying INAP parameters for the SPIRITS protocol, and
ways to encode these parameters (XML is the current candidate for this purpose).
The next step is to write a SIP protocol specification.

The chairs asked for volunteers for working on the SIP protocol specification.

Issue: (Vijay Gurbani) for SPIRITS to use the SUBS/NOT extensions, a SPIRITS-related
package of events has to be defined.  I will be glad to help in this work.
Anyone interested in working on this, please get in touch with me.

Issue: (Igor): SUBSCRIBE/NOTIFY extension must be stable in the SIP WG before SPIRITS uses it.
Brian Rosen, SIP WG co-chair was present at the meeting and indicated that
the SUB/NOT extension is quite stable and SPIRITS should be able to use it
without any adverse effects going forward.

Issue: (Igor) DP numbers and names should be registered with IANA, as should be the
package name.
Answer: (Brian Rosen) Until IANA gets to this, Henning Schulzrinne and/or Jonathan
Rosenberg will have a site to register names; simply use that.

Issue: (Alec) It is worth pointing out that the SUB/NOT extensions in PINT are *NOT*
the same as in SPIRITS.

Answer: (Igor) We have discussed this with the PINT editors; one way to resolve this is
to re-issue the PINT RFC to have the new SUB/NOT functionality.

Issue: (Alec) XML has been described as the choice to carry INAP parameters in SPIRITS.
The I-D has been posted on the list, but there have been no responses yet.  We
would like to reach a technical consensus on this.

[A hum was issued and XML won the day.]

Issue: (Alec) Now we need to specify which INAP parameters to carry.  There is an I-D
for this.
The chairs decided to take this issue to the list for further feedback and a conclusion.

Issue: (Frans) So far, the I-D in question uses CS-2 in the examples, but that 
should not stop people from using CS-3 parameters.  CS-3 is a superset of CS-2, 
thus all parameters supported in CS-2 are supported in CS-3.

Issue: (Alec) We need the following work to be done:

- Generate a call flows I-D, a la SIP for Services and SIP Call Flows I-Ds.
- Work on the events package and call flows
- Assume the use of SUBSCRIBE/NOTIFY and INVITE methods for SPIRITS services
   
Issue: (Alec) over the last few months, ICW has become less "cool"; but that should not
bother us since SPIRITS standardizes the building blocks to build new services and not the services themselves.
In the future, new "cool" services will emerge using these building blocks.

Agenda Item 4
-------------
Musa talked about the selection of INAP parameters in SPIRITS.  Those para-
meteres were selected that are of interest to application developers.  The
parameters focus on providing the building blocks of creating services and
leave the signaling aspect out.  The I-D is inspired by Parlay which has
already undergone a similar approach that has proved successful.

Alec: There is no merge with Parlay; we do not touch the APIs, only select
the parameters that can provide services.

Frans Haerens indicated support for this approach since Parlay defined the UML
for forward-based engineering.  This concept was being used successfully here
and allows for extensions at a later date.
Alec: Does I-D require any changes to the SPIRITS architecture?  or protocol
requirements?
Musa: No.  It is generic enough to be implemented either in a SPIRITS client
or a gateway.
Alec: What are the benefits for a service provider who wants to use this 
approach?
Musa: Applications that are already written in Parlay can now be run in a 
SPIRITS context.  They do not need to change.
Alec: Musa's I-D should be discussed in more detail on the mailing list.  Does
anyone object to making this a WG item?

[No one objected]

Chairs: Other business?

[There was none].

Chairs moved to adjourn the meeting.