[forces] AD review of draft-ietf-forces-interfelfb
Alia Atlas <akatlas@gmail.com> Wed, 25 May 2016 22:03 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: forces@ietfa.amsl.com
Delivered-To: forces@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63E312DDBF; Wed, 25 May 2016 15:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 uh8BO0ETrK3A; Wed, 25 May 2016 15:03:34 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 C8C1212DDCE; Wed, 25 May 2016 15:03:30 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id n63so45822013qkf.0; Wed, 25 May 2016 15:03:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=a9RLAmap6jgpEQjouSuP4LPNvtVzJULZTNu/N92COc8=; b=C/bqQTjGsr8amIGlhsZCdhofGmiGqNVJwC6PzocPvcGMLGY/csUkGH6OGBXSemiAKm VYuEes7+r3SQsV+btkhH45T8K1bBBCRgNGkP6UTpNKKPMNFRPrcMBH1UG4bDj2lvJ/W+ RxM8JV0ug6FLrmjQCqX+2WPAaiohaRsDqob49Q9NKELduAlga1z2fWQ4xvVW6X24EVqj 8BhE0qBo0g50LAkgM4mDtgaoWSxClZzcDO13Fr7GNNZSiGGNHyoCP69yxrXBl3UJql+B ucJGdov2dIl9uyHJLjK2e7w7TMAzcjyS8wVSEw2g9wCjbe7wTNyEBuKrjbXNBei2ZSEW P9fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=a9RLAmap6jgpEQjouSuP4LPNvtVzJULZTNu/N92COc8=; b=VX+1As6b4lYW8C2FJy//Z/fA6uwF8VIyVCk+qE8KRyM3yZhcJ0WhHQLsOx3+GoGEk6 4L0cuiP1wORXSht0VbOoqrhV0Xs6rVJrugE6GtebATI0orpBVDD4S25QhHN0RLAfTK0v 3OJdKM+70ubkz7/Ab09/8oI2skCjv5ZThpZ83V94fiZosXXiDOO7EsInvFTt5iJI+l3R le1LC7jYBu0GVT+46dgaV6WdJDmoYHRDJf2M0rS3q7nAyHH3kO+aBxmq9R6hXtCSt1J5 w1RHW4C+8x+ww4gCwLzS0YSfrr3U2sV1Gqk+0x/Qz2c9BKBrxEWprWChUnqIV42EKokB OY6A==
X-Gm-Message-State: ALyK8tJc9V+1kknsxDJQ7cVTHlJlVPLMN6g4t5JNZ6BeJ0wfamUC60Gtt2SVoQvkaAm/vtzhfOMo1wLCNdULvA==
MIME-Version: 1.0
X-Received: by 10.37.83.131 with SMTP id h125mr3697684ybb.109.1464213809145; Wed, 25 May 2016 15:03:29 -0700 (PDT)
Received: by 10.13.221.74 with HTTP; Wed, 25 May 2016 15:03:29 -0700 (PDT)
Date: Wed, 25 May 2016 18:03:29 -0400
Message-ID: <CAG4d1rfi7BNVkSXSZvXfuemz-Nuz3R+jHjT63_0xJ5tU+WmbwQ@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: draft-ietf-forces-interfelfb@ietf.org, Evangelos Haleplidis <ehalep@gmail.com>, "forces@ietf.org" <forces@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e60baf831df0533b1d769"
Archived-At: <http://mailarchive.ietf.org/arch/msg/forces/fB2vwgn63PN-hi8lRoP_1EQb250>
Subject: [forces] AD review of draft-ietf-forces-interfelfb
X-BeenThere: forces@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: ForCES WG mailing list <forces.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/forces>, <mailto:forces-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/forces/>
List-Post: <mailto:forces@ietf.org>
List-Help: <mailto:forces-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/forces>, <mailto:forces-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2016 22:03:36 -0000
As is customary - particularly with an AD sponsored draft, I have done a final review before requesting that this document proceed to IETF Last Call. First, I would like to thank Jamal and Damascene for their hard work on this final document and really improving it. Evangelos, thank you for shepherding this document. Please do update the shepherd's report. I know it has been a couple years but many on the IESG do read the entire shepherd's report and it needs to be up to date. While I do have some minor comments from my most recent review, I believe that these can all be fixed during IETF Last Call. Please do so ASAP; draft numbers are cheap and it is highly advantageous to have folks reading the most recent version so they don't pick on the same issues. With the expectation that any issues found in IETF Last Call will be dealt with rapidly, I am placing this on the telechat for June 16. Minor: a)In Sec 5.2: "Ethertype 0xFEFE is to be used (XXX: Note to editor, likely we wont get that value - update when available)." PLEASE update this to be Ethertype TBA1 is to be used. Then in IEEE assignment considerations, specify that the EtherType TBA1 requires allocation & possibly indicate that an experimental value of 0xFEFE has been used. Is that one of the playpen EtherTypes available? b) In Sec 6.1.1: Similarly, it says "If IFETYPE is absent then the standard Inter-FE LFB Ethernet type is used (XXX: Note to editor, to be updated)." Please update to TBA1 and add a reference to the IEEE Assignment Considerations section. c) In Sec 6.1.1: "Encapsulate each allowed Metadatum in a TLV. Use the Metaid as the "type" field in the TLV header. The TLV should be aligned to 32 bits. This means you may need to add padding of zeroes to ensure alignment." Trivial, but please clarify that the padding of zeroes is added at the end of the TLV. d) In Sec 6.1.2: "If an unknown Metadatum id is encountered, or if the metaid is not in the allowed filter list the implementation is expected to ignore it, increment the packet error statistic and proceed processing other Metadatum." Can you please clarify if the "packet error statistic" is incremented once per unknown Metadatum or metaid - or once per packet that has such a metadatum? The field description makes me think it is once per packet. Knowing the excitement that exists around computing worst-case number of counter increments per packet, I hope so. It would also be useful to indicate which componentID is mentioned - since this is normative. Nit: 1) Figure 6: the title should be "Packet format definition" and not "Packet format suggestion". This needs wording for a standard :-) 2) Sec 5.2: "However, at the time of publication we believe this is sufficient to carry all the info we need and approach taken would save us 4 bytes per Metadatum transferred." Please reword as for a standard (e.g. "...need; this approach has been selected because it saves 4 bytes per metadatum transferred." Regards, Alia
- Re: [forces] AD review of draft-ietf-forces-inter… Evangelos Haleplidis
- [forces] AD review of draft-ietf-forces-interfelfb Alia Atlas
- Re: [forces] AD review of draft-ietf-forces-inter… Jamal Hadi Salim