Notes for the first SIP session, 13:00 Monday 10 July 2006, at IETF 66.
Taken by Dale R. Worley.

* Agenda presented

* "Note Well" statement

* Chair polls

Question regarding the certs draft:  Is this leading toward implementation?
Consensus: Yes, several people are planning to implement it.

Question regarding the outbound draft:  Should it be revised?
Consensus: Responses were generally positive.

Question regrading the outbound draft:  Is it ready for WGLC?
Consensus:  The idea in the draft is good but there are open issues.

At this point the presenter projected a picture of a strikingly
flattened-looking squirrel on a flagstone patio.  After the audience
expressed some distress, he remarked that this is a natural
phenomenon, the temperature at the time was 45 C and the squirrel is
cooling its belly on the stones.

* Announcement of an effort to apply SIGCOMP to SIP.

* Outbound open issues, presented by Cullen Jennings

A proposed timer to avoid a DoS attach
	Consensus was not favorable.

How to discover STUN keep-alive support?
	Perceived need for an auto-discovery mechanism
		Consensus was to not worry about creating the mechanism now
	Perceived need for validating STUN keep-alive support in an
	outbound proxy by querying the proxy, independently of any
	configuration or advertising mechanism, to avoid trouble with
	the proxy if there is incorrect information about whether it
	supports STUN keep-alives.
		Proposal: Ignore this issue for the time being
		No objections

Presented various alternatives regarding what are adequate conditions
for a UA to send STUN keep-alives to a proxy
	Consensus was considerable support for the rule that
	"configuration information is enough to send STUN" but most
	would like some direct validation mechanism created

Chair noted that the most vigorous opinions on these topics were from
people not present at the meeting.

In regard to the general idea of using of STUN keep-alives outside of
the context of outbound.
	No objection

Regulation of the number of flows maintained by a UA
	Proposed reducing the requirement for the minimum number of
	flows from MUST to SHOULD
		Consensus:  Agreed - but there should be strong
		warnings in the RFC of the dangers of not adhering to
		the requirement.

Proposal: When UA adds a flow token per this I-D, it should add a URI
parameter to its registration requests so the Registrar can tell that
outbound mechanisms have been invoked (because the flow token does not
reach the Registrar).
	No conclusion.

In regard to re-registering with the same reg-id as used by a
previous, different registration.
	Proposal:  Should replace previous flow registration with same
	reg-id, rather than being additional to the previous flow
	(which is presumably defunct).
		Consensus:  No objections to this change.  Opinion was
		split between "MUST replace" and "SHOULD replace".  MUST
		has stronger support.

* Outbound-discovery, presented by Miguel Garcia for Erkki Koivusalo

Exposited known open issues:

	Should the discovery system reveal the number of flows to be
	maintained?

	How to allow various different schemes for terminating the redundant
	flows.

Noted with dismay the creeping dumping of SIP configuration information
into DNS.

Question: Should this I-D become a WG item?
	J. Rosenberg will write up description of alternative
	approaches, after which the issue will be discussed.

The chair noted that the most opinionated people on these issues were
not present at the meeting.

* Outbound Midcall Issues, presented by Kevin Johns

Explores enabling failover when middle boxes fail, and its interaction
with the outbound flow mechanism.

Question: Should this be a WG item?
Consensus is that the I-D remains individual, because there is no
consensus on the correct solution to this problem.

* Connection-reuse, presented by Vijay Gurbani

No contentious issues here.

* Domain-certificates, presented by Jason Fischl (ed: Actually, Vijay Gurbani)

There is a significant open issue regarding how SIP domains are to be
specified in certificates used by proxies for SSL.  This issue
interacts with practical issues regarding how certificates are
obtained, how SSL operates, and the intended security assertions of
SIPS/TLS.

The topic generated lots of spirited discussion, but no consensus.