Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt

Vincent Roca <vincent.roca@inria.fr> Thu, 26 July 2018 18:11 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0E4131193 for <tsvwg@ietfa.amsl.com>; Thu, 26 Jul 2018 11:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
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 iEzz7j5QjmjT for <tsvwg@ietfa.amsl.com>; Thu, 26 Jul 2018 11:11:28 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAF913123D for <tsvwg@ietf.org>; Thu, 26 Jul 2018 11:11:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.51,406,1526335200"; d="scan'208";a="340412001"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.119]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2018 20:11:26 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936301F1A7A@MX307CL04.corp.emc.com>
Date: Thu, 26 Jul 2018 20:11:25 +0200
Cc: Vincent Roca <vincent.roca@inria.fr>, Wesley Eddy <wes@mti-systems.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4A7B93E-E9C8-4390-A2B7-D666DC78A1B5@inria.fr>
References: <153251220347.15477.4964875960468719912@ietfa.amsl.com> <02E6BC9D-2A8C-4489-BA31-7DB0F0195F0E@inria.fr> <afeb6e10-2086-eb2f-0acb-4116c7ea0858@mti-systems.com> <F4EFE9F5-C1B0-44CD-93EC-D108FF025443@inria.fr> <CE03DB3D7B45C245BCA0D24327794936301F1A7A@MX307CL04.corp.emc.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2WlAbS1w4yC_XAS8jBgI_bMkpRo>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2018 18:11:39 -0000

Hello David,

> Le 25 juil. 2018 à 17:20, Black, David <David.Black@dell.com> a écrit :
> 
>> I don’t know what « updates RFC 6363 » implies exactly. If « updates »
>> implies « replaces » then the
>> answer is no. RFC 6363 will remain as is, without any change, we just add a
>> new capability to it.
> 
> Here, "updates" means "extends or modifies."    Looking at the two drafts, there appear to be two different outcomes.
> 
> 1) The fecframe-ext draft clearly extends the RFC 6363 framework.   In addition, Section 5.3 definitely modifies RFC 6363, as indicated by the first paragraph in that section:
> 
>   The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply
>   to this FECFRAME extension and are not repeated here.  An exception
>   though is the "full specification of the FEC code", item (4), that is
>   specific to block FEC codes.  The following item (4) applies in case
>   of Sliding Window FEC schemes:
> 
> So, it looks like the fecframe-ext draft need an "Updates: 6363" header,

I now fully agree.

> and the draft will need a section summarizing changes to RFC 6363 - at least the section 5.3 change, and also identifying any normative text in RFC 6363 that doesn't apply to Sliding Window Codes.

I realize the above text you quote is ambiguous. 

In fact Item (4) of RFC 6363 remains untouched but should be understood
as specific to block codes (it’s not indicated in RFC 6363 title of course).

In addition to that, this document adds what could be identified as 4-bis.

NEW:
   4-bis.  A full specification of the Sliding Window FEC code

I’ll clarify it in a future update.


> 2) In contrast, the rlc-fec-scheme draft appears to use the RFC 6363 framework as extended by the fecframe-ext draft without modifying that framework.  If that is correct, it does not need an "Updates: 6363" header, as all the changes & extensions to RFC 6363 ought to be in the fecframe-ext draft.

Exactly, the RLC FEC Scheme does not update anything.

Thanks for the feedback and guidance.

   Vincent