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-avtcore-multi-media-rtp-session,
          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)
   *   draft-ietf-avtext-framemarking-04

   *   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
   min)

   *    draft-lennox-avtcore-dtls-srtp-bigaes-00

   *    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
        registered.

   *    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
        this.


5. Next steps and open mic - (Chairs, 9:40, 5 min)