• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: avtcore

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

2013-05-07 05:20 Colin Perkins

New revision available

2013-03-13 15:29 Cindy Morgan

Shepherding AD changed to Richard Barnes

2013-02-25 15:55 Colin Perkins

New revision available

2012-11-28 07:37 Robert Sparks

State changed to AD is watching from IESG Evaluation::AD Followup

2012-11-28 07:37 Robert Sparks

The working group is going to review these changes and re pub-req the document

2012-11-20 05:27 Sean Turner

[Ballot comment]
I cleared. Thank you for working through this.

2012-11-20 05:27 Sean Turner

[Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss

2012-11-19 15:04 Stephen Farrell

[Ballot comment]

Many many thanks for working through this. We finally got it!

2012-11-19 15:04 Stephen Farrell

[Ballot Position Update] Position for Stephen Farrell has been changed to Yes from Discuss

2012-11-19 14:51 Colin Perkins

New revision available

2012-11-14 06:33 Sean Turner

[Ballot discuss]
Updated based on -10 and discussions Stephen and I had followed by additional discussions Stephen had with the authors. Much of this comes down to our definition of profile and the srtp definition of profile being different. Stephen suggested the following text that we're hoping will do the trick:

BCP61 generally requires that IETF protocols specify mandatory
to implement (MTI) strong security and this clearly applies to
specifications of applications that make use of RTP. RTP itself
however specifies a framework rather than a specific application,
and given the variability described in this document, and the
set of currently available mechanisms [ref] no one set of MTI
security options can realistically be specified for all RTP
applications.

Existing RTP profiles [ref,ref] and payload formats [ref,ref]
do not specify such an interoperable usage and are therefore
neither secure in themselves, nor something to which BCP66
applies. Future similar documents need to explicitly state
this.

Current work on real time web [ref] and SIP [ref] does
however need to meet BCP61 and therefore such documents need
to specify MTI security. This is because such specifications
do fully specify interoperable applications that use RTP.

2012-11-14 06:33 Sean Turner

Ballot discuss text updated for Sean Turner

2012-10-26 12:00 Stephen Farrell

[Ballot discuss]

This review is of version -10 of the draft.
This is definitely on the right track.

1. section 2 says that there's too much variation to pick a
single MTI security or key mgmt scheme but I'm not
convinced that all the variations would preclude that if
taken individually, for example bandwidth is no big deal
here, nor is realiability, in fact the only thing that
really seems relevant for MTI security/key mgmt is
multicast vs. point-to-point. if I'm right about the above
then could we say that for RTP stacks that will mostly be
used for point-to-point applications, then SRTP SHOULD be
implemented so as to be usable for point-to-point
applications?

2. Section 5, 1st para: Can you give a non-security example
of what might cause non-interop for some use-cases? I mean
where the two implementations couldn't work together for
any configuration. (Which is what you're implying to
justify that they security implementations can be
non-interoperable.)

3. Last sentence of section 5 seems broken. Not sure I get
what its saying either.

4. Section 6 - why can't you say that RTP profiles SHOULD
specify MTI security? Surely if its possible then it ought
be done, and if not then it cannot, which adds up to
SHOULD.

5. Can you give an example of an RTP profile for which it
does not make sense to specify MTI security? I think at
least an existence proof is needed here.

2012-10-26 12:00 Stephen Farrell

Ballot discuss text updated for Stephen Farrell

2012-10-22 04:40 Colin Perkins

New revision available

2012-08-22 10:04 (System)

post-migration administrative database adjustment to the No Objection position for Russ Housley

2012-07-16 08:16 Colin Perkins

New revision available

2011-11-16 01:13 Magnus Westerlund

Submitted a long time for publication

2011-11-16 01:13 Magnus Westerlund

IETF state changed to Submitted to IESG for Publication from WG Document

2011-10-31 06:48 Russ Housley

[Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss

Viewing the last 20 entries. Show full log.