From nobody Mon Sep 14 10:27:59 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C93A0ACD; Mon, 14 Sep 2020 10:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arx0Y11u9DAG; Mon, 14 Sep 2020 10:27:50 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99443A0D71; Mon, 14 Sep 2020 10:27:49 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id g4so514447wrs.5; Mon, 14 Sep 2020 10:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dvlmBUJL3BL4rf9dUddHCNTln4PU/ybhi8Xlml5bBmQ=; b=OFdImHvgK1OnWC6J6L6cgDbkm9OpjdZ4MypLJ8MSmR0yO0/5w+8ITLUNrpsEQ1BY3M gkpJHcfSw/rjKqAh8MUroF0Ros+mMo0793sOGbaLnU7RFjQFBdXVz5Q63gEgD3CAphAJ GshCygliOk+oHKmPhon+n4imajrwMn48Yt4xKoAisE7IrqBworznx0kqSO5K8PHX1bJg +n3q0/Hl8sBzDtoBYjwVBh2jVnLluuEailBGKqxLsa96tU5/ldqx0bG0DHLYZZDKO0tP ELxXgrEmAUxVyXFPbTTyrAIpq1YKKZh7tXbpxGS9W4X7hCbP/f/GhifAj3bN6nKW7UDs 4qBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dvlmBUJL3BL4rf9dUddHCNTln4PU/ybhi8Xlml5bBmQ=; b=SgKBUzeu+AkWoqqP6OcpSv65Bwg7ZxV6BKIqRkhbpzVBVAcrqqPAUXF45jxLoA/WjK L4+o+pVRBbz000ED3CfIBOetiKu3sW+MJUQWNqyYJW4pdIwvH+Tw8DdBO3ERU/LvDUUM z0/TIsofPH7p/wbAvWRvFoNwbgqpYfoRMyCmp6eVINFBBH/NAyiTUntOPjD4iS0Imles +cI5szzaRlZbHBK+Kk/S3/+q1E2g2oW+zVOkrTvMIwx9PgnTnBaIdFMzf3EqFJOncRnk YA+c1P0i4LmN89RcehU1yrn6vIJiFaJb8Ko1T3GWwsozMg6SLizYuRtYPG0guOw96Gwu kCDg== X-Gm-Message-State: AOAM533H8AQixDlBq0Ku+h/9foJFXC8yq5cvpWNbeBsPti8Tr94FETMk Zi7urzobmSz4WegaeK9jyl3pwz7BrwXbcw== X-Google-Smtp-Source: ABdhPJxoqDFs2P2gA/pEZnaY12pRm/9bJtXtaoBBgTiKrdZBNlBrIQQaDt2fO36ve3WOIzcNP4Czfg== X-Received: by 2002:a05:6000:12c3:: with SMTP id l3mr17973964wrx.164.1600104467904; Mon, 14 Sep 2020 10:27:47 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id q18sm21198428wre.78.2020.09.14.10.27.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 10:27:47 -0700 (PDT) To: Magnus Westerlund , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "rlb@ipv.sx" , "sergio.garcia.murillo@cosmosoftware.io" Cc: "dispatch@ietf.org" , "iesg@ietf.org" , "sframe@ietf.org" References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> From: Sergio Garcia Murillo Message-ID: Date: Mon, 14 Sep 2020 19:27:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A6220C6C449DF6DA458D35E4" Content-Language: en-US Archived-At: Subject: Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 17:27:53 -0000 This is a multi-part message in MIME format. --------------A6220C6C449DF6DA458D35E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 14/09/2020 16:12, Magnus Westerlund wrote: > Sergio, > > Having 20 years of experience with RTP payload format designs some of your > formulations made me a bit worried. After this discussion I think we are much > closer on a common understanding of the high level functionality necessary. > > However, there will be questions about where we document that interaction and > what dependencies that do exist on other specificaitons for scalable codecs that > are generic and is desirable to require from RTP middleboxes. In addition even > without RTP there will be need from the application to consider how it can > utilize one SFRAME key and its IVs to carry multiple application sub-streams and > the need to expose that to lower layer transport function to achiveve > performance goals. What I fail to understand is the nature of your concerns and how should we address them on the charter: * Is it something that we plan to do that is not covered in the charter? * Is it something that we don't plan to do but the charter is wide enough to allow it? * Is it something that we plan to do and it is covered in the charter but you don't agree to it? * Is it something that we don't plan to do and is neither covered by the charter and we should add it? > So I think some clarification on the RTP payload format work, and it that is > going to happen in the SFRAME WG. If happening in SFRAME WG I would like to have > a joint WG Last call with AVTCORE WG. I raised that question already a couple of times. I am not sure what is the role of the SFRAME WG regarding specifying a new RTP codec-agnostic payload. IMHO this WG should collect the requirements, match them to current specifications, and if anything is missing, liaise with the appropriate groups in order to produce the specs based on our requirements. Best regards Sergio --------------A6220C6C449DF6DA458D35E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 14/09/2020 16:12, Magnus Westerlund wrote:
Sergio,

Having 20 years of experience with RTP payload format designs some of your
formulations made me a bit worried. After this discussion I think we are much
closer on a common understanding of the high level functionality necessary. 

However, there will be questions about where we document that interaction and
what dependencies that do exist on other specificaitons for scalable codecs that
are generic and is desirable to require from RTP middleboxes. In addition even
without RTP there will be need from the application to consider how it can
utilize one SFRAME key and its IVs to carry multiple application sub-streams and
the need to expose that to lower layer transport function to achiveve
performance goals.


What I fail to understand is the nature of your concerns and how should we address them on the charter:

  • Is it something that we plan to do that is not covered in the charter?
  • Is it something that we don't plan to do but the charter is wide enough to allow it?
  • Is it something that we plan to do and it is covered in the charter but you don't agree to it?
  • Is it something that we don't plan to do and is neither covered by the charter and we should add it?


So I think some clarification on the RTP payload format work, and it that is
going to happen in the SFRAME WG. If happening in SFRAME WG I would like to have
a joint WG Last call with AVTCORE WG.


I raised that question already a couple of times. I am not sure what is the role of the SFRAME WG regarding specifying a new RTP codec-agnostic payload.

IMHO this WG should collect the requirements, match them to current specifications, and if anything is missing, liaise with the appropriate groups in order to produce the specs based on our requirements.

Best regards

Sergio

--------------A6220C6C449DF6DA458D35E4--