49th IETF SPIRITS Working Group Meeting Notes

Reported by Alec Brusilovsky.
Recorded by Kumar Vemuri, to whom both co-chairs express their deepest appreciation for the excellent job.

SPIRITS WG met in the afternoon of Tuesday, December 12, 2000.
There were 106 registered attendees.

Chairs: Steve Bellovin, Alec Brusilovsky

Agenda

1. Agenda bashing and goals of the session - 5 minutes;
2. SPIRITS progress in ITU-T - Hui-Lan Lu - 5 minutes;
3. Discussion on the additions to the SPIRITS Architecture Document - 5 minutes;
4. Discussion on the SPIRITS Protocol Requirements - 20 minutes - I. Faynberg;
5. Next step - SPIRITS Protocol - 20 minutes;
6. Wrap-up - 5 minutes.


1. Agenda bashing and goals of the session

A question on PINT related issues.
The chair requested this discussion to be taken to the PINT list.Agenda was accepted without changes.

2. SPIRITS progress in ITU-T - Hui-Lan Lu
ITU IN Architecture and Requirements WG requested the most recent SPIRITS information.  RFC 2995, The Spirits Architecture document, IN and PINT related Requirements for Spirits Protocol were shared  with the ITU-T. The IN group in the ITU took this information from the Spirits architecture and included this in one of their draft recommendations.  The drafting session in Geneva resulted in a Spirits example configuration in Q.1244.  More discussions may take place in the next ITU IN WG meeting.

3. Discussion on the additions to the SPIRITS Architecture Document

Alec B. talked about working on the protocol. There was consensus on the SPIRITS architecture at the last meeting, now we ought to start work on the protocol requirements.  Alec asked for an open discussion of Spirits related architectural issues, based on items discussed on the Spirits mailing list.

Issue: Comments on architectural framework. There's one interface between the PINT server and the PINT gateway.  This interface was not addressed in detail. Some people suggested that that interface be made Corba based.  The Spirits proxy in the modified architectural view becomes a gateway like entity on the domain interface, and that this does not impact the architectural diagram.

Alec took the Hum for keeping existing architecture vs. redrawing architecture to reflect similarities or symmetries with PINT.
The Hum for the former approach was louder. So the WG will be going forward with the existing architecture.  The Architecture Document will be submitted to the IESG as a candidate for the Informational RFC.

4. Discussion on the SPIRITS Protocol Requirements - I.Faynberg
Igor (de-facto Document Editor) talked about Spirits requirements. Igor summarized the changes to be made reflecting recent discussions. Igor suggested that the present document will be modified according to Sören's proposal to include the words that will specifically say that PINT implementation is not a requirement for a SPIRITS implementation. He also mentioned that there was much useful text in Lawrence's and Jim's drafts and asked that Sören, Jörgen, Lawrence, and Jim mail to him the pieces of their respective documents to be included in the requirements within the first couple weeks after the meeting.  The speaker talked about using IN as a mechanism for transporting notifications. Some changes were made to the mention of CAMEL related issues in the document.  Igor talked about DPs in the call model that would be "SPIRITS enabled", and about the need to pick the appropriate CS (CS-2 or CS-3?) for this as the base model.  He then discussed the use of the SIP SUBSCRIBE and NOTIFY mechanisms for SPIRITS.

Issue: How one could use SUBSCRIBE and NOTIFY methods when a protocol was not already selected.
Answer: the method names as used are merely indicative of the capabilities supported, not that we are talking about protocol specifics at this time.

Regarding persistent interactions, setting dynamic triggers etc., one may have to also use PINT building blocks to support SPIRITS end-to-end call flows. There is a possible problem in recursion: Changes in PINT impact SPIRITS and vice versa. We need PINT-related requirements in SPIRITS and vice-versa.

Issue: It should be possible to implement SPIRITS without implementing PINT.
Answer: We're not saying it is absolutely necessary, but we will also not discourage the use of PINT. Some requirements will continue to address the issue of what happens in SPIRITS, when we use PINT.
Alec B.: During the previous SPIRITS WG meeting in Pittsburgh we agreed that it is not necessary to implement PINT in order to implement SPIRITS.

Issue: JAIN/PARLAY and 3GPP APIs should interact easily with SPIRITS. Maybe we should look to these APIs while building a requirement set for SPIRITS.
Chair: Since IETF does not have formal relationships with JAIN and PARLAY, this may not be possible in all cases.

Both chairs asked for a Consensus Hum: Should we move on this (Requirements) document - is it ready to progress? Yes (based on the Hum). The Requirements Document will be shortly posted for a WG Last Call on the mailing list.

5. Next step - SPIRITS Protocol
The Architecture and the Protocol Requirements work is pretty much done. We are coming closer and closer to the actual SPIRITS Protocol work.  Chairs asked for the Protocol Proposals I-Ds to be submitted and for the volunteers for the Protocol Team to identify themselves.