Meeting notes from CUSS WG meeting, IETF79, Beijing, China Friday, November 12, 9:00-11:30 About 20 attendees This report has been distilled from the detailed meeting notes taken by Paul Kyzivat and Andrew Hutton Chairs: Enrico Marocco and Shida Shubert (acting chair). Vijay Gurbani in the Jabber chatroom. Agenda ------ Enrico presents agenda and a recap of the virtual interim meeting. Keith Drage: proposes can be flexible on time allocations, and need to be. Also doesn’t want to preclude decisions on mechanism. Problem statement and requirements draft ---------------------------------------- Alan Johnston presents the fresh WG document about problem statement and requirements. Doc was rev’ed on Tuesday as an IETF draft. Alan gave overview of changes. Discussion of REQ-8 on ensuring the UAS understands the mechanism. Keith: expresses doubt that this is useful. Asks to work out use cases for how we would use this. Alan: not sure the option tag is right way, but thinks this requirement is still useful. Use case may be requiring a GW that supports UUI rather than one that does not. Keith: how close we want this to be to the ISDN service? If it isn’t in the ISDN service he would take it out. Alan: we still need discussion on this requirement. Would be willing to remove this requirement if that is what the group wants. Discussion of REQ-9 on letting proxies remove UUI. Keith: we allow the header through or we don't there is no need to go any further than this. Alan: there is a need and will be useful for new uses og UUI. Kieth: it is a question of how much permission is needed but we cannot prevent any proxy from doing deep packet inspection. Alan: could be that a UAC will encrypt the content. No Plan to change this at present it will be taken to list. Discussion on REQ-10 on discovery of UUI capability. Keith: not convinced that this is useful no such capability in ISDN. Alan: want to focus on SIP usages and new SIP usages anybody creating a UUI application will need to write a draft and register the application. Andy Hutton: just realized this might be more than ISDN UUI, and that if others realized that there might be more people in the room. Open issue if the ISDN protocol discriminator as part of this discovery mechanism. Keith: this is no use for sip to ISDN because a GW would not know. Paul Kyzivat: thinks discriminator ought to be treated on a par with the application tag – that both serve to discriminate the syntax/semantics of the content. Discussion on REQ-11 on field length. Keith: this should be at most 128 for ISDN interwork. Alan: the limit should be application specific. Keith: this should be at most 128 for ISDN interwork. Alan: proposed to make the limit application specific, with the max of 128 for the ISDN application, regardless of whether ISDN is actually involved. Open issue on REQ-6 on minimizing reliance on extensions. Alan says this has been a bit controversy about this and he would be willing to drop it. Andy: would drop this. Kieth: seems like it is something we would do anyway without referring to the req. Alan: will check with the list that nobody loves this. Discussion on Security Considerations, need to decide whether to put security reqs here, or together with other reqs. Keith: there is similarity to info package, so we should look to see if there is anything to borrow from that. We should make it clear that we are leaving it up to the application to do. But then we discussed interwork to ISDN, where the only trust is the security of ISDN. Paul: don't push the responsibility for security to the applications as apps don't know the options. Keith: could do something similar to what is done for History-Info. Alan: it seems there is support for providing sec reqs in the document and should look at the INFO Package and the History-Info to see if they have relevant requirements. Will investigate and send potential requirements to this list. Leon Portman: is there a requirement for UUI to be added by intermediate nodes? Alan: yes but it might not be explicitly stated. Keith: this is again different to ISDN and means that when A calls B and is forwarded to C that B can insert UUI which finds its way to C this does impact security requirements. Mechanism for transporting UUI in SIP ------------------------------------- Alan presents the updated individual draft. Andy: do we have a requirement to include this info mid dialog? Alan: no this is restricted to INVITE and BYE could use INFO package for this if there are requirements. Hannu Hietalahti: is there an intent to restrict to INVITE? Alan: its just INVITE and BYE. Hannu: 3GPP has a similar mechanism that can be used in all call control. Will investigate what 3GPP has. Paul: could use INFO instead of this for BYE. Alan: the BYE is used because it can map to appropriate ISDN. Discussion on feature tags for application discovery. Paul: there are feature tags that don’t require any kind of RFC to define, which would lower the bar for applications using this. Discussion on alternatives of body or header and Cullen's idea to embed in SDP attribute. Andy: offerless invites could still require UUI, ruling out the SDP approach. Alan: believes the header field approach meets all the requirements. But security was mentioned as one that might present problems when using the header approach. Needs to be investigated. Hadriel Kaplan (from Jabber): why is this header more important than all the others? Alan: it has different security implications. Next steps: need to come to consensus on header vs body. Not calling for adoption today. Paul: requiring a RFC for specifying a purpose is clearing wrong if this relates to applications such as contact centre's which would need to identify the contact centre. Alan: the charter does not require that (verified with the charter text). Interworking ISDN call control user information with SIP -------------------------------------------------------- Keith presents the draft about ISDN interworking. Open issue: proposal to discard UUI without notification if cannot be conveyed in its full size. Open issue: proposal to discard non-ISDN UUI without notification. Open issue: multiple UUI. Alan: either you discard all, or else you discard all but one – with no clarity yet of which one. Keith: concerned that UUI inserted by middle box might be chosen, but that isn’t consistent with ISDN. Discussion about adoptin the draft. Keith: no need to rush. Alan: in favor. Paul: its premature. Open issue: what happens when we have SIP-T as well as UUI and there are conflicts does this need to be specified? Alan: cannot imagine doing both. Keith: every other draft created does not specify this (E.g. History-Info, PAI etc.). Will wait for the UUI mechanism to be updated before updating the ISDN interworking draft. Next steps and open discussion ------------------------------ Alan thinks he can rev the requirements draft in the next week or two, and the mechanism draft in a couple of weeks. But this will be a header-based approach. Expectation that the body approach will require someone in favor of it to submit a body-based mechanism. There was attempt to query if anyone was opposed to header based approach. Paul: cannot tell yet – it depends if a header based approach can successfully deal with the security concerns. Keith will update the interworking draft in a week or so after the mechanism draft has been revised. The working group will have a virtual interim meeting right before Christmas and periodic calls every three weeks (tentatively).