Subject: [dispatch] DISPATCH @ IETF-87 Deadlines

From: Mary Barnes <[email-masked]>
Date: Tue, 18 Jun 2013 17:05:02 -0500

As a reminder, the deadline for letting the chairs know that you are
planning to submit something for consideration for the IETF-87
deadline is June 24th, 2013 (next Monday - 6 days time).   The
subsequent deadlines are also in the wiki:
http://tools.ietf.org/wg/dispatch/trac/wiki
Noting, that the draft deadlines are the same as the IETF draft deadlines.

Regards,
Mary
DISPATCH WG co-chair

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Fri, 21 Jun 2013 10:29:57 +0000

Hello Mary,
I would like the dispatch working group to consider two drafts at IETF-87 as follows:

1) http://www.ietf.org/id/draft-dawes-dispatch-logme-reqs-02.txt 
This draft was discussed at IETF-86 and has been updated with potential solutions to requirements (clause 7). I would like to propose that INSIPID adopt this work.
(from IETF-86 http://trac.tools.ietf.org/wg/dispatch/trac/wiki#)
•Logging: General support for adopting this work. Proposal to update INSIPID WG with a new deliverable. 
	◦Charter: http://www.ietf.org/mail-archive/web/dispatch/current/msg04560.html 
	◦Related documents: 
		■draft-dawes-dispatch-logme-reqs

2) http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-06.txt 
An informational RFC describing a header field parameter to distinguish security mechanisms that protect media (as opposed to those that protect signalling) between a UA and its first-hop SIP entity, and to create an IANA registry to list names of such media-specific security mechanisms.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 18 June 2013 23:05
To: DISPATCH
Cc: Cullen Jennings
Subject: [dispatch] DISPATCH @ IETF-87 Deadlines

As a reminder, the deadline for letting the chairs know that you are planning to submit something for consideration for the IETF-87

Regards,
Mary
DISPATCH WG co-chair
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jun 2013 11:41:38 -0400

Peter,

I'm fine with discussing this in dispatch.

My main concern with this is around REQ9 - locator of log collector server:

- how is the log collector designated? The examples show just a dns 
name. I would think it would need to be a URL. But what protocol would 
be used to transfer the log? Is it required that those supporting log-me 
also support specific protocol(s) for log collection? If there is more 
than one protocol, how will the entity inserting the log-me indicator 
decide which one? (There isn't any opportunity here to negotiate which 
one will be used.)

- This has security implications. How would the server sending the log 
decide if it can trust the specified server? Would it have a list of 
servers it trusts? This seems like a hard problem. And it may need to be 
solved for each protocol that might be used to transfer logs. It is 
glossed over in the security considerations.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Thu, 27 Jun 2013 12:04:54 -0500

>                 ■draft-dawes-dispatch-logme-reqs
[MB] Per the above, we dispatched that document at IETF-86 with the
recommendation that it be handled in the INSIPID WG. We saw no
concerns over that expressed on this mailing list post-IETF-86.  My
recommendation is that the discussion of this document (and whether a
new deliverable should be added to the INSIPID WG charter) should move
to the INISIPID WG mailing list. [/MB]
> An informational RFC describing a header field parameter to distinguish security mechanisms that protect media (as opposed to those that protect signalling) between a UA and its first-hop SIP entit…
[MB] At this point, it's not clear as to exactly why this is required
and why this needs to be in a SIP header field parameter as opposed to
SDP, for example.  Again, we need clear problem statements as opposed
to specific solutions for discussion. Since this appears to be based
on 3GPP requirements, Gonzalo will follow-up with you all to get more
details in that regards to further inform the DISPATCH chairs & ADs
decision. [/MB]