Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

Roman Danyliw <rdd@cert.org> Tue, 18 June 2019 09:23 UTC

Return-Path: <rdd@cert.org>
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 B8255120074; Tue, 18 Jun 2019 02:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 N-VZAQfJHuVM; Tue, 18 Jun 2019 02:23:36 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 D194912000E; Tue, 18 Jun 2019 02:23:35 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5I9NYuD005448; Tue, 18 Jun 2019 05:23:34 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x5I9NYuD005448
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1560849814; bh=Fk7Vgf5W6JDapiUWPNBExYKdWiIlboi7e06MoyERaBc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=gIDhQaMDnMyA23xnv9kzZzEp1OVgUEjKYmDB7oXiI0Uyjb1ntlY76/wEtGJCOu4hs Hn+vfPg40+E9gj6xrldRC1ZG9xzdlnMVA+ANLA2DarOeO6+NGsC71pH5XCK4b1xBG9 wrS1YOSwzR9lsUFBu5nqBarisAup6K+PQMQMiO4k=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5I9NXlJ021017; Tue, 18 Jun 2019 05:23:33 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Tue, 18 Jun 2019 05:23:32 -0400
From: Roman Danyliw <rdd@cert.org>
To: Vincent Roca <vincent.roca@inria.fr>
CC: The IESG <iesg@ietf.org>, "draft-ietf-tsvwg-rlc-fec-scheme@ietf.org" <draft-ietf-tsvwg-rlc-fec-scheme@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "Benjamin Kaduk" <kaduk@MIT.EDU>
Thread-Topic: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)
Thread-Index: AQHVFde/aAoeGJm/QEO9wocH49MKcaaYi6GAgAFFd6CAB6q+AP//xwqg
Date: Tue, 18 Jun 2019 09:23:32 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33996F9@marathon>
References: <155910443990.25705.3545445265076552985.idtracker@ietfa.amsl.com> <110B6170-C8DA-4CEA-9A11-C4D787EF0A93@inria.fr> <359EC4B99E040048A7131E0F4E113AFC01B33926C6@marathon> <40DD3EA0-CAD9-4EAF-BB42-559378AA0EA0@inria.fr>
In-Reply-To: <40DD3EA0-CAD9-4EAF-BB42-559378AA0EA0@inria.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B33996F9marathon_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/oh9AnTT7g4EVkBbRNnrM6QwMqH0>
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 18 Jun 2019 09:23:38 -0000

Hello!

From: Vincent Roca [mailto:vincent.roca@inria.fr]
Sent: Tuesday, June 18, 2019 4:46 AM
To: Roman Danyliw <rdd@cert.org>;; Benjamin Kaduk <kaduk@MIT.EDU>;
Cc: Vincent Roca <vincent.roca@inria.fr>;; The IESG <iesg@ietf.org>;; draft-ietf-tsvwg-rlc-fec-scheme@ietf.org; tsvwg@ietf.org; tsvwg-chairs@ietf.org
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

Hi Roman, Benjamin, all,

Back to the RLC I-D.
I have copied below the Discuss/Comments made for the -14 version of the document.

Many thanks, the document quality has been further improved.
Cheers,

   Vincent and Belkacem

===

> Roman Danyliw Discuss
> Discuss (2019-05-28)
>
> A few code nits for Section 3.6 so that the code compiles:
> ** To make the combination of this source code and that in draft-ietf-tsvwg-tinymt32 compile requires that the directive “#include <string.h>” be added (for the memset).
>
> ** The final return in Section 3.6 is missing a semicolon:
> s/return 0/return 0;/

[VR] Done. I usually don't add system headers to focus on key aspects, but it does not hurt. And thanks for the ";".

===

> Comment (2019-05-28)
>
> (1) Section 3.5  Is there any guidance that needs to be provided on the value of the seed to tinymt32_init?

[VR] Good point. Anything is accepted, which is now clearly stated. Since we already discuss Repair_Key management (this repair_key is used as seed), we refer to section 6.1.

NEW:
   With the FEC Schemes defined in this document, the seed is in
   practice restricted to a value between 0 and 0xFFFF inclusive (note
   that this PRNG accepts a seed value equal to 0), since this is the
   Repair_Key 16-bit field value of the Repair FEC Payload ID
   (Section 4.1.3).  In practice, how to manage the seed and Repair_Key
   values (both are equal) is left to the implementer, using a
   monotonically increasing counter being one possibility (Section 6.1).


> (2) Section 3.6.  In the code comments for cc_nb, I recommend explicitly stating:
> s/number of entries in the table/
> number of entries in the cc_tab[] table/

[VR] Done.


> (3) Section 3.6.  Multiple C code fragments are used in the text.  Somewhere the text should state that the examples are C code and made a reference to what version -- consider C99 (ISO/IEC 9899:1999), C11 (ISO/IEC 9899:2011), C18 (ISO/IEC 9899:2018).

[VR] Yes. I added the same C99 normative reference as in the TinyMT32 I-D
and included some text to clearly state it. I did it for both Sections, 3.5
and 3.6.

NEW (3.6):
   Figure 3 shows the reference generate_coding_coefficients()
   implementation.  This is a C language implementation, written for C99
   [C99].


> (4) Other References Nits
> Section 1.  Please include a reference for FECFRAME on first introduction.

[VR] Done.

> Section 1.1.  What is the reference for Raptor/RaptorQ?

[VR] Added RFC6681.


> (6) Editorial Nits
> Abstract.  No references are permitted in the abstract

[VR] Removed.

> Section 1.1.  Multiple Typos.  s/either a end-/either an end-/g
> Section 1.2.  Extra space. s/constraints) ./constraints)./
> Section 1.4.  Multiple Typos.  s/signalling/signaling/g
> Section 6.2.  Typo.  s/Section Section 3.6/Section 3.6/

[VR] Done. Thanks.

[Roman] Thank you for making these changes.  They address all of my feedback.

Regards,
Roman