[Sip] Draft SIP minutes for IETF 74 posted

[Dean Willis <[e-mail]>]

See:
http://www.softarmor.com/mediawiki/index.php/Minutes_for_SIP_at_IETF_74

A text-paste follows (original has HTML markup for clarity).

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

Minutes for SIP at IETTF 74Session 1, SIPCORE-like topicsAgenda  
BashLed by Chairs
Slides presented and included in minutes
Agenda accepted as presented.

SIP Forum configuration profile work mentioned, interested people  
invited to Wednesday breakfast.

Current status of WG documents reviewed.

Topic: SIP Change Process IntroLed by: Jon Peterson
draft-peterson-rai-rfc3427bis-01
Slides presented and included in minutes
Reviewed IETF LC status of RFC32427bis and invited comments at IETF  
level.

Issue: SIPCORE scope
Spencer Dawkins suggested that the charter text should include  
discussion about ADs being able to make judgement calls on SIPCORE  
charter items as needed.

Issue: DISPATCH scope
Discussion centered on defining the deliverables of SIPCORE and the  
need to get small things done somewhere.

Issue: Deliverables of DISPATCH
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.

Issue: Where to do small work items
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.

Issue: Time required to launch a new WG
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.

Issue: P-headers and Existing Work In Progress
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.

Topic: Early Dialog terminationLed by: Christer Holmberg
draft-ietf-sip-199-02
Slides presented and included in minutes
Some discussion occurred on reliable transmission and B2BUA  
interactions. There was apparently a long on-list discussion that  
resulted in the current text.

ISsue: Are we ready for WGLC?
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.

Topic: 3261 Interop StatementLed by: Robert Sparks
draft-sparks-sip-3261-interop-statement-00
No slides presented.
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.

Topic: 3261 Normative ReferencesLed by: Robert Sparks
draft-sparks-sip-3261-norm-ref-status-00
No slides presented.
Status of work was presented, with no discussion or issues noted from  
attendees.

Topic: Fix INVITE transactionLed by: Robert Sparks
draft-sparks-sip-invfix-03
Slides presented and included in minutes
Theo Zourzouvillys will be acting as editor for this document.

Issue: Does the increase in state size (for accepted) break things?
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.

Topic: RFC 4244bisLed by: Francois Audet
draft-barnes-sip-rfc4244bis-00
draft-rosenberg-sip-target-uri-delivery-00
Slides presented and included in minutes
Initial discussion reviewed the changes to the document, and discussed  
whether resolving the security concerns of RFC 4244 are in-scope.

Issue: Naming semantics
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.

Issue: Marking History-Info Entries
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.)

Issue: Progress 4244bis, target-uri draft, or both?
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.

Topic: Info EventsLed by: Eric Burger
draft-ietf-sip-info-events-03
Slides presented and included in minutes
Issue: 489
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.

Issue: Where to allow/disallow Recv-info processing?
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.

Session 2, DISPATCH-like topicsTopic: SIP VIa CookiesLed by: Theo  
Zourzouvillys
draft-zourzouvillys-sip-via-cookie-02
Slides presented and included in minutes
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.

Topic: Keepalive Without OutboundLed by: Christer Holmberg
draft-holmberg-sip-keep-03
Slides presented and included in minutes
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.

Topic: Secure Call IDLed by: Hadriel Kaplan
draft-kaplan-sip-secure-call-id-00
Slides presented and included in minutes
A great deal of discussion ensued, with very little in the way of  
recognizable notes, or for that matter, recognizable progress, being  
made.


Having a recognizer in the call identifier
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.

Issue: Changing the ABNF
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.

Topic: Session IDLed by: Hadriel Kaplan
draft-kaplan-sip-session-id-01
Slides presented and included in minutes
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.

Topic: User to User for ISDNLed by: Alan Johnston
draft-johnston-sipping-cc-uui-07
Slides presented and included in minutes
Issue: Do we need INFO-style meta-information
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.

Issue: Header vs. body?
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.


Topic: Batch NOTIFYsLed by: Alan Johnston
draft-johnston-sipping-batch-notify-00
Slides presented and included in minutes
The room seems to have a consensus that more discussion at the  
requirements level is needed before we get into mechanism.

Topic: Context-ID RequirementsLed by: Salvatore Loreto
draft-loreto-sipping-context-id-requirements
Slides presented and included in minutes
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.

Topic: Changes to Referred-ByLed by: Salvatore Loreto
draft-loreto-sipping-3892bis-01
Slides presented and included in minutes
Issue: Including multiple P-Asserted-Identity values in Referred-By
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.

Topic: Updates to the Updates to Asserted Identity in SIPLed by:  
Hadriel Kaplan
draft-kaplan-sipping-pai-responses-00
Slides presented and included in minutes
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.

Topic: Digest Relay AttackLed by: Raphael Coeffic
draft-state-sip-relay-attack-00
Slides presented and included in minutes
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."

Meeting concluded