Re: [Gen-art] Genart last call review of draft-ietf-tsvwg-fecframe-ext-04
Alissa Cooper <alissa@cooperw.in> Thu, 11 October 2018 13:22 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F914130DE4; Thu, 11 Oct 2018 06:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=rOry2B2N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=efKvsQX4
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 th81kc8llpjR; Thu, 11 Oct 2018 06:22:05 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC79130E66; Thu, 11 Oct 2018 06:22:05 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 653E721D45; Thu, 11 Oct 2018 09:22:04 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 11 Oct 2018 09:22:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=g RCHrvSsyrMCILZlHhWjUwGeQ64mUvhyT4TI7lbUXVg=; b=rOry2B2NjJDXgKan7 CZIks3+u5JhkWP+xOkDOG6iza21hI5NRjFg0hG+taxeupXShQUGj+/8+7A6HQldi 6OI22H/uuaRVSiu7NTw9wsj7EW29X/udXvhLPTcRNKnaLEgYR5QJheptggjO/IKn Z0ZhwKyf08rgGZPymsWhoHPB8dUo3c2JerWKcVcpWLTMTlm6JGwNn2PRjlOKc7+C E/CVUItEGYaAo/aR5M1w4CpyIoVUqmT5m09b6hIh8u8I7FGc9JZ8XNo4ubMVAOgI MJC2F3myzL68p4KL7Yu+V8xGNUbctqb3R8anRx6VrPB26xirXrmmAvqgzw26gIRb nRH/A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=gRCHrvSsyrMCILZlHhWjUwGeQ64mUvhyT4TI7lbUX Vg=; b=efKvsQX4u4uYxys3GJ4OuPdGjOR9IklHY1Yh8Ue8dzYHCzOrgKjyNWgW+ v3mDwLxdYqDHRST7YdeSmSMugWqJiOAFe/tK5d8uendnvNyV/TWgClb5pX6uDTBw 4oWJxonhSsUTfWzH04/fB+QVzptknK5LDcWwYANeJsnZ1z4KOv/xVyFDt+OGbg2/ JFL/uhxIFIUo8Prt5XimJgJ0rfQegBz2EAjBkNeRyiQ+OOVNuSE1HTcYBP6425xA yYJIdECl7Kta0GGOdXjxO9UjGMA0kNizgncWCmez+dUrXq+K1bgAyvdUTIwD2sWR ORSCL9ORwrpXAwiVUOcjt9Ay0UQfQ==
X-ME-Sender: <xms:e06_W_eVw7sy_6Gp0o3r-R5pFdxlS8bsNNF73aa5RQFjZU9G7VWTIQ>
X-ME-Proxy: <xmx:e06_W0xUlG75N-E6OL9D6p3cnwCoFHNRRCAyfd7l1x0wV-WVHgaCPg> <xmx:e06_W4ciPSt9XwHVqVD3DgfE4-fGrgNLFvDqCWPbfnoKSbgACv091A> <xmx:e06_W4JGW2RKYsN4kFr7idPXl7kEwwuZu510SIl4ghzuFUcj64rh6A> <xmx:e06_WxFP1GGv2wVnUGcv-G9NXnh29dbAO1iniiY9uBbZSEcuCFMVvQ> <xmx:e06_W6rbsqWOGjEROuArpujDSFwzIoSJJqTup_JB5G_zrnPih5SJsQ> <xmx:fE6_W0Zy1Ha-cRvaGlywoKWnJHwX5DSQWM6eET6usugNQ-W83cCyzQ>
Received: from rtp-alcoop-nitro5.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 97B03E461E; Thu, 11 Oct 2018 09:22:02 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [Gen-art] Genart last call review of draft-ietf-tsvwg-fecframe-ext-04
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <BAF1776C-B207-45B7-A31A-A104EF81A186@inria.fr>
Date: Thu, 11 Oct 2018 09:22:00 -0400
Cc: draft-ietf-tsvwg-fecframe-ext.all@ietf.org, General Area Review Team <gen-art@ietf.org>, tsvwg@ietf.org, IETF list <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2E8475E-92A9-42A1-9F7B-9818C938F9E8@cooperw.in>
References: <153694236743.17692.10599342220445585312@ietfa.amsl.com> <BAF1776C-B207-45B7-A31A-A104EF81A186@inria.fr>
To: Vincent Roca <vincent.roca@inria.fr>, Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/dBxf-y84dEsOGrKcuTtF6j2FYkU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Oct 2018 13:22:08 -0000
Christer, thanks for your review. Vincent, thanks for your response. I entered a No Objection ballot. Alissa > On Sep 19, 2018, at 8:30 AM, Vincent Roca <vincent.roca@inria.fr> wrote: > > Hello Christer, > > Thanks a lot for the review. > >> Le 14 sept. 2018 à 18:26, Christer Holmberg <christer.holmberg@ericsson.com> a écrit : >> >> Reviewer: Christer Holmberg >> Review result: Ready with Nits >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> Document: draft-ietf-tsvwg-fecframe-ext-04 >> Reviewer: Christer Holmberg >> Review Date: 2018-09-14 >> IETF LC End Date: 2018-09-24 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: The document is well written, but there is an issue regarding backward >> compatibility that I want the authors to address. >> >> Major issues: >> >> Q1_MAJ: >> >> Regarding backward compatibility, it's difficult for me to parse the second >> bullet in Section 1. >> >> The text seems to assume that SDP, and RFC 6364, are used to negotiate FEC. >> But, RFC 6364 is only an informative reference, and I assume FEC does not even >> mandate SDP? >> >> Is there a generic requirement that the endpoints must negotiate the usage of >> this mechanism before it is used? Or, can the mechanism be used towards an >> endpoint that does not support it? > > You’re right, the use of SDP is not mandatory, I’ve used a shortcut that may be > wrong in some environments. In fact the only application I have in mind, 3GPP MBMS, > relies on SDP to carry the so-called « FEC Framework Configuration Information » that > includes the FEC Scheme identifier, hence the mistake. > Also, this is not, strictly speaking, a negotiation since there is usually no feedback. > The sender uses one or more FEC Scheme(s), the receiver chooses to join or not > (hopefully there will be a repair flow it can process). > > OLD: > o any receiver, for instance a legacy receiver that only supports > block FEC schemes, can easily identify the FEC Scheme used in a > FECFRAME session thanks to the associated SDP file and its FEC > Encoding ID information (i.e., the "encoding-id=" parameter of a > "fec-repair-flow" attribute, [RFC6364]). This mechanism is not > specific to this extension but is the basic approach for a > FECFRAME receiver to determine whether or not it supports the FEC > Scheme used in a given FECFRAME session; > > NEW: > o any receiver, for instance a legacy receiver that only supports > block FEC schemes, can easily identify the FEC Scheme used in a > FECFRAME session. This is made possible with the FEC Encoding ID > that identifies the FEC Scheme used and which is carried in the > FEC Framework Configuration Information (see section 5.5 of > [RFC6363]). For instance, when the Session Description Protocol > (SDP) is used to carry the FEC Framework Configuration > Information, the FEC Encoding ID can be communicated in the > "encoding-id=" parameter of a "fec-repair-flow" attribute > [RFC6364]. This mechanism is the basic approach for a FECFRAME > receiver to determine whether or not it supports the FEC Scheme > used in a given FECFRAME session; > > > >> Minor issues: >> >> N/A >> >> Nits/editorial comments: >> >> Q2_ED. >> >> The document uses "extends RFC 6363" terminology in a couple of places. I >> suggest to use "updates" instead. > > Agreed. Update is the right term. > > >> Q3_ED. >> >> Section 1 says: >> >> 'This document is fully backward compatible with [RFC6363] that it extends >> but does not replace." >> >> I don't think you need the "extends but does not replace" part. > > Done. > > Cheers, > > Vincent > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
- Genart last call review of draft-ietf-tsvwg-fecfr… Christer Holmberg
- Re: Genart last call review of draft-ietf-tsvwg-f… Vincent Roca
- Re: [Gen-art] Genart last call review of draft-ie… Alissa Cooper