Minutes IETF98: avtcore
Audio/Video Transport Core Maintenance
||Minutes IETF98: avtcore
Avtcore: Audio/Video Transport Core Maintenance WG Meeting
Date and Time: Tuesday 28/03/17, Morning Session, 9:00-10:00
Room: Zurich A
Chairs: Jonathan Lennox / Rachel Huang
1. Note Well, Note Takers, Agenda Bashing - (Chairs, 9:00, 5 min)
Note takers: Bo Burman, Varun Singh
Jabber scribe: Magnus Westerlund
2. WG Status - (Chairs, 9:05, 5 min)
WG is now merged with AVTEXT WG, taking the name AVTCORE, which was
considered better for activity tracking reasons, instead of reverting
to the old AVT that would show years-old content.
In addition to RFC 8082 that is in the chair presentation, there are
two more drafts published as RFC since IETF 97; RFC 8083 RTP Circuit
Breakers and RFC 8108 RTP multistream.
Status of working group draft:
* draft-ietf-avtext-lrr [ready for WGLC]
* draft-ietf-avtcore-aria-sdes [In progress]
- Unclear why it requires standards track action. We want to
discourage use of SDES.
- Cullen strongly supports the current way forward and is
willing to argue for that with the IESG.
* draft-ietf-avtcore-aria-srtp [In progress; write-up finished]
* draft-ietf-avtcore-mprtp [In progress; need updates]
- Emil Ivov volunteers to review. Draft expires today; OK to
revive and make ref update.
* draft-ietf-avtcore-rfc5285-bis [AD evaluation]
- There's currently two comments that should be rather easy to
resolve (on the list).
- Magnus will make an update.
* Multiplexing guidelines
- Jonathan wonders if this is needed. Magnus (as author)
thinks that there's lack of energy to complete it, Colin
agrees (remotely), and the milestone should maybe be
dropped. There are a few documents that references it
draft-ietf-mmusic-sdp-simulcast, draft-ietf-payload-rtp-howto, and
draft-ietf-rtcweb-rtp-usage). Magnus will send a mail to the
list with information about how it is referenced. Roni will
talk to Magnus on possibility to complete it.
3. Chartered work:
Frame Marking RTP Header Extension (Mo Zanaty, 9:10, 20 min)
* Jonathan and Bernard argue that it seems there's not
sufficient information in the format for spatially scalable
streams and that it's hard to know if something is
missing. Mo comments that the draft says that higher numbers
indicate higher fidelity and that the numbers need not be
contiguous. Jonathan suggests that the document should
clearly state that it is discouraged to use this with complex
scalability structures. It should also be clarified that (for
any future codec definition using this) LRR framemarking MUST
use the same values as the codec, to be able to identify when
refresh has happened through frame marking. Move text on how
to frame mark VP9 into the VP9 draft, to avoid MISSREF to the
VP9 draft. When using correct framemarkings, a middlebox can
avoid sending data that it knows that the receiver cannot
make use of (e.g. because some dependency data is lost).
* There was a discussion on how to use framemarking with
bandwidth probing, but there was no consensus and discussion
will continue on the list.
4. Proposed new work:
DTLS/SRTP Registration for AES256-CTR (Jonathan Lennox, 9:30, 10
* Cullen believes that the decision to not have AES-256 in
draft-ietf-avt-srtp-big-aes was very deliberate, to reduce the
number of security options and minimize complexity.
* Magnus thinks it is reasonable to specify and register this.
* Harald A says that if someone uses it, it is better to have it
* Mo thinks it may be different to allow it in DTLS and in SRTP.
* Ben C suggests that we want to have people move to DTLS/SRTP.
* Cullen thinks that this proposal would lead to
non-interoperability, but only specification is required to
register with IANA, not an RFC.
* Ben notes that taking this on in the WG would take time and
effort, and seems not strictly to be needed.
* Magnus thinks that a specification is needed from some type of
Standards Definition Organization.
* Jonathan will talk to IANA about what is needed to register
5. Next steps and open mic - (Chairs, 9:40, 5 min)