DISPATCH WG: DREGS Adhoc

Chairs: Eric Burger, Mary Barnes

Notes by: Jim McEachern

Thursday, 11:30 – 1:00

John Elwell – Charter Discussion.

http://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt

Jon Peterson reacted to the John’s statement that “decided we needed a new WG” and said that he had suggested it perhaps should be in DRINKS. Was concerned about the presumption of what needs to be done to address the open issue.

Cullen: the purpose of dispatch is to recommend what should be done. So we could recommend it go to DRINKS or wherever. Let’s see what we recommend.

Clarified that the proposal was that this should be looked at, not that a WG was needed.

Trying to standardize a uniform way for PBXs to register their domain. Today everyone does it their own way, even though they are all very similar.

Proposing to use REGISTER with an added header for requesting domain registration. They are proposing this approach because it builds on what is already widely deployed.

Adam Roach: Are we really proposing to write the use of REGISTER in the charter? Answer: Yes. Adam stated that he was not prepared to have that discussion today because he thought it would be discussed in the WG. This feels like “let’s ratify this draft” rather than “let’s work on this problem”.

Spencer Dawkins: the intent is not to ratify existing draft.

Eric: the subject of whether or not REGISTER should be included in the charter has been discussed on the list, but there is not consensus

Someone stated that REGISTER was proposed because “that is what is implemented” and we need to align with those implementations to be relevant. Jon countered that earlier it had been stated that the entire reason for this is that there are multiple ways this is implemented and that we need a standard to get interoperability. So if it is being done multiple ways today, the argument that REGISTER needs to be in the charter to align with deployed equipment, simply does not fly.

Cable Labs supported the use of REGISTER because that is what they use in their specifications.

Jim McEachern & Adam Roach both pointed out that even if you remove the word REGISTER from the charter, it does not mean that the eventual solution will have REGISTER. The bulk of the objections (dare I say the allergic reaction?) is to the fact that the solution (REGISTER) is being specified in the charter, when we should be simply defining the problem we are trying to solve.

Anwar? Asked about the definition of small – medium business, and said that this will not apply to large enterprises since they will never give their register information to the SP. Therefore why not make it optional.

Markus Isomaki, Nokia: What does this imply about the addresses of the terminals behind the PBX? Answer: UA registers with the PBX, but this work deals with the PBX registering with the SP. It is designed to help the SP work out where to send requests to “example.com”.

Jon Peterson: Charter scope question. Is the charter focused on the specific problem on the slide, or the more general problem? (Note: I think this was referring to the bullets specifying “a header field for requesting domain registration” and “a SIP option tag to detect non-support of this mechanism”.) Answer: The more general one. (Note: I think this meant the general problem of PBXs registering…)

Jon Peterson: The only way this charter will get approved is by taking REGISTER out of the draft. Lots of nods to that.

Spencer: If this looks like tweaking existing implementations, it will get more interest than if it looked like a new method. Preference is to be up front about this.

Cullen (channeling Hadriel): If Hadriel were here he would insist it must be REGISTER or it will never be deployed.

Cullen: would the possible solution space now include dynamic dns? The only reason to specify a solution in the charter is to explicitly exclude alternate classes of solution – isn’t it?

Chris Stanley – cable labs. We need to deploy this for businesses and need to move quickly. (And REGISTER is the mechanism we use.)

Adam Roach: how far are we going to go down this path of specifying the answer in the charter? If we allow it for REGISTER for this WG, what other things are we going to do it for?

Cullen as AD: He was the one who earlier encouraged them to be very specific to see if they could get consensus on the approach to shorten the process, even though he suspected the proposal would get the reaction that it is currently getting. However, if the group cannot get consensus to specify the solution in the charter, then the only approach is to remove it. This is clearly the case.

Vote: Should we leave the charter exactly as it is? Result: Moderate hum

Vote: Should we leave the charter largely as is, but remove the solution (REGISTER) from the charter. Result: Strong hum.

Discussed a vote on “Is there a critical mass in the IETF to work on this problem?”, but instead decided on the following wording.

Vote: Does anyone think that we don’t have the critical mass and the expertise to tackle this. Result: no one objected. So consensus for this.

Vote: is the IETF the place to work on this? Answer: yes

Note: The following happened after the meeting had officially closed, but is included here because it pointed toward a possible way forward.

Jon: Discussion of the precedent setting risks of just adopting an existing solution. One way forward may be to think about this as a telephone number problem rather than a domain problem, which would make it a much easier problem. If we can scope it that way then it will make it a much quicker problem to solve.

Alan Johnston: All the SIP Forum discussion is in fact about telephone numbers, so restricting it to telephone numbers would be acceptable

Cullen: Recognize that we do need to find ways to work faster. “If you send me a charter by midnight tonight, I will have it on the agenda for the next IESG meeting”

Meeting officially closed.

Since we had time, we had an open discussion of how to make progress…

Discussion of what would be realistic dates for this? The discussion indicated that March and June might be more believable dates.

Cullen: Recognize that we do need to find ways to work faster. “If you send me a charter by midnight tonight, I will have it on the agenda for the next IESG meeting”

Robert Sparks: Recipe for success in SDOs cooperating is having a significant overlap of common participants working on the problem. He is concerned that the overlap is not enough.

Spencer: Last SIP Forum meeting had 12 people and 7 of them were also in the IETF. Is that enough?

Jon: Discussion of the precedent setting risks of just adopting an existing solution. One way forward may be to think about this as a telephone number problem rather than a domain problem, then it is a much easier problem. If we can scope it that way then it will make it a much easier problem to solve.

Alan Johnston: All the SIP Forum discussion is in fact about telephone numbers, so restricting it to telephone numbers would be acceptable.