[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dispatch] DREGS Ad Hoc minutes



Hi, Shida and Jim,
 
Thanks for taking notes and publishing them quickly.
 
What *I* thought happened (very close to the end of the meeting), was that
 
- Robert expressed his concern that SIP Forum participation and IETF participation didn't overlap, and this was a problem because that's the IESG's experience with inter-SDO coordination is that nothing good happens unless there's sufficient overlap,
 
- Spencer said something like "we had about 12 (and John said 14) participants at the last SIPconnect face-to-face, and about 7 were regular IETF attendees, is that enough overlap?", and
 
- Robert said he didn't think so.
 
Others can, of course, confirm (and the audio will probably be available in a small number of days), but it's going to be real important to tease a way forward on this, and I don't want the notes to give the impression that Robert was convinced when I asked my question.
 
Thanks,
 
Spencer
----- Original Message -----
Sent: Thursday, November 12, 2009 5:14 PM
Subject: [dispatch] DREGS Ad Hoc minutes

DREGS Adhoc

Thursday 12 November 2009, 11:30 – 1:00

Chairs: Eric Burger and Mary Barnes

Scribes: Shida Schubert and Jim McEachern

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.

Note:  In spite of Spencer’s statement, the ensuing discussion made it very clear that for at least some of the authors, the intent was in fact very much to ratify this draft, or something very near it.  Apparently the initial charter draft did not mention REGISTER and it was included because SIP Forum participants explicitly asked for it to be added.

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 Siddiqi 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.

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

Hum:  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.

Hum:  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.

Hum: 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 is what we are looking for

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.   


_______________________________________________
dispatch mailing list
dispatch at ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.