Re: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

Sergio Garcia Murillo <> Mon, 14 September 2020 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F0C93A0ACD; Mon, 14 Sep 2020 10:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Arx0Y11u9DAG; Mon, 14 Sep 2020 10:27:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B99443A0D71; Mon, 14 Sep 2020 10:27:49 -0700 (PDT)
Received: by with SMTP id g4so514447wrs.5; Mon, 14 Sep 2020 10:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 [] ( []) by with ESMTPSA id q18sm21198428wre.78.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Sep 2020 10:27:47 -0700 (PDT)
To: Magnus Westerlund <>, "" <>, "" <>, "" <>
Cc: "" <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <>
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: [Sframe] [dispatch] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Sep 2020 17:27:53 -0000

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 

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