Minutes edited by Dean Willis based on notes from Shida Schubert, James Swan, Spencer Dawkins, and Roni Even
Agenda accepted as presented.
SIP Forum configuration profile work mentioned, interested people invited to Wednesday breakfast.
Current status of WG documents reviewed.
Reviewed IETF LC status of RFC32427bis and invited comments at IETF level.
Spencer Dawkins suggested that the charter text should include discussion about ADs being able to make judgement calls on SIPCORE charter items as needed.
Discussion centered on defining the deliverables of SIPCORE and the need to get small things done somewhere.
Agreed that DISPATCH will deliver neither Proposed Standards nor protocol specifications. Deliverables might include problem statements, draft charters, or work plans for non-WG BOFs such as was used for the media security requirements work. DISPATCH will not work like TSVWG, and will not act as a "product manager" serving requirements to the SIPCORE "engineers", but may direct work items towards working groups without placing any requirement on that WG to actually do the work.
It is envisioned that mall work items can be done in BOF-like formats or through individual efforts, and pushed through as AD-sponsored non-WG drafts.
We do not expect a mechanism whereby requirements can be brought into a DISPATCH meeting and result in a new WG formed at the next IETF meeting. Rather, the traditional BOF process is anticipated to apply.
Several in-process drafts define p-headers. This will proceed without change. Further new work will NOT define p-headers; rather each header will be tagged as to its status in the registry.
Some discussion occurred on reliable transmission and B2BUA interactions. There was apparently a long on-list discussion that resulted in the current text.
Chair noted that previous WGLC resulted in many new issues, and that he would like to see closure on those issues before renewing the last call. Chair is to make a new call on-list, and if there are no reports of remaining open issues, the chair will issue a new WGLC.
Proposed that the reference document will be placed on-line and maintained as a living document. Also proposed that the interop statement document can be used to build an evaluation tool for use at SIPit. No objections to this approach were noted.
Status of work was presented, with no discussion or issues noted from attendees.
Theo Zourzouvillys will be acting as editor for this document.
Robert noted that much of draft was driven by working implementations at SIPit, so this is not expected to be a major issue. However, it should be noted that this approach does significantly increase the amount of transaction state kept in proxies.
Initial discussion reviewed the changes to the document, and discussed whether resolving the security concerns of RFC 4244 are in-scope.
We have a number of names like retargeting, rerouting, etc. in use. Agreed that we need to have a more precise and semantically appropriate terminology for tagging.
An extended discussion developed on what H-I is used for, what the scope of our chartered work here is, and so on. It was noted that our scope here is to address the requirement to deliver the initial request-URI target to the UAS, which is required in 800-number translation (free-dial) services. (editors note: This is only true is the PSTN model is maintained; when not doing PSTN interworking, there are many other ways to approach such alias operations, including per-alias GRUU minting.)
In the absence of a clear consensus, the chairs proposed that both documents proceed and we'll hope that further discussion gives us a consensus.
Noted that while we agree that the content of the INFO itself does not directly change the state of the SIP machine, that protocol operations at the SIP level (such as cseq numbers and failure conditions) certainly do change the SIP state machine's state.
We agree that processing Recv-Info in 100 messages doesn't make a lot of sense. We do not seem to have a use case for Recv-Info in PRACK/PRACK-2xx or REFER, but currently see no real reason to forbid its use there.
Chair polled room for WGLC-readiness, and it seems that most people believe the draft is essentially ready.
Discussion showed a strong interest in the work, and a general consensus that switching to TCP is not an acceptable solution to the problems raised. Further discussion on approach and attack-prioritization is to be deferred to the list.
Presentation focused on use cases and requirements. It is not clear from the presentation whether there have been requirements changes since the preceding version. The author expects to submit a revised draft that will address all the use cases, so further discussion os deferred to the list after posting of the revised draft.
A great deal of discussion ensued, with very little in the way of recognizable notes, or for that matter, recognizable progress, being made.
It was proposed that the "new safe identifier" have some sort of recognizer token, so that SBCs could easily decide not to change it. This proposal was rejected, on the grounds that some UAs today send "safe" call-ids that do not need to be changed, but that do not contain the proposed recognizer token.
Noted that changing the ABNF is not nadvisable, as this might cause some picky nodes to reject legacy messages. This guidance may be better constructed as a "best practice."
Further discussion deferred to list.
Extended discussion focused on the use case and relationship to Call-ID. Further discussion centered on whether SBCs can be presumed to leave anything lone -- after all, many strip unknown headers already. Further discussion was deferred to the list.
Alan argues that no negotiation on data types is needed if this is requested to only ISDN-style user-to-user data. However, many participants seemed to believe that if the header is there, somebody will use it for something new, and we'll be back to where we were with non-negotiated INFO usages and having to guess about whether the other party understands the payload.
Proposed mechanism is to put the data in a SIP header, whereas our traditional approach to these sorts of things is to use a MIME body. There seemed to be a lack of consensus about this approach in the room.
The room seems to have a consensus that more discussion at the requirements level is needed before we get into mechanism.
Noted that this may be the tip of the iceberg for a larger body of disaggregated media work that we may need to address, and this raises many interesting questions. Further discussion is needed on-list.
Noted that we need to understand what a receiver does with multiple identity expressions. Also noted that if multiple identities make sense for P-Asserted-Identity, they may make sense for Referred-By.
No conclusion noted.
Noted by chair Dean That the current model "no identity in responses" was driven by security review on the initial work, and that changing to allow use in responses requires overcoming the objections raised at that time, which primarily relate to authentication of responses.
Discussion revealed that there may be use cases, specifically around draft-ietf-sip-outbound, where separate authentication of responses may not be required, and that this mechanism was not available at the time RFC 3325 was developed.
Further discussion was deferred to the list.
Initial discussion focused on the threat model in the draft and how this relates to message authentication.
Authors noted that Section 4 is weak and they may wish to remove it.
Chair noted that the question should be "Are these attacks important enough to describe them in BCP, and determine if we have interest in addressing them."