From nobody Wed May 25 07:44:57 2016 Return-Path: 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 C81DD12D176; Wed, 25 May 2016 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 iaFYzKJGNP7h; Wed, 25 May 2016 07:44:52 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4129C12D768; Wed, 25 May 2016 07:44:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.182.128; From: "Susan Hares" To: Date: Wed, 25 May 2016 10:44:45 -0400 Message-ID: <01b401d1b693$fb411810$f1c34830$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B5_01D1B672.74308980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdG2keUYwqsP4AJKSjCZY/xFiMIDqg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, zhang.xian@huawei.com, forces@ietf.org, Jonathan.Hardwick@metaswitch.com, draft-ietf-forces-interfelfb@tools.ietf.org, 'Jon Hudson' Subject: [forces] RTG-DIR review of ForCES Inter-FE LFB (draft-ietf-forces-interfelfb-04.txt) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 14:44:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B5_01D1B672.74308980 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello:=20 I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-forces-interfelfb-04.txt Reviewer: Susan Hares Date: 5/25/2016 IETF End Date: unknown=20 Intended Status: Standards track =20 Summary: This document is basically ready for publication, but has nits = that should be considered before publication.=20 =20 Comments:=20 =C2=B7 Document contains good technical content for extending = the Forces work into an Inter-FE LFB. The document is easily read, but = a few nits would improve its readability. =C2=B7 My hand check of the inter-FE LFB XML model indicated all = XML is fine. If an automated check of the XML with the Forces LFBs, it = would be useful to run this check. =20 =C2=B7 The improvement in the congestion consideration section = (5.1.3) between -03 and -04 was necessary. =20 =20 Major issues: none=20 =20 Nits:=20 Page 9 figure 5. =E2=80=93 the between figure lines is not aligned.=20 This line begins with the =E2=80=9CEthernet Frame with:=E2=80=9D=20 =20 Page 12 =E2=80=93=20 Old /(XXX: note to editor/ New /(XXX: note to RFC editor/ =20 Page 15=20 Old /original payload i.e. skips the IFE header information./ New /original payload (i.e. skips the IFE header information)/ =20 Page 21=20 =20 Old /This memo includes one IANA requests within the registry = https://www.iana.org/assignments/forces/ =20 New /This memo includes one IANA request within the registry = https://www.iana.org/assignments/forces. / =20 p. 22=20 Old /As such, it has no impact on their security considerations./ New/ As such, it has no impact on these documents security = considerations./ =20 Sue Hares=20 =20 =20 ------=_NextPart_000_01B5_01D1B672.74308980 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello: =

I have been selected as the = Routing Directorate reviewer for this draft. The Routing Directorate = seeks to review all routing or routing-related drafts as they pass = through IETF last call and IESG review, and sometimes on special = request. The purpose of the review is to provide assistance to the = Routing ADs. For more information about the Routing Directorate, please = see =E2=80=8Bhttp://trac.tools.ietf.org/area/= rtg/trac/wiki/RtgDir

Although these comments are = primarily for the use of the Routing ADs, it would be helpful if you = could consider them along with any other IETF Last Call comments that = you receive, and strive to resolve them through discussion or by = updating the draft.

Document: = draft-ietf-forces-interfelfb-04.txt

Reviewer: Susan Hares

Date: 5/25/2016

IETF End Date: unknown

Intended Status: Standards track

 

Summary: = This document is basically ready for publication, but has nits that = should be considered before publication.

 

Comments: =

=C2=B7         = Document contains good technical content = for extending the Forces work into an Inter-FE LFB. =C2=A0=C2=A0The = document is easily read, but a few nits would improve its = readability.

=C2=B7         = My hand check of the inter-FE LFB XML = model indicated all XML is fine.=C2=A0 If an automated check of the XML = with the Forces LFBs, it would be useful to run this check.=C2=A0 =

=C2=B7         = The improvement in the congestion = consideration section (5.1.3) between -03 and -04 was necessary.=C2=A0 =

 

Major issues: none

 

Nits: =

Page 9=C2=A0 figure 5. =E2=80=93 the = between figure lines is not aligned.

This line begins with the =E2=80=9CEthernet Frame = with:=E2=80=9D

 

Page 12 = =E2=80=93

Old

/(XXX: note to editor/

New /(XXX: note to RFC editor/

 

Page 15 =

Old /original payload i.e. skips the = IFE header information./

New = /original payload (i.e. skips the IFE header = information)/

 

Page 21

 

Old

/This memo = includes one IANA requests within the registry https://www.iana.org/as= signments/forces/

 

New

/This memo = includes one IANA request within the registry = https://www.iana.org/assignments/forces. /

 

p. 22 =

Old /As such, it has no impact on = their security considerations./

New/ = As such, it has no impact on these documents security = considerations./

 

Sue Hares =

 

 

------=_NextPart_000_01B5_01D1B672.74308980-- From nobody Wed May 25 15:03:38 2016 Return-Path: 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: From: Alia Atlas To: draft-ietf-forces-interfelfb@ietf.org, Evangelos Haleplidis , "forces@ietf.org" Content-Type: multipart/alternative; boundary=001a113e60baf831df0533b1d769 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 22:03:36 -0000 --001a113e60baf831df0533b1d769 Content-Type: text/plain; charset=UTF-8 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 --001a113e60baf831df0533b1d769 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 woul= d like to thank Jamal and Damascene for their hard work on this final docum= ent and really improving it.

Evangelos, thank you = for shepherding this document.=C2=A0 Please do update the shepherd's re= port.=C2=A0 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.
<= br>
While I do have some minor comments from my most recent revie= w, I believe that these can all be fixed during IETF Last Call.=C2=A0 Pleas= e 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 i= ssues.

With the expectation that any issues found = in IETF Last Call will be dealt with rapidly, I am placing this =C2=A0on th= e telechat for June 16.

Minor:

a)In Sec 5.2: =C2=A0"Ethertype 0xFEFE is to be used (XXX: Note t= o editor, likely
=C2=A0 =C2=A0 =C2=A0 we wont get that value - update wh= en available)." =C2=A0 PLEASE update this to be Ethertype TBA1 is to b= e used.=C2=A0 Then in IEEE assignment considerations, specify that the Ethe= rType TBA1 requires allocation & possibly indicate that an experimental= value of 0xFEFE has been used.=C2=A0 Is that one of the playpen EtherTypes= available?

b) In Sec 6.1.1: =C2=A0Similarly, it s= ays "If IFETYPE is absent then the standard
=C2=A0 =C2=A0 =C2=A0 In= ter-FE LFB Ethernet type is used (XXX: Note to editor, to be=C2=A0updated).= "
Please update to TBA1 and add a reference to the IEEE Assi= gnment Considerations section.

c) In Sec 6.1.1: &q= uot;Encapsulate each allowed Metadatum in a TLV. Use the Metaid as
=C2= =A0 =C2=A0 =C2=A0 the "type" field in the TLV header.=C2=A0 The T= LV should be aligned to
=C2=A0 =C2=A0 =C2=A0 32 bits.=C2=A0 This means y= ou may need to add padding of zeroes to
=C2=A0 =C2=A0 =C2=A0 ensure alig= nment."
Trivial, but please clarify that the padding of zero= es is added at the end of the TLV.

d) In Sec 6.1.2= :=C2=A0"If an=C2=A0unknown Metadatum id is encountered, or if the meta= id is not in
=C2=A0 =C2=A0 =C2=A0 the allowed filter list the implementa= tion is expected to ignore
=C2=A0 =C2=A0 =C2=A0 it, increment the packet= error statistic and proceed processing
=C2=A0 =C2=A0 =C2=A0 other Metad= atum."
Can you please clarify if the "packet error stat= istic" is incremented once per unknown Metadatum or metaid - or once p= er packet that has such a metadatum?=C2=A0 The field description makes me t= hink it is once per packet.=C2=A0 Knowing the excitement that exists around= computing worst-case number of counter increments per packet, I hope so.= =C2=A0

It would also be useful to indicate which c= omponentID is mentioned - since this is normative.

Nit:

1) Figure 6: =C2=A0the title should be "= ;Packet format definition" and not "Packet format suggestion"= ;.=C2=A0 This needs wording for a standard :-)

2) = Sec 5.2: "However, at the time of publication we believe
=C2=A0 =C2= =A0 =C2=A0 this is sufficient to carry all the info we need and approach=C2=A0 =C2=A0 =C2=A0 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,
A= lia
--001a113e60baf831df0533b1d769-- From nobody Thu May 26 04:29:42 2016 Return-Path: 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 3001612DA6B for ; Thu, 26 May 2016 04:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.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 AGssHNY-tmHs for ; Thu, 26 May 2016 04:29:39 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 AD16912DDDE for ; Thu, 26 May 2016 04:29:33 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id 90so35671518qgz.1 for ; Thu, 26 May 2016 04:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sOxpiXzLdbM0EALfWR5zJ1ttB00y6mmH1CoTQ1Zc0lY=; b=yjb8dmPTitX6VYcHpuYzHogQIuxAFCeF03fQLUr/JN7HcI4JfAubAGxjovdVCdY2xP nBdKijtyBp9eNTHH+PNnI2b6TdE0NZffROEIIfV7CH0YyJFWNt+X04q3VyvRDFp1+LBH nc5IAqco7iyAuS+CJ6agk8kLjzohN2MLzxyOPwIzzTfcGlrz+fH8YpY/Z/sZCO7KxjXU zN3EBUDcpKdcq3xMzFkIq7xCXyE5ijBLVKmuMK55nALXzfk8AcaCk8u59+TYLQ79RTWK 4KCESYl5Ia1iHA2i4bQpoUFsXgnnesY+OWieq4eNnPjPzIIjnPDcyNnJWWaHxbLKYPTy O2RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sOxpiXzLdbM0EALfWR5zJ1ttB00y6mmH1CoTQ1Zc0lY=; b=NRiaWYFHbZDNcmSkeezzsRCh3UoU62eWdaETz0njMvtUW11S/T8dxNwKqmk0ktb4jJ nGSVdia1BcjX091QHR6Y/sBTlXVhRDIQAXcAZBiFz8nuBGwDYNX8AjUgPFbpoIDJj5TB ripL7B3UkemAwfGKYLDdz/hGRuqfaswUICLn5Jl29FgX6umKEBkQ0lxNfrbooaX408kB /nYyUSqboEGdd7wY7BkEyiXO2gCJLLJ4K1x0/+snSnjAuWhmLbi/YdOzXBcH6VZyxWN0 tc7+4iZ7dA7WPfAI6hUiX37ml/BEHrVLrUd7/bjB/X/7hSL2ySmAEYGoYABa4CNlWj/1 8x4w== X-Gm-Message-State: ALyK8tKpgCb+pXuis86pZo8UDZboc7n2pNlbD0r1j47xXYQiWhVEL4hdXV/dhwLxIK4xIk3K4ygKi7DKIs/NZQ== X-Received: by 10.140.166.3 with SMTP id m3mr8417600qhm.100.1464262172615; Thu, 26 May 2016 04:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.195 with HTTP; Thu, 26 May 2016 04:29:12 -0700 (PDT) In-Reply-To: <01b401d1b693$fb411810$f1c34830$@ndzh.com> References: <01b401d1b693$fb411810$f1c34830$@ndzh.com> From: Jamal Hadi Salim Date: Thu, 26 May 2016 07:29:12 -0400 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a11393f74a85bb20533bd1a18 Archived-At: Cc: "rtg-dir@ietf.org" , zhang.xian@huawei.com, "" , draft-ietf-forces-interfelfb@tools.ietf.org, Jonathan Hardwick , "forces@ietf.org" , Jon Hudson Subject: Re: [forces] [RTG-DIR] RTG-DIR review of ForCES Inter-FE LFB (draft-ietf-forces-interfelfb-04.txt) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:29:41 -0000 --001a11393f74a85bb20533bd1a18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sue, Appreciate the review. All your suggested changes will be reflected in version 5 (which i hope we will get out by worst case the weekend). cheers, jamal On Wed, May 25, 2016 at 10:44 AM, Susan Hares wrote: > Hello: > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-forces-interfelfb-04.txt > > Reviewer: Susan Hares > > Date: 5/25/2016 > > IETF End Date: unknown > > Intended Status: Standards track > > > > Summary: This document is basically ready for publication, but has nits > that should be considered before publication. > > > > Comments: > > =C2=B7 Document contains good technical content for extending the > Forces work into an Inter-FE LFB. The document is easily read, but a fe= w > nits would improve its readability. > > =C2=B7 My hand check of the inter-FE LFB XML model indicated all = XML > is fine. If an automated check of the XML with the Forces LFBs, it would > be useful to run this check. > > =C2=B7 The improvement in the congestion consideration section (5= .1.3) > between -03 and -04 was necessary. > > > > Major issues: none > > > > Nits: > > Page 9 figure 5. =E2=80=93 the between figure lines is not aligned. > > This line begins with the =E2=80=9CEthernet Frame with:=E2=80=9D > > > > Page 12 =E2=80=93 > > Old > > /(XXX: note to editor/ > > New /(XXX: note to RFC editor/ > > > > Page 15 > > Old /original payload i.e. skips the IFE header information./ > > New /original payload (i.e. skips the IFE header information)/ > > > > Page 21 > > > > Old > > /This memo includes one IANA requests within the registry > https://www.iana.org/assignments/forces/ > > > > New > > /This memo includes one IANA request within the registry > https://www.iana.org/assignments/forces. / > > > > p. 22 > > Old /As such, it has no impact on their security considerations./ > > New/ As such, it has no impact on these documents security considerations= ./ > > > > Sue Hares > > > > > --001a11393f74a85bb20533bd1a18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sue,

Appreciate the review. All your suggested changes will be refl= ected in
version 5 (which i hope we will ge= t out by worst case the weekend).

cheers,
jamal

On Wed, May 25, 2016 at 10:44 AM, Susan Hares <shares@nd= zh.com> wrote:

Hello: <= u>

I have been selected as the Routing Directorate reviewer f= or this draft. The Routing Directorate seeks to review all routing or routi= ng-related drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide assis= tance to the Routing ADs. For more information about the Routing Directorat= e, please see=C2=A0=E2=80=8Bhttp= ://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing A= Ds, it would be helpful if you could consider them along with any other IET= F Last Call comments that you receive, and strive to resolve them through d= iscussion or by updating the draft.

Document: draft-ietf-forces-interfelfb-04.txt

Reviewer: Susan Hares

Date: 5/25/2016

IETF End Date= : unknown

Intended Status: Standar= ds track

=C2=A0

Summary: This document is basically ready for publicat= ion, but has nits that should be considered before publication. <= /u>

=C2=A0

Comments:

= =C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Docu= ment contains good technical content for extending the Forces work into an = Inter-FE LFB. =C2=A0=C2=A0The document is easily read, but a few nits would= improve its readability.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = My hand check of the inter-FE LFB XML model indicated all XML is fin= e.=C2=A0 If an automated check of the XML with the Forces LFBs, it would be= useful to run this check.=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The improvement in the congestion consideration section (5.1= .3) between -03 and -04 was necessary.=C2=A0

= =C2=A0

Major issues: none

=C2=A0

Nit= s:

Page 9=C2=A0 figure 5. =E2=80= =93 the between figure lines is not aligned.

This line begins with the =E2=80=9CEthernet Frame with:=E2=80=9D=

=C2=A0

Page 12 =E2=80=93

O= ld

/(XXX: note to editor/=

New /(XXX: note to RFC editor/=

=C2=A0

P= age 15

Old /original payload i.e. = skips the IFE header information./

= New /original payload (i.e. skips the IFE header information)/

=C2=A0

= Page 21

=C2=A0

Old

/This memo= includes one IANA requests within the registry https://www.iana.org/assignment= s/forces/

=C2=A0<= /p>

New

/This= memo includes one IANA request within the registry https://www.iana.org/assignm= ents/forces. /

=C2=A0=

p. 22

Old /As such, it has no impact on their security considerations./=

New/ As such, it has no impact on these d= ocuments security considerations./

= =C2=A0

Sue Hares

=

=C2=A0

=C2=A0


--001a11393f74a85bb20533bd1a18-- From nobody Thu May 26 04:39:35 2016 Return-Path: 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 B495E12D650 for ; Thu, 26 May 2016 04:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mojatatu-com.20150623.gappssmtp.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 GY_hPJRrU2rV for ; Thu, 26 May 2016 04:39:30 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 1A46E12DE1A for ; Thu, 26 May 2016 04:39:29 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id x7so55748749qkd.3 for ; Thu, 26 May 2016 04:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vDqeKChFm8XkaRGZcAbHeQFFq8A/wJyr3wGBgihhjUc=; b=XCnIeo4Nj9EXJcLaLYDp6P3DX5kktd9E6nrhvG3qYK4p/axB2Co+EXMwtiFcVJ5JPi DpE04sBv4RVtObZgr8RRXZfzZq0vHHw9Snqfj5udpw7FFrGPUmcuGPAMikh7PghXdMMY kBG10na8Lu1pWTBJ4l2PDtQqxbA10gkTMLt7K3Dbt3x1UiTGjAbsf5+9RfJ+EOAyn3i0 I42DxfVGEtpxffFXER0hMJGsGQA4NzK1dg5qERiluep7575o6TwOxTBeDXr3Dg+MX0tY rugNgNdcp40UiPj5XA/nz7h9wOqR3QoNU/u6HkzBATdI4es7zLxxiS20GetJ1WY1twZn iN8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vDqeKChFm8XkaRGZcAbHeQFFq8A/wJyr3wGBgihhjUc=; b=D6unGigDKzKxHBFdsvWBhkUPv++FOT5UmO5IiviKHCYnebsXVUTvug+KarS4S5tL/b xTc6CfYngNobcuv/JUlyVzxh9mFRIyolG01eN1/3njx1kgEA7EAbSCBdvmcc6Nu/+Lei tIUyndBEUjBLvpJ5fRt7XvSf6kWkyme4TNjbxQqgL162Qyl0nB/Qx0vlFowxshLzMoGy 0cgf8czxgR7bkUyZyXibpVG2NTwiJC6TRMDjB5M7mTPjYqibtZwwXc06A/sk8Q+e4saW l17NooSPWz56W5br9fgw4yyPgFMIM9k1/i9mzAcVuQ6tiX0a35fd+3qz4H25QNrT4yka TOoQ== X-Gm-Message-State: ALyK8tLoaFYSGsMWk1D9Cs7S91oBGF2vjX/MAfIXyHVI9KRPoNX5TXFyPnAcz0IIo7LRF0PdfoWaTN91uSCcSA== X-Received: by 10.55.39.140 with SMTP id n134mr8644329qkn.10.1464262768081; Thu, 26 May 2016 04:39:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.195 with HTTP; Thu, 26 May 2016 04:39:07 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Thu, 26 May 2016 07:39:07 -0400 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=94eb2c095a7c26716b0533bd3ef9 Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-interfelfb@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 11:39:33 -0000 --94eb2c095a7c26716b0533bd3ef9 Content-Type: text/plain; charset=UTF-8 Hi Alia, On Wed, May 25, 2016 at 6:03 PM, Alia Atlas wrote: > > 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. > > We wouldnt have gone this far without your dilligence to details. Thank you. > 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. > > Some responses to your comments below and then we can proceed to updating and publishing. > 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? > OxFEFE is not one of the available playpen EtherTypes. We ended enforcing the user to specify it in the deployed tools (on Linux). So people ended using different values none of which will stick. Once this value is issued we'll make it the default. Would be an easy 1-2 line patch. 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. > > Will do. > 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. > > Will do. > 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. > > The current deployment is _per metaid_;-> But i think it makes sense to make it per packet. It is a trivial change. I can update the doc to make it per-packet and then patch Linux version. Would that be fine with you? > It would also be useful to indicate which componentID is mentioned - since > this is normative. > > Parse error. Which componentID? Nit: > > 1) Figure 6: the title should be "Packet format definition" and not > "Packet format suggestion". This needs wording for a standard :-) > > ;-> Will fix. > 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." > > Will fix. Alia, a pleasure as always - worth the wait to see your comments. cheers, jamal > Regards, > Alia > --94eb2c095a7c26716b0533bd3ef9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia,

On Wed, May 25, 2016 at 6:03 PM, Alia Atlas &= lt;akatlas@gmail.com= > wrote:

=
As is customary - particularly with an AD sponsored draft, I have done= a final review before requesting that this document proceed to IETF Last C= all.

First, I would like to thank Jamal and Damasc= ene for their hard work on this final document and really improving it.


We wouldnt have gon= e this far without your dilligence to details. Thank
you.
=C2=A0
Evangelos,= thank you for shepherding this document.=C2=A0 Please do update the shephe= rd's report.=C2=A0 I know it has been a couple years but many on the IE= SG do read the entire shepherd's report and it needs to be up to date.<= /div>

While I do have some minor comments from my most r= ecent review, I believe that these can all be fixed during IETF Last Call.= =C2=A0 Please do so ASAP; draft numbers are cheap and it is highly advantag= eous to have folks reading the most recent version so they don't pick o= n the same issues.


Some responses to your comments below and then we can proceed to
updating and publishing.=C2=A0
=C2=A0
=
With the expectation that any issues found= in IETF Last Call will be dealt with rapidly, I am placing this =C2=A0on t= he telechat for June 16.

Minor:

a)In Sec 5.2: =C2=A0"Ethertype 0xFEFE is to be used (XXX: Note = to editor, likely
=C2=A0 =C2=A0 =C2=A0 we wont get that value - update w= hen available)." =C2=A0 PLEASE update this to be Ethertype TBA1 is to = be used.=C2=A0 Then in IEEE assignment considerations, specify that the Eth= erType TBA1 requires allocation & possibly indicate that an experimenta= l value of 0xFEFE has been used.=C2=A0 Is that one of the playpen EtherType= s available?

OxFEFE is not one = of the available playpen =C2=A0EtherTypes. We ended
enforcing the= user to specify it in the deployed tools (on Linux).
So people e= nded using different values none of which will stick. Once
this v= alue is issued we'll make it the default. Would be an easy 1-2
line patch.

=
b) In Sec 6.1.1: =C2=A0Similarly, it says "If IFETYPE is ab= sent then the standard
=C2=A0 =C2=A0 =C2=A0 Inter-FE LFB Ethernet type i= s used (XXX: Note to editor, to be=C2=A0updated)."
Please up= date to TBA1 and add a reference to the IEEE Assignment Considerations sect= ion.


Will do.
=C2=A0
c) In= Sec 6.1.1: "Encapsulate each allowed Metadatum in a TLV. Use the Meta= id as
=C2=A0 =C2=A0 =C2=A0 the "type" field in the TLV header.= =C2=A0 The TLV should be aligned to
=C2=A0 =C2=A0 =C2=A0 32 bits.=C2=A0 = This means you may need to add padding of zeroes to
=C2=A0 =C2=A0 =C2=A0= ensure alignment."
Trivial, but please clarify that the pad= ding of zeroes is added at the end of the TLV.


Will do.
=C2=A0
d) In Sec 6.1.2:=C2=A0"If an=C2= =A0unknown Metadatum id is encountered, or if the metaid is not in
=C2= =A0 =C2=A0 =C2=A0 the allowed filter list the implementation is expected to= ignore
=C2=A0 =C2=A0 =C2=A0 it, increment the packet error statistic an= d proceed processing
=C2=A0 =C2=A0 =C2=A0 other Metadatum."
Can you please clarify if the "packet error statistic" is incr= emented once per unknown Metadatum or metaid - or once per packet that has = such a metadatum?=C2=A0 The field description makes me think it is once per= packet.=C2=A0 Knowing the excitement that exists around computing worst-ca= se number of counter increments per packet, I hope so.=C2=A0

=

The current deployment is _per= metaid_;->=C2=A0
But i think it makes sense to make it per pa= cket. It is a trivial change.
I can update the doc to make it per= -packet and then patch Linux version.
Would that be fine with you= ?
=C2=A0
I= t would also be useful to indicate which componentID is mentioned - since t= his is normative.


Parse error.=C2=A0 Which=C2=A0componentID?

Nit:

1) Fi= gure 6: =C2=A0the title should be "Packet format definition" and = not "Packet format suggestion".=C2=A0 This needs wording for a st= andard :-)


;->= ; Will fix.
=C2=A0
=
2) Sec 5.2: "However, at the time of publication we believe=
=C2=A0 =C2=A0 =C2=A0 this is sufficient to carry all the info we need a= nd approach
=C2=A0 =C2=A0 =C2=A0 taken would save us 4 bytes per Metadat= um transferred."

Please reword as for a s= tandard (e.g. "...need; this approach has been selected because it sav= es 4 bytes per metadatum transferred."


Will fix.

Alia, a plea= sure as always - worth the wait to see your comments.

<= div>cheers,
jamal
=C2=A0
Regards,
Alia

--94eb2c095a7c26716b0533bd3ef9--