2.7.17 PSTN Internet Notification (pin) bof

Current Meeting Report

PIN BOF Meeting Notes

Reported by Alec Brusilovsky.
Recorded by Jim Buller and Vijay Gurbani, to whom both co-chairs express their deepest appreciation for the great job.

Please see talks, proposed charter and reference architecture diagram in PPT format attached.

Where possible (things are happening quickly) points raised are associated to specific individuals whose names were known to the BOF recorders. Apologies are extended to those individuals who raised issues or points but whose names are not known to the recorders. These individuals are indicated as '??'.

The PIN BOF met on Thursday afternoon, July 15.
There were 119 registered attendees.
Chairs: Steve Bellovin, Alec Brusilovsky

Legend:

SB: Steve Bellovin
JB: Jim Buller
AB: Alec Brusilovsky
LC: Lawrence Conroy
JD: Janusz Dobrowolski
IF: Igor Faynberg
HL: Hui-lan Lu
LO: Lyndon Ong
DO: Dave Oran
VP: Vern Paxson
SD: Steve Donovan
SP: Scott Petrack
JR: Jonathan Rosenberg
GS: Goutam Shaw
HS: Henry Sinnreich
LS: Lev Slutsman
??: Unknown

Abbreviations:

ACID - Advanced Caller ID Delivery
DP - Detection Point

1. Opening
AB opened the meeting by presenting the agenda. AB gave a brief outline of the upcoming talks. The proposed agenda was approved without changes.

Agenda:

1. Agenda bashing.
2. Mechanisms for Initiation of services from PSTN - Igor Faynberg.
3. What needs to be in PIN that is not in PINT - Lawrence Conroy.
4. Relevant ITU-T SG 11 Activities - Hui-Lan Lu.
5. One PINT is not enough - Lev Slutsman.
6. PIN goals, milestones, and charter.

Issue: BOF status
SB: Second and final meeting as a BOF, so either turn it into a WG or dissolve. Need to determine the fate in this meeting.

2. Mechanisms for Initiation of services from PSTN - Igor Faynberg.
Issues: How do PIN services start? Triggers and IN Call Models.
- No comments.

3. What needs to be in PIN that is not in PINT - Lawrence Conroy.

Issue: some DP got fired and that some parameters got passed but is that a service?
- SP: Some information is passed on a trigger from the client to the server. Is that the request for service?
- LC: No. The request for service is what is presented to the PIN server, example: ACID - where the service is to either send an email or run some other service.
- DO: (pointing out an error in LC's slides): megaco is device control, not call-oriented.
- SD: Do you want to deploy an SCP with INAP over IP interface to it? That's what it seems like?
- LC: No; we are doing some translation.
- SB: Simplicity and security; you do not want to expose all of IN to the Internet.

Issue: differences between service and call control
- DO: What is a service and call control? If I call 1800 car wash, is it call control or service? What is a service that is not call control?
- LC: If I ask my secretary to phone someone, she is providing a service. The fact that she picks up the phone is a call control.
- DO: Then I am worried, because you have reinvented the web. How is this different then the JavaScript that reserves a plane seat for me.
- ??: Confused about terminology and which way is up, "PIN is reverse of PINT, PIN is PINT upside down". They thought SCF and user initiated calls were the same.
- SB: Recall Igor's detection points when thinking about call control. Look at services like ICW. The phone network notifies you when a call is made. This is PIN. Think of it as an API to IN. Maybe we should define exactly which API -- one framework for how you connect, here are the parameters, here is what you can do and cannot.

Issue: the essence of PIN service
- GS: The way I see and read the charter is: at a trigger, the SCP delivers the message to an Internet network element, and this is informed of the DP. The Internet network element decides what are the services that need to be delivered at this point to the user. ICW is one example, voice IP roaming is another.
- LS: Here is an example of PIN: I want to use PIN to remotely switch off lights in a switching office. Is that not a PINT service? Another example: for the 800 subscriber who wants to change routing rules, why not send him the decision graph over IP? Right now we are doing that using private lines on X.25. We can use IP to do that.
- SB: This event is not interesting on our point, this is going too far in telephony.
- JD: Example of service is follow me. Not only call control, but also it knows where I am.
- SP: Where is the service to be run decided? On the PIN server or client? Does the PIN server says here are the primitives of the call. Who does what and when?
- SB: These are detailed questions that are implementation dependent and I would rather not go into them now.

There was some confusion about initiation of IP side services the explanation that PIN requests are requests to please run or execute a service. This seemed to get some agreement.

4. Relevant ITU-T SG 11 Activities - Hui-Lan Lu.

Issue: security
- DO: Just a nit-pick, you should not be passing IP addresses around.

Issue: ITU SG11 Entities Diagram
- SB: Make sure that everyone understands that everything to the right of SCGF line is out of our bounds (referring to HL's timeflow message). As we did in PINT, the entire IN is considered as a big black box.

Issue: Registration for the service and subscribe/notify model.
- SP: The Registration Request does not happen by magic. The ICW server gets notified because it asked for it. I would like to avoid standardizing an ICW service, then the next service will be ICID, etc. We should not go that way.
- AB: Registration is not a core function of the PIN service. It can be achieved over the Internet, as well, as over the regular snail mail.
- SB: Agreed.
- LC: The arrow labeled Notify is a service request. The Accept is the response.
- JB: Registration request does not look like PIN to me. Is it PINT? I have this simplistic mental model about PIN is hauling PSTN messages out of Internet.
- AB: Internet in only one venue to register.
- SD: Are the Register and Notify message coming out of SCGF standard INAP messages?
- HL: No.
- SP: There is a "subscribe-notify" model because the PC tells some other entity that I am interested in being notified of x message.
- SD: Messages to be delivered to the IP network was from the call model. It sounds like we are mapping those messages in other messages.
- SB: The job of the IN experts is to pick out and choose a small subset of important IN messages and map it into 1 PIN message that goes out to the Internet. The question is what are the interesting messages to be send to the Internet.
- ??: If you look to the interface we are trying to define here, if you look to the SCF, you have a notify-request coming back to it. We also have to define a client interface. Besides ICW, what other scenarios are you trying to support? What is your goal?
- SB: Goal is without regard to SCF, SSF, find interesting things in the PSTN and inform an Internet end point.
- JR: It is interesting to note that the Registration component is standardized. We should keep it distinct, if we can.
- LO: Looks like the ICW server decides the actual service when it gets the Notify message, not the SCGF. Is that correct?
- SB: SG 11 is of the opinion that ICW server is on the Internet, SCGF is in the PSTN domain. What is happening between ICW server and SCGF is in the Internet domain and thus IETF needs to decide what goes on here.
- DO: Can the ICW server be owned by a different organization then the SGCF?
- SB: Out of scope.
- DO: Can a PIN request be securely delivered to the organization other then the originator of the request.
- SB: That is nothing wrong with that as a service model for PIN, however whoever runs the ICW server has to have a trust relationship with the people who own SCGF.
- SP: Today PIN is about ICW service, tomorrow it will be XXX service. When we do this, we have to write down what all the parameters are for a service. Are these parameters generic enough? Can we have generic parameters so we do not define unique parameters for each new service.
- AB: The goal of PIN WG is to standardize building blocks, not the services like ICW and ICID.

5. One PINT is not enough - Lev Slutsman.
Issue: need for the class of services that start from PSTN.
- ??:When I look at the picture of PIN and ICW as a service, two things strike me: ICW is nothing but call forwarding on busy, and secondly you are forwarding the call to a E164 number. I do not see why we are discussing this on IETF.
- AB: An effort was made to work on that.
- IF: In ICW, we did not go into establishing an IP call, which would require PSTN help. The point is that we may be sending email, which is an Internet domain building block.
- SP: PIN server to me was some complicated server, but I now understand that PIN server is my PC, for instance. So is this meant to work when the end user is mobile? So those REGISTER message are coming from a mobile user, not some big ICW server?
- HS: Why does IETF has to do this work? Looks like many carriers have implemented these services like click to connect, but none of them interworks. So this cannot be a commercial success until the protocol becomes a standard. That's why IETF should be involved to make this a standard so carriers can interwork.

6. PIN goals, milestones, and charter.
- SB: Let's move on the objectives and charter. We will not do detailed wordsmithing now, that will be done on the mailing list. I want to scope, objective of the group and the milestones.
- AB: Let us see the reference architecture picture of PIN and PINT. This is a copy of the ASCI picture from our PIN Framework I-D, only better presented.
- JR: This is a broad definition. The problem in my mind is you should know when you are done. This to me could almost be INAP over IP, which is a lot of work. I think the scope is already there but is not expressed in the right way. I do not want anyone to think that we are done when we have INAP over IP.
- SB: We would consider the second option to be a failure.
- JR: Maybe you could limit it to some specific class of service.
- SB: Maybe those in the group with experience of IN could apply some judgement and provide a list of interesting DP's and events.
- AB: Three proposed services are outlined in the proposed charter, which was published on both PIN and PINT exploders.
- SB: We should have a list of all interesting DPs as a first action item.
- DO: Is this in scope: Receiving a call request from PSTN that says that the calling party wants to transfer you, and your PIN server would like to do a carrier select.
- SB: In scope, but not likely on my list of things to do first.
- IF: We may as well set up and agree on three or four services.
- SB: That will be discussed later.
- VP: Once you have a set of DPs and triggers defined, the Main Objective (1) is redundant. Should be deleted.
- SB: Deleted.
- SB: Services listed on Main Objectives(2) should be the ones we look into immediately. Any other services?
- ??: PSTN charging should be handled.
- SB: We do not do charging in IETF. If there is a particular feature in the protocol that will aid in charging, we can hash that out. Is this a billing notification from PSTN to IP user telling him how much the call is costing?
- AB: This is quite outside of our scope.
- DO: I would like to add a service: I would like to know when my daughter calls certain numbers.
- ??: Some kind of buddy list service that tells you when a user turns on his phone and turns off his phone.
- SB: I would rather put those in second round. I would like to keep the scope smaller in terms of what services we intend to do to start with.
- LC: There is IMPP, why do it here. Also, your SCP will get millions of requests.
- AB: Let's move on in the interest of time.
- SP: Third party services, like I want to know when my secretary calls someone.
- ??: Should be some emphasis on WG on how to use existing IETF services to deliver calls instead of inventing new ones.
- SB: Always. LC presented these.
- HL: Conference calls. Today you do not know who is on the conference call. Conference call identification.
- SB: Move on. Discuss other services on the mailing list.
- AB: This is the part of our proposed charter, addressing security issues. Steve has something to add here.
- SB: Main objectives(5) add "privacy" next to "security."
- SB: Deliverables: Information RFC with a list of DPs/triggers, Informational RFC on current practices, Standards Track RFC for defining the PIN protocol, and also a MIB.
- AB: Once again, this is how one would subscribe to the mail exploder.

7. Summary:

A very productive and well-attended second BOF with a lot of expressed interest from network providers and vendors. The BOF reached rough consensus on the amended WG description, milestones and charter. First milestone would be Informational RFC with the description of the IN triggers, needed to provide PIN services that are outlined in the proposed charter.

Slides

Agenda
Summary of the on-line discussion
PIN-Related Activities in ITU-T SG 11
Mailing List
Description of Working Group
Requests Diagram
IN, PINT, and PIN Services as Building Blocks for Complex Services
PIN - What it is, what it isnít