From nobody Fri Jul 31 12:47:24 2015 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6921E1A9045; Fri, 31 Jul 2015 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 P4dDEs2zXJcv; Fri, 31 Jul 2015 12:47:21 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 BE2EE1A8BB2; Fri, 31 Jul 2015 12:47:18 -0700 (PDT) Received: by obbop1 with SMTP id op1so61544333obb.2; Fri, 31 Jul 2015 12:47:18 -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:cc:content-type; bh=S3y+z2svjk1iVLg7FLLntafhdOeWZMEyzjjC2RQAGWI=; b=teaCXceJuQzpcIYldmkj3yheiZcJctIbzc0W7UQ0qSExerCTTjfi3AM9zERb/0hPKb 3ORK24In6X1ZQl52ogwYTvl05X/kt/jKXTa9wsoMZQF6VTPmTD4tIFTXJXQtEs9VWsZA azfrmFXcNcM8DSdShUDVBNVwsnzGhhPokEhL8+ENvhMEjaSnf10TuErE/CllrtcAq9BJ 7Ks+mrccDs3BWIfI2TGwOKrx9DB3aw/NAhw1qRQbIebq5AqW/xiaY29t3eHmGnJgh2RD 7YDdnmFNT51fZE5Te9P7BQavV6LZZvhljtehJQPPVULVR9X8N04a618ju9emFWFLhstW cJeA== MIME-Version: 1.0 X-Received: by 10.60.45.104 with SMTP id l8mr5463473oem.61.1438372038292; Fri, 31 Jul 2015 12:47:18 -0700 (PDT) Received: by 10.60.41.99 with HTTP; Fri, 31 Jul 2015 12:47:18 -0700 (PDT) Date: Fri, 31 Jul 2015 15:47:18 -0400 Message-ID: From: Alia Atlas To: draft-ietf-forces-lfb-subsidiary-management@ietf.org, "forces@ietf.org" Content-Type: multipart/alternative; boundary=089e0149ce3865b960051c31161e Archived-At: Cc: "Joel M. Halpern" Subject: [forces] AD review of draft-ietf-forces-lfb-subsidiary-management-01 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 19:47:23 -0000 --089e0149ce3865b960051c31161e Content-Type: text/plain; charset=UTF-8 Hi Bhumip, Evangelos, and Jamal, Thanks for your work on this draft. As is customary, I have done my AD review of the draft before asking that it go forward to IETF Last Call. I have only a few quibbles, so I have advanced this to IETF Last Call. It is on the IESG telechat on Sept 3. Please do respond and update the draft during IETF Last Call. As you well know, having authors who are extremely responsive helps greatly with getting these final steps done. Minor quibbles: 1) In Sec. 4.4.3, two of the capabilities are described as placeholders. Can you please clarify what the expected standardized behavior is? I imagine that the capabilities are filled out as described - though with unstandardized information. 2) In Sec. 4.2, could you please provide a reference to the syslog severity levels? For instance, the IANA registry ( http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-2 ) and/or RFC 3164 would be lovely. 3) In the Security Considerations section, a few words about why it is ok to trust a CE to create a connection to another CE would be useful. Thanks, Alia --089e0149ce3865b960051c31161e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bhumip, Evangelos, and Jamal,

Thanks for your wo= rk on this draft. As is customary, I have done my AD review of the draft be= fore asking that it go forward to IETF Last Call.

I have only a few = quibbles, so I have advanced this to IETF Last Call.=C2=A0 It is on the IES= G telechat on Sept 3. =C2=A0 =C2=A0Please do respond and update the draft d= uring IETF Last Call.=C2=A0 As you well know, having authors who are extrem= ely responsive helps greatly with getting these final steps done.

Mi= nor quibbles:

1) In Sec. 4.4.3, two of the capabilities are describe= d as placeholders.=C2=A0 Can you please clarify what the expected standardi= zed behavior is?=C2=A0 I imagine that the capabilities are filled out as de= scribed - though with unstandardized information.

2) In Sec. 4.2, co= uld you please provide a reference to the syslog severity levels?=C2=A0 For= instance, the IANA registry (http://www.ian= a.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-paramete= rs-2 ) and/or RFC 3164 would be lovely. =C2=A0

3) In the Securit= y Considerations section, a few words about why it is ok to trust a CE to c= reate a connection to another CE would be useful. =C2=A0

=
Thanks,
Alia
--089e0149ce3865b960051c31161e-- From nobody Fri Jul 31 13:05:55 2015 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E59E1B32B9; Fri, 31 Jul 2015 13:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 OBMEBUh9ho1O; Fri, 31 Jul 2015 13:05:52 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743A11B351F; Fri, 31 Jul 2015 13:05:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 439DF74002C; Fri, 31 Jul 2015 13:05:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.61.100.75] (mobile-166-171-057-070.mycingular.net [166.171.57.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 5CDEA1C0455; Fri, 31 Jul 2015 13:05:51 -0700 (PDT) Date: Fri, 31 Jul 2015 16:05:48 -0400 Message-ID: Importance: normal From: "jmh.direct" To: Alia Atlas , draft-ietf-forces-lfb-subsidiary-management@ietf.org, "forces@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_3880676985862850" Archived-At: Cc: "Joel M. Halpern" Subject: Re: [forces] AD review of draft-ietf-forces-lfb-subsidiary-management-01 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 20:05:54 -0000 ----_com.samsung.android.email_3880676985862850 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhhbmtzIEFsaWEuIMKgVGhvc2UgYWxsIGxvb2sgbGlrZSBnb29kIGNhdGNoZXMuWW91cnMsSm9l bAoKClNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBTwq4gNiwgYW4gQVQmVCA0RyBMVEUgc21h cnRwaG9uZS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogQWxpYSBBdGxh cyA8YWthdGxhc0BnbWFpbC5jb20+IApEYXRlOiAwNy8zMS8yMDE1ICAzOjQ3IFBNICAoR01ULTA1 OjAwKSAKVG86IGRyYWZ0LWlldGYtZm9yY2VzLWxmYi1zdWJzaWRpYXJ5LW1hbmFnZW1lbnRAaWV0 Zi5vcmcsIGZvcmNlc0BpZXRmLm9yZyAKQ2M6ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhh bHBlcm4uY29tPiAKU3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZm9yY2VzLWxmYi1z dWJzaWRpYXJ5LW1hbmFnZW1lbnQtMDEgCgpIaSBCaHVtaXAsIEV2YW5nZWxvcywgYW5kIEphbWFs LAoKVGhhbmtzIGZvciB5b3VyIHdvcmsgb24gdGhpcyBkcmFmdC4gQXMgaXMgY3VzdG9tYXJ5LCBJ IGhhdmUgZG9uZSBteSBBRCByZXZpZXcgb2YgdGhlIGRyYWZ0IGJlZm9yZSBhc2tpbmcgdGhhdCBp dCBnbyBmb3J3YXJkIHRvIElFVEYgTGFzdCBDYWxsLgoKSSBoYXZlIG9ubHkgYSBmZXcgcXVpYmJs ZXMsIHNvIEkgaGF2ZSBhZHZhbmNlZCB0aGlzIHRvIElFVEYgTGFzdCBDYWxsLsKgIEl0IGlzIG9u IHRoZSBJRVNHIHRlbGVjaGF0IG9uIFNlcHQgMy4gwqAgwqBQbGVhc2UgZG8gcmVzcG9uZCBhbmQg dXBkYXRlIHRoZSBkcmFmdCBkdXJpbmcgSUVURiBMYXN0IENhbGwuwqAgQXMgeW91IHdlbGwga25v dywgaGF2aW5nIGF1dGhvcnMgd2hvIGFyZSBleHRyZW1lbHkgcmVzcG9uc2l2ZSBoZWxwcyBncmVh dGx5IHdpdGggZ2V0dGluZyB0aGVzZSBmaW5hbCBzdGVwcyBkb25lLgoKTWlub3IgcXVpYmJsZXM6 CgoxKSBJbiBTZWMuIDQuNC4zLCB0d28gb2YgdGhlIGNhcGFiaWxpdGllcyBhcmUgZGVzY3JpYmVk IGFzIHBsYWNlaG9sZGVycy7CoCBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoYXQgdGhlIGV4cGVj dGVkIHN0YW5kYXJkaXplZCBiZWhhdmlvciBpcz/CoCBJIGltYWdpbmUgdGhhdCB0aGUgY2FwYWJp bGl0aWVzIGFyZSBmaWxsZWQgb3V0IGFzIGRlc2NyaWJlZCAtIHRob3VnaCB3aXRoIHVuc3RhbmRh cmRpemVkIGluZm9ybWF0aW9uLgoKMikgSW4gU2VjLiA0LjIsIGNvdWxkIHlvdSBwbGVhc2UgcHJv dmlkZSBhIHJlZmVyZW5jZSB0byB0aGUgc3lzbG9nIHNldmVyaXR5IGxldmVscz/CoCBGb3IgaW5z dGFuY2UsIHRoZSBJQU5BIHJlZ2lzdHJ5IChodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz L3N5c2xvZy1wYXJhbWV0ZXJzL3N5c2xvZy1wYXJhbWV0ZXJzLnhodG1sI3N5c2xvZy1wYXJhbWV0 ZXJzLTIgKSBhbmQvb3IgUkZDIDMxNjQgd291bGQgYmUgbG92ZWx5LiDCoAoKMykgSW4gdGhlIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGEgZmV3IHdvcmRzIGFib3V0IHdoeSBpdCBp cyBvayB0byB0cnVzdCBhIENFIHRvIGNyZWF0ZSBhIGNvbm5lY3Rpb24gdG8gYW5vdGhlciBDRSB3 b3VsZCBiZSB1c2VmdWwuIMKgCgpUaGFua3MsQWxpYQo= ----_com.samsung.android.email_3880676985862850 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlRoYW5rcyBBbGlhLiAmbmJz cDtUaG9zZSBhbGwgbG9vayBsaWtlIGdvb2QgY2F0Y2hlcy48L2Rpdj48ZGl2PllvdXJzLDwvZGl2 PjxkaXY+Sm9lbDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1 JTtjb2xvcjojNTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgU8KuIDYsIGFuIEFU JmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXpl OjEwMCU7dGV4dC1hbGlnbjpsZWZ0O2NvbG9yOiMwMDAwMDAiPi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogQWxpYSBBdGxhcyAmbHQ7YWthdGxhc0BnbWFpbC5jb20m Z3Q7IDxicj5EYXRlOiAwNy8zMS8yMDE1ICAzOjQ3IFBNICAoR01ULTA1OjAwKSA8YnI+VG86IGRy YWZ0LWlldGYtZm9yY2VzLWxmYi1zdWJzaWRpYXJ5LW1hbmFnZW1lbnRAaWV0Zi5vcmcsIGZvcmNl c0BpZXRmLm9yZyA8YnI+Q2M6ICJKb2VsIE0uIEhhbHBlcm4iICZsdDtqbWhAam9lbGhhbHBlcm4u Y29tJmd0OyA8YnI+U3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZm9yY2VzLWxmYi1z dWJzaWRpYXJ5LW1hbmFnZW1lbnQtMDEgPGJyPjxicj48L2Rpdj48ZGl2IGRpcj0ibHRyIj5IaSBC aHVtaXAsIEV2YW5nZWxvcywgYW5kIEphbWFsLDxicj48YnI+VGhhbmtzIGZvciB5b3VyIHdvcmsg b24gdGhpcyBkcmFmdC4gQXMgaXMgY3VzdG9tYXJ5LCBJIGhhdmUgZG9uZSBteSBBRCByZXZpZXcg b2YgdGhlIGRyYWZ0IGJlZm9yZSBhc2tpbmcgdGhhdCBpdCBnbyBmb3J3YXJkIHRvIElFVEYgTGFz dCBDYWxsLjxicj48YnI+SSBoYXZlIG9ubHkgYSBmZXcgcXVpYmJsZXMsIHNvIEkgaGF2ZSBhZHZh bmNlZCB0aGlzIHRvIElFVEYgTGFzdCBDYWxsLiZuYnNwOyBJdCBpcyBvbiB0aGUgSUVTRyB0ZWxl Y2hhdCBvbiBTZXB0IDMuICZuYnNwOyAmbmJzcDtQbGVhc2UgZG8gcmVzcG9uZCBhbmQgdXBkYXRl IHRoZSBkcmFmdCBkdXJpbmcgSUVURiBMYXN0IENhbGwuJm5ic3A7IEFzIHlvdSB3ZWxsIGtub3cs IGhhdmluZyBhdXRob3JzIHdobyBhcmUgZXh0cmVtZWx5IHJlc3BvbnNpdmUgaGVscHMgZ3JlYXRs eSB3aXRoIGdldHRpbmcgdGhlc2UgZmluYWwgc3RlcHMgZG9uZS48YnI+PGJyPk1pbm9yIHF1aWJi bGVzOjxicj48YnI+MSkgSW4gU2VjLiA0LjQuMywgdHdvIG9mIHRoZSBjYXBhYmlsaXRpZXMgYXJl IGRlc2NyaWJlZCBhcyBwbGFjZWhvbGRlcnMuJm5ic3A7IENhbiB5b3UgcGxlYXNlIGNsYXJpZnkg d2hhdCB0aGUgZXhwZWN0ZWQgc3RhbmRhcmRpemVkIGJlaGF2aW9yIGlzPyZuYnNwOyBJIGltYWdp bmUgdGhhdCB0aGUgY2FwYWJpbGl0aWVzIGFyZSBmaWxsZWQgb3V0IGFzIGRlc2NyaWJlZCAtIHRo b3VnaCB3aXRoIHVuc3RhbmRhcmRpemVkIGluZm9ybWF0aW9uLjxicj48YnI+MikgSW4gU2VjLiA0 LjIsIGNvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBhIHJlZmVyZW5jZSB0byB0aGUgc3lzbG9nIHNl dmVyaXR5IGxldmVscz8mbmJzcDsgRm9yIGluc3RhbmNlLCB0aGUgSUFOQSByZWdpc3RyeSAoPGEg aHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zeXNsb2ctcGFyYW1ldGVycy9z eXNsb2ctcGFyYW1ldGVycy54aHRtbCNzeXNsb2ctcGFyYW1ldGVycy0yIj5odHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL3N5c2xvZy1wYXJhbWV0ZXJzL3N5c2xvZy1wYXJhbWV0ZXJzLnho dG1sI3N5c2xvZy1wYXJhbWV0ZXJzLTI8L2E+ICkgYW5kL29yIFJGQyAzMTY0IHdvdWxkIGJlIGxv dmVseS4gJm5ic3A7PGJyPjxicj4zKSBJbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2Vj dGlvbiwgYSBmZXcgd29yZHMgYWJvdXQgd2h5IGl0IGlzIG9rIHRvIHRydXN0IGEgQ0UgdG8gY3Jl YXRlIGEgY29ubmVjdGlvbiB0byBhbm90aGVyIENFIHdvdWxkIGJlIHVzZWZ1bC4gJm5ic3A7PGJy PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzLDwvZGl2PjxkaXY+QWxpYTwvZGl2PjwvZGl2Pgo8 L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_3880676985862850-- From nobody Fri Jul 31 15:08:28 2015 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A131A8AD0; Fri, 31 Jul 2015 15:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 qkax7BukKt20; Fri, 31 Jul 2015 15:08:24 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 5AC6E1A8AC6; Fri, 31 Jul 2015 15:08:21 -0700 (PDT) Received: by obre1 with SMTP id e1so63690016obr.1; Fri, 31 Jul 2015 15:08:20 -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:content-type; bh=33XLfNGSCYW//6HpD6RRf/YCpnTwqbDcBhed4rk/EwE=; b=IUVvt4e6t0KuSku2lcM4iBjhEAlZs/Z1if1Af8R0yVI2Ah9Kv+VpK0X6ncWYcda37Y mc2SvIpN8XUMxqmTuBLZy0xBECK6N4iCZtrP92wu9fjwomuCOBn2MbhsJOD85hhFBNIx 2yFPs5ExIz49IieaNecH5mk400uQcdXTHbuspgdF/RGUmJwPfMzsVlfvVPSh6tz28uBt s49oFxd8VG3tJ9z12gXbsV27B4EG+gI4NkAph8Hifp3sQgAV3YjIFu36/keD/4IbaTwQ qEqhfRYRlLjVLKIs+3uGT7xc8e/I/XQGyCeR44zeUoI8akH0kd0yBTRWs9bJ82C0klHv IwvA== MIME-Version: 1.0 X-Received: by 10.182.58.81 with SMTP id o17mr5803866obq.13.1438380500799; Fri, 31 Jul 2015 15:08:20 -0700 (PDT) Received: by 10.60.41.99 with HTTP; Fri, 31 Jul 2015 15:08:20 -0700 (PDT) Date: Fri, 31 Jul 2015 18:08:20 -0400 Message-ID: From: Alia Atlas To: draft-ietf-forces-interfelfb@ietf.org, "forces@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f83a83bcd56fc051c330e31 Archived-At: Subject: [forces] AD review of draft-ietf-forces-interfelfb-01 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 22:08:28 -0000 --e89a8f83a83bcd56fc051c330e31 Content-Type: text/plain; charset=UTF-8 Hi Damascane and Jamal, First, thank you for your work on this draft. As is customary, I have done my AD review of this draft before requesting IETF Last Call. As part of this, I see that Evangelos, acting as Document Shepherd, found a number of issues that are written up in his report - and that still haven't been addressed two months later. Picking an IANA value that isn't available is one of them. I know these are editorial, but still needed. At this time, I really don't think this draft is ready to advance. There are some things that are editorial or clarifications, as I described below. Please take some serious time and focus to improve this document if you want it to progress. There are two primary major issues. First, you haven't in any way justified why the inter-FE communication needs to be encapsulated in an Ethernet frame. Since you are asking for the IETF to get an EtherType allocated, that's kind of a bare minimum. Second, the draft bounces around a lot around whether this is an encapsulation that is just inside Ethernet or a general encapsulation that can be inside IP and other things. Moreover, it doesn't actually describe the reasoning or handling of the src/dest information and the packets. You really need to better describe precisely the assumptions, behaviors, and error handling. Issues: 1) In Sec 5.1.1: "The frame may be dropped if there is congestion on the receiving FE side. One approach to mitigate this issue is to make sure that inter-FE LFB frames receive the highest priority treatment when scheduled on the wire." This suggestion just destroyed the possibility of respecting the requested CoS of the encapsulated packet and probably any actual high priority or EF traffic. This recommendation must be fixed. 2) In Sec 6.1.1: One step is " create the outer ethernet header which is a duplicate of the incoming frame's ethernet header. The outer ethernet header may have an optional 802.1q header (if one was included in the original frame)." First, what if the incoming packet wasn't in an ethernet frame? POS does still exist. Second, why would the 802.1q vlan tag be relevant/valid on the outgoing port in between FEs? This doesn't really make sense to me. I do see the next bullet talks about changing the vlan tag value but nothing happens if the NEID is 0 or absent. 3) How can the DSTFE be optional??? Why does sending the Ethernet Frame to the original destination MAC address work? 4) In Sec 6.2, what happens if none of the optional elements of an IFEInfo are specified? How can this work if there's no required way to describe the destination FE? 5) From p. 22, it looks like the IFETable is defined assuming only transport over Ethernet. 6) Sec 10: I think you'll find that there are security implications of taking packets and sending them in an Ethernet packet. Now, I realize that the different FEs are probably inside the same device on a private network - but you need to clarify why that's the case. Minor Quibble: a) There are places where this draft talks about other documents being written. For instance, on the top of p.13 "For any mapping towards these definitions a different document to describe the mapping, one per transport, is expected to be defined." It's fine to have a process in mind - but this is completely unclear, given that the WG is closed. Are these documents with a well-known place on-line? Are these ISE drafts? Do you think these would be AD-sponsored or in rtgwg? b) On the bottom of p. 13, it says "In this version of the specification, we only focus on data and metadata. Therefore we are not going to describe how to carry the ExceptionID information (future versions may). " PLEASE go through the document and get rid of these bits of tentative and future language. The document is doing and defining what it is. OWN that and fix the language everywhere. (e.g. bottom of p.14 "would save us") Nits: 1) On p. 6, "This information may include any source and destination information (MAC address to use, if ethernet;)" Sadly, I think the ;) needs to go - what about "e.g. MAC address to use, if Ethernet)". 2) In Sec. 3.1.1, the last paragraph is "The purpose of the inter-FE LFB is to define standard mechanisms for interconnecting FEs and for that reason we are not going to touch anymore on proprietary chip-chip interconnects other than state the fact they exist and that it is feasible to have translation to and from proprietary approaches." is a bit informal. Could you please clean it up a bit? For instance: "This document defines the inter-FE LFB, a standard mechanism for interconnecting FEs. Existing proprietary approaches, such as chip-chip interconnects, may be able to translate to and from the standard inter-FE LFB." 3) Sec 4 starts with "We address the inter-FE connectivity requirements by proposing the inter-FE LFB class." Remember this will be an RFC - please replace "proposing" with "defining". Similarly, the title of "Figure 6: Packet format suggestion" - is this what the document is standardizing or not?? Thanks, Alia --e89a8f83a83bcd56fc051c330e31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Damascane and Jamal,

First= , thank you for your work on this draft.

As is customary, I have done my AD review of this draft before req= uesting IETF Last Call. =C2=A0

<= span style=3D"font-size:14px;line-height:16.996000289917px;background-color= :rgb(255,253,245)">As part of this, I see that Evangelos, acting as Documen= t Shepherd, found a number of issues that are written up in his report - an= d that still haven't been addressed two months later.=C2=A0 Picking an = IANA value that isn't available is one of them.=C2=A0 I know these are = editorial, but still needed.

At this time, I really don't think this draft is ready= to advance.
There are some things that are ed= itorial or clarifications, as I described below.

Please take some serious time and focu= s to improve this document if you want it to progress.
<= div>
There are two primary major iss= ues.

First, you= haven't in any way justified why the inter-FE communication needs to b= e encapsulated in an Ethernet frame.=C2=A0 Since you are asking for the IET= F to get an EtherType allocated, that's kind of a bare minimum.<= /font>

Second, the draft b= ounces around a lot around whether this is an encapsulation that is just in= side Ethernet or a general encapsulation that can be inside IP and other th= ings.=C2=A0 Moreover, it doesn't actually describe the reasoning or han= dling of the src/dest information and the packets.
=
You really need to better describe p= recisely the assumptions, behaviors, and error handling.


<= font color=3D"#000000" face=3D"PT Mono, Monaco, monospace">Issues:

= 1) In Sec 5.1.1: =C2=A0"The frame may= be dropped if there is congestion on the receiving=C2=A0FE side.=C2=A0 One= approach to mitigate this issue is to make sure that=C2=A0inter-FE LFB fra= mes receive the highest priority treatment when=C2=A0scheduled on the wire.= " =C2=A0This suggestion just destroyed the possibility of respecting t= he requested CoS of the encapsulated packet and probably any actual high pr= iority or EF traffic. =C2=A0 This recommendation must be fixed.
<= br>
2) In Sec 6.1.1: One step is "=C2=A0create the outer eth= ernet header which is a duplicate of the
=C2=A0 =C2=A0 =C2=A0 incoming f= rame's ethernet header.=C2=A0 The outer ethernet header may
=C2=A0 = =C2=A0 =C2=A0 have an optional 802.1q header (if one was included in the=C2=A0 =C2=A0 =C2=A0 original frame)." =C2=A0First, what if the incom= ing packet wasn't in an ethernet frame?=C2=A0 POS does still exist.=C2= =A0 Second, why would the 802.1q vlan tag be relevant/valid on the outgoing= port in between FEs? =C2=A0 This doesn't really make sense to me.=C2= =A0 I do see the next bullet talks about changing the vlan tag value but no= thing happens if the NEID is 0 or absent.

3) How c= an the DSTFE be optional???=C2=A0 Why does sending the Ethernet Frame to th= e original destination MAC address work?

4) In Sec 6.2, what happe= ns if none of the optional elements of an IFEInfo are specified?=C2=A0 How = can this work if there's no required way to describe the destination FE= ?

5) From p. 22, it looks like the IFETable is defi= ned assuming only transport over Ethernet.
6) Sec 10: =C2=A0I think you'll find tha= t there are security implications of taking packets and sending them in an = Ethernet packet.=C2=A0 Now, I realize that the different FEs are probably i= nside the same device on a private network - but you need to clarify why th= at's the case.




= a) There are places where this draft talks about other documents being= written.=C2=A0 For instance, on the top of p.13 "For any m= apping towards these definitions a different=C2=A0 =C2=A0document to= describe the mapping, one per transport, is expected to=C2=A0be defined.&q= uot; =C2=A0It's fine to have a process in mind - but this is completely= unclear, given that the WG is closed.=C2=A0 Are these documents with a wel= l-known place on-line?=C2=A0 Are these ISE drafts?=C2=A0 Do you think these= would be AD-sponsored or in rtgwg?

b) On the bottom of p. 13, it = says "In this version of the specification, we only focus on data and = metadata.=C2=A0 Therefore we are not going to describe how to carry the Exc= eptionID information (future versions may). " =C2=A0 PLEASE go through= the document and get rid of these bits of tentative and future language.= =C2=A0 The document is doing and defining what it is.=C2=A0 OWN that and fi= x the language everywhere. =C2=A0(e.g. bottom of p.14 "would save us&q= uot;)


Nits:

1) On p= . 6, "This information may include any source and destination=C2=A0inf= ormation (MAC address to use, if ethernet;)" =C2=A0Sadly, I think the = ;) needs to go - what about "e.g. MAC address to use, if Ethernet)&quo= t;.

2) In Sec. 3.1.1, the last paragraph is=C2=A0"T= he purpose of the inter-FE LFB is to define standard mechanisms for=C2=A0in= terconnecting FEs and for that reason we are not going to touch
=C2=A0 = =C2=A0anymore on proprietary chip-chip interconnects other than state the=C2=A0 =C2=A0fact they exist and that it is feasible to have translation = to and
=C2=A0 =C2=A0from proprietary approaches." =C2=A0is a bit in= formal.=C2=A0 Could you please clean it up a bit?
For instanc= e: =C2=A0"This document defines the inter-FE LFB, a standard mechanism= for interconnecting FEs.=C2=A0 Existing proprietary approaches, such as ch= ip-chip interconnects, may be able to translate to and from the standard in= ter-FE LFB."

3) Sec 4 starts with "We address the inter-= FE connectivity requirements by proposing the=C2=A0inter-FE LFB class."= ; =C2=A0Remember this will be an RFC - please replace "proposing"= with "defining".=C2=A0 Similarly, the title of "Figure 6: P= acket format suggestion" - is this what the document is standardizing = or not??

Thanks,
Alia

--e89a8f83a83bcd56fc051c330e31-- From nobody Fri Jul 31 22:31:46 2015 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC44E1ACF17; Fri, 31 Jul 2015 22:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 g3I5-4yHMoY0; Fri, 31 Jul 2015 22:31:36 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 3E75C1ACEE7; Fri, 31 Jul 2015 22:31:36 -0700 (PDT) Received: by labks4 with SMTP id ks4so9784907lab.0; Fri, 31 Jul 2015 22:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=16mfltv6wqbpjQZXGuCXcgtfXOKyrj5EgHYlqObhBlk=; b=aZ9pSCw4r0RW8iOKFyju9zJgWjO6Rgo3lMfyKLappsMcsEn/xIB0c3rsrD7kaIS/p5 UwzHMVqp56M1ordqhYd2yDomC8oeF8xuTB8VKJkMdpBtAqZFiy3pqQ1fNYFbU5VjYA+m ve3BU2nVwrwOhuZ8YWMKz48uO8laAAsae1Kz/KC7RZ5KtlUHn40KXH+9FTr2562md+Gd CspQd8o6uNSqMWkqAHT+SmnE/13eOINpC7Tfw24p5RZLUwwhy3XmIbs+NHdUxteAeBQK 9qRFATd9+Ca52O0555LnbzhD0LVS59AIUGmr6NdbM2BzdBggvoE6Fc5r9gU7kWxTPW9v q6dQ== X-Received: by 10.152.37.37 with SMTP id v5mr6903004laj.11.1438407094656; Fri, 31 Jul 2015 22:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.145.139 with HTTP; Fri, 31 Jul 2015 22:30:55 -0700 (PDT) In-Reply-To: References: From: "B. Khasnabish" Date: Sat, 1 Aug 2015 01:30:55 -0400 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=089e0160b9aaeb63ce051c393f97 Archived-At: Cc: "forces@ietf.org" , draft-ietf-forces-lfb-subsidiary-management@ietf.org, "Joel M. Halpern" Subject: Re: [forces] AD review of draft-ietf-forces-lfb-subsidiary-management-01 X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 05:31:38 -0000 --089e0160b9aaeb63ce051c393f97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Alia, Thanks a lot. Yes, we'll do the updates based on your suggestions, and publish the revised draft soon. Best. Bhumip =E2=80=8B =E2=80=8B On Fri, Jul 31, 2015 at 3:47 PM, Alia Atlas wrote: > Hi Bhumip, Evangelos, and Jamal, > > Thanks for your work on this draft. As is customary, I have done my AD > review of the draft before asking that it go forward to IETF Last Call. > > I have only a few quibbles, so I have advanced this to IETF Last Call. I= t > is on the IESG telechat on Sept 3. Please do respond and update the > draft during IETF Last Call. As you well know, having authors who are > extremely responsive helps greatly with getting these final steps done. > > Minor quibbles: > > 1) In Sec. 4.4.3, two of the capabilities are described as placeholders. > Can you please clarify what the expected standardized behavior is? I > imagine that the capabilities are filled out as described - though with > unstandardized information. > > 2) In Sec. 4.2, could you please provide a reference to the syslog > severity levels? For instance, the IANA registry ( > http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml= #syslog-parameters-2 > ) and/or RFC 3164 would be lovely. > > 3) In the Security Considerations section, a few words about why it is ok > to trust a CE to create a connection to another CE would be useful. > > Thanks, > Alia > --089e0160b9aaeb63ce051c393f97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Alia,
=C2=A0
Than= ks a lot. Yes, we'll do the updates based on
your suggestio= ns, and publish the revised draft soon.
=C2=A0
Best= .
=C2=A0
Bhumip=C2=A0=C2=A0
=
=E2=80=8B
=E2=80=8B
=

On Fri, Jul 31, 2015 at 3:47 PM, Alia Atlas = <akatlas@gmail.com> wrote:
Hi Bhumip, Evangelos, and Jamal,

Thanks for your work on this dr= aft. As is customary, I have done my AD review of the draft before asking t= hat it go forward to IETF Last Call.

I have only a few quibbles, so = I have advanced this to IETF Last Call.=C2=A0 It is on the IESG telechat on= Sept 3. =C2=A0 =C2=A0Please do respond and update the draft during IETF La= st Call.=C2=A0 As you well know, having authors who are extremely responsiv= e helps greatly with getting these final steps done.

Minor quibbles:=

1) In Sec. 4.4.3, two of the capabilities are described as placehol= ders.=C2=A0 Can you please clarify what the expected standardized behavior = is?=C2=A0 I imagine that the capabilities are filled out as described - tho= ugh with unstandardized information.

2) In Sec. 4.2, could you pleas= e provide a reference to the syslog severity levels?=C2=A0 For instance, th= e IANA registry (http://ww= w.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-par= ameters-2 ) and/or RFC 3164 would be lovely. =C2=A0

3) In the Se= curity Considerations section, a few words about why it is ok to trust a CE= to create a connection to another CE would be useful. =C2=A0

<= /div>
Thanks,
Alia

--089e0160b9aaeb63ce051c393f97--