Minutes for DISPATCH at IETF-91
minutes-91-dispatch-1

Minutes from Dispatch at IETF 91

1) We clarified Keith's questions aboutif we had previous dispatch one or two
drafts to MMUSIC. The conclusion is that both
        draft-ejzak-mmusic-data-channel-sdpneg
        draft-ejzak-mmusic-msrp-usage-data-channel
were dispatch to mmusic.

2) Deadlines for IETF-92 will be sent to the list after we get the deadlines
for drafts at IETF 92.

3) Discussed Correlation of multiple responses of forked INVITES in Back to
Back User Agents

Conclusion:  Right now it was not clear enough for people to clearly decide the
scope and value. We have asked the authors to continue  on the individual draft
on the dispatch list.

Raw notes below

--------------------------------------------------

Below are the notes courtesy of Brian Rosen

Agenda bash (Chairs)

Dates will come on the list
Keith Drage: Doubt on SDP for MSRP draft dispatch
Chairs: Dispatch is good with your suggestion, up to ADs.  Both docs were
dispatched

Correlation of multiple responses of forked INVITES in Back to Back User Agents
(Roland Jesske)

Keith: No-fork is not a directive, only advisory

<scenarios>
Jon P: confused on how forking proxy returns candidates to B2BUA
Keith: Need a better reason to have document than implementations are
misbehaving Keith: Second scenario not reasonable, No-fork directive is only
advisory Paul K: Not sure if these are multiple responses in single early
dialog, or more than one Chairs: So do we need a real use case other than
broken hardware Jon P: Yes, need something more than broken implementations
Paul K: The B2BUA will itself be difficult to get right Christer: Guidelines on
how something should be done helps interoperable implementations.  Early media
with multiple dialogs has always been a problem. Adam R: Use cases show all we
can do is move the problem. Clarifications might be okay, no new protocol
mechanisms. Robert S: Not just user agents misbehaving, also what the network
does to get things to that user agent Keith: Is there a problem with existing
specifications (imprecise specification) that we could fix? Chairs: He wants
more deterministic behavior Chairs: Should we improve the document to prevent
bad behavior or describe new behavior to fix bad implementations? Paul K: Not
seeing any new protocol mechanism, it's best practice or advice Robert: Or
document that if you do it wrong you won't be able to make it work Christer: If
this goes to STRAW, it's not new mechanism, just explaining how to do it right
Robert: Agree that a good survey and analysis when there is logic correlating
multiple dialogs to one dialog.  We have a notion of a "conference servers",
with protocols.  Could use a lot of these ideas. Jonathan: Not clear if this is
lazy implementation or engineering constraint.  If it's the latter, need some
analysis and possible alternatives. Keith: Not happy describing a box that
turns multiple dialog into one.  Could see advice on handling multiple dialogs
Christer: We have 3261 (From-tag),... Chairs: Proposal - write an individual
draft so we see how this is proposed to work, then decide what to do and then
we can make a dispatch decision. Keith: Anyone can do that, so no problem. 
Describing a box isn't good IETF work (in a work group) Robert: Rewrite draft
as a problem statement and come back? Chairs: Problem statement and proposal
for how to solve it Robert: <To Roland> Do you understand what to do? Roland: I
thought I did that.  How deep should I go? Robert: I agree, people available to
help,  What list? Chairs: Dispatch Paul K: Responding to Keith, we do this kind
of stuff in STRAW Chairs: STRAW does more than explanations Paul K: But the
point is we do that kind of stuff Keith: Not proven to me that this within the
scope of IETF Chairs: Agree, that's why we want another draft, then decide
Paul: Existing doc has much of what you want Chairs: Yes, but we want more
Richard Barnes: "It's not clear" has been said a lot.  Better problem statement
and sketch out straw-man solution

------------------------------------------

Some extra notes from Cullen bellow

Jon Peterson pointed out use case just did not look like sip.

Keith Drage pointed out we need uses cases for non broken equipment.

Keith pointed out presentation seemed someone confused about what no-fork
directive did.

Paul K and others questions why this is better than fixing it

Christer - if we took on this, we would need to study what information we want
to provide and what is ok to loose

Adam Roach - the best we can do is move the problem around in the network and
that does not solve anything. What we need is a clarification document of what
can happen.

Robert Sparks - it's not just UA behavior, but also to what the network is
doing to get things to the UA

Keith D - is there a problem to solve here. Is there some existing UA RFC that
is not clear enough. Would we get more deterministic behavior to say

Keith does not see new protocol coming out of this

Christer something here would help people design network

Sparks - it would be useful to have a survey and analysis of what existing RFC
have to support this type of arch where one correlates multiple dialogs to a
single dialog.

Keith - we have forking in SIP. Hesitant to add a spec that says how to write a
device that converts multiple dialogs to one. Would be willing to say if you
have a box that has multiple dialogs, here is how you correlate them together.
Should not say how to convert it back to a single doc.