From nobody Mon Apr 4 04:53:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930D012D540 for ; Mon, 4 Apr 2016 04:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Kjq4E-5oqeUx for ; Mon, 4 Apr 2016 04:53:00 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 7CC5612D563 for ; Mon, 4 Apr 2016 04:53:00 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id g184so92150447lfb.3 for ; Mon, 04 Apr 2016 04:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=8DcJ31Aouw3lY8IQ+FIHV5CXESGfWvA3R/Dlv5o4D9k=; b=tgTgi0XkapO9NfgXtKybYnoSKQCKQjKByQdbvGfPI2IyjdhddFa9YnuWYE0FY4QB6z VsZOYujvadbc/Ubx1x5Uy+pE845oxM6x6sUOrl9qaKh7l/OI9utVJCQzbeZH/942k0mY PoWZ3cctgsgjiVq8VCS7IiJSkypyugfcqKN9n0JGgUtdIkhc263ddD7VlNPgxhhTAo4w XnJpTVPxRbrYd2YFZA0eBkWMBRgSi5ZtnpenQx29rvfOzpJu+IrW7qEFRcuTb0C3RUEz mkEfGMffcXVBBOyuaM5WbZ35vbnYoOP7o/uuGoi0+K28mslyV7P4iHJ1PgE0rX6rVxos F4OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=8DcJ31Aouw3lY8IQ+FIHV5CXESGfWvA3R/Dlv5o4D9k=; b=m3esZj7X0qszeHcjVygjlvddzyywK5sSAZbW8XoMHUd66EnoaPwxHO0QFLFUDqZtgl lmIz1KBN40vjecTievjXmSC2UOycPrQWOzmrcItTHIV0FLXsoSJkgEMWjKGRdbVhJgJ6 pkCswu08zicHo4jP6g6Hv2983q2mLhz1nq5aiDvlUcnPFE1uKf2m2iC91MWNxsApQJP5 dtUeWuksjUOaxMI0Huc7w1ic+k5/rd/FlPwk3dko1BanoIxJsNpuqPHh8gwwMHs03So8 qJ+HYzfmisAiFP+CW8+19kGd2Nn/MtrgPxdtj+YGSg34nR9LVWtfojefgwOgsfI3ZLpy BYjQ== X-Gm-Message-State: AD7BkJIFo9IjD+9TA02fG9m7YfnNdlcx6WTsNxio9GjI6Q3Wmp5yZK/hXPH9yh3UDqsz3laDpu/n4KIV3NNZKQ== MIME-Version: 1.0 X-Received: by 10.25.150.147 with SMTP id y141mr4936426lfd.95.1459770778746; Mon, 04 Apr 2016 04:52:58 -0700 (PDT) Received: by 10.25.154.210 with HTTP; Mon, 4 Apr 2016 04:52:58 -0700 (PDT) Date: Mon, 4 Apr 2016 08:52:58 -0300 Message-ID: From: Hui Deng To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a11402544b885c9052fa75ea4 Archived-At: Subject: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 11:53:05 -0000 --001a11402544b885c9052fa75ea4 Content-Type: text/plain; charset=UTF-8 Hello all We have posted a submission this morning, apologize for late submission. https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt OPEN-O would intent to propose an open source project under Linux foundation. It includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is sitting on top of SDN Controller like ODL or ONOS and somewhere below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document is seeking for the relationship between open standard IETF and open source project OPEN-O. thanks a lot for your kind review Best regards, DENG Hui --001a11402544b885c9052fa75ea4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all

We have posted a submission t= his morning, apologize for late submission.

https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-ope= no-00.txt

OPEN-O would intent to propose an open source =
project under Linux foundation. It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
--001a11402544b885c9052fa75ea4-- From nobody Mon Apr 4 07:42:19 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A75712D1BF for ; Mon, 4 Apr 2016 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9aTn3AWnGUD4 for ; Mon, 4 Apr 2016 07:42:15 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EEA612D6F6 for ; Mon, 4 Apr 2016 07:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14610; q=dns/txt; s=iport; t=1459780932; x=1460990532; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NWl5dRNC2wcgF5M5K6cWrSHa/GFvLti79qo2wVJ+7rU=; b=hUOqb65wMdj0tigqh/WN4vVgfoFcyMlBqPXLaix5guyHHA52g3Z7yk2J Cx4rhz813C3n2m29yMlOUM6QuL6akqWGq39h1CF6am/Q8uPaibO9AX7eB mibRiXeSimBZtIv00IfOuOVRNUuuh7YQu7y6Z49UHPqO45Uq8VwSWDThI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgD8ewJX/4UNJK1dgmtMU30GtjGEc?= =?us-ascii?q?AENgXIXAQiFI0oCgTM4FAEBAQEBAQFlJ4RBAQEBAwEBAQFrEAsCAQgOAwMBAQE?= =?us-ascii?q?BIwQHJwsUCQgCBAESCYgWCA68fQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIRKg?= =?us-ascii?q?jOBXBACASMahTYFmAEBhXKIFYFojSeGGoh/AR4BAUKCMoE1bAEBAYclfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,440,1454976000"; d="scan'208,217";a="255399663" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 14:42:11 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u34EgBlK030495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 14:42:11 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 09:42:10 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 09:42:10 -0500 From: "Sri Gundavelli (sgundave)" To: Andreas Schultz , "Romascanu, Dan (Dan)" , "opsawg@ietf.org" , Dorothy Stanley , Warren Kumari Thread-Topic: [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel Thread-Index: AQHRjnsv2wIJgbcr4EK2X1IABxycCp96NXEA//+MZQA= Date: Mon, 4 Apr 2016 14:42:10 +0000 Message-ID: References: <57027BCA.8090004@cisco.com> In-Reply-To: <57027BCA.8090004@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.246.175] Content-Type: multipart/alternative; boundary="_000_D327CA7220EA9Asgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:42:18 -0000 --_000_D327CA7220EA9Asgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andreas, Thanks for the review comments. We plan to incorporate this review comments= in the next rev. We will work with you on the resolution for these issues. Regards Sri -------- Forwarded Message -------- Subject: Re: [OPSAWG] Review of "Alternate Tunnel Encapsulation for = Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel Date: Wed, 17 Feb 2016 12:05:29 +0100 From: Andreas Schultz To: Romascanu, Dan (Dan) , Warren Kumari , opsawg@ietf.org CC: Dorothy Stanley Hi, On 02/17/2016 11:36 AM, Romascanu, Dan (Dan) wrote: > Hi, > > I have reviewed the previous versions of this document. I do not find sig= nificant changes in the content since. I believe that it=92s ready > for publication. The comments in https://www.ietf.org/mail-archive/web/opsawg/current/msg041= 61.html have not yet been addressed. Having written those comment, I obviously feel that there should be some ch= anges made before publication. Regards Andreas > AFAIK the document was also reviewed by IEEE 802.11. I am copying the Dor= othy Stanley who is the liaison manager, as I do not know if she is > subscribed to the WG mail list. > > Regards, > > Dan > > *From:*OPSAWG [mailto:opsawg-bounces@ietf.org] *On Behalf Of *Warren Kuma= ri > *Sent:* Wednesday, February 17, 2016 12:31 AM > *To:* opsawg@ietf.org > *Subject:* [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Fr= ames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel > > Dear OpsAWG, > > While we have lots of energy / interest, we'd appreciate some additional = review of draft-ietf-opsawg-capwap-alt-tunnel > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ > ). > > This document has an interesting history - it completed WGLC in 2014-08-2= 7 and was submitted to be published as an RFC on 2014-09-08. > > We then got draft-you-opsawg-capwap-separation-for-mp, which had some som= e significant similarities. We asked the ADs to hold alt-tunnel > while we discussed what to do, and then finally asked the ADs / IESG to r= eturn it to the WG so that these two documents could be merged into > one ( https://www.ietf.org/mail-archive/web/opsawg/current/msg04071.html > ). > > This document has already passed one WGLC (module the minor merging), and= we are waiting on the authors to address some comments (e.g: > https://www.ietf.org/mail-archive/web/opsawg/current/msg04161.html > ) > and update the email addresses - once that happens we will do another WGL= C -- but, while we are waiting, we'd appreciate any other review > and feedback. > > W > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.orghttps://www.ietf.org/mailman/listinf= o/opsawg . . --_000_D327CA7220EA9Asgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Andreas,

Thanks for the review comments. We plan to incorporate this review com= ments in the next rev. We will work with you on the resolution for these is= sues.



Regards
Sri


-------- Forwarded Message --------
Subject: Re: [OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Fr= ames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel
Date: Wed, 17 Feb 2016 12:05:29 +0100
From: Andreas Schultz <aschultz@tpip.net>
To: Romascanu, Dan (Dan) <dromasca@avaya.com>, Warren Kumari &l= t;warren@kumari.net>, o= psawg@ietf.org <opsawg@ietf.org>
CC: Dorothy Stanley <DStanley@arubanetworks.com> 


Hi,

On 02/17/2016 11:36 AM, Romascanu, Dan (Dan) wrote:
> Hi,
>
> I have reviewed the previous versions of this document. I do not find =
significant changes in the content since. I believe that it=92s ready
> for publication.

The comments in https://www.ietf.org/mail-archive/web/opsawg/current/msg04161.html ha=
ve not yet been addressed.
Having written those comment, I obviously feel that there should be some ch=
anges made before publication.

Regards
Andreas


> AFAIK the document was also reviewed by IEEE 802.11. I am copying the =
Dorothy Stanley who is the liaison manager, as I do not know if she is
> subscribed to the WG mail list.
>
> Regards,
>
> Dan
>
> *From:*OPSAWG [mailto:opsawg-bounces@ietf.org=
] *On Behalf Of *Warren Kumari
> *Sent:* Wednesday, February 17, 2016 12:31 AM
> *To:* opsawg@ietf.org
> *Subject:* [OPSAWG] Review of "Alternate Tunnel Encapsulation for=
 Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel
>
> Dear OpsAWG,
>
> While we have lots of energy / interest, we'd appreciate some addition=
al review of draft-ietf-opsawg-capwap-alt-tunnel
> (https=
://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/
> <https://urldefense.proofpoint.com/=
v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dopsawg-2Dcapwa=
p-2Dalt-2Dtunnel_&d=3DBQMFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4d=
zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DYSTTTzZjDjD_fxRDbZTWgW6tBr=
wOadoMW7MP4RRFFdQ&s=3DZuwP2TZyReJXmH8tHtt8Bg0SDGvmX2_un8TtmJU5sQI&e=
=3D> ).
>
> This document has an interesting history - it completed WGLC in 2014-0=
8-27 and was submitted to be published as an RFC on 2014-09-08.
>
> We then got draft-you-opsawg-capwap-separation-for-mp, which had some =
some significant similarities. We asked the ADs to hold alt-tunnel
> while we discussed what to do, and then finally asked the ADs / IESG t=
o return it to the WG so that these two documents could be merged into
> one ( htt=
ps://www.ietf.org/mail-archive/web/opsawg/current/msg04071.html
> <https://urldefense.proofpoint.com/v2/url?u=3D=
https-3A__www.ietf.org_mail-2Darchive_web_opsawg_current_msg04071.html&=
d=3DBQMFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQf=
ucBXRucPvdrphpBsFA&m=3DYSTTTzZjDjD_fxRDbZTWgW6tBrwOadoMW7MP4RRFFdQ&=
s=3D59ocMkJDZW_0tPUy9QccyjIc81Yjqe5RhjgrCX0aG8M&e=3D> ).
>
> This document has already passed one WGLC (module the minor merging), =
andwe are waiting on the authors to address some comments (e.g:
> https://w=
ww.ietf.org/mail-archive/web/opsawg/current/msg04161.html
> <https://urldefense.proofpoint.com/v2/url?u=3D=
https-3A__www.ietf.org_mail-2Darchive_web_opsawg_current_msg04161.html&=
d=3DBQMFaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQf=
ucBXRucPvdrphpBsFA&m=3DYSTTTzZjDjD_fxRDbZTWgW6tBrwOadoMW7MP4RRFFdQ&=
s=3DY24UHv4v54xg7rgWKHivf8xbeORWBYd3sjg6SJg1t2w&e=3D> )
> and update the email addresses - once that happens we will do another =
WGLC -- but, while we are waiting, we'd appreciate any other review
> and feedback.
>
> W
>
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/li=
stinfo/opsawg
>

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg
.


.

--_000_D327CA7220EA9Asgundaveciscocom_-- From nobody Mon Apr 4 15:06:48 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF52E12D5E4 for ; Mon, 4 Apr 2016 15:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001] 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 6w9jm7Ny81LJ for ; Mon, 4 Apr 2016 15:06:42 -0700 (PDT) Received: from 189corp.21cn.com (forptr.bnet.cn [183.61.185.80]) by ietfa.amsl.com (Postfix) with ESMTP id 50D2812D8CC for ; Mon, 4 Apr 2016 15:06:40 -0700 (PDT) Received: from clientip-31.133.163.89 (unknown [10.64.15.12]) by 189corp.21cn.com (HERMES) with ESMTP id 6B4C13C0094; Tue, 5 Apr 2016 06:06:38 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.10.64.15.12.1827209011 HMM_SOURCE_TYPE: WEBMAIL Received: from ip<31.133.163.89> ([10.64.15.24]) by zment-as2(MEDUSA 0.0.0.0) with ESMTP id e4ec46fd-8860-4278-9725-1d97ddfb2e72 for denghui02@gmail.com; Tue Apr 5 06:06:38 2016 0/X-Total-Score: 0: X-FILTER-SCORE: to=<85868f8889968a515361888e828a8d4f84908e>, score=<1459807598voYG+++++w++I++c+wIcJ/NS9JDDDDDzDDQDD1DzQ1sE> X-REAL-FROM: zhangr@gsta.com X-Receive-IP: 10.64.15.24 Date: Tue, 5 Apr 2016 06:06:38 +0800 (CST) From: zhangr To: Hui Deng , "opsawg@ietf.org" Message-ID: <454248678.52791459807598557.JavaMail.hermes@zment-web4> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5796_1162740107.1459807598108" HMM_WEBCLN_IP: 10.64.15.21 X-HERMES-SENDMODE: normal X-HERMES-SET: d6Zd6eavBrbqCZ2mYA7Dv8Zph2NgLyhP Archived-At: Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:06:48 -0000 ------=_Part_5796_1162740107.1459807598108 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+CiA8aGVhZD48L2hlYWQ+CiA8Ym9keT4KICA8ZGl2PgogICBUaGlzIGRyYWZ0IHNvdW5k cyBpbnRlcmVzdGluZywgd291bGQgbGlrZSB0byBzZWUgaXQgaXMgcHJlc2VudGVkIGR1cmluZyB0 aGUgbWVldGluZyBhYm91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gb3BlbiBzdGFuZGFyZCBh bmQgb3BlbiBzb3VyY2UuCiAgPC9kaXY+CiAgPGRpdj4KICAgPGJyIC8+CiAgPC9kaXY+CiAgPGRp dj4KICAgUm9uZyBaaGFuZyZuYnNwOwogIDwvZGl2PgogIDxkaXY+CiAgICZuYnNwOwogIDwvZGl2 PgogIDxkaXY+CiAgICZuYnNwOwogIDwvZGl2PgogIDxkaXYgaWQ9InNwblNpZ24yMDE2NDQxOTUi PjwvZGl2PiAKICA8ZGl2IHN0eWxlPSJib3JkZXItbGVmdDoxcHggc29saWQgI0RERERERDtwYWRk aW5nLWxlZnQ6NXB4O21hcmdpbi1sZWZ0OjVweDsiPgogICAtLS0tLS0tLS0tLS0tLS0tLS0g5Y6f 5aeL6YKu5Lu2IC0tLS0tLS0tLS0tLS0tLS0tLQogICA8YnIgLz4KICAgPGJyIC8+5Y+R5Lu25Lq6 77yaSHVpIERlbmcgJnF1b3Q7ZGVuZ2h1aTAyQGdtYWlsLmNvbSZxdW90OwogICA8YnIgLz7ml7bj gIDpl7TvvJoyMDE2LzA0LzA0IDE5OjUyOjU4IOaYn+acn+S4gAogICA8YnIgLz7mlLbku7bkurrv vJomcXVvdDtvcHNhd2dAaWV0Zi5vcmcmcXVvdDsgJnF1b3Q7b3BzYXdnQGlldGYub3JnJnF1b3Q7 CiAgIDxiciAvPuaKhOmAgeS6uu+8mgogICA8YnIgLz7kuLvjgIDpopjvvJpbT1BTQVdHXSBPUEVO LU8gZHJhZnQKICAgPGJyIC8+CiAgIDxiciAvPiAKICAgPGRpdiBkaXI9Imx0ciI+CiAgICAgSGVs bG8gYWxsIAogICAgPGRpdj4gCiAgICAgPGJyIC8+IAogICAgPC9kaXY+IAogICAgPGRpdj4KICAg ICAgV2UgaGF2ZSBwb3N0ZWQgYSBzdWJtaXNzaW9uIHRoaXMgbW9ybmluZywgYXBvbG9naXplIGZv ciBsYXRlIHN1Ym1pc3Npb24uIAogICAgPC9kaXY+IAogICAgPGRpdj4gCiAgICAgPHAgY2xhc3M9 IiI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWRlbmctb3BzYXdnLW5mdnJnLXNkbnJnLW9wZW5vLTAwLnR4dCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtZGVuZy1vcHNhd2ctbmZ2cmctc2Rucmctb3Blbm8tMDAudHh0PC9hPjwv c3Bhbj48L3A+IAogICAgIDxwcmU+T1BFTi1PIHdvdWxkIGludGVudCB0byBwcm9wb3NlIGFuIG9w ZW4gc291cmNlIHByb2plY3QgdW5kZXIgTGludXggZm91bmRhdGlvbi4gSXQNCg0KICAgaW5jbHVk ZXMgY3Jvc3MgZG9tYWluIG9yY2hlc3RyYXRvciwgU0ROLU8gYW5kIE5GVi1PLiBTRE4tTyBpcw0K DQogICBzaXR0aW5nIG9uIHRvcCBvZiBTRE4gQ29udHJvbGxlciBsaWtlIE9ETCBvciBPTk9TIGFu ZCBzb21ld2hlcmUNCg0KICAgYmVsb3cgdGhlIFNETiBBUFAuIE5GVk8gaXMgYWxpZ25lZCB3aXRo IEVUU0kgTkZWIElTRy4gVGhpcyBkb2N1bWVudA0KDQogICBpcyBzZWVraW5nIGZvciB0aGUgcmVs YXRpb25zaGlwIGJldHdlZW4gb3BlbiBzdGFuZGFyZCBJRVRGIGFuZCBvcGVuDQoNCiAgIHNvdXJj ZSBwcm9qZWN0IE9QRU4tTy4NCg0KPC9wcmU+IAogICAgIDxwcmU+dGhhbmtzIGEgbG90IGZvciB5 b3VyIGtpbmQgcmV2aWV3PC9wcmU+IAogICAgIDxwcmU+QmVzdCByZWdhcmRzLDwvcHJlPiAKICAg ICA8cHJlPkRFTkcgSHVpPC9wcmU+IAogICAgPC9kaXY+IAogICA8L2Rpdj4gCiAgPC9kaXY+IAog PC9ib2R5Pgo8L2h0bWw+ ------=_Part_5796_1162740107.1459807598108-- From nobody Mon Apr 4 16:34:32 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B871F12D645 for ; Mon, 4 Apr 2016 16: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 A9jYEYlS3qbH for ; Mon, 4 Apr 2016 16:34:28 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D6112D126 for ; Mon, 4 Apr 2016 16:34:27 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id s5so69466566qkd.0 for ; Mon, 04 Apr 2016 16:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xcHr1dXuztvyXjfFgPbBlGP1VpcI/Fp9w/mg+rtbDvk=; b=uuY2OMVMF/zFFoY6eN7ZOAj3x+n68OKHgpMi7EHaYDm2Z7o2FXStmu+2PDPSW8Irxh 4BfhtfV9YcfKEB74HuJ7gKzJUeVc0g2qKBwkamkzcsWPlWv0N5RnjBKjSyHw8xPX+9Yz T/XMfZj9U+eyE2fUjUvSq+rmg7KWIFhOizPaHi8qTbCVabDWhSeRpLh7uYkohoHXHMmh JLyEZS9Bnlu7hAfnC70Gj+eSCMq8b8eCH2C678JXF8QBV1GLUovaVKUKE30USd24jVP8 BCwrT350kKI5I8ukH+NlAHoHOp/DG6zPbSjd3ZLCTyla4/OQN0i8t+Ia6onNgbzOLOTI fozA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xcHr1dXuztvyXjfFgPbBlGP1VpcI/Fp9w/mg+rtbDvk=; b=NKgxDvNfz5pLP8XLPEGMRnOEr0zrxVEBD/hA2b1KgqE66T87EfySqZ9K2fJwCm4l65 KFzJHnL1mKBdNu3Ch+Tg/09oRjN1pJvrEEGNsRnJMXyD10Bzj/XGtDoWShb3x7gapLQZ y9tvCYlit6bq36LjazwZOn6pIZuN0KxIYiEPkRHeI1Te1+hJeKEDQVIbLqIb0SVj4ZlB kjOZrISL05h7LiHzs2pgq0IuaZiiI6YyXNVHjefNAf4J73tiugHxxphiAw86IXQZ2PHf Q4Re6Smn2LAZoTTm8JStXffzcBGY31BvGZ0HfjkcTmGJaea7k0ZkiJVUocZdeFgt23Js llLQ== X-Gm-Message-State: AD7BkJJ6QLT3W95qHTaqDMhPtKQNeMp0jTxNRoqL+YF50bTNydeqIlnVB/1kt+ERBmiGJMSytmxAbhttWRyZ0qSU X-Received: by 10.37.231.88 with SMTP id e85mr5138042ybh.137.1459812867119; Mon, 04 Apr 2016 16:34:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Mon, 04 Apr 2016 23:34:17 +0000 Message-ID: To: Hui Deng , "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a114a147e624bd5052fb12b02 Archived-At: Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 23:34:30 -0000 --001a114a147e624bd5052fb12b02 Content-Type: text/plain; charset=UTF-8 There is very little content in the draft (although it does have a very pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( https://datatracker.ietf.org/group/netconf/charter/) Those groups seem much more likely... W On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: > Hello all > > We have posted a submission this morning, apologize for late submission. > > https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt > > OPEN-O would intent to propose an open source project under Linux foundation. It > includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is > sitting on top of SDN Controller like ODL or ONOS and somewhere > below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document > is seeking for the relationship between open standard IETF and open > source project OPEN-O. > > thanks a lot for your kind review > > Best regards, > > DENG Hui > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a114a147e624bd5052fb12b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is very little content in the draft (although it doe= s have a very pretty ASCII art drawing), but I'm not sure why OpsAWG an= d not NFVRG (= https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG (https://datatracker.iet= f.org/group/sdnrg/charter/) or Netconf (https://datatracker.ietf.org/group/netconf= /charter/)=C2=A0

Those groups seem much more likely.= ..

W

On Mon, Apr 4, 2016 at 8:53 AM Hui Deng <denghui02@gmail.com> wrote:
Hello all

We have posted = a submission this morning, apologize for late submission.

https://www.ietf.org/id/draft-deng-o= psawg-nfvrg-sdnrg-openo-00.txt

OPEN-O would intent to pr=
opose an open source project under Linux foundation. It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
--001a114a147e624bd5052fb12b02-- From nobody Tue Apr 5 16:18:10 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C364B12D180 for ; Tue, 5 Apr 2016 16:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vkLPfChJHaQc for ; Tue, 5 Apr 2016 16:18:07 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 A4EF712D178 for ; Tue, 5 Apr 2016 16:18:06 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id vo2so19058211lbb.1 for ; Tue, 05 Apr 2016 16:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oyASLY60y1fblu06y3FjQn/TJ/pPtwjezZWVYmP4FlY=; b=ZCecNT83lqOJe3JLJD9MC2gmntEAV8ks6Q0javXgLLrEkCKkOqy53yKhbUGdUgyka6 0eqfzbIHvf3kMRFQu3M7pc1J1IHqYtxqDWb2+EAbMADJ3CfI6P6xh49DPajhiUtGoayw INWTSVGv5d0Nhcl7SQLqStc1bS5Lg/L9l5O8X/iWBW+3CDqHo1JGVbR9n1E9ROhKjx3s /e5/rLdrd5gjZ7r76cAKX7b80jPSBdDE0ACwL2FvNsOD3GS/MLLBYmqgRfUyWwSKIYdL t7KmDekZ/QtALA0Kg8N0OrlMikB8u90Yx2hrHW+a7+W69DNVj8IWUREpxJ+r0IHRE7NS qpHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oyASLY60y1fblu06y3FjQn/TJ/pPtwjezZWVYmP4FlY=; b=bTDSnfinlopZLjRF3BmRCDDx75cTcgFTDW4hl7tFGXx81xcdenq5knEjPImpM6E9Hd i0Mj5payCrUlHy5WuEG8gW2lkHpU+sgxfVYe4EMcSqws58bdyOhBBj3+P+StLFxY9UZ/ 9HAVfhIPmjmM00+jy5nrHypnjoA4KExDcY0W1xU8PkbyAjr2aIvDC8gneJwRiq3k3Hvo 0m6Bqa5hi0Qjo+GEAj/4d1165fpW2aHG7nViEKUQ/Iq+Joi+5gvFPavniT1Lmu1Ni6kG 4NGROV8xHKqA00ET9lfaTT9jZBG5GrlQTyyueBz5M2B1WXw8ONFf31yZbx859gDXw1Lb yUFg== X-Gm-Message-State: AD7BkJJL9tLf4mrNQG27Dg3T9KFpTxRktN8NiKgA8JK8wfCutme0mlTfRfr8Abxk0i7u84Fj37rFGVNQ6ZXUQA== MIME-Version: 1.0 X-Received: by 10.112.183.199 with SMTP id eo7mr8364552lbc.49.1459898284897; Tue, 05 Apr 2016 16:18:04 -0700 (PDT) Received: by 10.25.154.210 with HTTP; Tue, 5 Apr 2016 16:18:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Apr 2016 20:18:04 -0300 Message-ID: From: Hui Deng To: Warren Kumari Content-Type: multipart/alternative; boundary=001a113484dcadfcdf052fc50ed2 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 23:18:09 -0000 --001a113484dcadfcdf052fc50ed2 Content-Type: text/plain; charset=UTF-8 Hi Warren As you said, we do also contact with NFVRG and SDNRG about the draft. The reason coming to OPSAWG is to discuss about Yang related in OPS Area, because there are multiple WGs related to this like (NETCONF, NETMOD), so we approach OPSAWG for the simple way to proceed, thanks a lot for your consideration Best regards, DENG Hui 2016-04-04 20:34 GMT-03:00 Warren Kumari : > There is very little content in the draft (although it does have a very > pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( > https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( > https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( > https://datatracker.ietf.org/group/netconf/charter/) > > Those groups seem much more likely... > > W > > On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: > >> Hello all >> >> We have posted a submission this morning, apologize for late submission. >> >> https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt >> >> OPEN-O would intent to propose an open source project under Linux foundation. It >> includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is >> sitting on top of SDN Controller like ODL or ONOS and somewhere >> below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document >> is seeking for the relationship between open standard IETF and open >> source project OPEN-O. >> >> thanks a lot for your kind review >> >> Best regards, >> >> DENG Hui >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > --001a113484dcadfcdf052fc50ed2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Warren

As you said, we do also conta= ct with NFVRG and SDNRG about the draft.
The reason coming to OPS= AWG is to discuss about Yang related in OPS Area,
because there a= re multiple WGs related to this like (NETCONF, NETMOD),=C2=A0
so = we approach OPSAWG for the simple way to proceed,

= thanks a lot for your consideration
Best regards,

<= /div>
DENG Hui



2016-04-04 20:34 GMT-03:00 Warre= n Kumari <warren@kumari.net>:
There is very little content in the draft (although i= t does have a very pretty ASCII art drawing), but I'm not sure why OpsA= WG and not NFVRG (https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG (https://datatracker.ietf.org/group/sdnrg/charter/) or= Netconf (https://datatracker.ietf.org/group/netconf/charter/)= =C2=A0

Those groups seem much more likely...
<= br>
W

On Mon, Apr 4, 2016 at 8:53 AM Hui Deng <denghui02@gmail.com> wrote:=
Hello all

We have posted a submission = this morning, apologize for late submission.

https://www.ietf.org/id/draft-deng-opsawg-nfvrg-s= dnrg-openo-00.txt

OPEN-O would intent to propose an open=
 source project under Linux foundation. It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg

--001a113484dcadfcdf052fc50ed2-- From nobody Wed Apr 6 09:46:29 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610D112D588 for ; Wed, 6 Apr 2016 09:46:28 -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 U6XKyJt7rhhk for ; Wed, 6 Apr 2016 09:46:23 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5F812D566 for ; Wed, 6 Apr 2016 09:46:23 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id t10so64046287ywa.0 for ; Wed, 06 Apr 2016 09:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gfXAf+8adhaRc9q4Inswhu8YYvpgPi5GKUPmA4Ew88o=; b=q/OQ37UNHTepwgq1k96DSPUXfKruCoCng4bkuZen4+tMZXPEcNPV91L38fPf/AZnzH QUk3CsT3f2QHTmu9zrpY+7EuASxpjanK6LxM+mhBYE+0uYgFp/nk2jmwZ1/QW6HcOrML O8Ut1Q3XeyBHzfnsDtwBNdLfEox1eVIRW2JJvJo4ezvzYQ08Nro8smKk0NHlu1hMBAbD 1Vi6W9Ioq/J2M1GhQHHHG3Oqv073eT4kTJpYgWTkv5PpeZDvc5tDMJJQ3BE/YZEz0L+a U0ZYfZL9P6M2d+qTptRBdVNssLSg88S3xI88X98hbUbS+5e1GTUUbOooscmX0Vh8TUvF 3L5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gfXAf+8adhaRc9q4Inswhu8YYvpgPi5GKUPmA4Ew88o=; b=CfnTo27ueH5t77QmDYZr6JEUuA5j+5X804hP8R1h3AzLagM7jNvaw1P2uEwmmOvv5P H5EFf7opcqoFayMUXimckeeD7wKP57C4hbpo7XVwnQ1cLMFCL5I69dIhtKcW2YQi9lP1 W11HP0R+fhQGrXeQUvbXK6nhHi8bmvMKW1q/PkKwD5tptmHdYZdxFc7v/O9FLnfrzV7W njbHCx2yUlSyoVuTrUvcYIJ6dRmAA5cs++FzvMMkttLU/aONCAWhZoB0FQeEoMHzKEgP bReV3+9IEvRVFsnnD/UjHmjEVT2r7C9YXMefBw4ULBItsZ+mHqbQ8IqsgY6bjNXB5hpS bT8g== X-Gm-Message-State: AD7BkJKLc/l0FRYeTxS1yBq3dEnBIbtwbGuvIKVPMAb4FD/YzV2dfYKjBGlApwYW+klLyosPqgzRX/Tg14bDUg== MIME-Version: 1.0 X-Received: by 10.13.192.65 with SMTP id b62mr18032445ywd.113.1459961182408; Wed, 06 Apr 2016 09:46:22 -0700 (PDT) Received: by 10.13.209.198 with HTTP; Wed, 6 Apr 2016 09:46:22 -0700 (PDT) In-Reply-To: <81589497-305F-49DF-BACD-B3701902B285@deployingradius.com> References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> <017b01d16b34$d3c92020$4001a8c0@gateway.2wire.net> <81589497-305F-49DF-BACD-B3701902B285@deployingradius.com> Date: Wed, 6 Apr 2016 12:46:22 -0400 Message-ID: From: Christopher Morrow To: Alan DeKok Content-Type: multipart/alternative; boundary=001a114e6fdaa9d7af052fd3b395 Archived-At: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:46:28 -0000 --001a114e6fdaa9d7af052fd3b395 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B(I hate to resurrect an old thread. but)=E2=80=8B On Mon, Feb 22, 2016 at 10:37 AM, Alan DeKok wrote: > And since TACACS+ is largely used *within* the enterprise, the issue of > securing it is less relevant than (say) RADIUS, which is used across the > wider internet. =E2=80=8BThis is flat wrong. Tac+ is used across the wide-area, both within= a single routing administrative domain (Autonomous system, single company network) and wit=E2=80=8Bhout. -chris --001a114e6fdaa9d7af052fd3b395 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B(I hate to resurrect an old thread. but)= =E2=80=8B

On Mon, Feb 22, 2016 at 10:37= AM, Alan DeKok <aland@deployingradius.com> wrote:
=C2=A0 And since TACACS+ is largely used *= within* the enterprise, the issue of securing it is less relevant than (say= ) RADIUS, which is used across the wider internet.

=E2=80=8BThis is flat = wrong. Tac+ is used across the wide-area, both within a single routing admi= nistrative domain (Autonomous system, single company network) and wit=E2=80= =8Bhout.

-chris

=
--001a114e6fdaa9d7af052fd3b395-- From nobody Wed Apr 6 10:26:25 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DC812D6E3 for ; Wed, 6 Apr 2016 10:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kyy8x46cflrj for ; Wed, 6 Apr 2016 10:26:08 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 23CEF12D6DB for ; Wed, 6 Apr 2016 10:25:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 5AF3B1C48; Wed, 6 Apr 2016 17:25:58 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKJzDFsM5rYP; Wed, 6 Apr 2016 17:25:58 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id C70471B18; Wed, 6 Apr 2016 17:25:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Wed, 6 Apr 2016 13:26:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <606A13DC-0438-42C5-82C2-496D5EA8C2C2@deployingradius.com> References: <049bf48d-64db-91ba-b13c-1aa021e4f7ac@bogus.com> <56C65A2A.1050304@gmail.com> <017b01d16b34$d3c92020$4001a8c0@gateway.2wire.net> <81589497-305F-49DF-BACD-B3701902B285@deployingradius.com> To: Christopher Morrow X-Mailer: Apple Mail (2.3112) Archived-At: Cc: IETF OOPSAWG Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:26:20 -0000 > On Apr 6, 2016, at 12:46 PM, Christopher Morrow = wrote: >=20 > =E2=80=8B(I hate to resurrect an old thread. but)=E2=80=8B >=20 > On Mon, Feb 22, 2016 at 10:37 AM, Alan DeKok = wrote: > And since TACACS+ is largely used *within* the enterprise, the issue = of securing it is less relevant than (say) RADIUS, which is used across = the wider internet. >=20 > =E2=80=8BThis is flat wrong. Tac+ is used across the wide-area, both = within a single routing administrative domain (Autonomous system, single = company network) As I said. > and wit=E2=80=8Bhout. That which is asserted without evidence can be dismissed without = evidence. I'll note that the existing document doesn't describe this scenario at = all. So you're asserting (again) that we should be standardizing = TACACS+ because of use-cases which are so important that they're not = even mentioned in the document. Or on this mailing list, so far as I've = been able to find. I find blind assertions entirely unconvincing. Alan DeKok. From nobody Wed Apr 6 10:45:18 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17B312D6D2 for ; Wed, 6 Apr 2016 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 yTcvyt4D2-lI for ; Wed, 6 Apr 2016 10:45:15 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 16DBA12D164 for ; Wed, 6 Apr 2016 10:45:15 -0700 (PDT) Received: by mail-lb0-x22f.google.com with SMTP id bk9so7497422lbc.3 for ; Wed, 06 Apr 2016 10:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=H/DeQZH0vU3kkFpzSfwVTCFug3SvPeH07eYCGrdoY6c=; b=oUn9Y2dGOTWKAYuHQcIMNkdd9kpSbIVK4JQarsyTbVmzDtDGPlmGXuoGuRg2K+XzmE 54voJVaVnlOR50qEwXDZ6wH+ziiJvNiBChHVP+EHA8+c9VPI57LjAcVplulUrKmEz5xL iz4xg0qBr4LncwOgvPi9R8JuLClk+zVHfnPgNyq2naTgSxlcd3qfKdEq/SYo9EsVImee fDY60ITmbMjdoxaks6Ea8uEPQ8jNdC2K2DIlEP96uPtPddhjvJG7HTKYolE76VrGv2LF enlEIxcNrXqE6BocD93HcZRrGhz5BQZ6Qn4BGQGn/4qwytOmqF+N0a3WDBqwdmKPNcHx TylA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=H/DeQZH0vU3kkFpzSfwVTCFug3SvPeH07eYCGrdoY6c=; b=Sgf6TQN6NFAn2+BfWhcoV2QxgXBXEJ88bwLvrWAzRaGJtGRzMITOL13mHYUcfP2Qya kjXZt2CV0n9/B4ueN1qGB05cZCDogYwAZZ2ceOSzYZUJIHm9LfKY/XQZqMazHZZqCBm2 L6XqyUNvnurb5tbN/oei+hZrndbqCAQA7WuQPdYyUj2tjHYxlEYtc5kqAoV25wBw+C/q sW8TWgAtCX+JQApxBh86gYN+j1tko1sqwfG9FXfiNqlJGw65IBVEePBKDRkroovea4ME JoVKJOQHHZzTeS8gYiXoCGVU1oEU+1fZObRw/wxfL6bNlVORU9EJZvwTJMDY1PFa8HXr BbZw== X-Gm-Message-State: AD7BkJJvUZBDpekRikQjR52HiVJf8LwDhnshleAt3jwRdV+hy8wefaXeVuCbcI8vsd3vV1CLqcrqHH3Ld17nSA== MIME-Version: 1.0 X-Received: by 10.112.64.6 with SMTP id k6mr2908745lbs.50.1459964713290; Wed, 06 Apr 2016 10:45:13 -0700 (PDT) Received: by 10.25.154.210 with HTTP; Wed, 6 Apr 2016 10:45:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2016 14:45:13 -0300 Message-ID: From: Hui Deng To: Warren Kumari Content-Type: multipart/alternative; boundary=001a11c3ff501ed4c4052fd486e8 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:45:17 -0000 --001a11c3ff501ed4c4052fd486e8 Content-Type: text/plain; charset=UTF-8 Can I treat no reply means "No", thanks a lot for chair's reply, that could save me time to work on useless preparation. Best regards, DENG Hui 2016-04-05 20:18 GMT-03:00 Hui Deng : > Hi Warren > > As you said, we do also contact with NFVRG and SDNRG about the draft. > The reason coming to OPSAWG is to discuss about Yang related in OPS Area, > because there are multiple WGs related to this like (NETCONF, NETMOD), > so we approach OPSAWG for the simple way to proceed, > > thanks a lot for your consideration > Best regards, > > DENG Hui > > > > 2016-04-04 20:34 GMT-03:00 Warren Kumari : > >> There is very little content in the draft (although it does have a very >> pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( >> https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( >> https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( >> https://datatracker.ietf.org/group/netconf/charter/) >> >> Those groups seem much more likely... >> >> W >> >> On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: >> >>> Hello all >>> >>> We have posted a submission this morning, apologize for late submission. >>> >>> https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt >>> >>> OPEN-O would intent to propose an open source project under Linux foundation. It >>> includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is >>> sitting on top of SDN Controller like ODL or ONOS and somewhere >>> below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document >>> is seeking for the relationship between open standard IETF and open >>> source project OPEN-O. >>> >>> thanks a lot for your kind review >>> >>> Best regards, >>> >>> DENG Hui >>> >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>> >> > --001a11c3ff501ed4c4052fd486e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can I treat no reply means "No", thanks a lot fo= r chair's reply,=C2=A0
that could save me time to work on useless p= reparation.

Best regards,

DENG = Hui

2016-04-05 20:18 GMT-03:00 Hui Deng <denghui02@gmail.com>:
Hi Warren

<= /div>
As you said, we do also contact with NFVRG and SDNRG about the dr= aft.
The reason coming to OPSAWG is to discuss about Yang related= in OPS Area,
because there are multiple WGs related to this like= (NETCONF, NETMOD),=C2=A0
so we approach OPSAWG for the simple wa= y to proceed,

thanks a lot for your consideration<= /div>
Best regards,

DENG Hui



2016-04-04 20:34 GMT-03:00 = Warren Kumari <warren@kumari.net>:
There is very little content in the draft (althou= gh it does have a very pretty ASCII art drawing), but I'm not sure why = OpsAWG and not NFVRG (https://datatracker.ietf.org/group/nfvrg/charter= /) or SDNRG (https://datatracker.ietf.org/group/sdnrg/charter/= ) or Netconf (https://datatracker.ietf.org/group/netconf/charter/)=C2=A0

Those groups seem much more likely...

W

Hello = all

We have posted a submission this morning, apologize = for late submission.

https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt

OPEN-O would intent to propose an open source project under Li=
nux foundation. It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg


--001a11c3ff501ed4c4052fd486e8-- From nobody Wed Apr 6 11:17:09 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C69712D158 for ; Wed, 6 Apr 2016 11:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gmlwjTVdZs5e for ; Wed, 6 Apr 2016 11:17:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC25512D0E1 for ; Wed, 6 Apr 2016 11:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1938; q=dns/txt; s=iport; t=1459966626; x=1461176226; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=0BLT1a8+4+O02OQhR818LatPZ52b8iVPtNdDgHrRTeU=; b=jmfqdHOv6TmSaPfetQWrr6GmspUwlXyiABcALrXUJbuvFnyeswxXlkGP HEZDnEWYZ5r/ZROeRY2Rx0+pga0XC0TZCGqvN+RNcNJlEr8lMuu5puPYx 4m8f3octne0BSuoLivSHo2HXuLR173GTiTOwhBUGPWrI+QWa07G/beXAG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgA3UgVX/5JdJa1SCoM3UwO5N4IPA?= =?us-ascii?q?Q2BcyGFbAKBTjgUAQEBAQEBAWUnhEIBAQQdGzwEEQsYCRYPCQMCAQIBRQYBDAg?= =?us-ascii?q?BAYgjDsEiAQEBAQEBAQEBAQEBAQEBAQEVBIYhg0mBAoQVhgABBJgBhXaIFYk5h?= =?us-ascii?q?VWPIR4BAUKEAyCJIwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="93613225" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2016 18:17:05 +0000 Received: from [10.24.131.193] ([10.24.131.193]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u36IH4KJ004824; Wed, 6 Apr 2016 18:17:05 GMT To: Petr Lapukhov , "opsawg@ietf.org" References: <3F437107848A5140A6A19222EFFB3481200F061D@PRN-MBX01-2.TheFacebook.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <5705529E.4020700@cisco.com> Date: Wed, 6 Apr 2016 14:17:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3F437107848A5140A6A19222EFFB3481200F061D@PRN-MBX01-2.TheFacebook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Call for Agenda Items for Buenos Aires X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:17:08 -0000 On 3/18/16 09:41, Petr Lapukhov wrote: > Folks, > > If possible I would like to request a slot on the agenda to present > > https://datatracker.ietf.org/doc/draft-lapukhov-dataplane-probe/ > > This to start work on in-band telemetry format standardization. The > technology is still at early stages, and I believe it would be helpful > to agree on common formats to be used across multiple silicon vendors. > > Looking for feedback and finding a best place to continue this work at. Petr, I was going to ask these in the meeting, but given the number of questions, I thought it better to ask on the list. * How do you propose the populated data to be handled normally? Will the probe destination (i.e., the dest address of the UDP packet) be expected to understand these, or will loopback mode have to be used? The reason I ask is that I'm not sure what happens if all nodes in the network do not support this probe. Could this give more network insight to the destination, and thus be a security weakness? * Related to the question above what would happen if a set a hop count of four, but the fourth device (before my destination) has not awareness of this telemetry system? * Why not use ifIndex values for port IDs? It seems to me that having a more standard and known cross-vendor way to identify ports is useful. * You do not list IANA considerations, but it seems to me that your probe types would be well-suited for a registry that perhaps could live with IANA? It would also be useful to have some reserved space for private extensions where possible. * I think you mentioned it at the mic, but the draft doesn't really address what happens if a device supports this telemetry system, but does not support a specific probe type? For example, what if I define type 50 down the road, but not all of my devices/hardware yet support this? What happens then? Joe From nobody Wed Apr 6 11:21:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C385112D645 for ; Wed, 6 Apr 2016 11:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 A9LWYt7TXg93 for ; Wed, 6 Apr 2016 11:21:43 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7986A12D158 for ; Wed, 6 Apr 2016 11:21:43 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g3so67322314ywa.3 for ; Wed, 06 Apr 2016 11:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PFgpT1XhHy7R90GZvPYUw5pDzV6S4iWNSncWAfNROK4=; b=hkEc9H6nibvFWfEZXW5b1RILfB+2xpbodg1TyJfMItBl4TqcC+b2Kfx0g+HZ+LnHBT TBJJmmulqeVVSfGdZiX4A1z8+TqiauCpBN7F43kGwa+8qNoQ6uI5xNLAjn6dKvzyls7E S1a62Vh+fBAKPhVZ9sp8G06jZm97RFOu9zVFJ3d1xaMv43OgphpfRWuoAazG8mCWXnYD g2c2v04HNbgY/Wgja9SQc4sEGZYh3s4ulOuhhP1FGdJngi2JavEntnJcUhlRmvCVaPe5 qrXIycKdcObx+zZuHYNh0SzFkZikNokoz16rVz2bJc0bOA8ozznn2BZQpzbeNBZvRPIo L8Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PFgpT1XhHy7R90GZvPYUw5pDzV6S4iWNSncWAfNROK4=; b=Hb2CU5t/LTnia6IkO8L9GjUQpdYOGs2Gara7HIUFokqgK0+0N900oawVFWsnu0765Y 6fpMmO9YHQfYDVKki3rG/+/V1wqDvP8IFNqvJg4ANtzwkf3TsWAbaKO1cXd8gCeX7VcI 7NJ5aWuo9R+cfS3Rd2Bpr7MDY8LLL27U1lFx8/zh+T38kKwBjCY1/oBbVi6DND+UYmL7 DKHMDOxbMK/9sWFPf7+eXPJRY/yvDIU/YDtyw/Estkg3nyGxXu91ebIY3LGCl1Bvin4w /9Tmw0TJ7+UbQCPAnJgRBgaOuAwDgkgJ4KykOzxUzDW+xleaJmWVmrSF3E1wT7d3SNsL CbFA== X-Gm-Message-State: AD7BkJL0wFiLnIk78jBNsp1ftEf2NwX37MzvFGBXdUliqrZVWVDs8QRJ0qQ+JCfMElXi7gOGNuBjdKj6eVZoNUmB X-Received: by 10.13.227.1 with SMTP id m1mr27499488ywe.249.1459966902714; Wed, 06 Apr 2016 11:21:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Wed, 06 Apr 2016 18:21:33 +0000 Message-ID: To: Hui Deng Content-Type: multipart/alternative; boundary=94eb2c07d0fa9f0436052fd50809 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:21:45 -0000 --94eb2c07d0fa9f0436052fd50809 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 6, 2016 at 2:45 PM Hui Deng wrote: > Can I treat no reply means "No", thanks a lot for chair's reply, > that could save me time to work on useless preparation. > It is currently a No. The current document has almost no detail. I think the right thing to do is: 1: flesh out the document so that there is content / protein. 2: discuss it in NFVRG / SDNRG, once there is support OpsAWG might be the place for a yang discussion / how this integrates with other things, etc. W > > Best regards, > > DENG Hui > > 2016-04-05 20:18 GMT-03:00 Hui Deng : > >> Hi Warren >> >> As you said, we do also contact with NFVRG and SDNRG about the draft. >> The reason coming to OPSAWG is to discuss about Yang related in OPS Area, >> because there are multiple WGs related to this like (NETCONF, NETMOD), >> so we approach OPSAWG for the simple way to proceed, >> >> thanks a lot for your consideration >> Best regards, >> >> DENG Hui >> >> >> >> 2016-04-04 20:34 GMT-03:00 Warren Kumari : >> >>> There is very little content in the draft (although it does have a very >>> pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( >>> https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( >>> https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( >>> https://datatracker.ietf.org/group/netconf/charter/) >>> >>> Those groups seem much more likely... >>> >>> W >>> >>> On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: >>> >>>> Hello all >>>> >>>> We have posted a submission this morning, apologize for late submission. >>>> >>>> https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt >>>> >>>> OPEN-O would intent to propose an open source project under Linux foundation. It >>>> includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is >>>> sitting on top of SDN Controller like ODL or ONOS and somewhere >>>> below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document >>>> is seeking for the relationship between open standard IETF and open >>>> source project OPEN-O. >>>> >>>> thanks a lot for your kind review >>>> >>>> Best regards, >>>> >>>> DENG Hui >>>> >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg >>>> >>> >> > --94eb2c07d0fa9f0436052fd50809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , Apr 6, 2016 at 2:45 PM Hui Deng <denghui02@gmail.com> wrote:
Can I treat no reply means "No", thanks a lot = for chair's reply,=C2=A0
that could save me time to work on useless= preparation.

It is currently a= No.=C2=A0

The current document has almost no deta= il. I think the right thing to do is:
1: flesh out the document s= o that there is content / protein.=C2=A0
2: discuss it in NFVRG /= SDNRG, once there is support OpsAWG might be the place for a yang discussi= on / how this integrates with other things, etc.

W=
=C2=A0

Best regards,

DENG Hui
<= /div>

2016-0= 4-05 20:18 GMT-03:00 Hui Deng <denghui02@gmail.com>:
Hi Warren

= As you said, we do also contact with NFVRG and SDNRG about the draft.
=
The reason coming to OPSAWG is to discuss about Yang related in OPS Ar= ea,
because there are multiple WGs related to this like (NETCONF,= NETMOD),=C2=A0
so we approach OPSAWG for the simple way to proce= ed,

thanks a lot for your consideration
= Best regards,

DENG Hui


2016-04-04 20:34 GMT-03:00 Warren Kumari <warren@kumari.net>= :
There is very l= ittle content in the draft (although it does have a very pretty ASCII art d= rawing), but I'm not sure why OpsAWG and not NFVRG (https://datatr= acker.ietf.org/group/nfvrg/charter/) or SDNRG (https://datatracker= .ietf.org/group/sdnrg/charter/) or Netconf (https://datatracker.= ietf.org/group/netconf/charter/)=C2=A0

Those groups = seem much more likely...

W

On Mon, Apr 4, 2016 at 8:53 AM Hui De= ng <denghui02@g= mail.com> wrote:
Hello all

We have posted a s= ubmission this morning, apologize for late submission.

https://www.ietf.org/id/draft-deng-opsa= wg-nfvrg-sdnrg-openo-00.txt

OPEN-O would intent to propo=
se an open source project under Linux foundation. It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg


--94eb2c07d0fa9f0436052fd50809-- From nobody Wed Apr 6 11:52:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2256C12D115 for ; Wed, 6 Apr 2016 11:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-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 V6GE_SHCEMa6 for ; Wed, 6 Apr 2016 11:52:23 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F23012D0C6 for ; Wed, 6 Apr 2016 11:52:22 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id j11so40493627lfb.1 for ; Wed, 06 Apr 2016 11:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=abCY/w3iQ8j1XXy3oQyETgoPMbN0O8OXcuKpgyEFjcQ=; b=2E7F5Yu7oHuXxZQvlrNFrPV0eSBKScyiHRsEgRrMRzd36Bv2hJGyAXoPfuA+dsptH1 6aNPlU+xIzz3OfNWP7twDbPphhIq/bg2jUsBsoN44gJwe0gCQj1ubo4GKd5fFyA4WQxF FecElw7bl6xo7eU/T6Hw7yb/wAHwbHnDf2BxND42m+ziQ0j/sDExARvlFgKIc6V2Umjl VYnoe5naJ11u8JdGIL9wfCMHFSnOP62w4fsAzg62eMxiR+kt99h4bYXsieRe1osYXr/J xwhGubMxP1aojlpNac0US6RVM1xD3npD5028Cs9Wa/OR2RdLnzqo+/W4zA1oIYjqnu8H o4DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=abCY/w3iQ8j1XXy3oQyETgoPMbN0O8OXcuKpgyEFjcQ=; b=DLrrAY4fPlyIgWW6wLTDFlBbvVJ18vQerORVvWrzxgskmlQQLFCZveIHqcs+2udd/w g9O30Sl5UW8T67quT7G8CJbWzHt00gkN3CMQ2CGou1htcx/1SuFKua4MLKGqEEn53+/2 nCfQwGIGthEf4gajCY5TUmVWvayHwjT8MIMwq7KBT6OKimsFp1JyVfZkKyzqtMglSoSE 5MsLGABQMdHmqnG5fVDJrU0KwynZDDYFUjaqtImITSSCgZ/0ONL2Gy9TnywRwBYr1rGc VvVryy/OuoE9n3DkGfWO0sMHTTRw+U+2ar8OFEIS6uWzXG2wUQUh+nYisRmQjKMNyOlc fmsw== X-Gm-Message-State: AD7BkJKXKKwCcdNYKkgmwOFm/TGFF7247le5Y1bfLQP31PNt5MC+tCk+j3n6oxdknokn8K83IlCG8HD8VuBoMQ== MIME-Version: 1.0 X-Received: by 10.25.85.145 with SMTP id j139mr10528107lfb.131.1459968740581; Wed, 06 Apr 2016 11:52:20 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Wed, 6 Apr 2016 11:52:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2016 11:52:20 -0700 Message-ID: From: Andy Bierman To: Warren Kumari Content-Type: multipart/alternative; boundary=001a114059362a7a0c052fd57685 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:52:25 -0000 --001a114059362a7a0c052fd57685 Content-Type: text/plain; charset=UTF-8 Hi, I have a stronger opinion... IMO the IETF is not in the open-source business and has no official role to play in open-source. You should come to the IETF with very specific requests that you want addressed in the standards. Andy On Wed, Apr 6, 2016 at 11:21 AM, Warren Kumari wrote: > > > On Wed, Apr 6, 2016 at 2:45 PM Hui Deng wrote: > >> Can I treat no reply means "No", thanks a lot for chair's reply, >> that could save me time to work on useless preparation. >> > > It is currently a No. > > The current document has almost no detail. I think the right thing to do > is: > 1: flesh out the document so that there is content / protein. > 2: discuss it in NFVRG / SDNRG, once there is support OpsAWG might be the > place for a yang discussion / how this integrates with other things, etc. > > W > > >> >> Best regards, >> >> DENG Hui >> >> 2016-04-05 20:18 GMT-03:00 Hui Deng : >> >>> Hi Warren >>> >>> As you said, we do also contact with NFVRG and SDNRG about the draft. >>> The reason coming to OPSAWG is to discuss about Yang related in OPS Area, >>> because there are multiple WGs related to this like (NETCONF, NETMOD), >>> so we approach OPSAWG for the simple way to proceed, >>> >>> thanks a lot for your consideration >>> Best regards, >>> >>> DENG Hui >>> >>> >>> >>> 2016-04-04 20:34 GMT-03:00 Warren Kumari : >>> >>>> There is very little content in the draft (although it does have a very >>>> pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( >>>> https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( >>>> https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( >>>> https://datatracker.ietf.org/group/netconf/charter/) >>>> >>>> Those groups seem much more likely... >>>> >>>> W >>>> >>>> On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: >>>> >>>>> Hello all >>>>> >>>>> We have posted a submission this morning, apologize for late >>>>> submission. >>>>> >>>>> https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt >>>>> >>>>> OPEN-O would intent to propose an open source project under Linux foundation. It >>>>> includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is >>>>> sitting on top of SDN Controller like ODL or ONOS and somewhere >>>>> below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document >>>>> is seeking for the relationship between open standard IETF and open >>>>> source project OPEN-O. >>>>> >>>>> thanks a lot for your kind review >>>>> >>>>> Best regards, >>>>> >>>>> DENG Hui >>>>> >>>>> _______________________________________________ >>>>> OPSAWG mailing list >>>>> OPSAWG@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>>> >>>> >>> >> > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --001a114059362a7a0c052fd57685 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a stronger opinion...
<= div>IMO the IETF is not in the open-source business and has no
of= ficial role to play in open-source.=C2=A0 You should come to the
= IETF with very specific requests that you want addressed
in the s= tandards.

Andy


On Wed, Apr 6, 2016 at 11:= 21 AM, Warren Kumari <warren@kumari.net> wrote:


<= div dir=3D"ltr">On Wed, Apr 6, 2016 at 2:45 PM Hui Deng <denghui02@gmail.com> wrote= :
Can I treat no r= eply means "No", thanks a lot for chair's reply,=C2=A0
th= at could save me time to work on useless preparation.

It is currently a No.=C2=A0

The current document has almost no detail. I think the right thing to do i= s:
1: flesh out the document so that there is content / protein.= =C2=A0
2: discuss it in NFVRG / SDNRG, once there is support OpsA= WG might be the place for a yang discussion / how this integrates with othe= r things, etc.

W
=C2=A0

Best regards,=

DENG Hui

2016-04-05 20:18 GMT-03:00 Hui Deng <= denghui02@gmail.com>:
Hi Warren

As you said, we do also contact wi= th NFVRG and SDNRG about the draft.
The reason coming to OPSAWG i= s to discuss about Yang related in OPS Area,
because there are mu= ltiple WGs related to this like (NETCONF, NETMOD),=C2=A0
so we ap= proach OPSAWG for the simple way to proceed,

thank= s a lot for your consideration
Best regards,

=
DENG Hui



2016-04-04 20:34 GMT-03:00 = Warren Kumari <warren@kumari.net>:
There is very little content in the draft (althou= gh it does have a very pretty ASCII art drawing), but I'm not sure why = OpsAWG and not NFVRG (https://datatracker.ietf.org/group/nfvrg/charter= /) or SDNRG (https://datatracker.ietf.org/group/sdnrg/charter/= ) or Netconf (https://datatracker.ietf.org/group/netconf/charter/)=C2=A0

Those groups seem much more likely...

W

Hello = all

We have posted a submission this morning, apologize = for late submission.

https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt

OPEN-O would intent to propose an open source project under Li=
nux foundation. It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg



_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


--001a114059362a7a0c052fd57685-- From nobody Wed Apr 6 11:55:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1471512D18B for ; Wed, 6 Apr 2016 11:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 O1wVTR8vdj1l for ; Wed, 6 Apr 2016 11:55:19 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 13A2512D0E2 for ; Wed, 6 Apr 2016 11:55:19 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id c126so40761537lfb.2 for ; Wed, 06 Apr 2016 11:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cxPzr9llIvEdEo6OKy00jRgeL97QMRar6mRqNgK7E40=; b=FHhaU2hesma2OsO4w1APPPOXkbJNHG/JxlmfdEaIPr4bJxUoaXlKNF6FPW4KpJT7GS j8zFaFfhPFrDvjxpEPH/5YmGaVGK5scBUYXegHR0I4LmqUyVoy2zlClBmN1WeXw5g1Yt 1FlLhnCNePLFefNHCoaD7i9oW6mFQ/D9tnINgEzo+sO7bu5VwjIWrfK3iIywTZMOUltM 0/1ZEzn90g7KwHT8UZAZwPrZaZDUlQzwBqu6j0DpoCFcx0S3geRkSEyJhgzuMZr8EqGF AGm+BHUoA1xcr2ZQz1CMyEp6XBWUh4RLoX8mIXqBInVTEtH+14NphZju+XQjjKCB6DSS FjXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cxPzr9llIvEdEo6OKy00jRgeL97QMRar6mRqNgK7E40=; b=gq68CGKgMQJGH3lq3jY91JJRC3XdyZfe7By4WNILpk1O02ooJ+yCGk7ZCtli8wcGOL TLttPYUEBBCMY6fO/3xTHU4JMXBRVVCa+b8z9fkUu8+ZHhzqQlPbCRCerD9M5DLbbcFh iN0o+YH6Lt2t+1it/R/xsGNCqzjqQ7hHLX4vQZO4fE1mcidD1Hwz2gZYzs5vh6hQcNNG 26MV0kMOOEW5Yfe0bmRm/KUn+TMtcs41ojMZh8O+slX7/ecfuzDu6fqNFCikgjWK8842 6ighTXNxYd2eMyFKfQ3gPQFgHcjkmvhlkNh9/v3CY09uqDNIdWiUscogUul1dlYsgVqE LBPA== X-Gm-Message-State: AD7BkJJbPLr0eZZydXZMeviilLZ4OvuvgCMLbl+/v9aykZoDnmHRVawOrU/Av4lbDNeVY/UYJX3STGHXAxmDog== MIME-Version: 1.0 X-Received: by 10.25.205.205 with SMTP id d196mr9497799lfg.30.1459968917148; Wed, 06 Apr 2016 11:55:17 -0700 (PDT) Received: by 10.25.154.210 with HTTP; Wed, 6 Apr 2016 11:55:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2016 15:55:17 -0300 Message-ID: From: Hui Deng To: Warren Kumari Content-Type: multipart/alternative; boundary=001a11412194b0a5be052fd58075 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:55:22 -0000 --001a11412194b0a5be052fd58075 Content-Type: text/plain; charset=UTF-8 Thank you for letting us know after we asked, we must be not clear before. We thought the architecture diagram shows some detail and content, maybe different people has different opinion. Anyhow we will try to work in other place first. thanks a lot for your advice DENG Hui 2016-04-06 15:21 GMT-03:00 Warren Kumari : > > > On Wed, Apr 6, 2016 at 2:45 PM Hui Deng wrote: > >> Can I treat no reply means "No", thanks a lot for chair's reply, >> that could save me time to work on useless preparation. >> > > It is currently a No. > > The current document has almost no detail. I think the right thing to do > is: > 1: flesh out the document so that there is content / protein. > 2: discuss it in NFVRG / SDNRG, once there is support OpsAWG might be the > place for a yang discussion / how this integrates with other things, etc. > > W > > >> >> Best regards, >> >> DENG Hui >> >> 2016-04-05 20:18 GMT-03:00 Hui Deng : >> >>> Hi Warren >>> >>> As you said, we do also contact with NFVRG and SDNRG about the draft. >>> The reason coming to OPSAWG is to discuss about Yang related in OPS Area, >>> because there are multiple WGs related to this like (NETCONF, NETMOD), >>> so we approach OPSAWG for the simple way to proceed, >>> >>> thanks a lot for your consideration >>> Best regards, >>> >>> DENG Hui >>> >>> >>> >>> 2016-04-04 20:34 GMT-03:00 Warren Kumari : >>> >>>> There is very little content in the draft (although it does have a very >>>> pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( >>>> https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( >>>> https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( >>>> https://datatracker.ietf.org/group/netconf/charter/) >>>> >>>> Those groups seem much more likely... >>>> >>>> W >>>> >>>> On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: >>>> >>>>> Hello all >>>>> >>>>> We have posted a submission this morning, apologize for late >>>>> submission. >>>>> >>>>> https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt >>>>> >>>>> OPEN-O would intent to propose an open source project under Linux foundation. It >>>>> includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is >>>>> sitting on top of SDN Controller like ODL or ONOS and somewhere >>>>> below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document >>>>> is seeking for the relationship between open standard IETF and open >>>>> source project OPEN-O. >>>>> >>>>> thanks a lot for your kind review >>>>> >>>>> Best regards, >>>>> >>>>> DENG Hui >>>>> >>>>> _______________________________________________ >>>>> OPSAWG mailing list >>>>> OPSAWG@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>>> >>>> >>> >> --001a11412194b0a5be052fd58075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for letting us know after we asked, we must be n= ot clear before.

We thought the architecture diagram sho= ws some detail and content, maybe different people has different opinion.
Anyhow we will try to work in other place first.

thanks a lot for your advice

DENG Hui

2016-04-06= 15:21 GMT-03:00 Warren Kumari <warren@kumari.net>:


On Wed, Apr 6, 2016 at 2:45 PM Hui Den= g <denghui02@gm= ail.com> wrote:
Can I treat no reply means "No", thanks a lot for chair'= s reply,=C2=A0
that could save me time to work on useless preparation.<= /div>

It is currently a No.=C2= =A0

The current document has almost no detail. I t= hink the right thing to do is:
1: flesh out the document so that = there is content / protein.=C2=A0
2: discuss it in NFVRG / SDNRG,= once there is support OpsAWG might be the place for a yang discussion / ho= w this integrates with other things, etc.

W
=C2=A0

Best regards,

DENG Hui

2016= -04-05 20:18 GMT-03:00 Hui Deng <denghui02@gmail.com>:
=
Hi Warren

As you said, we do also contact with NFVRG and SDNRG about the draft.
The reason coming to OPSAWG is to discuss about Yang related in OPS = Area,
because there are multiple WGs related to this like (NETCON= F, NETMOD),=C2=A0
so we approach OPSAWG for the simple way to pro= ceed,

thanks a lot for your consideration
Best regards,

DENG Hui

=

2016-04-04 20:34 GMT-03:00 Warren Kumari <warren@kumari.net&g= t;:
There is very= little content in the draft (although it does have a very pretty ASCII art= drawing), but I'm not sure why OpsAWG and not NFVRG (https://data= tracker.ietf.org/group/nfvrg/charter/) or SDNRG (https://datatrack= er.ietf.org/group/sdnrg/charter/) or Netconf (https://datatracke= r.ietf.org/group/netconf/charter/)=C2=A0

Those group= s seem much more likely...

W

On Mon, Apr 4, 2016 at 8:53 AM Hui = Deng <denghui02= @gmail.com> wrote:
Hello all

We have posted a= submission this morning, apologize for late submission.

https://www.ietf.org/id/draft-deng-op= sawg-nfvrg-sdnrg-openo-00.txt

OPEN-O would intent to pro=
pose an open source project under Linux foundation. It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg



--001a11412194b0a5be052fd58075-- From nobody Wed Apr 6 11:59:39 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9712D13D for ; Wed, 6 Apr 2016 11:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 u_TvGPjlDY12 for ; Wed, 6 Apr 2016 11:59:35 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4456212D0E2 for ; Wed, 6 Apr 2016 11:59:35 -0700 (PDT) Received: by mail-lb0-x22b.google.com with SMTP id vo2so35938701lbb.1 for ; Wed, 06 Apr 2016 11:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=v8QQzMFRyTGjkD9KZEeyYTR1ANW0kdSjEiLRmdienF8=; b=opC1bjQW1UU5C5MCqbJhmfap+7RMyzW/fhsUAoyEVBkHPeSgTxh8zTjO6hJgtfkZsO bhAYVIr2JLxTFP4K+DkoD6d8CjF9OYGRMBMgn7FF6Z06DA8oilsOmiSmNcSm2PvAlj9L kfWjeo2p4cWJh7M8gtL6v/koJLRAby9/gqYBFUmH4wSdAtJU4WEylCabtUH5thDluD5M lX2w7dYhSBKw96jbJBPfwDM5+slRuVGDFXxyGJ9iAveu0ier9yZ4dt1cFbBpn3sqRXTc AWFlR5JY7n1w+1XxMo7uCJlYuhObtbscbaZpyhWeox7GOeeXmizR0MgsivmtlJLZmmve 5Y+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=v8QQzMFRyTGjkD9KZEeyYTR1ANW0kdSjEiLRmdienF8=; b=Pa26Aq6po5kcLJvJEeqk8C1FJlMHGpoh289UL5PVpcs9Ae5ofsKkQgrRaRmA3n5vTk JomEmQAZWekD/1IT8ixEuGwvJuFeb/t4jrLOvCqYuHwxsnNGugeA4TgTzwQ91c52rEDW XoLb+5rAgkl55x0cBthJOgC/cpg75HeOfGzgeHgelTyEFY+JOFQDRG0iUXOBKPeMwBSC o3feGZg1jJlYuDEMKB2n+E6vXddPML2MXgZEFVCnxyayFjI7Z3O6s/FopoqV49NvPnlw pxxD7m4tzxXBO/AzGfsD0J2qko1FAWkOW2oXv3I+PUwwYGcDiK/Bm4TUTknXH5ZGXA7r EpqQ== X-Gm-Message-State: AD7BkJLoFOl+AQTHY9S3WYDdUoHwwQOB/Q3sj8OyqppOQVQAU00s6J8iRbWLkR/2G0eyC5LYXhqkIn7gGmbiKw== MIME-Version: 1.0 X-Received: by 10.112.30.163 with SMTP id t3mr11252183lbh.15.1459969173408; Wed, 06 Apr 2016 11:59:33 -0700 (PDT) Received: by 10.25.154.210 with HTTP; Wed, 6 Apr 2016 11:59:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2016 15:59:33 -0300 Message-ID: From: Hui Deng To: Andy Bierman Content-Type: multipart/alternative; boundary=001a11336424f6d296052fd58f20 Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:59:38 -0000 --001a11336424f6d296052fd58f20 Content-Type: text/plain; charset=UTF-8 I see that open standard is working together with open source today, just like OPSArea presentation today. People are seeking for the cooperation, it doesn't mean open source is superior than open standard, or vice versa 2016-04-06 15:52 GMT-03:00 Andy Bierman : > Hi, > > I have a stronger opinion... > IMO the IETF is not in the open-source business and has no > official role to play in open-source. You should come to the > IETF with very specific requests that you want addressed > in the standards. > > Andy > > > On Wed, Apr 6, 2016 at 11:21 AM, Warren Kumari wrote: > >> >> >> On Wed, Apr 6, 2016 at 2:45 PM Hui Deng wrote: >> >>> Can I treat no reply means "No", thanks a lot for chair's reply, >>> that could save me time to work on useless preparation. >>> >> >> It is currently a No. >> >> The current document has almost no detail. I think the right thing to do >> is: >> 1: flesh out the document so that there is content / protein. >> 2: discuss it in NFVRG / SDNRG, once there is support OpsAWG might be the >> place for a yang discussion / how this integrates with other things, etc. >> >> W >> >> >>> >>> Best regards, >>> >>> DENG Hui >>> >>> 2016-04-05 20:18 GMT-03:00 Hui Deng : >>> >>>> Hi Warren >>>> >>>> As you said, we do also contact with NFVRG and SDNRG about the draft. >>>> The reason coming to OPSAWG is to discuss about Yang related in OPS >>>> Area, >>>> because there are multiple WGs related to this like (NETCONF, NETMOD), >>>> so we approach OPSAWG for the simple way to proceed, >>>> >>>> thanks a lot for your consideration >>>> Best regards, >>>> >>>> DENG Hui >>>> >>>> >>>> >>>> 2016-04-04 20:34 GMT-03:00 Warren Kumari : >>>> >>>>> There is very little content in the draft (although it does have a >>>>> very pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( >>>>> https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( >>>>> https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( >>>>> https://datatracker.ietf.org/group/netconf/charter/) >>>>> >>>>> Those groups seem much more likely... >>>>> >>>>> W >>>>> >>>>> On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: >>>>> >>>>>> Hello all >>>>>> >>>>>> We have posted a submission this morning, apologize for late >>>>>> submission. >>>>>> >>>>>> https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt >>>>>> >>>>>> OPEN-O would intent to propose an open source project under Linux foundation. It >>>>>> includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is >>>>>> sitting on top of SDN Controller like ODL or ONOS and somewhere >>>>>> below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document >>>>>> is seeking for the relationship between open standard IETF and open >>>>>> source project OPEN-O. >>>>>> >>>>>> thanks a lot for your kind review >>>>>> >>>>>> Best regards, >>>>>> >>>>>> DENG Hui >>>>>> >>>>>> _______________________________________________ >>>>>> OPSAWG mailing list >>>>>> OPSAWG@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> >> > --001a11336424f6d296052fd58f20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see that open standard is working together with open sou= rce today, just like OPSArea presentation today.
People are seeking for= the cooperation, it doesn't mean open source is superior than open sta= ndard, or vice versa

2016-04-06 15:52 GMT-03:00 Andy Bierman = <andy@yumaworks.= com>:
Hi,<= div>
I have a stronger opinion...
IMO the IETF is n= ot in the open-source business and has no
official role to play i= n open-source.=C2=A0 You should come to the
IETF with very specif= ic requests that you want addressed
in the standards.

Andy


On Wed, Apr 6, 2016 a= t 11:21 AM, Warren Kumari <warren@kumari.net> wrote:


On Wed, Apr 6, 2016 at 2:45 PM Hui Deng <denghui02@gmail.com> = wrote:
Can I treat= no reply means "No", thanks a lot for chair's reply,=C2=A0that could save me time to work on useless preparation.

It is currently a No.=C2=A0

The current document has almost no detail. I think the right thing to= do is:
1: flesh out the document so that there is content / prot= ein.=C2=A0
2: discuss it in NFVRG / SDNRG, once there is support = OpsAWG might be the place for a yang discussion / how this integrates with = other things, etc.

W
=C2=A0

Best rega= rds,

DENG Hui

2016-04-05 20:18 GMT-03:00 Hui Deng = <denghui02@gmail.com>:
<= div dir=3D"ltr">Hi Warren

As you said, we do also contac= t with NFVRG and SDNRG about the draft.
The reason coming to OPSA= WG is to discuss about Yang related in OPS Area,
because there ar= e multiple WGs related to this like (NETCONF, NETMOD),=C2=A0
so w= e approach OPSAWG for the simple way to proceed,

t= hanks a lot for your consideration
Best regards,

DENG Hui



2016-04-04 20:34 GMT-03= :00 Warren Kumari <warren@kumari.net>:
There is very little content in the draft (a= lthough it does have a very pretty ASCII art drawing), but I'm not sure= why OpsAWG and not NFVRG (https://datatracker.ietf.org/group/nfvrg/ch= arter/) or SDNRG (https://datatracker.ietf.org/group/sdnrg/charter= /) or Netconf (https://datatracker.ietf.org/group/netconf/charte= r/)=C2=A0

Those groups seem much more likely...




_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg



--001a11336424f6d296052fd58f20-- From nobody Wed Apr 6 12:08:21 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7346812D771 for ; Wed, 6 Apr 2016 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.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 Pbwwume_N3ZK for ; Wed, 6 Apr 2016 12:08:18 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 0A4AB12D755 for ; Wed, 6 Apr 2016 12:08:17 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u36J4giF008146; Wed, 6 Apr 2016 12:08:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=YUdLMguqUVyRsHICTLl/KYCeuZfv4gne0kdTPEJWlfE=; b=YpVPNX2KHnPWSD9tCeA2E1neex/dGGAnDfnPL+25N8zZdWzW8j4koAWrYz/yAxjGKoGH ZdSTCQtNUrDgEyje8/+hzW2c4qeT1nGGVtCHdfNOXnJPfxx/+E2wAfKIlWgewGAc97SK CrDqz4RPoH/92KYo1ziF0CXq5fTEO0QseBE= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 224kerx52j-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Apr 2016 12:08:16 -0700 Received: from PRN-CHUB19.TheFacebook.com (192.168.16.73) by PRN-CHUB10.TheFacebook.com (192.168.16.20) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 6 Apr 2016 12:08:14 -0700 Received: from PRN-MBX01-2.TheFacebook.com ([169.254.3.204]) by PRN-CHUB19.TheFacebook.com ([fe80::143:941d:8f95:c768%13]) with mapi id 14.03.0248.002; Wed, 6 Apr 2016 12:08:13 -0700 From: Petr Lapukhov To: Joe Clarke , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Call for Agenda Items for Buenos Aires Thread-Index: AQHRkDCHkOXfRmxyB0mKSYdZLvEHHZ99S50l Date: Wed, 6 Apr 2016 19:08:12 +0000 Message-ID: <3F437107848A5140A6A19222EFFB34812011BD6E@PRN-MBX01-2.TheFacebook.com> References: <3F437107848A5140A6A19222EFFB3481200F061D@PRN-MBX01-2.TheFacebook.com>, <5705529E.4020700@cisco.com> In-Reply-To: <5705529E.4020700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-06_08:, , signatures=0 Archived-At: Subject: Re: [OPSAWG] Call for Agenda Items for Buenos Aires X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:08:19 -0000 Thank for the questions! =0A= =0A= Please see responses inline:=0A= =0A= > * How do you propose the populated data to be handled normally? Will=0A= > the probe destination (i.e., the dest address of the UDP packet) be=0A= > expected to understand these, or will loopback mode have to be used?=0A= > The reason I ask is that I'm not sure what happens if all nodes in the=0A= > network do not support this probe. Could this give more network insight= =0A= > to the destination, and thus be a security weakness?=0A= =0A= One of the main reasons to use regular data packet and not any special OAM = format or IPv6 extension header is to let the packet pass through non-compl= iant devices transparently. The device that understand the request will fil= l in their data, but others will remain invisible (unless hop-by-hop varian= t is requests using router-alert option - but I doubt this would be viable = given the state of hardware in the DC at the moment).=0A= =0A= For security concerns: this is a rather big topic in context of data-plane = probe, and I haven't completed the section yet. Easy way out is saying "we = control the network in DC and we are aware of security consequences of disc= losing the device state". The header marker might help here - a random key = value would need to be guessed by possible attacker. In addition, only sele= ct applications could be allowed to send the probes to the "special" port. = =0A= =0A= > * Related to the question above what would happen if a set a hop count=0A= > of four, but the fourth device (before my destination) has not awareness= =0A= > of this telemetry system?=0A= =0A= The responsibility for setting the right hop limit is on the sender. It nee= ds to be aware there are devices that do not understand the form of signali= ng, and adjust hop-limit respectively. All non-compliant hops will be trans= parent. Worst case, if sender was clueless, the packet will just fall throu= gh to the other side just like a regular active probe.=0A= =0A= > * Why not use ifIndex values for port IDs? It seems to me that having a= =0A= > more standard and known cross-vendor way to identify ports is useful.=0A= =0A= This is a good idea: I heard this a few times already and I will change the= spec accordingly :) It is hard to number the physical ser/des (e.g. BRCM h= as a way to do this in SDK, but others would likely be different). The trad= eoff is that the ifIndex will need to be stored in some state table in hard= ware.=0A= =0A= >* You do not list IANA considerations, but it seems to me that your=0A= >probe types would be well-suited for a registry that perhaps could live=0A= >with IANA? It would also be useful to have some reserved space for=0A= > private extensions where possible.=0A= =0A= I wasn't sure what kind of code-point could be requested. I think this is a= very good point for "Type" registration, to ensure better interop.=0A= =0A= > * I think you mentioned it at the mic, but the draft doesn't really=0A= > address what happens if a device supports this telemetry system, but=0A= > does not support a specific probe type? For example, what if I define=0A= > type 50 down the road, but not all of my devices/hardware yet support=0A= > this? What happens then?=0A= =0A= Right now the idea is that device will simply set the bit signaling that it= does not understand the requested type, and leave the value in TLV empty (= zero). The length is known to the device even if it does not understand the= type.= From nobody Wed Apr 6 12:19:13 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411A212D755 for ; Wed, 6 Apr 2016 12:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 ufMUttf6KI18 for ; Wed, 6 Apr 2016 12:19:09 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (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 B267712D747 for ; Wed, 6 Apr 2016 12:19:06 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id zy2so4894757pac.2 for ; Wed, 06 Apr 2016 12:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=C036ZDkL3T46ixtVF9L49cUGouyV89eUMY80+6YF2yU=; b=hRFDcT7iVD4QJbygpdlAb6+t+z8U0Sant+lIMcftZXs+lqsFo5z6BH3bdvtKozrIhb ELYuAvfxPOtPOUvts5FwUo4PhVQFzP2a5XlJapbfUNY8xkYPqiv3wWMqauoJIuMAfR+c LadDLv2VvUzIncZbaegDHTEhWYjMP7w8nU8pE3cpS+UU6ta3vkXDVYLr/HnqzyUU20e5 yiPnomlUo4gw5l8ujqldz8RKLImgdwQpNKVeIGIPaCq3kyR4SWDBdDdapuXk02rC+PiS X1ZCx/i9CuthLKgkWy2BPQWbwZtjqSaGh0YKzM18ztX/S26EF/mAVVPzDKbZRSjlEG5N 2Ytg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=C036ZDkL3T46ixtVF9L49cUGouyV89eUMY80+6YF2yU=; b=jZr6Y6AQXcBR6R4IAMU7unIgPQmYdDdVRJtsp58/dhttmm385hN/kwxBYyH8CWb/yJ tJmoUOn2GU671APyE0WVe+GwViwxOYgJl261CM4oTAwM9SZp+jIgqJEHuM/cPm7yuCLh 1Tjhk2qH3d6Otr6VMWAEs6FKyKMJkDbNE3wo3+QeUFM6QYpAfneuJdFxbfKIasfgEl0U yeRlSEleLMPCLmirDC0Ob4SN9y1QsCqSrxejPaA5EripmZprJ1SpJS3sXCXFt0HxbhsE bL8OTaD1N0v6ocf3KhGSjseXd80ui+MRbhVR4YlaE3nSo+EVcqQu/G16Md7c+InW+vpC 9xVQ== X-Gm-Message-State: AD7BkJIo7Ln+RN3VSYqQqFf4+wH3uyUP4cqonXRa1lU9hjjT4r7AuPvtvl0dQCxp10t0xw== X-Received: by 10.66.90.163 with SMTP id bx3mr73484123pab.59.1459970346367; Wed, 06 Apr 2016 12:19:06 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (74-124-96-91-radius.dynamic.acsalaska.net. [74.124.96.91]) by smtp.googlemail.com with ESMTPSA id l11sm6703917pfb.56.2016.04.06.12.19.04 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 12:19:05 -0700 (PDT) To: opsawg@ietf.org References: From: Melinda Shore Message-ID: <5705615B.3070402@gmail.com> Date: Wed, 6 Apr 2016 11:19:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:19:11 -0000 On 4/6/16 10:59 AM, Hui Deng wrote: > I see that open standard is working together with open source today, > just like OPSArea presentation today. I guess I don't understand why it requires "cooperation." I think that the IETF has by and large benefited from an increased focus on implementation, both in terms of the quality of the documents (in those cases where there's an implementation underway in partnership with the document development) and in terms of the timeliness of the documents (it's a lot easier to move things along when there's running code available to support your argument). So this one's easy: code it up, check the code into a publicly- available repository, and release it under a liberal license. But, in this case, you appear to want more than that. Again, the document doesn't really have much in the way of detail, but what I'm inferring from it is that you'd like the IETF to support ETSI's request for funding from the Linux Foundation for implementation of this vaguely- specified thing? Melinda From nobody Wed Apr 6 12:27:31 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C9C12D791 for ; Wed, 6 Apr 2016 12:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-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 iRHuXN42BW0P for ; Wed, 6 Apr 2016 12:27:29 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B45F12D775 for ; Wed, 6 Apr 2016 12:27:28 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g184so41344633lfb.3 for ; Wed, 06 Apr 2016 12:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2IFlSbKTVq+IlSPAc4WVTa07Uadjqai8AtpNckFjshc=; b=spOvl0qyC56b02tiYLEl8/A12wXY/WGsFQSiehcPUptclhoD3twAjN7Co+9ljrylDG XVgV4wX9n/tQVLtd2Qo0+LnkQ7R96SFfJvcok5AbqJonXARbgdiwcGbQFzJHTNJ1mKyt mvM8uUFPl7W2+MMi8T/u4Hzwu9HiyoTOMGpypvXq232nP070bHOSm5L/qX/PmjoqkuH/ Jy05T32K+TMUUWFerGc9LWkbEUGM7s/RkAnBJe77sq9c+37WyIG0+UGnh5F3f/8kFheh Y0ol5pAaQ88c5qZ527QRmiFK6iP5HudBWkTlwFnZMx3vjD911e+MqwKFgEvGNTFOg2Gn 6COQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2IFlSbKTVq+IlSPAc4WVTa07Uadjqai8AtpNckFjshc=; b=ebdrDlCEx5MeG5mbLHy+vgBSkZpdB2/rsr88v40u8Zxh5nSWkoEWuE8GFHsR7lZgMb /cDttu8aZ0oKCU4ljLXFppe517NQsxm8RLZa7i+kTCtF03XYC5Szas7B3b4ePcQUjcKL NfllhDwDh4MW3zZgEqElcKjXhATlptVdjr8QwlGs/Ppb9a6Q+iaNlf5Ldvi2NZXCezUu 86DBevcRXcC+tsf8L0gfOGmGF9ujC7h7I0l2uYMsvp5AxYQ7o9fICFOhKU3oJMn7mPdh uIvzrqk4F9jJV9ZZFaH+OMP4XB7/t+qeroLW/9gE+mJP4Br7Y3/rZ1V001x1Tnjlrgmq htCA== X-Gm-Message-State: AD7BkJJF02U9nAv1C44PhLyYC7eW7AWdf6WqX0jSA3zhxVSD0zYgvTCj6Zw/kAqthA+vpzPyre8PpoFx8zcsHA== MIME-Version: 1.0 X-Received: by 10.25.83.197 with SMTP id h188mr9031346lfb.13.1459970846559; Wed, 06 Apr 2016 12:27:26 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Wed, 6 Apr 2016 12:27:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2016 12:27:26 -0700 Message-ID: From: Andy Bierman To: Hui Deng Content-Type: multipart/alternative; boundary=001a11424abeb12592052fd5f38b Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:27:30 -0000 --001a11424abeb12592052fd5f38b Content-Type: text/plain; charset=UTF-8 On Wed, Apr 6, 2016 at 11:59 AM, Hui Deng wrote: > I see that open standard is working together with open source today, just > like OPSArea presentation today. > People are seeking for the cooperation, it doesn't mean open source is > superior than open standard, or vice versa > > Nobody is saying one is better than the other. I am saying the IETF does standards. Is there a protocol you have that you want the IETF to standardize? Is there an existing protocol that needs improvement so you can accomplish your open-source project goals? Your draft needs to identify the specific work you want done in the IETF. Andy > 2016-04-06 15:52 GMT-03:00 Andy Bierman : > >> Hi, >> >> I have a stronger opinion... >> IMO the IETF is not in the open-source business and has no >> official role to play in open-source. You should come to the >> IETF with very specific requests that you want addressed >> in the standards. >> >> Andy >> >> >> On Wed, Apr 6, 2016 at 11:21 AM, Warren Kumari wrote: >> >>> >>> >>> On Wed, Apr 6, 2016 at 2:45 PM Hui Deng wrote: >>> >>>> Can I treat no reply means "No", thanks a lot for chair's reply, >>>> that could save me time to work on useless preparation. >>>> >>> >>> It is currently a No. >>> >>> The current document has almost no detail. I think the right thing to do >>> is: >>> 1: flesh out the document so that there is content / protein. >>> 2: discuss it in NFVRG / SDNRG, once there is support OpsAWG might be >>> the place for a yang discussion / how this integrates with other things, >>> etc. >>> >>> W >>> >>> >>>> >>>> Best regards, >>>> >>>> DENG Hui >>>> >>>> 2016-04-05 20:18 GMT-03:00 Hui Deng : >>>> >>>>> Hi Warren >>>>> >>>>> As you said, we do also contact with NFVRG and SDNRG about the draft. >>>>> The reason coming to OPSAWG is to discuss about Yang related in OPS >>>>> Area, >>>>> because there are multiple WGs related to this like (NETCONF, NETMOD), >>>>> so we approach OPSAWG for the simple way to proceed, >>>>> >>>>> thanks a lot for your consideration >>>>> Best regards, >>>>> >>>>> DENG Hui >>>>> >>>>> >>>>> >>>>> 2016-04-04 20:34 GMT-03:00 Warren Kumari : >>>>> >>>>>> There is very little content in the draft (although it does have a >>>>>> very pretty ASCII art drawing), but I'm not sure why OpsAWG and not NFVRG ( >>>>>> https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG ( >>>>>> https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf ( >>>>>> https://datatracker.ietf.org/group/netconf/charter/) >>>>>> >>>>>> Those groups seem much more likely... >>>>>> >>>>>> W >>>>>> >>>>>> On Mon, Apr 4, 2016 at 8:53 AM Hui Deng wrote: >>>>>> >>>>>>> Hello all >>>>>>> >>>>>>> We have posted a submission this morning, apologize for late >>>>>>> submission. >>>>>>> >>>>>>> https://www.ietf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt >>>>>>> >>>>>>> OPEN-O would intent to propose an open source project under Linux foundation. It >>>>>>> includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is >>>>>>> sitting on top of SDN Controller like ODL or ONOS and somewhere >>>>>>> below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document >>>>>>> is seeking for the relationship between open standard IETF and open >>>>>>> source project OPEN-O. >>>>>>> >>>>>>> thanks a lot for your kind review >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> DENG Hui >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OPSAWG mailing list >>>>>>> OPSAWG@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>>>>> >>>>>> >>>>> >>>> >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>> >>> >> > --001a11424abeb12592052fd5f38b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 6, 2016 at 11:59 AM, Hui Deng <denghui02@gmail.com&g= t; wrote:
I see t= hat open standard is working together with open source today, just like OPS= Area presentation today.
People are seeking for the cooperation, it doe= sn't mean open source is superior than open standard, or vice versa



Nobody is saying one is better than the other.
= I am saying the IETF does standards.
Is there a protocol you have= that you want the IETF to standardize?
Is there an existing prot= ocol that needs improvement so you
can accomplish your open-sourc= e project goals?

Your draft needs to identify the = specific work you want done in the IETF.


Andy
=C2=A0
2016-04-06 15:52 GMT-03:00 Andy= Bierman <andy@yumaworks.com>:
Hi,

I have a stronger opinion...<= /div>
IMO the IETF is not in the open-source business and has no
<= div>official role to play in open-source.=C2=A0 You should come to the
IETF with very specific requests that you want addressed
in= the standards.

Andy=


On Wed, Apr 6, 2016 at 11:21 AM, Warren K= umari <warren@kumari.net> wrote:


On Wed, Apr 6, 2016 at 2:45 PM Hui Deng <denghui02@gmail.com> wrote:
Can I treat no reply means &quo= t;No", thanks a lot for chair's reply,=C2=A0
that could save m= e time to work on useless preparation.

It is currently a No.=C2=A0

The current do= cument has almost no detail. I think the right thing to do is:
1:= flesh out the document so that there is content / protein.=C2=A0
2: discuss it in NFVRG / SDNRG, once there is support OpsAWG might be the = place for a yang discussion / how this integrates with other things, etc.

W
=C2=A0

Best regards,

<= /div>
DENG Hui

2016-04-05 20:18 GMT-03:00 Hui Deng &l= t;denghui02@gmail.= com>:
Hi W= arren

As you said, we do also contact with NFVRG and SDN= RG about the draft.
The reason coming to OPSAWG is to discuss abo= ut Yang related in OPS Area,
because there are multiple WGs relat= ed to this like (NETCONF, NETMOD),=C2=A0
so we approach OPSAWG fo= r the simple way to proceed,

thanks a lot for your= consideration
Best regards,

DENG Hui



2016-04-04 20:34 GMT-03:00 Warren Kumari <= warren@kumari.net>:
There is very little content in the draft (although it does have = a very pretty ASCII art drawing), but I'm not sure why OpsAWG and not N= FVRG (https://datatracker.ietf.org/group/nfvrg/charter/) or SDNRG= (https://datatracker.ietf.org/group/sdnrg/charter/) or Netconf (<= a href=3D"https://datatracker.ietf.org/group/netconf/charter/" target=3D"_b= lank">https://datatracker.ietf.org/group/netconf/charter/)=C2=A0
Those groups seem much more likely...

W

On Mon, Apr= 4, 2016 at 8:53 AM Hui Deng <denghui02@gmail.com> wrote:
Hello all

We have posted a submission this morning, apologize for late submis= sion.

https://www.i= etf.org/id/draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt

OP=
EN-O would intent to propose an open source project under Linux foundation.=
 It
   includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
   sitting on top of SDN Controller like ODL or ONOS and somewhere
   below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
   is seeking for the relationship between open standard IETF and open
   source project OPEN-O.

thanks a lot for your kind review
Best regards,
<= pre>DENG Hui
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg



_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg




--001a11424abeb12592052fd5f38b-- From nobody Wed Apr 6 14:08:42 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FC412D11A for ; Wed, 6 Apr 2016 14:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 kAzYPRt4xL0N for ; Wed, 6 Apr 2016 14:08:39 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8860B12D0EB for ; Wed, 6 Apr 2016 14:08:39 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id d68so72960641ywe.1 for ; Wed, 06 Apr 2016 14:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=OdUHfWgGMFueV/66VklwtMfUJWdMHDd6Uwhg8BwZbgk=; b=WU6VnyGrl36/6X+C01ir3k0VO3yvxUt2iU6G9S+TtuIxy2R6knmhlC08W7lSeW5BcJ bPpuP/965JhyVk3qTQ4YMIVBgzmk4AqmKBSRWkW6eSMYN7XtAJ53G9hWvAFakNGoyKVU M1G1jOVG3o1B/RvXu31xjh38amQrFM7OdQDMVT1eFnQdU2IKTfl5rqbE1QjUkEOj93OD t/snG3ZfVeJwTYvNB6dQTXXRmGZFp/t0hFHNnqvu+uPC5humS3EycTQnuiSnhgtCwd4u eoLscRwK8E+HNCvtHDD8IVA9K4mbLnhEiSPXqa11Vqp9G7plHVzQM2h67ahY/QJpKP3K eb9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OdUHfWgGMFueV/66VklwtMfUJWdMHDd6Uwhg8BwZbgk=; b=X3ZgJh824er5KJ7+2ka0yjYQdeEmtpcI7paeA+RMzLujJUnlHOr8dEFyzEO016TfRA V7hRFIJgNK7ntRxti1Qp5LWgYWk2TnnGWgobpORO7hb8HwiSxVSf/eIABQEHPYSIulrW MuJvFrnqVrPS2Yi/hRawGWsr3HNDX1WPm7OLZ6u9Z5j8E52QQh1/alEMIAJXa8P2HN6Q 409ITfB6BVaNtBM4tpT1pqMMi60YBi41TaiThC/F8r8TAxXMbmBEUWWB2cPVBS/e6y5D YIwvWk2IDxC1z5VdsALPf+X0q9Lng0aebBlkB+9JUZUNmEU+kIwdSR+YK66Lb8STTMD6 0yOQ== X-Gm-Message-State: AD7BkJIa3nBb5sA1jO/y09Xfu0Sb/41azdP9t/TJ99Th+kKPo1sieNIoObLyMGoAIDzbEOimF1boVhdYVoc6YZoB X-Received: by 10.129.124.70 with SMTP id x67mr17653536ywc.333.1459976918768; Wed, 06 Apr 2016 14:08:38 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Wed, 06 Apr 2016 21:08:29 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a11494ad49fd20d052fd75d39 Archived-At: Subject: [OPSAWG] Minutes posted. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:08:41 -0000 --001a11494ad49fd20d052fd75d39 Content-Type: text/plain; charset=UTF-8 Hi all, Thanks to Barbara for taking minutes. Draft minutes have been posted, please let the chairs know if anything you say was misrepresented. W --001a11494ad49fd20d052fd75d39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks to Barbara for taking mi= nutes.=C2=A0
Draft minutes have been posted, please let the chair= s know if anything you say was misrepresented.

W
--001a11494ad49fd20d052fd75d39-- From nobody Wed Apr 6 14:29:05 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C655B12D15D for ; Wed, 6 Apr 2016 14:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 tdLTgzk_2_LS for ; Wed, 6 Apr 2016 14:29:02 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B468212D542 for ; Wed, 6 Apr 2016 14:29:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AWAgBBfgVX/xUHmMZdGgEBAYJOIStTfQa4OIIPAQ2Bc4YNAhyBNDgUAQEBAQEBAWUnhEEBAQEBAxIRClwCAQgNBAQBAQsdAwICAjAUCQgCBAESCBMHiAUBpRqKS5F4AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYihEqEPxYggkorgisFkxiEaQGPcYRNgxyFPo8hHgEBQoNnbId1AX0BAQE X-IPAS-Result: A2AWAgBBfgVX/xUHmMZdGgEBAYJOIStTfQa4OIIPAQ2Bc4YNAhyBNDgUAQEBAQEBAWUnhEEBAQEBAxIRClwCAQgNBAQBAQsdAwICAjAUCQgCBAESCBMHiAUBpRqKS5F4AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYihEqEPxYggkorgisFkxiEaQGPcYRNgxyFPo8hHgEBQoNnbId1AX0BAQE X-IronPort-AV: E=Sophos;i="5.24,448,1454994000"; d="scan'208,217";a="178980471" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Apr 2016 17:29:00 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 06 Apr 2016 17:28:59 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 6 Apr 2016 23:28:56 +0200 From: "Romascanu, Dan (Dan)" To: Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Minutes posted. Thread-Index: AQHRkEiM+83xuBt0sEuU4UXsVGNttZ99dLqA Date: Wed, 6 Apr 2016 21:28:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA751BD7E7@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA751BD7E7AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] Minutes posted. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:29:04 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA751BD7E7AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk9uIHRoZSBBdXRvbWF0aWMgQXR0YWNobWVudCBzZWN0aW9uOg0KDQpPTEQ6DQoNCg0K RGFuOiBDYW4gYmUgYXBwbGljYWJsZSB0byBvdGhlciB0eXBlcyBvZiB0dW5uZWxzLiBOb3QgYXNr aW5nIGZvciBuZXcgcHJvdG9jb2wuIFByb3ZpZGluZyBhIHJlcG9ydC4NCg0KU2hhaHJhbTogVGhl cmUgc2VlbXMgdG8gYmUgYSBtaXggb2YgcmVxdWlyZW1lbnRzLCBkaXNjdXNzaW9uLCBvdGhlciBp biBkb2MuDQoNCkRhbjogWWVzLiBJdCBuZWVkcyB0byBiZSBjbGVhbmVkIHVwLg0KDQpEaWVnbyBM b3BleiBjb21tZW50ZWQuDQoNCk5FVzoNCg0KRGFuOiBDYW4gYmUgYXBwbGljYWJsZSB0byBvdGhl ciB0eXBlcyBvZiB0dW5uZWxzLiBOb3QgYXNraW5nIGZvciBuZXcgcHJvdG9jb2wuIERlc2NyaWJp bmcgc29sdXRpb24gdG8gYW4gb3BlcmF0aW9uYWwgcHJvYmxlbS4NClNoYWhyYW06IFRoZXJlIHNl ZW1zIHRvIGJlIGEgbWl4IG9mIHJlcXVpcmVtZW50cywgZGlzY3Vzc2lvbiwgb3RoZXIgaW4gZG9j Lg0KRGFuOiBZZXMuIEl0IG5lZWRzIHRvIGJlIGNsZWFuZWQgdXAuIFBsYW4gdG8gc3BsaXQgZG9j dW1lbnRzIGluIHNlcGFyYXRlIEktRHMuDQpEaWVnbyBMb3BleiBleHByZXNzZWQgaW50ZXJlc3Qg YW5kIGNvbW1lbnRlZC4NCg0KUmVnYXJkcywNCg0KRGFuDQoNCg0KRnJvbTogT1BTQVdHIFttYWls dG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXYXJyZW4gS3VtYXJpDQpT ZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgMTI6MDggQU0NClRvOiBvcHNhd2dAaWV0Zi5v cmcNClN1YmplY3Q6IFtPUFNBV0ddIE1pbnV0ZXMgcG9zdGVkLg0KDQpIaSBhbGwsDQoNClRoYW5r cyB0byBCYXJiYXJhIGZvciB0YWtpbmcgbWludXRlcy4NCkRyYWZ0IG1pbnV0ZXMgaGF2ZSBiZWVu IHBvc3RlZCwgcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtub3cgaWYgYW55dGhpbmcgeW91IHNheSB3 YXMgbWlzcmVwcmVzZW50ZWQuDQoNClcNCg== --_000_9904FB1B0159DA42B0B887B7FA8119CA751BD7E7AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbiB0aGUg QXV0b21hdGljIEF0dGFjaG1lbnQgc2VjdGlvbjoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0xEOg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EYW46IENhbiBiZSBhcHBsaWNhYmxlIHRvIG90aGVy IHR5cGVzIG9mIHR1bm5lbHMuIE5vdCBhc2tpbmcgZm9yIG5ldyBwcm90b2NvbC4gUHJvdmlkaW5n IGEgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlNoYWhyYW06IFRoZXJlIHNlZW1zIHRvIGJlIGEgbWl4IG9mIHJlcXVpcmVtZW50 cywgZGlzY3Vzc2lvbiwgb3RoZXIgaW4gZG9jLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRhbjogWWVzLiBJdCBuZWVkcyB0byBiZSBjbGVh bmVkIHVwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkRpZWdvIExvcGV6IGNvbW1lbnRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5ORVc6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPkRhbjogQ2FuIGJlIGFwcGxpY2FibGUgdG8gb3RoZXIgdHlwZXMgb2YgdHVubmVs cy4gTm90IGFza2luZyBmb3IgbmV3IHByb3RvY29sLiBEZXNjcmliaW5nIHNvbHV0aW9uIHRvIGFu IG9wZXJhdGlvbmFsIHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlNoYWhyYW06IFRoZXJlIHNlZW1zIHRvIGJl IGEgbWl4IG9mIHJlcXVpcmVtZW50cywgZGlzY3Vzc2lvbiwgb3RoZXIgaW4gZG9jLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5EYW46IFllcy4gSXQgbmVlZHMgdG8gYmUgY2xlYW5lZCB1cC4gUGxhbiB0byBzcGxpdCBkb2N1 bWVudHMgaW4gc2VwYXJhdGUgSS1Ecy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+RGllZ28gTG9wZXogZXhwcmVzc2VkIGlu dGVyZXN0IGFuZCBjb21tZW50ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGFuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+V2FycmVuIEt1bWFyaTxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgMTI6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IG9wc2F3 Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT1BTQVdHXSBNaW51dGVzIHBvc3RlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg YWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IHRvIEJhcmJhcmEgZm9yIHRha2luZyBtaW51dGVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHJhZnQgbWludXRlcyBoYXZlIGJlZW4g cG9zdGVkLCBwbGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdyBpZiBhbnl0aGluZyB5b3Ugc2F5IHdh cyBtaXNyZXByZXNlbnRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA751BD7E7AZFFEXMB04globa_-- From nobody Thu Apr 7 10:21:58 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542FE12D530 for ; Thu, 7 Apr 2016 10:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 27ektNjbFUWL for ; Thu, 7 Apr 2016 10:21:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FC512D0BD for ; Thu, 7 Apr 2016 10:21:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aoDcw-0008H7-Pk; Thu, 07 Apr 2016 17:21:54 +0000 Date: Thu, 07 Apr 2016 14:21:53 -0300 Message-ID: From: Randy Bush To: Andy Bierman In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:21:57 -0000 > Nobody is saying one is better than the other. > I am saying the IETF does standards. and running code From nobody Thu Apr 7 10:51:16 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5F412D592 for ; Thu, 7 Apr 2016 10:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-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 HwusUBXuLw1O for ; Thu, 7 Apr 2016 10:51:13 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 DDDB112D652 for ; Thu, 7 Apr 2016 10:50:53 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id e190so60757456lfe.0 for ; Thu, 07 Apr 2016 10:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yYo/6oWOeA3fUbxKjRY4P4qxfAslpCQPSkaympumi+w=; b=ScLBTX3tGzV20u4uW2FWEvRTQDG9L8tH4tY8G+Z/NatxmIBWROQr1q/ozLEiuvjrRK BZH1KqQwvO7ZqCMtfbdx3EQop49iDt/TQEy9pfoBua4hd+jLrl/sTFN2U9Fgf1LFoXvz ztH/rGDngfY0YMJW5JRhFd460C8ryckY0iLDiNNG5XhOsrgCHBUWdfscbupWwEHMA7K9 VEUSuzuCNQ9/T63qaO7yw1qP6Q4LRQumMJ7E7Xgl3vslZa3TGcOyVNicnDxyc8IRJWfk ryRp5EsGwB6dhV8oA06gF/JJ3I+ppr5i6kiYooA6aK8tjd2IWr5jjlb1rtDeBAOzaPSg +Trg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yYo/6oWOeA3fUbxKjRY4P4qxfAslpCQPSkaympumi+w=; b=JcsJ6hQgIZfvbLyS7tL9kdV2CiOP0cmlbTPPlCoTJoj4wRSL/uYJhynMqbnFKIbkDU 00+2pZVcsE3uoaQPWOKa7T8GbmrpCo4LbrjBpVzcDZEoj/CJRz1QGWuJn8ki+8VXHSzh Cdgu2fE5xZkTlNVudNA390Kg4UcIarVLArMXQdSwjczSlQW+YpaPHvgciErf6DRUxvfp jZRc4bASMMbwUBCTDzoDYGMxs+LH0LsXmzV4PvV4kZEaeN6FB7cI8PPsoyvUiDybQeMf BmZ5YdNMnVMzWkY9kHqiIBRJNP3sEfKD3FrZM/xH1CfeKjnmX/3zlrh90GQ8bi42Iol2 cEpw== X-Gm-Message-State: AD7BkJLa1kQITSKMEwtNE+YrgwD2AKmdaxuwyj95u29CswBMaHclDtF3Wc52Q3pLgtSwnXzHVQgfBtoTHlh4Cw== MIME-Version: 1.0 X-Received: by 10.25.83.197 with SMTP id h188mr1938055lfb.13.1460051452132; Thu, 07 Apr 2016 10:50:52 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Thu, 7 Apr 2016 10:50:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Apr 2016 10:50:52 -0700 Message-ID: From: Andy Bierman To: Randy Bush Content-Type: multipart/alternative; boundary=001a11424abe2894a8052fe8b833 Archived-At: Cc: opsawg Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:51:15 -0000 --001a11424abe2894a8052fe8b833 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 10:21 AM, Randy Bush wrote: > > Nobody is saying one is better than the other. > > I am saying the IETF does standards. > > and running code > that's what the t-shirt says, but I have never seen "running code" in a WG charter. Andy --001a11424abe2894a8052fe8b833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 10:21 AM, Randy Bush <randy@psg.com> = wrote:
> Nobody is saying one is bette= r than the other.
> I am saying the IETF does standards.

and running code

that's what the t-= shirt says, but I have never seen "running code"
in a W= G charter.


Andy
=C2=A0

--001a11424abe2894a8052fe8b833-- From nobody Thu Apr 7 10:53:11 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E7C12D5CF for ; Thu, 7 Apr 2016 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 tNJNSXBkcaMn for ; Thu, 7 Apr 2016 10:53:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D3612D59A for ; Thu, 7 Apr 2016 10:53:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1aoE78-0008Rs-SD; Thu, 07 Apr 2016 17:53:07 +0000 Date: Thu, 07 Apr 2016 14:53:05 -0300 Message-ID: From: Randy Bush To: Andy Bierman In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: opsawg Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:53:09 -0000 >>> Nobody is saying one is better than the other. >>> I am saying the IETF does standards. >> and running code > that's what the t-shirt says, but I have never seen "running code" in > a WG charter. an ops wg might be a good place to start. but we've kinda been beaten to the punch. the idr wg, as in most routing wgs, requires two or more interoperating implementations to progress a document. randy From nobody Thu Apr 7 11:03:25 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAB112D64D for ; Thu, 7 Apr 2016 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-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 FenOpqeFbiGd for ; Thu, 7 Apr 2016 11:03:22 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 87FD912D525 for ; Thu, 7 Apr 2016 11:03:21 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id os9so10689604lbb.2 for ; Thu, 07 Apr 2016 11:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=c1ZmXEhZH43lPhki3Iscsg+15TkG47DLRZCvhRrwJQc=; b=P8GlTTTb96KVOoav7ZcwA+7NCo0WE+KodCz+PHj3wVV3XxwGj/6XRDhY0GoIrVKY1g 3pMR7p0Z95W2zsCckdUSSzjIbCB1tdqmwhr7KIN2rn7lNgQVRRMr0U2NVVKRoWZll43f VQKwn0PPYj7LfDHtde8Yp/zuM6PkoLI0sNxj0FbNzEgtwPgHHP+vUag+A25+3P9TNY0Y uP13FFGu+LZ68h3Nk3N2TGAJP8LFtGganh4O7GDcu9JeXMFA2Y6X9tL6cYFY3EDTCUpN nU8VFp2tC2Xul8aDk+2Mi5q/OyrWAStQJxZ64NQBKUM/A/fgkXywPShGbZtfzNC9a/TU b3OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=c1ZmXEhZH43lPhki3Iscsg+15TkG47DLRZCvhRrwJQc=; b=RLSPhq3Mzmg3lv5AZUHu0RGR1nFGGhCL4SNVOEv3dPTTTXFfSHQZor+OJEcszK5taA O5jTILWodFihr0EUIWZpQAC1zV+V56tFhwY7LAzj4KjWmn7v02CCXFJABRVOZuTUPhzz KY2xT75FWMsE3EbkEK8iAk+kf8SeTi3wasYayuKVRzy6cJ2vFMDkdfbKWw3+ftZyt6lf 6u5DugbOUdPE7kqmr+bNrR2f73dhxisInKtEpSwQXG5jgIL6tq52TlJC2r694WwFDPg0 rWrh3iHb5WRS2pQFh0fFN3sg3vb/17wekrBRAC2qImSJD/89OZk97bjf2A/Y7K/1sbgX KAug== X-Gm-Message-State: AD7BkJIH9XVjbnj15JU6xKhMz95YqZ+X558jEH/jfpFqllDA5BJhaN7g5iNRjt4AmRKbX4mjiT0/YQ7DJGYcfw== MIME-Version: 1.0 X-Received: by 10.112.170.68 with SMTP id ak4mr1603640lbc.94.1460052199698; Thu, 07 Apr 2016 11:03:19 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Thu, 7 Apr 2016 11:03:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Apr 2016 11:03:19 -0700 Message-ID: From: Andy Bierman To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c259a8b790ff052fe8e4ed Archived-At: Cc: opsawg Subject: Re: [OPSAWG] OPEN-O draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:03:23 -0000 --001a11c259a8b790ff052fe8e4ed Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 10:53 AM, Randy Bush wrote: > >>> Nobody is saying one is better than the other. > >>> I am saying the IETF does standards. > >> and running code > > that's what the t-shirt says, but I have never seen "running code" in > > a WG charter. > > an ops wg might be a good place to start. but we've kinda been beaten > to the punch. > > the idr wg, as in most routing wgs, requires two or more interoperating > implementations to progress a document. > sounds wonderful. All WGs should avoid sandbox flailing, and requiring 2 implementations is a nice high bar to accomplish that. My point was that (for YANG anyway) the IETF is working closely with opensource projects like OpenDaylight because people involved in these projects bring their requests to the WGs. I don't think ODL wants to be "owned" by the IETF and the IETF should not attempt to control such projects. > randy > Andy --001a11c259a8b790ff052fe8e4ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 7, 2016 at 10:53 AM, Randy Bush <randy@psg.com> = wrote:
>>> Nobody is saying one = is better than the other.
>>> I am saying the IETF does standards.
>> and running code
> that's what the t-shirt says, but I have never seen "running = code" in
> a WG charter.

an ops wg might be a good place to start.=C2=A0 but we've kinda been be= aten
to the punch.

the idr wg, as in most routing wgs, requires two or more interoperating
implementations to progress a document.

sounds wonderful.=C2=A0 All WGs should avoid sandbox flailing, and=C2=A0
requiring 2 implementations is a nice high bar to accomplish that.=

My point was that (for YANG anyway) the IETF is w= orking closely with
opensource projects like OpenDaylight because= people involved in these
projects bring their requests to the WG= s.=C2=A0 I don't think ODL wants to
be "owned" by t= he IETF and the IETF should not attempt to control
such projects.=



randy


<= /div>
Andy

--001a11c259a8b790ff052fe8e4ed-- From nobody Fri Apr 8 06:41:01 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3104012D0FF; Fri, 8 Apr 2016 06:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2na0yiz8YZkD; Fri, 8 Apr 2016 06:40:46 -0700 (PDT) Received: from athena.nowhere.ws (athena.nowhere.ws [146.0.105.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6154712D8B3; Fri, 8 Apr 2016 06:40:46 -0700 (PDT) Received: from [31.133.176.90] (dhcp-b05a.meeting.ietf.org [31.133.176.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by athena.nowhere.ws (qmail) with ESMTPSA id C62DFE005; Fri, 8 Apr 2016 13:40:43 +0000 (UTC) To: Stefan Winter , IETF OPSEC References: <20160321092737.6013.75371.idtracker@ietfa.amsl.com> <56EFBF2D.5090904@restena.lu> From: Christian Franke Message-ID: <5707B4D9.9010508@nowhere.ws> Date: Fri, 8 Apr 2016 10:40:41 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56EFBF2D.5090904@restena.lu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:40:58 -0000 On 03/21/2016 06:30 AM, Stefan Winter wrote: > this is the draft corresponding to my agenda slot request from last week. > Name: draft-winter-opsec-netconfig-metadata > Revision: 00 I have just read through your draft. In my opinion, it would be very useful to have a standardized way to provide configuration profiles to users. Looking through the draft and the yang file, I came up with the following notes: Comments on the draft: - it would be useful if subject alt match could be configured for usage with e.g. EAP-TTLS - how would the private key for a client certificate be stored, also in `cert-data`? I don't see another suitable field - which information does `allow-save` apply to? If it applies to the private key of a client certificate, how would public key authentication work without storing it? - can you provide a usecase for the `valid-until` field? - it is not obvious to me how the current model applies to VPN or E-Mail Server connections as named in the draft - it is not clear to me how an anonymous identify for EAP-TTLS or EAP-PEAP would be configured - I think it would be useful to have some consideration, either in this or another document, about how the files procuded according to this model should be processed, i.e. requirements on how their authenticity must be verified, how they should be displayed to the users and in what configuration they should actually result. Yang related: - there is a type leafref which should probably used when referring to config parts by UUID - there are types for ipv4 and ipv6 addresses that should be used instead of string - list IPAddress has dynamic and static as keys, keys need to be unique, so how to enable both dhcpv4 and dhcpv6? Same thing e.g. for DNS -Christian From nobody Sun Apr 10 08:18:26 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8354F12D5E9 for ; Sun, 10 Apr 2016 08:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 r-QvkHK4-HBI for ; Sun, 10 Apr 2016 08:18:23 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B1C12009C for ; Sun, 10 Apr 2016 08:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4746; q=dns/txt; s=iport; t=1460301502; x=1461511102; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=OLd0K1FJFpnw1J8RbiVYftZ261EsNAMkywTzTluT5Oc=; b=IAdQFiLx97Mc9uC/u+ObIh1ps0s16SamSqCqFczZMH9Plre/6rz/wg7m SduNK1XcsyOa5ocWbz2tf7ouePOpmsjQLiZaeTO05tpc8SIr+7DZhCG6H 9qEHgJHkzJbpeSsXPM4tNoRh/edYmy4qdigZpFA7ONIoG9EK58F6xjb82 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgB5bQpX/4gNJK1SCoM3uhaCDwENg?= =?us-ascii?q?XOGDQKBITgUAQEBAQEBAWUnhEIBAQQdG0ARCxgJFg8JAwIBAgFFBgEMCAEBiCO?= =?us-ascii?q?8CQEBAQEBAQEBAQEBAQEBAQEahiGES4QVBQ+FbAEEmASODIk5hVSPJh4BAUKBf?= =?us-ascii?q?4IEIIkfgTwBAQE?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="257813734" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2016 15:18:21 +0000 Received: from [10.24.211.202] ([10.24.211.202]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3AFIKd8031142; Sun, 10 Apr 2016 15:18:21 GMT To: Petr Lapukhov , "opsawg@ietf.org" References: <3F437107848A5140A6A19222EFFB3481200F061D@PRN-MBX01-2.TheFacebook.com> <5705529E.4020700@cisco.com> <3F437107848A5140A6A19222EFFB34812011BD6E@PRN-MBX01-2.TheFacebook.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <570A6EBB.8020902@cisco.com> Date: Sun, 10 Apr 2016 11:18:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3F437107848A5140A6A19222EFFB34812011BD6E@PRN-MBX01-2.TheFacebook.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Call for Agenda Items for Buenos Aires X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 15:18:24 -0000 On 4/6/16 15:08, Petr Lapukhov wrote: >> * How do you propose the populated data to be handled normally? Will >> the probe destination (i.e., the dest address of the UDP packet) be >> expected to understand these, or will loopback mode have to be used? >> The reason I ask is that I'm not sure what happens if all nodes in the >> network do not support this probe. Could this give more network insight >> to the destination, and thus be a security weakness? > > One of the main reasons to use regular data packet and not any special OAM format or IPv6 extension header is to let the packet pass through non-compliant devices transparently. The device that understand the request will fill in their data, but others will remain invisible (unless hop-by-hop variant is requests using router-alert option - but I doubt this would be viable given the state of hardware in the DC at the moment). > > For security concerns: this is a rather big topic in context of data-plane probe, and I haven't completed the section yet. Easy way out is saying "we control the network in DC and we are aware of security consequences of disclosing the device state". The header marker might help here - a random key value would need to be guessed by possible attacker. In addition, only select applications could be allowed to send the probes to the "special" port. Agreed this will need some fleshing out. Coming from a technical support background, I see the value in obtaining this information in all networks, even those without a single source of control. A thought on this might be that there is a flag that signals local storage on the device only. This way the data is recorded, but not in the packet itself. Instead, local buffers hold this where it can be queried later. > >> * Related to the question above what would happen if a set a hop count >> of four, but the fourth device (before my destination) has not awareness >> of this telemetry system? > > The responsibility for setting the right hop limit is on the sender. It needs to be aware there are devices that do not understand the form of signaling, and adjust hop-limit respectively. All non-compliant hops will be transparent. Worst case, if sender was clueless, the packet will just fall through to the other side just like a regular active probe. Understood. But how does the sender know/discover this? The network can change dynamically, and sending the packet without a good understanding of the intermediate nodes' support of the probe could result in the destination receiving this telemetry-rich packet when they shouldn't be. > >> * Why not use ifIndex values for port IDs? It seems to me that having a >> more standard and known cross-vendor way to identify ports is useful. > > This is a good idea: I heard this a few times already and I will change the spec accordingly :) It is hard to number the physical ser/des (e.g. BRCM has a way to do this in SDK, but others would likely be different). The tradeoff is that the ifIndex will need to be stored in some state table in hardware. Whatever value is chosen, it needs to be well-understood and easily queryable by the administrator. Normative language around ifIndex would be very clear, but I agree this may not be trivial to obtain in the ASIC. What I want to avoid is having to know vendor-by-vendor, hop-by-hop what this value represents and how to obtain a mapping to physcal/virtual port. > >> * You do not list IANA considerations, but it seems to me that your >> probe types would be well-suited for a registry that perhaps could live >> with IANA? It would also be useful to have some reserved space for >> private extensions where possible. > > I wasn't sure what kind of code-point could be requested. I think this is a very good point for "Type" registration, to ensure better interop. Maybe the chairs or others in the WG can suggest something. I would personally like a registry with space for reserved probe IDs exactly for interoperability and extension. > >> * I think you mentioned it at the mic, but the draft doesn't really >> address what happens if a device supports this telemetry system, but >> does not support a specific probe type? For example, what if I define >> type 50 down the road, but not all of my devices/hardware yet support >> this? What happens then? > > Right now the idea is that device will simply set the bit signaling that it does not understand the requested type, and leave the value in TLV empty (zero). The length is known to the device even if it does not understand the type. Ah, right. The length is known because the sender has filled in all the possible fields. Joe From nobody Tue Apr 12 06:41:13 2016 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBBF12DBD3; Tue, 12 Apr 2016 06:41:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160412134109.32190.42127.idtracker@ietfa.amsl.com> Date: Tue, 12 Apr 2016 06:41:09 -0700 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:41:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group of the IETF. Title : The TACACS+ Protocol Authors : Thorsten Dahm Andrej Ota Douglas C. Medway Gash David Carrel Lol Grant Filename : draft-ietf-opsawg-tacacs-02.txt Pages : 35 Date : 2016-04-11 Abstract: TACACS+ provides Device Administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document describes the protocol that is used by TACACS+. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-02 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 Wed Apr 20 00:28:37 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E3312E2C4 for ; Wed, 20 Apr 2016 00:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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.996, 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 GLWAafz0Ksdc for ; Wed, 20 Apr 2016 00:28:32 -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 9184D12D8A1 for ; Wed, 20 Apr 2016 00:28:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHY43296; Wed, 20 Apr 2016 07:28:27 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 20 Apr 2016 08:28:20 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 20 Apr 2016 15:27:48 +0800 From: Zhoutianran To: "Romascanu, Dan (Dan)" , Warren Kumari , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Minutes posted. Thread-Index: AQHRkEjbsvS0MBF9RkW/4Gt0yYAqHp987/aAgBWX0yA= Date: Wed, 20 Apr 2016 07:27:47 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA751BD7E7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA751BD7E7@AZ-FFEXMB04.global.avaya.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F2183BAD9B4NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57172F9C.0057, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6a16f0f9ed45b431d76ae5a58c9a7164 Archived-At: Subject: Re: [OPSAWG] Minutes posted. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 07:28:34 -0000 --_000_BBA82579FD347748BEADC4C445EA0F2183BAD9B4NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJIGhhdmUgcmV2aXNlZCB0aGUgbWludXRlIGFjY29yZGluZyB0byBEYW7igJlz IGluZm9ybWF0aW9uLg0KQW5kIGl0IHNlZW1zIG5vIG90aGVyIGNoYW5nZSBvbiB0aGUgbWludXRl Lg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9vcHNhd2cvbWludXRlcw0KDQoNClJlZ2FyZHMs DQpUaWFucmFuDQoNCkZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUm9tYXNjYW51LCBEYW4gKERhbikNClNlbnQ6IFRodXJzZGF5LCBBcHJp bCAwNywgMjAxNiA1OjI5IEFNDQpUbzogV2FycmVuIEt1bWFyaTsgb3BzYXdnQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW09QU0FXR10gTWludXRlcyBwb3N0ZWQuDQoNCkhpLA0KDQpPbiB0aGUgQXV0 b21hdGljIEF0dGFjaG1lbnQgc2VjdGlvbjoNCg0KT0xEOg0KDQoNCkRhbjogQ2FuIGJlIGFwcGxp Y2FibGUgdG8gb3RoZXIgdHlwZXMgb2YgdHVubmVscy4gTm90IGFza2luZyBmb3IgbmV3IHByb3Rv Y29sLiBQcm92aWRpbmcgYSByZXBvcnQuDQoNClNoYWhyYW06IFRoZXJlIHNlZW1zIHRvIGJlIGEg bWl4IG9mIHJlcXVpcmVtZW50cywgZGlzY3Vzc2lvbiwgb3RoZXIgaW4gZG9jLg0KDQpEYW46IFll cy4gSXQgbmVlZHMgdG8gYmUgY2xlYW5lZCB1cC4NCg0KRGllZ28gTG9wZXogY29tbWVudGVkLg0K DQpORVc6DQoNCkRhbjogQ2FuIGJlIGFwcGxpY2FibGUgdG8gb3RoZXIgdHlwZXMgb2YgdHVubmVs cy4gTm90IGFza2luZyBmb3IgbmV3IHByb3RvY29sLiBEZXNjcmliaW5nIHNvbHV0aW9uIHRvIGFu IG9wZXJhdGlvbmFsIHByb2JsZW0uDQpTaGFocmFtOiBUaGVyZSBzZWVtcyB0byBiZSBhIG1peCBv ZiByZXF1aXJlbWVudHMsIGRpc2N1c3Npb24sIG90aGVyIGluIGRvYy4NCkRhbjogWWVzLiBJdCBu ZWVkcyB0byBiZSBjbGVhbmVkIHVwLiBQbGFuIHRvIHNwbGl0IGRvY3VtZW50cyBpbiBzZXBhcmF0 ZSBJLURzLg0KRGllZ28gTG9wZXogZXhwcmVzc2VkIGludGVyZXN0IGFuZCBjb21tZW50ZWQuDQoN ClJlZ2FyZHMsDQoNCkRhbg0KDQoNCkZyb206IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2FycmVuIEt1bWFyaQ0KU2VudDogVGh1cnNkYXksIEFw cmlsIDA3LCAyMDE2IDEyOjA4IEFNDQpUbzogb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dA aWV0Zi5vcmc+DQpTdWJqZWN0OiBbT1BTQVdHXSBNaW51dGVzIHBvc3RlZC4NCg0KSGkgYWxsLA0K DQpUaGFua3MgdG8gQmFyYmFyYSBmb3IgdGFraW5nIG1pbnV0ZXMuDQpEcmFmdCBtaW51dGVzIGhh dmUgYmVlbiBwb3N0ZWQsIHBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IGlmIGFueXRoaW5nIHlv dSBzYXkgd2FzIG1pc3JlcHJlc2VudGVkLg0KDQpXDQo= --_000_BBA82579FD347748BEADC4C445EA0F2183BAD9B4NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuaWsOWui+S9kzsNCglw YW5vc2UtMToyIDEgNiA5IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5paw5a6L5L2TIjsNCglwYW5vc2UtMToyIDEg NiA5IDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuag vOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRl LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpw LkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5IVE1MUHJlZm9ybWF0 dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQt ZmFtaWx5OuWui+S9kzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgcmV2aXNlZCB0aGUgbWludXRlIGFjY29yZGluZyB0 byBEYW7igJlzIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmQgaXQgc2Vl bXMgbm8gb3RoZXIgY2hhbmdlIG9uIHRoZSBtaW51dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvb3BzYXdnL21pbnV0ZXMiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvd2cvb3BzYXdnL21pbnV0ZXM8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5Sb21hc2NhbnUsIERhbiAoRGFuKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg QXByaWwgMDcsIDIwMTYgNToyOSBBTTxicj4NCjxiPlRvOjwvYj4gV2FycmVuIEt1bWFyaTsgb3Bz YXdnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT1BTQVdHXSBNaW51dGVzIHBv c3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+T24gdGhlIEF1dG9tYXRpYyBBdHRhY2htZW50IHNlY3Rpb246DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0xEOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkRhbjogQ2FuIGJlIGFwcGxpY2FibGUg dG8gb3RoZXIgdHlwZXMgb2YgdHVubmVscy4gTm90IGFza2luZyBmb3IgbmV3IHByb3RvY29sLiBQ cm92aWRpbmcgYSByZXBvcnQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlNoYWhyYW06IFRoZXJlIHNlZW1zIHRvIGJl IGEgbWl4IG9mIHJlcXVpcmVtZW50cywgZGlzY3Vzc2lvbiwgb3RoZXIgaW4gZG9jLjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj5EYW46IFllcy4gSXQgbmVlZHMgdG8gYmUgY2xlYW5lZCB1cC48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RGll Z28gTG9wZXogY29tbWVudGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TkVXOg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkRhbjog Q2FuIGJlIGFwcGxpY2FibGUgdG8gb3RoZXIgdHlwZXMgb2YgdHVubmVscy4gTm90IGFza2luZyBm b3IgbmV3IHByb3RvY29sLiBEZXNjcmliaW5nIHNvbHV0aW9uIHRvIGFuIG9wZXJhdGlvbmFsIHBy b2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5TaGFocmFtOiBUaGVyZSBzZWVtcyB0byBiZSBh IG1peCBvZiByZXF1aXJlbWVudHMsIGRpc2N1c3Npb24sIG90aGVyIGluIGRvYy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPkRhbjogWWVzLiBJdCBuZWVkcyB0byBiZSBjbGVhbmVkIHVwLiBQbGFuIHRv IHNwbGl0IGRvY3VtZW50cyBpbiBzZXBhcmF0ZSBJLURzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ RGllZ28gTG9wZXogZXhwcmVzc2VkIGludGVyZXN0IGFuZCBjb21tZW50ZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9QU0FXRyBbPGEgaHJlZj0ibWFp bHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5XYXJyZW4gS3VtYXJpPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiAxMjowOCBBTTxicj4NCjxiPlRvOjwvYj4gPGEg aHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBbT1BTQVdHXSBNaW51dGVzIHBvc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRoYW5rcyB0byBCYXJiYXJhIGZvciB0YWtpbmcgbWludXRlcy4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RHJhZnQgbWludXRlcyBoYXZlIGJlZW4gcG9zdGVkLCBw bGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdyBpZiBhbnl0aGluZyB5b3Ugc2F5IHdhcyBtaXNyZXBy ZXNlbnRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Plc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BBA82579FD347748BEADC4C445EA0F2183BAD9B4NKGEML515MBXchi_-- From nobody Wed Apr 20 12:49:15 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7C112D1AF for ; Wed, 20 Apr 2016 12:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 JpsXjofyh_61 for ; Wed, 20 Apr 2016 12:49:12 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5569D12DF8E for ; Wed, 20 Apr 2016 12:49:12 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id c6so35704172qga.1 for ; Wed, 20 Apr 2016 12:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=h3NJp0htPXQfNz95s9uLLQD75NtA4A1yAfO143HRZbI=; b=fuwTHUKYPuAoaaWcWDZRTITjQPu97sgnYzsz07KNkLEFfT0tJz5uqH5WLol5ZDfBXE t/CbbQI/+lj2yrrUOWHvN3WjfXD/XusTi69hdDPsVG36c/7VVWASrKZQNeGpE4+wZdZz xqiRD6pEYbD4rejNd4I5q9BySxy3VOS1eqhalpKwbEnLZS8iRf6dkabMs2QLOY+Fl5Xn OsjtWboP8EEX0EsA0AeNBFwi4LIk/U8cf8FHyyVhvr/Im2MAnjicsvjggPo/pez/THKT uMN3UPTFO4Lz4RI2EbiuBNoxm9SPxCq86Ex6KaeFxFsZYhxlkqND49YAvzjuAIoh7cIj KAuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=h3NJp0htPXQfNz95s9uLLQD75NtA4A1yAfO143HRZbI=; b=FnIkrlFNmiOeD/dyweo5PFCxSKj0mCkhFmz+cQaoCHKg1pv4LPMdFgSxBq8HdGF95f 3ZHYWxURGxzys2fV7mBC3vwL11TsfWdqPVT5qV0oulYOWguXG6whO0ZdvU6WlkDMI+Zk +sJyCuJxPg14/SJboytpW+OYqqJZQHPHWJj5J5XCcN+SUj69a0CnCg/u1yyqjwfJKBHa lsqodDDV9dJKV7JnsDeaANwgLry4PCOi+9YLs6nRntUhwVHUUNPhkqseAR5waBbLBkj/ /g8evfCf3qx0RmbuGHybHRvORhFE/x10XP7x/FdMpqH6mO9Y/yvjE5eJv7/QN4Nb/vUg 4ylA== X-Gm-Message-State: AOPr4FWyXXeGeYTL/lHOQvG+Rq944G/w+BMj5PubPcEwBwc0l3LgbgdzoLhHv3SyFGT43sfdRovRcteXx+NJ/rHh X-Received: by 10.140.30.246 with SMTP id d109mr13019798qgd.25.1461181751339; Wed, 20 Apr 2016 12:49:11 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Wed, 20 Apr 2016 19:49:02 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a113a67683dc1c10530efe3e8 Archived-At: Subject: [OPSAWG] TACACS+ informational document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:49:14 -0000 --001a113a67683dc1c10530efe3e8 Content-Type: text/plain; charset=UTF-8 Hi there all, The authors of draft-ietf-opsawg-tacacs have updated the document and would like some review. As a reminder, this document is supposed to describe how TACACS currently works. We will then publish a new document which improves the security of TACACS. I'd really appreciate it if people could review the current document (Link for easy clicking: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/) and provide feedback to the list by Friday April 29th. W --001a113a67683dc1c10530efe3e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi there all,

The authors of=C2=A0draft= -ietf-opsawg-tacacs have updated the document and would like some review.= =C2=A0

As a reminder, this document is supposed to= describe how TACACS currently works.
We will then publish a new = document which improves the security of TACACS.

I&= #39;d really appreciate it if people could review the current document (Lin= k for easy clicking:=C2=A0https://datatracker.ietf.org/doc/draft-ietf-opsawg-ta= cacs/) and provide feedback to the list by Friday April 29th.

W
--001a113a67683dc1c10530efe3e8-- From nobody Thu Apr 21 07:18:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F3612DFB9 for ; Thu, 21 Apr 2016 07:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5mN8Ri8tgRE8 for ; Thu, 21 Apr 2016 07:18:19 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0212DB1D for ; Thu, 21 Apr 2016 07:18:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 423781BE1; Thu, 21 Apr 2016 14:18:18 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GR8Wo9nFtUb; Thu, 21 Apr 2016 14:18:18 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 8FD84B8F; Thu, 21 Apr 2016 14:18:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 21 Apr 2016 10:18:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] TACACS+ informational document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 14:18:21 -0000 On Apr 20, 2016, at 3:49 PM, Warren Kumari wrote: > I'd really appreciate it if people could review the current document = (Link for easy clicking: = https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/) and provide = feedback to the list by Friday April 29th. Overall, it's a lot more focussed than the original draft. This is = good. More detailed comments: Section 2 ... Authentication generally takes place when the user first logs in = to a machine or requests a service of it. What is meant by "requests a service of it" ? The subsequent = paragraph explains in a bit more detail, but the phrasing here sounds = awkward. Also "log into a machine" is a bit vague. Perhaps also use = "privilege" as per the subsequent text: ... Authentication generally takes place when the user first = connects to the machine for device administration, and may also happen later when additional privileges are requested. Authentication is not mandatory; it is a site-configured option. I would suggest adding "... not mandatory in the protocol". =46rom a = security point of view, unauthenticated device administration is bad. ... The server receives TACACS+ protocol requests, and replies = according to its business model What's a "business model" in relation to a protocol? Perhaps it could = instead say ... The server receives TACACS+ protocol requests, and replies = according to its configured policy Section 3.1.1 ... It is NOT recommended to deploy TACACS+ without Body encryption, other than for test environments. Perhaps "NOT RECOMMENDED" 3.2. Session The concept of a session is used throughout this document. A TACACS+ session is a single authentication sequence, a single authorization exchange, or a single accounting exchange. I find that a little confusing. When an admin logs into a device, the = common terminology is to call one particular connection as a session. = i.e. user logs in at 10am, runs 3 commands, and logs out at 10:10am. Using "session" to refer to request/reply exchanges is a bit = confusing.=20 3.3. Single Connect Mode The packet header (see below) contains a flag to allow sessions to be multiplexed on a connection. If a client sets this flag, this indicates that it supports multiplexing TACACS+ sessions over a single TCP connection.=20 Can exchanges for multiple *users* be sent over a single TCP = connection? The document doesn't seem to say anything about this. =46rom Section 3.4: ... The sequence number must never wrap i.e. if the sequence number = 2^8-1 is ever reached, that session must terminate and be restarted with a sequence number of 1. I have a few questions about this. The use of "session" here is = confusing. It was earlier defined to be a request/reply exchange. But = here the implication is that it's something else. Perhaps what's meant = is a "connection"? There is also the implication that the authentication / authorization = process starts again. It would be good to clarify this text to use a = term other than "session". And to explain what happens when a = session/connection is restarted. If the intention is to open a new TCP connection, we presume that the = user must re-authenticate. Do they use the same credentials as last = time? How are these cached on the client? ... session_id The Id for this TACACS+ session. The session id should be randomly chosen. This field does not change for the duration of the TACACS+ session. (If this value is not a cryptographically strong random number, it will compromise the protocol's security, see RFC 1750 Again, what is meant by "session" here? If we use the definition from = Section 3.2, a session is a request/reply exchange. So can the = "session_id" be different for every exchange? I presume not, otherwise = the authentication step couldn't be associated with subsequent = authorization an accounting steps. I suggest changing Section 3.2 to use a term other than "session". = Perhaps "exchange" would be better. The term "session" should be = reserved for a series of authentication / authorization / accounting = exchanges, which are all tied to the same user login. I see this change = as critical to getting the document published. As it stands today, I = have no real idea what a "session" is, as it's used in multiple = contradictory ways. ... length The total length of the packet body (not including the header). This value is in network byte order. Packets are never padded beyond this length. I'm not sure what is meant by "packets are never padded". This is = TCP, not UDP. UDP packets can be larger than the application data = packets they transport. TCP cannot, as it is a stream protocol. Perhaps what is meant here is that the data following "length" octets = MUST be another valid TACACS+ header. And the corollary (from a security perspective) is that any time the = data is *not* a valid TACACS+ header, the TCP connection MUST be = dropped. The alternative is to read through streams of random garbage, = hoping that perhaps something will decode as a correct TACACS+ packet. Section 3.5; - There should be no padding in any of the fields or at the end of a packet. This is another way of saying that the "length" field isn't lying to = you. I'm not opposed to this statement, I'm just wondering why it's = necessary. 3.6. Encryption 3.6.1. Body Encryption In general it's bad form to have 2 section headers immediately = following one another. I would suggest adding a sentence after the 3.6 header which = re-iterates the earlier comments saying "yes, this isn't really = encryption, but it was designed 20 years ago, and this is the = terminology used in the protocol." ... NOTE: Implementations should take care not to skip decryption = simply because an incoming packet indicates that it is not encrypted. If the unencrypted flag is not set, and the packet is not encrypted, it must be dropped. That isn't very clear to me. Double negatives tend to be hard = understand. The use of encryption should be an administrative decision, and = enforced on the wire. e.g. If the configuration has a shared secret = and/or says that encryption is required, then packets received without = encryption MUST be dropped, and the TCP connection MUST be closed. Similarly, if the configuration has no shared secret or says that = encryption is not used, then packets received with encryption MUST be = dropped, and the TCP connection MUST be closed. ... After a packet body is decrypted, the lengths of the component = values in the packet should be summed and checked against the cleartext datalength value from the header. Any packets which fail this check should be discarded and an error signalled. And also the TCP connection should be dropped. If the packet is = malformed, and the shared secret doesn't match, there is no point in = keeping the TCP connection open. The only thing that can be exchanged = is garbage data, which isn't useful to anyone. If an error must be declared but the type of the incoming packet cannot be determined, a packet with the identical cleartext header but with a sequence number incremented by one and the length set to zero MUST be returned to indicate an error. And then the TCP connection should be dropped. Section 4.1 It would be good to explain what the various "len" fields mean. It's = implied from context, but as a protocol specification, explicit = description is preferred to implicit understanding. Similar comments apply for the rest of the packet bodies. The 'len" = fields are given in the ASCII diagram, but not further explained or = referred to. ... user The username. It is encoded in [UTF-8]. It is optional in this packet, depending upon the class of authentication. What does it mean to be "optional"? Perhaps the "user_len" field is = equal to zero, which means that the "user" field does not exist. Also, since "user_len" is 8 bits, it would be good to note that the = maximum "user" name which can be exchanged is 255 octets. Similar text should be added to the other fields. That's it for now. I'll post more later. Alan DeKok. From nobody Thu Apr 21 19:06:33 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD33012DAE8 for ; Thu, 21 Apr 2016 19:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 v-H8_t3q8QD4 for ; Thu, 21 Apr 2016 19:06:29 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8B612DA03 for ; Thu, 21 Apr 2016 19:06:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C85F91CB8; Fri, 22 Apr 2016 02:06:28 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDWPI3ZcGCzT; Fri, 22 Apr 2016 02:06:28 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id D399DB99; Fri, 22 Apr 2016 02:06:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 21 Apr 2016 22:06:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <946763DD-7EBE-44F2-B94E-910B55FBDE6C@deployingradius.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] TACACS+ informational document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 02:06:31 -0000 More comments... 4.4. Description of Authentication Process Authentications are classified by the action, authen_type and service fields in the START packet of the authentication Session. The user, priv_lvl, service, port and rem_addr in the START packet are all provided to help identify the conditions on the client What is meant by "conditions on the client"? It would be best to = describe what those fields mean instead. ... The information necessary to transact the authentication is passed = ... What is "information necessary to transact the authentication"? This = sounds unclear to me. ... A set of standard authentication classifications is defined in = this document. =20 What is meant by "authentication classifications" ? It's not clear = from the context or the rest of the document. Perhaps it means = "authentication protocols" ? i.e. one exchange is done for PAP, another = for MS-CHAP, another for OTP, etc. ... When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, then authentication continues and the server_msg may be used by the client to prompt the user for more information. "may be used"? What happens when the client doesn't use server_msg to = prompt the user? ... All three cause the same action to be performed, but in the case = of TAC_PLUS_AUTHEN_STATUS_GETUSER, the client can know that the information that the user responds with is a username, and for TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a password. I'm wary of statements such as "the client can know..." Is that a = philosophical statement? It's generally best to describe actions instead of knowledge. e..g. = "for prompts using TAC_PLUS_AUTHEN_STATUS_GETUSER, the users response is = interpreted by the client as a username, for use in subsequent = exchanges". ... TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents = a password. Similar comments apply here. ... TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic request for more information. And what happens then with the data? When is this message used? 4.4.1. Version Behaviour ... in the table below: LOGIN CHPASS SENDAUTH ASCII v0 v0 NA PAP v1 NA v1 CHAP v1 NA v1 MS-CHAP v1 NA v1 What does "NA" mean? I suspect I know, but it's good to be explicit = instead of assuming that the reader knows the authors intent. ... The removal of SENDPASS was prompted by security concerns, and is no longer considered part of the TACACS+ protocol. It may be worth considering the removal of all documentation of = SENDPASS. If it's not just deprecated by removed entirely, then it = should probably be just removed entirely. 4.4.2. Common Authentication Flows This section describes the authentication flows that should be supported. What is meant by "should be supported"? Is this an RFC 2119 = statement? Or are these examples of authentication flows which are in = common use, and that all clients && servers are expected to support? ... A PAP authentication only consists of a username and password=20 RFC 1334 [RFC1334] . I think referencing a later RFC is preferable. (chap) ... The length of the challenge value can be determined from the = length of the data field minus the length of the id (always 1 octet) and the length of the response field (always 16 octets). This would seem to impose limits on the "date len" field. It would be = good to state these explicitly. Also, to indicate that the challenges MUST have a minimal length, = which should probably be no less than 8, though 16 is suggested. The = alternative is to allow zero-length challenges, which is not good. And how are the challenge, ID, and response fields packed into the = data field? i.e. in what order are they packed? ASCII art would be = *very* helpful here.=20 Similar comments apply for MS-CHAPv1 and MS-CHAPv2 authentication. 4.4.3 ... When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet indicates that the TACACS+ server requests that authentication should be performed with an alternate server. The data field MUST contain ASCII text describing one or more servers. A server description appears like this: [@@]>[@] Examples would help here. The above text isn't ABNF, or any other = machine-readable definition of a text string. Perhaps the text could be updated to say that "@" is a delimiter. for = text strings: 0 @ =3D host 1 @ =3D host@key 2 @ =3D @protocol@host 3 @ =3D @protocol@host@key ... If a key is supplied, the client MAY use the key in order to authenticate to that host. If more than one host is specified, they MUST be separated by an ASCII Carriage Return (0x0D). Some questions here. What happens if the client doesn't want to use = that key? What happens if the client is pre-provisioned with a = different key than what is supplied here? If there are multiple hosts, = does the client use the supplied key for all of them? What if the = client has a disparate set of keys for the list of hosts? ... This packet is only currently intended for PPP authentication when multiple authentication mechanisms are available and can be negotiated between the client and the remote peer. This also requires future PPP authentication extensions which have not yet been passed through the IETF. Are users performing device administration over PPP? If that isn't = the 99% case, then I suggest re-wording the paragraph. Also, updating it to clarify what it means for "future PPP = extensions". Perhaps just removing that sentence would be best. 5. Authorization ... The authorization REQUEST message contains a fixed set of fields = that describe the authenticity of the user or process, What is "authenticity" of a user? ... priv_lvl This field matches the priv_lvl field in authentication request a What does this statement mean? Does the field (length and value) have = to be identical to the field in the authentication request? If not, why = not, and what happens? If so, it would be better to just say that it = MUST be identical. Similar comments apply for the other fields. = "match" is a word which should be used in the context of "A must match = B", instead of "is used for matching". The first is concrete and = implementable. The second is more philosophical than protocol oriented. ... Attribute-value strings are not NULL terminated, rather their = length value indicates their end. The maximum length of an attribute-value string is 255 characters. Are zero-length strings allowed? I presume not, but it would be good = to say so. 7. Attribute-Value Pairs ... A value of NULL means an attribute with a zero length string for = its value i.e. cmd=3DNULL is actually transmitted as the string of 4 characters "cmd=3D". That seems contradictory.. NULL is encoded by not encoding it.. = Perhaps the text could instead say: Attributes which have no value are transmitted as the attribute name, = followed by the mandatory or optional flag. The value is elided. For = example, the attribute "cmd" which has no value is transmitted as a = string of 4 characters "cmd=3D" ... acl US-ASCII number representing a connection access list. Used only when service=3Dshell and cmd=3DNULL I would suggest eliding the NULL here, too. The temptation for naive = implementors would be to encode an actual string "NULL". =20 There should be a separate "Security Considerations" section as = Section 9. It should explain all of the issues with the protocol, such = as the use of "encryption", etc. Alan DeKok. From nobody Fri Apr 22 05:13:47 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA44C12DC61 for ; Fri, 22 Apr 2016 05:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 kVsnydVSRU6v for ; Fri, 22 Apr 2016 05:13:43 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 AD3ED12DAB9 for ; Fri, 22 Apr 2016 05:13:43 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 102E443B03 for ; Fri, 22 Apr 2016 14:13:42 +0200 (CEST) To: "opsawg@ietf.org" References: From: Stefan Winter Organization: RESTENA Message-ID: <571A1575.4030400@restena.lu> Date: Fri, 22 Apr 2016 14:13:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] TACACS+ informational document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:13:45 -0000 Hi, the draft states: user The username. It is encoded in [UTF-8]. It is optional in this packet, depending upon the class of authentication. The old expired draft from 1997 states: user The username. It is optional in this packet. Somehow, an explicit encoding requirement made it into the new draft. It's good to be explicit when designing a protocol; but when it comes to documenting deployed reality it's important to be sure that this really *is* the deployed reality. Are you sure / how sure are you that deployed reality agrees with this change of wording? Greetings, Stefan Winter Am 20.04.2016 um 21:49 schrieb Warren Kumari: > Hi there all, > > The authors of draft-ietf-opsawg-tacacs have updated the document and > would like some review. > > As a reminder, this document is supposed to describe how TACACS > currently works. > We will then publish a new document which improves the security of TACACS. > > I'd really appreciate it if people could review the current document > (Link for easy > clicking: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/) > and provide feedback to the list by Friday April 29th. > > W From nobody Fri Apr 22 05:38:51 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB7212DB20 for ; Fri, 22 Apr 2016 05:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0mTghn0Cblst for ; Fri, 22 Apr 2016 05:38:45 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 87E0212D92E for ; Fri, 22 Apr 2016 05:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id E5B321ABD; Fri, 22 Apr 2016 12:38:44 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQD53Yzz3uXL; Fri, 22 Apr 2016 12:38:44 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 726104CD; Fri, 22 Apr 2016 12:38:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 22 Apr 2016 08:38:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <35A816AD-6739-4CF3-AD78-3045A029AE89@deployingradius.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] TACACS+ informational document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:38:48 -0000 A short summary: - many fields are named but not defined - structures with multiple fields are described, but field order is not = defined - terms are used inconsistently - the document is silent on critical points - how do user logins map to TCP connections? 1-1? 1-N? N-M? - can the same session_id be used in multiple TCP connections? - the general tone seems philosophical: systems "know" things, not = prescriptive: systems "do" things. - edge cases are not discussed - what happens with zero-length fields? - common use-cases aren't described (e.g. inter-site use of the = protocol) - the security considerations section is minimal - how do the edge cases affect security? - is the TCP connection closed when the key is found to be wrong? If = not, why not? - what are best practice recommendations for deployment? - what impact does inter-site deployment have on security? As an implementor, I would have to guess at large portions of the = protocol, or I would have to read the source to existing = implementations. The draft as is stands today can get me ~90% of the = way to implementing the protocol, but critical portions are not present. Alan DeKok. From nobody Fri Apr 22 08:41:45 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2612412DC43 for ; Fri, 22 Apr 2016 08:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 8zv8-fuAfMZt for ; Fri, 22 Apr 2016 08:41:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 C292112DB41 for ; Fri, 22 Apr 2016 08:41:42 -0700 (PDT) Received: from [21.62.19.182] ([172.56.39.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u3MFfaBN052645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Apr 2016 15:41:37 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (13E238) In-Reply-To: <35A816AD-6739-4CF3-AD78-3045A029AE89@deployingradius.com> Date: Fri, 22 Apr 2016 08:41:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C57DC37-EBA1-46A6-9DA6-4AC4588B737F@bogus.com> References: <35A816AD-6739-4CF3-AD78-3045A029AE89@deployingradius.com> To: Alan DeKok Archived-At: Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] TACACS+ informational document. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 15:41:44 -0000 Thanks,=20 This is useful feedback. > On Apr 22, 2016, at 05:38, Alan DeKok wrote: >=20 > A short summary: >=20 > - many fields are named but not defined >=20 > - structures with multiple fields are described, but field order is not de= fined >=20 > - terms are used inconsistently >=20 > - the document is silent on critical points >=20 > - how do user logins map to TCP connections? 1-1? 1-N? N-M? >=20 > - can the same session_id be used in multiple TCP connections? >=20 > - the general tone seems philosophical: systems "know" things, not prescri= ptive: systems "do" things. >=20 > - edge cases are not discussed >=20 > - what happens with zero-length fields? >=20 > - common use-cases aren't described (e.g. inter-site use of the protocol) >=20 > - the security considerations section is minimal >=20 > - how do the edge cases affect security? >=20 > - is the TCP connection closed when the key is found to be wrong? If not= , why not? >=20 > - what are best practice recommendations for deployment? >=20 > - what impact does inter-site deployment have on security? >=20 >=20 > As an implementor, I would have to guess at large portions of the protoco= l, or I would have to read the source to existing implementations. The draf= t as is stands today can get me ~90% of the way to implementing the protocol= , but critical portions are not present. >=20 > Alan DeKok. >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From nobody Fri Apr 22 10:48:35 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD912E0EA for ; Fri, 22 Apr 2016 10:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 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, TRACKER_ID=1.306] 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 ujHAd3QSLKrv for ; Fri, 22 Apr 2016 10:48:32 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3F512E11A for ; Fri, 22 Apr 2016 10:48:32 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id e190so83596470lfe.0 for ; Fri, 22 Apr 2016 10:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=fzhrL+hEyf52hnnoLNGB+VzG6Iwu2qgMBR7FGvdFxt0=; b=JNBsJ1/NM2Njn70Hs6andOG+2zQ52FpQB8afvz4j4TRgezGZrxxsQwvozA1wK3lLwi lNYq8/Wqy0lSHT8ZYtdQ0PBPe/6XSLLy7uSZ+7ayNd6O5pQNZ6AXr/VV0JuViggYXnPP 7QpTdEh9pshuePdPcxhq7PJx1kLoJzTQw5WsJWqCm/eY52A8vsJRNUgPu9ccRjTvSNP1 b1YRVj/SMkhHPVYpg3yod4kWmzviVy80YI6H4HHnrPRgUwT0yG1Dag1ikuQn6Rj2XCZD 7joBRL+HdRHfBFV7aDjZvjtpLbHopYkXZfmognj1i99M1TT7js07w1Jwr41isimZDbSK BUQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=fzhrL+hEyf52hnnoLNGB+VzG6Iwu2qgMBR7FGvdFxt0=; b=fXA4ppYiKpo083GS5s5u6TDuwPenyL8HOXOKLzSkvNTibgqQUXJXIiMThIdMf3auMI lydy7GxrcpBdE0agiwkGW7EOYWWuV1mV3XViYmuh3RHgPf3A9Kts7wCbOXq09bTohVmL FUh/ranKrC6Xc+SQgM486Dm+2UJKcIZF08zLYPBmHh05zz9hOW36rtliMIQc90y9RyRq aCG9pUWIjYTyN1MJhe2DeRiqHf+sGT2GfWcXhZcnxh/q60qk1vbbZ+cM5JjGzFP0nfDy CyshrvTnfNuAboSdf0iLU4t7j6sD9qSTlxuUxrR1KJn201Z35AAORBiT6S51SyE+dQCk 5vmw== X-Gm-Message-State: AOPr4FXTK/lwCuAHK85tZnVuxYMXgDfWrV9arCuofg/MSFNjpgXp58TN5PnHBrJsWjL4WBDarN4HfUIfzLaiFA== MIME-Version: 1.0 X-Received: by 10.25.154.5 with SMTP id c5mr9875346lfe.85.1461347310449; Fri, 22 Apr 2016 10:48:30 -0700 (PDT) Received: by 10.114.69.179 with HTTP; Fri, 22 Apr 2016 10:48:30 -0700 (PDT) Date: Fri, 22 Apr 2016 23:18:30 +0530 Message-ID: From: Mahesh Govind To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=001a1140346c553e7c0531166f58 Archived-At: Subject: [OPSAWG] opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 17:48:34 -0000 --001a1140346c553e7c0531166f58 Content-Type: text/plain; charset=UTF-8 Hi, Could you please let me know whether any one has implemented the draft ( opsawg-capwap-alt-tunnel ) regards Mahesh --001a1140346c553e7c0531166f58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Could you please let me know = whether any one has implemented the draft (opsawg-capwap-alt-tunnel)=C2=A0

<= /div>
regards
Mahesh

--001a1140346c553e7c0531166f58-- From nobody Fri Apr 22 11:44:06 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E5612D5A4 for ; Fri, 22 Apr 2016 11:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.496 X-Spam-Level: X-Spam-Status: No, score=-14.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Mq2x5mnD2g1e for ; Fri, 22 Apr 2016 11:44:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E840E12D9E2 for ; Fri, 22 Apr 2016 11:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3701; q=dns/txt; s=iport; t=1461350642; x=1462560242; h=subject:references:cc:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=U7TEIGrsabCVJaTPVZcionTT4a+NND7cxhQg/Deuj4k=; b=TIzRW9ZjyPUO+/tz944q1uhCr+eUz5odV6gxOpU8XnSz3B48jF4jiBDw 1WZ5EFqXeKIM4y1326DQD35250bUosdXybES9LTgKjpuwpBQFawEsilXV IEp4o1IBZzN0fQxNSfak7aBbYnXw9oxg0EZLjbI6b7ZaGSeZsfdwU6uCu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7CQCMcBpX/4ENJK1egzhTK0YMpmOJb?= =?us-ascii?q?Yk3AQ2BcxcLhSJKAiiBBDgUAQEBAQEBAWUnhDkJAQEEAQEBNTQCCAMQCxgYFic?= =?us-ascii?q?wEwYCAQGFboI4Dr9vAQEBAQEBAQMBAQEBAQEahiGBdYJWhQ2CQoJGAQSYD4V7i?= =?us-ascii?q?BmBZk6Df4MGI4U0jy8eAQFCggYagWcgMIh7AQEF?= X-IronPort-AV: E=Sophos;i="5.24,518,1454976000"; d="scan'208";a="264097410" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2016 18:43:51 +0000 Received: from [10.150.54.119] (dhcp-10-150-54-119.cisco.com [10.150.54.119]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3MIhpK7017067 for ; Fri, 22 Apr 2016 18:43:51 GMT References: <20160412134109.32190.42127.idtracker@ietfa.amsl.com> Cc: opsawg@ietf.org From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: Date: Fri, 22 Apr 2016 14:43:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160412134109.32190.42127.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 18:44:04 -0000 I've done a quick read-through of the draft, and I have a few comments. * Assuming someone is completely unfamiliar with T+ and they came across this draft, they might assume "TACACS" stood for something, but it is not expanded. Since this draft describes the protocol, I think it would be good to expand the acronym in the intro paragraph. * There are terminology spread throughout the draft (e.g., MD5, 'TheDraft', session, etc.). I've seen such things summarized early on in a glossary in other long drafts. It might make it easier for a reader to refer to if that was done here as well. * There is a lot of use of NULL in this document where you either mean NUL byte termination or an empty field. It would be helpful to clarify the usage where you mean a NUL ASCII byte or a field with a zero length value. * In Section 4.1, the username is stated to be encoded in UTF-8. This is not the case in the _current_ implementation of the protocol. A code inspection of at least the tac_plus4 module shows this is as US-ASCII as some of the other fields. * In Section 4.1 as well, the various AUTHEN_SVC types are defined, but only ENABLE (and NONE to some extent) is really described. It would be useful to describe the others as well. * In Section 4.2, the "data" field is mentioned and says it will be described in more detail per authen_type below. Since the START, REPLY, and CONTINUE packets each have a "data" field, and they're respective sections all point to details "below," it's hard to discern what field is being described. While I was able to figure out what I'd see in various START and CONTINUE packets, I didn't see much on what I'd see in the REPLY. For example, where can I expect to see custom authn prompts pushed? * In Section 5.1, you define TAC_PLUS_AUTHEN_METH_LINE as a "fixed password associated with the line used to gain access." I don't think it's clear what a "line" is. It might be better to say "terminal line" or "terminal port." That's it for now. Joe On 4/12/16 09:41, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operations and Management Area Working Group of the IETF. > > Title : The TACACS+ Protocol > Authors : Thorsten Dahm > Andrej Ota > Douglas C. Medway Gash > David Carrel > Lol Grant > Filename : draft-ietf-opsawg-tacacs-02.txt > Pages : 35 > Date : 2016-04-11 > > Abstract: > TACACS+ provides Device Administration for routers, network access > servers and other networked computing devices via one or more > centralized servers. This document describes the protocol that is > used by TACACS+. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-02 > > > 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/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Apr 22 20:32:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B3712D107 for ; Fri, 22 Apr 2016 20:32:42 -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 3_m5B3YoRvIY for ; Fri, 22 Apr 2016 20:32:40 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 AA4F412E3C2 for ; Fri, 22 Apr 2016 20:32:39 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id b1so46626072lbi.1 for ; Fri, 22 Apr 2016 20:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=ucxLTCfy+SSQPXMerDRH9v/9ToSOL8v+DBR2KaENPVo=; b=SpEvKRT518s44OA+GlBkluWkrG9Nt8jHdq9AnT9AWqIU0aXCxbjCDOUHEbJjTXrRZR DHFVbnbammqJ9KF/ODW0EOBUUZtmZRGCmKcQ1NFsGN/GliMbZXxeLnygLq9LVD+mVwmM LR3ZQVWc32+gXnldpNeysMsx+vQkA0EPp8GEqvO3o9eC6SgPVNA/Wp2LnwQ8LkkIreXz JPapUaBKG28dhIVGrHsoLvewmkdO7mAg76hqGjc0nlw1+7KU8sbDQQSSJSx/oHxAoJle mqzAq7o53Akv55lRV6gI6aqwv+uTJMWT6KLyintwcA6OEbByw/FmUs4E9VBDKZUP3+7O Y1bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=ucxLTCfy+SSQPXMerDRH9v/9ToSOL8v+DBR2KaENPVo=; b=UzWq6ZCeIZzO2x6k65heg0lXfRolXm9wmgBYfWHNiQCmedJV1Uck/lTTeLJCHj4J1T 9XE3/1u+RE08u4AWaoUbqZR5DYq+b8fajm3Xg7NQO+koMnuEbNvWDAvLBgsNZzrRSCIt u5h8zWM/hT/SnemVmOH1k9hzRAyGxNwildpueQy9aJEeZSf3ViFuvHFeWwJOqJcaRLVI rbgfFhuISWsi22JC9ku5+Dsg9Z1092miuEOUOye9vJJ4gTNFkAF2yFINsf9IXeh/2ji9 Ggu5P3qj71jgFotb8tf90umuL7LMjbEXgrIuaHQrimYEiady2iGnuXP3TMhzB4DUBpiu pQZQ== X-Gm-Message-State: AOPr4FVQQZ5lgqSfJtzxRYC7F0TTMmCjou/LsAcCoL5KYq9Qo1SqNO0cB4wy5CMkz/xpBVHj3dsiWP21ie/72w== MIME-Version: 1.0 X-Received: by 10.112.227.71 with SMTP id ry7mr9726741lbc.78.1461382357913; Fri, 22 Apr 2016 20:32:37 -0700 (PDT) Received: by 10.114.69.179 with HTTP; Fri, 22 Apr 2016 20:32:37 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Apr 2016 09:02:37 +0530 Message-ID: From: Mahesh Govind To: Zhoutianran , opsawg@ietf.org, Warren Kumari Content-Type: multipart/alternative; boundary=001a11347e8e53187905311e9806 Archived-At: Subject: Re: [OPSAWG] opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 03:32:42 -0000 --001a11347e8e53187905311e9806 Content-Type: text/plain; charset=UTF-8 Hi Tianran, Thanks for the reply . I am implementing capwap in opendaylight . https://wiki.opendaylight.org/view/Project_Proposals:CAPWAP Already pushing a good amount of code . Alternate tunneling seems to be a good choice for me . If there is acceptance for alt-tunneling , I could implement the draft in ODL . Thanks in advance for any kind of support . regards Mahesh > > > > On Sat, Apr 23, 2016 at 6:48 AM, Zhoutianran > wrote: > >> Hi Mahesh, >> >> >> >> You have this question in the mailing list. >> >> I think it would be helpful to get a concrete answer if you can also give >> a reason why you want to know this. >> >> >> >> Regards, >> >> Tianran >> >> >> >> *From:* OPSAWG [mailto:opsawg-bounces@ietf.org] *On Behalf Of *Mahesh >> Govind >> *Sent:* Saturday, April 23, 2016 1:49 AM >> *To:* opsawg@ietf.org >> *Subject:* [OPSAWG] opsawg-capwap-alt-tunnel >> >> >> >> Hi, >> >> >> >> Could you please let me know whether any one has implemented the draft ( >> opsawg-capwap-alt-tunnel >> ) >> >> >> >> regards >> >> Mahesh >> >> >> > > --001a11347e8e53187905311e9806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Tianran,
Thanks for the reply .

=
I am implementing capwap in opendaylight .

Already pushing a good amount of code =C2=A0. Alternate tun= neling seems to be a good choice for me .
If there is acceptance = for alt-tunneling , I could implement the draft in ODL .

Thanks in advance for any kind of support .

regards
Mahesh=

=C2=A0



On Sat, Apr 23, 2016 at 6:48 AM, Z= houtianran <zhoutianran@huawei.com> wrote:

Hi Mahesh,=

=C2=A0

You have this question i= n the mailing list.

I think it would be help= ful to get a concrete answer if you can also give a reason why you want to = know this.

=C2=A0

Regards,

Tianran

=C2=A0

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Mahesh Govind
Sent: Saturday, April 23, 2016 1:49 AM
To: opsawg@ietf= .org
Subject: [OPSAWG] opsawg-capwap-alt-tunnel

=C2=A0

Hi,=C2=A0<= /p>

=C2=A0

Could you please let me know wh= ether any one has implemented the draft (opsawg-capwap-alt-tunnel)=C2=A0

=C2=A0

regards

Mahesh

=C2=A0



--001a11347e8e53187905311e9806-- From nobody Mon Apr 25 06:29:00 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D321B12D519 for ; Mon, 25 Apr 2016 06:28:58 -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 urHtYr3W4UAu for ; Mon, 25 Apr 2016 06:28:57 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 0FF7112D501 for ; Mon, 25 Apr 2016 06:28:50 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id y84so18896573lfc.0 for ; Mon, 25 Apr 2016 06:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=ZbDzP5p/JZIN3wBynV6GQe5fOW5N1Wup5hr+lASJT3M=; b=y4RYaX7xP73W0KttNXn3SXp8odQj7zGJtiSZWsf54utRnhtBeS8WwuQU9WKPy5cLlp haM39Kahs7n5o0Slr+QtfG7uty+mc4cWOo6bLNx2q7Tpxrnn9ZFJbdocQbAQ8cxZPueH S+rqGSkLH1mSLPJVIIMsfYsaYJ0bBnVrBSO/bw1ToHXKa2IPcQHUMQzPN4hrXFL+e+zf 4iHwcru3SwLjrzSUY17Covc0oNK59Bz3ymRH2hS38ydd7uHPDchJoZaeOn0VJVW5mB+4 joQZiNv342jBsUD6DxA/3D3U5X3vPb+9APSJi60hxjhDgUOi6Ot4RnLCpYz6xPXR0olh zJlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=ZbDzP5p/JZIN3wBynV6GQe5fOW5N1Wup5hr+lASJT3M=; b=cW/pStbL1AjNfO1OO6v2PcNzdD81VA+C2+W5Y+RswcRl+Npe4QPbAQWogfk25gTVOC Vk0OrhHoaZVlPCwfcR7+QiNHHvl5JGbbADsF5aAPgWXhSU8+8mWIP9rsE5F2JqhNO1zo YX7uxRDG9yg/yRrH0M5XzlJeyELM637ZzMfVdpFuz6/BKYTpoqwk4G45XV3q1vWlQjS3 0oo87uCNG8Nh3ek0wTBdkOfvl9cjUW4NMARSn9MFfg6gCtRe3Ba9SHi/oEljvRwEG6JT SdWFh+b1GMQ+tThNPO8frJQXpUvh2O4JBIIJHIujfXaFgDE+z7dnHBOi74h3qCWlT/yE SnAA== X-Gm-Message-State: AOPr4FUE6qirVHwsKH7e8shNg/D86G/nQgDfm075nwxLjXgYQNWZmKIFhUigysA4bTQpl702p+NV/kSUD+/GgQ== MIME-Version: 1.0 X-Received: by 10.25.166.140 with SMTP id p134mr11847715lfe.29.1461590928194; Mon, 25 Apr 2016 06:28:48 -0700 (PDT) Received: by 10.114.69.179 with HTTP; Mon, 25 Apr 2016 06:28:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Apr 2016 18:58:48 +0530 Message-ID: From: Mahesh Govind To: Zhoutianran , opsawg@ietf.org, Warren Kumari Content-Type: multipart/alternative; boundary=001a114118c61502a905314f2889 Archived-At: Subject: Re: [OPSAWG] opsawg-capwap-alt-tunnel X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 13:28:59 -0000 --001a114118c61502a905314f2889 Content-Type: text/plain; charset=UTF-8 Hi All, Any info about the adoption of alt-tunneling will be helpful . regards Mahesh On Sat, Apr 23, 2016 at 9:02 AM, Mahesh Govind wrote: > > Hi Tianran, > Thanks for the reply . > > I am implementing capwap in opendaylight . > https://wiki.opendaylight.org/view/Project_Proposals:CAPWAP > > Already pushing a good amount of code . Alternate tunneling seems to be a > good choice for me . > If there is acceptance for alt-tunneling , I could implement the draft in > ODL . > > Thanks in advance for any kind of support . > > regards > Mahesh > > > >> >> >> >> On Sat, Apr 23, 2016 at 6:48 AM, Zhoutianran >> wrote: >> >>> Hi Mahesh, >>> >>> >>> >>> You have this question in the mailing list. >>> >>> I think it would be helpful to get a concrete answer if you can also >>> give a reason why you want to know this. >>> >>> >>> >>> Regards, >>> >>> Tianran >>> >>> >>> >>> *From:* OPSAWG [mailto:opsawg-bounces@ietf.org] *On Behalf Of *Mahesh >>> Govind >>> *Sent:* Saturday, April 23, 2016 1:49 AM >>> *To:* opsawg@ietf.org >>> *Subject:* [OPSAWG] opsawg-capwap-alt-tunnel >>> >>> >>> >>> Hi, >>> >>> >>> >>> Could you please let me know whether any one has implemented the draft ( >>> opsawg-capwap-alt-tunnel >>> >>> ) >>> >>> >>> >>> regards >>> >>> Mahesh >>> >>> >>> >> >> > --001a114118c61502a905314f2889 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,
Any info about the adoption of alt-tunneling w= ill be helpful .

regards
Mahesh


On Sat, Apr 23, 2016 at 9:02 AM, Mahesh Govind <vu3mmg@gmail.com> wrote:

Hi Tianran,
Thanks for the reply .

I am = implementing capwap in opendaylight .

Already pushing a good amount of code =C2=A0. Alternate tunneling see= ms to be a good choice for me .
If there is acceptance for alt-tu= nneling , I could implement the draft in ODL .

<= div>Thanks in advance for any kind of support .

re= gards
Mahesh
=
=C2=A0



On Sa= t, Apr 23, 2016 at 6:48 AM, Zhoutianran <zhoutianran@huawei.com&g= t; wrote:

Hi Mahesh,=

=C2=A0

You have this question i= n the mailing list.

I think it would be help= ful to get a concrete answer if you can also give a reason why you want to = know this.

=C2=A0

Regards,

Tianran

=C2=A0

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Mahesh Govind
Sent: Saturday, April 23, 2016 1:49 AM
To: opsawg@ietf= .org
Subject: [OPSAWG] opsawg-capwap-alt-tunnel

=C2=A0

Hi,=C2=A0<= /p>

=C2=A0

Could you please let me know wh= ether any one has implemented the draft (opsawg-capwap-alt-tunnel)=C2=A0

=C2=A0

regards

Mahesh

=C2=A0




--001a114118c61502a905314f2889-- From nobody Thu Apr 28 22:19:23 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25512B01C for ; Thu, 28 Apr 2016 22:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jl9UzuB9jUr9 for ; Thu, 28 Apr 2016 22:19:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550B612B00A for ; Thu, 28 Apr 2016 22:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20332; q=dns/txt; s=iport; t=1461907158; x=1463116758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZlItsFwHi+6SjRbHNBtxupnWUC1Luz9FWds26i1r7v4=; b=EW1qVyBc3gLWj4TNG45NTwKJWivHBhn7Pm5ITrGR8BbzL7qsId0rvEV3 uy2W/ykaoQVuwIXtf1AWxr09TJNprHCP4usf1nrOezl6vxyFc/nCmqt7F MZQD2jaoDIEMhv6lSYvtpDeLM9RT74RlQJr6rnohYOZGXwHk9qLfPuyVo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgCP7iJX/51dJa1UCoM4U30GrgSLY?= =?us-ascii?q?AENgXYXDYUhSgKBKjgUAQEBAQEBAWUcC4RBAQEBBAEBATcUGQUCCAMQAgEIEQM?= =?us-ascii?q?BAgEMCgEBBgYKIQYKAR0IAgQOBR0Eh3QDEg63EodADYRLAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFYlqgQKCQYFOBgoCAQUdJQwQAQWFCAWHcASFYIEyhBqEQDEBhXu?= =?us-ascii?q?CM0SCXlCBdoFnToN/gymFNIdRh14BHgEBQoIGGoFLbIYsBxcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,550,1454976000"; d="scan'208";a="102729308" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 05:19:16 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3T5JG0P006280 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 05:19:16 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 00:19:15 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 00:19:15 -0500 From: "Douglas Gash (dcmgash)" To: "opsawg@ietf.org" Thread-Topic: OPSAWG Digest, Vol 107, Issue 11 Thread-Index: AQHRnMlXl2k26L6hgEu9RTll4r7R2Z+g2FWA Date: Fri, 29 Apr 2016 05:19:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.1.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <6EB7B52F21ED1F459EDE6892BFFC320E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Andrej Ota , Thorsten Dahm Subject: Re: [OPSAWG] OPSAWG Digest, Vol 107, Issue 11 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 05:19:22 -0000 Many thanks Alan, Stefan, Joe and Joel for the detailed review and useful feedback, Very much appreciated! On 22/04/2016 20:00, "OPSAWG on behalf of opsawg-request@ietf.org" wrote: >Send OPSAWG mailing list submissions to > opsawg@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > opsawg-request@ietf.org > >You can reach the person managing the list at > opsawg-owner@ietf.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. Re: TACACS+ informational document. (Alan DeKok) > 2. Re: TACACS+ informational document. (Stefan Winter) > 3. Re: TACACS+ informational document. (Alan DeKok) > 4. Re: TACACS+ informational document. (Joel Jaeggli) > 5. opsawg-capwap-alt-tunnel (Mahesh Govind) > 6. Re: I-D Action: draft-ietf-opsawg-tacacs-02.txt (Joe Clarke) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 21 Apr 2016 22:06:25 -0400 >From: Alan DeKok >To: Warren Kumari >Cc: "opsawg@ietf.org" >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <946763DD-7EBE-44F2-B94E-910B55FBDE6C@deployingradius.com> >Content-Type: text/plain; charset=3Dus-ascii > > More comments... > >4.4. Description of Authentication Process > > Authentications are classified by the action, authen_type and service > fields in the START packet of the authentication Session. The user, > priv_lvl, service, port and rem_addr in the START packet are all > provided to help identify the conditions on the client > > What is meant by "conditions on the client"? It would be best to >describe what those fields mean instead. > > ... The information necessary to transact the authentication is passed >... > > What is "information necessary to transact the authentication"? This >sounds unclear to me. > > ... A set of standard authentication classifications is defined in this > document. =20 > > What is meant by "authentication classifications" ? It's not clear >from the context or the rest of the document. Perhaps it means >"authentication protocols" ? i.e. one exchange is done for PAP, another >for MS-CHAP, another for OTP, etc. > > ... When the REPLY status equals TAC_PLUS_AUTHEN_STATUS_GETDATA, > TAC_PLUS_AUTHEN_STATUS_GETUSER or TAC_PLUS_AUTHEN_STATUS_GETPASS, > then authentication continues and the server_msg may be used by the > client to prompt the user for more information. > > "may be used"? What happens when the client doesn't use server_msg to >prompt the user? > > ... All three cause the same action to be performed, but in the case of > TAC_PLUS_AUTHEN_STATUS_GETUSER, the client can know that the > information that the user responds with is a username, and for > TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a > password. > > I'm wary of statements such as "the client can know..." Is that a >philosophical statement? > > It's generally best to describe actions instead of knowledge. e..g. >"for prompts using TAC_PLUS_AUTHEN_STATUS_GETUSER, the users response is >interpreted by the client as a username, for use in subsequent exchanges". > > ... TAC_PLUS_AUTHEN_STATUS_GETPASS, that the user response represents a > password. > > Similar comments apply here. > > ... TAC_PLUS_AUTHEN_STATUS_GETDATA is the generic request for > more information. > > And what happens then with the data? When is this message used? > >4.4.1. Version Behaviour > > ... in the table below: > > LOGIN CHPASS SENDAUTH > ASCII v0 v0 NA > PAP v1 NA v1 > CHAP v1 NA v1 > MS-CHAP v1 NA v1 > > > What does "NA" mean? I suspect I know, but it's good to be explicit >instead of assuming that the reader knows the authors intent. > > ... The removal of SENDPASS > was prompted by security concerns, and is no longer considered part > of the TACACS+ protocol. > > It may be worth considering the removal of all documentation of >SENDPASS. If it's not just deprecated by removed entirely, then it >should probably be just removed entirely. > > 4.4.2. Common Authentication Flows > > This section describes the authentication flows that should be > supported. > > What is meant by "should be supported"? Is this an RFC 2119 statement? > Or are these examples of authentication flows which are in common use, >and that all clients && servers are expected to support? > > ... A PAP authentication only consists of a username and password > RFC 1334 [RFC1334] . > > I think referencing a later RFC is preferable. > > (chap) > > ... The length of the challenge value can be determined from the >length > of the data field minus the length of the id (always 1 octet) and the > length of the response field (always 16 octets). > > This would seem to impose limits on the "date len" field. It would be >good to state these explicitly. > > Also, to indicate that the challenges MUST have a minimal length, which >should probably be no less than 8, though 16 is suggested. The >alternative is to allow zero-length challenges, which is not good. > > And how are the challenge, ID, and response fields packed into the data >field? i.e. in what order are they packed? ASCII art would be *very* >helpful here.=20 > > Similar comments apply for MS-CHAPv1 and MS-CHAPv2 authentication. > > 4.4.3 > > ... When the status equals TAC_PLUS_AUTHEN_STATUS_FOLLOW the packet > indicates that the TACACS+ server requests that authentication should > be performed with an alternate server. The data field MUST contain > ASCII text describing one or more servers. A server description > appears like this: > > [@@]>[@] > > Examples would help here. The above text isn't ABNF, or any other >machine-readable definition of a text string. > > Perhaps the text could be updated to say that "@" is a delimiter. for >text strings: > >0 @ =3D host >1 @ =3D host@key >2 @ =3D @protocol@host >3 @ =3D @protocol@host@key > > ... If a key is supplied, the client MAY use the key in order to > authenticate to that host. If more than one host is specified, they > MUST be separated by an ASCII Carriage Return (0x0D). > > Some questions here. What happens if the client doesn't want to use >that key? What happens if the client is pre-provisioned with a different >key than what is supplied here? If there are multiple hosts, does the >client use the supplied key for all of them? What if the client has a >disparate set of keys for the list of hosts? > > ... This packet is > only currently intended for PPP authentication when multiple > authentication mechanisms are available and can be negotiated between > the client and the remote peer. This also requires future PPP > authentication extensions which have not yet been passed through the > IETF. > > Are users performing device administration over PPP? If that isn't the >99% case, then I suggest re-wording the paragraph. > > Also, updating it to clarify what it means for "future PPP extensions". > Perhaps just removing that sentence would be best. > >5. Authorization > > ... The authorization REQUEST message contains a fixed set of fields >that > describe the authenticity of the user or process, > > What is "authenticity" of a user? > > ... priv_lvl > > This field matches the priv_lvl field in authentication request a > > What does this statement mean? Does the field (length and value) have >to be identical to the field in the authentication request? If not, why >not, and what happens? If so, it would be better to just say that it >MUST be identical. Similar comments apply for the other fields. "match" >is a word which should be used in the context of "A must match B", >instead of "is used for matching". The first is concrete and >implementable. The second is more philosophical than protocol oriented. > > ... Attribute-value strings are not NULL terminated, rather their >length > value indicates their end. The maximum length of an attribute-value > string is 255 characters. > > Are zero-length strings allowed? I presume not, but it would be good >to say so. > >7. Attribute-Value Pairs > > ... A value of NULL means an attribute with a zero length string for its > value i.e. cmd=3DNULL is actually transmitted as the string of 4 > characters "cmd=3D". > > That seems contradictory.. NULL is encoded by not encoding it.. >Perhaps the text could instead say: > > Attributes which have no value are transmitted as the attribute name, >followed by the mandatory or optional flag. The value is elided. For >example, the attribute "cmd" which has no value is transmitted as a >string of 4 characters "cmd=3D" > > ... acl > > US-ASCII number representing a connection access list. Used only > when service=3Dshell and cmd=3DNULL > > I would suggest eliding the NULL here, too. The temptation for naive >implementors would be to encode an actual string "NULL". > > =20 > There should be a separate "Security Considerations" section as Section >9. It should explain all of the issues with the protocol, such as the >use of "encryption", etc. > > Alan DeKok. > > > >------------------------------ > >Message: 2 >Date: Fri, 22 Apr 2016 14:13:41 +0200 >From: Stefan Winter >To: "opsawg@ietf.org" >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <571A1575.4030400@restena.lu> >Content-Type: text/plain; charset=3Dutf-8 > >Hi, > >the draft states: > > user > > The username. It is encoded in [UTF-8]. It is optional in this > packet, depending upon the class of authentication. > >The old expired draft from 1997 states: > >user > > The username. It is optional in this packet. > > >Somehow, an explicit encoding requirement made it into the new draft. It's >good to be explicit when designing a protocol; but when it comes >to documenting deployed reality it's important to be sure that >this really *is* the deployed reality. > >Are you sure / how sure are you that deployed reality agrees with this >change of wording? > >Greetings, > >Stefan Winter > >Am 20.04.2016 um 21:49 schrieb Warren Kumari: >> Hi there all, >> >> The authors of draft-ietf-opsawg-tacacs have updated the document and >> would like some review. >> >> As a reminder, this document is supposed to describe how TACACS >> currently works. >> We will then publish a new document which improves the security of >>TACACS. >> >> I'd really appreciate it if people could review the current document >> (Link for easy >> clicking: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/) >> and provide feedback to the list by Friday April 29th. >> >> W > > > >------------------------------ > >Message: 3 >Date: Fri, 22 Apr 2016 08:38:43 -0400 >From: Alan DeKok >To: Warren Kumari >Cc: "opsawg@ietf.org" >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <35A816AD-6739-4CF3-AD78-3045A029AE89@deployingradius.com> >Content-Type: text/plain; charset=3Dus-ascii > > A short summary: > >- many fields are named but not defined > >- structures with multiple fields are described, but field order is not >defined > >- terms are used inconsistently > >- the document is silent on critical points > > - how do user logins map to TCP connections? 1-1? 1-N? N-M? > > - can the same session_id be used in multiple TCP connections? > >- the general tone seems philosophical: systems "know" things, not >prescriptive: systems "do" things. > >- edge cases are not discussed > > - what happens with zero-length fields? > >- common use-cases aren't described (e.g. inter-site use of the protocol) > >- the security considerations section is minimal > > - how do the edge cases affect security? > > - is the TCP connection closed when the key is found to be wrong? If >not, why not? > > - what are best practice recommendations for deployment? > > - what impact does inter-site deployment have on security? > > > As an implementor, I would have to guess at large portions of the >protocol, or I would have to read the source to existing implementations. > The draft as is stands today can get me ~90% of the way to implementing >the protocol, but critical portions are not present. > > Alan DeKok. > > > >------------------------------ > >Message: 4 >Date: Fri, 22 Apr 2016 08:41:30 -0700 >From: Joel Jaeggli >To: Alan DeKok >Cc: "opsawg@ietf.org" >Subject: Re: [OPSAWG] TACACS+ informational document. >Message-ID: <6C57DC37-EBA1-46A6-9DA6-4AC4588B737F@bogus.com> >Content-Type: text/plain; charset=3Dus-ascii > >Thanks,=20 > >This is useful feedback. > >> On Apr 22, 2016, at 05:38, Alan DeKok wrote: >>=20 >> A short summary: >>=20 >> - many fields are named but not defined >>=20 >> - structures with multiple fields are described, but field order is not >>defined >>=20 >> - terms are used inconsistently >>=20 >> - the document is silent on critical points >>=20 >> - how do user logins map to TCP connections? 1-1? 1-N? N-M? >>=20 >> - can the same session_id be used in multiple TCP connections? >>=20 >> - the general tone seems philosophical: systems "know" things, not >>prescriptive: systems "do" things. >>=20 >> - edge cases are not discussed >>=20 >> - what happens with zero-length fields? >>=20 >> - common use-cases aren't described (e.g. inter-site use of the >>protocol) >>=20 >> - the security considerations section is minimal >>=20 >> - how do the edge cases affect security? >>=20 >> - is the TCP connection closed when the key is found to be wrong? If >>not, why not? >>=20 >> - what are best practice recommendations for deployment? >>=20 >> - what impact does inter-site deployment have on security? >>=20 >>=20 >> As an implementor, I would have to guess at large portions of the >>protocol, or I would have to read the source to existing >>implementations. The draft as is stands today can get me ~90% of the >>way to implementing the protocol, but critical portions are not present. >>=20 >> Alan DeKok. >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >>=20 > > > >------------------------------ > >Message: 5 >Date: Fri, 22 Apr 2016 23:18:30 +0530 >From: Mahesh Govind >To: opsawg@ietf.org >Subject: [OPSAWG] opsawg-capwap-alt-tunnel >Message-ID: > >Content-Type: text/plain; charset=3D"utf-8" > >Hi, > >Could you please let me know whether any one has implemented the draft ( >opsawg-capwap-alt-tunnel >) > >regards >Mahesh >-------------- next part -------------- >An HTML attachment was scrubbed... >URL:=20 >b6f0/attachment.html> > >------------------------------ > >Message: 6 >Date: Fri, 22 Apr 2016 14:43:51 -0400 >From: Joe Clarke >Cc: opsawg@ietf.org >Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-02.txt >Message-ID: >Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed > >I've done a quick read-through of the draft, and I have a few comments. > >* Assuming someone is completely unfamiliar with T+ and they came across >this draft, they might assume "TACACS" stood for something, but it is >not expanded. Since this draft describes the protocol, I think it would >be good to expand the acronym in the intro paragraph. > >* There are terminology spread throughout the draft (e.g., MD5, >'TheDraft', session, etc.). I've seen such things summarized early on >in a glossary in other long drafts. It might make it easier for a >reader to refer to if that was done here as well. > >* There is a lot of use of NULL in this document where you either mean >NUL byte termination or an empty field. It would be helpful to clarify >the usage where you mean a NUL ASCII byte or a field with a zero length >value. > >* In Section 4.1, the username is stated to be encoded in UTF-8. This >is not the case in the _current_ implementation of the protocol. A code >inspection of at least the tac_plus4 module shows this is as US-ASCII as >some of the other fields. > >* In Section 4.1 as well, the various AUTHEN_SVC types are defined, but >only ENABLE (and NONE to some extent) is really described. It would be >useful to describe the others as well. > >* In Section 4.2, the "data" field is mentioned and says it will be >described in more detail per authen_type below. Since the START, REPLY, >and CONTINUE packets each have a "data" field, and they're respective >sections all point to details "below," it's hard to discern what field >is being described. While I was able to figure out what I'd see in >various START and CONTINUE packets, I didn't see much on what I'd see in >the REPLY. For example, where can I expect to see custom authn prompts >pushed? > >* In Section 5.1, you define TAC_PLUS_AUTHEN_METH_LINE as a "fixed >password associated with the line used to gain access." I don't think >it's clear what a "line" is. It might be better to say "terminal line" >or "terminal port." > >That's it for now. > >Joe > >On 4/12/16 09:41, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Operations and Management Area Working >>Group of the IETF. >> >> Title : The TACACS+ Protocol >> Authors : Thorsten Dahm >> Andrej Ota >> Douglas C. Medway Gash >> David Carrel >> Lol Grant >> Filename : draft-ietf-opsawg-tacacs-02.txt >> Pages : 35 >> Date : 2016-04-11 >> >> Abstract: >> TACACS+ provides Device Administration for routers, network access >> servers and other networked computing devices via one or more >> centralized servers. This document describes the protocol that is >> used by TACACS+. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-tacacs-02 >> >> >> 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/ >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 107, Issue 11 >*************************************** From nobody Fri Apr 29 20:13:43 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59612D65A; Fri, 29 Apr 2016 20:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 PNAE5BBiTNn6; Fri, 29 Apr 2016 20:13:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8394812B035; Fri, 29 Apr 2016 20:13:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1E913180003; Fri, 29 Apr 2016 20:13:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160430031320.1E913180003@rfc-editor.org> Date: Fri, 29 Apr 2016 20:13:20 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 7860 on HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 03:13:42 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7860 Title: HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 Author: J. Merkle, Ed., M. Lochter Status: Standards Track Stream: IETF Date: April 2016 Mailbox: johannes.merkle@secunet.com, manfred.lochter@bsi.bund.de Pages: 14 Characters: 29329 Obsoletes: RFC 7630 I-D Tag: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05.txt URL: https://www.rfc-editor.org/info/rfc7860 DOI: http://dx.doi.org/10.17487/RFC7860 This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC