From nobody Thu Apr 6 02:50:15 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03770126557 for ; Thu, 6 Apr 2017 02:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 Xv9ObB94hnnz for ; Thu, 6 Apr 2017 02:50:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6851F127698 for ; Thu, 6 Apr 2017 02:50:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEF73806; Thu, 06 Apr 2017 09:50:07 +0000 (GMT) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 10:50:06 +0100 Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.93]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 17:49:58 +0800 From: "Xialiang (Frank)" To: Linda Dunbar , Adrian Farrel CC: "i2nsf@ietf.org" Thread-Topic: Request for WG adoption for the draft -- draft-xibassnez-i2nsf-capability-01: Thread-Index: AdKuux+0EtElKfzdR6aXlomeFFxHRw== Date: Thu, 6 Apr 2017 09:49:58 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BABA7D4DGGEML502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58E60F50.007D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.93, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d9ca662933a058e53616cb2d40a97455 Archived-At: Subject: [I2nsf] Request for WG adoption for the draft -- draft-xibassnez-i2nsf-capability-01: X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 09:50:13 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BABA7D4DGGEML502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG and Chairs, We co-authors of draft-xibassnez-i2nsf-capability-01 think this draft is in= good shape through many rounds update, and gathers a lot of interests and = cooperation in I2NSF WG. As a result, we request for the WG adoption for it so that it can be a good= start and base for further work: I2NSF capability information/data model d= esign and update, others... Thanks! B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12BABA7D4DGGEML502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG and Chairs,

We co-authors of draft-xibassne= z-i2nsf-capability-01 think this draft is in good shape through many rounds= update, and gathers a lot of interests and cooperation in I2NSF WG.

As a result, we request for the= WG adoption for it so that it can be a good start and base for further wor= k: I2NSF capability information/data model design and update, others…=

 

Thanks!

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12BABA7D4DGGEML502MBSchi_-- From nobody Thu Apr 6 08:49:07 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202DA129524 for ; Thu, 6 Apr 2017 08:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 hxr0dbcMq2Z3 for ; Thu, 6 Apr 2017 08:49:02 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE1E126BF7 for ; Thu, 6 Apr 2017 08:49:01 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v36FmRKG002141; Thu, 6 Apr 2017 16:48:27 +0100 Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v36FmNoh002077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Apr 2017 16:48:25 +0100 Reply-To: From: "Adrian Farrel" To: "'Xialiang \(Frank\)'" , "'Linda Dunbar'" Cc: References: In-Reply-To: Date: Thu, 6 Apr 2017 16:48:23 +0100 Message-ID: <08d001d2aeed$3ab8fdd0$b02af970$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08D1_01D2AEF5.9C7FD6D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGPAE2GIRepuwxERQ40RFkuU1OB+qI/2YzQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22988.007 X-TM-AS-Result: No--20.507-10.0-31-10 X-imss-scan-details: No--20.507-10.0-31-10 X-TMASE-MatchedRID: oCj5caaCQynW/bDrA6VrLQuB7zdAMUjAEtdrY/Wb3fO67Q3uPo9KI4AH BPmVHmpkzmcbs/BswOUXIJWO/t2WjkKtkjlYA82dVo6mn+xXmdXJOJysDBbflleilmPI7oJlZZZ 3VUEj3ofD+jr+TKt6ZhHlKZ0KtAaIR1vveBQPCRdCvapcIkxJX66IBbSnfz+3ut/GVGOoEneALj qnIlNKdNXjKfop/WvT3wqC9Qsu3hf9+rKlRf1WaEtzk37SzX4NlPV6Vaqi4bDxxaAXDrCns4j7J 3jzONjdJa6rGJR4RfowuiDzT/FFiVHi+vC6FxL8BU4uU+5y12ot0t+aIVLt+5KzWy3+GmBuXM4p VHn2LwM/makG0+v97t639oRBFUkeQ0pFGvYttetYKMMlFh4BnUopYlyHMD9xtoOo2rdpi1VGrs1 oWaIIgBnqlgHBkV8KtpqoU9tNJ/5TeZCGZ2HhGGOILin78AgWMx981lgKTcNLwIXeA1TZXTiTqP yDEY2yfcUBSI0HztKGAoXhhbsbIC95uXownWhRnQrZDK7DrTqZEoWHC6Rh/WTNuWQFsA2G2P13j 4ZncXBJGMhiY3U6uSqFmu/h/tw7fgWNZg36My97k1ZHmKLF7Zv8tNLRPUrWQdOsmUEGvaXgn8HV 6/VM7buwuIYnhcFSgDLqnrRlXrbVE7HmVnVGHv7E6GNqs6ceavP8b9lJtWpFGCd0S0NCskFhGHb 3BQGgnwOke7bsWMZJa1p5LANWcD/5OxWcTIMmxYVzI3UCCaY= Archived-At: Subject: Re: [I2nsf] Request for WG adoption for the draft -- draft-xibassnez-i2nsf-capability-01: X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:49:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08D1_01D2AEF5.9C7FD6D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Frank, Thanks for the reminder. As we discussed in the meeting and face-to-face, this draft is on our list of candidates for adoption and we hope to start processing that list soon. Regards, Arian From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com] Sent: 06 April 2017 10:50 To: Linda Dunbar; Adrian Farrel Cc: i2nsf@ietf.org Subject: Request for WG adoption for the draft -- draft-xibassnez-i2nsf-capability-01: Hi WG and Chairs, We co-authors of draft-xibassnez-i2nsf-capability-01 think this draft is in good shape through many rounds update, and gathers a lot of interests and cooperation in I2NSF WG. As a result, we request for the WG adoption for it so that it can be a good start and base for further work: I2NSF capability information/data model design and update, others. Thanks! B.R. Frank ------=_NextPart_000_08D1_01D2AEF5.9C7FD6D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Frank,

 

Thanks for the reminder.

 

As we = discussed in the meeting and face-to-face, this draft is on our list of = candidates for adoption and we hope to start processing that list = soon.

 

Regards,

Arian

 

From: Xialiang (Frank) = [mailto:frank.xialiang@huawei.com]
Sent: 06 April 2017 = 10:50
To: Linda Dunbar; Adrian Farrel
Cc: = i2nsf@ietf.org
Subject: Request for WG adoption for the draft = -- = draft-xibassnez-i2nsf-capability-01:

 

Hi WG and = Chairs,

We = co-authors of draft-xibassnez-i2nsf-capability-01 think this draft is in = good shape through many rounds update, and gathers a lot of interests = and cooperation in I2NSF WG.

As a = result, we request for the WG adoption for it so that it can be a good = start and base for further work: I2NSF capability information/data model = design and update, others…

 <= /o:p>

Thanks!=

 <= /o:p>

B.R.

Frank

------=_NextPart_000_08D1_01D2AEF5.9C7FD6D0-- From nobody Fri Apr 7 16:42:01 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2010128DE7; Fri, 7 Apr 2017 16:41:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149160850285.11224.2464729863969311049.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 16:41:42 -0700 Archived-At: Subject: [I2nsf] Eric Rescorla's No Objection on draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:41:43 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't have any problem with this document per se, but it's a little odd how it's written in a vacuum as if there weren't already technologies which did a lot of the things you are talking about here (e.g., YANG) and which the WG intends to use. I think this document would be a lot stronger if it didn't act as if the WG was agnostic and instead called out what solutions the WG intends to adopt for these. I'm also somewhat surprised this is being advanced as Standards Track, given that it doesn't have any normative content, and becaus ehte writeup says that there isn't commitment to implement this. I won't hold a DISCUSS on this, but I would suggest it be Informational. S 2. Flow-based NSF: An NSF which inspects network flows according to a security policy. Flow-based security also means that packets are inspected in the order they are received, This seems over-specific, because sometimes firewalls and the like will store packets so that it can re-assemble them, in which case it inspects them in logical not time order. S 3.1.7. Different policies might need different signatures or profiles. Today, the construction and use of black list databases can be a win-win strategy for all parties involved. Well, except for attackers. They are involved. S 3.1.9; bullet 3. Symmetric keys and group keys are not the same type of category, so I can't read this section. What are you trying to say here? S 3.5. "xamine" and "scnearios" are misspelled. S 3.6. ToR seems to be undefined. Figure 3. I think this dotted circle-thing is intended to tell me that the operator controls the stuff inside the circle, but I'm not sure. Maybe some labels would help. From nobody Sat Apr 8 11:49:02 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3429A126DEE; Sat, 8 Apr 2017 11:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 AVBHlak2y09z; Sat, 8 Apr 2017 11:48:58 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791C8128C84; Sat, 8 Apr 2017 11:48:57 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v38ImtMM021725; Sat, 8 Apr 2017 19:48:55 +0100 Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v38ImowF021681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Apr 2017 19:48:53 +0100 Reply-To: From: "Adrian Farrel" To: "'Eric Rescorla'" , "'The IESG'" Cc: , , References: <149160850285.11224.2464729863969311049.idtracker@ietfa.amsl.com> In-Reply-To: <149160850285.11224.2464729863969311049.idtracker@ietfa.amsl.com> Date: Sat, 8 Apr 2017 19:48:50 +0100 Message-ID: <0b6601d2b098$c626e100$5274a300$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLp+LmdSbjdDBob/4eJx7rF7fr92p+NPmRQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22994.001 X-TM-AS-Result: No--6.383-10.0-31-10 X-imss-scan-details: No--6.383-10.0-31-10 X-TMASE-MatchedRID: 9zTThWtzIms4HKI/yaqRm521GZGE81yGt6fWTFY+RBksugxReYWqZoc7 DaU6vSPuZW5WXoFxG7Y52jCcSJt6UO+xMqHZ7jWp3fn7n/ZHGqYZtDeWeYUCStJgDNnoqapa4OE EoEwjVDnBg3evtT7XeVyaaHlq2HL/jlkz19bnEODzkvkkcY4BcG79evoIpeI3nyns0uPuBWTzvp rOXn6be+fOVcxjDhcwEFY6gDmeXI0LbigRnpKlKWxlRJiH4397dp3Z4CSaWwdHVPaLU+ZDSvSoF 2XkGMgYesvof1GVdk4zHTHAlhj2Zw== Archived-At: Subject: Re: [I2nsf] Eric Rescorla's No Objection on draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 18:49:00 -0000 Hi ekr,=20 Welcome to the treadmill :-) > I'm also somewhat surprised this is being advanced as Standards Track, > given that it doesn't have any normative content, and becaus ehte > writeup says that there isn't commitment to implement this. > I won't hold a DISCUSS on this, but I would suggest it be > Informational. Don't be too surprised as the shepherd write-up touches on this. While the IESG has done some work on relaxing downref rules, the WGs = still struggle with how to handle foundation documents that will be = essential reading (i.e., normative references) for later work. My advice to the WG for this document was, "Push it through as Standards = Track and let the IESG worry about whether it should be Informational or = not." I think my advice will remain, "Let the IESG tell us what to do, and we = will do it. But don't go making changes unless instructed to do so." Cheers, Adrian From nobody Mon Apr 10 08:13:21 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105B1129537; Mon, 10 Apr 2017 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 eQLBoLUiGrgH; Mon, 10 Apr 2017 08:13:16 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 7189E1294F6; Mon, 10 Apr 2017 08:13:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.20.181; From: "Susan Hares" To: "'Dale Worley'" , Cc: , , References: <148952979419.24295.8210647087024239014@ietfa.amsl.com> In-Reply-To: <148952979419.24295.8210647087024239014@ietfa.amsl.com> Date: Mon, 10 Apr 2017 11:08:04 -0400 Message-ID: <00fb01d2b20c$4182ab80$c4880280$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGutpg0SXJzXob6/wPiGXgr+oPIOqHd3kAA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:13:20 -0000 Dale: Thank you for the review. Please see my comments below. Sue -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Dale Worley Sent: Tuesday, March 14, 2017 6:17 PM To: gen-art@ietf.org Cc: i2nsf@ietf.org; ietf@ietf.org; draft-ietf-i2nsf-problem-and-use-cases.all@ietf.org Subject: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. Document: draft-ietf-i2nsf-problem-and-use-cases-11 Reviewer: Dale R. Worley Review Date: 2017-03-14 IETF LC End Date: 2017-03-22 IESG Telechat date: [unknown] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. All of these nits are editorial. >1. Introduction > > This document describes the problem statement for Interface to > Network Security Functions (I2NSF) as well as some I2NSF use cases. > A summary of the state of the art in the industry and IETF which is > relevant to I2NSF work is documented in > [I-D.hares-i2nsf-gap-analysis]. >The content of these sentences is very good, but the construction seems to be peculiar. The document doesn't *describe* the problem statement, the document *is* a statement. Similarly, hares-i2nsf-gap-analysis *is* a summary of the state of the art. >So I would use > > This document is the problem statement for Interface to Network > Security Functions (I2NSF) as well as some I2NSF use cases. A > summary of the state of the art in the industry and IETF which is > relevant to I2NSF work is [I-D.hares-i2nsf-gap-analysis]. Dale >But maybe you'll prefer to ask the RFC Editor. > > This document also briefly describes the > following use cases summarized by > [I-D.pastor-i2nsf-merged-use-cases]: > >This sentence should start a new paragraph, as it's not connected to the sentences before it. Thank you for finding these errors. I also needed to change I-D.hares-i2nsf-gap-analysis to draft-ietf-i2nsf-gap-analysis. >3. Problem Space > > The following sub-section describes ... >s/sub-section describes/sub-sections describe/ Thank you - sorry to have missed it. >3.1.1. Diverse Types of Security Functions > > NSFs by different vendors can have > different features and have different interfaces. > >It might be worth mentioning somewhere what seems to be a convention: >the document (or at least, section 3.1) is largely oriented toward "service providers" who sell comprehensive network services (including security functions) to "customers", but who in turn buy security functions from "vendors". Perhaps this could be ?>entered as terminology in section 2. > >The reason I mention this is that my background is as an end-user (which is common in the IETF), so the term "service provider" >Triggers in my mind the idea "someone I buy something from". And the term "vendor" triggers the *same* idea. But in this draft, the default reader is a "service provider" and "vendor" is *not* the same thing. I've added this text: Security Service Provider: A provider of security services to the customers (end-users or enterprises) using NSF equipment purchased from vendors or created by the service provider. >This point started to confuse me at the beginning of section 3.1.6. > > Security Functions in a Demilitarized Zone (DMZ): Examples of this > function are firewall/ACLs, IDS/IPS, one or all of AAA services > NAT, forwarding proxies, and application filtering. > The phrase "one or all of AAA services NAT" seems to be incorrect. I suspect there's supposed to be a comma before NAT. Good catch. I will fix. > Security gateways and VPN concentrators: Examples of these > functions are; IPsec gateways, Secure VPN concentrators that > handle bridging secure VPNs, and Secure VPN controllers for data > flows. > Unless "Secure VPN" is a name in itself, "secure" shouldn't be capitalized. Good point. I will fix. > 3.1.2. Diverse Interfaces to Control and Monitor NSFs > > A challenge for monitoring is that an NSF cannot monitor what it > cannot view. Therefore, enabling a security function (e.g., firewall > [I-D.ietf-opsawg-firewalls]) does not mean that a network is > protected. As such, it is necessary to have a mechanism to monitor > and provide execution status of NSFs to security and compliance > management tools. There exist various network security monitoring > vendor-specific interfaces for forensics and troubleshooting. > This paragraph seems awkward. Each sentence is reasonable, but the connection between them is not clear to me. > Perhaps the third sentence has the meaning "... it is necesary to have a mechanism ...to verify that the NSF is seeing the traffic that is intended". >The last sentence contains "network security monitoring vendor-specific interfaces" which is awkward. Perhaps > > There exist various vendor-specific interfaces for network security > monitoring, forensics, and troubleshooting. New paragraph is below. Is it better New/ A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function to mitigate an intrusion (e.g., firewall ) does not mean that a network is protected if there is no monitoring feedback. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across avariety of NSFs. / 3.1.4. More Demand to Control NSFs Dynamically > The Security Service Providers ... >The capitalization of "security service providers" is inconsistent. > Some times all three words are capitalized, and some times they're not. Thanks for catching this - I will fix it. 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs > Service providers may need several operational units to control and > monitor the NSFs, especially when NSFs become distributed and > virtualized. > > You may want to explain what an "operational unit" is. As far as I can tell, neither "unit" nor "operational" (in this sense) is used elsewhere in this draft. Thanks for catching this vagueness. The point the service provides may have to deploy multiple controllers. How about: Service providers may need to deploy several NSF controllers to control and monitor the NSFs, especially when NSFs become distributed and virtualized. >3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles > Many security functions depend on signature files or profiles to > perform (e.g., IPS/IDS signatures, DDos Open Threat Signaling > (DOTS) filters). >I think the words "to perform" should be removed. The sentence makes more sense to me without those. Or, if there is a meaning that needs to be specified, "to perform" probably >isn't the right choice. "to work" makes sense in this place, but is an informal usage. Perhaps "to function". [removed "to perform") > Today, the construction and use of black list databases > can be a win-win strategy for all parties involved. >"win-win strategy" is a hackneyed phrase. This is better > Today, the construction and use of black list databases > can be beneficial for all parties involved. >However, it's not clear to me what additional information is carried by "for all parties involved". And for that matter, is "today" >important here? >I suspect that you mean something like this: > > Today, black list databases can be beneficial, and in the future > there might be open source signatures/profiles ... > > (e.g., by Snort, Suricata, Bro and Kisnet) > >s/Kisnet/Kismet/ >"Snort, Suricata, Bro and Kisnet" reads like a reference -- I had to look them up to discover that they are IDS software! > >But there needs to be some connection between a list of IDS software systems and "open source signatures/profiles". Perhaps: > > Today, black list databases can be beneficial, and in the future > there might be open source signatures/profiles distributed as part > of IDS systems (e.g. Snort, Suricata, Bro and Kisnet). All good comments, but my recollection was the WG wanted to underscore the strategy was good for all parties. Therefore, here's the new paragraph New/ Today, black list databases can be a beneficial strategy for all parties involved, but in the future there might be open Source-provided signature/profiles distributed as part of IDS systems (e.g., by Snort, Suricata, Bro and Kismet). / -- >There is a need to have a standard envelope (i.e., the format) to > allow NSFs to use external profiles. >This is awkward. Perhaps > There is a need to have a standard format to allow NSFs to use > external profiles. This part hit many discussions. How about New/ There is a need to have a standard envelope (i.e., a message format) to allow NSFs to use external profiles./ >3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger ... > > I2NSF controller(s) would manage the changing to the affected > policies ... > This could be simplified to "I2NSF controller(s) would change the affected policies ...". New/ I2NSF controller(s) would control any changes to affected policies (e.g., forwarding and routing, filtering, etc.)./ >The I2NSF controls the change (whether others change the policies or not). > By monitoring the network alerts from DDoS ... >Probably s/DDoS/DOTS/. > > ... I2NSF > can feed an alerts analytics engine that could recognize attacks so > the I2NSF can enforce the appropriate policies. > Here, "I2NSF" is being used as a noun, whereas the previous usage is that it is an adjective, and "I2NSF controller(s)" would be used. New/ By monitoring the network alerts regarding DDoS attacks (e.g. from DOTS servers or clients), the I2NSF controller(s) can feed an alerts analytics engine that could recognize attacks so the I2NSF can enforce the appropriate policies. / > ... provide information to the client ... > >I think this is clearer if s/the client/its clients/. "client" is used with two meanings, one is "customer" (e.g., in the definition of "Bespoke"), and more commonly as "software client". > If you say "[the controller's] clients", it is clear that you're using the second meaning. New/ DDoS mitigation is enhanced if the provider's network security controller can monitor, analyze, and investigate the abnormal events and provide information to the customer or change the network configuration automatically / >3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs > > There is a need for a controller to distribute various keys to > distributed NSFs. To distribute various keys, the keys must be > created and managed. >Perhaps combine these as > > There is a need for a controller to create, manage, and distribute > various keys to distributed NSFs. I've made this change. > In addition, keys may be used to secure > the protocol and messages in the core routing infrastructure (see > [RFC4948]) >Probably s/protocol/protocols/. > I've made this change. > If a device had an abstract key table > maintained by security services, a device could use these keys for > routing and seurity devices. > >s/seurity/security/ > >Typical English usage in this situation is "it could use ..."; because "it" is the subject of the second clause, it is presupposed to be the same as the subject of the first clause. New sentences: / If a device had an abstract key table maintained by security services, it could use these keys for routing and security devices. / > Conceptually, there must be an interface defined for routing/ > signaling protocols to make requests for automated key management > when it is being used, and to notify the protocols when keys become > available in the key table. One potential use of such an interface > is to manage IPsec security associations on SDN networks. >I think you need to add a subject in "... and for XXX to notify the protocols ..." for clarity, the omitted noun could be "interface" or "protocols". Grammatically - I disagree . The clauses "to make request...." and "to notify" are infinitive clauses which modify the direct object (an interface) which are linked together in a list. However, rather than debate this syntax with others - I've changed the syntax to a cl New/ Conceptually, there must be an interface defined for routing/signaling protocols that can: a) make requests for automated key management when it is being used. and b) notify the protocols when keys become available in the key table. / >The last sentence seems redundant, as security associations have been discussed at the beginning of 3.1.9. Is there a particular reason to point out IPsec at this point (since many >secured protocols need keys)? The WG felt it needed an example here. If it is OK, I'm going to leave this in for another round of editing. > If protocols share > common mechanisms for authentication (e.g., TCP Authentication > Option [RFC5925]), then the same mapping may be reused. >This sentence starts with "protocols [that] share common mechanisms" >but then mentions only one protocol. Do you mean > If several protocols share a > common mechanism for authentication (e.g., TCP Authentication > Option [RFC5925]), then the same mapping may be used for all > usages of that mechanism. Thank you. I've changed to this sentence. > 3. Automated Key management needs to support both symmetric keys and > group keys via the abstract key service provided by items 1 and > 2. >s/Key/key/ --Thank you. >I think "via the abstract key service provided by items 1 and 2" is redundant here. It may be redundant, but as I recall it was important to some of the authors. -------------- 3.2. Challenges Facing Customers > o Which critical communications are to be preserved during critical > events and which hosts are continue service, > >"are continue service" seems to be incorrect in some way. New/Which critical communications are to be preserved during critical events and which hosts will continue services over the network,/ > o What signaling information is passed to a controller that during a > Distributed Denial of Service in order to ask for mitigation > services (within the scope DOTS working group), > "that" should be removed, I think. Removed. >3.2.2. Today's Control Requests are Vendor Specific > > Without a standard technical > standard interface that provides a clear technical characterization, > the service provider faces many challenges: >Should "standard technical standard interface" be "standard interface" >or "standardized interface"? >Standardized interface. > No standard technical characterization, APIs, or Interface >I think you want a colon after this phrase to parallel the other items in the list. Thank you. > Managing by scripts de-jour: The current practices rely upon the > use of scripts that generate other scripts which automatically run > to upload or download configuration changes, log information and > other things. These scripts have to be adjusted each time an > implementation from a different vendor technology is enabled on a > provider side. > The phrase "on a provider side" doesn't read well. Perhaps "by a service provider"? 3.3. Lack of Standard Interface to Inject Feedback to NSF > The following sub-section describes the problems and challenges > facing customers and security service providers when some or all of > the security functions are no longer physically hosted by the > customer's adminstrative domain. >s/adminstrative/administrative/ Note: Sentence was removed. > As more sophisticated threats arise, enterprises, vendors, and > service providers have to rely on each other to achieve optimal > protection. Cyber Threat Alliance (CTA, > http://cyberthreatalliance.org/) is one of those initiatives that aim > at combining efforts conducted by multiple organizations. >This paragraph doesn't fit well in the flow of the text. The second sentence seems like it's basically a reference, and the link should be put down in the references. But I think the >point resembles the discussion in 3.1.7, that you want to enable organizations to pass among themselves new profiles, which the customers or service providers can insert into NSFs > in a simple way. Perhaps > As more sophisticated threats arise, protection will depend > on enterprises, vendors, and service providers being able to > cooperate to develop optimal profiles, e.g., through initiatives > like [CTA]. >and then combine with the paragraph which follows: > > The standard interface to provide security profiles to the NSF should > interwork with the formats which exchange security profiles between > organizations. 3.5. Difficulty to Validate Policies across Multiple Domains >As discussed in the previous four sections, both service providers ... >Probably s/sections/sub-sections/. > ... and customers have needs to express policies and profiles ... > >s/needs/need/ > > This section and the next section (section 3.6) xamine what ... >s/xamine/examine/ > (Have you spell-checked this draft?) Not this one. I'm afraid I rushed the -11 out in response to query. I lived to regret this fact. > > > ... happens in two specific network scnearios: ... s/scnearios/scenarios/ > a) multi-domain control of > security devices hosted on virtual and non-virtual ... >There is a noun missing after "virtual and non-virtual". Noun is NSFs > Hosted security service may instantiate NSFs in Virtual Machines > > >You probably don't want to capitalize "virtual machines" here. Changed. > To set-up this cross-domain service, the security controller must be > able to communicate with NSFs and/or controllers within its domain > and across domains to negatiate for the services needed. > s/set-up/set up/ ("set up" is a verb (more or less), "set-up" is the action of setting up or the thing which is set up.) The text should be "to set up" an infinitive verb setting up an infinitive clause, or it can be considered a prepositional phrase "to set up ..." Anyway, thank you for the editing. s/negatiate/negotiate/ 3.6. Software-Defined Networks > Software-Defined Networks have changed the landscape of data center > designs by introducing overlay networks deployed over ToR switches > that connect to a hypervisor. >You probably should spell out "ToR switch"; "top of rack switch" is not yet listed in Wikipedia as a meaning of "ToR". Start here ----------------- 4.1. Basic Framework > Integrity of the NSF: by ensuring that the NSF is not > compromised; > Isolation: by ensuring the execution of the NSF is self-contained > for privacy requirements in multi-tenancy scenarios. > Provenance of NSF: Customers may need to be provided with strict > guarantees about the origin of the NSF, its status (e.g., > available, idle, down, and others), and feedback mechanisms so > that a customer may be able to check that a given NSF or set of > NSFs properly conform to the the customer's requirements and > subsequent configuration tasks. >The punctuation and capitalization is inconsistent between the list items here. I suggest changing the first two to (more or less)\ >sentences: > > Integrity of the NSF: Ensuring that the NSF is not compromised. > > Isolation: Ensuring the execution of the NSF is self-contained > for privacy requirements in multi-tenancy scenarios. > >?Probably s/Provenance of NSF/Provenance of the NSF/. > > In order to achieve this, the security controller may collect > security measurements and share them with an independent and trusted > third party (via Interface 1) in order to allow for attestation of > NSF functions using the third party added information. > >Would this really be via Interface 1? It looks like Interface 1 only goes to the customer's client, not a 3rd party service, and it is used for passing security requests. This is made clearer in the next paragraph, but it would probably be better to only say that there needs to be an interface to 3rd parties for services like this, and it may be a variant of Interface 1 or it may be a distinct interface. Dale: While this make be clearer, it was the WGs final comments. I'll see what the IESG says. >4.2. Access Networks > Figure 3 shows how these virtual > access nodes for different types of customers connect connect through > virtual access nodes an NSF. > s/connect connect/connect/ >The grammar of the sentence needs fixing also somewhere near "nodes an NSF". Sue: Fixed > These use cases define the interaction between the operator and the > vNSFs through automated interfaces, typically by means of > Business- to-Business (B2B) communications. >Dale: Is "Business-to-Business (B2B) communications" a technical term? > It doesn't seem to me to convey any additional information, since most of the usages envision that NSFs may be provided by outside vendors, so pretty much any communication with an NSF may be business-to-business communication. New/These use cases define the interaction between the operator and the vNSFs through automated interfaces which support the business communications between customer and provider or between two business entities./ > Service Provider: Service requests for policies that protect ... > >There isn't a "Service Provider" illustrated in the figure. >I assume that the Service Provider looks much like the other three cases, >since those look very much like each other, but some sort of > illustration should be provided. Especially if the Service Provider > has further customers (presumably further to the left in the figure), that would be a more complex architecture. Sue: Service Provider added to the network > ... may want to get > their dedicated NSFs (most likely vNSFs) for direct control purposes. >This is rather informal usage. Perhaps better: > ... may want to contract separately for dedicated NSFs ... Sue: Thank you - changed. > In this case, here are the steps to associate vNSFs to specific > customers: >There are two cases discussed in the paragraph before this sentence, >and it's not obvious which one this sentence is connected to via "In this case". >Or does it apply to both? If it applies to the second case only, >I suggest splitting the last two sentences off as a separate paragraph. >If this sentence applies to all cases in this subsection, I suggest removing "In this case". Done - split off the second 2 sentences. >4.3. Cloud Data Center Scenario > > The on-demand, dynamic nature of security service delivery > essentially encourages that the network security "devices" be in > software or virtual form factors, rather than in a physical appliance > form. >I think you want to s/form factors/forms/. (The phrase "form factor" >seems to be abused to mean many things.) Done - corrected to "forms" > Another example is that IPS/ > IDS services for investment banking and non-banking traffic may be > separated for regulatory reasons. > Is "investment banking" specific here, or does this statement also apply to "banking" generally? Or is "non-banking traffic" really "non-investment-banking traffic" (in which case calling it "other traffic" is probably better)? Sue: Good point. New / Another example is that IPS/IDS services which splits traffic into investment banking traffic and other data traffic to comply with regulatory restrictions for transfer of investment banking information/ >4.3.2. Firewall Policy Deployment Automation > > Even though most vendors support similar firewall features, the > actual rule configuration keywords are different from vendors to > vendors, making it difficult for automation. > >Probably s/actual rule/specific rule/ or even just "specific". Sue: New/ Even though most vendors support similar firewall features, the specific rule configuration keywords are different from vendors to vendors, making it difficult for automation. / 4.3.3. Client-Specific Security Policy in Cloud VPNs / Clients of service provider-operated cloud data centers not only need / to secure Virtual Private Networks (VPNs), but also [X] virtual security / functions that apply the clients' security policies. /There's an understood verb at the location marked [X]. I think it's supposed to be "to secure", and if so, the usage is correct. But it's hard to read, so I think it would be better to not omit the verb. Sue: You are right. The negation in the sentence makes this difficult. New /Clients of service provider-operated cloud data centers need to secure Virtual Private Networks (VPNs) and virtual security functions that apply the clients' security policies./ Now the direct objection into a list (VPNs + virtual security functions). 4.4. Preventing Distributed DoS, Malware and Botnet attacks > Many networks such as Internet of > Things (IoT) networks, Information-Centric Networks (ICN), Content > Delivery Networks (CDN), Voice over IP packet networks (VoIP), and > Voice over LTE (VoLTE) are also exposed to such attacks. > >This seems to be just a specialization of the preceding sentences. >Does it add more information? >(E.g., perhaps there are special considerations for each of these types of networks, in which case it might be useful to state that.) Changed to:/ Many networks which carry groups of information (such as Internet of Things (IoT) networks, Information-Centric Networks (ICN), Content Delivery Networks (CDN), Voice over IP packet networks (VoIP), and Voice over LTE (VoLTE)) are also exposed to such remote attacks. There are many examples of remote attacks on these networks, but the following examples will illustrate the issues. A malware attack on an IoT network which carries sensor readings and instructions may attempt to alter the sensor instructions in order to disable a key sensor. A malware attack VoIP or VoLTE networks is software that attempts to place unauthorized long-distance calls. Botnets may overwhelm nodes in ICN and CDN networks so that the networks cannot pass critical data. / 4.5. Regulatory and Compliance Security Policies >Organizations are not only supposed to protect their networks against >attacks, but they should also adhere to various industry >regulations: >It's probably better to s/should also/must also/! Thanks for noticing. 7. Security Considerations >Having a secure access to control and monitor NSFs is crucial for > hosted security services. >Probably s/a secure/secure/. > Therefore, proper secure communication > channels have to be carefully specified for carrying controlling and > monitoring traffic between the NSFs and their management entity (or > entities). >I think you can condense this to "management entity(ies)", but you probably should talk to the RFC Editor about it. I will ask the RFC Editor about this point. >> In addition, the Flow security policies specified by customers can >> conflict with providers' internal security policies which may allow >> unauthorized traffic or unauthorized changes to flow polices (e.g. >> customers changing flow policies that do not belong to them). >I don't think you want to capitalize "flow" here. Agreed, >It's not clear to me what "which may allow unauthorized ..." applies to. It seems like there's an important issue in just > In addition, the Flow security policies specified by customers can > conflict with providers' internal security policies > >It seems that solving I2NSF requires a clear understanding of how the customer's policies and the provider's policies interact. (I would think something is allowed only if both policies allow it, but the reality may be more complex.) >The rest of the sentence seems redundant given the discussion in the rest of document. > > Therefore, it is crucial to have proper AAA [RFC2904] to authorize > access to the network and access to the I2NSF management stream. > >It seems to me that this is a rather generalized need for I2NSF, and not connected to the previous sentences. So I would omit "Therefore" >and put it as a separate paragraph. Good catch. _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Mon Apr 10 08:55:07 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1010A12955A; Mon, 10 Apr 2017 08:55:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149183970602.3077.691012552943496445@ietfa.amsl.com> Date: Mon, 10 Apr 2017 08:55:06 -0700 Archived-At: Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-problem-and-use-cases-12.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:55:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to Network Security Functions of the IETF. Title : I2NSF Problem Statement and Use cases Authors : Susan Hares Diego R. Lopez Myo Zarny Christian Jacquenet Rakesh Kumar Jaehoon Paul Jeong Filename : draft-ietf-i2nsf-problem-and-use-cases-12.txt Pages : 28 Date : 2017-04-10 Abstract: This document is the problem statement for Interface to Network Security Functions (I2NSF) as well as some companion use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-12 https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-problem-and-use-cases-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-problem-and-use-cases-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 10 11:18:38 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF92129502; Mon, 10 Apr 2017 11:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 7csl9Mrn5uCK; Mon, 10 Apr 2017 11:18:32 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96AC12947E; Mon, 10 Apr 2017 11:18:31 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3AIIIBA026094; Mon, 10 Apr 2017 19:18:19 +0100 Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3AIIFxJ026066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2017 19:18:17 +0100 Reply-To: From: "Adrian Farrel" To: "'Susan Hares'" , "'Dale Worley'" Cc: , References: <148952979419.24295.8210647087024239014@ietfa.amsl.com> <00fb01d2b20c$4182ab80$c4880280$@ndzh.com> In-Reply-To: <00fb01d2b20c$4182ab80$c4880280$@ndzh.com> Date: Mon, 10 Apr 2017 19:18:16 +0100 Message-ID: <004301d2b226$d53cf910$7fb6eb30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGutpg0SXJzXob6/wPiGXgr+oPIOgGqJ4NzofmO9dA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22998.002 X-TM-AS-Result: No--38.406-10.0-31-10 X-imss-scan-details: No--38.406-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFqnykMun0J1wvHkpkyUphL9Ud7Bjfo+5jT8bD+4PAZXi8HM 7omNQ6mPq03l+sq3oX/ejIKemsMsDVlOqKNI2QkGvHKClHGjjr3BErlOTfHjCsLDTLpTjMJ3oCy y4pUARDd4a68pNxoKIH1X8uGvwCuC8Nk4qYUuW8hwUSK4/EeOxTIaJpKzSfrs2hV8jMmGLDQDuw Qv5f82WHdl8cmhdAVwI8UVBDAyPnq5XqTmH3jzrdcjCbPZgQnF6Jj6zYvfFATjsTquy0JRi8YR+ i1NmBQl2ZOtE1CE989XEkxN3utneOFey8O38FDPdiLDwvWethiWVaHO6LheVWecrqZc3vabHo5w Mef4pjfYK7fnL8T5InudmZKCXGD2t/u7j6qyAO9bd1zMnVGjF9tb21l1J0jcJHCYQwMS7BnSjgo INhqipeOeSd9SIGnwnIG5RvYyUn2l05pvXTeRR5/ETtb6upYl9l9p8mNlkgnxxaAXDrCnszxs6S hzEml76S7c1c/4s1TcrmvysJppxTurH0qx1kBYVU3yVpaj3QyhZMTEKbB3flpbYq2f4jz+lUNmx PSthYKR6mkkcyBSSQgW2b7mHW7HBns/ppvOO7pz5CFYokzTg6APS3vFyaW6y2AfkkgSmXMX3fxV 7jdRyTXyAOBIcGE57+46SmoCLG6rxbGELyJP0x47EGkpGeA9eFyzQYzPQ+SrzPs85fwUkxSj+G9 s2jV9B4XlsWI+zD+FeweRLJS5btTO9w9KisCUEmjYWS3nO0BKFU+QqbaW+slXhVyLNg5t3/ZVsr HDi8rVpyR2KoGTx9U65J3foW7bzADlhR5/wkeeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jgfCfWl nNb/1cppCzPq+1UkGUtrowrXLg= Archived-At: Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 18:18:37 -0000 Thanks Sue! Adrian > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Susan Hares > Sent: 10 April 2017 16:08 > To: 'Dale Worley'; gen-art@ietf.org > Cc: i2nsf@ietf.org; ietf@ietf.org; draft-ietf-i2nsf-problem-and-use- > cases.all@ietf.org > Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11 > > Dale: > > Thank you for the review. Please see my comments below. > > Sue > > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Dale Worley > Sent: Tuesday, March 14, 2017 6:17 PM > To: gen-art@ietf.org > Cc: i2nsf@ietf.org; ietf@ietf.org; > draft-ietf-i2nsf-problem-and-use-cases.all@ietf.org > Subject: [I2nsf] Review of draft-ietf-i2nsf-problem-and-use-cases-11 > > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > Document: draft-ietf-i2nsf-problem-and-use-cases-11 > Reviewer: Dale R. Worley > Review Date: 2017-03-14 > IETF LC End Date: 2017-03-22 > IESG Telechat date: [unknown] > > Summary: > > This draft is basically ready for publication, but has nits > that should be fixed before publication. > > All of these nits are editorial. > > >1. Introduction > > > > This document describes the problem statement for Interface to > > Network Security Functions (I2NSF) as well as some I2NSF use cases. > > A summary of the state of the art in the industry and IETF which is > > relevant to I2NSF work is documented in > > [I-D.hares-i2nsf-gap-analysis]. > > >The content of these sentences is very good, but the construction seems to > be peculiar. The document doesn't *describe* the problem statement, the > document *is* a statement. Similarly, hares-i2nsf-gap-analysis *is* a > summary of the state of the art. >So I would use > > > > This document is the problem statement for Interface to Network > > Security Functions (I2NSF) as well as some I2NSF use cases. A > > summary of the state of the art in the industry and IETF which is > > relevant to I2NSF work is [I-D.hares-i2nsf-gap-analysis]. > > Dale > > >But maybe you'll prefer to ask the RFC Editor. > > > > This document also briefly describes the > > following use cases summarized by > > [I-D.pastor-i2nsf-merged-use-cases]: > > > >This sentence should start a new paragraph, as it's not connected to the > sentences before it. > > Thank you for finding these errors. I also needed to change > I-D.hares-i2nsf-gap-analysis to draft-ietf-i2nsf-gap-analysis. > > > >3. Problem Space > > > > The following sub-section describes ... > >s/sub-section describes/sub-sections describe/ > > Thank you - sorry to have missed it. > > >3.1.1. Diverse Types of Security Functions > > > > NSFs by different vendors can have > > different features and have different interfaces. > > > >It might be worth mentioning somewhere what seems to be a convention: > >the document (or at least, section 3.1) is largely oriented toward "service > providers" who sell comprehensive network services (including security > functions) to "customers", but who in turn buy security functions from > "vendors". Perhaps this could be ?>entered as terminology in section 2. > > > >The reason I mention this is that my background is as an end-user (which is > common in the IETF), so the term "service provider" > >Triggers in my mind the idea "someone I buy something from". And the term > "vendor" triggers the *same* idea. But in this draft, the default reader is > a "service provider" and "vendor" is *not* the same thing. > > I've added this text: Security Service Provider: A provider of security > services to the customers (end-users or enterprises) using NSF equipment > purchased from vendors or created by the service provider. > > >This point started to confuse me at the beginning of section 3.1.6. > > > > Security Functions in a Demilitarized Zone (DMZ): Examples of this > > function are firewall/ACLs, IDS/IPS, one or all of AAA services > > NAT, forwarding proxies, and application filtering. > > The phrase "one or all of AAA services NAT" seems to be incorrect. I > suspect there's supposed to be a comma before NAT. > > Good catch. I will fix. > > > Security gateways and VPN concentrators: Examples of these > > functions are; IPsec gateways, Secure VPN concentrators that > > handle bridging secure VPNs, and Secure VPN controllers for data > > flows. > > > Unless "Secure VPN" is a name in itself, "secure" shouldn't be > capitalized. > > Good point. I will fix. > > > 3.1.2. Diverse Interfaces to Control and Monitor NSFs > > > > A challenge for monitoring is that an NSF cannot monitor what it > > cannot view. Therefore, enabling a security function (e.g., firewall > > [I-D.ietf-opsawg-firewalls]) does not mean that a network is > > protected. As such, it is necessary to have a mechanism to monitor > > and provide execution status of NSFs to security and compliance > > management tools. There exist various network security monitoring > > vendor-specific interfaces for forensics and troubleshooting. > > > This paragraph seems awkward. Each sentence is reasonable, but the > connection between them is not clear to me. > > Perhaps the third sentence has the meaning "... it is necesary to have a > mechanism ...to verify that the NSF is seeing the traffic that is intended". > >The last sentence contains "network security monitoring vendor-specific > interfaces" which is awkward. Perhaps > > > > There exist various vendor-specific interfaces for network security > > monitoring, forensics, and troubleshooting. > > New paragraph is below. Is it better > > New/ > A challenge for monitoring prior to mitigation of a security intrusion > is that an NSF cannot monitor what it cannot view. Therefore, enabling a > security function to mitigate an intrusion > (e.g., firewall ) > does not mean that a network is protected if there is no monitoring > feedback. > As such, it is necessary to have a mechanism > to monitor and provide execution status of NSFs to security and > compliance management tools. There exist various network security > monitoring vendor-specific interfaces for forensics and > troubleshooting, but an industry standard interface could > provide monitoring across avariety of NSFs. > / > > > > 3.1.4. More Demand to Control NSFs Dynamically > > > The Security Service Providers ... > > >The capitalization of "security service providers" is inconsistent. > > Some times all three words are capitalized, and some times they're not. > Thanks for catching this - I will fix it. > > 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs > > > Service providers may need several operational units to control and > > monitor the NSFs, especially when NSFs become distributed and > > virtualized. > > > > You may want to explain what an "operational unit" is. As far as I can > tell, neither "unit" nor "operational" (in this sense) is used elsewhere in > this draft. > > Thanks for catching this vagueness. > The point the service provides may have to deploy multiple controllers. > > How about: > > Service providers may need to deploy several NSF controllers to control and > monitor the NSFs, especially when NSFs become distributed and > virtualized. > > >3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles > > Many security functions depend on signature files or profiles to > > perform (e.g., IPS/IDS signatures, DDos Open Threat Signaling > > (DOTS) filters). > >I think the words "to perform" should be removed. The sentence makes more > sense to me without those. Or, if there is a meaning that needs to be > specified, "to perform" probably >isn't the right choice. "to work" makes > sense in this place, but is an informal usage. Perhaps "to function". > > [removed "to perform") > > > Today, the construction and use of black list databases > > can be a win-win strategy for all parties involved. > >"win-win strategy" is a hackneyed phrase. This is better > > > Today, the construction and use of black list databases > > can be beneficial for all parties involved. > > >However, it's not clear to me what additional information is carried by > "for all parties involved". And for that matter, is "today" > >important here? > >I suspect that you mean something like this: > > > > Today, black list databases can be beneficial, and in the future > > there might be open source signatures/profiles ... > > > > > (e.g., by Snort, Suricata, Bro and Kisnet) > > > >s/Kisnet/Kismet/ > >"Snort, Suricata, Bro and Kisnet" reads like a reference -- I had to look > them up to discover that they are IDS software! > > > >But there needs to be some connection between a list of IDS software > systems and "open source signatures/profiles". Perhaps: > > > > Today, black list databases can be beneficial, and in the future > > there might be open source signatures/profiles distributed as part > > of IDS systems (e.g. Snort, Suricata, Bro and Kisnet). > > All good comments, but my recollection was the WG wanted to underscore the > strategy was good for all parties. > Therefore, here's the new paragraph > > > New/ > Today, black list databases can be a beneficial > strategy for all parties involved, but in the future there might be > open Source-provided signature/profiles distributed as part of IDS systems > (e.g., by Snort, Suricata, Bro and Kismet). > / > -- > >There is a need to have a standard envelope (i.e., the format) to > > allow NSFs to use external profiles. > >This is awkward. Perhaps > > There is a need to have a standard format to allow NSFs to use > > external profiles. > > This part hit many discussions. How about > > New/ There is a need to have a standard envelope (i.e., a message format) to > > allow NSFs to use external profiles./ > > >3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger ... > > > > I2NSF controller(s) would manage the changing to the affected > > policies ... > > This could be simplified to "I2NSF controller(s) would change the affected > policies ...". > > New/ I2NSF controller(s) would control any changes to affected policies > (e.g., forwarding and routing, filtering, etc.)./ > > >The I2NSF controls the change (whether others change the policies or not). > > By monitoring the network alerts from DDoS ... > >Probably s/DDoS/DOTS/. > > > > ... I2NSF > > can feed an alerts analytics engine that could recognize attacks so > > the I2NSF can enforce the appropriate policies. > > Here, "I2NSF" is being used as a noun, whereas the previous usage is that > it is an adjective, and "I2NSF controller(s)" would be used. > > New/ > By monitoring the network alerts regarding DDoS attacks (e.g. from DOTS > servers or clients), > the I2NSF controller(s) can feed an alerts analytics engine > that could recognize attacks so the I2NSF can enforce the > appropriate policies. > / > > > > ... provide information to the client ... > > > >I think this is clearer if s/the client/its clients/. "client" is used > with two meanings, one is "customer" (e.g., in the definition of "Bespoke"), > and more commonly as "software client". > If you say "[the controller's] > clients", it is clear that you're using the second meaning. > > New/ DDoS mitigation is enhanced if the provider's network security > controller can monitor, analyze, and investigate the abnormal > events > and provide information to the customer or change the network > configuration automatically > / > > >3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs > > > > There is a need for a controller to distribute various keys to > > distributed NSFs. To distribute various keys, the keys must be > > created and managed. > > >Perhaps combine these as > > > > There is a need for a controller to create, manage, and distribute > > various keys to distributed NSFs. > > I've made this change. > > > > In addition, keys may be used to secure > > the protocol and messages in the core routing infrastructure (see > > [RFC4948]) > > >Probably s/protocol/protocols/. > > > I've made this change. > > > If a device had an abstract key table > > maintained by security services, a device could use these keys for > > routing and seurity devices. > > > >s/seurity/security/ > > > >Typical English usage in this situation is "it could use ..."; because "it" > is the subject of the second clause, it is presupposed to be the same as the > subject of the first clause. > > New sentences: > / If a device had an abstract key table maintained by security services, it > could use these > keys for routing and security devices. / > > > Conceptually, there must be an interface defined for routing/ > > signaling protocols to make requests for automated key management > > when it is being used, and to notify the protocols when keys become > > available in the key table. One potential use of such an interface > > is to manage IPsec security associations on SDN networks. > >I think you need to add a subject in "... and for XXX to notify the > protocols ..." for clarity, the omitted noun could be "interface" or > "protocols". > > Grammatically - I disagree . The clauses "to make request...." and "to > notify" are infinitive clauses which modify the direct object (an interface) > which are linked together in a list. > However, rather than debate this syntax with others - I've changed the > syntax to a cl > > New/ > Conceptually, there must be an interface defined for routing/signaling > protocols > that can: a) make requests for automated key management when it is being > used. and > b) notify the protocols when keys become available in the key table. > / > > > >The last sentence seems redundant, as security associations have been > discussed at the beginning of 3.1.9. Is there a particular reason to point > out IPsec at this point (since many >secured protocols need keys)? > > The WG felt it needed an example here. If it is OK, I'm going to leave > this in for another round of editing. > > > If protocols share > > common mechanisms for authentication (e.g., TCP Authentication > > Option [RFC5925]), then the same mapping may be reused. > > >This sentence starts with "protocols [that] share common mechanisms" > >but then mentions only one protocol. Do you mean > > > If several protocols share a > > common mechanism for authentication (e.g., TCP Authentication > > Option [RFC5925]), then the same mapping may be used for all > > usages of that mechanism. > > > Thank you. I've changed to this sentence. > > > > 3. Automated Key management needs to support both symmetric keys and > > group keys via the abstract key service provided by items 1 and > > 2. > >s/Key/key/ > > --Thank you. > > >I think "via the abstract key service provided by items 1 and 2" is > redundant here. > > It may be redundant, but as I recall it was important to some of the > authors. > -------------- > > 3.2. Challenges Facing Customers > > > o Which critical communications are to be preserved during critical > > events and which hosts are continue service, > > > >"are continue service" seems to be incorrect in some way. > > New/Which critical communications are to be preserved during > critical events and which hosts will continue services over the > network,/ > > > > o What signaling information is passed to a controller that during a > > Distributed Denial of Service in order to ask for mitigation > > services (within the scope DOTS working group), > > "that" should be removed, I think. > > Removed. > > >3.2.2. Today's Control Requests are Vendor Specific > > > > Without a standard technical > > standard interface that provides a clear technical characterization, > > the service provider faces many challenges: > > >Should "standard technical standard interface" be "standard interface" > >or "standardized interface"? > > >Standardized interface. > > No standard technical characterization, APIs, or Interface > >I think you want a colon after this phrase to parallel the other items in > the list. > > Thank you. > > > Managing by scripts de-jour: The current practices rely upon the > > use of scripts that generate other scripts which automatically run > > to upload or download configuration changes, log information and > > other things. These scripts have to be adjusted each time an > > implementation from a different vendor technology is enabled on a > > provider side. > > The phrase "on a provider side" doesn't read well. Perhaps "by a service > provider"? > > 3.3. Lack of Standard Interface to Inject Feedback to NSF > > > The following sub-section describes the problems and challenges > > facing customers and security service providers when some or all of > > the security functions are no longer physically hosted by the > > customer's adminstrative domain. > >s/adminstrative/administrative/ > > Note: Sentence was removed. > > > As more sophisticated threats arise, enterprises, vendors, and > > service providers have to rely on each other to achieve optimal > > protection. Cyber Threat Alliance (CTA, > > http://cyberthreatalliance.org/) is one of those initiatives that aim > > at combining efforts conducted by multiple organizations. > > >This paragraph doesn't fit well in the flow of the text. The second > sentence seems like it's basically a reference, and the link should be put > down in the references. But I think the >point resembles the discussion in > 3.1.7, that you want to enable organizations to pass among themselves new > profiles, which the customers or service providers can insert into NSFs > in > a simple way. Perhaps > > > As more sophisticated threats arise, protection will depend > > on enterprises, vendors, and service providers being able to > > cooperate to develop optimal profiles, e.g., through initiatives > > like [CTA]. > > >and then combine with the paragraph which follows: > > > > The standard interface to provide security profiles to the NSF should > > interwork with the formats which exchange security profiles between > > organizations. > > 3.5. Difficulty to Validate Policies across Multiple Domains > > >As discussed in the previous four sections, both service providers ... > > >Probably s/sections/sub-sections/. > > ... and customers have needs to express policies and profiles ... > > > >s/needs/need/ > > > > This section and the next section (section 3.6) xamine what ... > >s/xamine/examine/ > > > (Have you spell-checked this draft?) > > Not this one. I'm afraid I rushed the -11 out in response to query. I > lived to regret this fact. > > > > > > ... happens in two specific network scnearios: ... > > s/scnearios/scenarios/ > > > a) multi-domain control of > > security devices hosted on virtual and non-virtual ... > >There is a noun missing after "virtual and non-virtual". > > Noun is NSFs > > > Hosted security service may instantiate NSFs in Virtual Machines > > > > > >You probably don't want to capitalize "virtual machines" here. > > Changed. > > > > To set-up this cross-domain service, the security controller must be > > able to communicate with NSFs and/or controllers within its domain > > and across domains to negatiate for the services needed. > > > s/set-up/set up/ ("set up" is a verb (more or less), "set-up" is the > action of setting up or the thing which is set up.) > > The text should be "to set up" an infinitive verb setting up an infinitive > clause, or it can be considered a prepositional phrase "to set up ..." > Anyway, thank you for the editing. > > s/negatiate/negotiate/ > > 3.6. Software-Defined Networks > > > Software-Defined Networks have changed the landscape of data center > > designs by introducing overlay networks deployed over ToR switches > > that connect to a hypervisor. > > >You probably should spell out "ToR switch"; "top of rack switch" is not yet > listed in Wikipedia as a meaning of "ToR". > > > Start here > ----------------- > 4.1. Basic Framework > > > Integrity of the NSF: by ensuring that the NSF is not > > compromised; > > > Isolation: by ensuring the execution of the NSF is self-contained > > for privacy requirements in multi-tenancy scenarios. > > Provenance of NSF: Customers may need to be provided with strict > > guarantees about the origin of the NSF, its status (e.g., > > available, idle, down, and others), and feedback mechanisms so > > that a customer may be able to check that a given NSF or set of > > NSFs properly conform to the the customer's requirements and > > subsequent configuration tasks. > >The punctuation and capitalization is inconsistent between the list items > here. I suggest changing the first two to (more or less)\ > >sentences: > > > > Integrity of the NSF: Ensuring that the NSF is not compromised. > > > > Isolation: Ensuring the execution of the NSF is self-contained > > for privacy requirements in multi-tenancy scenarios. > > > >?Probably s/Provenance of NSF/Provenance of the NSF/. > > > > In order to achieve this, the security controller may collect > > security measurements and share them with an independent and trusted > > third party (via Interface 1) in order to allow for attestation of > > NSF functions using the third party added information. > > > >Would this really be via Interface 1? It looks like Interface 1 only goes > to the customer's client, not a 3rd party service, and it is used for > passing security requests. This is made clearer in the next paragraph, but > it would probably be better to only say that there needs to be an interface > to 3rd parties for services like this, and it may be a variant of Interface > 1 or it may be a distinct interface. > > Dale: While this make be clearer, it was the WGs final comments. I'll see > what the IESG says. > > > >4.2. Access Networks > > > Figure 3 shows how these virtual > > access nodes for different types of customers connect connect through > > virtual access nodes an NSF. > > s/connect connect/connect/ > >The grammar of the sentence needs fixing also somewhere near "nodes an > NSF". > > Sue: Fixed > > > These use cases define the interaction between the operator and the > > vNSFs through automated interfaces, typically by means of > > Business- to-Business (B2B) communications. > >Dale: Is "Business-to-Business (B2B) communications" a technical term? > > It doesn't seem to me to convey any additional information, since most of > the usages envision that NSFs may be provided by outside vendors, so pretty > much any communication with an NSF may be business-to-business > communication. > > New/These use cases define the interaction between the operator and the > vNSFs through automated interfaces which support the business > communications > between customer and provider or between two business entities./ > > > Service Provider: Service requests for policies that protect ... > > > >There isn't a "Service Provider" illustrated in the figure. > >I assume that the Service Provider looks much like the other three cases, > >since those look very much like each other, but some sort of > > illustration should be provided. Especially if the Service Provider > > has further customers (presumably further to the left in the figure), that > would be a more complex architecture. > > Sue: Service Provider added to the network > > > ... may want to get > > their dedicated NSFs (most likely vNSFs) for direct control purposes. > >This is rather informal usage. Perhaps better: > > > ... may want to contract separately for dedicated NSFs ... > > Sue: Thank you - changed. > > > In this case, here are the steps to associate vNSFs to specific > > customers: > >There are two cases discussed in the paragraph before this sentence, > >and it's not obvious which one this sentence is connected to via "In this > case". > >Or does it apply to both? If it applies to the second case only, > >I suggest splitting the last two sentences off as a separate paragraph. > >If this sentence applies to all cases in this subsection, I suggest > removing "In this case". > > Done - split off the second 2 sentences. > > >4.3. Cloud Data Center Scenario > > > > The on-demand, dynamic nature of security service delivery > > essentially encourages that the network security "devices" be in > > software or virtual form factors, rather than in a physical appliance > > form. > > >I think you want to s/form factors/forms/. (The phrase "form factor" > >seems to be abused to mean many things.) > > Done - corrected to "forms" > > > Another example is that IPS/ > > IDS services for investment banking and non-banking traffic may be > > separated for regulatory reasons. > > > Is "investment banking" specific here, or does this statement also apply > to "banking" generally? Or is "non-banking traffic" really > "non-investment-banking traffic" (in which case calling it "other traffic" > is probably better)? > > Sue: Good point. > New / > Another example is that IPS/IDS services which splits traffic into > investment banking traffic and other data traffic to comply with > regulatory restrictions for transfer of investment banking information/ > > >4.3.2. Firewall Policy Deployment Automation > > > > Even though most vendors support similar firewall features, the > > actual rule configuration keywords are different from vendors to > > vendors, making it difficult for automation. > > > >Probably s/actual rule/specific rule/ or even just "specific". > > Sue: > New/ > Even though most vendors support similar firewall features, the > specific rule configuration keywords are different from vendors to > vendors, making it difficult for automation. > / > > 4.3.3. Client-Specific Security Policy in Cloud VPNs > > / Clients of service provider-operated cloud data centers not only need > / to secure Virtual Private Networks (VPNs), but also [X] virtual security > / functions that apply the clients' security policies. > /There's an understood verb at the location marked [X]. I think it's > supposed to be "to secure", and if so, the usage is correct. But it's hard > to read, so I think it would be better to not omit the verb. > > Sue: You are right. The negation in the sentence makes this difficult. > > New /Clients of service provider-operated cloud data centers > need to secure Virtual Private Networks (VPNs) and virtual > security functions that apply the clients' security policies./ > > Now the direct objection into a list (VPNs + virtual security functions). > > > 4.4. Preventing Distributed DoS, Malware and Botnet attacks > > > Many networks such as Internet of > > Things (IoT) networks, Information-Centric Networks (ICN), Content > > Delivery Networks (CDN), Voice over IP packet networks (VoIP), and > > Voice over LTE (VoLTE) are also exposed to such attacks. > > > >This seems to be just a specialization of the preceding sentences. > >Does it add more information? > >(E.g., perhaps there are special considerations for each of these types of > networks, in which case it might be useful to state that.) > > Changed to:/ > Many networks > which carry groups of information (such as Internet of Things (IoT) > networks, > Information-Centric Networks (ICN), Content Delivery Networks (CDN), > Voice over IP packet networks (VoIP), and Voice over LTE (VoLTE)) > are also exposed to such remote attacks. There are many examples of > remote attacks on these networks, but the following examples will illustrate > the > issues. A malware attack on an IoT network which carries sensor readings and > instructions may attempt to > alter the sensor instructions in order to disable a key sensor. > A malware attack VoIP or VoLTE networks is software that attempts to place > unauthorized > long-distance calls. Botnets may overwhelm nodes in ICN and CDN networks so > that > the networks cannot pass critical data. > / > > 4.5. Regulatory and Compliance Security Policies > > >Organizations are not only supposed to protect their networks against > >attacks, but they should also adhere to various industry > >regulations: > >It's probably better to s/should also/must also/! > > Thanks for noticing. > > 7. Security Considerations > > >Having a secure access to control and monitor NSFs is crucial for > > hosted security services. > >Probably s/a secure/secure/. > > > Therefore, proper secure communication > > channels have to be carefully specified for carrying controlling and > > monitoring traffic between the NSFs and their management entity (or > > entities). > > >I think you can condense this to "management entity(ies)", but you probably > should talk to the RFC Editor about it. > > I will ask the RFC Editor about this point. > > > >> In addition, the Flow security policies specified by customers can > >> conflict with providers' internal security policies which may allow > >> unauthorized traffic or unauthorized changes to flow polices (e.g. > >> customers changing flow policies that do not belong to them). > >I don't think you want to capitalize "flow" here. > > Agreed, > > >It's not clear to me what "which may allow unauthorized ..." applies to. > It seems like there's an important issue in just > > In addition, the Flow security policies specified by customers can > > conflict with providers' internal security policies > > > >It seems that solving I2NSF requires a clear understanding of how the > customer's policies and the provider's policies interact. (I would think > something is allowed only if both policies allow it, but the reality may be > more complex.) > > >The rest of the sentence seems redundant given the discussion in the rest > of document. > > > > Therefore, it is crucial to have proper AAA [RFC2904] to authorize > > access to the network and access to the I2NSF management stream. > > > >It seems to me that this is a rather generalized need for I2NSF, and not > connected to the previous sentences. So I would omit "Therefore" > >and put it as a separate paragraph. > > Good catch. > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf From nobody Tue Apr 11 11:26:09 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5F5129649; Tue, 11 Apr 2017 11:26:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 11:26:06 -0700 Archived-At: Subject: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:26:07 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document should be informational. I don't see any reason that this document must be cited normatively by all following document of this wg (as indicated in the shepherd write-up) and even if so that does not justify publication as Standards track if the information in the document is only informational. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As soon as my discuss is resolved I will change to 'Abstain' as I don't see value in the publication of this document. I can see that this document was useful for discussion in the working group but I don't know why it needs to be published as RFC. Also there is quite some redundancy everywhere in the document aa well as between the problem statement and use case part. Spelling out requirements for the protocol design based on the analysis of these problems and use cases (which was already a bit attempted from time to time in the doc) would have been more useful but does still not have an archivable value that justifies publication as RFC in the IETF stream (indicating IETF consensus). From nobody Tue Apr 11 11:34:40 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612A312EBCE; Tue, 11 Apr 2017 11:34:30 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 Sk4uLnHyV5t7; Tue, 11 Apr 2017 11:34:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40ABD12EBED; Tue, 11 Apr 2017 11:34:21 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3BIYIov018514; Tue, 11 Apr 2017 19:34:18 +0100 Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3BIYGuV018502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2017 19:34:17 +0100 Reply-To: From: "Adrian Farrel" To: "=?utf-8?Q?'Mirja_K=C3=BChlewind'?=" , "'The IESG'" Cc: , , References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> In-Reply-To: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 19:34:18 +0100 Message-ID: <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPxQa9DuYm0jMhf5hfvNuXa/BqqaHGWbRg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23000.001 X-TM-AS-Result: No--11.913-10.0-31-10 X-imss-scan-details: No--11.913-10.0-31-10 X-TMASE-MatchedRID: WMT2WRIkHPOnykMun0J1wovtmwtVGLEkJxBM/say9igvTa5XKXxtjOu8 ykIiv8CsMIZH9N34VaFEkoIXE55LN9Yfe9ARablSyKTEsCRIdyW36GGfwjLoZdp1biJhIyNRp7u eaEkDqTMZVo/zFzAyt82ls5FhrJqfTZWdcxHMgGOVUcz8XpiS9KwE/ma/sO5rgrAXgr/AjP0wLT 76CSwjkFeUb5vx9r5wXulhb9SxPH3qe192VL/v4M36paW7ZnForDEJQSM/J20R34ro7k23nTIfm 20Z3bid16I/GFps8QJljNliJG8RJLCul2XVVRIPLi5PDX0qWHoSw8czqIcvdmsTVziYHlSaFhMg ncTYqyRyk9gtyrrr7GuRi/mMYtyxCXZ8FQwqLpiiI3xhOar5yzUb/dhGoRHB0mAM2eipqlqF53Q d/vHkq6vwoPy4UoLI70Qm3YXk6Sy/WXZS/HqJ2lZ0V5tYhzdWxEHRux+uk8hUW0/J/LzLMKM0mg 9xJw+lokmnaz0A101ej6tTw1SvW60APn9X1kS6VICRhEmZ7EU= Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:34:30 -0000 Thanks Mirja, I think it is best that you discuss this topic with the rest of the IESG = and then we can be told what to do. (FWIW, I heard this conversation about 6 times in the 6 years I was on = the IESG and the opinion swung back and forth. The IESG I was on never = managed to get a clear position set down to guide the authors of future = documents. Perhaps you could write one?) Cheers, Adrian > -----Original Message----- > From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] > Sent: 11 April 2017 19:26 > To: The IESG > Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; = i2nsf- > chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org > Subject: Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12: > (with DISCUSS and COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This document should be informational. I don't see any reason that = this > document must be cited normatively by all following document of this = wg > (as indicated in the shepherd write-up) and even if so that does not > justify publication as Standards track if the information in the = document > is only informational. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > As soon as my discuss is resolved I will change to 'Abstain' as I = don't > see value in the publication of this document. I can see that this > document was useful for discussion in the working group but I don't = know > why it needs to be published as RFC. Also there is quite some = redundancy > everywhere in the document aa well as between the problem statement = and > use case part. Spelling out requirements for the protocol design based = on > the analysis of these problems and use cases (which was already a bit > attempted from time to time in the doc) would have been more useful = but > does still not have an archivable value that justifies publication as = RFC > in the IETF stream (indicating IETF consensus). From nobody Tue Apr 11 11:37:07 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F11212EBED; Tue, 11 Apr 2017 11:36:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193581951.15666.16044630513523846316.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 11:36:59 -0700 Archived-At: Subject: [I2nsf] Alvaro Retana's Abstain on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:36:59 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Mirja beat me to the DISCUSS; FWIW, I completely agree that, if published, this document should not be in the Standards Track.] Because this document only provides background on the problem space and some use cases, I don't think it has the long standing value to be published as an RFC (of any maturity level). Having a clear understanding of the problem and of the use cases is important for the eventual development of a solution, but in this case no specific path is clearly marked: the language includes a lot of "may be required/need/etc" not resulting in a strong basis to build a solution. I know that the i2nsf Charter gave the WG the option to not publish this document, and that it is being published anyway...so I won't stand in the way of publication and am ABSTAINing instead. From nobody Tue Apr 11 11:50:51 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7212A12EC2A; Tue, 11 Apr 2017 11:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=sxTIiTiI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l+98lAZ9 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 s0MkESQ0JZRo; Tue, 11 Apr 2017 11:50:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091E112EC2C; Tue, 11 Apr 2017 11:50:39 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 78F8420FAF; Tue, 11 Apr 2017 14:50:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 11 Apr 2017 14:50:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=YE8lrnqEaYLt5jS1RXEywd7+uRTJitu4Lel18ud+C B8=; b=sxTIiTiIZiJSU/dFrcWTfG3w7kGpY4ei3qz6x7uhudQWuPb7oYhZWWGJG HEtj3KkpZPY/QrM5aWLrEDFxH34Scn6lhXlSn/8scRuc0S0jwULQvma/PBBJ+bh9 Z54vqm+QSg4qMCY5ssEUTiw59sOaRdTs7eIJw77eZ4HjG2dWAAMx6Q+LMvcezCHc ptdcfZ+ssUdFhS/x7YsuSEbULUiOoHna9nlW1PP9ItyZE3nC59EQtIEiUHP8qgb1 9sYfIk85C4VgygybmkFJpw2e3782bTq+YveUhIxRn0p8pfr14pKy7lGWarbKWcqr yjnlryjwtSvsglTupkwC+uDhU4Kqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=YE8lrnqEaYLt5jS1RX Eywd7+uRTJitu4Lel18ud+CB8=; b=l+98lAZ9NIblhhqm4L3jjGjN1Kc+emoraJ ATecG9s769Cwy8m1D8cgEpkFWdd6zmYYbpJldGqvL9bW13QZP2OlrEnD+H18HV+c lBCVhy1D8yAjLhrgZYDOhYPWeBWZbXUIZJyF01Q1t4bjt/kTnW00Fk1E9Ju8KZay XKXZsuBbZiS7IzVHPUCX5GcH+MY/VsOCF2MrAGWOC3bRtcBJ8//UY8Uqj3u8L3Q6 zwA6Bhv6ffyPbIdKUbaxBXhHDFDTE2YsVskae3au7k9uHZ276fYAQzIAyz6wVM+q Jgy39X2oWLus9URdON4RIzfcssJlCCM99sfLrZQShPQBkT2QVSjQ== X-ME-Sender: X-Sasl-enc: r1w55GrLbijBdDVO9+pd4fDN6S2kKZDsh+3oc1tkXLY6 1491936637 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 076982464B; Tue, 11 Apr 2017 14:50:36 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_90431641-8A95-4E35-8F8C-9523E2511421" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> Date: Tue, 11 Apr 2017 14:50:35 -0400 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , IESG , i2nsf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases@ietf.org, i2nsf-chairs@ietf.org Message-Id: <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:50:43 -0000 --Apple-Mail=_90431641-8A95-4E35-8F8C-9523E2511421 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adrian, > On Apr 11, 2017, at 2:34 PM, Adrian Farrel = wrote: >=20 > Thanks Mirja, > I think it is best that you discuss this topic with the rest of the = IESG and then we can be told what to do. >=20 > (FWIW, I heard this conversation about 6 times in the 6 years I was on = the IESG and the opinion swung back and forth. The IESG I was on never = managed to get a clear position set down to guide the authors of future = documents. Perhaps you could write one?) We did, last year: = https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html = Alissa >=20 > Cheers, > Adrian >=20 >> -----Original Message----- >> From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] >> Sent: 11 April 2017 19:26 >> To: The IESG >> Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; = i2nsf- >> chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org >> Subject: Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12: >> (with DISCUSS and COMMENT) >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-i2nsf-problem-and-use-cases-12: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> This document should be informational. I don't see any reason that = this >> document must be cited normatively by all following document of this = wg >> (as indicated in the shepherd write-up) and even if so that does not >> justify publication as Standards track if the information in the = document >> is only informational. >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> As soon as my discuss is resolved I will change to 'Abstain' as I = don't >> see value in the publication of this document. I can see that this >> document was useful for discussion in the working group but I don't = know >> why it needs to be published as RFC. Also there is quite some = redundancy >> everywhere in the document aa well as between the problem statement = and >> use case part. Spelling out requirements for the protocol design = based on >> the analysis of these problems and use cases (which was already a bit >> attempted from time to time in the doc) would have been more useful = but >> does still not have an archivable value that justifies publication as = RFC >> in the IETF stream (indicating IETF consensus). >=20 >=20 --Apple-Mail=_90431641-8A95-4E35-8F8C-9523E2511421 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Adrian,

On Apr 11, 2017, at 2:34 PM, = Adrian Farrel <adrian@olddog.co.uk> wrote:

Thanks= Mirja,
I think it is best that you discuss this topic = with the rest of the IESG and then we can be told what to do.

(FWIW, I heard this conversation about 6 times = in the 6 years I was on the IESG and the opinion swung back and forth. = The IESG I was on never managed to get a clear position set down to = guide the authors of future documents. Perhaps you could write one?)


Alissa


Cheers,
Adrian

-----Original = Message-----
From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net]
Sent: 11 April = 2017 19:26
To: The IESG
Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian = Farrel; i2nsf-
chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org
Subject: Mirja K=C3=BChlewind'= s Discuss on draft-ietf-i2nsf-problem-and-use-cases-12:
(with DISCUSS and COMMENT)

Mirja = K=C3=BChlewind has entered the following ballot position for
draft-ietf-i2nsf-problem-and-use-cases-12: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-u= se-cases/



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

This document should be = informational. I don't see any reason that this
document = must be cited normatively by all following document of this wg
(as indicated in the shepherd write-up) and even if so that = does not
justify publication as Standards track if the = information in the document
is only informational.


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

As soon as my discuss is resolved I = will change to 'Abstain' as I don't
see value in the = publication of this document. I can see that this
document = was useful for discussion in the working group but I don't know
why it needs to be published as RFC. Also there is quite some = redundancy
everywhere in the document aa well as between = the problem statement and
use case part. Spelling out = requirements for the protocol design based on
the analysis = of these problems and use cases (which was already a bit
attempted from time to time in the doc) would have been more = useful but
does still not have an archivable value that = justifies publication as RFC
in the IETF stream = (indicating IETF consensus).


= --Apple-Mail=_90431641-8A95-4E35-8F8C-9523E2511421-- From nobody Tue Apr 11 12:46:15 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C25112FEE2; Tue, 11 Apr 2017 12:45:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193995723.15718.14667798074605160817.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 12:45:57 -0700 Archived-At: Subject: [I2nsf] Alissa Cooper's Abstain on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:45:57 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alvaro and Mirja. From nobody Tue Apr 11 12:55:33 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2734C130A92; Tue, 11 Apr 2017 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 GCTphA4pUUWS; Tue, 11 Apr 2017 12:55:30 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 A70C1130154; Tue, 11 Apr 2017 12:55:29 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id s16so3232085pfs.0; Tue, 11 Apr 2017 12:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eFFxZo6VwAFJnbSXTb1De+NKtKWg2vlQsI1Y42asK5c=; b=WAQnuZcoWB+ugwWUBBSdSadmVUBz/M6Ksi8P20QNnegVJA9mdC0B5TTpjiWju7amk5 Rc3LEA6s99BLNj6TmDqb21DMY1ydcS5nO2sovG1wroa8N2a5B3KoBXCZHKMw8yPh/VDJ 1MxDRGVwE3vEd9f07KoveFvu3grbUEZsoOVphWp1YHHOI/u4FikwlZDserEZ8N2NYvur Ctib4NtP8U7052V0s2aYmvRyw34stqsZGtAXZZ0O+s1yVT8y7IFp5y5IehoUkNdKyiai zODiKd/Kv9fzH9BONz3oQgq8l51FsnxA4kgSu7/BHR5s6JfC817ldpDqA4gVt6AaSemZ 6AQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eFFxZo6VwAFJnbSXTb1De+NKtKWg2vlQsI1Y42asK5c=; b=SUZ/2RnpRLxDhgrRIHm2KNzSazd5fWC4PsisQssrfvPc9lS+fjhnFHMdGnf9A9q4EB wc4TC7xDt3+89/rivPb/atfhVbMfZtp6qo34+LCZoNuEdbK5s6dnyFWImAdcFGTL5l/K Hx9nKJ1puSv1aR+wyeHcDCJINDUanU/MqfnN8PGR4cNRPr8ehwawJBrsXR8Yab56x9Oo fjZt2QsmQ15TEnoxT8Kvd/Irn/vgoQ+XU8GFfkwEvEw4XnzVHDg5bSpupMzMUxadL3T7 lCUUhJzylR1b3uVwPe8fCDWuLbLmN8AK0Jzu6raMEZoZJ+/mmZB+cclpYqJdJTovy7YG n/Qg== X-Gm-Message-State: AFeK/H2zNld6eF9hNgpkzG947Gg3eDcmt7ZJ+QJi9Jmn3Ppr/tVx/4dqF01445LlN3eGCwRwAiFM6SMlq3pScQ== X-Received: by 10.98.44.142 with SMTP id s136mr63460500pfs.244.1491940529202; Tue, 11 Apr 2017 12:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.139 with HTTP; Tue, 11 Apr 2017 12:54:48 -0700 (PDT) In-Reply-To: <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> From: Kathleen Moriarty Date: Tue, 11 Apr 2017 15:54:48 -0400 Message-ID: To: Alissa Cooper Cc: "adrian@olddog.co.uk" , "i2nsf@ietf.org" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IESG , i2nsf-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:55:32 -0000 Hi Adrian, I think it's pretty clear that this should go down to informational now. Thanks for raising the question and having the IESG weigh in as the published statement did not cover whether these support document should be informational only in nature. I do think that is the current opinion and that they are fine to publish if the WG would like to do so, but it's not encouraged. We could see about updating the statement to cover your point that support documents are to be informational. Thank you, Kathleen On Tue, Apr 11, 2017 at 2:50 PM, Alissa Cooper wrote: > Hi Adrian, > > On Apr 11, 2017, at 2:34 PM, Adrian Farrel wrote: > > Thanks Mirja, > I think it is best that you discuss this topic with the rest of the IESG = and > then we can be told what to do. > > (FWIW, I heard this conversation about 6 times in the 6 years I was on th= e > IESG and the opinion swung back and forth. The IESG I was on never manage= d > to get a clear position set down to guide the authors of future documents= . > Perhaps you could write one?) > > > We did, last year: > https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html > > Alissa > > > Cheers, > Adrian > > -----Original Message----- > From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] > Sent: 11 April 2017 19:26 > To: The IESG > Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; i2nsf= - > chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org > Subject: Mirja K=C3=BChlewind's Discuss on > draft-ietf-i2nsf-problem-and-use-cases-12: > (with DISCUSS and COMMENT) > > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This document should be informational. I don't see any reason that this > document must be cited normatively by all following document of this wg > (as indicated in the shepherd write-up) and even if so that does not > justify publication as Standards track if the information in the document > is only informational. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As soon as my discuss is resolved I will change to 'Abstain' as I don't > see value in the publication of this document. I can see that this > document was useful for discussion in the working group but I don't know > why it needs to be published as RFC. Also there is quite some redundancy > everywhere in the document aa well as between the problem statement and > use case part. Spelling out requirements for the protocol design based on > the analysis of these problems and use cases (which was already a bit > attempted from time to time in the doc) would have been more useful but > does still not have an archivable value that justifies publication as RFC > in the IETF stream (indicating IETF consensus). > > > > --=20 Best regards, Kathleen From nobody Tue Apr 11 14:20:55 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B44C71279E5; Tue, 11 Apr 2017 14:20:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149194565373.15662.3048610482760333306.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 14:20:53 -0700 Archived-At: Subject: [I2nsf] Deborah Brungard's Abstain on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:20:54 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Similar to other Abstains, I won't block publication but question the value, especially the current version to be published at this time. The document rambles on descriptions and it is not concise on the problem to be addressed by i2nsf. I recommend holding off on publication until it can be fine tuned, it currently appears to be a cut and paste of many documents. Examples, section 5 seems to summarize that i2nsf will only focus on policy provisioning. Yet, section 3.4 discusses capability negotiation and 3.1.2 discusses monitoring mechanisms and execution status of NSFs capabilities. And other sections also infer much more, describing expectations of security controller functionality. There are several rather overzealous claims: Section 4.4 "botnet attacks could be easily prevented by provisioning security policies using the i2nsf..interface" and section 4.5 "security controller would keep track of ..if there is any policy violation ..proof..in full compliance with the required regulations". Several sentences don't parse e.g. "thereby raising concerns about the ability of SDN computation logic to send security policy-provisioning information to the participating NSFs". From nobody Tue Apr 11 14:53:44 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4915127B52; Tue, 11 Apr 2017 14:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 0fcibWNtxhGi; Tue, 11 Apr 2017 14:53:42 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 18B2B12706D; Tue, 11 Apr 2017 14:53:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.89.24; From: "Susan Hares" To: "'Kathleen Moriarty'" , "'Alissa Cooper'" Cc: , =?utf-8?Q?'Mirja_K=C3=BChlewind'?= , "'IESG'" , , , References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> In-Reply-To: Date: Tue, 11 Apr 2017 17:48:26 -0400 Message-ID: <00a601d2b30d$5a5803b0$0f080b10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPxQa9DuYm0jMhf5hfvNuXa/BqqQF4tSBOAUVugSAA5nm1wKGpa5Bw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 21:53:44 -0000 Kathleen:=20 I will submit a version -13 later tonight with the change to = informational.=20 Sue=20 -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Kathleen = Moriarty Sent: Tuesday, April 11, 2017 3:55 PM To: Alissa Cooper Cc: i2nsf@ietf.org; Mirja K=C3=BChlewind; IESG; i2nsf-chairs@ietf.org; = adrian@olddog.co.uk; draft-ietf-i2nsf-problem-and-use-cases@ietf.org Subject: Re: [I2nsf] Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT) Hi Adrian, I think it's pretty clear that this should go down to informational now. = Thanks for raising the question and having the IESG weigh in as the = published statement did not cover whether these support document should = be informational only in nature. I do think that is the current opinion = and that they are fine to publish if the WG would like to do so, but = it's not encouraged. We could see about updating the statement to cover your point that = support documents are to be informational. Thank you, Kathleen On Tue, Apr 11, 2017 at 2:50 PM, Alissa Cooper = wrote: > Hi Adrian, > > On Apr 11, 2017, at 2:34 PM, Adrian Farrel = wrote: > > Thanks Mirja, > I think it is best that you discuss this topic with the rest of the=20 > IESG and then we can be told what to do. > > (FWIW, I heard this conversation about 6 times in the 6 years I was on = > the IESG and the opinion swung back and forth. The IESG I was on never = > managed to get a clear position set down to guide the authors of = future documents. > Perhaps you could write one?) > > > We did, last year: > https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html > > Alissa > > > Cheers, > Adrian > > -----Original Message----- > From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] > Sent: 11 April 2017 19:26 > To: The IESG > Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel;=20 > i2nsf- chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org > Subject: Mirja K=C3=BChlewind's Discuss on > draft-ietf-i2nsf-problem-and-use-cases-12: > (with DISCUSS and COMMENT) > > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: Discuss > > When responding, please keep the subject line intact and reply to all=20 > email addresses included in the To and CC lines. (Feel free to cut=20 > this introductory paragraph, however.) > > > Please refer to=20 > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-case > s/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This document should be informational. I don't see any reason that=20 > this document must be cited normatively by all following document of=20 > this wg (as indicated in the shepherd write-up) and even if so that=20 > does not justify publication as Standards track if the information in=20 > the document is only informational. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As soon as my discuss is resolved I will change to 'Abstain' as I=20 > don't see value in the publication of this document. I can see that=20 > this document was useful for discussion in the working group but I=20 > don't know why it needs to be published as RFC. Also there is quite=20 > some redundancy everywhere in the document aa well as between the=20 > problem statement and use case part. Spelling out requirements for the = > protocol design based on the analysis of these problems and use cases=20 > (which was already a bit attempted from time to time in the doc) would = > have been more useful but does still not have an archivable value that = > justifies publication as RFC in the IETF stream (indicating IETF = consensus). > > > > --=20 Best regards, Kathleen _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Tue Apr 11 19:54:05 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB981242F5; Tue, 11 Apr 2017 19:53:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149196563769.15746.5801383926535892733.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 19:53:57 -0700 Archived-At: Subject: [I2nsf] Suresh Krishnan's Abstain on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:53:58 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Agree with my Abstaining co-ADs and don't think this document should be published on the Standards track but I will not stand in the way of publication. From nobody Wed Apr 12 02:39:27 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB591314F1; Wed, 12 Apr 2017 02:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] 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 oKNaMH7H4jWK; Wed, 12 Apr 2017 02:39:13 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 A1FCB1314EC; Wed, 12 Apr 2017 02:39:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.20.72; Date: Wed, 12 Apr 2017 05:39:07 -0400 Message-ID: <3g69hcpl66fun0s19rp8jsoi.1491989947000@email.android.com> Importance: normal From: Susan Hares To: Kathleen Moriarty , Alissa Cooper Cc: "i2nsf@ietf.org" , =?ISO-8859-1?Q?Mirja_K=FChlewind?= , IESG , i2nsf-chairs@ietf.org, "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_22182365409844420" X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_C?= =?iso-8859-1?q?OMMENT=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 09:39:18 -0000 ----_com.samsung.android.email_22182365409844420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 S2F0aGxlZW4KUGxlYXNlIG1vdmUgdGhpcyBkcmFmdCB0byAyIHdlZWtzIGZyb20gbm93LiDCoEkg YW0gc2ljayB0b2RheSBzbyBJIHdpbGwgbm90IGdldCB0aGVzZSByZXZpc2lvbnMgZG9uZSB0b2Rh eS7CoApTdWUgSGFyZXPCoAoKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcgZWRnZSwg YW4gQVQmVCA0RyBMVEUgc21hcnRwaG9uZQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tRnJvbTogS2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwu Y29tPiBEYXRlOiA0LzExLzE3ICAzOjU0IFBNICAoR01ULTA1OjAwKSBUbzogQWxpc3NhIENvb3Bl ciA8YWxpc3NhQGNvb3BlcncuaW4+IENjOiBpMm5zZkBpZXRmLm9yZywgTWlyamEgS8O8aGxld2lu ZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD4sIElFU0cgPGllc2dAaWV0Zi5vcmc+LCBpMm5zZi1jaGFp cnNAaWV0Zi5vcmcsIGFkcmlhbkBvbGRkb2cuY28udWssIGRyYWZ0LWlldGYtaTJuc2YtcHJvYmxl bS1hbmQtdXNlLWNhc2VzQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbSTJuc2ZdIArCoCBNaXJqYSBL w7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWkybnNmLXByb2JsZW0tYW5kLXVzZS1j YXNlcy0xMjogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkgCkhpIEFkcmlhbiwKCkkgdGhpbmsg aXQncyBwcmV0dHkgY2xlYXIgdGhhdCB0aGlzIHNob3VsZCBnbyBkb3duIHRvIGluZm9ybWF0aW9u YWwKbm93LsKgIFRoYW5rcyBmb3IgcmFpc2luZyB0aGUgcXVlc3Rpb24gYW5kIGhhdmluZyB0aGUg SUVTRyB3ZWlnaCBpbiBhcwp0aGUgcHVibGlzaGVkIHN0YXRlbWVudCBkaWQgbm90IGNvdmVyIHdo ZXRoZXIgdGhlc2Ugc3VwcG9ydCBkb2N1bWVudApzaG91bGQgYmUgaW5mb3JtYXRpb25hbCBvbmx5 IGluIG5hdHVyZS7CoCBJIGRvIHRoaW5rIHRoYXQgaXMgdGhlCmN1cnJlbnQgb3BpbmlvbiBhbmQg dGhhdCB0aGV5IGFyZSBmaW5lIHRvIHB1Ymxpc2ggaWYgdGhlIFdHIHdvdWxkIGxpa2UKdG8gZG8g c28sIGJ1dCBpdCdzIG5vdCBlbmNvdXJhZ2VkLgoKV2UgY291bGQgc2VlIGFib3V0IHVwZGF0aW5n IHRoZSBzdGF0ZW1lbnQgdG8gY292ZXIgeW91ciBwb2ludCB0aGF0CnN1cHBvcnQgZG9jdW1lbnRz IGFyZSB0byBiZSBpbmZvcm1hdGlvbmFsLgoKVGhhbmsgeW91LApLYXRobGVlbgoKT24gVHVlLCBB cHIgMTEsIDIwMTcgYXQgMjo1MCBQTSwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+ IHdyb3RlOgo+IEhpIEFkcmlhbiwKPgo+IE9uIEFwciAxMSwgMjAxNywgYXQgMjozNCBQTSwgQWRy aWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6Cj4KPiBUaGFua3MgTWlyamEs Cj4gSSB0aGluayBpdCBpcyBiZXN0IHRoYXQgeW91IGRpc2N1c3MgdGhpcyB0b3BpYyB3aXRoIHRo ZSByZXN0IG9mIHRoZSBJRVNHIGFuZAo+IHRoZW4gd2UgY2FuIGJlIHRvbGQgd2hhdCB0byBkby4K Pgo+IChGV0lXLCBJIGhlYXJkIHRoaXMgY29udmVyc2F0aW9uIGFib3V0IDYgdGltZXMgaW4gdGhl IDYgeWVhcnMgSSB3YXMgb24gdGhlCj4gSUVTRyBhbmQgdGhlIG9waW5pb24gc3d1bmcgYmFjayBh bmQgZm9ydGguIFRoZSBJRVNHIEkgd2FzIG9uIG5ldmVyIG1hbmFnZWQKPiB0byBnZXQgYSBjbGVh ciBwb3NpdGlvbiBzZXQgZG93biB0byBndWlkZSB0aGUgYXV0aG9ycyBvZiBmdXR1cmUgZG9jdW1l bnRzLgo+IFBlcmhhcHMgeW91IGNvdWxkIHdyaXRlIG9uZT8pCj4KPgo+IFdlIGRpZCwgbGFzdCB5 ZWFyOgo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L3N1cHBvcnQtZG9jdW1l bnRzLWluLWlldGYtd2dzLmh0bWwKPgo+IEFsaXNzYQo+Cj4KPiBDaGVlcnMsCj4gQWRyaWFuCj4K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IE1pcmphIEvDvGhsZXdpbmQgW21h aWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XQo+IFNlbnQ6IDExIEFwcmlsIDIwMTcgMTk6MjYKPiBU bzogVGhlIElFU0cKPiBDYzogZHJhZnQtaWV0Zi1pMm5zZi1wcm9ibGVtLWFuZC11c2UtY2FzZXNA aWV0Zi5vcmc7IEFkcmlhbiBGYXJyZWw7IGkybnNmLQo+IGNoYWlyc0BpZXRmLm9yZzsgYWRyaWFu QG9sZGRvZy5jby51azsgaTJuc2ZAaWV0Zi5vcmcKPiBTdWJqZWN0OiBNaXJqYSBLw7xobGV3aW5k J3MgRGlzY3VzcyBvbgo+IGRyYWZ0LWlldGYtaTJuc2YtcHJvYmxlbS1hbmQtdXNlLWNhc2VzLTEy Ogo+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpCj4KPiBNaXJqYSBLw7xobGV3aW5kIGhhcyBl bnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcgo+IGRyYWZ0LWlldGYtaTJu c2YtcHJvYmxlbS1hbmQtdXNlLWNhc2VzLTEyOiBEaXNjdXNzCj4KPiBXaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwKPiBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcwo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQo+Cj4KPiBQ bGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vz cy1jcml0ZXJpYS5odG1sCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy4KPgo+Cj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90 aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOgo+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJuc2YtcHJvYmxlbS1hbmQtdXNlLWNhc2Vz Lwo+Cj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBESVNDVVNTOgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IFRo aXMgZG9jdW1lbnQgc2hvdWxkIGJlIGluZm9ybWF0aW9uYWwuIEkgZG9uJ3Qgc2VlIGFueSByZWFz b24gdGhhdCB0aGlzCj4gZG9jdW1lbnQgbXVzdCBiZSBjaXRlZCBub3JtYXRpdmVseSBieSBhbGwg Zm9sbG93aW5nIGRvY3VtZW50IG9mIHRoaXMgd2cKPiAoYXMgaW5kaWNhdGVkIGluIHRoZSBzaGVw aGVyZCB3cml0ZS11cCkgYW5kIGV2ZW4gaWYgc28gdGhhdCBkb2VzIG5vdAo+IGp1c3RpZnkgcHVi bGljYXRpb24gYXMgU3RhbmRhcmRzIHRyYWNrIGlmIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgZG9j dW1lbnQKPiBpcyBvbmx5IGluZm9ybWF0aW9uYWwuCj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBDT01N RU5UOgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IEFzIHNvb24gYXMgbXkgZGlzY3VzcyBpcyByZXNvbHZl ZCBJIHdpbGwgY2hhbmdlIHRvICdBYnN0YWluJyBhcyBJIGRvbid0Cj4gc2VlIHZhbHVlIGluIHRo ZSBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBJIGNhbiBzZWUgdGhhdCB0aGlzCj4gZG9j dW1lbnQgd2FzIHVzZWZ1bCBmb3IgZGlzY3Vzc2lvbiBpbiB0aGUgd29ya2luZyBncm91cCBidXQg SSBkb24ndCBrbm93Cj4gd2h5IGl0IG5lZWRzIHRvIGJlIHB1Ymxpc2hlZCBhcyBSRkMuIEFsc28g dGhlcmUgaXMgcXVpdGUgc29tZSByZWR1bmRhbmN5Cj4gZXZlcnl3aGVyZSBpbiB0aGUgZG9jdW1l bnQgYWEgd2VsbCBhcyBiZXR3ZWVuIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQKPiB1c2UgY2Fz ZSBwYXJ0LiBTcGVsbGluZyBvdXQgcmVxdWlyZW1lbnRzIGZvciB0aGUgcHJvdG9jb2wgZGVzaWdu IGJhc2VkIG9uCj4gdGhlIGFuYWx5c2lzIG9mIHRoZXNlIHByb2JsZW1zIGFuZCB1c2UgY2FzZXMg KHdoaWNoIHdhcyBhbHJlYWR5IGEgYml0Cj4gYXR0ZW1wdGVkIGZyb20gdGltZSB0byB0aW1lIGlu IHRoZSBkb2MpIHdvdWxkIGhhdmUgYmVlbiBtb3JlIHVzZWZ1bCBidXQKPiBkb2VzIHN0aWxsIG5v dCBoYXZlIGFuIGFyY2hpdmFibGUgdmFsdWUgdGhhdCBqdXN0aWZpZXMgcHVibGljYXRpb24gYXMg UkZDCj4gaW4gdGhlIElFVEYgc3RyZWFtIChpbmRpY2F0aW5nIElFVEYgY29uc2Vuc3VzKS4KPgo+ Cj4KPgoKCgotLSAKCkJlc3QgcmVnYXJkcywKS2F0aGxlZW4KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCkkybnNmIG1haWxpbmcgbGlzdApJMm5zZkBpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kybnNmCg== ----_com.samsung.android.email_22182365409844420 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkthdGhsZWVuPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5QbGVhc2UgbW92ZSB0aGlzIGRyYWZ0IHRvIDIgd2Vla3MgZnJvbSBu b3cuICZuYnNwO0kgYW0gc2ljayB0b2RheSBzbyBJIHdpbGwgbm90IGdldCB0aGVzZSByZXZpc2lv bnMgZG9uZSB0b2RheS4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlN1ZSBIYXJlcyZu YnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9u dC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5n IEdhbGF4eSBTNyBlZGdlLCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2PjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAi PjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAt LS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogS2F0aGxlZW4gTW9yaWFydHkgJmx0O2thdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDQvMTEvMTcgIDM6NTQg UE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IEFsaXNzYSBDb29wZXIgJmx0O2FsaXNzYUBj b29wZXJ3LmluJmd0OyA8L2Rpdj48ZGl2PkNjOiBpMm5zZkBpZXRmLm9yZywgTWlyamEgS8O8aGxl d2luZCAmbHQ7aWV0ZkBrdWVobGV3aW5kLm5ldCZndDssIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcm Z3Q7LCBpMm5zZi1jaGFpcnNAaWV0Zi5vcmcsIGFkcmlhbkBvbGRkb2cuY28udWssIGRyYWZ0LWll dGYtaTJuc2YtcHJvYmxlbS1hbmQtdXNlLWNhc2VzQGlldGYub3JnIDwvZGl2PjxkaXY+U3ViamVj dDogUmU6IFtJMm5zZl0gCiZuYnNwOyBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFm dC1pZXRmLWkybnNmLXByb2JsZW0tYW5kLXVzZS1jYXNlcy0xMjogKHdpdGggRElTQ1VTUyBhbmQg Q09NTUVOVCkgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+SGkgQWRyaWFuLDxicj48YnI+SSB0 aGluayBpdCdzIHByZXR0eSBjbGVhciB0aGF0IHRoaXMgc2hvdWxkIGdvIGRvd24gdG8gaW5mb3Jt YXRpb25hbDxicj5ub3cuJm5ic3A7IFRoYW5rcyBmb3IgcmFpc2luZyB0aGUgcXVlc3Rpb24gYW5k IGhhdmluZyB0aGUgSUVTRyB3ZWlnaCBpbiBhczxicj50aGUgcHVibGlzaGVkIHN0YXRlbWVudCBk aWQgbm90IGNvdmVyIHdoZXRoZXIgdGhlc2Ugc3VwcG9ydCBkb2N1bWVudDxicj5zaG91bGQgYmUg aW5mb3JtYXRpb25hbCBvbmx5IGluIG5hdHVyZS4mbmJzcDsgSSBkbyB0aGluayB0aGF0IGlzIHRo ZTxicj5jdXJyZW50IG9waW5pb24gYW5kIHRoYXQgdGhleSBhcmUgZmluZSB0byBwdWJsaXNoIGlm IHRoZSBXRyB3b3VsZCBsaWtlPGJyPnRvIGRvIHNvLCBidXQgaXQncyBub3QgZW5jb3VyYWdlZC48 YnI+PGJyPldlIGNvdWxkIHNlZSBhYm91dCB1cGRhdGluZyB0aGUgc3RhdGVtZW50IHRvIGNvdmVy IHlvdXIgcG9pbnQgdGhhdDxicj5zdXBwb3J0IGRvY3VtZW50cyBhcmUgdG8gYmUgaW5mb3JtYXRp b25hbC48YnI+PGJyPlRoYW5rIHlvdSw8YnI+S2F0aGxlZW48YnI+PGJyPk9uIFR1ZSwgQXByIDEx LCAyMDE3IGF0IDI6NTAgUE0sIEFsaXNzYSBDb29wZXIgJmx0O2FsaXNzYUBjb29wZXJ3LmluJmd0 OyB3cm90ZTo8YnI+Jmd0OyBIaSBBZHJpYW4sPGJyPiZndDs8YnI+Jmd0OyBPbiBBcHIgMTEsIDIw MTcsIGF0IDI6MzQgUE0sIEFkcmlhbiBGYXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7 IHdyb3RlOjxicj4mZ3Q7PGJyPiZndDsgVGhhbmtzIE1pcmphLDxicj4mZ3Q7IEkgdGhpbmsgaXQg aXMgYmVzdCB0aGF0IHlvdSBkaXNjdXNzIHRoaXMgdG9waWMgd2l0aCB0aGUgcmVzdCBvZiB0aGUg SUVTRyBhbmQ8YnI+Jmd0OyB0aGVuIHdlIGNhbiBiZSB0b2xkIHdoYXQgdG8gZG8uPGJyPiZndDs8 YnI+Jmd0OyAoRldJVywgSSBoZWFyZCB0aGlzIGNvbnZlcnNhdGlvbiBhYm91dCA2IHRpbWVzIGlu IHRoZSA2IHllYXJzIEkgd2FzIG9uIHRoZTxicj4mZ3Q7IElFU0cgYW5kIHRoZSBvcGluaW9uIHN3 dW5nIGJhY2sgYW5kIGZvcnRoLiBUaGUgSUVTRyBJIHdhcyBvbiBuZXZlciBtYW5hZ2VkPGJyPiZn dDsgdG8gZ2V0IGEgY2xlYXIgcG9zaXRpb24gc2V0IGRvd24gdG8gZ3VpZGUgdGhlIGF1dGhvcnMg b2YgZnV0dXJlIGRvY3VtZW50cy48YnI+Jmd0OyBQZXJoYXBzIHlvdSBjb3VsZCB3cml0ZSBvbmU/ KTxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBXZSBkaWQsIGxhc3QgeWVhcjo8YnI+Jmd0OyBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9zdXBwb3J0LWRvY3VtZW50cy1pbi1pZXRm LXdncy5odG1sPGJyPiZndDs8YnI+Jmd0OyBBbGlzc2E8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsg Q2hlZXJzLDxicj4mZ3Q7IEFkcmlhbjxicj4mZ3Q7PGJyPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+Jmd0OyBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIFttYWlsdG86aWV0ZkBrdWVo bGV3aW5kLm5ldF08YnI+Jmd0OyBTZW50OiAxMSBBcHJpbCAyMDE3IDE5OjI2PGJyPiZndDsgVG86 IFRoZSBJRVNHPGJyPiZndDsgQ2M6IGRyYWZ0LWlldGYtaTJuc2YtcHJvYmxlbS1hbmQtdXNlLWNh c2VzQGlldGYub3JnOyBBZHJpYW4gRmFycmVsOyBpMm5zZi08YnI+Jmd0OyBjaGFpcnNAaWV0Zi5v cmc7IGFkcmlhbkBvbGRkb2cuY28udWs7IGkybnNmQGlldGYub3JnPGJyPiZndDsgU3ViamVjdDog TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb248YnI+Jmd0OyBkcmFmdC1pZXRmLWkybnNmLXBy b2JsZW0tYW5kLXVzZS1jYXNlcy0xMjo8YnI+Jmd0OyAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KTxicj4mZ3Q7PGJyPiZndDsgTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+Jmd0OyBkcmFmdC1pZXRmLWkybnNmLXByb2JsZW0t YW5kLXVzZS1jYXNlcy0xMjogRGlzY3Vzczxicj4mZ3Q7PGJyPiZndDsgV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJy PiZndDsgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG ZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnI+Jmd0OyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLik8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDxicj4mZ3Q7IGZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnI+Jmd0OyBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkybnNmLXByb2JsZW0tYW5kLXVzZS1j YXNlcy88YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZn dDsgRElTQ1VTUzo8YnI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDs8YnI+Jmd0OyBUaGlzIGRv Y3VtZW50IHNob3VsZCBiZSBpbmZvcm1hdGlvbmFsLiBJIGRvbid0IHNlZSBhbnkgcmVhc29uIHRo YXQgdGhpczxicj4mZ3Q7IGRvY3VtZW50IG11c3QgYmUgY2l0ZWQgbm9ybWF0aXZlbHkgYnkgYWxs IGZvbGxvd2luZyBkb2N1bWVudCBvZiB0aGlzIHdnPGJyPiZndDsgKGFzIGluZGljYXRlZCBpbiB0 aGUgc2hlcGhlcmQgd3JpdGUtdXApIGFuZCBldmVuIGlmIHNvIHRoYXQgZG9lcyBub3Q8YnI+Jmd0 OyBqdXN0aWZ5IHB1YmxpY2F0aW9uIGFzIFN0YW5kYXJkcyB0cmFjayBpZiB0aGUgaW5mb3JtYXRp b24gaW4gdGhlIGRvY3VtZW50PGJyPiZndDsgaXMgb25seSBpbmZvcm1hdGlvbmFsLjxicj4mZ3Q7 PGJyPiZndDs8YnI+Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgQ09NTUVOVDo8YnI+Jmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPiZndDs8YnI+Jmd0OyBBcyBzb29uIGFzIG15IGRpc2N1c3MgaXMgcmVz b2x2ZWQgSSB3aWxsIGNoYW5nZSB0byAnQWJzdGFpbicgYXMgSSBkb24ndDxicj4mZ3Q7IHNlZSB2 YWx1ZSBpbiB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gSSBjYW4gc2VlIHRoYXQg dGhpczxicj4mZ3Q7IGRvY3VtZW50IHdhcyB1c2VmdWwgZm9yIGRpc2N1c3Npb24gaW4gdGhlIHdv cmtpbmcgZ3JvdXAgYnV0IEkgZG9uJ3Qga25vdzxicj4mZ3Q7IHdoeSBpdCBuZWVkcyB0byBiZSBw dWJsaXNoZWQgYXMgUkZDLiBBbHNvIHRoZXJlIGlzIHF1aXRlIHNvbWUgcmVkdW5kYW5jeTxicj4m Z3Q7IGV2ZXJ5d2hlcmUgaW4gdGhlIGRvY3VtZW50IGFhIHdlbGwgYXMgYmV0d2VlbiB0aGUgcHJv YmxlbSBzdGF0ZW1lbnQgYW5kPGJyPiZndDsgdXNlIGNhc2UgcGFydC4gU3BlbGxpbmcgb3V0IHJl cXVpcmVtZW50cyBmb3IgdGhlIHByb3RvY29sIGRlc2lnbiBiYXNlZCBvbjxicj4mZ3Q7IHRoZSBh bmFseXNpcyBvZiB0aGVzZSBwcm9ibGVtcyBhbmQgdXNlIGNhc2VzICh3aGljaCB3YXMgYWxyZWFk eSBhIGJpdDxicj4mZ3Q7IGF0dGVtcHRlZCBmcm9tIHRpbWUgdG8gdGltZSBpbiB0aGUgZG9jKSB3 b3VsZCBoYXZlIGJlZW4gbW9yZSB1c2VmdWwgYnV0PGJyPiZndDsgZG9lcyBzdGlsbCBub3QgaGF2 ZSBhbiBhcmNoaXZhYmxlIHZhbHVlIHRoYXQganVzdGlmaWVzIHB1YmxpY2F0aW9uIGFzIFJGQzxi cj4mZ3Q7IGluIHRoZSBJRVRGIHN0cmVhbSAoaW5kaWNhdGluZyBJRVRGIGNvbnNlbnN1cykuPGJy PiZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+PGJyPjxicj48YnI+LS0gPGJyPjxicj5C ZXN0IHJlZ2FyZHMsPGJyPkthdGhsZWVuPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5JMm5zZiBtYWlsaW5nIGxpc3Q8YnI+STJuc2ZAaWV0 Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZjxicj48 L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_22182365409844420-- From nobody Wed Apr 12 05:03:34 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF28A1293D9; Wed, 12 Apr 2017 05:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 HlA2q2c9-bC4; Wed, 12 Apr 2017 05:03:29 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE28C129353; Wed, 12 Apr 2017 05:03:28 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3CC3NEa017800; Wed, 12 Apr 2017 13:03:23 +0100 Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3CC3ELk017565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Apr 2017 13:03:19 +0100 Reply-To: From: "Adrian Farrel" To: "'Alissa Cooper'" Cc: "'IESG'" , , , References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> In-Reply-To: <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> Date: Wed, 12 Apr 2017 13:03:16 +0100 Message-ID: <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D8_01D2B38D.2C478150" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPxQa9DuYm0jMhf5hfvNuXa/BqqQF4tSBOAUVugSChsYho8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23000.006 X-TM-AS-Result: No--15.286-10.0-31-10 X-imss-scan-details: No--15.286-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wsnUTf2MoOKY5HnIpVYlaByzNiYrvQPckXws T5jF3WC+/Dc+2eYZvLQvnh8ihWv+/+mf0V7i7SoM3FqOVb7PDEIF15s6prCIu6izNBq55glQfOp R+eEJVXg9ZX6sAXLybbenQkLW/KtRcMgJs8W+2dOKQCqq8vYqFY+YVJqrrEz4grAXgr/AjP3zVX 5vAXf22x6+AP71wsjrZZ1VyyTdGfN0vLz9+O4Ky277LFtuRggWCAruoteJOhyfZo0Tq+NWlGb6P phVtfZgoDHAaly7gjqWLz7gHk2taTK42JVSvu3A+lWD63Q3aXrjNBTAhtr6C6aDeNpTFrdeTMjx CaRkpO+apARHaCa858/IweUDXd3c5v/RsXkmsjFor4yxPAz7WZTZyU9UaoN2Blt4RZwvTdWtEaJ oVjyWkAyMtK5Cqm3BWFu6uXExXrqHcw4kILw6GrMjW/sniEQK67bK6MyA7xlMUbk7iJxcXcU5Iu Oi05hmbrgUJ4CnqHjHaRV3qIXYN8JYn8FAurxC4nbwqqmOd2loWqHVtK0gRp0j8OKRnVQ8kxRIr BUwVoynEV8M9iZlAz/YOWgGuxeGL/fdNahJQfpCvapcIkxJXyUEq8j01YhfehnlgrviZRCnu55o SQOpM1GXjDJez7QRZIUKW7g6rHWc95xD+Eo4wLtsiy3ZR8MEDYBVKmbeeQMt88jwUkXq9SMOuGt F4L1E5CExRqzKGHYkNJbVMSlGZ5FN+B8oJZ5aNcoW2wO1ntOimsR6hkcJAraDqNq3aYtVUDgx1H hI/5SbRUCnTPMAhbg/pXPYldTsRvuPymaKFCWeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyLxyVDO2 rxhe0ESKBlicakMJ743Tpyj890N0tgRo0VIy+FSORhExLTOVCptSaYGi69eGkMHBEqG9Au+r9Ud Fs+6Cu5K5PUoVB8eYt+RvZ5+D7R+2dEGs3L3 Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:03:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D8_01D2B38D.2C478150 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks For the pointer, Alissa. I think I was aware of this IESG = statement and I believe it was factored into the working group's = discussions (per its charter milestone) of which documents to pursue to = publication and which not. =20 But, as I believe Kathleen has just noted, this statement does not = comment on the positioning on so-called support documents as Informative = or Normative. This is the first point in Mirja's Discuss and the = question I was asking.=20 =20 A lot of the issue comes down to how the RFC Editor defines a Normative = reference, but maybe some of it resolves to the IESG's own definitions = of downward references. Consider, if you will, the most extreme case = which is a set of requirements. Such documents (often using 2119 = language) do not contain protocol specifications and are not what you = would normally expect to see end up as an Internet Standard. But = (clearly?) you will want to reference the requirements as part of the = protocol specification that follows. The question is: when stating that = the protocol widget is shaped a particular way in order to satisfy a = particular requirement, do you need to make normative or informative = reference to that requirement, and so should the reference be Standards = Track or downwards-referenced Informational. =20 (Some history that no longer applies... Once upon a time the MoU with = the ITU-T stated that they could only reference an RFC on the Standards = Track. This meant that, for example, to get them to develop a protocol = spec that was based on IETF requirements it was necessary to publish the = requirements in a Standards Track RFC. We fixed this by re-writing the = MoU and this particular shard of the problem has gone way.) =20 Why is this question important? The working groups spend a lot of cycles trying to decide what track to = put documents on. Cycles cost money and ruin lives. My approach now is = to have a quick guess and punt to the IESG. But it is apparent that the IESG is also burning cycles. Maybe a clear directive would allow everyone to get on with their lives = and spend time writing code. =20 =20 [And a side comment on the IESG statement and subsequent Abstains. If = the so-called support documents receive no wider review than within the = WG, and if the subsequent protocol specs then attract review comments = along the lines of "why are you supporting this function?" or even " = there is absolutely no need for this function" then we have set = ourselves up for confrontation with the WG which will feel that it has = done good work based on its own view of the use cases or requirements, = and the reviewer who did not comment at the right time in the process. = Who knows whether this will happen and how it will be resolved?] =20 Ciao, Adrian =20 From: Alissa Cooper [mailto:alissa@cooperw.in]=20 Sent: 11 April 2017 19:51 To: adrian@olddog.co.uk Cc: Mirja K=C3=BChlewind; IESG; i2nsf@ietf.org; = draft-ietf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org Subject: Re: Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT) =20 Hi Adrian, =20 On Apr 11, 2017, at 2:34 PM, Adrian Farrel wrote: =20 Thanks Mirja, I think it is best that you discuss this topic with the rest of the IESG = and then we can be told what to do. (FWIW, I heard this conversation about 6 times in the 6 years I was on = the IESG and the opinion swung back and forth. The IESG I was on never = managed to get a clear position set down to guide the authors of future = documents. Perhaps you could write one?) =20 We did, last year: = https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html =20 Alissa Cheers, Adrian -----Original Message----- From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] Sent: 11 April 2017 19:26 To: The IESG Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; = i2nsf- chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org Subject: Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document should be informational. I don't see any reason that this document must be cited normatively by all following document of this wg (as indicated in the shepherd write-up) and even if so that does not justify publication as Standards track if the information in the = document is only informational. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As soon as my discuss is resolved I will change to 'Abstain' as I don't see value in the publication of this document. I can see that this document was useful for discussion in the working group but I don't know why it needs to be published as RFC. Also there is quite some redundancy everywhere in the document aa well as between the problem statement and use case part. Spelling out requirements for the protocol design based = on the analysis of these problems and use cases (which was already a bit attempted from time to time in the doc) would have been more useful but does still not have an archivable value that justifies publication as = RFC in the IETF stream (indicating IETF consensus). =20 =20 ------=_NextPart_000_02D8_01D2B38D.2C478150 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks For the pointer, = Alissa. I think I was aware of this IESG statement and I believe it was = factored into the working group's discussions (per its charter = milestone) of which documents to pursue to publication and which = not.

 

But, as I believe Kathleen has = just noted, this statement does not comment on the positioning on = so-called support documents as Informative or Normative. This is the = first point in Mirja's Discuss and the question I was asking. =

 

A lot of the issue comes down = to how the RFC Editor defines a Normative reference, but maybe some of = it resolves to the IESG's own definitions of downward references. = Consider, if you will, the most extreme case which is a set of = requirements. Such documents (often using 2119 language) do not contain = protocol specifications and are not what you would normally expect to = see end up as an Internet Standard. But (clearly?) you will want to = reference the requirements as part of the protocol specification that = follows. The question is: when stating that the protocol widget is = shaped a particular way in order to satisfy a particular requirement, do = you need to make normative or informative reference to that requirement, = and so should the reference be Standards Track or downwards-referenced = Informational.

 

(Some history that no longer = applies...=C2=A0 Once upon a = time the MoU with the ITU-T stated that they could only reference an RFC = on the Standards Track. This meant that, for example, to get them to = develop a protocol spec that was based on IETF requirements it was = necessary to publish the requirements in a Standards Track RFC. We fixed = this by re-writing the MoU and this particular shard of the problem has = gone way.)

 

Why is this question = important?

The working groups spend a lot = of cycles trying to decide what track to put documents on. Cycles cost = money and ruin lives. My approach now is to have a quick guess and punt = to the IESG.

But it is apparent that the = IESG is also burning cycles.

Maybe a clear directive would = allow everyone to get on with their lives and spend time writing = code.

 

 

[And a side comment on the = IESG statement and subsequent Abstains. If the so-called support = documents receive no wider review than within the WG, and if the = subsequent protocol specs then attract review comments along the lines = of "why are you supporting this function?" or even " = there is absolutely no need for this function" then we have set = ourselves up for confrontation with the WG which will feel that it has = done good work based on its own view of the use cases or requirements, = and the reviewer who did not comment at the right time in the process. = Who knows whether this will happen and how it will be = resolved?]

 

Ciao,

Adrian

 

From: Alissa Cooper = [mailto:alissa@cooperw.in]
Sent: 11 April 2017 = 19:51
To: adrian@olddog.co.uk
Cc: Mirja = K=C3=BChlewind; IESG; i2nsf@ietf.org; = draft-ietf-i2nsf-problem-and-use-cases@ietf.org; = i2nsf-chairs@ietf.org
Subject: Re: Mirja K=C3=BChlewind's = Discuss on draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and = COMMENT)

 

Hi = Adrian,

 

On Apr 11, 2017, at 2:34 PM, Adrian Farrel <adrian@olddog.co.uk> = wrote:

 

Thanks Mirja,
I = think it is best that you discuss this topic with the rest of the IESG = and then we can be told what to do.

(FWIW, I heard this = conversation about 6 times in the 6 years I was on the IESG and the = opinion swung back and forth. The IESG I was on never managed to get a = clear position set down to guide the authors of future documents. = Perhaps you could write = one?)

 

 

Alissa




Cheers,
Adrian


-----Original Message-----
From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net]
Se= nt: 11 April 2017 19:26
To: The IESG
Cc: draft-iet= f-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; i2nsf-
chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org
Subject: Mirja = K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12:
(with DISCUSS and = COMMENT)

Mirja K=C3=BChlewind has entered the following ballot = position for
draft-ietf-i2nsf-problem-and-use-cases-12: = Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC lines. (Feel = free to cut this
introductory paragraph, however.)


Please = refer to https:= //www.ietf.org/iesg/statement/discuss-criteria.html
for more = information about IESG DISCUSS and COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-us= e-cases/



---------------------------------------------= -------------------------
DISCUSS:
--------------------------------= --------------------------------------

This document should be = informational. I don't see any reason that this
document must be = cited normatively by all following document of this wg
(as indicated = in the shepherd write-up) and even if so that does not
justify = publication as Standards track if the information in the document
is = only = informational.


-----------------------------------------------= -----------------------
COMMENT:
----------------------------------= ------------------------------------

As soon as my discuss is = resolved I will change to 'Abstain' as I don't
see value in the = publication of this document. I can see that this
document was useful = for discussion in the working group but I don't know
why it needs to = be published as RFC. Also there is quite some redundancy
everywhere = in the document aa well as between the problem statement and
use case = part. Spelling out requirements for the protocol design based on
the = analysis of these problems and use cases (which was already a = bit
attempted from time to time in the doc) would have been more = useful but
does still not have an archivable value that justifies = publication as RFC
in the IETF stream (indicating IETF = consensus).

 

 

------=_NextPart_000_02D8_01D2B38D.2C478150-- From nobody Wed Apr 12 05:05:44 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9357C13169A; Wed, 12 Apr 2017 05:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 OZpVFGJBu8X9; Wed, 12 Apr 2017 05:05:32 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8754129444; Wed, 12 Apr 2017 05:05:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3CC5T8X019447; Wed, 12 Apr 2017 13:05:29 +0100 Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3CC5RkF019426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Apr 2017 13:05:28 +0100 Reply-To: From: "Adrian Farrel" To: "'Kathleen Moriarty'" Cc: , , "=?utf-8?Q?'Mirja_K=C3=BChlewind'?=" , "'IESG'" , References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> In-Reply-To: Date: Wed, 12 Apr 2017 13:05:29 +0100 Message-ID: <02e201d2b385$15d664c0$41832e40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPxQa9DuYm0jMhf5hfvNuXa/BqqQF4tSBOAUVugSAA5nm1wKGqWrlA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23000.006 X-TM-AS-Result: No--16.777-10.0-31-10 X-imss-scan-details: No--16.777-10.0-31-10 X-TMASE-MatchedRID: oTBA/+sdKaYWZlH9Y0dXnumc4/pDEQa2t3aeg7g/usAiFs20Vxq/wrez ZCdgUysvm/4ob9BK0iWK0Joj0npda2wXxFs1CTxXliwpJdZauwcS12tj9Zvd8ySqFMz9Rn22zcw TglIp/qOMsMmsZgEW1Ca7SDxLKuqz2rvYheZgBXvcWo5Vvs8MQhlgDfyCPcHEMxVjmK1sOgMvc8 syVBJ2ZJWEBfIMPOI2dhHodlSD+CTeG3z9uXufsm0PWqD0pliRfS0Ip2eEHnzUHQeTVDUrItRnE QCUU+jzjoczmuoPCq2UU3xFGFvHz9fzCe/0Sg23T5RrRWjjGo/+Og2AXiN99sikwR4DWBlI Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:05:38 -0000 OK with me, Kathleen. Can you handle as an RFC editor note? Cheers, Adrian > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: 11 April 2017 20:55 > To: Alissa Cooper > Cc: adrian@olddog.co.uk; i2nsf@ietf.org; = draft-ietf-i2nsf-problem-and-use- > cases@ietf.org; Mirja K=C3=BChlewind; IESG; i2nsf-chairs@ietf.org > Subject: Re: Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use- > cases-12: (with DISCUSS and COMMENT) >=20 > Hi Adrian, >=20 > I think it's pretty clear that this should go down to informational > now. Thanks for raising the question and having the IESG weigh in as > the published statement did not cover whether these support document > should be informational only in nature. I do think that is the > current opinion and that they are fine to publish if the WG would like > to do so, but it's not encouraged. >=20 > We could see about updating the statement to cover your point that > support documents are to be informational. >=20 > Thank you, > Kathleen >=20 > On Tue, Apr 11, 2017 at 2:50 PM, Alissa Cooper = wrote: > > Hi Adrian, > > > > On Apr 11, 2017, at 2:34 PM, Adrian Farrel = wrote: > > > > Thanks Mirja, > > I think it is best that you discuss this topic with the rest of the = IESG and > > then we can be told what to do. > > > > (FWIW, I heard this conversation about 6 times in the 6 years I was = on the > > IESG and the opinion swung back and forth. The IESG I was on never = managed > > to get a clear position set down to guide the authors of future = documents=3D From nobody Wed Apr 12 05:17:08 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F014B12944D; Wed, 12 Apr 2017 05:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 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, MIME_QP_LONG_LINE=0.001, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 x1pPaLtn6vzA; Wed, 12 Apr 2017 05:16:58 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 AF5B512943F; Wed, 12 Apr 2017 05:16:51 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id v75so3626078qkb.3; Wed, 12 Apr 2017 05:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:message-id :references:cc:to:in-reply-to; bh=U7PshaMCMq4c6MgsuI1pPeGlTzdbdRKwFsbqKn05x94=; b=aP1ecv/ojT4KOIHuw7IUB2dAUHxFD7QTQzudXclSLA89p/DmMFKjp2ul89tnzPaZUy RDc3xt16QCj+umanN0zzxVKNe06gbNyyewVaVc8lcbYF4n3i/2MwSv7vu4lb2dD0WTn8 /mGwaBxG3oAOEhk1H35m0UFQPtB4E4L8GcZPHmLeXXUxzMu1UOYgJlf8zSYrnKu0h7kd wVGKmdrU4RqUG3Pey5e6fRK5KGJ8G2fXttCmh/iwCG01p5YWBJIxYU7uc1TLuNNzJwpJ xloGi6PxAYyG8/wGi3PkyNpHEASesWLOrMz2C4F6yBfLSREUnzHWdSU3KtwQiupooDda s7NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :message-id:references:cc:to:in-reply-to; bh=U7PshaMCMq4c6MgsuI1pPeGlTzdbdRKwFsbqKn05x94=; b=KUqwl5OkH9U54Jc/2TcVyLEj2NCWZP+ik0wDdyzsCJK0uMyPeWDM/v06zOzaXZAhdg YKuotf8XdynGMEZxgEb5btSKdnvqmSEGtnYJ6cx1MLMYaBaSRt5dBGiLi5aNfXV+trQh VNAuU/IulLlIuCT0OOHaZ0p5nEQYv9eQp4/rcYKMtrKw1mqn2lHOLsHu6R5ZtOmGA9df F8EgUqQJh6rNVCkFyFAB2ITnNmypFs/CiwWiEjBUh6R60IFvD9M4+pcsggjzzV51oFLL +JQlIobijbkQc0MQKp3C1rsNbLvvrACTx0aHX+BaJR8MF3+CP45Z9kdmKQQQ98Nf+6wU jkjw== X-Gm-Message-State: AFeK/H06JF/QcPT5edqSboSYFjqqxgYUtcNNDIMaZ6NQbpPd367jiaZoTetJaw7pwl1xtA== X-Received: by 10.55.21.86 with SMTP id f83mr54469111qkh.214.1491999410897; Wed, 12 Apr 2017 05:16:50 -0700 (PDT) Received: from [192.168.1.13] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id d142sm13239289qkc.32.2017.04.12.05.16.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 05:16:49 -0700 (PDT) From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-8A2AA552-0AB5-4610-86D3-D07DE4F919D8 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (14D27) Mime-Version: 1.0 (1.0) Date: Wed, 12 Apr 2017 08:16:49 -0400 Message-Id: <6491DAEE-2AB6-46E4-BD19-B33AAF446D4B@gmail.com> References: <3g69hcpl66fun0s19rp8jsoi.1491989947000@email.android.com> Cc: Alissa Cooper , "i2nsf@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , IESG , i2nsf-chairs@ietf.org, "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org To: Susan Hares In-Reply-To: <3g69hcpl66fun0s19rp8jsoi.1491989947000@email.android.com> Archived-At: Subject: [I2nsf] (no subject) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:17:00 -0000 --Apple-Mail-8A2AA552-0AB5-4610-86D3-D07DE4F919D8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sue, I hope you feel better! I'll move it out 2 weeks. Thank you, Kathleen=20 Sent from my iPhone > On Apr 12, 2017, at 5:39 AM, Susan Hares wrote: >=20 > Kathleen >=20 > Please move this draft to 2 weeks from now. I am sick today so I will not= get these revisions done today.=20 >=20 > Sue Hares=20 >=20 >=20 >=20 >=20 > Sent via the Samsung Galaxy S7 edge, an AT&T 4G LTE smartphone >=20 > -------- Original message -------- > From: Kathleen Moriarty > Date: 4/11/17 3:54 PM (GMT-05:00) > To: Alissa Cooper > Cc: i2nsf@ietf.org, Mirja K=C3=BChlewind , IESG , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, draft-ietf-i2nsf-pro= blem-and-use-cases@ietf.org > Subject: Re: [I2nsf] Mirja K=C3=BChlewind's Discuss on draft-ietf-i2nsf-= problem-and-use-cases-12: (with DISCUSS and COMMENT) >=20 > Hi Adrian, >=20 > I think it's pretty clear that this should go down to informational > now. Thanks for raising the question and having the IESG weigh in as > the published statement did not cover whether these support document > should be informational only in nature. I do think that is the > current opinion and that they are fine to publish if the WG would like > to do so, but it's not encouraged. >=20 > We could see about updating the statement to cover your point that > support documents are to be informational. >=20 > Thank you, > Kathleen >=20 > On Tue, Apr 11, 2017 at 2:50 PM, Alissa Cooper wrote: > > Hi Adrian, > > > > On Apr 11, 2017, at 2:34 PM, Adrian Farrel wrote: > > > > Thanks Mirja, > > I think it is best that you discuss this topic with the rest of the IESG= and > > then we can be told what to do. > > > > (FWIW, I heard this conversation about 6 times in the 6 years I was on t= he > > IESG and the opinion swung back and forth. The IESG I was on never manag= ed > > to get a clear position set down to guide the authors of future document= s. > > Perhaps you could write one?) > > > > > > We did, last year: > > https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html > > > > Alissa > > > > > > Cheers, > > Adrian > > > > -----Original Message----- > > From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] > > Sent: 11 April 2017 19:26 > > To: The IESG > > Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; i2ns= f- > > chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org > > Subject: Mirja K=C3=BChlewind's Discuss on > > draft-ietf-i2nsf-problem-and-use-cases-12: > > (with DISCUSS and COMMENT) > > > > Mirja K=C3=BChlewind has entered the following ballot position for > > draft-ietf-i2nsf-problem-and-use-cases-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/= > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This document should be informational. I don't see any reason that this > > document must be cited normatively by all following document of this wg > > (as indicated in the shepherd write-up) and even if so that does not > > justify publication as Standards track if the information in the documen= t > > is only informational. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > As soon as my discuss is resolved I will change to 'Abstain' as I don't > > see value in the publication of this document. I can see that this > > document was useful for discussion in the working group but I don't know= > > why it needs to be published as RFC. Also there is quite some redundancy= > > everywhere in the document aa well as between the problem statement and > > use case part. Spelling out requirements for the protocol design based o= n > > the analysis of these problems and use cases (which was already a bit > > attempted from time to time in the doc) would have been more useful but > > does still not have an archivable value that justifies publication as RFC= > > in the IETF stream (indicating IETF consensus). > > > > > > > > >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --Apple-Mail-8A2AA552-0AB5-4610-86D3-D07DE4F919D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Sue,

I hope you feel better!  = ;I'll move it out 2 weeks.

Thank you,
K= athleen 

Sent from my iPhone

On Apr 12, 2017, at 5:39 AM, Susan Hares <shares@ndzh.com> wrote:

Kathleen

Please move this draft to= 2 weeks from now.  I am sick today so I will not get these revisions d= one today. 

Sue Hares 




Sent via the Samsu= ng Galaxy S7 edge, an AT&T 4G LTE smartphone

<= div style=3D"font-size:100%;color:#000000">
----= ---- Original message --------
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m>
Date: 4/11/17 3:54 PM (GMT-05:00)
To: Alis= sa Cooper <alissa@cooperw.in>=
Cc: i2nsf@ietf.org, Mirja K= =C3=BChlewind <ietf@kuehlewind.net= >, IESG <iesg@ietf.org>, <= a href=3D"mailto:i2nsf-chairs@ietf.org">i2nsf-chairs@ietf.org, adrian@olddog.co.uk, draft-ietf-i2nsf-problem-and-us= e-cases@ietf.org
Subject: Re: [I2nsf]=20   Mirja K=C3=BChlewind's Discuss on draft-ietf-i2nsf-problem-and-use-ca= ses-12: (with DISCUSS and COMMENT)

Hi Adrian,
=
I think it's pretty clear that this should go down to informational
n= ow.  Thanks for raising the question and having the IESG weigh in asthe published statement did not cover whether these support document
sho= uld be informational only in nature.  I do think that is the
current= opinion and that they are fine to publish if the WG would like
to do so,= but it's not encouraged.

We could see about updating the statement t= o cover your point that
support documents are to be informational.
Thank you,
Kathleen

On Tue, Apr 11, 2017 at 2:50 PM, Alissa Coope= r <alissa@cooperw.in> wrote:<= br>> Hi Adrian,
>
> On Apr 11, 2017, at 2:34 PM, Adrian Farre= l <adrian@olddog.co.uk> wro= te:
>
> Thanks Mirja,
> I think it is best that you discus= s this topic with the rest of the IESG and
> then we can be told what t= o do.
>
> (FWIW, I heard this conversation about 6 times in the 6= years I was on the
> IESG and the opinion swung back and forth. The I= ESG I was on never managed
> to get a clear position set down to guide= the authors of future documents.
> Perhaps you could write one?)
&= gt;
>
> We did, last year:
> https://www.ietf.org/i= esg/statement/support-documents-in-ietf-wgs.html
>
> Alissa<= br>>
>
> Cheers,
> Adrian
>
> -----Original= Message-----
> From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net]
> Sent: 11 April 2017 19:= 26
> To: The IESG
> Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; i2nsf-
> chairs@= ietf.org; adrian@olddog.co.uk= ; i2nsf@ietf.org
> Subject: Mirj= a K=C3=BChlewind's Discuss on
> draft-ietf-i2nsf-problem-and-use-cases= -12:
> (with DISCUSS and COMMENT)
>
> Mirja K=C3=BChlewind= has entered the following ballot position for
> draft-ietf-i2nsf-prob= lem-and-use-cases-12: Discuss
>
> When responding, please keep t= he subject line intact and reply to all
> email addresses included in t= he To and CC lines. (Feel free to cut this
> introductory paragraph, h= owever.)
>
>
> Please refer to https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
> for more information about IESG DISCUSS= and COMMENT positions.
>
>
> The document, along with oth= er ballot positions, can be found here:
> https://datatracker= .ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/
>
>>
> --------------------------------------------------------------= --------
> DISCUSS:
> ------------------------------------------= ----------------------------
>
> This document should be informa= tional. I don't see any reason that this
> document must be cited norm= atively by all following document of this wg
> (as indicated in the sh= epherd write-up) and even if so that does not
> justify publication as= Standards track if the information in the document
> is only informat= ional.
>
>
> ---------------------------------------------= -------------------------
> COMMENT:
> -------------------------= ---------------------------------------------
>
> As soon as my d= iscuss is resolved I will change to 'Abstain' as I don't
> see value i= n the publication of this document. I can see that this
> document was= useful for discussion in the working group but I don't know
> why it n= eeds to be published as RFC. Also there is quite some redundancy
> eve= rywhere in the document aa well as between the problem statement and
>= use case part. Spelling out requirements for the protocol design based on> the analysis of these problems and use cases (which was already a bit=
> attempted from time to time in the doc) would have been more useful= but
> does still not have an archivable value that justifies publicat= ion as RFC
> in the IETF stream (indicating IETF consensus).
>>
>
>



--

Best regards,
Kathleen
_______________________________________________
I2nsf mailing list<= br>I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo= /i2nsf
= --Apple-Mail-8A2AA552-0AB5-4610-86D3-D07DE4F919D8-- From nobody Wed Apr 12 06:30:49 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B11129B3A for ; Wed, 12 Apr 2017 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 YjQcQmBA54BQ for ; Wed, 12 Apr 2017 06:30:45 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16D1129B30 for ; Wed, 12 Apr 2017 06:30:41 -0700 (PDT) Received: (qmail 22176 invoked from network); 12 Apr 2017 15:23:59 +0200 Received: from p5dec24e1.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.36.225) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Apr 2017 15:23:59 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> Date: Wed, 12 Apr 2017 15:23:57 +0200 Cc: Alissa Cooper , i2nsf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases@ietf.org, IESG , i2nsf-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:30:47 -0000 Hi Adrian, first of all I have to say that deciding between standards track and = informational did not occur to me as persistent problem. I believe there = was only one other case in the last year (that was less clear than this = case), and maybe one more case where the IESG decided to change from = information to standards tracks. Both cases were simple to handle with = not much discussion and were both less clear cases than this one.=20 Regarding the IESG statement, for me it was an implicit assumption that = these documents are informational anyway. I guess we could spell this = out if that helps. See more comments inline. =20 > Am 12.04.2017 um 14:03 schrieb Adrian Farrel : >=20 > Thanks For the pointer, Alissa. I think I was aware of this IESG = statement and I believe it was factored into the working group's = discussions (per its charter milestone) of which documents to pursue to = publication and which not. > =20 > But, as I believe Kathleen has just noted, this statement does not = comment on the positioning on so-called support documents as Informative = or Normative. This is the first point in Mirja's Discuss and the = question I was asking.=20 > =20 > A lot of the issue comes down to how the RFC Editor defines a = Normative reference, but maybe some of it resolves to the IESG's own = definitions of downward references. Consider, if you will, the most = extreme case which is a set of requirements. Such documents (often using = 2119 language) do not contain protocol specifications and are not what = you would normally expect to see end up as an Internet Standard. But = (clearly?) you will want to reference the requirements as part of the = protocol specification that follows. So what I really don=E2=80=99t understand is why you need to refer these = requirements or other support documents normatively. You can alway = reference them informatively and I would assume that=E2=80=99s fine. A = normative reference means, you have to read those documents as well to = be able understand the spec/implement it correctly. I don=E2=80=99t = think any background information and motivation or reasoning falls into = that category. Further the status of a document should foremost be decided based on its = content and not on the question how it could or could not be referenced = in future. I know that these points are sometimes part of the discussion = but usually for documents where there are also other reasons to maybe = have it as standards track. > The question is: when stating that the protocol widget is shaped a = particular way in order to satisfy a particular requirement, do you need = to make normative or informative reference to that requirement, and so = should the reference be Standards Track or downwards-referenced = Informational. Again informative references are fine! > =20 > (Some history that no longer applies... Once upon a time the MoU with = the ITU-T stated that they could only reference an RFC on the Standards = Track. This meant that, for example, to get them to develop a protocol = spec that was based on IETF requirements it was necessary to publish the = requirements in a Standards Track RFC. We fixed this by re-writing the = MoU and this particular shard of the problem has gone way.) Here the right solution is (which I believe was done) to explain to an = informational document is an as stable reference as the standards track = and can be referred without concerns, and not changing the status. > =20 > Why is this question important? > The working groups spend a lot of cycles trying to decide what track = to put documents on. Cycles cost money and ruin lives. My approach now = is to have a quick guess and punt to the IESG. > But it is apparent that the IESG is also burning cycles. > Maybe a clear directive would allow everyone to get on with their = lives and spend time writing code. Again, I wasn=E2=80=99t aware of this kind of confusion. Yes, there are = a lot of discussions about the right status but there is also existing = documentation about what the different cases mean. For some document = it=E2=80=99s sometimes also not that clear but usually my advise as AD = is to make some choice and then wait for further feedback in the IESG = evaluation and IETF last call. However, in your case, it=E2=80=99s actually very clear to me that this = document must be informational and as I said in my discuss I really = don=E2=80=99t even see the point about future references because = informative references are fine anyway. > =20 > =20 > [And a side comment on the IESG statement and subsequent Abstains. If = the so-called support documents receive no wider review than within the = WG, and if the subsequent protocol specs then attract review comments = along the lines of "why are you supporting this function?" or even " = there is absolutely no need for this function" then we have set = ourselves up for confrontation with the WG which will feel that it has = done good work based on its own view of the use cases or requirements, = and the reviewer who did not comment at the right time in the process. = Who knows whether this will happen and how it will be resolved?] So I think this can happen no matter if you have published any support = document or not because very often these kind of document are less well = reviewed in IETF last call. However, the questions you raise above are = explicitly mentioned as not beginning discuss-worthy in=20 https://www.ietf.org/iesg/statement/discuss-criteria.html so that should not hold up publication anyway. Also it is fully okay to integrate some background information on = requirements or use case in the appendix of the actual protocol spec, as = mentioned in the IESG statement. If the wg feels that useful, that can = be done. Otherwise sneaking a requirements document through the process to have a = handle later to undermine some discussion, seems also just not the right = thing to do. I know this is phrased a little to exaggerated but my point = is, while I really, really know that discussion can be very length and = annoying in the IETF, usually there is a valid core that is worth having = the discussion when it comes up. Mirja > =20 > Ciao, > Adrian > =20 > From: Alissa Cooper [mailto:alissa@cooperw.in]=20 > Sent: 11 April 2017 19:51 > To: adrian@olddog.co.uk > Cc: Mirja K=C3=BChlewind; IESG; i2nsf@ietf.org; = draft-ietf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org > Subject: Re: Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT) > =20 > Hi Adrian, > =20 >> On Apr 11, 2017, at 2:34 PM, Adrian Farrel = wrote: >> =20 >> Thanks Mirja, >> I think it is best that you discuss this topic with the rest of the = IESG and then we can be told what to do. >>=20 >> (FWIW, I heard this conversation about 6 times in the 6 years I was = on the IESG and the opinion swung back and forth. The IESG I was on = never managed to get a clear position set down to guide the authors of = future documents. Perhaps you could write one?) > =20 > We did, last year: = https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html > =20 > Alissa >=20 >=20 >=20 > Cheers, > Adrian >=20 >=20 > -----Original Message----- > From: Mirja K=C3=BChlewind [mailto:ietf@kuehlewind.net] > Sent: 11 April 2017 19:26 > To: The IESG > Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org; Adrian Farrel; = i2nsf- > chairs@ietf.org; adrian@olddog.co.uk; i2nsf@ietf.org > Subject: Mirja K=C3=BChlewind's Discuss on = draft-ietf-i2nsf-problem-and-use-cases-12: > (with DISCUSS and COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This document should be informational. I don't see any reason that = this > document must be cited normatively by all following document of this = wg > (as indicated in the shepherd write-up) and even if so that does not > justify publication as Standards track if the information in the = document > is only informational. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > As soon as my discuss is resolved I will change to 'Abstain' as I = don't > see value in the publication of this document. I can see that this > document was useful for discussion in the working group but I don't = know > why it needs to be published as RFC. Also there is quite some = redundancy > everywhere in the document aa well as between the problem statement = and > use case part. Spelling out requirements for the protocol design based = on > the analysis of these problems and use cases (which was already a bit > attempted from time to time in the doc) would have been more useful = but > does still not have an archivable value that justifies publication as = RFC > in the IETF stream (indicating IETF consensus). From nobody Sat Apr 15 03:49:35 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78121127867; Sat, 15 Apr 2017 03:49:27 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 abQxoz7rE19U; Sat, 15 Apr 2017 03:49:25 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC40F12751F; Sat, 15 Apr 2017 03:49:24 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3FAnJqM025461; Sat, 15 Apr 2017 11:49:19 +0100 Received: from 950129200 (251.129.113.87.dyn.plus.net [87.113.129.251]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v3FAnIc6025444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Apr 2017 11:49:19 +0100 Reply-To: From: "Adrian Farrel" To: "'Mirja Kuehlewind \(IETF\)'" Cc: "'Alissa Cooper'" , , , "'IESG'" , References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> In-Reply-To: <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> Date: Sat, 15 Apr 2017 11:49:22 +0100 Message-ID: <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPxQa9DuYm0jMhf5hfvNuXa/BqqQF4tSBOAUVugSAA3P+7DwKwZB0FoZm+MyA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23006.006 X-TM-AS-Result: No--22.167-10.0-31-10 X-imss-scan-details: No--22.167-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wozb2GR6Ttd3C/ExpXrHizwsugxReYWqZgi3 0NhSIvprp8B+3FyRXGKEepLbI+P7qA5G/b6aSGR8w4PlNTUpnLk0AKed0u9fBwk1NPNX01GCz+Q gFL42EMQP12I8voeiQoDO5vLPyksxuI4dUviLh3VrRpSjNebQNm79evoIpeI3rZ44xGFc5oIAPe CazHn0ZrAZ8ZFF+GWeVF78GWxSIdG5fzRNL0I/VnXuAcDIAWvTh8Ytn75ClDOInvV8Dy0ZaGXFJ gb8rLoPMlU9/HlxDMvZkuP0U656MQp2iRVeF6F285L5JHGOAXA5LRtPnepd1bKeTtOdjMy6mO7Y cjYHQ54Q2Hu4NKrkwWRWQrGZDn7BbboYgHrsZfKzI1v7J4hEClxIyn/X4SmniGWrzccRsv7/898 ll77v0LB6CrpgrK99h6zDXIPqd8wFZ32u8aHsrBHRbGr1ECgHwkzmVqNbwpUM74Nf6tTB9kykjz g+ado3O/Svh7JUHbOju3XKtAcB0759Npo/5cPBHPYwOJi6PLkrHkgIan9a0S3uO0xwI7o/C7nvt 4YvZMhyyMuC9GszD+n8tL23JZtkO6sfSrHWQFidVNZaI2n6/0GV2YNiPCWm9Epe9s75/BNnKwnY EuaPmCTsWFkuegVTMrekcva/5Pn3HQOPl5LqmyU3k0n8S5KpRetMg/KQ57lzXwu+EY2dZDLk8G2 qhCWT4Jb4zOUcrh7EOPXYpA5hUgqinms2D2HC7T+j7/gPsPPiZyLfY10wsgn8pPiKHhdcQQ/s9v EJJnfZjV/gzZp7vSIwt0I7shg0OkjQDRo1OZSeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 10:49:27 -0000 Hello Mirja, Thanks for continuing to discuss this issue. > first of all I have to say that deciding between standards track and = informational > did not occur to me as persistent problem. I believe there was only = one other > case in the last year (that was less clear than this case), and maybe = one more case > where the IESG decided to change from information to standards tracks. = Both > cases were simple to handle with not much discussion and were both = less clear > cases than this one. The IESG needs to be aware of a persistent problem: by this stage in the = publication process most authors will do whatever it takes to get the = document published. They are not going to dig in their heals over = "editorial matters" and will simply roll over. You are, therefore, = getting false data. The situation is made "worse" by the fact that by the time a document = reaches the IESG, the discussion has been had=20 - with the chairs, who have good experience of what is necessary to get through the IESG) - with the responsible AD (who has that experience and also their=20 own views) > Regarding the IESG statement, for me it was an implicit assumption = that these > documents are informational anyway. I guess we could spell this out if = that helps. Surely. I think it would be very helpful for the IESG to consider the document = series again and to indicate clearly indicate how an author determines = whether the document they are writing is Informational or Standards = Track. > A lot of the issue comes down to how the RFC Editor defines a = Normative > reference, but maybe some of it resolves to the IESG's own definitions = of > downward references. Consider, if you will, the most extreme case = which is a set > of requirements. Such documents (often using 2119 language) do not = contain > protocol specifications and are not what you would normally expect to = see end > up as an Internet Standard. But (clearly?) you will want to reference = the > requirements as part of the protocol specification that follows. >=20 > So what I really don=E2=80=99t understand is why you need to refer = these requirements or > other support documents normatively. You can alway reference them > informatively and I would assume that=E2=80=99s fine. A normative = reference means, you > have to read those documents as well to be able understand the > spec/implement it correctly. I don=E2=80=99t think any background = information and > motivation or reasoning falls into that category. So let's assume we have a terminology document in our hands. Clearly (?) = you can't use terms from that document without a reference to it. Is = that reference normative or not? Probably it is normative because how = can the reader of a protocol spec know what is being discussed if they = don't know the terms? Now more to an architecture document. This document describes the = components and interfaces. It indicates what the senders and receivers = of a protocol message are and what they are doing. Maybe in a very dry = protocol spec you can avoid making a reference to the architecture = normative, but probably not. And what about a problem statement document that introduces terms and = architecture? Isn't that document going to need to be referenced, and = because the protocol specs rely on those terms and that architecture, = isn't that reference normative? [Please note that I do not personally make such claims for the document = in hand, but I believe the authors and WG do make those claims.] > Further the status of a document should foremost be decided based on = its > content and not on the question how it could or could not be = referenced in > future. I know that these points are sometimes part of the discussion = but usually > for documents where there are also other reasons to maybe have it as = standards > track. Actually I agree. BUT that means that the work on downward references = really needs to be sorted out, made clearer, and made easier. Essentially, we could dispense with this discussion if we could stop it = being any type of issue to have a normative reference to an = Informational RFC. > The question is: when stating that the protocol widget is shaped a = particular > way in order to satisfy a particular requirement, do you need to make = normative > or informative reference to that requirement, and so should the = reference be > Standards Track or downwards-referenced Informational. >=20 > Again informative references are fine! I should point you at = https://www.ietf.org/iesg/statement/normative-informative.html This says that=20 | Normative references specify documents that must be read to understand = or | implement the technology in the new RFC, or whose technology must be=20 | present for the technology in the new RFC to work. The crunch is "understand the technology". That makes the line hard to = draw. > > Why is this question important? > > The working groups spend a lot of cycles trying to decide what track = to put > > documents on. Cycles cost money and ruin lives. My approach now is = to have > > a quick guess and punt to the IESG. > > But it is apparent that the IESG is also burning cycles. > > Maybe a clear directive would allow everyone to get on with their = lives and > > spend time writing code. >=20 > Again, I wasn=E2=80=99t aware of this kind of confusion. Yes, there = are a lot of discussions > about the right status but there is also existing documentation about = what the > different cases mean. For some document it=E2=80=99s sometimes also = not that clear but > usually my advise as AD is to make some choice and then wait for = further > feedback in the IESG evaluation and IETF last call. OK. We are both taking the same approach :-) But I am wondering (out loud) whether we could do better by pushing the = information that feeds the final decision down the stack a little. Why should we be "guessing" and getting the answer from our superiors? = Why should we not know how to make the right decision? > However, in your case, it=E2=80=99s actually very clear to me that = this document must be > informational and as I said in my discuss I really don=E2=80=99t even = see the point about > future references because informative references are fine anyway. Well, I think I addressed your second part above. As to "should *this* document be one thing or another" I suspect no-one = responsible for the production actually cares. They simply want the = document published. But they are also wary of a road crash later. So what I am doing (in case it was not obvious) is gathering a paper = trail that will allow the chairs to say to a future IESG, "Tough! This = is what we were told to do and so the [future] document cannot be held = up by this situation." Of course, I'd be happy to not have to do this on a document-by-document = basis. So some clearer direction from the IESG would always be welcome. Thanks, Adrian From nobody Sat Apr 15 12:49:36 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740EF129484; Sat, 15 Apr 2017 12:49:29 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 aDH09czsgl7t; Sat, 15 Apr 2017 12:49:26 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 6AACC12948A; Sat, 15 Apr 2017 12:49:24 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id f204so24086950ybc.2; Sat, 15 Apr 2017 12:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xD4Xp7VOcvnvmHvExv1hG9hMKrCnblQU6je3QdqoxPA=; b=fVQkAB9t3+P6+4AiIKsmm7PxvaNPjw4diO4zyjdGCoB1ICS7mfvzWijvVp/VXo9wZi YTETezh8wPnawxQ5iPSO/qqSG6kIn1OePcsq0lmC33ThmX/RFNhz42OVt36A6xEpP/LO GdsVEqwAPJwsqNmZq00NV63JbAAenkwsISzyw/HG/0aqG5Um1euy0H9SbB4wZ4Ap9Xx0 5VMCSxF0ikMCMsfcO4QzMvf0LspbhnzZ8nqTRwwGzyn4gO3aMpa/a2uBoshqzXkOz8DZ ej9UDkSkBxk/qA5DZwUsJ0Xkx2WkDF7K299twZnsKI0fC5YCR55R5VbQ0Qz6eQjAaE8m SA4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xD4Xp7VOcvnvmHvExv1hG9hMKrCnblQU6je3QdqoxPA=; b=pJJM4ywoRKyE3ze8SaxgbFVkV3J6hdSSjWxUA7PlH+qyMJXBGJPiFCFO9Dz23vDBte Ckd0/uMVMow2B4xLkGiZTWE7W0W05Fam0NsNs7cWSjf+g5oi5lKXpAEry7CdOEsyxTeT k30nAiuD9NnjY8oYpVpSr88ydKBkfT9n8nXovdbufbDSofwMpKh57ZEAx/xI1f5S3Jho QevNZQpJxTPR3zipl9cbgHWDfyNsEXeg/L4P+I2LHcfe+q20VGLmyNFv0U0L5AZ1YNtj uvQOLl16iqKQf6pAzwIy5qTSDBizzoaZs9B5HIEXkeVeMfnofBnOKBb+Nx1EGsSmGK3i Rs1w== X-Gm-Message-State: AN3rC/4nPy0F46rMducXkGJXTW4MMWWjqhsY7zj2NTTj5mj8DItUIVuO NWziDeXABqi/Nq8TkHRKFuRpzJWJeg== X-Received: by 10.37.88.137 with SMTP id m131mr10786450ybb.12.1492285763627; Sat, 15 Apr 2017 12:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Sat, 15 Apr 2017 12:49:23 -0700 (PDT) Received: by 10.37.73.129 with HTTP; Sat, 15 Apr 2017 12:49:23 -0700 (PDT) In-Reply-To: <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> From: Spencer Dawkins at IETF Date: Sat, 15 Apr 2017 14:49:23 -0500 Message-ID: To: adrian@olddog.co.uk Cc: Alissa Cooper , draft-ietf-i2nsf-problem-and-use-cases@ietf.org, IESG , "Mirja Kuehlewind (IETF)" , i2nsf-chairs@ietf.org, i2nsf@ietf.org Content-Type: multipart/alternative; boundary=001a113fc5dad836bd054d39dac5 Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 19:49:29 -0000 --001a113fc5dad836bd054d39dac5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is not my circus, but on one point ... On Apr 15, 2017 05:49, "Adrian Farrel" wrote: Hello Mirja, Thanks for continuing to discuss this issue. > first of all I have to say that deciding between standards track and informational > did not occur to me as persistent problem. I believe there was only one other > case in the last year (that was less clear than this case), and maybe one more case > where the IESG decided to change from information to standards tracks. Both > cases were simple to handle with not much discussion and were both less clear > cases than this one. The IESG needs to be aware of a persistent problem: by this stage in the publication process most authors will do whatever it takes to get the document published. They are not going to dig in their heals over "editorial matters" and will simply roll over. You are, therefore, getting false data. The situation is made "worse" by the fact that by the time a document reaches the IESG, the discussion has been had - with the chairs, who have good experience of what is necessary to get through the IESG) - with the responsible AD (who has that experience and also their own views) > Regarding the IESG statement, for me it was an implicit assumption that these > documents are informational anyway. I guess we could spell this out if that helps. Surely. I think it would be very helpful for the IESG to consider the document series again and to indicate clearly indicate how an author determines whether the document they are writing is Informational or Standards Track. > A lot of the issue comes down to how the RFC Editor defines a Normative > reference, but maybe some of it resolves to the IESG's own definitions of > downward references. Consider, if you will, the most extreme case which is a set > of requirements. Such documents (often using 2119 language) do not contai= n > protocol specifications and are not what you would normally expect to see end > up as an Internet Standard. But (clearly?) you will want to reference the > requirements as part of the protocol specification that follows. > > So what I really don=E2=80=99t understand is why you need to refer these requirements or > other support documents normatively. You can alway reference them > informatively and I would assume that=E2=80=99s fine. A normative referen= ce means, you > have to read those documents as well to be able understand the > spec/implement it correctly. I don=E2=80=99t think any background informa= tion and > motivation or reasoning falls into that category. So let's assume we have a terminology document in our hands. Clearly (?) you can't use terms from that document without a reference to it. Is that reference normative or not? Probably it is normative because how can the reader of a protocol spec know what is being discussed if they don't know the terms? Now more to an architecture document. This document describes the components and interfaces. It indicates what the senders and receivers of a protocol message are and what they are doing. Maybe in a very dry protocol spec you can avoid making a reference to the architecture normative, but probably not. And what about a problem statement document that introduces terms and architecture? Isn't that document going to need to be referenced, and because the protocol specs rely on those terms and that architecture, isn't that reference normative? [Please note that I do not personally make such claims for the document in hand, but I believe the authors and WG do make those claims.] > Further the status of a document should foremost be decided based on its > content and not on the question how it could or could not be referenced i= n > future. I know that these points are sometimes part of the discussion but usually > for documents where there are also other reasons to maybe have it as standards > track. Actually I agree. BUT that means that the work on downward references really needs to be sorted out, made clearer, and made easier. Essentially, we could dispense with this discussion if we could stop it being any type of issue to have a normative reference to an Informational RFC. So, here's where I'm getting stuck. Standards-track and BCP drafts require 2/3rds of the IESG to ballot Yes or No Objection (with no Discusses), while Informational, Experimental, and Historic drafts require only one Yes (and no Discusses). All this, per https://www.ietf.org/iesg/voting-procedures.html. So my question is, if a terminology or architecture draft is going to be foundational for Standards-track or BCP drafts, is it OK that the foundational draft requires less review than the drafts that are building on it? If that's not a problem, with some plausible reasoning why not(*), I'd be fine with allowing Normative references to Informational RFCs, with no special attention. (*) I'm not suggesting this is plausible reasoning, but it's worth noting that most of the Informational documents we process are balloted by more than half the IESG, even though one Yes is sufficient, and most go though reviews from multiple review teams before they appear on a telechat agenda. So maybe this is a distinction without a difference, and that is sufficient to justify allowing Normative references to Informational RFCs. It's also worth noting that working group charters also require only one Yes (and no Blocks), and one might think charters are at least as foundational as terminology or architecture drafts. If those aren't a good enough alibis, maybe someone could come up with another one ;-) Spencer > The question is: when stating that the protocol widget is shaped a particular > way in order to satisfy a particular requirement, do you need to make normative > or informative reference to that requirement, and so should the reference be > Standards Track or downwards-referenced Informational. > > Again informative references are fine! I should point you at https://www.ietf.org/iesg/stat ement/normative-informative.html This says that | Normative references specify documents that must be read to understand or | implement the technology in the new RFC, or whose technology must be | present for the technology in the new RFC to work. The crunch is "understand the technology". That makes the line hard to draw= . > > Why is this question important? > > The working groups spend a lot of cycles trying to decide what track to put > > documents on. Cycles cost money and ruin lives. My approach now is to have > > a quick guess and punt to the IESG. > > But it is apparent that the IESG is also burning cycles. > > Maybe a clear directive would allow everyone to get on with their lives and > > spend time writing code. > > Again, I wasn=E2=80=99t aware of this kind of confusion. Yes, there are a= lot of discussions > about the right status but there is also existing documentation about what the > different cases mean. For some document it=E2=80=99s sometimes also not t= hat clear but > usually my advise as AD is to make some choice and then wait for further > feedback in the IESG evaluation and IETF last call. OK. We are both taking the same approach :-) But I am wondering (out loud) whether we could do better by pushing the information that feeds the final decision down the stack a little. Why should we be "guessing" and getting the answer from our superiors? Why should we not know how to make the right decision? > However, in your case, it=E2=80=99s actually very clear to me that this d= ocument must be > informational and as I said in my discuss I really don=E2=80=99t even see= the point about > future references because informative references are fine anyway. Well, I think I addressed your second part above. As to "should *this* document be one thing or another" I suspect no-one responsible for the production actually cares. They simply want the document published. But they are also wary of a road crash later. So what I am doing (in case it was not obvious) is gathering a paper trail that will allow the chairs to say to a future IESG, "Tough! This is what we were told to do and so the [future] document cannot be held up by this situation." Of course, I'd be happy to not have to do this on a document-by-document basis. So some clearer direction from the IESG would always be welcome. Thanks, Adrian --001a113fc5dad836bd054d39dac5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is not my circus, but on one point ...

On Apr 15, 2017 05:49,= "Adrian Farrel" <adrian@olddog.co.uk> wrote:
Hello Mirja,

Thanks for continuing to discuss this issue.

> first of all I have to say that deciding between standards track and i= nformational
> did not occur to me as persistent problem. I believe there was only on= e other
> case in the last year (that was less clear than this case), and maybe = one more case
> where the IESG decided to change from information to standards tracks.= Both
> cases were simple to handle with not much discussion and were both les= s clear
> cases than this one.

The IESG needs to be aware of a persistent problem: by this stage in = the publication process most authors will do whatever it takes to get the d= ocument published. They are not going to dig in their heals over "edit= orial matters" and will simply roll over. You are, therefore, getting = false data.

The situation is made "worse" by the fact that by the time a docu= ment reaches the IESG, the discussion has been had
- with the chairs, who have good experience of what is necessary
=C2=A0 =C2=A0to get through the IESG)
- with the responsible AD (who has that experience and also their
=C2=A0 =C2=A0own views)

> Regarding the IESG statement, for me it was an implicit assumption tha= t these
> documents are informational anyway. I guess we could spell this out if= that helps.

Surely.
I think it would be very helpful for the IESG to consider the document seri= es again and to indicate clearly indicate how an author determines whether = the document they are writing is Informational or Standards Track.

> A lot of the issue comes down to how the RFC Editor defines a Normativ= e
> reference, but maybe some of it resolves to the IESG's own definit= ions of
> downward references. Consider, if you will, the most extreme case whic= h is a set
> of requirements. Such documents (often using 2119 language) do not con= tain
> protocol specifications and are not what you would normally expect to = see end
> up as an Internet Standard. But (clearly?) you will want to reference = the
> requirements as part of the protocol specification that follows.
>
> So what I really don=E2=80=99t understand is why you need to refer the= se requirements or
> other support documents normatively. You can alway reference them
> informatively and I would assume that=E2=80=99s fine. A normative refe= rence means, you
> have to read those documents as well to be able understand the
> spec/implement it correctly. I don=E2=80=99t think any background info= rmation and
> motivation or reasoning falls into that category.

So let's assume we have a terminology document in our hands. Clea= rly (?) you can't use terms from that document without a reference to i= t. Is that reference normative or not? Probably it is normative because how= can the reader of a protocol spec know what is being discussed if they don= 't know the terms?

Now more to an architecture document. This document describes the component= s and interfaces. It indicates what the senders and receivers of a protocol= message are and what they are doing. Maybe in a very dry protocol spec you= can avoid making a reference to the architecture normative, but probably n= ot.

And what about a problem statement document that introduces terms and archi= tecture? Isn't that document going to need to be referenced, and becaus= e the protocol specs rely on those terms and that architecture, isn't t= hat reference normative?

[Please note that I do not personally make such claims for the document in = hand, but I believe the authors and WG do make those claims.]

> Further the status of a document should foremost be decided based on i= ts
> content and not on the question how it could or could not be reference= d in
> future. I know that these points are sometimes part of the discussion = but usually
> for documents where there are also other reasons to maybe have it as s= tandards
> track.

Actually I agree. BUT that means that the work on downward references= really needs to be sorted out, made clearer, and made easier.
Essentially, we could dispense with this discussion if we could stop it bei= ng any type of issue to have a normative reference to an Informational RFC.=

So, here's wher= e I'm getting stuck.

Standards-track and BCP drafts require 2/3rds of the IESG to ballot Yes or= No Objection (with no Discusses), while Informational, Experimental, and H= istoric drafts require only one Yes (and no Discusses). All this, per=C2=A0= https://www.ie= tf.org/iesg/voting-procedures.html.

So my question is, if a terminology or architecture draft i= s going to be foundational for Standards-track or BCP drafts, is it OK that= the foundational draft requires less review than the drafts that are build= ing on it?

If that's= not a problem, with some plausible reasoning why not(*), I'd be fine w= ith allowing Normative references to Informational RFCs, with no special at= tention.

(*) I'm not= suggesting this is plausible reasoning, but it's worth noting that mos= t of the Informational documents we process are balloted by more than half = the IESG, even though one Yes is sufficient, and most go though reviews fro= m multiple review teams before they appear on a telechat agenda. So maybe t= his is a distinction without a difference, and that is sufficient to justif= y allowing Normative references to Informational RFCs.=C2=A0

It's also worth noting that worki= ng group charters also require only one Yes (and no Blocks), and one might = think charters are at least as foundational as terminology or architecture = drafts.

If those aren= 9;t a good enough alibis, maybe someone could come up with another one ;-)<= /div>

Spencer

> The question is: when stating that th= e protocol widget is shaped a particular
> way in order to satisfy a particular requirement, do you need to make = normative
> or informative reference to that requirement, and so should the refere= nce be
> Standards Track or downwards-referenced Informational.
>
> Again informative references are fine!

I should point you at https://ww= w.ietf.org/iesg/statement/normative-informative.html
This says that
| Normative references specify documents that must be read to understand or=
| implement the technology in the new RFC, or whose technology must be
| present for the technology in the new RFC to work.

The crunch is "understand the technology". That makes the line ha= rd to draw.

> > Why is this question important?
> > The working groups spend a lot of cycles trying to decide what tr= ack to put
> > documents on. Cycles cost money and ruin lives. My approach now i= s to have
> > a quick guess and punt to the IESG.
> > But it is apparent that the IESG is also burning cycles.
> > Maybe a clear directive would allow everyone to get on with their= lives and
> > spend time writing code.
>
> Again, I wasn=E2=80=99t aware of this kind of confusion. Yes, there ar= e a lot of discussions
> about the right status but there is also existing documentation about = what the
> different cases mean. For some document it=E2=80=99s sometimes also no= t that clear but
> usually my advise as AD is to make some choice and then wait for furth= er
> feedback in the IESG evaluation and IETF last call.

OK. We are both taking the same approach :-)
But I am wondering (out loud) whether we could do better by pushing the inf= ormation that feeds the final decision down the stack a little.
Why should we be "guessing" and getting the answer from our super= iors? Why should we not know how to make the right decision?

> However, in your case, it=E2=80=99s actually very clear to me that thi= s document must be
> informational and as I said in my discuss I really don=E2=80=99t even = see the point about
> future references because informative references are fine anyway.

Well, I think I addressed your second part above.

As to "should *this* document be one thing or another" I suspect = no-one responsible for the production actually cares. They simply want the = document published. But they are also wary of a road crash later.

So what I am doing (in case it was not obvious) is gathering a paper trail = that will allow the chairs to say to a future IESG, "Tough! This is wh= at we were told to do and so the [future] document cannot be held up by thi= s situation."

Of course, I'd be happy to not have to do this on a document-by-documen= t basis. So some clearer direction from the IESG would always be welcome.
Thanks,
Adrian


--001a113fc5dad836bd054d39dac5-- From nobody Tue Apr 18 13:29:44 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583412943F for ; Tue, 18 Apr 2017 13:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 1CdA49lQbHMD for ; Tue, 18 Apr 2017 13:29:36 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F2A129443 for ; Tue, 18 Apr 2017 13:29:36 -0700 (PDT) Received: (qmail 11367 invoked from network); 18 Apr 2017 22:29:34 +0200 Received: from p5dec25a2.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.162) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Apr 2017 22:29:34 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> Date: Tue, 18 Apr 2017 22:29:33 +0200 Cc: i2nsf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Alissa Cooper , IESG , i2nsf-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:29:38 -0000 Hi Adrian, again I, as AD and also as chair and contributor, didn=E2=80=99t notice = this to be such a big problem. Yes there are over and over again = discussions about what the right intented status is but often these are = between standards track and experimental or BCP and informational=E2=80=A6= Anyway to your questions below. > Am 15.04.2017 um 12:49 schrieb Adrian Farrel : >=20 > So let's assume we have a terminology document in our hands. Clearly = (?) you can't use terms from that document without a reference to it. Is = that reference normative or not? Probably it is normative because how = can the reader of a protocol spec know what is being discussed if they = don't know the terms? Often terminology does not need a normative reference; it=E2=80=99s = rather a "if you are not sure, please see these documents for better = definitions". So the approach that is often taken is, to list the terms = and give an informational reference to the document where they are = specified. I think that=E2=80=99s a good approach. If that=E2=80=99s not good enough, you may also copy all or some of the = terminology section (usually less preferred by at least this IESG) into = the protocol spec itself or, of course, it still is possible to have a = down-ref if that seems useful in a specific case. >=20 > Now more to an architecture document. This document describes the = components and interfaces. It indicates what the senders and receivers = of a protocol message are and what they are doing. Maybe in a very dry = protocol spec you can avoid making a reference to the architecture = normative, but probably not. Architecture documents may be different and that's one of the cases = where the situation may be sometimes less clear. However, there are also = protocols that can be correctly implemented without understanding all = architectural consideration that lead to the final design. My general = advise would be to have architecture documents as informational and = potentially briefly summarize anything that may be important to know to = understand the protocol spec in the protocol spec itself. However, this = might be different from case to case. >=20 > And what about a problem statement document that introduces terms and = architecture? Isn't that document going to need to be referenced, and = because the protocol specs rely on those terms and that architecture, = isn't that reference normative? See above; keep the reference informational and briefly summarize if = really needed. Mirja From nobody Tue Apr 18 18:13:47 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331931243F3 for ; Tue, 18 Apr 2017 18:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xReuIrZFdYIf for ; Tue, 18 Apr 2017 18:13:40 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FFB1292F5 for ; Tue, 18 Apr 2017 18:13:39 -0700 (PDT) Received: (qmail 15830 invoked from network); 19 Apr 2017 03:06:57 +0200 Received: from p5dec224d.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.34.77) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Apr 2017 03:06:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> Date: Wed, 19 Apr 2017 03:06:55 +0200 Cc: i2nsf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Alissa Cooper , IESG , i2nsf-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 01:13:41 -0000 One more point: I=E2=80=99ve noticed your point that at some point = people just want to get their document through the process. I=E2=80=99m = aware of this =E2=80=9Aproblem=E2=80=98. On the one hand, I think that = actually good: I=E2=80=99m happy if people are sure about the content = and see no problem in letting the IESG figure out the actual less = important questions about processing. On the other hand, I agree that we = should of course try to avoid any kind of confusion people may have. = However, in this case I (still) don=E2=80=99t understand well where this = confusion is coming from and as such, at least I, don=E2=80=99t know how = to clarify. I=E2=80=99m pretty sure we will further discuss this at the = up-coming retreat though. Mirja > Am 18.04.2017 um 22:29 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi Adrian, >=20 > again I, as AD and also as chair and contributor, didn=E2=80=99t = notice this to be such a big problem. Yes there are over and over again = discussions about what the right intented status is but often these are = between standards track and experimental or BCP and informational=E2=80=A6= >=20 > Anyway to your questions below. >=20 >> Am 15.04.2017 um 12:49 schrieb Adrian Farrel : >>=20 >> So let's assume we have a terminology document in our hands. Clearly = (?) you can't use terms from that document without a reference to it. Is = that reference normative or not? Probably it is normative because how = can the reader of a protocol spec know what is being discussed if they = don't know the terms? >=20 > Often terminology does not need a normative reference; it=E2=80=99s = rather a "if you are not sure, please see these documents for better = definitions". So the approach that is often taken is, to list the terms = and give an informational reference to the document where they are = specified. I think that=E2=80=99s a good approach. >=20 > If that=E2=80=99s not good enough, you may also copy all or some of = the terminology section (usually less preferred by at least this IESG) = into the protocol spec itself or, of course, it still is possible to = have a down-ref if that seems useful in a specific case. >=20 >>=20 >> Now more to an architecture document. This document describes the = components and interfaces. It indicates what the senders and receivers = of a protocol message are and what they are doing. Maybe in a very dry = protocol spec you can avoid making a reference to the architecture = normative, but probably not. >=20 > Architecture documents may be different and that's one of the cases = where the situation may be sometimes less clear. However, there are also = protocols that can be correctly implemented without understanding all = architectural consideration that lead to the final design. My general = advise would be to have architecture documents as informational and = potentially briefly summarize anything that may be important to know to = understand the protocol spec in the protocol spec itself. However, this = might be different from case to case. >=20 >>=20 >> And what about a problem statement document that introduces terms and = architecture? Isn't that document going to need to be referenced, and = because the protocol specs rely on those terms and that architecture, = isn't that reference normative? >=20 > See above; keep the reference informational and briefly summarize if = really needed. >=20 > Mirja >=20 >=20 >=20 >=20 From nobody Tue Apr 18 19:36:54 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F96128D6F; Tue, 18 Apr 2017 19:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 wvidAdKHuA6T; Tue, 18 Apr 2017 19:36:47 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 873D1128616; Tue, 18 Apr 2017 19:36:47 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id 72so5521998pge.2; Tue, 18 Apr 2017 19:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=l3fWcEPYpHbA926nPT73WJQucg2e83PjcrUB9yfreP0=; b=elGltBdCH3qWmGrbPxXT/EehAZlMWmRQD5K3q0MchWsfZcQbKH0jUYFf/eO1AYgwHb /If/940qsBL3kTHBTXTUtxisUCobLiSVZT8KkHJPnbbYUG8X0A3dcaGi2wHx/bILoxRF ND3qQMGYCyOI0uBVING2aj28GTdhlhRuKidINE6DABdAkYN+abbP0vtFbkfuwYgo/CGZ i77jHNiwbyp1wHZjHuLteD5mgcBZlRBK9u/6o4O7IGTqaOvo0lkOuYNlQ9tqSEVY/8Ow /wZEl/D8ZzLnkljXC6Q5AQ3G0TAGIZyHLUEtdQqyVR9MjA7v1QLbIG0i571tYMgkee91 rsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l3fWcEPYpHbA926nPT73WJQucg2e83PjcrUB9yfreP0=; b=KM9nJfKKhHzwCayn3B0aEV0bOpNHgN36yia2cIzt1qAsKMAW6PIhZ1QcUn6+C49VAK KXGQQmL1z4PVCROj0ANRVIvO+cO4shbaP0AjaP0KXO4b7fQM2vDk4JiCe1TJn4b/HGAx YFjPT98VAFRODBWKZh+K6vGiV7oS3oXfiIJ0Ut1g1s+7KOvxE+6DpWF9GQgLtRH9tIBM yqumClZ7WxGEqgAvyjHUW2v4DOg0e3l3NLT7IJ7AP8Up9V9iq/PC09ghmsRRw9clgOG8 wq96SM4Iv14I+3HCx5ecpjdyPNWPeluyvOPXgn5r8t5HPExQlq25wHvSl0FuRUw6g7c7 xOBA== X-Gm-Message-State: AN3rC/43TAh0ruefGcD8eML527d0bV0iWgOXFtgDg93phrWnyFQbtR6l keMMIom7QgDjuY4CjajiY4S+0VqjGQ== X-Received: by 10.98.8.143 with SMTP id 15mr660222pfi.268.1492569407116; Tue, 18 Apr 2017 19:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.41 with HTTP; Tue, 18 Apr 2017 19:36:06 -0700 (PDT) In-Reply-To: References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> From: Kathleen Moriarty Date: Tue, 18 Apr 2017 22:36:06 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: "adrian@olddog.co.uk" , "i2nsf@ietf.org" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Alissa Cooper , IESG , i2nsf-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 02:36:49 -0000 On Tue, Apr 18, 2017 at 9:06 PM, Mirja Kuehlewind (IETF) wrote: > One more point: I=E2=80=99ve noticed your point that at some point people= just want to get their document through the process. I=E2=80=99m aware of = this =E2=80=9Aproblem=E2=80=98. On the one hand, I think that actually good= : I=E2=80=99m happy if people are sure about the content and see no problem= in letting the IESG figure out the actual less important questions about p= rocessing. On the other hand, I agree that we should of course try to avoid= any kind of confusion people may have. However, in this case I (still) don= =E2=80=99t understand well where this confusion is coming from and as such,= at least I, don=E2=80=99t know how to clarify. I=E2=80=99m pretty sure we = will further discuss this at the up-coming retreat though. Yes, I agree that we should discuss these types of documents and our published guidance on them to assist working groups at the retreat. Adrian raised some important points I would bet many in the IESG didn't read since this was just on the thread for your ballot. It would be more fair to WGs if we could update the guidance. If there will be a number of abstains on this type of document, then informational is the only way they will get published. Adrian raised a number of very good points that should get considered prior to any such update IMO. I've always been fine with supporting what the WG decides is best for them to accomplish their work goals, so I do support publishing support documents. Thank you both for the discussion. > > Mirja > > >> Am 18.04.2017 um 22:29 schrieb Mirja Kuehlewind (IETF) : >> >> Hi Adrian, >> >> again I, as AD and also as chair and contributor, didn=E2=80=99t notice = this to be such a big problem. Yes there are over and over again discussion= s about what the right intented status is but often these are between stand= ards track and experimental or BCP and informational=E2=80=A6 >> >> Anyway to your questions below. >> >>> Am 15.04.2017 um 12:49 schrieb Adrian Farrel : >>> >>> So let's assume we have a terminology document in our hands. Clearly (?= ) you can't use terms from that document without a reference to it. Is that= reference normative or not? Probably it is normative because how can the r= eader of a protocol spec know what is being discussed if they don't know th= e terms? >> >> Often terminology does not need a normative reference; it=E2=80=99s rath= er a "if you are not sure, please see these documents for better definition= s". So the approach that is often taken is, to list the terms and give an i= nformational reference to the document where they are specified. I think th= at=E2=80=99s a good approach. >> >> If that=E2=80=99s not good enough, you may also copy all or some of the = terminology section (usually less preferred by at least this IESG) into the= protocol spec itself or, of course, it still is possible to have a down-re= f if that seems useful in a specific case. >> >>> >>> Now more to an architecture document. This document describes the compo= nents and interfaces. It indicates what the senders and receivers of a prot= ocol message are and what they are doing. Maybe in a very dry protocol spec= you can avoid making a reference to the architecture normative, but probab= ly not. >> >> Architecture documents may be different and that's one of the cases wher= e the situation may be sometimes less clear. However, there are also protoc= ols that can be correctly implemented without understanding all architectur= al consideration that lead to the final design. My general advise would be = to have architecture documents as informational and potentially briefly sum= marize anything that may be important to know to understand the protocol sp= ec in the protocol spec itself. However, this might be different from case = to case. >> >>> >>> And what about a problem statement document that introduces terms and a= rchitecture? Isn't that document going to need to be referenced, and becaus= e the protocol specs rely on those terms and that architecture, isn't that = reference normative? >> >> See above; keep the reference informational and briefly summarize if rea= lly needed. >> >> Mirja >> >> >> >> > --=20 Best regards, Kathleen From nobody Wed Apr 19 12:13:50 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8F128DF6; Wed, 19 Apr 2017 12:13:44 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 X5JU7KEVGEXb; Wed, 19 Apr 2017 12:13:41 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 8E03A129C08; Wed, 19 Apr 2017 12:13:41 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id 6so11987602ybq.2; Wed, 19 Apr 2017 12:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tQxPo0BqXg/esmvucE5T03OdVTjbec04IU7/p1rhfWw=; b=iTgSetfGX1lNiNDF6oZYoQUBPSI52dVL0L0E6u5oDAZdvV7uq//vdsHPcmq3Mqm6L7 tCgx/Z+j7Dt0l02P2I7q/AcAnn0EhycPGJj3FxqQL+VDiGT6m78bZYgu4fqPXhpq28FJ e+M0Il8CscYlFwff9yTdlYrSeDhFMVzDb5J8B8AoQWViTZAZx6fLnq9OA5XP+FFJc/p9 z7nZmL5emNzw7Yof6MSlK+sbPyaXbPa/fH88iJPaY5D3daQO1ZtAxItGs6hp/yiI+zrj PcwPzT4Iaxs9HSftauvKs4jOlN271q8uFgYDF9OZ42thQg0TZGS1kQcRyoU8U7TG7g0p L5MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tQxPo0BqXg/esmvucE5T03OdVTjbec04IU7/p1rhfWw=; b=H9O7QQwRqXIF9VHrLiE5PEhKXhxs3M6rA8DU46rHb5wDr0J0Pse7AwqOHYFbWnnQYt c+KTRlbrM2rWAvxNXs3ve09yBSGBUybpqDvniI9Rk8fN8APXsr9cLqWMO/AiN+eloJ8/ ZFUkR5tVSFKukxFFyOipZ2rw5TYk4/YuJrQEdB9Bo2YY8k3zChMQaR9Ksn/jIt2BynUq cfCAvQ2XTDWb3AyIPhJv9m/eFgV85/0YJoLZqRNZgDFLvQCA1+4Xi9Ry+alAzc0mDL8i nyw7AzqqrexwuUN2xd5XAYrAcMzy547iMLlR/39Bph5Bk56brMrM6APeg390ap9voVvo pfdQ== X-Gm-Message-State: AN3rC/6RZvSKNo14lvfDwDwXC39gdJmS90lsF+0ujmmi/tyG0OfP/+pB xtocitKRY7hg/NC2eskX57hpYwxmchEk X-Received: by 10.37.125.196 with SMTP id y187mr3630059ybc.22.1492629220639; Wed, 19 Apr 2017 12:13:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 19 Apr 2017 12:13:40 -0700 (PDT) In-Reply-To: References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> From: Spencer Dawkins at IETF Date: Wed, 19 Apr 2017 14:13:40 -0500 Message-ID: To: Kathleen Moriarty Cc: "Mirja Kuehlewind (IETF)" , "i2nsf@ietf.org" , Alissa Cooper , IESG , i2nsf-chairs@ietf.org, "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org Content-Type: multipart/alternative; boundary=001a114dd3c67a6199054d89d2c5 Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:13:44 -0000 --001a114dd3c67a6199054d89d2c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Kathleen, On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > On Tue, Apr 18, 2017 at 9:06 PM, Mirja Kuehlewind (IETF) > wrote: > > One more point: I=E2=80=99ve noticed your point that at some point peop= le just > want to get their document through the process. I=E2=80=99m aware of this > =E2=80=9Aproblem=E2=80=98. On the one hand, I think that actually good: I= =E2=80=99m happy if people > are sure about the content and see no problem in letting the IESG figure > out the actual less important questions about processing. On the other > hand, I agree that we should of course try to avoid any kind of confusion > people may have. However, in this case I (still) don=E2=80=99t understand= well > where this confusion is coming from and as such, at least I, don=E2=80=99= t know how > to clarify. I=E2=80=99m pretty sure we will further discuss this at the u= p-coming > retreat though. > > Yes, I agree that we should discuss these types of documents and our > published guidance on them to assist working groups at the retreat. > I agree. Am I adding this to https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you? Spencer > Adrian raised some important points I would bet many in the IESG > didn't read since this was just on the thread for your ballot. It > would be more fair to WGs if we could update the guidance. If there > will be a number of abstains on this type of document, then > informational is the only way they will get published. Adrian raised > a number of very good points that should get considered prior to any > such update IMO. I've always been fine with supporting what the WG > decides is best for them to accomplish their work goals, so I do > support publishing support documents. > > Thank you both for the discussion. > > > > > Mirja > > > > > >> Am 18.04.2017 um 22:29 schrieb Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net>: > >> > >> Hi Adrian, > >> > >> again I, as AD and also as chair and contributor, didn=E2=80=99t notic= e this to > be such a big problem. Yes there are over and over again discussions abou= t > what the right intented status is but often these are between standards > track and experimental or BCP and informational=E2=80=A6 > >> > >> Anyway to your questions below. > >> > >>> Am 15.04.2017 um 12:49 schrieb Adrian Farrel : > >>> > >>> So let's assume we have a terminology document in our hands. Clearly > (?) you can't use terms from that document without a reference to it. Is > that reference normative or not? Probably it is normative because how can > the reader of a protocol spec know what is being discussed if they don't > know the terms? > >> > >> Often terminology does not need a normative reference; it=E2=80=99s ra= ther a > "if you are not sure, please see these documents for better definitions". > So the approach that is often taken is, to list the terms and give an > informational reference to the document where they are specified. I think > that=E2=80=99s a good approach. > >> > >> If that=E2=80=99s not good enough, you may also copy all or some of th= e > terminology section (usually less preferred by at least this IESG) into t= he > protocol spec itself or, of course, it still is possible to have a down-r= ef > if that seems useful in a specific case. > >> > >>> > >>> Now more to an architecture document. This document describes the > components and interfaces. It indicates what the senders and receivers of= a > protocol message are and what they are doing. Maybe in a very dry protoco= l > spec you can avoid making a reference to the architecture normative, but > probably not. > >> > >> Architecture documents may be different and that's one of the cases > where the situation may be sometimes less clear. However, there are also > protocols that can be correctly implemented without understanding all > architectural consideration that lead to the final design. My general > advise would be to have architecture documents as informational and > potentially briefly summarize anything that may be important to know to > understand the protocol spec in the protocol spec itself. However, this > might be different from case to case. > >> > >>> > >>> And what about a problem statement document that introduces terms and > architecture? Isn't that document going to need to be referenced, and > because the protocol specs rely on those terms and that architecture, isn= 't > that reference normative? > >> > >> See above; keep the reference informational and briefly summarize if > really needed. > >> > >> Mirja > >> > >> > >> > >> > > > > > > -- > > Best regards, > Kathleen > > --001a114dd3c67a6199054d89d2c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Kathleen,

On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
On Tue, Apr= 18, 2017 at 9:06 PM, Mirja Kuehlewind (IETF)
<ietf@kuehlewind.net> wrot= e:
> One more point: I=E2=80=99ve noticed your point that at some point peo= ple just want to get their document through the process. I=E2=80=99m aware = of this =E2=80=9Aproblem=E2=80=98. On the one hand, I think that actually g= ood: I=E2=80=99m happy if people are sure about the content and see no prob= lem in letting the IESG figure out the actual less important questions abou= t processing. On the other hand, I agree that we should of course try to av= oid any kind of confusion people may have. However, in this case I (still) = don=E2=80=99t understand well where this confusion is coming from and as su= ch, at least I, don=E2=80=99t know how to clarify. I=E2=80=99m pretty sure = we will further discuss this at the up-coming retreat though.

Yes, I agree that we should discuss these types of documents and our=
published guidance on them to assist working groups at the retreat.

I agree. Am I adding this to=C2=A0https://trac.ietf.org/trac= /iesg/wiki/RetreatInfo, or should you?=C2=A0

S= pencer
=C2=A0
Adrian raised some important points I would bet many in the IESG
didn't read since this was just on the thread for your ballot.=C2=A0 It=
would be more fair to WGs if we could update the guidance.=C2=A0 If there will be a number of abstains on this type of document, then
informational is the only way they will get published.=C2=A0 Adrian raised<= br> a number of very good points that should get considered prior to any
such update IMO.=C2=A0 I've always been fine with supporting what the W= G
decides is best for them to accomplish their work goals, so I do
support publishing support documents.

Thank you both for the discussion.

>
> Mirja
>
>
>> Am 18.04.2017 um 22:29 schrieb Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>:
>>
>> Hi Adrian,
>>
>> again I, as AD and also as chair and contributor, didn=E2=80=99t n= otice this to be such a big problem. Yes there are over and over again disc= ussions about what the right intented status is but often these are between= standards track and experimental or BCP and informational=E2=80=A6
>>
>> Anyway to your questions below.
>>
>>> Am 15.04.2017 um 12:49 schrieb Adrian Farrel <adrian@olddog.co.uk>:
>>>
>>> So let's assume we have a terminology document in our hand= s. Clearly (?) you can't use terms from that document without a referen= ce to it. Is that reference normative or not? Probably it is normative beca= use how can the reader of a protocol spec know what is being discussed if t= hey don't know the terms?
>>
>> Often terminology does not need a normative reference; it=E2=80=99= s rather a "if you are not sure, please see these documents for better= definitions". So the approach that is often taken is, to list the ter= ms and give an informational reference to the document where they are speci= fied. I think that=E2=80=99s a good approach.
>>
>> If that=E2=80=99s not good enough, you may also copy all or some o= f the terminology section (usually less preferred by at least this IESG) in= to the protocol spec itself or, of course, it still is possible to have a d= own-ref if that seems useful in a specific case.
>>
>>>
>>> Now more to an architecture document. This document describes = the components and interfaces. It indicates what the senders and receivers = of a protocol message are and what they are doing. Maybe in a very dry prot= ocol spec you can avoid making a reference to the architecture normative, b= ut probably not.
>>
>> Architecture documents may be different and that's one of the = cases where the situation may be sometimes less clear. However, there are a= lso protocols that can be correctly implemented without understanding all a= rchitectural consideration that lead to the final design. My general advise= would be to have architecture documents as informational and potentially b= riefly summarize anything that may be important to know to understand the p= rotocol spec in the protocol spec itself. However, this might be different = from case to case.
>>
>>>
>>> And what about a problem statement document that introduces te= rms and architecture? Isn't that document going to need to be reference= d, and because the protocol specs rely on those terms and that architecture= , isn't that reference normative?
>>
>> See above; keep the reference informational and briefly summarize = if really needed.
>>
>> Mirja
>>
>>
>>
>>
>



--

Best regards,
Kathleen


--001a114dd3c67a6199054d89d2c5-- From nobody Wed Apr 19 12:16:46 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047F2128B44; Wed, 19 Apr 2017 12:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 5vBGcqeONmkf; Wed, 19 Apr 2017 12:16:36 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 BFA2612896F; Wed, 19 Apr 2017 12:16:36 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id 81so13555326ybp.0; Wed, 19 Apr 2017 12:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IHPVjxAs3hj05MbqMkbt9CIIJB8M3t6T8FNkS5PRn/M=; b=Gasqw9ruTMQpMOPceuQ14eP9EXs8C1wvsEfZ9qo4A43MjnxzdnDAmeLuC2xUi8rmNg n2/byrahvsyPkExaFfCjAPjLWMMpn0veP8GwMLs+W9cit9B6ejmA9AJfk6mw6c/HCEIa nZT9QCIPB9vh82aF3O0wXd7sQpuvOefgxyrs+3cKKAqFcLhg67CkpdKlkwLcbWxPHG1P OmqWygIUqk07ltJF3+5R3x5MbNC+SkBW1mJOb0PlJxh7vwehqNp6tegUzf0a1pLS6lrL J3KyKlsOdp+6fa7zyCzG795hOoMG9V03xFji3H2r8uq1fe7RkexALSN6uPyCP/KrW/7D DLsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IHPVjxAs3hj05MbqMkbt9CIIJB8M3t6T8FNkS5PRn/M=; b=Vfz2/9VkEXePNODKWz8/UGIXgOg8PF6MRU2wtiQPj/bJbzFfZ947hgx9Vd42HiVPOZ qvFSTQYjuUlAVrYLbkBR6seZDs44frRY7XigjY4ZBNl1sfwxJj11K58LXwdGs/ns+0ye 6k7Wdlk9Sr23Y2yhAyBp9iiiExryPwomvLTTmBQ7CJ5pYIWOVIvlTVqiGgi+W6Fvt1Qo 9VMxJCPyzdOcKGIutCVc9lH3U71vMG5ffExSsESd+2GfKqbW87vcqZ6oiD8dfbFhU/Fy 4faOPpacM3WsWW/lONonXIwhTU1X35eRgujyTJr+0mi+4X9Eu+TKDn/et2lC7N9cvymQ lVTA== X-Gm-Message-State: AN3rC/59atu9GLDrsQbGJKzBX+x3MDA/ONd311AVdfo+Qzwfo06WzQCg yujHpLCfEoV+hsKdfeItAAxwqNPmrA== X-Received: by 10.98.60.134 with SMTP id b6mr4397929pfk.19.1492629395885; Wed, 19 Apr 2017 12:16:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.41 with HTTP; Wed, 19 Apr 2017 12:15:55 -0700 (PDT) In-Reply-To: References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> From: Kathleen Moriarty Date: Wed, 19 Apr 2017 15:15:55 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: "Mirja Kuehlewind (IETF)" , "i2nsf@ietf.org" , Alissa Cooper , IESG , i2nsf-chairs@ietf.org, "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:16:39 -0000 On Wed, Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF wrote: > Hi, Kathleen, > > On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty > wrote: >> >> On Tue, Apr 18, 2017 at 9:06 PM, Mirja Kuehlewind (IETF) >> wrote: >> > One more point: I=E2=80=99ve noticed your point that at some point peo= ple just >> > want to get their document through the process. I=E2=80=99m aware of t= his =E2=80=9Aproblem=E2=80=98. >> > On the one hand, I think that actually good: I=E2=80=99m happy if peop= le are sure >> > about the content and see no problem in letting the IESG figure out th= e >> > actual less important questions about processing. On the other hand, I= agree >> > that we should of course try to avoid any kind of confusion people may= have. >> > However, in this case I (still) don=E2=80=99t understand well where th= is confusion >> > is coming from and as such, at least I, don=E2=80=99t know how to clar= ify. I=E2=80=99m >> > pretty sure we will further discuss this at the up-coming retreat thou= gh. >> >> Yes, I agree that we should discuss these types of documents and our >> published guidance on them to assist working groups at the retreat. > > > I agree. Am I adding this to > https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you? Go for it! Do you want to work together on this? I think it's important to capture Adrian's input for this discussion. Thank you, Kathleen > > Spencer > >> >> Adrian raised some important points I would bet many in the IESG >> didn't read since this was just on the thread for your ballot. It >> would be more fair to WGs if we could update the guidance. If there >> will be a number of abstains on this type of document, then >> informational is the only way they will get published. Adrian raised >> a number of very good points that should get considered prior to any >> such update IMO. I've always been fine with supporting what the WG >> decides is best for them to accomplish their work goals, so I do >> support publishing support documents. >> >> Thank you both for the discussion. >> >> > >> > Mirja >> > >> > >> >> Am 18.04.2017 um 22:29 schrieb Mirja Kuehlewind (IETF) >> >> : >> >> >> >> Hi Adrian, >> >> >> >> again I, as AD and also as chair and contributor, didn=E2=80=99t noti= ce this to >> >> be such a big problem. Yes there are over and over again discussions = about >> >> what the right intented status is but often these are between standar= ds >> >> track and experimental or BCP and informational=E2=80=A6 >> >> >> >> Anyway to your questions below. >> >> >> >>> Am 15.04.2017 um 12:49 schrieb Adrian Farrel : >> >>> >> >>> So let's assume we have a terminology document in our hands. Clearly >> >>> (?) you can't use terms from that document without a reference to it= . Is >> >>> that reference normative or not? Probably it is normative because ho= w can >> >>> the reader of a protocol spec know what is being discussed if they d= on't >> >>> know the terms? >> >> >> >> Often terminology does not need a normative reference; it=E2=80=99s r= ather a >> >> "if you are not sure, please see these documents for better definitio= ns". So >> >> the approach that is often taken is, to list the terms and give an >> >> informational reference to the document where they are specified. I t= hink >> >> that=E2=80=99s a good approach. >> >> >> >> If that=E2=80=99s not good enough, you may also copy all or some of t= he >> >> terminology section (usually less preferred by at least this IESG) in= to the >> >> protocol spec itself or, of course, it still is possible to have a do= wn-ref >> >> if that seems useful in a specific case. >> >> >> >>> >> >>> Now more to an architecture document. This document describes the >> >>> components and interfaces. It indicates what the senders and receive= rs of a >> >>> protocol message are and what they are doing. Maybe in a very dry pr= otocol >> >>> spec you can avoid making a reference to the architecture normative,= but >> >>> probably not. >> >> >> >> Architecture documents may be different and that's one of the cases >> >> where the situation may be sometimes less clear. However, there are a= lso >> >> protocols that can be correctly implemented without understanding all >> >> architectural consideration that lead to the final design. My general= advise >> >> would be to have architecture documents as informational and potentia= lly >> >> briefly summarize anything that may be important to know to understan= d the >> >> protocol spec in the protocol spec itself. However, this might be dif= ferent >> >> from case to case. >> >> >> >>> >> >>> And what about a problem statement document that introduces terms an= d >> >>> architecture? Isn't that document going to need to be referenced, an= d >> >>> because the protocol specs rely on those terms and that architecture= , isn't >> >>> that reference normative? >> >> >> >> See above; keep the reference informational and briefly summarize if >> >> really needed. >> >> >> >> Mirja >> >> >> >> >> >> >> >> >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > --=20 Best regards, Kathleen From nobody Wed Apr 19 12:17:35 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4599C128B44; Wed, 19 Apr 2017 12:17:33 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 TSG_LEymDac4; Wed, 19 Apr 2017 12:17:32 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 D2635126CD8; Wed, 19 Apr 2017 12:17:31 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 81so13586883ybp.0; Wed, 19 Apr 2017 12:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nVu0GcX9PvJ2wtAYdN0C5l9c6ieZgjFkGdb2K3hLgbM=; b=bRTBXNn84m1GDgctooYj1gLRMImPCVl24D0j5bGLARnM8xO8BsLJW/WJejkqYsDsVQ zaAinHF5EIUX0/zFfV0iFWH8Bw7qJuzJX1A+wwbQwOErabCMUqGlD4mk6slUth+u8rHx 2OJPwFmc1SYyvJB8krkpL4UuKepyKqXmeq+pTsQWgup0NVlgtiGai0hxE8W6J3bfYhzk l+pkheUZ502pa9OVaonl6ShmLCsWHdaIO5p3E8GIde5QE5IUmZpguCuwauLHfjr5B8LM t8V3qRQmKsm2zDa8HNZ+hVQKfk+d/Kjg7voYiIsW6y27phkExolSwDujEFNOp3wr6huG i4QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nVu0GcX9PvJ2wtAYdN0C5l9c6ieZgjFkGdb2K3hLgbM=; b=BSHeyED9bGzaDXJpOTH/d+5jWueYCkghKq2BQ1uXJ0bL8MyVSscT1vjf82V9oqLJgY DumB4YghXXAKreMtBNaYy1AVVGol1rc1Qx2F3XsJK8F0owEOWpT3umNw47OcVVEgzvxh HiuH28yP2nxtveviswNjdzxg50ExR7H73yMQXXkGFAwl6ke09b1tT3aRI4B0iBGKbgOv /ka78IuvpvoPiZ5tcbpXKFJZpOW/Qr9pG9CnAkGt3tfnXeYdRADr5e7gMagmZ9zxnPmD NKiu8gRBswdnr2w1JxIACNmABnzeAI2izEy2XLiBYUmi2bWhrCO+8V0Pli3dopiOfc0h A0Kw== X-Gm-Message-State: AN3rC/73i2ZNK4Y6ypAl9jOBj/ith04Bpr3TPSXDpsVtQ0F0hqZNRxhN d2Rqf0voWNYcvIBgEr70YQgK1zuN1A== X-Received: by 10.37.88.137 with SMTP id m131mr3606111ybb.12.1492629451188; Wed, 19 Apr 2017 12:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 19 Apr 2017 12:17:30 -0700 (PDT) In-Reply-To: References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> From: Spencer Dawkins at IETF Date: Wed, 19 Apr 2017 14:17:30 -0500 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: "adrian@olddog.co.uk" , i2nsf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Alissa Cooper , IESG , i2nsf-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a113fc5da38338c054d89e0cf Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:17:33 -0000 --001a113fc5da38338c054d89e0cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, On Tue, Apr 18, 2017 at 8:06 PM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > One more point: I=E2=80=99ve noticed your point that at some point people= just > want to get their document through the process. I=E2=80=99m aware of this > =E2=80=9Aproblem=E2=80=98. On the one hand, I think that actually good: I= =E2=80=99m happy if people > are sure about the content and see no problem in letting the IESG figure > out the actual less important questions about processing. On the other > hand, I agree that we should of course try to avoid any kind of confusion > people may have. And, on the OTHER other hand, I've certainly seen authors who said "just tell me what it needs to say, to clear your Discuss". Happily, I've seen less of that with recent IESGs, but it's still something we need to watch for. If the AD knew what the document should say better than the authors, the wrong person is the author ... Spencer --001a113fc5da38338c054d89e0cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW,

On Tue, Apr 18, 2017 at 8:06 PM, Mirja Kuehlewind (IETF) <ietf@kueh= lewind.net> wrote:
One more= point: I=E2=80=99ve noticed your point that at some point people just want= to get their document through the process. I=E2=80=99m aware of this =E2= =80=9Aproblem=E2=80=98. On the one hand, I think that actually good: I=E2= =80=99m happy if people are sure about the content and see no problem in le= tting the IESG figure out the actual less important questions about process= ing. On the other hand, I agree that we should of course try to avoid any k= ind of confusion people may have.=C2=A0

And= , on the OTHER other hand, I've certainly seen authors who said "j= ust tell me what it needs to say, to clear your Discuss".=C2=A0
<= div>
Happily, I've seen less of that with recent IESGs, b= ut it's still something we need to watch for. If the AD knew what the d= ocument should say better than the authors, the wrong person is the author = ...

Spencer=C2=A0
--001a113fc5da38338c054d89e0cf-- From nobody Wed Apr 19 12:37:15 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB611129B4B; Wed, 19 Apr 2017 12:37:08 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 n7zkAZqnJH5V; Wed, 19 Apr 2017 12:37:07 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 352751243F3; Wed, 19 Apr 2017 12:37:07 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id 6so12715465ybq.2; Wed, 19 Apr 2017 12:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zkfSZdhA7Pv8mQRYpilBQ3X1v0kvbqqW9GEEWPZU+x0=; b=soIaOBhu3XlBeN9wvMCv7B6DTdwR0GkdUtYJezhHeAkImvvkhJLjHoBOoFPCsXxr6t Cua4YqYKxBrvNqT58LrDdXnHjXDe7zIwUP6wVn1PTF4PRcZWqcY0nvPep423DZ24FeEv d58Q7fw6qZFWj7xtFanAPTYvlt4t5F+XrMz07/1Ut6cfoqVMgOP6GA2cGJGu2BMpASgj STtlNVfG6Fuom8VUeLI+cMWF03Y1uSEHrtwiw8fgnK3ILvXpXuSRSeSCC6d6UW7O+7N3 CjnJjmK/XtPmuMMwmccIS+G4r89cS05/5lSfmO3dUwRUgQooD1yjObTjYFRyP/zkuKyX xU/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zkfSZdhA7Pv8mQRYpilBQ3X1v0kvbqqW9GEEWPZU+x0=; b=cUelp43Hmazot6swcLrhNSj9jvoYmZcMwDQMZ0pSMY63+H0vjGHNTw0YfIY9QGs/gA H3QzO6m7fLWiHVdInGc4Xvb8XZDebKPjGoNwhcfS1NstJfzWAv//64TCmW8dVy+cT9wD e4+siysSvxBlvEtplY56Nb73pkgreFntgYMmpx0gLxQ3YfuX6ZkGbTuC+dlCGcYc0S4y 9+/GnDt4LjWEBQ3nxt+jHVrwUv6G9DcFZKH7fHAnhVN/UQi4zEnlxszz3iWptnTHfqlU zN/a4sOOZ4UcZ9tG7ASKb2mwME4NmahN8CAorwOeSjd3hDveTZ4tpyYWm7tkzZ9DGk8T o6RQ== X-Gm-Message-State: AN3rC/6sR7uhDLLTyZ8mX3H0Cawucc29GG37RtxMCkKeQMaxnQ94CqSB lBpPlXuwe4R17PwH6YI9ivdWAQEuHQhB X-Received: by 10.37.164.3 with SMTP id f3mr3632044ybi.182.1492630626535; Wed, 19 Apr 2017 12:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 19 Apr 2017 12:37:05 -0700 (PDT) In-Reply-To: References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> From: Spencer Dawkins at IETF Date: Wed, 19 Apr 2017 14:37:05 -0500 Message-ID: To: Kathleen Moriarty Cc: "Mirja Kuehlewind (IETF)" , "i2nsf@ietf.org" , Alissa Cooper , IESG , i2nsf-chairs@ietf.org, "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org Content-Type: multipart/alternative; boundary=f403045c665e468e8c054d8a261f Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:37:09 -0000 --f403045c665e468e8c054d8a261f Content-Type: text/plain; charset=UTF-8 Hi, Kathleen, On Wed, Apr 19, 2017 at 2:15 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > On Wed, Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF > wrote: > > Hi, Kathleen, > > > > On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty > > wrote: > >> > >> Yes, I agree that we should discuss these types of documents and our > >> published guidance on them to assist working groups at the retreat. > > > > > > I agree. Am I adding this to > > https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you? > > Go for it! Do you want to work together on this? I think it's > important to capture Adrian's input for this discussion. I added this as - Do we still agree with https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html? Does it say what it needs to say? (Kathleen) I'm happy to help prepare for this, and will let you lead the discussion :-) Spencer --f403045c665e468e8c054d8a261f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Kathleen,=C2=A0

On Wed, Apr 19, 2017 at 2:15 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
On Wed,= Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF
<spencerdawkins.ietf@gm= ail.com> wrote:
> Hi, Kathleen,
>
> On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
>>
>> Yes, I agree that we should discuss these types of documents and o= ur
>> published guidance on them to assist working groups at the retreat= .
>
>
> I agree. Am I adding this to
> https://trac.ietf.org/trac/iesg/wiki/Retre= atInfo, or should you?

Go for it!=C2=A0 Do you want to work together on this?=C2=A0 I think= it's
important to capture Adrian's input for this discussion.
I added this as=C2=A0
I'= m happy to help prepare for this, and will let you lead the discussion :-)<= br>
Spencer
=C2=A0
--f403045c665e468e8c054d8a261f-- From nobody Wed Apr 19 12:54:17 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BCF128D40; Wed, 19 Apr 2017 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 2M88lbda0OqN; Wed, 19 Apr 2017 12:54:08 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 215B1126CF9; Wed, 19 Apr 2017 12:54:08 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id o22so37028849iod.3; Wed, 19 Apr 2017 12:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lnoXRfHcFY6GV0H9GgQMYeONEwrMdrB3bjUgBMGWwT0=; b=YbT8YxALGU3VPwxSwhFNmHvTaN5aKxiY74Oo2xle7UWmyZZMbjNPmBPbD2aSmjNjnE xjx5P2bM2VMBHRzCOdboD5E0v8/o1hm0PQ3L/5inXrZoWkbpPR/5XdwG7l66EX5AG1Jg 1C4pzDsk3ZtTwrFR1eBDNJiXNg5FTXmxCFHgVFJh1BRX8OIjc4n9FoaDMS5KWjV8OUXQ MBHSEs4mtZOP6XxtxeprKP4qkKNLJa97RcYRsy2/JEAevtR/WOuO4qBe8IbOtxnviK+E fLOm6URcPnCzSZzB5zHsXT3enB/8F/tMXyd5J4O9oab/QSlDR1CTMUgoxTJ8Tk0ad/4D 1m5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lnoXRfHcFY6GV0H9GgQMYeONEwrMdrB3bjUgBMGWwT0=; b=krK1cqy6YC4phETAPyuXAOWzNas2GcZG27F202uy0npVKMYPbhCvEkCn/rVWoci654 gbyrei7WNwuXfZO2MH3hqEqfVIAydTXitOJcoSjRIShJrOvtabS9AZ86InJrYyT4XsW6 D53nEAXwlFpXHroeTwbUZ+Fus4KueZNFoDf50La2JHxD6x5fsEY3p849tHPtQeyFWH/Q D1W+MRXPz2AHK2IkWRwc762QEOB5iP6szTuF50uc33yLAGNBmKgKuwQ7bDhPthTfoG4H g+ag6enLonyVVnDGp7dKbe4OqVRbKssmsto9siReZS8qnaJ+bQRfQZ5wxt+JW067pNsi JKJA== X-Gm-Message-State: AN3rC/6BHW4N4G4l9PcfjkmFvXSxedfSrjBUmoZzZh1ZY3S75UfQ7zrN h9yoh597wrx8JP5u+UHZt52hH/4y/Q== X-Received: by 10.99.160.73 with SMTP id u9mr4580658pgn.176.1492631647536; Wed, 19 Apr 2017 12:54:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.41 with HTTP; Wed, 19 Apr 2017 12:53:26 -0700 (PDT) In-Reply-To: References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> From: Kathleen Moriarty Date: Wed, 19 Apr 2017 15:53:26 -0400 Message-ID: To: Spencer Dawkins at IETF Cc: "Mirja Kuehlewind (IETF)" , "i2nsf@ietf.org" , Alissa Cooper , IESG , i2nsf-chairs@ietf.org, "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:54:10 -0000 On Wed, Apr 19, 2017 at 3:37 PM, Spencer Dawkins at IETF wrote: > Hi, Kathleen, > > On Wed, Apr 19, 2017 at 2:15 PM, Kathleen Moriarty > wrote: >> >> On Wed, Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF >> wrote: >> > Hi, Kathleen, >> > >> > On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty >> > wrote: >> >> >> >> Yes, I agree that we should discuss these types of documents and our >> >> published guidance on them to assist working groups at the retreat. >> > >> > >> > I agree. Am I adding this to >> > https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you? >> >> Go for it! Do you want to work together on this? I think it's >> important to capture Adrian's input for this discussion. > > > I added this as > > Do we still agree with > https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html? Does > it say what it needs to say? (Kathleen) > > I'm happy to help prepare for this, and will let you lead the discussion :-) Thank you, Spencer! > > Spencer > -- Best regards, Kathleen From nobody Thu Apr 20 12:30:37 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7D41315F0 for ; Thu, 20 Apr 2017 12:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 U4aMIA363xq4 for ; Thu, 20 Apr 2017 12:30:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E011315FA for ; Thu, 20 Apr 2017 12:30:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFF42573; Thu, 20 Apr 2017 19:30:24 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Apr 2017 20:30:23 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML701-CHM.china.huawei.com ([169.254.3.8]) with mapi id 14.03.0235.001; Thu, 20 Apr 2017 12:30:14 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: I2NSF IETF 98 session Minutes has been uploaded Thread-Index: AdK6DFWKBvEHYb9BQNCA6088g/a6kg== Date: Thu, 20 Apr 2017 19:30:13 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F659275815@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.188] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F659275815SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58F90C50.0152, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ca5823fbe94e29105c4cb815c1bb98ea Archived-At: Subject: [I2nsf] I2NSF IETF 98 session Minutes has been uploaded X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 19:30:35 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F659275815SJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many thanks to the note taker: John Strassner, Frank Xia, and Sue Hares. He= re are the IETF98 I2NSF session minutes. If you find anything missing, plea= se let us know. https://www.ietf.org/proceedings/98/minutes/minutes-98-i2nsf-00 Linda & Adrian --_000_4A95BA014132FF49AE685FAB4B9F17F659275815SJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Many thanks to the note taker: John Strassner, Frank= Xia, and Sue Hares. Here are the IETF98 I2NSF session minutes. If you find= anything missing, please let us know.

https://www.ietf.org/proceedings/98/minutes/minutes= -98-i2nsf-00

 

Linda & Adrian

 

--_000_4A95BA014132FF49AE685FAB4B9F17F659275815SJCEML702CHMchi_-- From nobody Thu Apr 20 13:15:53 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5548C129B16; Thu, 20 Apr 2017 13:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 qTWo0D8KgnXu; Thu, 20 Apr 2017 13:15:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36E213163C; Thu, 20 Apr 2017 13:15:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFF46042; Thu, 20 Apr 2017 20:15:46 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Apr 2017 21:15:44 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Thu, 20 Apr 2017 13:15:35 -0700 From: Linda Dunbar To: "draft-abad-i2nsf-sdn-ipsec-flow-protection@ietf.org" , Gabriel Lopez , Rafa Marin Lopez , Sowmini Varadhan CC: "i2nsf@ietf.org" Thread-Topic: IPSec group's comment to draft-abad-i2nsf-sdn-ipsec-flow-protection Thread-Index: AdK6EhBlIIE3TD36TeykzmKyDIN8aQ== Date: Thu, 20 Apr 2017 20:15:34 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F659275882@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.188] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58F916F2.0124, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 07012e638f98336f2e1d074b1604399f Archived-At: Subject: [I2nsf] IPSec group's comment to draft-abad-i2nsf-sdn-ipsec-flow-protection X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 20:15:52 -0000 UmFmYSwgR2FicmllbCwgYW5kIFNvd21pbmksIA0KDQpIZXJlIGFyZSBzb21lIGNvbW1lbnRzIGZy b20gSVBTZWNNZSBncm91cCBmb3IgeW91ciBkcmFmdC1hYmFkLWkybnNmLXNkbi1pcHNlYy1mbG93 LXByb3RlY3Rpb24tMDEuIEkgdGhpbmsgaXQgd29ydGggdGhlIGNoZWNrDQoNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWW9hdiBOaXIgW21haWx0bzp5bmlyLmlldGZAZ21h aWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxMywgMjAxNyA0OjQyIFBNDQpUbzogTGlu ZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4NCkNjOiBJUHNlY0BpZXRmLm9yZzsg TWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+DQpTdWJqZWN0OiBSZTog W0lQc2VjXSBDYW4gSVBTZWMgKFJGQyA1OTk2KSBzdXBwb3J0IHR1bm5lbHMgd2l0aCBlbmQgcG9p bnQgYmVpbmcgKHZpcnR1YWwpIENQRXMgd2hpY2ggaGFzIGEgc2V0IG9mIHdvcmtsb2FkIGF0dGFj aGVkIChzYXkgVmlydHVhbCBNYWNoaW5lcykgYWxsIGhhdmluZyB2aXJ0dWFsIElQIGFkZHJlc3Nl cz8NCg0KPDxzbmlwPj4NCg0KPj4gLSBJMk5TRiBoYXMgYSBwcm9wb3NhbCBvbiB1c2luZyBDb250 cm9sbGVyIHRvIG1hbmFnZXIgYWxsIHRoZSBJUFNlYw0KPj4gdHVubmVsczoNCj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWJhZC1pMm5zZi1zZG4taXBzZWMt Zmxvdy1wcm90ZWN0aW9uLg0KPj4gV2hhdCBraW5kIG9mIGlzc3VlcyBkbyB5b3Ugc2VlIHdpdGgg dGhlIHByb3Bvc2VkIGFwcHJvYWNoPw0KPiANCj4gSSBkaWRuJ3QgcmVhZCBpdC4NCg0KSSBkaWQu IFRoZXkgaGF2ZSB0d28gY2FzZXMuIEluIGNhc2UgIzEgdGhlIGNvbnRyb2xsZXIgcHJvdmlzaW9u cyBjcmVkZW50aWFscyBmb3IgSUtFIGFuZCBlbnRyaWVzIGluIFBBRCBhbmQgU1BELiBJbiBjYXNl ICMyIHlvdSBmb3JlZ28gSUtFIGFuZCBoYXZlIHRoZSBjb250cm9sbGVyIHByb3Zpc2lvbiB0aGUg U0FzIChpbmNsdWRpbmcga2V5cykuDQoNCkkgZXNwZWNpYWxseSBkaWRu4oCZdCBsaWtlIGNhc2Ug IzIuIFNoYXJpbmcgYSBzZWNyZXQga2V5IGFtb25nIHRocmVlIGVudGl0aWVzIGlzIGEgYmFkIGlk ZWEuIEEgc2hhcmVkIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWwgY2FuIGFsc28gYmUgbWlzdXNl ZCwgYnV0IHRoYXTigJlzIGEgaGFyZCBhdHRhY2sgdG8gbW91bnQuIEEgc2hhcmVkIHRyYWZmaWMg a2V5IG1ha2VzIHRoZSBjb250cm9sbGVyIGEgdmVyeSBhdHRyYWN0aXZlIHRhcmdldC4NCg0KTW9y ZSBpbiBnZW5lcmFsLCBTRE4gd2FzIGJvcm4gaW4gdGhlIGRhdGEgY2VudGVyLiBJbiBhIGRhdGEg Y2VudGVyIGFuIGFsbC1rbm93aW5nIGNvbnRyb2xsZXIgbWFrZXMgc2Vuc2UuIFRoaXMgaXMgdHJ1 ZSBmb3Igcm91dGluZyBhcyBpdCBpcyBmb3IgTlNGcyBzdWNoIGFzIGZpcmV3YWxscywgSURQcyBh bmQgSURTcy4gVlBOIGV4dGVuZHMgdGhlIHJlYWNoIG9mIHRoZSBwcml2YXRlIG5ldHdvcmsgdG8g YWxsIGNvcm5lcnMgb2YgdGhlIEludGVybmV0LiBUaGluayBvZiBhIHN0b3JlIGNoYWluIHdpdGgg YSBDUEUgaW4gZXZlcnkgb25lIG9mIHRob3VzYW5kcyBvZiBicmFuY2hlcy4gT3IgYSBiYW5rLiBU aGUgcHJvYmxlbSB0aGVyZSBpcyB0aGF0IHRoZXJlIGlzIG5vIGNlbnRyYWwgYWRtaW5pc3RyYXRp dmUgZnVuY3Rpb24uIExvY2FsIGJyYW5jaGVzIG1heSBzd2l0Y2ggSVNQIGFuZCByZW51bWJlciB0 aGVpciBuZXR3b3JrIHdpdGhvdXQgYm90aGVyaW5nIHRvIHRlbGwgdGhlIElUIHBlb3BsZS4gU28g dGhlIG1vZGVsIHdoZXJlIHRoZSBjb250cm9sbGVyIGtub3dzIGV2ZXJ5dGhpbmcgaXMgdG91Z2gg dG8gZGVwbG95IGluIHByYWN0aWNlLg0KDQpJdCBpcyBwcm9iYWJseSBuZWNlc3NhcnkgdG8gaGF2 ZSB0d28td2F5IGNvbW11bmljYXRpb25zLCB3aGVyZSB0aGUgQ1BFIHRlbGxzIHRoZSBjb250cm9s bGVyIGFib3V0IGl0cyB0b3BvbG9neSAoaG93IGl0IHBhcnRpdGlvbnMgdGhlIEludGVybmV0IHRv IOKAnGlu4oCdIHZzIOKAnG91dOKAnSkgc28gdGhhdCB0aGUgY29udHJvbGxlciBjYW4gc2V0IHVw IHRoZSBhcHByb3ByaWF0ZSBTUERzLg0KDQpUaGVyZSBoYXZlIGJlZW4gc2V2ZXJhbCBhdHRlbXB0 cyBhdCB0aGlzLiBSRkMgNzAxOCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzLCBidXQgdGhlIFdHIHVs dGltYXRlbHkgZmFpbGVkIHRvIHB1Ymxpc2ggYSBzb2x1dGlvbiBkb2N1bWVudC4gIFRoZXJlIGFy ZSBhbHNvIG1vcmUgcmVjZW50IGNvbW1lcmNpYWwgc29sdXRpb25zIHNvbGQgdG9kYXkgdW5kZXIg dGhlIG1hcmtldGluZyBuYW1lIG9mIOKAnFNELVdBTuKAnSwgd2hpY2ggaXMgc29ydCBvZiBsaWtl IFNETiBpZiB5b3Ugc3F1aW50IGhhcmQgZW5vdWdoLiBBbGwgb2YgdGhlc2UgaGF2ZSBzb21lIGlu dGVyYWN0aW9uIGJldHdlZW4gQ1BFIGFuZCBjb250cm9sbGVycyAob3IgaHVicykgd2hpY2ggZHJh ZnQtYWJhZCBkb2VzIG5vdC4NCg0KWW9hdg0KDQo= From nobody Thu Apr 20 14:40:48 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE28129C68; Thu, 20 Apr 2017 14:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 e1ob38RRw62Q; Thu, 20 Apr 2017 14:40:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7EE129459; Thu, 20 Apr 2017 14:40:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFF52560; Thu, 20 Apr 2017 21:40:35 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Apr 2017 22:40:34 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML701-CHM.china.huawei.com ([169.254.3.8]) with mapi id 14.03.0235.001; Thu, 20 Apr 2017 14:40:27 -0700 From: Linda Dunbar To: Yoav Nir CC: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" Thread-Topic: sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio Thread-Index: AdK6G/pAtzEdg5HCTk+UmsKBqK3FvQ== Date: Thu, 20 Apr 2017 21:40:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.188] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58F92AD3.018A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cbe01f43a73bf9dc9c90b5ce0ff06eba Archived-At: Subject: [I2nsf] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:40:41 -0000 WW9hdiwgDQoNCllvdSBzYWlkIHRoYXQgaXQgaXMgYSBiYWQgaWRlYSB0byBoYXZlICJzaGFyaW5n IGtleSBhbW9uZyBtdWx0aXBsZSBwb2ludHMiIGFzIGludHJvZHVjZWQgYnkgZHJhZnQtYWJhZC1p Mm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLiANCg0KSXNuJ3QgdGhlICJHcm91cCBFbmNy eXB0aW9uIEtleSIgb2YgaGF2aW5nIGEgIktleSBTZXJ2ZXIiIGRpc3RyaWJ1dGluZyB0aGUga2V5 IHRvIG11bHRpcGxlIG1lbWJlcnMgZG9pbmcgdGhlIHNhbWU/IGh0dHA6Ly93d3cuY2lzY28uY29t L2MvZGFtL2VuL3VzL3Byb2R1Y3RzL2NvbGxhdGVyYWwvc2VjdXJpdHkvZ3JvdXAtZW5jcnlwdGVk LXRyYW5zcG9ydC12cG4vR0VUVlBOX0RJR192ZXJzaW9uXzFfMF9FeHRlcm5hbC5wZGYNCg0KDQpM aW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWW9hdiBOaXIgW21haWx0 bzp5bmlyLmlldGZAZ21haWwuY29tXSANCg0KDQo+PiAtIEkyTlNGIGhhcyBhIHByb3Bvc2FsIG9u IHVzaW5nIENvbnRyb2xsZXIgdG8gbWFuYWdlciBhbGwgdGhlIElQU2VjDQo+PiB0dW5uZWxzOg0K Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1hYmFkLWkybnNm LXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24uDQo+PiBXaGF0IGtpbmQgb2YgaXNzdWVzIGRvIHlv dSBzZWUgd2l0aCB0aGUgcHJvcG9zZWQgYXBwcm9hY2g/DQo+IA0KPiBJIGRpZG4ndCByZWFkIGl0 Lg0KDQpJIGRpZC4gVGhleSBoYXZlIHR3byBjYXNlcy4gSW4gY2FzZSAjMSB0aGUgY29udHJvbGxl ciBwcm92aXNpb25zIGNyZWRlbnRpYWxzIGZvciBJS0UgYW5kIGVudHJpZXMgaW4gUEFEIGFuZCBT UEQuIEluIGNhc2UgIzIgeW91IGZvcmVnbyBJS0UgYW5kIGhhdmUgdGhlIGNvbnRyb2xsZXIgcHJv dmlzaW9uIHRoZSBTQXMgKGluY2x1ZGluZyBrZXlzKS4NCg0KSSBlc3BlY2lhbGx5IGRpZG7igJl0 IGxpa2UgY2FzZSAjMi4gU2hhcmluZyBhIHNlY3JldCBrZXkgYW1vbmcgdGhyZWUgZW50aXRpZXMg aXMgYSBiYWQgaWRlYS4gQSBzaGFyZWQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbCBjYW4gYWxz byBiZSBtaXN1c2VkLCBidXQgdGhhdOKAmXMgYSBoYXJkIGF0dGFjayB0byBtb3VudC4gQSBzaGFy ZWQgdHJhZmZpYyBrZXkgbWFrZXMgdGhlIGNvbnRyb2xsZXIgYSB2ZXJ5IGF0dHJhY3RpdmUgdGFy Z2V0Lg0KDQpNb3JlIGluIGdlbmVyYWwsIFNETiB3YXMgYm9ybiBpbiB0aGUgZGF0YSBjZW50ZXIu IEluIGEgZGF0YSBjZW50ZXIgYW4gYWxsLWtub3dpbmcgY29udHJvbGxlciBtYWtlcyBzZW5zZS4g VGhpcyBpcyB0cnVlIGZvciByb3V0aW5nIGFzIGl0IGlzIGZvciBOU0ZzIHN1Y2ggYXMgZmlyZXdh bGxzLCBJRFBzIGFuZCBJRFNzLiBWUE4gZXh0ZW5kcyB0aGUgcmVhY2ggb2YgdGhlIHByaXZhdGUg bmV0d29yayB0byBhbGwgY29ybmVycyBvZiB0aGUgSW50ZXJuZXQuIFRoaW5rIG9mIGEgc3RvcmUg Y2hhaW4gd2l0aCBhIENQRSBpbiBldmVyeSBvbmUgb2YgdGhvdXNhbmRzIG9mIGJyYW5jaGVzLiBP ciBhIGJhbmsuIFRoZSBwcm9ibGVtIHRoZXJlIGlzIHRoYXQgdGhlcmUgaXMgbm8gY2VudHJhbCBh ZG1pbmlzdHJhdGl2ZSBmdW5jdGlvbi4gTG9jYWwgYnJhbmNoZXMgbWF5IHN3aXRjaCBJU1AgYW5k IHJlbnVtYmVyIHRoZWlyIG5ldHdvcmsgd2l0aG91dCBib3RoZXJpbmcgdG8gdGVsbCB0aGUgSVQg cGVvcGxlLiBTbyB0aGUgbW9kZWwgd2hlcmUgdGhlIGNvbnRyb2xsZXIga25vd3MgZXZlcnl0aGlu ZyBpcyB0b3VnaCB0byBkZXBsb3kgaW4gcHJhY3RpY2UuDQoNCkl0IGlzIHByb2JhYmx5IG5lY2Vz c2FyeSB0byBoYXZlIHR3by13YXkgY29tbXVuaWNhdGlvbnMsIHdoZXJlIHRoZSBDUEUgdGVsbHMg dGhlIGNvbnRyb2xsZXIgYWJvdXQgaXRzIHRvcG9sb2d5IChob3cgaXQgcGFydGl0aW9ucyB0aGUg SW50ZXJuZXQgdG8g4oCcaW7igJ0gdnMg4oCcb3V04oCdKSBzbyB0aGF0IHRoZSBjb250cm9sbGVy IGNhbiBzZXQgdXAgdGhlIGFwcHJvcHJpYXRlIFNQRHMuDQoNClRoZXJlIGhhdmUgYmVlbiBzZXZl cmFsIGF0dGVtcHRzIGF0IHRoaXMuIFJGQyA3MDE4IGRlc2NyaWJlcyByZXF1aXJlbWVudHMsIGJ1 dCB0aGUgV0cgdWx0aW1hdGVseSBmYWlsZWQgdG8gcHVibGlzaCBhIHNvbHV0aW9uIGRvY3VtZW50 LiAgVGhlcmUgYXJlIGFsc28gbW9yZSByZWNlbnQgY29tbWVyY2lhbCBzb2x1dGlvbnMgc29sZCB0 b2RheSB1bmRlciB0aGUgbWFya2V0aW5nIG5hbWUgb2Yg4oCcU0QtV0FO4oCdLCB3aGljaCBpcyBz b3J0IG9mIGxpa2UgU0ROIGlmIHlvdSBzcXVpbnQgaGFyZCBlbm91Z2guIEFsbCBvZiB0aGVzZSBo YXZlIHNvbWUgaW50ZXJhY3Rpb24gYmV0d2VlbiBDUEUgYW5kIGNvbnRyb2xsZXJzIChvciBodWJz KSB3aGljaCBkcmFmdC1hYmFkIGRvZXMgbm90Lg0KDQpZb2F2DQoNCg== From nobody Thu Apr 20 15:18:50 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38221316ED; Thu, 20 Apr 2017 15:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 F5QV3d1dXP2J; Thu, 20 Apr 2017 15:18:40 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c: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 998AF1316EA; Thu, 20 Apr 2017 15:18:39 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id o81so3464581wmb.1; Thu, 20 Apr 2017 15:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DmYkNeTozN6pnnuk+Jy/3P4aHP2pX/QD9fGAN5wtoy8=; b=dpcVtPH3HdA0Ond4gMcezbMpJ6H+heTM/FTx9eYYHVg8zla2TzxrfdFwDE9Q3k9wxN omxMvFtYr055Wl5zyyiUn9nS0kbsqP5Om/m3W84hYDR3ZdNXMHZKQV+MN9+bkcfMVwPT EA8gsvq0yEqEM3YABE3oZ40oIy9Ao6FD3mfHdfiEDdwLfuOULdKWJPTO1Z5aqAqUzM4d 1NDYAUr52IMb1G9hP2zT9v8dG8UtVYwCaGzrDt+p4nG6ovZgFvnzk9eUfZWmXj3ZuB0z hxKkzGGQClBRqyrEFca0veK6EB1jo/Mn51DC4YTlsX2U3698ofLbiMjWz73FUMVnRWtF 7ttg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DmYkNeTozN6pnnuk+Jy/3P4aHP2pX/QD9fGAN5wtoy8=; b=WH5IDyoUkG613Q/XUc0QvTZo/V8FytjG1mnADamT2Rzv6XEce2sAizLQeMh3n9nhcE eppTpXn6QTF+0hPTA/Uy3+YeSCfzYlU4sKj2BsHPwt8EJyF1iCCbbQP6z5/Tc2InFAkl zLf44Patfti+1pcmt15oFkS4wtYbPhbscylitPusowWWUCiUSL/Q6Bk1wJc7cGwdTKxY 771BPcxEwHuACO+n0ZwRZdVmkbiLz5HZPd8cLNC+tt7ZAtnYfKaIRiTEC9IgUQMUXdCU n/YtrkZIdTENURefHVq0xqn6YZPIsyzhQMPZFwnHw2s1Ja1sgDP5RZmS2wF8n+GOnmnB u9Og== X-Gm-Message-State: AN3rC/7bPzlRnyL7rJzfqPkUczs60xudjfMI6NMSezAYqJ18XHtHj35n yxiabBX1z3nyXU/neKY= X-Received: by 10.28.150.213 with SMTP id y204mr5046372wmd.138.1492726718129; Thu, 20 Apr 2017 15:18:38 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e21sm598806wma.5.2017.04.20.15.18.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 15:18:37 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 01:18:34 +0300 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> Cc: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [I2nsf] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 22:18:42 -0000 --Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926 Content-Type: multipart/alternative; boundary="Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47" --Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Linda > On 21 Apr 2017, at 0:40, Linda Dunbar wrote: >=20 > Yoav, >=20 > You said that it is a bad idea to have "sharing key among multiple = points" as introduced by draft-abad-i2nsf-sdn-ipsec-flow-protection. >=20 > Isn't the "Group Encryption Key" of having a "Key Server" distributing = the key to multiple members doing the same? = http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encryp= ted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf = Just because Cisco do it doesn=E2=80=99t mean that it=E2=80=99s not a = bad idea. :-) GETVPN is based on GDOI (RFC 6407). GDOI is about extending IPsec to = multicast communications, where in a group of nodes a node encrypts a = multicast IPsec packet and sends it to all group members who in turn = decrypt it. For group communications sharing a key is inevitable. GETVPN extends the key server back to regular unicast IPsec. It trades = the security and robustness of pair-wise key exchange for the = operational convenience of using a single traffic key for the entire = configuration.In return for everyone using the same key, they eliminate = the need for each node to be configured with the IP address and = protected domain of every other node. Any SDN or SDN-like solution does not need to eliminate configuration as = that can be done dynamically by the controller. I don=E2=80=99t think = the trade-off that was necessary for GDOI and convenient for GETVPN has = many advantages for VPN with SDN. Yoav --Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Linda

On 21 Apr 2017, at 0:40, Linda = Dunbar <linda.dunbar@huawei.com> wrote:

Yoav, =

You said that it is a bad idea to have = "sharing key among multiple points" as introduced by = draft-abad-i2nsf-sdn-ipsec-flow-protection.

Isn't the "Group Encryption Key" of having a "Key Server" = distributing the key to multiple members doing the same? http://www.cisco.com/c/dam/en/us/products/collateral/security/g= roup-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf

Just = because Cisco do it doesn=E2=80=99t mean that it=E2=80=99s not a bad = idea.  :-)

GETVPN is based on = GDOI (RFC 6407). GDOI is about extending IPsec to multicast = communications, where in a group of nodes a node encrypts a multicast = IPsec packet and sends it to all group members who in turn decrypt it. =  For group communications sharing a key is = inevitable.

GETVPN extends the key = server back to regular unicast IPsec. It trades the security and = robustness of pair-wise key exchange for the operational convenience of = using a single traffic key for the entire configuration.In return for = everyone using the same key, they eliminate the need for each node to be = configured with the IP address and protected domain of every other = node.

Any SDN or SDN-like solution = does not need to eliminate configuration as that can be done dynamically = by the controller. I don=E2=80=99t think the trade-off that was = necessary for GDOI and convenient for GETVPN has many advantages for VPN = with SDN.

Yoav

= --Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47-- --Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY+TO7AAoJELhJCxUKWMyZdMsH/1CQLGEL+m5dnIn2/RbU4G/F t7C2Y9SAQ0Il77KZU+LVM894VpX1yoOkDdZ3IRuGJa9lGsCFQ5x0k8L1kPqbAnFy b9AFR0s4OSbxkzSz4Omln8EkXDEik+cWjGiKn8KJMANqsNJxYY22OVtXHv9Y7HQn TP2QpZ26bVVhyww2nKLQXG0hMPIVBB7bcj6XBcIxBNWVp2sKAxkJHHnXfsOH1RTS ys2tE8FX2HxH+bvk3/5l62FE4R5PJ2XrpRTiAnTAcaAH+iEJUdl8jVws9moc6kQJ i7WSU7OyVPz/lOF2bCyLn1S2Rh9t4cOGGt9vrUYL6tqzEn/PJJJ4sAjLQNwhbHM= =r9u7 -----END PGP SIGNATURE----- --Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926-- From nobody Fri Apr 21 12:49:45 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29471292CE; Fri, 21 Apr 2017 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 K2Liyl4VdkO6; Fri, 21 Apr 2017 12:49:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25ABC12441E; Fri, 21 Apr 2017 12:49:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLM55728; Fri, 21 Apr 2017 19:49:30 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 21 Apr 2017 20:49:28 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Fri, 21 Apr 2017 12:49:24 -0700 From: Linda Dunbar To: Yoav Nir CC: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" Thread-Topic: sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio Thread-Index: AdK6G/pAtzEdg5HCTk+UmsKBqK3FvQAQr60AAB41whA= Date: Fri, 21 Apr 2017 19:49:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65927632E@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.188] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58FA624B.00AE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c8e4ccdfcb5621266ee07a2671e33a7b Archived-At: Subject: Re: [I2nsf] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:49:37 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW9hdiwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9u Lg0KDQpKdXN0IG91dCBvZiBjdXJpb3NpdHksIHdoYXQga2luZCBvZiDigJxzZWN1cml0eSBhbmQg cm9idXN0bmVzcyBvZiBwYWlyLXdpc2Uga2V5IGV4Y2hhbmdl4oCdIGFyZSBsb3N0IGJ5IHVzaW5n IGEgc2luZ2xlIHRyYWZmaWMga2V5IGZvciBtdWx0aXBsZSBlbmQgcG9pbnRzPw0KDQpFdmVuIHdp dGggU0ROIGFwcHJvYWNoLCBhcyBiZWluZyBwcm9wb3NlZCBieSB0aGUgZHJhZnQtYWJhZC1pMm5z Zi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTAxLCBzb21lIGVuZCBwb2ludHMgKGkuZS4gYnJh bmNoIENQRXMpIG1heSBub3QgaGF2ZSBlbm91Z2ggcmVzb3VyY2UgdG8gbWFuYWdlIGxhcmdlIG51 bWJlciBvZiBzZWN1cml0eSBhc3NvY2lhdGlvbnMgd2l0aCBtYW55IG90aGVyIGVuZCBwb2ludHMg KGFzIGluIG1hbnkgU0QtV0FOIGJyYW5jaCB0byBicmFuY2ggZGlyZWN0IHR1bm5lbHMgdXNlIGNh c2UpLg0KDQpMaW5kYQ0KDQpGcm9tOiBZb2F2IE5pciBbbWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5j b21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjAsIDIwMTcgNToxOSBQTQ0KVG86IExpbmRhIER1 bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+DQpDYzogSVBzZWNAaWV0Zi5vcmc7IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgaTJuc2ZAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBzaGFyaW5nIGtleSBhbW9uZyBtdWx0aXBsZSBlbmQgcG9pbnRzIHZzLiBHcm91 cCBFbmNyeXB0aW9uIEtleSAtIGRyYWZ0LWFiYWQtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVj dGlvDQoNCkhpLCBMaW5kYQ0KDQpPbiAyMSBBcHIgMjAxNywgYXQgMDo0MCwgTGluZGEgRHVuYmFy IDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ PiB3cm90ZToNCg0KWW9hdiwNCg0KWW91IHNhaWQgdGhhdCBpdCBpcyBhIGJhZCBpZGVhIHRvIGhh dmUgInNoYXJpbmcga2V5IGFtb25nIG11bHRpcGxlIHBvaW50cyIgYXMgaW50cm9kdWNlZCBieSBk cmFmdC1hYmFkLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24uDQoNCklzbid0IHRoZSAi R3JvdXAgRW5jcnlwdGlvbiBLZXkiIG9mIGhhdmluZyBhICJLZXkgU2VydmVyIiBkaXN0cmlidXRp bmcgdGhlIGtleSB0byBtdWx0aXBsZSBtZW1iZXJzIGRvaW5nIHRoZSBzYW1lPyBodHRwOi8vd3d3 LmNpc2NvLmNvbS9jL2RhbS9lbi91cy9wcm9kdWN0cy9jb2xsYXRlcmFsL3NlY3VyaXR5L2dyb3Vw LWVuY3J5cHRlZC10cmFuc3BvcnQtdnBuL0dFVFZQTl9ESUdfdmVyc2lvbl8xXzBfRXh0ZXJuYWwu cGRmDQoNCkp1c3QgYmVjYXVzZSBDaXNjbyBkbyBpdCBkb2VzbuKAmXQgbWVhbiB0aGF0IGl04oCZ cyBub3QgYSBiYWQgaWRlYS4gIDotKQ0KDQpHRVRWUE4gaXMgYmFzZWQgb24gR0RPSSAoUkZDIDY0 MDcpLiBHRE9JIGlzIGFib3V0IGV4dGVuZGluZyBJUHNlYyB0byBtdWx0aWNhc3QgY29tbXVuaWNh dGlvbnMsIHdoZXJlIGluIGEgZ3JvdXAgb2Ygbm9kZXMgYSBub2RlIGVuY3J5cHRzIGEgbXVsdGlj YXN0IElQc2VjIHBhY2tldCBhbmQgc2VuZHMgaXQgdG8gYWxsIGdyb3VwIG1lbWJlcnMgd2hvIGlu IHR1cm4gZGVjcnlwdCBpdC4gIEZvciBncm91cCBjb21tdW5pY2F0aW9ucyBzaGFyaW5nIGEga2V5 IGlzIGluZXZpdGFibGUuDQoNCkdFVFZQTiBleHRlbmRzIHRoZSBrZXkgc2VydmVyIGJhY2sgdG8g cmVndWxhciB1bmljYXN0IElQc2VjLiBJdCB0cmFkZXMgdGhlIHNlY3VyaXR5IGFuZCByb2J1c3Ru ZXNzIG9mIHBhaXItd2lzZSBrZXkgZXhjaGFuZ2UgZm9yIHRoZSBvcGVyYXRpb25hbCBjb252ZW5p ZW5jZSBvZiB1c2luZyBhIHNpbmdsZSB0cmFmZmljIGtleSBmb3IgdGhlIGVudGlyZSBjb25maWd1 cmF0aW9uLkluIHJldHVybiBmb3IgZXZlcnlvbmUgdXNpbmcgdGhlIHNhbWUga2V5LCB0aGV5IGVs aW1pbmF0ZSB0aGUgbmVlZCBmb3IgZWFjaCBub2RlIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCB0aGUg SVAgYWRkcmVzcyBhbmQgcHJvdGVjdGVkIGRvbWFpbiBvZiBldmVyeSBvdGhlciBub2RlLg0KDQpB bnkgU0ROIG9yIFNETi1saWtlIHNvbHV0aW9uIGRvZXMgbm90IG5lZWQgdG8gZWxpbWluYXRlIGNv bmZpZ3VyYXRpb24gYXMgdGhhdCBjYW4gYmUgZG9uZSBkeW5hbWljYWxseSBieSB0aGUgY29udHJv bGxlci4gSSBkb27igJl0IHRoaW5rIHRoZSB0cmFkZS1vZmYgdGhhdCB3YXMgbmVjZXNzYXJ5IGZv ciBHRE9JIGFuZCBjb252ZW5pZW50IGZvciBHRVRWUE4gaGFzIG1hbnkgYWR2YW50YWdlcyBmb3Ig VlBOIHdpdGggU0ROLg0KDQpZb2F2DQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb2F2LA0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgdmVyeSBtdWNoIGZv ciB0aGUgZGV0YWlsZWQgZXhwbGFuYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkp1c3Qgb3V0IG9mIGN1cmlvc2l0eSwgd2hhdCBraW5kIG9mIOKAnDwv c3Bhbj48Yj48aT5zZWN1cml0eSBhbmQgcm9idXN0bmVzcyBvZiBwYWlyLXdpc2Uga2V5IGV4Y2hh bmdl4oCdPC9pPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hcmUgbG9zdCBi eSB1c2luZyBhIHNpbmdsZSB0cmFmZmljIGtleSBmb3IgbXVsdGlwbGUgZW5kIHBvaW50cz8gJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FdmVuIHdpdGgg U0ROIGFwcHJvYWNoLCBhcyBiZWluZyBwcm9wb3NlZCBieSB0aGUgZHJhZnQtYWJhZC1pMm5zZi1z ZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTAxLCBzb21lIGVuZCBwb2ludHMgKGkuZS4gYnJhbmNo IENQRXMpIG1heSBub3QgaGF2ZSBlbm91Z2ggcmVzb3VyY2UNCiB0byBtYW5hZ2UgbGFyZ2UgbnVt YmVyIG9mIHNlY3VyaXR5IGFzc29jaWF0aW9ucyB3aXRoIG1hbnkgb3RoZXIgZW5kIHBvaW50cyAo YXMgaW4gbWFueSBTRC1XQU4gYnJhbmNoIHRvIGJyYW5jaCBkaXJlY3QgdHVubmVscyB1c2UgY2Fz ZSkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxpbmRhICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gWW9hdiBOaXIgW21haWx0bzp5bmlyLmlldGZAZ21haWwuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAyMCwgMjAxNyA1OjE5IFBNPGJy Pg0KPGI+VG86PC9iPiBMaW5kYSBEdW5iYXIgJmx0O2xpbmRhLmR1bmJhckBodWF3ZWkuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gSVBzZWNAaWV0Zi5vcmc7IE1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7 bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSZndDs7IGkybnNmQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBzaGFyaW5nIGtleSBhbW9uZyBtdWx0aXBsZSBlbmQgcG9pbnRzIHZzLiBH cm91cCBFbmNyeXB0aW9uIEtleSAtIGRyYWZ0LWFiYWQtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJv dGVjdGlvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGks IExpbmRhPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g MjEgQXByIDIwMTcsIGF0IDA6NDAsIExpbmRhIER1bmJhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxp bmRhLmR1bmJhckBodWF3ZWkuY29tIj5saW5kYS5kdW5iYXJAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9hdiwg PGJyPg0KPGJyPg0KWW91IHNhaWQgdGhhdCBpdCBpcyBhIGJhZCBpZGVhIHRvIGhhdmUgJnF1b3Q7 c2hhcmluZyBrZXkgYW1vbmcgbXVsdGlwbGUgcG9pbnRzJnF1b3Q7IGFzIGludHJvZHVjZWQgYnkg ZHJhZnQtYWJhZC1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLg0KPGJyPg0KPGJyPg0K SXNuJ3QgdGhlICZxdW90O0dyb3VwIEVuY3J5cHRpb24gS2V5JnF1b3Q7IG9mIGhhdmluZyBhICZx dW90O0tleSBTZXJ2ZXImcXVvdDsgZGlzdHJpYnV0aW5nIHRoZSBrZXkgdG8gbXVsdGlwbGUgbWVt YmVycyBkb2luZyB0aGUgc2FtZT8NCjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL2MvZGFt L2VuL3VzL3Byb2R1Y3RzL2NvbGxhdGVyYWwvc2VjdXJpdHkvZ3JvdXAtZW5jcnlwdGVkLXRyYW5z cG9ydC12cG4vR0VUVlBOX0RJR192ZXJzaW9uXzFfMF9FeHRlcm5hbC5wZGYiPg0KaHR0cDovL3d3 dy5jaXNjby5jb20vYy9kYW0vZW4vdXMvcHJvZHVjdHMvY29sbGF0ZXJhbC9zZWN1cml0eS9ncm91 cC1lbmNyeXB0ZWQtdHJhbnNwb3J0LXZwbi9HRVRWUE5fRElHX3ZlcnNpb25fMV8wX0V4dGVybmFs LnBkZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBiZWNhdXNlIENpc2NvIGRvIGl0IGRv ZXNu4oCZdCBtZWFuIHRoYXQgaXTigJlzIG5vdCBhIGJhZCBpZGVhLiAmbmJzcDs6LSk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0VUVlBOIGlz IGJhc2VkIG9uIEdET0kgKFJGQyA2NDA3KS4gR0RPSSBpcyBhYm91dCBleHRlbmRpbmcgSVBzZWMg dG8gbXVsdGljYXN0IGNvbW11bmljYXRpb25zLCB3aGVyZSBpbiBhIGdyb3VwIG9mIG5vZGVzIGEg bm9kZSBlbmNyeXB0cyBhIG11bHRpY2FzdCBJUHNlYyBwYWNrZXQgYW5kIHNlbmRzIGl0IHRvIGFs bCBncm91cCBtZW1iZXJzIHdobyBpbiB0dXJuIGRlY3J5cHQgaXQuICZuYnNwO0ZvciBncm91cCBj b21tdW5pY2F0aW9ucw0KIHNoYXJpbmcgYSBrZXkgaXMgaW5ldml0YWJsZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0VUVlBOIGV4dGVuZHMg dGhlIGtleSBzZXJ2ZXIgYmFjayB0byByZWd1bGFyIHVuaWNhc3QgSVBzZWMuIEl0IHRyYWRlcyB0 aGUgc2VjdXJpdHkgYW5kIHJvYnVzdG5lc3Mgb2YgcGFpci13aXNlIGtleSBleGNoYW5nZSBmb3Ig dGhlIG9wZXJhdGlvbmFsIGNvbnZlbmllbmNlIG9mIHVzaW5nIGEgc2luZ2xlIHRyYWZmaWMga2V5 IGZvciB0aGUgZW50aXJlIGNvbmZpZ3VyYXRpb24uSW4gcmV0dXJuIGZvciBldmVyeW9uZQ0KIHVz aW5nIHRoZSBzYW1lIGtleSwgdGhleSBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGVhY2ggbm9kZSB0 byBiZSBjb25maWd1cmVkIHdpdGggdGhlIElQIGFkZHJlc3MgYW5kIHByb3RlY3RlZCBkb21haW4g b2YgZXZlcnkgb3RoZXIgbm9kZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QW55IFNETiBvciBTRE4tbGlrZSBzb2x1dGlvbiBkb2VzIG5vdCBu ZWVkIHRvIGVsaW1pbmF0ZSBjb25maWd1cmF0aW9uIGFzIHRoYXQgY2FuIGJlIGRvbmUgZHluYW1p Y2FsbHkgYnkgdGhlIGNvbnRyb2xsZXIuIEkgZG9u4oCZdCB0aGluayB0aGUgdHJhZGUtb2ZmIHRo YXQgd2FzIG5lY2Vzc2FyeSBmb3IgR0RPSSBhbmQgY29udmVuaWVudCBmb3IgR0VUVlBOIGhhcyBt YW55IGFkdmFudGFnZXMgZm9yIFZQTiB3aXRoDQogU0ROLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb2F2PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_-- From nobody Sun Apr 23 19:04:38 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751A127071; Sun, 23 Apr 2017 19:04:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: Cc: i2nsf@ietf.org, ietf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149299947052.25893.14183369388246516074@ietfa.amsl.com> Date: Sun, 23 Apr 2017 19:04:30 -0700 Archived-At: Subject: [I2nsf] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 02:04:31 -0000 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale R. Worley Review Date: 2017-04-23 IETF LC End Date: 2017-03-22 IESG Telechat date: 2017-04-27 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. All of these nits are editorial. 3.1.1. Diverse Types of Security Functions Security gateways and VPN concentrators: Examples of these functions are; IPsec gateways, Secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows. Unless "Secure VPN" is a name in itself, "secure" shouldn't be capitalized. (Between -11 and -12, one instance of this was fixed, but the other one remains.) 3.1.2. Diverse Interfaces to Control and Monitor NSFs A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function to mitigate an intrusion (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected if there is no monitoring feedback. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. This paragraph still seems to have problems. What the second sentence seems to mean (though it doesn't say it) is that if you enable a security function, you don't *know* that the network is protected if you don't have any monitoring feedback. (The sentence is stated in terms of whether the network *is* protected, which it might well be, even if you don't have monitoring.) It seems that you need to replace "does not mean that a network is protected" with something that is more literally correct. The third sentence is constructed "... to have a mechanism to monitor and provide execution status of NSFs to ...". There's an awkwardness that "monitor" isn't connected to "security and compliance management tools", whereas "provide ... status ... to" *is* connected; there's a problem that the "monitor" and "provide" are written as if they're parallel, but they're not. I think the wording is less confusing this way: As such, it is necessary to have a mechanism to monitor NSFs and provide their execution status to security and compliance management tools. -- There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. I think it's easier to read "vendor-specific network security monitoring interfaces". 3.1.4. More Demand to Control NSFs Dynamically The Security Service Providers ... The capitalization of "security service providers" is inconsistent. Some times all three words are capitalized (in 3.1.2, 3.1.4, and 4), and some times they're not (two places in 3). 3.2.2. Today's Control Requests are Vendor Specific Managing by scripts de-jour: The current practices rely upon the use of scripts that generate other scripts which automatically run to upload or download configuration changes, log information and other things. These scripts have to be adjusted each time an implementation from a different vendor technology is enabled by a provider side. What is "a provider side"? I suspect it means "the provider side of an XXX", but I'm not familiar enough with the subject to know what XXX is. [END] From nobody Sun Apr 23 21:38:17 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A67126B6D; Sun, 23 Apr 2017 21:38:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149300869547.25862.13390393389506057763.idtracker@ietfa.amsl.com> Date: Sun, 23 Apr 2017 21:38:15 -0700 Archived-At: Subject: [I2nsf] Terry Manderson's Abstain on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 04:38:15 -0000 Terry Manderson has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I appreciate the work that has gone into the document for the exercise of defining the problem and use-cases, however I question the value of publishing this document as an RFC, but I will not block its path should other ADs consider it of use. I am taking an abstain position. From nobody Mon Apr 24 19:05:14 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C111204DA; Mon, 24 Apr 2017 19:05:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149308590735.13684.18127771505881667407.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 19:05:07 -0700 Archived-At: Subject: [I2nsf] Ben Campbell's No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:05:07 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the various abstains about this draft not appearing to have archival value. I chose not to ballot "abstain" because I think it's best to handle that issue at charter or adoption time rather than doing so this close to the finish line. (I note that the WG charter explicitly says that the WG may choose not to publish, so this is a borderline case.) If there really are good reasons to expect archival value, it would be helpful to include a paragraph early in the document describing those reasons. I have a few additional comments on the odd chance this draft progresses: -2: -- B2B describes a business model. I don't see how that is useful for IETF discussion unless it implies specific technical characteristics. If it does, them please describe them. Bespoke": In other usages, "bespoke" often implies positive thing, which I don't think the draft intends. I think the work "customized" would better fit the usage herein. -3: "The "Customer-Provider" relationship may be between any two parties. The parties can be in different firms or different domains of the same firm." There again seem to be implied business models here. Is it technically relevant if organizations qualify as "firms"? - 3.1.1: -- Consider adding DMZ to the glossary -- "Centralized or Distributed security functions" seems out of place. The rest of the section describes kinds of security functions; this describes the design of security functions. - 3.2.1, first sentence: The second instance of "deploy" seems like a strange usage. Should this be "use"? -3.5, title: s/Difficulty/Difficult -3.6: "SDN-inferred agility" Should that be SDN "implied" or "conferred" agility? - 4.2: -- "typically by means of Business- to-Business (B2B) communications." Again, does B2B imply some technical characteristics of the communication? Otherwise, how is this different than just "communication"? -- Figure 3: Please define or cite a definition for Evolved Packet Core. -7: Are there no privacy related requirements? From nobody Mon Apr 24 19:06:33 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 039231204DA; Mon, 24 Apr 2017 19:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149308599201.28934.2545459090807327923.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 19:06:32 -0700 Archived-At: Subject: [I2nsf] Ben Campbell's No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:06:32 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the various abstains about this draft not appearing to have archival value. I chose not to ballot "abstain" because I think it's best to handle that issue at charter or adoption time rather than doing so this close to the finish line. (I note that the WG charter explicitly says that the WG may choose not to publish, so this is a borderline case.) If there really are good reasons to expect archival value, it would be helpful to include a paragraph early in the document describing those reasons. I also agree that this should be informational. I have a few additional comments on the odd chance this draft progresses: -2: -- B2B describes a business model. I don't see how that is useful for IETF discussion unless it implies specific technical characteristics. If it does, them please describe them. Bespoke": In other usages, "bespoke" often implies positive thing, which I don't think the draft intends. I think the work "customized" would better fit the usage herein. -3: "The "Customer-Provider" relationship may be between any two parties. The parties can be in different firms or different domains of the same firm." There again seem to be implied business models here. Is it technically relevant if organizations qualify as "firms"? - 3.1.1: -- Consider adding DMZ to the glossary -- "Centralized or Distributed security functions" seems out of place. The rest of the section describes kinds of security functions; this describes the design of security functions. - 3.2.1, first sentence: The second instance of "deploy" seems like a strange usage. Should this be "use"? -3.5, title: s/Difficulty/Difficult -3.6: "SDN-inferred agility" Should that be SDN "implied" or "conferred" agility? - 4.2: -- "typically by means of Business- to-Business (B2B) communications." Again, does B2B imply some technical characteristics of the communication? Otherwise, how is this different than just "communication"? -- Figure 3: Please define or cite a definition for Evolved Packet Core. -7: Are there no privacy related requirements? From nobody Tue Apr 25 07:17:02 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC95131452; Tue, 25 Apr 2017 07:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 Kril4VnfMUYW; Tue, 25 Apr 2017 07:16:52 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 CAFD313144B; Tue, 25 Apr 2017 07:16:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.18.96; From: "Susan Hares" To: "'Dale Worley'" , Cc: , , References: <149299947052.25893.14183369388246516074@ietfa.amsl.com> In-Reply-To: <149299947052.25893.14183369388246516074@ietfa.amsl.com> Date: Tue, 25 Apr 2017 10:11:31 -0400 Message-ID: <006201d2bdcd$d8d21e40$8a765ac0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJj1w0Rmgy1J+ijI/wBRaCzRiot8qCz7RLA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:16:54 -0000 Dale: Thank you for the second review. I'll address these issues along with others later today. Sue Hares -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Dale Worley Sent: Sunday, April 23, 2017 10:05 PM To: gen-art@ietf.org Cc: i2nsf@ietf.org; ietf@ietf.org; draft-ietf-i2nsf-problem-and-use-cases.all@ietf.org Subject: [I2nsf] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale R. Worley Review Date: 2017-04-23 IETF LC End Date: 2017-03-22 IESG Telechat date: 2017-04-27 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. All of these nits are editorial. 3.1.1. Diverse Types of Security Functions Security gateways and VPN concentrators: Examples of these functions are; IPsec gateways, Secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows. Unless "Secure VPN" is a name in itself, "secure" shouldn't be capitalized. (Between -11 and -12, one instance of this was fixed, but the other one remains.) 3.1.2. Diverse Interfaces to Control and Monitor NSFs A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function to mitigate an intrusion (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected if there is no monitoring feedback. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. This paragraph still seems to have problems. What the second sentence seems to mean (though it doesn't say it) is that if you enable a security function, you don't *know* that the network is protected if you don't have any monitoring feedback. (The sentence is stated in terms of whether the network *is* protected, which it might well be, even if you don't have monitoring.) It seems that you need to replace "does not mean that a network is protected" with something that is more literally correct. The third sentence is constructed "... to have a mechanism to monitor and provide execution status of NSFs to ...". There's an awkwardness that "monitor" isn't connected to "security and compliance management tools", whereas "provide ... status ... to" *is* connected; there's a problem that the "monitor" and "provide" are written as if they're parallel, but they're not. I think the wording is less confusing this way: As such, it is necessary to have a mechanism to monitor NSFs and provide their execution status to security and compliance management tools. -- There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. I think it's easier to read "vendor-specific network security monitoring interfaces". 3.1.4. More Demand to Control NSFs Dynamically The Security Service Providers ... The capitalization of "security service providers" is inconsistent. Some times all three words are capitalized (in 3.1.2, 3.1.4, and 4), and some times they're not (two places in 3). 3.2.2. Today's Control Requests are Vendor Specific Managing by scripts de-jour: The current practices rely upon the use of scripts that generate other scripts which automatically run to upload or download configuration changes, log information and other things. These scripts have to be adjusted each time an implementation from a different vendor technology is enabled by a provider side. What is "a provider side"? I suspect it means "the provider side of an XXX", but I'm not familiar enough with the subject to know what XXX is. [END] _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Wed Apr 26 02:27:09 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952051294D4; Wed, 26 Apr 2017 02:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 q-ku65RBGXHc; Wed, 26 Apr 2017 02:27:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB611293FC; Wed, 26 Apr 2017 02:26:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFN63885; Wed, 26 Apr 2017 09:26:57 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Apr 2017 10:26:56 +0100 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by nkgeml414-hub.china.huawei.com (10.98.56.75) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Apr 2017 17:26:52 +0800 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.150]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 26 Apr 2017 17:26:43 +0800 From: Sandeep Kampati To: Linda Dunbar , Yoav Nir CC: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" Thread-Topic: small correction : draft-abad-i2nsf-sdn-ipsec-flow-protectio Thread-Index: AdK+blunDApn44IOSkOt8f5iV5jx0Q== Date: Wed, 26 Apr 2017 09:26:42 +0000 Message-ID: <2DA788A5A7D91747AEA54B502558D73826A6C421@DGGEMM506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.590067E1.018F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.150, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ecaf94c04e6d69e3f8fb0912d258ab5a Archived-At: Subject: [I2nsf] small correction : draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 09:27:01 -0000 SGkgQWxsLA0KDQpzbWFsbCBjb3JyZWN0aW9uICAgIA0KDQo4LiAgRGF0YSBtb2RlbA0KDQoJRGF0 YSBtb2RlbCBmb3IgdGhlIFNEUCBlbnRyaWVzOiAtLT4gaXQgc2hvdWxkIGJlICAgICJEYXRhIG1v ZGVsIGZvciB0aGUgU1BEIGVudHJpZXM6ICINCg0KUmVnYXJkcywNClNhbmRlZXAuaw0KDQoNCg0K From nobody Wed Apr 26 13:01:42 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4425F126DED; Wed, 26 Apr 2017 13:01:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149323690127.3044.15708275060600942742.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 13:01:41 -0700 Archived-At: Subject: [I2nsf] Alia Atlas' No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:01:41 -0000 Alia Atlas has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given that the WG charter gave i2nsf the decision about whether to publish as an RFC and that this is Informational, I am fine with this document being published as an RFC. I think that it will serve as useful background to folks considering the i2nsf work and understanding the motivations for standardizing interfaces that have previously been vendor-specific. From nobody Wed Apr 26 15:01:59 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8691252BA; Wed, 26 Apr 2017 15:01:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-i2nsf-problem-and-use-cases@ietf.org, Adrian Farrel , i2nsf-chairs@ietf.org, adrian@olddog.co.uk, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149324411111.2995.4194660598814951426.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 15:01:51 -0700 Archived-At: Subject: [I2nsf] Adam Roach's No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:01:51 -0000 Adam Roach has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Mirja's DISCUSS, which appears to have been mostly addressed. The IESG writeup appears to need updating to match the new document's intended status. I am voting No Objection rather than Abstaining for the reasons Ben outlines in his No Objection. From nobody Wed Apr 26 18:12:22 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D181112940F; Wed, 26 Apr 2017 18:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 l-f0xC2aas51; Wed, 26 Apr 2017 18:12:19 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 2E6E61243F3; Wed, 26 Apr 2017 18:12:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.23.139; From: "Susan Hares" To: "'Kathleen Moriarty'" , "'Spencer Dawkins at IETF'" Cc: , "'Alissa Cooper'" , "'Mirja Kuehlewind \(IETF\)'" , "'IESG'" , , , References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> In-Reply-To: Date: Wed, 26 Apr 2017 21:06:53 -0400 Message-ID: <007601d2bef2$8fe33180$afa99480$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPxQa9DuYm0jMhf5hfvNuXa/BqqQF4tSBOAUVugSAA3P+7DwKwZB0FAgXS7MECBALO9AId6FETAcVyIJ4CKIGb6AIhmKIvAmUeLoYCxaYC6KEg7a7Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_C?= =?iso-8859-1?q?OMMENT=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 01:12:21 -0000 Kathleen:=20 I apologize - but you will need to delay this drafts another 2 weeks. = My editing capabilities only turned on today. I am working to respond to = all the emails today, but I need time to respond to Deborah's comments. =20 I am still moving very slow after this illness.=20 Sue Hares=20 -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Kathleen = Moriarty Sent: Wednesday, April 19, 2017 3:53 PM To: Spencer Dawkins at IETF Cc: i2nsf@ietf.org; Alissa Cooper; Mirja Kuehlewind (IETF); IESG; i2nsf-chairs@ietf.org; adrian@olddog.co.uk; draft-ietf-i2nsf-problem-and-use-cases@ietf.org Subject: Re: [I2nsf] Mirja K=FChlewind's Discuss on draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT) On Wed, Apr 19, 2017 at 3:37 PM, Spencer Dawkins at IETF wrote: > Hi, Kathleen, > > On Wed, Apr 19, 2017 at 2:15 PM, Kathleen Moriarty=20 > wrote: >> >> On Wed, Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF=20 >> wrote: >> > Hi, Kathleen, >> > >> > On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty=20 >> > wrote: >> >> >> >> Yes, I agree that we should discuss these types of documents and=20 >> >> our published guidance on them to assist working groups at the retreat. >> > >> > >> > I agree. Am I adding this to >> > https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you? >> >> Go for it! Do you want to work together on this? I think it's=20 >> important to capture Adrian's input for this discussion. > > > I added this as > > Do we still agree with > https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html > ? Does it say what it needs to say? (Kathleen) > > I'm happy to help prepare for this, and will let you lead the=20 > discussion :-) Thank you, Spencer! > > Spencer > --=20 Best regards, Kathleen _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Wed Apr 26 18:33:30 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2431294A6; Wed, 26 Apr 2017 18:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 0BbDPYmEiuuK; Wed, 26 Apr 2017 18:33:27 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 7C701124281; Wed, 26 Apr 2017 18:33:27 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id c198so10555407pfc.1; Wed, 26 Apr 2017 18:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=E2Yrr85CLR3FvxDa1G/lhpk91pHn5GOLXdyKmGpA6V4=; b=ihBCvJObU26Hi2w/570iRIo34rR4T0wg5iv6R+X7wFTzduTepQnvlapEYUr6jTpuYK Ql7jMwjkuF9SAYeIFViuPS+VGg/3VUwn5g6iaiBv/3T1d0BXYbboKETGmmfBi3KiJXWg 4+MRlY0KcSlAV4LHUwXS85G1JlJndJEcdhQu59XbtaSc/MCDyz+x2D/VsPE4mDmQemMD xNLU2ZcxcCl1H0WIzR8dRODH/r08cDS40Qu/jv7CKtEZbxMrcNA7VWXRVFeBEO/00Pl2 XI7SE552s6vplU5CSwi6Db0jaSnXRDABCdg2tgTir0CQyb4S7nfNwlwBfeQzGfBBa0L4 5VXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=E2Yrr85CLR3FvxDa1G/lhpk91pHn5GOLXdyKmGpA6V4=; b=hiMiihHDRz8ma55PabQhRM817M6VJWFYHtggi+H6ViPYXtK5D2iynwgunkQMdxWsDy SGEDECptUdRdFMQn5EPc+2kSzxNY/pDeOExjv8LL/OtCair7q8jN/HYMXMIuFlRZIH9M cGr3guQwO4GCaGcfWkKUMoOzThw4S0Hux+82yCou2+2Ge+RfLrLv0KS7HRhtAX1Fw3eb eoWeOqiN91tTcyCX5s4kfCPo5xnMZEbFrIj0DkbNEkw80nwwYzBpTwhPMNOsDAyXGBr+ 4zuij0Ps8CsQqrJazo1CDDwCGOQFEbmsp7y0hqgHr2N7Z/vCvZK82A3DLc+X1PxbXClR sOag== X-Gm-Message-State: AN3rC/4HDR5bTtHGuiby75wlyik4NwwmUtRfzophPRFcHLQc1uNOZQZh zxSCVUlbYZKFG5oN2vn1Ivs5/MC3gQ== X-Received: by 10.84.194.165 with SMTP id h34mr3644825pld.129.1493256807143; Wed, 26 Apr 2017 18:33:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 18:32:46 -0700 (PDT) In-Reply-To: <007601d2bef2$8fe33180$afa99480$@ndzh.com> References: <149193516676.15734.6125116013211340679.idtracker@ietfa.amsl.com> <01ee01d2b2f2$3c2e4220$b48ac660$@olddog.co.uk> <9734055A-B854-4054-B67B-ACAE5B8DF049@cooperw.in> <02d701d2b384$ca7e3750$5f7aa5f0$@olddog.co.uk> <06DA4D8C-A338-4E46-BE92-38C62A272C5D@kuehlewind.net> <071301d2b5d5$f1d279d0$d5776d70$@olddog.co.uk> <6F6B47F0-DD1F-4765-8144-DBC426BD708A@kuehlewind.net> <007601d2bef2$8fe33180$afa99480$@ndzh.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 21:32:46 -0400 Message-ID: To: Susan Hares Cc: Spencer Dawkins at IETF , "i2nsf@ietf.org" , Alissa Cooper , "Mirja Kuehlewind (IETF)" , IESG , i2nsf-chairs@ietf.org, "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [I2nsf] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-i2nsf-problem-and-use-cases-12=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 01:33:29 -0000 Thank you, Sue for letting me know. I hope you feel better soon! Kathleen On Wed, Apr 26, 2017 at 9:06 PM, Susan Hares wrote: > Kathleen: > > I apologize - but you will need to delay this drafts another 2 weeks. My > editing capabilities only turned on today. I am working to respond to all > the emails today, but I need time to respond to Deborah's comments. > > I am still moving very slow after this illness. > > Sue Hares > > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Kathleen Moriart= y > Sent: Wednesday, April 19, 2017 3:53 PM > To: Spencer Dawkins at IETF > Cc: i2nsf@ietf.org; Alissa Cooper; Mirja Kuehlewind (IETF); IESG; > i2nsf-chairs@ietf.org; adrian@olddog.co.uk; > draft-ietf-i2nsf-problem-and-use-cases@ietf.org > Subject: Re: [I2nsf] Mirja K=C3=BChlewind's Discuss on > draft-ietf-i2nsf-problem-and-use-cases-12: (with DISCUSS and COMMENT) > > On Wed, Apr 19, 2017 at 3:37 PM, Spencer Dawkins at IETF > wrote: >> Hi, Kathleen, >> >> On Wed, Apr 19, 2017 at 2:15 PM, Kathleen Moriarty >> wrote: >>> >>> On Wed, Apr 19, 2017 at 3:13 PM, Spencer Dawkins at IETF >>> wrote: >>> > Hi, Kathleen, >>> > >>> > On Tue, Apr 18, 2017 at 9:36 PM, Kathleen Moriarty >>> > wrote: >>> >> >>> >> Yes, I agree that we should discuss these types of documents and >>> >> our published guidance on them to assist working groups at the > retreat. >>> > >>> > >>> > I agree. Am I adding this to >>> > https://trac.ietf.org/trac/iesg/wiki/RetreatInfo, or should you? >>> >>> Go for it! Do you want to work together on this? I think it's >>> important to capture Adrian's input for this discussion. >> >> >> I added this as >> >> Do we still agree with >> https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html >> ? Does it say what it needs to say? (Kathleen) >> >> I'm happy to help prepare for this, and will let you lead the >> discussion :-) > > Thank you, Spencer! > >> >> Spencer >> > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > --=20 Best regards, Kathleen From nobody Wed Apr 26 18:35:49 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A0D12441E; Wed, 26 Apr 2017 18:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 16B2n4WlrIPx; Wed, 26 Apr 2017 18:35:46 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 CDB34124281; Wed, 26 Apr 2017 18:35:46 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id a188so10610617pfa.0; Wed, 26 Apr 2017 18:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dpnOpszWh9qApWFo5Z4+nlpcD5OMIlHo9N5TQrZz47k=; b=dWWh95iokmJ+ditCmZHO8/M/F9iRqpHLa/uxBTJtK60tuMxXk61NUwHlbTobhfKmd2 WiBVpVZB9HeiyAXlnRfwA/UwaUVvZ3oQxkieh3fBMgprC0BEB33JqijNZRxxg5z0aujG +LpjKNveVgAVFFjUqVGt9r+qYjWmj+MoX3SuFY34MD9Q+wLMjlBcVxPJzGkWFGIO6cIe 18TYJdDIVgUunz8JsYpt8jk18INc3IUpASifnBtpXv6C8BQviL4AUIpJuksM5jw2Um04 Xo1iwVbosUnSCDs09WIE/JHd0NvBgvIjSGtePCzou6bWKV0qnliAI+JgFfq427q2OkjR owoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dpnOpszWh9qApWFo5Z4+nlpcD5OMIlHo9N5TQrZz47k=; b=sv+RwKB+3xIfrNcF8hwNn0wmOoJ9g7+PQYWCtNw7tmhh75TojjCsGlmZ/4zWH5iAVK wWdyAg9FaTvLTVKlmHNXaIjOW3qu9nTgLFy6BiT7HTwuzlXzaAAMEcwxKj5Wv/G9X3tZ Rw5upHWUcaf/FLXiYw7crfoFYc+N9owQmj7RYXqiqGKh1f4M7oelzUyBnSjxkZHNLjyc pmOEMhOILHsuh2HialIzXgNR8s2Usl00cLfTkVfJW2D0vzi8X1drEoTwb8HSETi1vFNA TWaFb48rxpJ2vyQj+lJIhrlTyeN402RTOhpWtoURcjo6GNPrLuxC59a1hzEulVye7RqU yL2A== X-Gm-Message-State: AN3rC/6Sp9+y6XlCzS4v6eEphxDgkD1aqM3VtjwwIQ+qUWsowO3SJfgk TVedyCc8xgk6DqcW5Zjenw2GxcHtxw== X-Received: by 10.99.62.68 with SMTP id l65mr2882302pga.172.1493256946464; Wed, 26 Apr 2017 18:35:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 18:35:06 -0700 (PDT) In-Reply-To: <149324411111.2995.4194660598814951426.idtracker@ietfa.amsl.com> References: <149324411111.2995.4194660598814951426.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 21:35:06 -0400 Message-ID: To: Adam Roach Cc: The IESG , "i2nsf@ietf.org" , "adrian@olddog.co.uk" , draft-ietf-i2nsf-problem-and-use-cases@ietf.org, i2nsf-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [I2nsf] Adam Roach's No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 01:35:48 -0000 On Wed, Apr 26, 2017 at 6:01 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Mirja's DISCUSS, which appears to have been mostly > addressed. The IESG writeup appears to need updating to match the new > document's intended status. As an FYI , if the ballot is updated, then everyone needs to recast their ballots, so I updated the datatracker status for the document and the shepherd can update their report. I can add some text to my YES ballot to explain the change. > > I am voting No Objection rather than Abstaining for the reasons Ben > outlines in his No Objection. > Thanks. > -- Best regards, Kathleen From nobody Thu Apr 27 05:25:44 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 916EB129453; Thu, 27 Apr 2017 05:25:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149329593654.3040.11139998618339557017@ietfa.amsl.com> Date: Thu, 27 Apr 2017 05:25:36 -0700 Archived-At: Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-problem-and-use-cases-13.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:25:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to Network Security Functions of the IETF. Title : I2NSF Problem Statement and Use cases Authors : Susan Hares Diego R. Lopez Myo Zarny Christian Jacquenet Rakesh Kumar Jaehoon Paul Jeong Filename : draft-ietf-i2nsf-problem-and-use-cases-13.txt Pages : 28 Date : 2017-04-27 Abstract: This document is the problem statement for Interface to Network Security Functions (I2NSF) as well as some companion use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-13 https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-problem-and-use-cases-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-problem-and-use-cases-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 27 05:50:36 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F91312949F; Thu, 27 Apr 2017 05:50:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149329742640.2991.844447672164202794@ietfa.amsl.com> Date: Thu, 27 Apr 2017 05:50:26 -0700 Archived-At: Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-problem-and-use-cases-14.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:50:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to Network Security Functions of the IETF. Title : I2NSF Problem Statement and Use cases Authors : Susan Hares Diego R. Lopez Myo Zarny Christian Jacquenet Rakesh Kumar Jaehoon Paul Jeong Filename : draft-ietf-i2nsf-problem-and-use-cases-14.txt Pages : 28 Date : 2017-04-27 Abstract: This document is the problem statement for Interface to Network Security Functions (I2NSF) as well as some companion use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-14 https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-problem-and-use-cases-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-problem-and-use-cases-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 27 05:52:03 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BF01294A1; Thu, 27 Apr 2017 05:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 WAS7zLiJza0e; Thu, 27 Apr 2017 05:52:01 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 EED371294C5; Thu, 27 Apr 2017 05:52:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.23.139; From: "Susan Hares" To: "'Dale Worley'" , Cc: , , References: <149299947052.25893.14183369388246516074@ietfa.amsl.com> In-Reply-To: <149299947052.25893.14183369388246516074@ietfa.amsl.com> Date: Thu, 27 Apr 2017 08:46:06 -0400 Message-ID: <012d01d2bf54$3d9bbb60$b8d33220$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJj1w0Rmgy1J+ijI/wBRaCzRiot8qC29IzQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:52:03 -0000 Dale: Thank you for taking the time do a second careful review. I can only wish I such an excellent review of documents I am an editor on. Version 14 addresses all of your comments. Sue -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Dale Worley Sent: Sunday, April 23, 2017 10:05 PM To: gen-art@ietf.org Cc: i2nsf@ietf.org; ietf@ietf.org; draft-ietf-i2nsf-problem-and-use-cases.all@ietf.org Subject: [I2nsf] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale R. Worley Review Date: 2017-04-23 IETF LC End Date: 2017-03-22 IESG Telechat date: 2017-04-27 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. All of these nits are editorial. 3.1.1. Diverse Types of Security Functions Security gateways and VPN concentrators: Examples of these functions are; IPsec gateways, Secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows. Unless "Secure VPN" is a name in itself, "secure" shouldn't be capitalized. (Between -11 and -12, one instance of this was fixed, but the other one remains.) Changed in version 14. 3.1.2. Diverse Interfaces to Control and Monitor NSFs A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function to mitigate an intrusion (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected if there is no monitoring feedback. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. This paragraph still seems to have problems. What the second sentence seems to mean (though it doesn't say it) is that if you enable a security function, you don't *know* that the network is protected if you don't have any monitoring feedback. (The sentence is stated in terms of whether the network *is* protected, which it might well be, even if you don't have monitoring.) It seems that you need to replace "does not mean that a network is protected" with something that is more literally correct. The third sentence is constructed "... to have a mechanism to monitor and provide execution status of NSFs to ...". There's an awkwardness that "monitor" isn't connected to "security and compliance management tools", whereas "provide ... status ... to" *is* connected; there's a problem that the "monitor" and "provide" are written as if they're parallel, but they're not. I think the wording is less confusing this way: As such, it is necessary to have a mechanism to monitor NSFs and provide their execution status to security and compliance management tools. -- There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. I think it's easier to read "vendor-specific network security monitoring interfaces". Sue: Dale I rewrote the whole paragraph in version 14. New/ A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. For example, enabling a security function to mitigate an intrusion (e.g., firewall ) must include a mechanism to provide monitoring feedback in order to determine the intrusion has been stopped. Therefore, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist such mechanisms in vendor-specific network security interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs./ 3.1.4. More Demand to Control NSFs Dynamically The Security Service Providers ... The capitalization of "security service providers" is inconsistent. Some times all three words are capitalized (in 3.1.2, 3.1.4, and 4), and some times they're not (two places in 3). Sue: Thank you for catching this. I moved all of these words to small case except in titles. 3.2.2. Today's Control Requests are Vendor Specific Managing by scripts de-jour: The current practices rely upon the use of scripts that generate other scripts which automatically run to upload or download configuration changes, log information and other things. These scripts have to be adjusted each time an implementation from a different vendor technology is enabled by a provider side. What is "a provider side"? I suspect it means "the provider side of an XXX", but I'm not familiar enough with the subject to know what XXX is. Sue: Old/provider side/New/Provide/ [END] _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Thu Apr 27 05:57:39 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C32212949D; Thu, 27 Apr 2017 05:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 WejIAtvbgmId; Thu, 27 Apr 2017 05:57:30 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 BBB9B129412; Thu, 27 Apr 2017 05:57:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.23.139; From: "Susan Hares" To: "'Ben Campbell'" , "'The IESG'" Cc: , , , References: <149308590735.13684.18127771505881667407.idtracker@ietfa.amsl.com> In-Reply-To: <149308590735.13684.18127771505881667407.idtracker@ietfa.amsl.com> Date: Thu, 27 Apr 2017 08:20:25 -0400 Message-ID: <011c01d2bf50$a709c550$f51d4ff0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ9ca4x9o/KiHt4VEj+lyxPM9Bs46CC2qJQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] Ben Campbell's No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:57:31 -0000 Ben: I am dealing with the editorial comments you indicated. I am not dealing with the wider scope issues of information for support documents. Version 13 is submitted to fix these issues, and to change the draft's status to informational. Sue -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Monday, April 24, 2017 10:05 PM To: The IESG Cc: i2nsf@ietf.org; adrian@olddog.co.uk; draft-ietf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org Subject: [I2nsf] Ben Campbell's No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) Ben Campbell has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the various abstains about this draft not appearing to have archival value. I chose not to ballot "abstain" because I think it's best to handle that issue at charter or adoption time rather than doing so this close to the finish line. (I note that the WG charter explicitly says that the WG may choose not to publish, so this is a borderline case.) If there really are good reasons to expect archival value, it would be helpful to include a paragraph early in the document describing those reasons. I have a few additional comments on the odd chance this draft progresses: -2: -- B2B describes a business model. I don't see how that is useful for IETF discussion unless it implies specific technical characteristics. If it does, them please describe them. Bespoke": In other usages, "bespoke" often implies positive thing, which I don't think the draft intends. I think the work "customized" would better fit the usage herein. 2-a) Removed B2B in sentence: New/For example, an enterprise may mandate that firewalls serving Internet traffic, within organization, and inter-organization traffic be separated./ 2-b) Webster defines bespoke as: custom-made (https://www.merriam-webster.com/dictionary/bespoke). I believe the nuances in bespoke better fit, but several people have comment on this issue - so let's just change it. The text you refer to is: Old /Since no widely accepted industry standard security interface to security NSFs exists today, management of NSFs (device and policy provisioning, monitoring, etc.) tends to be bespoke security management offered by product vendors. As a result, automation of such services, if it exists at all, is also bespoke. / New/ Since no widely accepted industry standard security interface to security NSFs exists today, management of NSFs (device and policy provisioning, monitoring, etc.) tends to be custom-made security management offered by product vendors. As a result, automation of such services, if it exists at all, is also custom-made. / -3: "The "Customer-Provider" relationship may be between any two parties. The parties can be in different firms or different domains of the same firm." There again seem to be implied business models here. Is it technically relevant if organizations qualify as "firms"? Sue: a replacement of New/The "Customer-Provider" relationship may be between any two parties. The parties can be in different organization or different domains of the same organization./ - 3.1.1: -- Consider adding DMZ to the glossary Sue: DMZ - is in the security glossary - RFC4949. As such, it was suggested that we do not need to add it to this draft. -- "Centralized or Distributed security functions" seems out of place. The rest of the section describes kinds of security functions; this describes the design of security functions. Sue: beginning of the lists states "Below are a few examples of security functions and locations or contexts in which they are often deployed:" . On the list is "DMZ", Centralized or distributed security functions, and "security gateways". The WG choose not to debate whether each was a function or a location. Please let me know how high a priority this is for you as I will have modify the whole list. - 3.2.1, first sentence: The second instance of "deploy" seems like a strange usage. Should this be "use"? Sue: Yes. -3.5, title: s/Difficulty/Difficult Sue: Thank you for the change. -3.6: "SDN-inferred agility" Should that be SDN "implied" or "conferred" agility? Sue: Thank you. Conferred - 4.2: -- "typically by means of Business- to-Business (B2B) communications." Again, does B2B imply some technical characteristics of the communication? Otherwise, how is this different than just "communication"? Removed B2B, and replaced with appropriate text. -- Figure 3: Please define or cite a definition for Evolved Packet Core. Added a reference in the definition section vEPC -7: Are there no privacy related requirements? I've added some text, but I can added more. _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Thu Apr 27 05:58:48 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262CF1200DF; Thu, 27 Apr 2017 05:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 eo2hJBNkPJP9; Thu, 27 Apr 2017 05:58:39 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 92B41129412; Thu, 27 Apr 2017 05:58:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.23.139; From: "Susan Hares" To: "'Deborah Brungard'" , "'The IESG'" Cc: , , , References: <149194565373.15662.3048610482760333306.idtracker@ietfa.amsl.com> In-Reply-To: <149194565373.15662.3048610482760333306.idtracker@ietfa.amsl.com> Date: Thu, 27 Apr 2017 08:52:31 -0400 Message-ID: <012f01d2bf55$228c6f80$67a54e80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFxKYNhMTnbSMIhG8VSm03IpkrcW6KcVldA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] Deborah Brungard's Abstain on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:58:40 -0000 Deborah: I asked Kathleen to move this one out 2 more weeks so that we could work through any issues you have with the document. Version 15 will take care of all other editorial comments. During the next few days or next Monday, perhaps we could chat on a phone call. I'm glad to change anything that does not parse or smooth out particular sections. Sue -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Deborah Brungard Sent: Tuesday, April 11, 2017 5:21 PM To: The IESG Cc: i2nsf@ietf.org; adrian@olddog.co.uk; draft-ietf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org Subject: [I2nsf] Deborah Brungard's Abstain on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) Deborah Brungard has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-12: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Similar to other Abstains, I won't block publication but question the value, especially the current version to be published at this time. The document rambles on descriptions and it is not concise on the problem to be addressed by i2nsf. I recommend holding off on publication until it can be fine tuned, it currently appears to be a cut and paste of many documents. Examples, section 5 seems to summarize that i2nsf will only focus on policy provisioning. Yet, section 3.4 discusses capability negotiation and 3.1.2 discusses monitoring mechanisms and execution status of NSFs capabilities. And other sections also infer much more, describing expectations of security controller functionality. There are several rather overzealous claims: Section 4.4 "botnet attacks could be easily prevented by provisioning security policies using the i2nsf..interface" and section 4.5 "security controller would keep track of ..if there is any policy violation ..proof..in full compliance with the required regulations". Several sentences don't parse e.g. "thereby raising concerns about the ability of SDN computation logic to send security policy-provisioning information to the participating NSFs". _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Thu Apr 27 06:22:16 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EB91294EF; Thu, 27 Apr 2017 06:22:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149329933375.2959.6902992785999929814@ietfa.amsl.com> Date: Thu, 27 Apr 2017 06:22:13 -0700 Archived-At: Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-problem-and-use-cases-15.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:22:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to Network Security Functions of the IETF. Title : I2NSF Problem Statement and Use cases Authors : Susan Hares Diego R. Lopez Myo Zarny Christian Jacquenet Rakesh Kumar Jaehoon Paul Jeong Filename : draft-ietf-i2nsf-problem-and-use-cases-15.txt Pages : 28 Date : 2017-04-27 Abstract: This document is the problem statement for Interface to Network Security Functions (I2NSF) as well as some companion use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-problem-and-use-cases-15 https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-problem-and-use-cases-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-problem-and-use-cases-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 27 06:23:26 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4FE1294EE; Thu, 27 Apr 2017 06:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, URIBL_BLOCKED=0.001] 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 2cGb4vW3Iyzl; Thu, 27 Apr 2017 06:23:23 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 D8F061294E2; Thu, 27 Apr 2017 06:23:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.23.139; From: "Susan Hares" To: "'Eric Rescorla'" , "'The IESG'" Cc: , , , References: <149160850285.11224.2464729863969311049.idtracker@ietfa.amsl.com> In-Reply-To: <149160850285.11224.2464729863969311049.idtracker@ietfa.amsl.com> Date: Thu, 27 Apr 2017 09:17:31 -0400 Message-ID: <014a01d2bf58$a0b35420$e219fc60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLp+LmdSbjdDBob/4eJx7rF7fr92p+qt79g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] Eric Rescorla's No Objection on draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:23:24 -0000 Ekr: Thank you for your insightful comments. The track has been changed to informational in version 13. Your comments have been fixed in version 15 (or in earlier versions). Sue -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Friday, April 7, 2017 7:42 PM To: The IESG Cc: i2nsf@ietf.org; adrian@olddog.co.uk; draft-ietf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org Subject: [I2nsf] Eric Rescorla's No Objection on draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT) Eric Rescorla has entered the following ballot position for draft-ietf-i2nsf-problem-and-use-cases-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't have any problem with this document per se, but it's a little odd how it's written in a vacuum as if there weren't already technologies which did a lot of the things you are talking about here (e.g., YANG) and which the WG intends to use. I think this document would be a lot stronger if it didn't act as if the WG was agnostic and instead called out what solutions the WG intends to adopt for these. Sue: Having set-up requirements for the I2RS protocol changes to YANG, NETCONF, and RESTCONF, I respectfully disagree with you. In writing the document in this style, it allows other technologies (CBOR or COAP) to be used. We may invent other functions in the future that may better secure mobile devices. I'm also somewhat surprised this is being advanced as Standards Track, given that it doesn't have any normative content, and becaus ehte writeup says that there isn't commitment to implement this. I won't hold a DISCUSS on this, but I would suggest it be Informational. Sue: It has been changed. S 2. Flow-based NSF: An NSF which inspects network flows according to a security policy. Flow-based security also means that packets are inspected in the order they are received, This seems over-specific, because sometimes firewalls and the like will store packets so that it can re-assemble them, in which case it inspects them in logical not time order. Sue: This specific comment summarizes a decision by the WG to define flow-based security in this fashion. This definition was the source of much debate in the WG. I agree that logical order can be used rather than time order, but the WG focused on time order. S 3.1.7. Different policies might need different signatures or profiles. Today, the construction and use of black list databases can be a win-win strategy for all parties involved. Well, except for attackers. They are involved. Sue: Nicely put - but S 3.1.9; bullet 3. Symmetric keys and group keys are not the same type of category, so I can't read this section. What are you trying to say here? Agreed - symmetric keys and group keys are not the same type of category. The point is that automated key management needs to support both. Otherwise requirements 1 + 2 cannot be met. If you can suggest a better way to put this section, please let me know. Section 3.1.9 - bullet 3: Old /Automated key management needs to support both symmetric keys and group keys via the abstract key service provided by items 1 and 2. I2NSF controllers within the NSF required to exchange data with NSFs may exchange data with individual NSFs using individual symmetric keys or with a group of NSFs simultaneously using an IP group address secured by a group security key(s). / S 3.5. "xamine" and "scnearios" are misspelled. Sue: Fixed in earlier version. My apologies for the error. (I had the joy of finding out my spell checker had been corrupted on my tool (notepad++)). S 3.6. ToR seems to be undefined. Sue: It was changed prior to version 15. Figure 3. I think this dotted circle-thing is intended to tell me that the operator controls the stuff inside the circle, but I'm not sure. Maybe some labels would help. Sue: Label "Service provider is within figure 3. Any further suggestions would help. _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Thu Apr 27 06:30:11 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0801276AF for ; Thu, 27 Apr 2017 06:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 wk-mSeQ1X3ZQ for ; Thu, 27 Apr 2017 06:29:58 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 EE4DA1200DF for ; Thu, 27 Apr 2017 06:29:52 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id 203so15442808ywe.0 for ; Thu, 27 Apr 2017 06:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8IHQjccB9YUJ4TsId3jGZT3OHhmrp4oQnD9vtYmoscQ=; b=dKKfeRn+m0Bz/pyoHtoX6iW7IKvgKrTQ0gvhuaEVHE8hFMC3SnG720qJx9RZABGw0Z hS2XavM3womSfMoX/weP/7Sfdhu7xa4mn5wWBxWMqZlfp3RGS0kk7JR9/5xvvuFfdwXx q8ClywIRWgLu9AFGZILpb0+/M+96egvJhVNGw9ni1rq7TuRrZmGwJlDxzBnpWtDYjzR/ jnL2dZjPTmPMV/poQfyvHou//eMvacCQK2EzhcKbUoX3nTXqXF3eN+e18zq6DmTEiUda led7X09l8IuVuSV7EBQ8Ch0pvQa2vHQMxv93mUJH3CgmPfjpzZR+VumAO0m8wbF9Xtyv 1HMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8IHQjccB9YUJ4TsId3jGZT3OHhmrp4oQnD9vtYmoscQ=; b=ssPedp/Dxg5hYdLtjtjnbrZVKYm4OMz3xgWazH/7GHXeRBKkoXvu6VsDorapa8eh5g +w6uw8zODqk+ZUqMAqtMSAv262Q44C3r36V9UeSgwkhlI0tKzhtuGCB7HoPMQsoG590s 8gszekuHk620KK0H/KVL3DrmfT6iwj5U9GKvNjHgkQhsEgjW6N9uCJXXWfd5gKUL+WMm 5k8wYMIxL2Ri38iXi6huFDGkDquHHZllWs6FRg0G3Tek2m37+V+8gGUOmiLoVUS8Vzb3 WCEdANN4nGxCVayq22Pj44UJBGoVvT6d0pyXEzeDCEBcjmFCwMS3bN/8j15r41GkZq3A sQcg== X-Gm-Message-State: AN3rC/4W1hlvGyf0XhdRAw7GGKGAFKe/qWA7YZDWL2rbpc5vL2Ob7wLe zvb//ZImFhBMvSxQwluPG+WJHLoEAw== X-Received: by 10.13.245.2 with SMTP id e2mr4541718ywf.270.1493299792056; Thu, 27 Apr 2017 06:29:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 06:29:11 -0700 (PDT) In-Reply-To: <014a01d2bf58$a0b35420$e219fc60$@ndzh.com> References: <149160850285.11224.2464729863969311049.idtracker@ietfa.amsl.com> <014a01d2bf58$a0b35420$e219fc60$@ndzh.com> From: Eric Rescorla Date: Thu, 27 Apr 2017 06:29:11 -0700 Message-ID: To: Susan Hares Cc: The IESG , i2nsf@ietf.org, Adrian Farrel , draft-ietf-i2nsf-problem-and-use-cases@ietf.org, i2nsf-chairs@ietf.org Content-Type: multipart/alternative; boundary=94eb2c08763aa6700c054e25f301 Archived-At: Subject: Re: [I2nsf] Eric Rescorla's No Objection on draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:30:04 -0000 --94eb2c08763aa6700c054e25f301 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 6:17 AM, Susan Hares wrote: > Ekr: > > Thank you for your insightful comments. The track has been changed to > informational in version 13. Your comments have been fixed in version 15 > (or in earlier versions). > > Sue > > > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Eric Rescorla > Sent: Friday, April 7, 2017 7:42 PM > To: The IESG > Cc: i2nsf@ietf.org; adrian@olddog.co.uk; > draft-ietf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org > Subject: [I2nsf] Eric Rescorla's No Objection on > draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT) > > Eric Rescorla has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-11: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I don't have any problem with this document per se, but it's a little odd > how it's written in a vacuum as if there weren't already technologies which > did a lot of the things you are talking about here (e.g., YANG) and which > the WG intends to use. I think this document would be a lot stronger if it > didn't act as if the WG was agnostic and instead called out what solutions > the WG intends to adopt for these. > > Sue: Having set-up requirements for the I2RS protocol changes to YANG, > NETCONF, and RESTCONF, I respectfully disagree with you. In writing the > document in this style, it allows other technologies (CBOR or COAP) to be > used. We may invent other functions in the future that may better secure > mobile devices. > OK, well, this is a WG decision, but I found it kind of hard to read as an outsider. > S 2. > Flow-based NSF: An NSF which inspects network flows according to a > security policy. Flow-based security also means that packets are > inspected in the order they are received, > > This seems over-specific, because sometimes firewalls and the like will > store packets so that it can re-assemble them, in which case it inspects > them in logical not time order. > > Sue: This specific comment summarizes a decision by the WG to define > flow-based security in this fashion. This definition was the source of > much > debate in the WG. I agree that logical order can be used rather than time > order, but the WG focused on time order So I guess my question is: say I had such a firewall. Would it not be a flow-based NSF? If not, what would it be? Note: My ask here is merely that the document be clear about what's in or out. I'm not arguing about the content of the decision. > S 3.1.9; bullet 3. > Symmetric keys and group keys are not the same type of category, so I can't > read this section. What are you trying to say here? > > Agreed - symmetric keys and group keys are not the same type of category. > The point is that automated key management needs to support both. > Otherwise > requirements 1 + 2 cannot be met. If you can suggest a better way to put > this section, please let me know. > > Section 3.1.9 - bullet 3: > Old /Automated key management needs to support both symmetric keys and > group keys via the abstract key service provided by items 1 and > 2. I2NSF controllers within the NSF required to exchange data > with NSFs may exchange data with individual NSFs using individual > symmetric keys or with a group of NSFs simultaneously using an IP > group address secured by a group security key(s). / I would suggest using "pairwise" and "group" as that's the distinction I think you want to draw. S 3.5. > "xamine" and "scnearios" are misspelled. > > Sue: Fixed in earlier version. My apologies for the error. (I had the joy > of finding out my spell checker had been corrupted on my tool (notepad++)). > > > S 3.6. > ToR seems to be undefined. > > Sue: It was changed prior to version 15. > > > Figure 3. > I think this dotted circle-thing is intended to tell me that the operator > controls the stuff inside the circle, but I'm not sure. Maybe some labels > would help. > > Sue: Label "Service provider is within figure 3. Any further suggestions > would help. > Huh. Maybe move the label outside and have an arrow to the circle saying "service provider boundary"? I know that ASCII art is tough here. -Ekr > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > --94eb2c08763aa6700c054e25f301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 6:17 AM, Susan Hares <shares@ndzh.com> wrote:
Ekr:

Thank you for your insightful comments.=C2=A0 The track has been changed to=
informational in version 13.=C2=A0 Your comments have been fixed in version= 15
(or in earlier versions).

Sue


-----Original Message-----
From: I2nsf [mailto:i2nsf-bounces= @ietf.org] On Behalf Of Eric Rescorla
Sent: Friday, April 7, 2017 7:42 PM
To: The IESG
Cc: i2nsf@ietf.org; adrian@olddog.co.uk;
draft-ie= tf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org
Subject: [I2nsf] Eric Rescorla's No Objection on
draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT)

Eric Rescorla has entered the following ballot position for
draft-ietf-i2nsf-problem-and-use-cases-11: No Objection

When responding, please keep the subject line intact and reply to all email=
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org= /doc/draft-ietf-i2nsf-problem-and-use-cases/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I don't have any problem with this document per se, but it's a litt= le odd
how it's written in a vacuum as if there weren't already technologi= es which
did a lot of the things you are talking about here (e.g., YANG) and which the WG intends to use. I think this document would be a lot stronger if it<= br> didn't act as if the WG was agnostic and instead called out what soluti= ons
the WG intends to adopt for these.

Sue: Having set-up requirements for the I2RS protocol changes t= o YANG,
NETCONF, and RESTCONF, I respectfully disagree with you.=C2=A0 In writing t= he
document in this style, it allows other technologies (CBOR or COAP) to be used.=C2=A0 =C2=A0We may invent other functions in the future that may bett= er secure
mobile devices.

OK, well, this is a WG = decision, but I found it kind of hard to read as an outsider.
=C2=A0
S 2.
=C2=A0 Flow-based NSF:=C2=A0 =C2=A0 An NSF which inspects network flows acc= ording to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 security policy.=C2=A0 Flow-based security also= means that packets are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 inspected in the order they are received,

This seems over-specific, because sometimes firewalls and the like will
store packets so that it can re-assemble them, in which case it inspects them in logical not time order.

Sue: This specific comment summarizes a decision by the WG to define=
flow-based security in this fashion.=C2=A0 This definition was the source o= f much
debate in the WG.=C2=A0 =C2=A0I agree that logical order can be used rather= than time
order, but the WG focused on time order

So = I guess my question is: say I had such a firewall. Would it not be a flow-b= ased
NSF? If not, what would it be? Note: My ask here is merely t= hat the document
be clear about what's in or out. I'm not= arguing about the content of the decision.

=C2=A0=
S 3.1.9; bullet 3.
Symmetric keys and group keys are not the same type of category, so I can&#= 39;t
read this section. What are you trying to say here?

Agreed - symmetric keys and group keys are not the same type of cate= gory.
The point is that automated key management needs to support both.=C2=A0 Oth= erwise
requirements 1 + 2 cannot be met.=C2=A0 If you can suggest a better way to = put
this section, please let me know.

Section 3.1.9 - bullet 3:
Old /Automated key management needs to support both symmetric keys and
group keys via the abstract key service provided by items 1 and
2. I2NSF controllers within the NSF required to exchange data
with NSFs may exchange data with individual NSFs using individual
symmetric keys or with a group of NSFs simultaneously using an IP
group address secured by a group security key(s). /

I would suggest using "pairwise" and "group" a= s that's the distinction I think you
want to draw.
=



S 3.5.
"xamine" and "scnearios" are misspelled.

Sue: Fixed in earlier version.=C2=A0 My apologies for the error.=C2= =A0 (I had the joy
of finding out my spell checker had been corrupted on my tool (notepad++)).=


S 3.6.
ToR seems to be undefined.

Sue: It was changed prior to version 15.


Figure 3.
I think this dotted circle-thing is intended to tell me that the operator controls the stuff inside the circle, but I'm not sure. Maybe some labe= ls
would help.

Sue: Label "Service provider is within figure 3.=C2=A0 Any furt= her suggestions
would help.

Huh. Maybe move the label o= utside and have an arrow to the circle saying
"service provi= der boundary"?

I know that ASCII art is tough= here.

-Ekr
=C2=A0


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf


--94eb2c08763aa6700c054e25f301-- From nobody Thu Apr 27 08:36:39 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAB3129AD1 for ; Thu, 27 Apr 2017 08:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 g8n9bVpF1XGF for ; Thu, 27 Apr 2017 08:36:23 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 B4AF7129B19 for ; Thu, 27 Apr 2017 08:34:42 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-05v.sys.comcast.net with SMTP id 3lR9dMrXIzz3d3lRJd4FHN; Thu, 27 Apr 2017 15:34:41 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-04v.sys.comcast.net with SMTP id 3lRHd0yrWFcZ23lRJd6sqp; Thu, 27 Apr 2017 15:34:41 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v3RFYbmi010046; Thu, 27 Apr 2017 11:34:38 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v3RFYa2n010027; Thu, 27 Apr 2017 11:34:36 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Susan Hares" Cc: gen-art@ietf.org, i2nsf@ietf.org, ietf@ietf.org, draft-ietf-i2nsf-problem-and-use-cases.all@ietf.org In-Reply-To: <012d01d2bf54$3d9bbb60$b8d33220$@ndzh.com> (shares@ndzh.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 27 Apr 2017 11:34:34 -0400 Message-ID: <8737ctrhit.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMU/myGjX5MRLWJJP6QFWDh0apPIByWYoYsEzaVfPzskhuCu/rClk3pHbAP4uHRsBZebwTWZRiC4sYcIULtiNuz+tjykKzqMPboSJmL7oyfph72a6S/P 5CJ/QBMh1Qg1alyj28HAXDbABcVyNKngDGCkmpU9rf/KBFCeoB/JdTM4kivOaHxQ1bLbtngcn62gmaz2ljUWJkYTqDsE1hbw4Az4SSqC5fYGzpcX6Fpwm1or TleS5qh3zmamY7li4nJNhbOQZcszYA3JktIE8h2KWiKW3Xn0BIyvAriciDvbs1hBAnonvgd3bdQE8HcmrPmRFw== Archived-At: Subject: Re: [I2nsf] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:36:24 -0000 "Susan Hares" writes: > Thank you for taking the time do a second careful review. I can only wish > I such an excellent review of documents I am an editor on. Version 14 > addresses all of your comments. Thanks! -15 looks great, except (ugh) for one remaining nit: > Sue: Dale I rewrote the whole paragraph in version 14. When I read the new paragraph, I get a slightly different impression than I did from the old paragraph (which is likely something you indend), viz., that it's about what could be called "the mitigation action lifecycle", the entire process from identification of the problem to verification that it has been mitigated, rather than just the *action* of mitigating the traffic problem. Within that broader context, the importance of monitoring is obvious. > 3.1.4. More Demand to Control NSFs Dynamically > > The Security Service Providers ... > > The capitalization of "security service providers" is inconsistent. > Some times all three words are capitalized (in 3.1.2, 3.1.4, and 4), and > some times they're not (two places in 3). > > Sue: Thank you for catching this. I moved all of these words to small case > except in titles. I overlooked (ugh) that there's an instance in section 2: Security Service Provider: A provider of security services to the customers (end-users or enterprises) using NSF equipment purchased from vendors or created by the service provider. It turns out that there are only 2 multi-word terms defined in section 2 where the later words aren't acronyms, which are the terms whose capitalization should be consistent. The other one is: Bespoke security management: Security management which is made to fit a particular customer. Dale From nobody Thu Apr 27 15:30:17 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757D81296C9; Thu, 27 Apr 2017 15:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=1.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 FStFqjC1Wsj5; Thu, 27 Apr 2017 15:30:06 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 7A08C129A9E; Thu, 27 Apr 2017 15:27:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 61896D00; Fri, 28 Apr 2017 00:27:01 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5AYhHiNOXyF4; Fri, 28 Apr 2017 00:27:01 +0200 (CEST) Received: from [192.168.1.36] (148.red-88-10-88.dynamicip.rima-tde.net [88.10.88.148]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon24.um.es (Postfix) with ESMTPSA id 8AC62853; Fri, 28 Apr 2017 00:26:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: Date: Fri, 28 Apr 2017 00:26:55 +0200 Cc: Rafa Marin Lopez , "IPsec@ietf.org" , Linda Dunbar , i2nsf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> <960CA8F1-256D-485F-91D7-20AFDB332BD5@um.es> To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [I2nsf] [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:30:09 -0000 Hi Paul: Thank you for your comments. Please, see mine inline. >>> [Rafa] I guess, it will depend on the scenario. I remember an e-mail = to I2NSF = (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html) = mentioning that they were doing sort of case 2 and they would like to = have a standard way of doing it. Precisely the effort behind our I-D is = trying to provide an standard interface standard not only for case 1 = (with IKE in the NSF) but also for case 2 (no IKE in the NSF).=20 >>>=20 >=20 > Don't. You will need to builtin there same security features as IKE = has. [Rafa] Yes, but in case 2 all those features (e.g. key management = operations) are in the controller but not in the NSFs. The NSFs only = implements IPsec stack and deploys, for example, a NETFCONF server for = the communication with the controller. Thus, all the key management = operations are performed in the controller in case 2 and the resulting = IPsec SAs are installed in the NSFs using, for example, NETCONF.=20 > Focus instead of implementing "minimal ikev2" >=20 > https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-01 [Rafa] Minimal IKEv2 implementation in the NSF would be case 1.=20 Nevertheless, implementing minimal ikev2 does not solve, for example, = NAT-T for case 1 so controller should do something anyway. >=20 >=20 > For example, most modern ciphers require timely rekeying and must = never reuse IV/counters with the same private key. [Rafa] Why do you imply that IV/counters will be the same with same = private key? That is not the assumption in case 2 where the controller = always generates fresh IPsec SAs. > Synching that across independent hosts is impossible. [Rafa] I do not see how it is impossible when a controller that have = access to both NSFs provides that information. If it is not impossible = when using IKEv2, it should not be impossible for case 2.=20 The point is that the result of running IKEv2 is the IPsec SAs in the = IPsec kernel of both NSFs. In case 2, that state is coming from the = controller that is performing the key management operations (generate = fresh key material, IV, etc=E2=80=A6 per each IPsec SA). The controller = has a connection with both NSFs using, for example, NETCONF. Moreover, = as I commented , you can read this e-mail = (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html). So = there is proof that it is working. Thus, it is more difficult to manage, yes, (in fact, we admit that in = our I-D), but not impossible.=20 In fact, I think it would be worthy if you can provide a concrete = example of that use case where both NSFs are under the same controller. = Maybe we can help you to address your concern and explain how the = operation would be in that specific case you have in mind. Best Regards and many thanks for your comments. >=20 > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ---------------------------------------------------------- From nobody Thu Apr 27 15:30:48 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5829E129AB3; Thu, 27 Apr 2017 15:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 YzNn-hrp6R-Y; Thu, 27 Apr 2017 15:30:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 147D0129AB5; Thu, 27 Apr 2017 15:27:25 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3RMRNas044231 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 27 Apr 2017 17:27:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <011c01d2bf50$a709c550$f51d4ff0$@ndzh.com> Date: Thu, 27 Apr 2017 17:27:23 -0500 Cc: The IESG , i2nsf@ietf.org, adrian@olddog.co.uk, draft-ietf-i2nsf-problem-and-use-cases@ietf.org, i2nsf-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0BFE7C47-A230-4DBE-B48E-F78F9BDF810E@nostrum.com> References: <149308590735.13684.18127771505881667407.idtracker@ietfa.amsl.com> <011c01d2bf50$a709c550$f51d4ff0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [I2nsf] Ben Campbell's No Objection on draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:30:33 -0000 > On Apr 27, 2017, at 7:20 AM, Susan Hares wrote: >=20 > Ben:=20 >=20 > I am dealing with the editorial comments you indicated. I am not = dealing > with the wider scope issues of information for support documents. = Version > 13 is submitted to fix these issues, and to change the draft's status = to > informational.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Monday, April 24, 2017 10:05 PM > To: The IESG > Cc: i2nsf@ietf.org; adrian@olddog.co.uk; > draft-ietf-i2nsf-problem-and-use-cases@ietf.org; i2nsf-chairs@ietf.org > Subject: [I2nsf] Ben Campbell's No Objection on > draft-ietf-i2nsf-problem-and-use-cases-12: (with COMMENT) >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-i2nsf-problem-and-use-cases-12: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I agree with the various abstains about this draft not appearing to = have > archival value. I chose not to ballot "abstain" because I think it's = best to > handle that issue at charter or adoption time rather than doing so = this > close to the finish line. (I note that the WG charter explicitly says = that > the WG may choose not to publish, so this is a borderline > case.) If there really are good reasons to expect archival value, it = would > be helpful to include a paragraph early in the document describing = those > reasons. >=20 > I have a few additional comments on the odd chance this draft > progresses: >=20 > -2: > -- B2B describes a business model. I don't see how that is useful for = IETF > discussion unless it implies specific technical characteristics. If it = does, > them please describe them. > Bespoke": In other usages, "bespoke" often implies positive thing, = which I > don't think the draft intends. I think the work "customized" would = better > fit the usage herein. >=20 > 2-a) Removed B2B in sentence: =20 > New/For example, an enterprise may mandate that firewalls serving = Internet > traffic, within organization, and inter-organization traffic be = separated./ WFM >=20 > 2-b)=20 > Webster defines bespoke as: custom-made > (https://www.merriam-webster.com/dictionary/bespoke). I believe the > nuances in bespoke better fit, but several people have comment on this = issue > - so let's just change it.=20 > The text you refer to is:=20 > Old /Since no widely accepted industry standard security interface > to security NSFs exists today, management of NSFs (device and policy > provisioning, > monitoring, etc.) tends to be bespoke security management offered by > product vendors. As a result, automation of such services, if it > exists at all, is also bespoke. > /=20 > New/ > Since no widely accepted industry standard security interface > to security NSFs exists today, management of NSFs (device and policy > provisioning, > monitoring, etc.) tends to be custom-made security management offered = by > product vendors. As a result, automation of such services, if it > exists at all, is also custom-made. > / That WFM. In this context, I might suggest =E2=80=9Ccustomized=E2=80=9D, = but either is okay. >=20 >=20 > -3: "The "Customer-Provider" relationship may be between any two = parties. > The parties can be in different firms or different domains of the same > firm." > There again seem to be implied business models here. Is it technically > relevant if organizations qualify as "firms"? >=20 > Sue: a replacement of=20 >=20 > New/The "Customer-Provider" relationship may be between any two = parties. > The parties can be in different organization or different domains = of > the same > organization./=20 WFM >=20 > - 3.1.1: > -- Consider adding DMZ to the glossary >=20 > Sue: DMZ - is in the security glossary - RFC4949. As such, it was > suggested that we do not need to add it to this draft. =20 Okay. >=20 > -- "Centralized or Distributed security functions" seems out of place. > The rest of the section describes kinds of security functions; this > describes the design of security functions. >=20 > Sue: beginning of the lists states "Below are a few examples of = security > functions and locations or contexts in which they are often deployed:" = . > On the list is "DMZ", Centralized or distributed security functions, = and > "security gateways". The WG choose not to debate whether each was a > function or a location. Please let me know how high a priority this = is for > you as I will have modify the whole list.=20 It=E2=80=99s certainly not a showstopper, so I will leave it to you to = decide. In my case, It took me out of the flow of reading and left me = with the Big Bird singing =E2=80=9COne of these things=E2=80=A6.=E2=80=9D = in my head. But maybe that=E2=80=99s just me. :-) [Several points elided to which my replies would be along the lines of = =E2=80=9Csounds good=E2=80=9D] > -7: Are there no privacy related requirements? >=20 > I've added some text, but I can added more.=20 The text in version 15 looks good to me. (Not sure which version first = contained it.) Thanks! Ben. From nobody Fri Apr 28 08:58:24 2017 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3F12EAF1; Fri, 28 Apr 2017 08:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 a4DwLaoojVFX; Fri, 28 Apr 2017 08:58:13 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3A02F124217; Fri, 28 Apr 2017 08:54:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id AA2F73FF9A; Fri, 28 Apr 2017 17:54:34 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3Z5GJ20HiB8H; Fri, 28 Apr 2017 17:54:34 +0200 (CEST) Received: from inf-205-158.inf.um.es (inf-205-158.inf.um.es [155.54.205.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon21.um.es (Postfix) with ESMTPSA id 9C97C3F974; Fri, 28 Apr 2017 17:54:30 +0200 (CEST) From: Gabriel Lopez Message-Id: <67B6C8B8-4345-4250-A4BA-801986197A17@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Apr 2017 17:54:30 +0200 In-Reply-To: <2DA788A5A7D91747AEA54B502558D73826A6C421@DGGEMM506-MBS.china.huawei.com> Cc: Linda Dunbar , Yoav Nir , "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" To: Sandeep Kampati References: <2DA788A5A7D91747AEA54B502558D73826A6C421@DGGEMM506-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [I2nsf] [IPsec] small correction : draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 15:58:16 -0000 --Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sandeep, > El 26 abr 2017, a las 11:26, Sandeep Kampati = escribi=C3=B3: >=20 > Hi All, >=20 > small correction =20 >=20 > 8. Data model >=20 > Data model for the SDP entries: --> it should be "Data model = for the SPD entries: =E2=80=9C Thanks. We expect to have a new version in the next days. Regards, Gabi. >=20 > Regards, > Sandeep.k >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Sandeep,


El 26 abr 2017, a las 11:26, Sandeep Kampati <sandeepkampati@huawei.com> escribi=C3=B3:

Hi = All,

small correction    

8.  Data model

= Data model for the SDP entries: --> it should be =    "Data model for the SPD entries: = =E2=80=9C


Thanks.
We expect to have a new version in = the next days.

Regards, = Gabi.


Regards,
Sandeep.k



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es

= --Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A-- From nobody Fri Apr 28 23:16:17 2017 Return-Path: X-Original-To: i2nsf@ietf.org Delivered-To: i2nsf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F277C129AF9; Fri, 28 Apr 2017 23:16:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149344656494.2869.3929572588032800625@ietfa.amsl.com> Date: Fri, 28 Apr 2017 23:16:04 -0700 Archived-At: Subject: [I2nsf] I-D Action: draft-ietf-i2nsf-client-facing-interface-req-01.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.22 List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 06:16:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to Network Security Functions of the IETF. Title : Requirements for Client-Facing Interface to Security Controller Authors : Rakesh Kumar Anil Lohiya Dave Qi Nabil Bitar Senad Palislamovic Liang Xia Filename : draft-ietf-i2nsf-client-facing-interface-req-01.txt Pages : 22 Date : 2017-04-28 Abstract: This document captures requirements for Client-Facing interface to Security Controller. The interface is expressed using objects and constructs understood by Security Admin as opposed to vendor or device specific expressions associated with individual product and feature. This document identifies a broad set of requirements needed to express security policies based on User-constructs which are well understood by User Community. This gives ability to decouple policy definition from policy enforcement on a specific element, be it a physical or virtual. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-i2nsf-client-facing-interface-req-01 https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-client-facing-interface-req-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2nsf-client-facing-interface-req-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/