[dispatch] IETF#81: My DISPATCH notes

[Christer Holmberg <[e-mail]>]

Hi,

Below are my notes from the DISPATCH session.

(Hopefully the other note taker managed to cover the Global Service Provider Identification Number part.)

Regards,

Christer



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

Topic:          Session-id
Presenter:      Salvatore Loreto
Focus:          Use-cases and proposed charter
Draft:          draft-jones-ipmc-session-id-reqts-00


The presenter suggested that the work should only cover a limited set of use-cases. It was commented that the draft
discusses many more use-cases, and that people are interested in a solution that also solves use-cases not listed in
the suggested charter.

It was indicated that, in order to solve more use-cases, a re-charter would be needed, but that everytime people
have tried to expand the proposed charter something has come up that others are not happy with.

It was indicated that, instead of talking about which use-cases are NOT covered, we should focus on the use-cases that
we do want to solve.

It was indicated that there would need to be a requirement on SBC customers not to modify the session-id information. However, it is
not possible to make such requirement, as it is not technical, and since there might be different reasons why customers want
to remove/modify specific information.

It was indicated that there might be different understandings on what the identified session is, and it needs to be clear
in order for everyone to have a common understanding.

It was asked whether the problem could be solved by making sure that user identity is not revealed in the Call-Id header. However,
there might be other reasons why B2BUAs need to modify the Call-Id.

In addition to the charter discussions, there were discussions whether forking is covered, whether end-users need the information, and whether the
session-id can change during the call, e.g. due to different applications, but where the call is still
considered to be the same.


It was clarified that, if it could be guaranteed that it would remain unchanged, the Call-Id would solve the use-cases
in the currently proposed charter.


HUM:

Question:       People who are in favor in moving forward with the propsed charter? vs People who are in oppose in moving forward with the propsed charter?
Result:         There was strong consensus in favor of moving the work forward.


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


Topic:          Load balancing
Presenter:      Vijay Gurbani
Focus:          Proposed charter
Draft:          None specific for the meeting.


It was commented that the difference between overload control is not clear. It was indicated that, with load balancing, you will not have
to put effort associated with overload control, as the idea is to avoid overload scenarios to take place.

It was commented that there currently are multiple different solutions available, without any guarantee of interoperability, but that
a standardized solution hopefully would make that problem go away.

It was questioned what, if any, IETF standardization work is needed, or whether this would be better as a reasearch topic?

It was indicated that there are solutions that be used to provide feedback from server, which receiving entities might use to
perform load balancing, and that it would be good to have a BCP or use-case document.

It was indicated that there has been no discussions with the APPS people regarding this topic.


There was an indication that people are interested in the topic as such, but that it is unclear where and what work
should be done. People were encouraged to continue the discussions per e-mail, and it was indicated that the
focus should be on what needs to be done from an engineering perspective.


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


Topic:          Binary Floor Control Protocol (BFCP)
Presenter:      Charles Eckel
Focus:          Proposed charter
Draft:          draft-sandbakken-dispatch-bfcp-udp

It was indicated that, if it is possible to do BFCP both with UDP and TCP, there might be a need
to specify gateway procedures, as we don't want to mandate support of both transport options.

It was discussed where the work would be done, as the XCON WG is closing up. Most likely a mini WG would be created.
Also indicated that it needs to be done in a WG, rather than as an AD sponsored wrok, as one would have to
deal with how different versions of the protocol wold interoperate.

Indicated that there seems to be an assumption that a protocol that relies on a reliable transport can be moved
to an unreliable transport just by adding responses.

There was some confusion of what the purpose, and intended outcome of the work is. If the purpose is to simply
describe existing implementations, the outcome should beinformational rather than a standards
track. It was claried that the proposal is for a new standards track protocol.


HUM:

Question:       Are people in favor in IETF publishing an RFC how to do BFCF over UDP?
Result:         Strong concensus for doing BFCP over UDP.


HUM:

Question:       Do people whink it should be standards/informational/do not care?
Result:         Equal between people who care, and more strong among people who do not care.