[martini] Draft notes from MARTINI Interim V

["Bernard Aboba" <[e-mail]>]

If you want me to tidy them up, ask and I will do it tomorrow. I've already
had a 14 hour working day.

John

################################

Adam Roach
Bernard Aboba
Brian Lindsay
Cullen Jennings begin_of_the_skype_highlighting
end_of_the_skype_highlighting
Ernst Horvath
John Elwell
Laura Liess
Martien Huysmans
Mary Barnes
Paul Kyzivat
Richard Shockey begin_of_the_skype_highlighting
end_of_the_skype_highlighting
Spencer Dawkins
Alan Johnston
Dan Romascanu
Krisztian Kiss
Keith Drage
Peter Leis
Tim Dwight
David Hancock
James Swan
Hadriel Kaplan
Martin Dolly

Draft-ietf-martin-gin-03 - Adam Roach
No objection to moving requirements analysis to appendix.

Ticket#28 - user=phone. Can we live with autouser mechanism in 03?
Cullen: PBX does nothing different if it receives user=phone - effectively
should be ignored, so adding specification for this will make things better
rather than worse.
John: Shares Adam's opinion that just need a solution, but solution should
be as simple as possible.
Cullen: Similar statement. E.g., if get all numeric string or string
beginning +, just ignore whether user=phone present.
Keith: So rewrite RFC 3261?
Cullen: Expect the unexpected - be generous in what you receive.
Keith: So send whatever you like?
Cullen: Yes.
Adam: ????
Cullen: Send what 3261 says you should send, and accept whatever you receive
(with/without user=phone).
Adam: So what template is sent to SSP?
Cullen: Doesn't matter.
Spencer: So sending should be OK.
Cullen: It doesn't matter.
Adam: Cullen seems to be suggesting don't send user= in templates, and SSP
sends whatever 3261 says, and PBX acceptes what it receives (with/without
user=phone). Any objection?
Bernard: Would we expect any objection from IESG.
Adam: Should be a problem as long as we are not contradicting SIP.
Keith: So 3261 says must include user=phone if expect recipient to process
as telephone-subscriber string.
Adam: That is really an issue with 3261 itself.
Adam: No objection to proposal above, so will reflect in next draft.
Keith: What about delivery through to phones behind the PBX.
Adam: That is a matter for the PBX.
Keith: Which entities are we writing behaviour for?
Adam: Terminals not impacted and will have no knowledge that they are behind
a MARTINI interface.
Keith: ????
Adam: We are only specifying the PBX interface to the SSP and vice versa.
Keith: PBX could be a proxy or B2BUA. What requirement are we placing the
"ignore" on?
Paul: This is processing request-URIs.
John: And even proxies can manipulate Request-URIs
Adam: ????
Keith: Be careful of terminology.
Paul: ????
Adam: I think I can provide text to capture Keith's concerns and make it
clear exactly to which interface procedures apply to.
No further objection to the approach.

Ticket #36 - reg-event handling
Issue of whether to handle subscription at SSP or at PBX. Proposed way
forward is for gin to mandate neither behaviour - just describe the pros and
cons and leave it to other bodies such as 3GPP to define it to suit their
architectures.
Cullen: Sounds like an interoperability nightmare, because a subscriber
won't know what it will get.
Spencer: Will have different Request-URIs
Adam: No, they will be the same. This is a similar situation to
architectural issues already discussed with presence, i.e., whether a
presence subscription is handled by a presence server or a terminal.
Paul: I am more in Cullen's camp. People will want both.
Cullen: Different people will want different things.
Keith: If you want the local one, how do you ensure you have got the local
one.
Paul: Could do a second subscription if it gets the wrong one, but puts
burden on client, which shouldn't know about MARTINI.
Keith: Yes.
Adam: That is why my initial proposal was for PBX to process subscriptions,
which would normally be what the subscriber expects. Hadriel and Bernard
convinced him to do differently.
Bernard: Was not disagreeing with Paul.
Hadriel: Doesn't understand what domain name a UA behind the PBX would
register to - isn't ssp.com, so if they want events for the PBX registrar,
would not be subscribing to [e-mail].
Paul: But other people wanting information about me would use the URI they
would use to reach me.
Keith: If get URI of business card and subscribe to it, would they get the
information they want?
Adam: Right, and if SSP replies would not get expected information like
whether I can do video.
Cullen: Agree with Keith that it has to be the PBX that responds.
Paul: If there are other cases requiring different logic ...
Martin: ????
Adam: Part of callee caps, part of registrar and in reg-event package.
Martin: Doesn't see usefulness of this.
Hadriel: That is not a commmon use case for reg-event package.
Adam:
Keith: Can understand why you might want to do it for diagnostic purposes.
Cullen: Boatload of reasons for callee caps.
Paul: Question was simply why callee caps is included in reg-event. For
completeness.
Hadriel: This is a sidetrack - what are people using reg-event for.
Paul: Mostly people in same domain, UAs from same user, buddies, etc. But
dangerous to make assumptions about what things are used for.
Hadriel: Most people use reg-event just for ????
???? Couldn't keep up with discussion here - largely repetitive.
Keith: Not sure whether we have a need for reg-event from the MARTINI side
of the PBX requiring state from the PBX.
Chair: Need to take this to list.
Adam: We tried this already, and we had this proposal and no comments on
list.
Bernard: Can we cover the points stated during this discussion in context of
Adam's proposal:
????: But doesn't address Cullen's concern.
Hadriel: Happy to say it must go to the PBX, as long as you have some
separate means for subscribing to the SSP.
Adam: That is already covered in the document - can subscribe to the PBX
state as whole as seen by the SSP.
Spencer: would be thrilled to stick with what is in the document.
Cullen: Any objections to this?
Hadriel: Question about URS that end up in reg-event document.
Adam: Will need to dig into reg-event a little to clarify this.
Paul: A way of federating:
Adam: SSP can create back-end subscriptions and aggregate them, but a lot of
work and unlikely to be implemented.
Paul: We have a bunch of stuff on GRUU, but we have not talked about GRUU
reg-event.
Adam: What are use cases?
Paul: Some 3GPP cases.
Keith: Have to make sure that what we do works even when PBX registrar is
not aware of MARTINI.
Adam: PBX has the information, because it is the one handing out the GRUUs
to the terminals.
Paul: Public GRUU will be in domain of SSP anyway.
Adam: Yes, and that can be send for reg-event.
Paul: Will result in hairpinning of request to these GRUUs
Adam: Can have local interception.
Martin: What problem are we solving. PBXs know where to route traffic.
Adam: Don't think there is one.
Martin: We can route things today, so why is routing of GRUUs any different?
Paul: But this is something different they have to route, so might break
things.
Paul: I go back to what Adam says - PBX allocates the GRUUs and can route
accordingly.
Martin: We don't want people hairpinning through us.
All seem to be in agreement really!
Adam: To summarise, text in -03 is what we will move forward with, but need
to work out how it interacts with URIs in body or reg-event document.
Keith: Going in right direction, but not sufficient.
Richard: Isn't the PBX logically the correct entity?
Keith: Does 03 allow subscription to SSP registrar.
Adam: Yes, but only for the PBX itself, not for a single phone number behind
the PBX.
Keith: So need some text that clarifies the two cases.
Adam: These are in separate sections, so difference should be clear enough.
Keith: Would like something earlier on in an informative part of the
document, e.g., section 4.
Adam: 7.2 talks about this, send text if something is missing.

Temp-GRUU handling. Described how asymmetric encryption scheme replaces the
symmetric encryption scheme of GRUU RFC.
Paul: Seem to recall some desire at time of working on GRUU to distribute
the functionality more between registrar and UA, and gave up on it.
Cullen: Three key people at the time had very different ideas on how to
proceed.
Alan: Is it the case that what might be acceptable for PBXs would have been
unacceptable to terminals?
Paul: But Cullen doesn't find it acceptable to PBXs either.
Cullen: Issue is with transporting the key. Can easily avoid it, and doesn't
object to mechanism in general.
Paul: Don't have a good idea on computational load - could be a problem.
Adam: Operations are exactly the same, except for SSP signing an integer,
but only happens once when PBX comes on-line. Plus one is RSA rather than
symmetric, but still talking the same order of magnitude.
Bernard: Need to take to list.


Draft-vanelburg-martini-friends-00 (Martin Dolly)

Adam: So what changes are proposed to gin:
????: Just a new option tag
Martin: Want to define another option tag within gin that is not the gin
option tag.
???? What are semantics of new option tag?
Spencer: Would it be sufficient just to point to the 3GPP/ETSI standard.
Adam: Could be done as a different draft.
Cullen: Can somebody give me a description of this, can somebody send a
link?
Keith: Was in slides for one of the early MARTINI meetings.
Richard: References are in the 3GPP draft.
Cullen: Want specific reference, and in fact a description of how it works
in 3GPP.
Martini: Can do that on the list. Speaking as AT&T, my motivation for
including it in the gin draft, as opposed to a separate draft, makes me feel
more comfortable.
Richard: I am sold with the idea of two option tags, and only question is
which draft.
Martin: ????
Spencer: Both chairs are sold on two option tags, and need to work out how
to make that happen. Can somebody provide some text for the IANA section?
Bernard: Would it be possible for ETSI/3GPP to actually ask for the tag?
Spencer: Perhaps Gonzalo could help.
John: Concern that 3GPP/ETSI would be allocated an option tag without
undergoing the same scrutiny that the SIP Forum proposal 6 months ago had to
go through, going through several drafts and end up with gin.
Cullen: I have some sympathy with AT&T, Verizon, etc., and want to know what
has to be done to make it work.
Martin: We enter into business agreement with enterprise, and know exactly
what we will receive from them, what sort of traffic. Don't need reg-event
package.
Richard: As chairman of SIP Forum board, different sizes of PBX, and
reg-event package deals with the <24 or <12 size.
Bernard: Way forward is to get 3GPP/ETSI to make a proposal.
John: Concerned about 2 solutions, when in fact the 3GPP/ETSI proposal is
not 100 miles away from the original SIP Forum proposal, which was rejected
by the IETF.
Spencer: Need to see what our AD, Gonzalo, thinks about this, also in his
capacity as 3GPP liaison officer. I hear what John says and is sympathetic,
but does not want to hold up gin.
Adam: But including option tag in gin draft would hold it up anyway.
Keith: Should already have been done. Nothing in IETF/3GPP agreement that
3GPP has to submit an I-D. IETF should take publicly available specs.
Martin: Will provide information for Cullen.
Richard: Simply a tactical issue whether two RFCs or not.
Spencer: Actions are 3GPP guys (Martin, Keith) to make sure we get a request
to our 3GPP liaison, and see what Gonzalo as AD thinks is the right way to
go.
Richard: And that we get the documents to the list so we can see them.