From nobody Thu Jul 2 03:54:39 2020 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFB23A0ACD for ; Thu, 2 Jul 2020 03:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ggEMOHV6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eiVBpyKg 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 FQIW4Xl3jIlC for ; Thu, 2 Jul 2020 03:54:35 -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 959283A0A4F for ; Thu, 2 Jul 2020 03:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6623; q=dns/txt; s=iport; t=1593687275; x=1594896875; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/ko62zjKXwmVLzVLajzWGNwPz8sDYoC1w6Spow9BG68=; b=ggEMOHV64KNViDaS9WuRy5q0jWIwVq1Fxjsmt423jWt8V66WaF1X/2ZY T0DaAv+3rHfa4tw7kveBSdAcFI9oaMpJNHpaBW5IpROU0YkSR+7ZTUoQD 2hZvfCRtI9OP4ezSZL14pTRI2BhWFYZFft7ERJTk154dRl/XgtG2t7Y6z 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AOtrd4xOM9MOthTKc6V4l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK8x3lPMVJ/QrfNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFHXq2e5qz8fBh?= =?us-ascii?q?u5MhB6daz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AABrvP1e/5FdJa1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBOAQBAQELAYFRIy4Hb1gvLAqHbQONS4EBl1mBLoE?= =?us-ascii?q?kA1ULAQEBDAEBGA0IAgQBAYRHAoIcAiQ2Bw4CAwEBCwEBBQEBAQIBBgRthVs?= =?us-ascii?q?MhW4BAQEBAgEBARALHQYBASUHDAsEAgEIEQEDAQEBHhAnCxcGCAEBBAESCBM?= =?us-ascii?q?HgwWCSwMOIAEOoEwCgTmIYXSBNIMBAQEFgUZBg0MYgg4JgTgBgmiCTEaFKoF?= =?us-ascii?q?DGoFBPxJ/Q4IYNT6CXAEBAgEBgTMqg0eCLbUOCoJciEuGLopxgnOJMJJ6kVm?= =?us-ascii?q?BZYg3kCQWhAoCBAIEBQIOAQEFgVoDL4FWcBU7gmkJRxcCDY4eDBeDToUUhUJ?= =?us-ascii?q?0NwIGCAEBAwl8jB2BNAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,304,1589241600"; d="scan'208";a="517702714" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Jul 2020 10:54:34 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 062AsYfF016770 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Jul 2020 10:54:34 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Jul 2020 05:54:34 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Jul 2020 06:54:33 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 2 Jul 2020 06:54:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O9Fod1m7mQgRgLQ0o50+xWqX4elRz/qsRhCqs7J+Udx84IyMrhKPzDG2mXOqxhS5oE8pFVn1BILK4BiTcY3S5Wpi7VEmFNFdHCKz3f2N+vg0P1bSp+4evkMafvfq18pN1ZdKRltUAevwemjKliX0DDTUQv/LJb+Eu5VWEj/0CKDiKBYDIYeUsrwSdL3Ozl3A9p83mqFk8Tv/Ov9MsHiM30YEJI2bJeDACg6nlFm68SYDcP6aTWUeudpbJNqhEkBVeSG4BchhNneQtrRahxzHciCJnz/7sr8nkf2SFcD8WkXEPwF5q/kuJguCJmElf9aZ15HacgDttTg7MUJh0xy81Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iI2Kro73r5g86DLX8jDAs93u85n5PGeFR1faJAE9Bzw=; b=EyadWbFu+i5t/SlDAMsKLTQfze4NqhX4bflrd5lyg6jsTmrnqEMWnDUXIO/CBzNJddvk/8C+w4P4ciP3z70FwLgZKFkLgdLkHVZkIrShKy3PHMoQL8sL5gh+JxHDek1bMmNSUPWfmbHhWYCEUD0dVcRueEwxwrF/4XIhOWHg2PMXYs9InEzk8yhaStwzBrhRWM9OTy8H0yB+AdS9qcGPYS/N0a9pAfKBT0eNv4j03W3zPMp/Jo7u1eyMBJqhjtT61sQQgHXNlMRO83Ohdg3O0UuMTlhb5Cwx2Q/29eMjNqts/WpeVCu7+L6TCWT03M26xpMOxbwJquS6ceRmo7LuUg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iI2Kro73r5g86DLX8jDAs93u85n5PGeFR1faJAE9Bzw=; b=eiVBpyKg0uIMCO4fG6cCF+EqONMes+0wBrnfKgkZANZkPaf2PHSczhgV6RYe/lJlVfUfCm2G9RAGgOIk8o9k6S5f69CeNV0qZxNbWbcNud37pB9Y9TiBxkfx2gjYU5UrbFFAcMTXHQy3Fe8+bNfF17Uykvp9L4X3I0krDybccDI= Received: from BYAPR11MB2584.namprd11.prod.outlook.com (2603:10b6:a02:c8::31) by BYAPR11MB2760.namprd11.prod.outlook.com (2603:10b6:a02:c0::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Thu, 2 Jul 2020 10:54:31 +0000 Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d8d7:dbc7:25a8:a4bd]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d8d7:dbc7:25a8:a4bd%3]) with mapi id 15.20.3153.027; Thu, 2 Jul 2020 10:54:31 +0000 From: "Frank Brockners (fbrockne)" To: "Vengada Prasad Govindan (venggovi)" , "sfc@ietf.org" Thread-Topic: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit Thread-Index: AdZK2SX2LrPrxvKtTuqDAc47v17FHAFbaSmw Date: Thu, 2 Jul 2020 10:54:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53af8c19-1293-4e9b-e277-08d81e764cd9 x-ms-traffictypediagnostic: BYAPR11MB2760: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0452022BE1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XC8OrBgNaPC2JiJQsRuhCmxHl6UePau9+4DOhzgprEH8peUEl8Cckau45w9sEgAg9Nwt7G09Zjvbgs5FeCGyjor1ErblqskuBw6gq6tEkRNHN64xSqBZnCdYEyn4w9uuFDsV5gARaStqeOCXhUeLp1veSBjHnVDK1zzJcmmIpZ8dn5fLdTcpMANBC2lcxD/P8A9spB91hHhQE4WmcGn+cesw/iFr3CR3DXOI8Z5PHPVbrFoG4zbv8GN0tYU2uh/BRuA8SMtw6McdsNOu4q18xoFM/xlRTiUuU8fumWrndOhBu58g41Y9/GAmqErbDjE+q2l38pKNVBQj8TYjHuaKdGT5BR7OpRl7PNokP7Pqt0BPJTTRxKB78BZOzPE05AlkroGeOX1RBAhncNg+z9hg0Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2584.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(366004)(39860400002)(346002)(2906002)(7696005)(66446008)(53546011)(71200400001)(66556008)(9686003)(64756008)(66946007)(76116006)(66476007)(86362001)(83380400001)(8676002)(33656002)(55016002)(966005)(478600001)(8936002)(52536014)(110136005)(186003)(26005)(6506007)(316002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: pm65eyZohOF7wDuDA/R9FJyQix0TV9mcL1pz8WaFANBwO1ZZjpO+bjDizP/46YTshLIl3NvkpYiOpI0p45D88HePAgc4VbEpw+ZbMZhpZqusiwC2Oc6Un9gRra7p2fp/2dwe+ibROtEn+0lb2D4Wwd6eaeqBt82cVXM4ouGSvjuSqriq+lioRT+J91dE8Egp2beITsWHN30orG1z9hanMRuamQkiiRl6n6RySHaibgo7q9jvjXUkWs32N92Re4WEW4xYCa5p5rPNntj+AAZ3xW6U2u0ot6PI1noN9ZueB7PGM5HTJJglCDaW8rAqcgo+depm3Ie2NfbPDa/k2KswGhfpKBivNPvxHYIOKM9+Zg8mEpPjPOpA8UfsIjAyHLcuXZ/Ls+or8kobX5cccfkbI4vJdqLBLPhlFe/Dft8s8RywjlXAJoND84GM/f8Tnbo60p1LLUuaXOmPFDiNSgiIUtqyyWnjvszBNkzUQoNd4WPrY4HmWUuVw4TSxDyj82t0 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2584.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53af8c19-1293-4e9b-e277-08d81e764cd9 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2020 10:54:31.4608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RZNC7TEIakBQHn5+qBzuV76TZVErxi1lMyhbfw/vsyQutXfwOnCRxoV7GgPxiRqeAj6K0gUS7ePCmK+hs383gA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2760 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 10:54:38 -0000 Hi Prasad, Thanks a lot for your comments. Please see inline ("..FB"). > -----Original Message----- > From: sfc On Behalf Of Vengada Prasad Govindan > (venggovi) > Sent: Donnerstag, 25. Juni 2020 13:02 > To: sfc@ietf.org > Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-tran= sit >=20 > Hello all, >=20 > I support progressing this draft to an Experimental RFC. Please consider = the > following comments (mostly editorial): >=20 > 1) > Not sure what is implied by the sentence below (Sec 1): > > A particular set of nodes "to be verified" is either described by a set= of shares > of a single secret. ...FB: Good catch. We'll remove the word "either". This is an editorial lef= t-over from the time when the draft had two methods mentioned (SSSS and nes= ted crypto). >=20 > 2) > The following sentence (Sec 1) describes about controller nodes and verif= ier > nodes. While the former's role could be easily understood, I am not sure = the > latter node role is clearly defined. If it does not limit the scope, we m= ay use only > one terminology or clarify the difference, if we need to refer about two = roles. > > The complete secret set is only known to the controller and a verifier= node, > which is typically the ultimate node on a path that performs verification= . ...FB: A network element that compares the iteratively (by all nodes that p= articipate in POT on the path) computed result which is carried along in th= e packet with the secret and concludes whether the computed result matches = the secret. If the two match, the packet transit is proven. The role of the= verifier naturally assumes that the packets had a chance to traverse the n= odes subject to POT before arriving at the verifier. We can add a short paragraph with such an explanation to the document to en= sure the role of the verifier is properly explained. >=20 > 3) > Sec 7.9.1 > OLD > Since these schemes introduce at least additional control requirements, = the > selection of order verification SHOULD be configurable the Controller > management interface NEW Since these schemes introduce at least additiona= l > control requirements, the selection of order verification SHOULD be > configurable BY the Controller management interface ...FB: Thanks. We'll update the sentence accordingly. >=20 > 4) > Sec 3.2 has the words Solution Approach duplicated ...FB: Thanks. Good catch.=20 >=20 > 5) > Not sure if there is a missing reference here (Sec: 3.3.1.3): > > For a general way to compute the modular multiplicative inverse, see = e.g., > the Euclidean algorithm. ...FB: We'll add a reference to http://en.wikipedia.org/wiki/Modular_multip= licative_inverse#Computation >=20 > 6) > General comment: It may be helpful to either have a diagram or a pointer = to a > diagram pointing out the different roles like Controller, ingress node. A= lso I am > not sure if there is text (other than the section in Security Considerati= ons) that > explains that POT should be deployed in a set of nodes under a single > administrative domain. ...FB: The scope of this draft is the definition of methods for proof-of-tr= ansit. Like I mentioned in an earlier discussion on the SFC mailing list: An implementor of POT for SFC with NSH would need to rely on several docume= nts: - draft-ietf-sfc-proof-of-transit: for the POT concept and mechanism - draft-ietf-ippm-ioam-data: for the definition of POT related data fie= lds in IOAM - draft-ietf-sfc-ioam-nsh: for the definition of the encapsulation of P= OT related data fields in IOAM into NSH What you seem to be missing is an architecture-level discussion of how the = mix of POT+IOAM+NSH apply to the SFC architecture. IMHO this would best be = addressed by an architecture-level document, because all of the above menti= oned documents are focused on a specific subject and neither of the documen= ts would be a good fit for an architecture level definition. IMHO the best = place for that would be a "RFC 7665bis" document - i.e. we'd extend the SFC= architecture with a discussion how POT applies. That said - and this is along the lines of your comment wrt/ the verifier: = What is feasible within the scope of the document is to have an explanation= of the different roles in POT in the document (e.g. we can do this in sect= ion 3), where we discuss the role of nodes which participate in POT, the ve= rifier and the controller role, i.e. * Node: A network element through which packet transit has to be proven. * Controller: The Controller that creates secrets and secrets shares and co= nfigures the nodes for POT operations. * Verifier: A network element that compares the iteratively (by all nodes t= hat participate in POT on the path) computed result which is carried along = in the packet with the secret and concludes whether the computed result mat= ches the secret. If the two match, the packet transit is proven. The role o= f the verifier naturally assumes that the packets had a chance to traverse = the nodes subject to POT before arriving at the verifier. Thanks again, Frank >=20 > Thanks > Prasad >=20 > > > -----Original Message----- > > > From: sfc On Behalf Of Joel M. Halpern > > > Sent: Dienstag, 16. Juni 2020 15:42 > > > To: sfc@ietf.org > > > Subject: Re: [sfc] IETF WG state changed for > > > draft-ietf-sfc-proof-of-transit > > > > > > The chairs are starting the WG last call for > > > draft-ietf-sfc-proof-of-transit. Please reply explicitly whether > > > you think this is ready to go to the IETF for publication as a Experi= mental > RFC. > > > As noted below, the call runs through June 30. > > > > > > Note that silence does not imply consent, so please speak up. > > > > > > Yours, > > > Joel (& Jim) > > > > > > On 6/16/2020 9:32 AM, IETF Secretariat wrote: > > > > > > > > The IETF WG state of draft-ietf-sfc-proof-of-transit has been > > > > changed to "In WG Last Call" from "WG Document" by Joel Halpern: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/ > > > > > > > > Comment: > > > > This starts WG last call for this document, ending June 30. > > > > > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 3 04:12:04 2020 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D22C3A0C6D for ; Fri, 3 Jul 2020 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ig2UX4H1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BS8GVvi9 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 7Cr6YLAR6CDw for ; Fri, 3 Jul 2020 04:11:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5593F3A0C67 for ; Fri, 3 Jul 2020 04:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17073; q=dns/txt; s=iport; t=1593774718; x=1594984318; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=p9J8PiYUCUNDYx36gLMeARxP9vyzhnizR0he4tFmDPs=; b=ig2UX4H1YIhnMvvW4TnL9V7rAOhTtNNdjT0N5HV0ac6t1d9IhrQQ6jo3 gy5FWjrnac4a4horiJ8TlGaWyAn9dMuiBeDKtqZgknwvZOMR+pR01hgmF zaT4TbwVQhyIO4NqvbjbdmbHjWKQI3GysGEmbBny9LGCmepLHLlum7A2a Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AeIdKQRIuy8f0apC69dmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGv6k/gFrAR46d6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsuta1jbuHb07DMOFF?= =?us-ascii?q?P4LwUmbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAAD8Ef9e/5BdJa1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIE3BAEBAQELAYEiAS4jLgdvWC8sCoYEgWk?= =?us-ascii?q?DjUuBAZJuhGuBLoEkA1ULAQEBDAEBGAEMBAQCBAEBgxGBNgKCIAIkNQgOAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVbDIVuAQEBAQIBAQEQCyMBASUHDAsEAgEIEQEDAQE?= =?us-ascii?q?BLicLFwYIAQEEARIIEweDAAWBfk0DDh8BAQ6eHQKBOYhhdIE0gwEBAQWBRkG?= =?us-ascii?q?DPhiCDgmBOAGCaIJMRoUqgUMagUE/En9Dghg1PoJcAQECAQGBMyorgxyCLZh?= =?us-ascii?q?9nBEKglyIS4YuinGCc4kwknqRWYFlgXCGR5AkFoQKAgQCBAUCDgEBBYFAFQE?= =?us-ascii?q?2DIFKcBU7gmkJFjEXAg2NeyMMF4NOhD5WhUJ0AhgBHAIGCAEBAwl8jRWBNAG?= =?us-ascii?q?BEAEB?= X-IronPort-AV: E=Sophos;i="5.75,308,1589241600"; d="scan'208,217";a="702807265" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jul 2020 11:11:56 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 063BBulR004733 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Jul 2020 11:11:56 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Jul 2020 06:11:56 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Jul 2020 06:11:55 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 3 Jul 2020 06:11:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GIeGmSfBfQlD17zdRJNU6cVjZi70Xgr3h+4caKVS7jTj9By15sVWj4RQc+XB3jTSCtlVhi2XBMjtZjtbtMYI/v6SwhObl4n/PLAjyPhhvLVcJ4WEwysGqnGC0yXgTSzPiFxvWTmZE36D9R6gqiMa+5/n05wsabPEIeQe4omp5J3TZtvu7UXamE7hdfSyU+r7jWB+oSizHt5a09KmsGwb0j6PfrYl7kornT7ckV2yzvnraNK30RdxM7eU+tzDMLJ5Ih5I9EKd2uBoDpiEAO9tU00gT3svFnGhkeGeJfbN94G7SlnjVbRbsqoaPGm+haD36M8ZgJVXpE02DRaX3SPJEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+pATO0LFpicyY5PRtTVRbdgicoGTDnnPX2s5+/yz2PU=; b=Ejv+tJaj04Ivj4+UB1jP4SlAx18CkWvP+sTejK06KczgneZmjritCQq0/mmBGp086o9yQ3sF1JUJYseJU125SiI6C316sU51UdfEXlT2Dkx6Zz30QYXlQawRNERoJxUwYYvc2AvHEyBYpRO9g5Wx8FpQzz1pjKD5S5hhU8VNi6ebqHAk2inLJeidzNOUegJVjEX/51oETXmG6Uea+2pY3JAxb8LGR53VURc9P1u25glW4Zqk24vY4Fzj8Knhu2n+7dLHNJ/t2+yI11g5Xr76wDyuozA8yQjvf6fdxBLHkPl5VB4oWfoMag/SLr8WZAzYmADA3qZ7zjoTPGtuQdCScQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+pATO0LFpicyY5PRtTVRbdgicoGTDnnPX2s5+/yz2PU=; b=BS8GVvi9HdBsb7wad6eG8C74ko6vQv5T1wSjZ7Uxlr7h2iE6OkO2VdaRIio9NXrWZhmZx0jZQ+CN68Y4OhQ3MR2l7NYIITF/4oflpeLGIrthNhxE66/od+v9MiWhrLngyvHFQApq4Zh835BUNjtZ4cQ8PLfuU5UiXWC6G9nUwRs= Received: from SN6PR11MB3152.namprd11.prod.outlook.com (2603:10b6:805:cd::19) by SN6PR11MB2784.namprd11.prod.outlook.com (2603:10b6:805:54::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.28; Fri, 3 Jul 2020 11:11:54 +0000 Received: from SN6PR11MB3152.namprd11.prod.outlook.com ([fe80::1146:4941:6bec:a44e]) by SN6PR11MB3152.namprd11.prod.outlook.com ([fe80::1146:4941:6bec:a44e%6]) with mapi id 15.20.3153.023; Fri, 3 Jul 2020 11:11:54 +0000 From: "Vengada Prasad Govindan (venggovi)" To: "Frank Brockners (fbrockne)" , "sfc@ietf.org" Thread-Topic: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit Thread-Index: AdZK2SX2LrPrxvKtTuqDAc47v17FHAFbaSmwADj37sE= Date: Fri, 3 Jul 2020 11:11:54 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [49.206.126.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e7b1e69a-dc81-451d-1c99-08d81f41e4e6 x-ms-traffictypediagnostic: SN6PR11MB2784: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 045315E1EE x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UCI9njELtVOZ/h/MD+rJjBke3Xu6giQJGsxT0DAjvOxQLSxvbqjTwdsjq/xLk9Gh8YHibL8N9kVJ/EjMESWBRb6/4SqwXweT2Af1B8L1LFGfZVOUix7GcrtGFA5Lh1luFzWooF992Dp6FyZgd/raI/GipMSG1AdsNtvbj+NOBcu+26IsaX8Pk9JCZmoXMQ4JdIpE7a7FCOjA1pThwcbR4pJP6/v66k4P2oJYnMmDRmlF8ngNvrZfYa+H6RQKvP6iqqL02/P5kaKp5rN6ElcYOUG6OAstGfemB+saix2e83AwhWRMUrRhiMWYWgi+R8UhkxdXMChWKgmwi3wQbUmbVUSYiVs+4bWxvZx4u2hvIIRyrnTkrQ+7Gz361ISvCxAQxCGCjs2i5MDPwJ+yfo51kQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB3152.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(366004)(39860400002)(136003)(346002)(8676002)(71200400001)(66446008)(64756008)(66556008)(66476007)(66946007)(7696005)(2906002)(26005)(9686003)(55016002)(6506007)(53546011)(55236004)(8936002)(110136005)(52536014)(186003)(5660300002)(966005)(166002)(45080400002)(478600001)(33656002)(316002)(76116006)(91956017)(86362001)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PyRzMpb/uZxLgJI+IFjEsaJR4ptB5x5sNfkzOv3CHuG3uIjSTa5+c6RD6stUK5N5Vc+oJueYoPw7i0CL8CNj9d9oya1r+I1htelyzPTsMVF5QtVBE+avK1/5nS66ViUoWUtqrzkNdrZBXjezxNR3uUV4nuRB39vCUlumyKaM55FTccmp6T22+6XJ3xegdOUdsZ86Q5Rd6RYnlCMQsz8VMCBgxJLQy6a9US4CGsmvdf37sO47q2LLhFyDa1Co9GprgoZTAYh0oGFgoJvxo6nU0zoLsCogkZ7ieFU8sQP7fbKJubWNEKryiqDu6tljw7QIVESGRyjoE2wkVVHXuWfAt3T2Y7rJsxduTOfjDPy790LR+qch9myFefmp60ildX1U/gnmd6hvDGbMqfcoQpI7vWvtl1FLZFvO3FDeNmhXsoW6oZyHoTsfsDomQzwQm4D/Y9oBNyUYLNlFxMlVp1jOX6YL4r0iXPyBT3ebym4fFvc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR11MB3152B4C3FB1C08186DF50E1BCD6A0SN6PR11MB3152namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB3152.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7b1e69a-dc81-451d-1c99-08d81f41e4e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2020 11:11:54.4987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HbFUCzwdUrPw+yUDAur/1BXYzi0YGMGT6hlhKKk5EMyNLUkTdr39wcgVb/spglIR5pN46IzrB0MwL5Kymc85qA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2784 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transit X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 11:12:03 -0000 --_000_SN6PR11MB3152B4C3FB1C08186DF50E1BCD6A0SN6PR11MB3152namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for considering the comments, Frank. Prasad Get Outlook for Android ________________________________ From: Frank Brockners (fbrockne) Sent: Thursday, July 2, 2020 4:24:31 PM To: Vengada Prasad Govindan (venggovi) ; sfc@ietf.org <= sfc@ietf.org> Subject: RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-transi= t Hi Prasad, Thanks a lot for your comments. Please see inline ("..FB"). > -----Original Message----- > From: sfc On Behalf Of Vengada Prasad Govindan > (venggovi) > Sent: Donnerstag, 25. Juni 2020 13:02 > To: sfc@ietf.org > Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-tran= sit > > Hello all, > > I support progressing this draft to an Experimental RFC. Please consider = the > following comments (mostly editorial): > > 1) > Not sure what is implied by the sentence below (Sec 1): > > A particular set of nodes "to be verified" is either described by a set= of shares > of a single secret. ....FB: Good catch. We'll remove the word "either". This is an editorial le= ft-over from the time when the draft had two methods mentioned (SSSS and ne= sted crypto). > > 2) > The following sentence (Sec 1) describes about controller nodes and verif= ier > nodes. While the former's role could be easily understood, I am not sure = the > latter node role is clearly defined. If it does not limit the scope, we m= ay use only > one terminology or clarify the difference, if we need to refer about two = roles. > > The complete secret set is only known to the controller and a verifier= node, > which is typically the ultimate node on a path that performs verification= .. ....FB: A network element that compares the iteratively (by all nodes that = participate in POT on the path) computed result which is carried along in t= he packet with the secret and concludes whether the computed result matches= the secret. If the two match, the packet transit is proven. The role of th= e verifier naturally assumes that the packets had a chance to traverse the = nodes subject to POT before arriving at the verifier. We can add a short paragraph with such an explanation to the document to en= sure the role of the verifier is properly explained. > > 3) > Sec 7.9.1 > OLD > Since these schemes introduce at least additional control requirements, = the > selection of order verification SHOULD be configurable the Controller > management interface NEW Since these schemes introduce at least additiona= l > control requirements, the selection of order verification SHOULD be > configurable BY the Controller management interface ....FB: Thanks. We'll update the sentence accordingly. > > 4) > Sec 3.2 has the words Solution Approach duplicated ....FB: Thanks. Good catch. > > 5) > Not sure if there is a missing reference here (Sec: 3.3.1.3): > > For a general way to compute the modular multiplicative inverse, see = e.g., > the Euclidean algorithm. ....FB: We'll add a reference to http://en.wikipedia.org/wiki/Modular_multi= plicative_inverse#Computation > > 6) > General comment: It may be helpful to either have a diagram or a pointer = to a > diagram pointing out the different roles like Controller, ingress node. A= lso I am > not sure if there is text (other than the section in Security Considerati= ons) that > explains that POT should be deployed in a set of nodes under a single > administrative domain. ....FB: The scope of this draft is the definition of methods for proof-of-t= ransit. Like I mentioned in an earlier discussion on the SFC mailing list: An implementor of POT for SFC with NSH would need to rely on several docume= nts: - draft-ietf-sfc-proof-of-transit: for the POT concept and mechanism - draft-ietf-ippm-ioam-data: for the definition of POT related data fie= lds in IOAM - draft-ietf-sfc-ioam-nsh: for the definition of the encapsulation of P= OT related data fields in IOAM into NSH What you seem to be missing is an architecture-level discussion of how the = mix of POT+IOAM+NSH apply to the SFC architecture. IMHO this would best be = addressed by an architecture-level document, because all of the above menti= oned documents are focused on a specific subject and neither of the documen= ts would be a good fit for an architecture level definition. IMHO the best = place for that would be a "RFC 7665bis" document - i.e. we'd extend the SFC= architecture with a discussion how POT applies. That said - and this is along the lines of your comment wrt/ the verifier: = What is feasible within the scope of the document is to have an explanation= of the different roles in POT in the document (e.g. we can do this in sect= ion 3), where we discuss the role of nodes which participate in POT, the ve= rifier and the controller role, i.e. * Node: A network element through which packet transit has to be proven. * Controller: The Controller that creates secrets and secrets shares and co= nfigures the nodes for POT operations. * Verifier: A network element that compares the iteratively (by all nodes t= hat participate in POT on the path) computed result which is carried along = in the packet with the secret and concludes whether the computed result mat= ches the secret. If the two match, the packet transit is proven. The role o= f the verifier naturally assumes that the packets had a chance to traverse = the nodes subject to POT before arriving at the verifier. Thanks again, Frank > > Thanks > Prasad > > > > -----Original Message----- > > > From: sfc On Behalf Of Joel M. Halpern > > > Sent: Dienstag, 16. Juni 2020 15:42 > > > To: sfc@ietf.org > > > Subject: Re: [sfc] IETF WG state changed for > > > draft-ietf-sfc-proof-of-transit > > > > > > The chairs are starting the WG last call for > > > draft-ietf-sfc-proof-of-transit. Please reply explicitly whether > > > you think this is ready to go to the IETF for publication as a Experi= mental > RFC. > > > As noted below, the call runs through June 30. > > > > > > Note that silence does not imply consent, so please speak up. > > > > > > Yours, > > > Joel (& Jim) > > > > > > On 6/16/2020 9:32 AM, IETF Secretariat wrote: > > > > > > > > The IETF WG state of draft-ietf-sfc-proof-of-transit has been > > > > changed to "In WG Last Call" from "WG Document" by Joel Halpern: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/ > > > > > > > > Comment: > > > > This starts WG last call for this document, ending June 30. > > > > > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --_000_SN6PR11MB3152B4C3FB1C08186DF50E1BCD6A0SN6PR11MB3152namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for considering the comments, Frank.
Prasad

From: Frank Brockners (fbro= ckne) <fbrockne=3D40cisco.com@dmarc.ietf.org>
Sent: Thursday, July 2, 2020 4:24:31 PM
To: Vengada Prasad Govindan (venggovi) <venggovi@cisco.com>; s= fc@ietf.org <sfc@ietf.org>
Subject: RE: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of= -transit
 
Hi Prasad,

Thanks a lot for your comments. Please see inline ("..FB").

> -----Original Message-----
> From: sfc <sfc-bounces@ietf.org> On Behalf Of Vengada Prasad Gov= indan
> (venggovi)
> Sent: Donnerstag, 25. Juni 2020 13:02
> To: sfc@ietf.org
> Subject: Re: [sfc] IETF WG state changed for draft-ietf-sfc-proof-of-t= ransit
>
> Hello all,
>
> I support progressing this draft to an Experimental RFC. Please consid= er the
> following comments (mostly editorial):
>
> 1)
> Not sure what is implied by the sentence below (Sec 1):
> > A particular set of nodes "to be verified" is either de= scribed by a set of shares
> of a single secret.
....FB: Good catch. We'll remove the word "either". This is an ed= itorial left-over from the time when the draft had two methods mentioned (S= SSS and nested crypto).

>
> 2)
> The following sentence (Sec 1) describes about controller nodes and ve= rifier
> nodes. While the former's role could be easily understood, I am not su= re the
> latter node role is clearly defined. If it does not limit the scope, w= e may use only
> one terminology or clarify the difference, if we need to refer about t= wo roles.
> > The complete secret set is only known to  the controller and= a verifier node,
> which is typically the ultimate node on a path that performs verificat= ion..

....FB: A network element that compares the iteratively (by all nodes that = participate in POT on the path) computed result which is carried along in t= he packet with the secret and concludes whether the computed result matches= the secret. If the two match, the packet transit is proven. The role of the verifier naturally assumes that = the packets had a chance to traverse the nodes subject to POT before arrivi= ng at the verifier.

We can add a short paragraph with such an explanation to the document to en= sure the role of the verifier is properly explained.

>
> 3)
> Sec 7.9.1
> OLD
>  Since these schemes introduce at least additional control requir= ements, the
> selection of order verification SHOULD be configurable the Controller<= br> > management interface NEW Since these schemes introduce at least additi= onal
> control requirements, the selection of order verification SHOULD be > configurable BY the Controller management interface

....FB: Thanks. We'll update the sentence accordingly.

>
> 4)
> Sec 3.2 has the words Solution Approach duplicated

....FB: Thanks. Good catch.
>
> 5)
> Not sure if there is a missing reference here (Sec: 3.3.1.3):
> > For a general way to compute the modular multiplicative inverse, = see   e.g.,
> the Euclidean algorithm.

....FB: We'll add a reference to http://en.wikipedia.org/wiki/Modular_multiplicative_inverse#Computation=

>
> 6)
> General comment: It may be helpful to either have a diagram or a point= er to a
> diagram pointing out the different roles like Controller, ingress node= . Also I am
> not sure if there is text (other than the section in Security Consider= ations) that
> explains that POT should be deployed in a set of nodes under a single<= br> > administrative domain.

....FB: The scope of this draft is the definition of methods for proof-of-t= ransit. Like I mentioned in an earlier discussion on the SFC mailing list:<= br> An implementor of POT for SFC with NSH would need to rely on several docume= nts:
    - draft-ietf-sfc-proof-of-transit: for the POT concept a= nd mechanism
    - draft-ietf-ippm-ioam-data: for the definition of POT r= elated data fields in IOAM
    - draft-ietf-sfc-ioam-nsh: for the definition of the enc= apsulation of POT related data fields in IOAM into NSH
What you seem to be missing is an architecture-level discussion of how the = mix of POT+IOAM+NSH apply to the SFC architecture. IMHO this would = best be addressed by an architecture-level document, because all of the abo= ve mentioned documents are focused on a specific subject and neither of the documents would be a good fit for an a= rchitecture level definition. IMHO the best place for that would be a "= ;RFC 7665bis" document - i.e. we'd extend the SFC architecture with a = discussion how POT applies.

That said - and this is along the lines of your comment wrt/ the verifier: = What is feasible within the scope of the document is to have an explanation= of the different roles in POT in the document (e.g. we can do this in sect= ion 3), where we discuss the role of nodes which participate in POT, the verifier and the controller role, i= .e.

* Node: A network element through which packet transit has to be proven. * Controller: The Controller that creates secrets and secrets shares and co= nfigures the nodes for POT operations.
* Verifier: A network element that compares the iteratively (by all nodes t= hat participate in POT on the path) computed result which is carried along = in the packet with the secret and concludes whether the computed result mat= ches the secret. If the two match, the packet transit is proven. The role of the verifier naturally assumes t= hat the packets had a chance to traverse the nodes subject to POT before ar= riving at the verifier.

Thanks again, Frank

>
> Thanks
> Prasad
>
> > > -----Original Message-----
> > > From: sfc <sfc-bounces@ietf.org> On Behalf Of Joel M. = Halpern
> > > Sent: Dienstag, 16. Juni 2020 15:42
> > > To: sfc@ietf.org
> > > Subject: Re: [sfc] IETF WG state changed for
> > > draft-ietf-sfc-proof-of-transit
> > >
> > > The chairs are starting the WG last call for
> > > draft-ietf-sfc-proof-of-transit.  Please reply explicit= ly whether
> > > you think this is ready to go to the IETF for publication as= a Experimental
> RFC.
> > > As noted below, the call runs through June 30.
> > >
> > > Note that silence does not imply consent, so please speak up= .
> > >
> > > Yours,
> > > Joel (& Jim)
> > >
> > > On 6/16/2020 9:32 AM, IETF Secretariat wrote:
> > > >
> > > > The IETF WG state of draft-ietf-sfc-proof-of-transit ha= s been
> > > > changed to "In WG Last Call" from "WG Do= cument" by Joel Halpern:
> > > >
> > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-proof-of-transit/
> > > >
> > > > Comment:
> > > > This starts WG last call for this document, ending June= 30.
> > > >
> > >
> > > _______________________________________________
> > > sfc mailing list
> > > sfc@ietf.org
> > > https:= //www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf= .org/mailman/listinfo/sfc
--_000_SN6PR11MB3152B4C3FB1C08186DF50E1BCD6A0SN6PR11MB3152namp_-- From nobody Fri Jul 3 07:24:34 2020 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1CD3A07E0; Fri, 3 Jul 2020 07:24:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <159378627355.10469.13776754832509946736@ietfa.amsl.com> Date: Fri, 03 Jul 2020 07:24:33 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-ecn-support-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 14:24:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) Authors : Donald E. Eastlake Bob Briscoe Andrew G. Malis Filename : draft-ietf-sfc-nsh-ecn-support-03.txt Pages : 21 Date : 2020-07-03 Abstract: Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed back information about congestion to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, draft-ietf-tsvwg-tunnel-congestion-feedback). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-ecn-support/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-ecn-support-03 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-ecn-support-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-ecn-support-03 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 Fri Jul 3 07:26:44 2020 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3E3A07ED for ; Fri, 3 Jul 2020 07:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4zc-K_9K9WI for ; Fri, 3 Jul 2020 07:26:41 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 3B8383A07E6 for ; Fri, 3 Jul 2020 07:26:41 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id e64so27720608iof.12 for ; Fri, 03 Jul 2020 07:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=QvATsW9WXsahOwPc3t4hADjc7kVaFIEHORglYErCcio=; b=e/pM/4D2a2EYphbCPLTXdNE6erpI+RvSJLpZ+oeMGtPTCLRLcWodHzqaADBOBBabgi pr5XAztAwDaMAw+5iEn7FQ6ylG6ehquIx7cv5nYIzOqxROY0j1+VtTIoZ5L0FQ0bsrnu COvHqyLspoPMEdm6+NXopdrg57+pczCUz5Bl3Pj8PQq1NIl0N3kjvfij4c70ztvi+I25 PrKLNXHjP9fdhqY1yJbJ3oXBJ4fIeGpePLktPLDG4gdNZOLiUyWKIZ9RgUoIlZDS30KY GM9uulWpcqk7bU1flg3iHmcJ3o620vDTpUFwRW9bsaEQAZomapH4fw1lgnma8ro2qAT+ PkWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=QvATsW9WXsahOwPc3t4hADjc7kVaFIEHORglYErCcio=; b=SGci4PSt5UcknWOqyitlxUJO+OEl7Gfecjaa0FV1FW01vY4kSy9hH3bcugVyp0xo/T sLZObOhXvcT8nF036jGDRg/1BmSDeUqHyJDuYcalpze6A8J2EuJX/PpgvWSacdzPtMmT cOm2/tkELD7MuISUVdzqOKmGsK2QoqXyKP+b88DxzQPQx44gmIlkUQ96pZhBGGnnf4Z0 2X7OLBXEi0w7l9xpfc1yBauXMGzj9KMraIZcw1wX0wKhyvFYydlgZppReaPLghSxIBMp fORcRh/kfR3YLrmJJcYJicOVXQ1CFymkj1IL48uriDkpGyB3FqbBYRhtsDfDQy6/oUIV J0oQ== X-Gm-Message-State: AOAM531+f+aCW6ZnZrvQLMfzE1jUsC+ZqeI7jts7Ak4WQfXPSCSeFb2H jy4Lq0ulVxsSqrz3gXUQtB19azQSRrRtn/GLkXb5+cB3 X-Google-Smtp-Source: ABdhPJw99f2rHCKjwGqqnYwCcbml/K7xeeLgqYK612DRzW1tWavzFnr710grDH0eIORXC+bh4EU93SvmtvyF5jOicu8= X-Received: by 2002:a02:b899:: with SMTP id p25mr34337113jam.115.1593786400035; Fri, 03 Jul 2020 07:26:40 -0700 (PDT) MIME-Version: 1.0 References: <159378627355.10469.13776754832509946736@ietfa.amsl.com> In-Reply-To: <159378627355.10469.13776754832509946736@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 3 Jul 2020 10:26:28 -0400 Message-ID: To: sfc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-nsh-ecn-support-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 14:26:43 -0000 This is a very minor revision fixing some typos and the like. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Jul 3, 2020 at 10:24 AM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Service Function Chaining WG of the IETF. > > Title : Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) > Authors : Donald E. Eastlake > Bob Briscoe > Andrew G. Malis > Filename : draft-ietf-sfc-nsh-ecn-support-03.txt > Pages : 21 > Date : 2020-07-03 > > Abstract: > Explicit congestion notification (ECN) allows a forwarding element to > notify downstream devices of the onset of congestion without having > to drop packets. Coupled with a means to feed back information about > congestion to upstream nodes, this can improve network efficiency > through better congestion control, frequently without packet drops. > This document specifies ECN and congestion feedback support within a > Service Function Chaining (SFC) domain through use of the Network > Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, > draft-ietf-tsvwg-tunnel-congestion-feedback). > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-ecn-support/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sfc-nsh-ecn-support-03 > https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-ecn-support-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-ecn-support-03 > > > 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/ > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Jul 5 17:37:29 2020 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A41713A0C79; Sun, 5 Jul 2020 17:37:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-sfc-oam-framework@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, Tal Mizrahi , tal.mizrahi.phd@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <159399584265.930.1625381848582188379@ietfa.amsl.com> Date: Sun, 05 Jul 2020 17:37:22 -0700 Archived-At: Subject: [sfc] Alissa Cooper's No Objection on draft-ietf-sfc-oam-framework-15: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 00:37:23 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sfc-oam-framework-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENT. From nobody Tue Jul 7 06:52:21 2020 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CAC3A0CD8; Tue, 7 Jul 2020 06:52:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sfc@ietf.org, The IESG , tal.mizrahi.phd@gmail.com, Tal Mizrahi , draft-ietf-sfc-oam-framework@ietf.org, rfc-editor@rfc-editor.org, martin.vigoureux@nokia.com, sfc-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159412993107.28047.14290730342077938448@ietfa.amsl.com> Date: Tue, 07 Jul 2020 06:52:11 -0700 Archived-At: Subject: [sfc] Document Action: 'Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework' to Informational RFC (draft-ietf-sfc-oam-framework-15.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 13:52:11 -0000 The IESG has approved the following document: - 'Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework' (draft-ietf-sfc-oam-framework-15.txt) as Informational RFC This document is the product of the Service Function Chaining Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ Technical Summary This document provides a reference framework for Operations, Administration and Maintenance (OAM) for Service Function Chaining (SFC). Working Group Summary There were several (5) revisions of the document as part of WG LC which substantially improved and clarified the document. Document Quality There were multiple reviews of this document, the quality of which is satisfactory. Personnel Document Shepherd: Tal Mizrahi Responsible AD: Martin Vigoureux From nobody Tue Jul 7 07:07:32 2020 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1C03A0CE9; Tue, 7 Jul 2020 07:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 q0Y_a1l0sT0G; Tue, 7 Jul 2020 07:07:30 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 159F03A0CED; Tue, 7 Jul 2020 07:07:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4B1PQT5mKfz6GD3S; Tue, 7 Jul 2020 07:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1594130849; bh=Ljvpz7KOvL8SWU9tdbPQhkhjLODeF9t2V+bsynjH81I=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=Z5Vq8oNo476dP6XMq8fc9nwchGw04MCSdso7VZbVPKfb6u3X6JxAR+zMow5AMk2kk CkVmWGpEsThckwFGCGJ2BbYF2UBwIVcpe6J6GXw+CdY3nFY4zQxqhDEz4qUb5+XuoE J7EPKal19PSjar4JxopAPaFUlniqoAQLTPYE2QGo= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4B1PQR4vKKz6GBCw; Tue, 7 Jul 2020 07:07:27 -0700 (PDT) Cc: sfc@ietf.org, tal.mizrahi.phd@gmail.com, draft-ietf-sfc-oam-framework@ietf.org, rfc-editor@rfc-editor.org, martin.vigoureux@nokia.com, sfc-chairs@ietf.org References: <159412993107.28047.14290730342077938448@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <1e85722e-a731-fbb0-8fc4-1bdd44611db7@joelhalpern.com> Date: Tue, 7 Jul 2020 10:07:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159412993107.28047.14290730342077938448@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Document Action: 'Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework' to Informational RFC (draft-ietf-sfc-oam-framework-15.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 14:07:31 -0000 Congratulations to the authors, shepherd, and WG on another useful document moving to RFC. Thank you, Joel On 7/7/2020 9:52 AM, The IESG wrote: > The IESG has approved the following document: > - 'Service Function Chaining (SFC) Operations, Administration and > Maintenance (OAM) Framework' > (draft-ietf-sfc-oam-framework-15.txt) as Informational RFC > > This document is the product of the Service Function Chaining Working Group. > > The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin > Vigoureux. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ > > > > > > Technical Summary > > This document provides a reference framework for Operations, > Administration and Maintenance (OAM) for Service Function Chaining > (SFC). > > Working Group Summary > > There were several (5) revisions of the document as part of WG LC which substantially improved and clarified the document. > > Document Quality > > There were multiple reviews of this document, the quality of which is satisfactory. > > Personnel > > Document Shepherd: Tal Mizrahi > Responsible AD: Martin Vigoureux > From nobody Tue Jul 7 08:29:20 2020 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5893A3A0E5E; Tue, 7 Jul 2020 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=cP/tUWg+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FdWq3prK 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 e4hP2QMsloIE; Tue, 7 Jul 2020 08:29:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07593A0E5B; Tue, 7 Jul 2020 08:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1480; q=dns/txt; s=iport; t=1594135756; x=1595345356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=o18HhjkR4EFK0b6pXM5HfWOy3LRRiYRQD6QcZi8BuYE=; b=cP/tUWg+8V9XBFI1uVSEIAbV5rBNxVURj0ASENZTfBHVi4q5lHzEIBvV eMTRv9YDmelnTo4gLdqjVtsmM4yDfnu7QjHOMjjqD+T0H5gvHrRGzuVT0 5N+n8z7tdY40GEDDdCd72RSJdLsGUDVrNTwX9sXicRJERaTWqMhd7tHda E=; IronPort-PHdr: =?us-ascii?q?9a23=3AHqMEGRU+MaV4fpxn7iJ9TA/gsGjV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+FufBDhu7WuqT4VHYGp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0QHR?= =?us-ascii?q?j7NQNxPunvHMjZiMHkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRegYZrJqsrjB?= =?us-ascii?q?XTpX4dcOVNzmQuLlWWzBs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AAA+lARf/5NdJa1gGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUqBUlEHb1gvLAqHbgONTJhaglI?= =?us-ascii?q?DVQsBAQEMAQEjCgIEAQGERwKCEQIkOBMCAwEBCwEBBQEBAQIBBgRthVsMhW4?= =?us-ascii?q?BAQEBAgESKAYBATcBBAsCAQgYHgULMiUCBA4FIoMEAYJLAw4gAQ6ePAKBOYh?= =?us-ascii?q?hdIE0gwEBAQWBRkGDEBiCDgMGgTgBgmiKARqBQT+BESccgk0+glwCAwGBW4N?= =?us-ascii?q?Jggsijy6CUAGSOpBWCoJciEuQfwMdnx2bdpB0g1ECBAIEBQIOAQEFgWoigVZ?= =?us-ascii?q?wFWUBgj4+EhcCDY4eN4M6hRSFQnQ3AgYIAQEDCXyOXgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,324,1589241600"; d="scan'208";a="794252248" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jul 2020 15:29:15 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 067FTF85026551 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jul 2020 15:29:15 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Jul 2020 10:29:15 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Jul 2020 10:29:14 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 7 Jul 2020 11:29:14 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RltbBlx54NI+od7WfR96X21mknpk5MyEqvAMZSlGDqX4LDXeelehm0ou6LaD/iH4ozMjtYsG5OMqbdmBu5qljb3XGHF1xP2OuEws4jlVIvfgO/1G9suurN0MYvReV3jApAL6hvqd1nav2Lecug4fARLpqLafRPghQocR9pnWnmMOBH5U3ZGFs68zoMqwoXJObtGYEkuO4inIjOU5g5yxqxOY7pqmaTfeyrWOBAQx8cmObyqXSES/tCy0o2MKyfP0EUV95vpakCST90lE6r+NWlZxH/5LP1irniWo5063uDco3cr8CSYwgmh4nPz97DLlqFUCzdZvydGtSAf3ACgDIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zhZeC4CZsKBQMsNEqSPsPddxZgmweguiUpXgTC+CsDo=; b=oGqo0udLQdh/+6Vb7n7KkAL9aTRp/NwW3ibMqTID0muvHF0QTr3SoaHpEpvt6hicqTKalUgtv6XFP5xR/yqyuAvQ332ZXzeba9IsoG5VtaEIio7U7xcUBlDasu9vwYeFEFqdOHiSzHYpfpsTcx94CV1WtfzHu49EsBtGzcIdEgjovx5aBsqLq6gxAliN8n0xru/sz/FZwFNMRhoKdjkRRGr72+rMEnNW/CPS2Do8OkFmHYcrzkYbbZFOKIzV7j0V4OSOFYK290sg5e2cRLx2ulvYG1g+kyYnv1Kj2aLtXv1Ds4SXdrIJtwo7XLK4gAuqu9J5sO+hpcWFr6aTlhRmIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zhZeC4CZsKBQMsNEqSPsPddxZgmweguiUpXgTC+CsDo=; b=FdWq3prKJe3UI3iuH+iG8gnjnfWSARxAUu06xAd8XIUf1/LCl5DoMbptEpuXHioqSG/+lz4KUMBynXc2Nihl2OHa1ydBEBlGjc50pMcSePnzJ7h7EqAqQd2pJe6MmfWXM2Q4hNeFiCpmskGQERxpAvAcyoKmAq+Ur//WI2AsOtI= Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3794.namprd11.prod.outlook.com (2603:10b6:408:8f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.22; Tue, 7 Jul 2020 15:29:13 +0000 Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::c0e8:9942:9972:5590]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::c0e8:9942:9972:5590%5]) with mapi id 15.20.3153.029; Tue, 7 Jul 2020 15:29:13 +0000 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" CC: Service Function Chaining IETF list , Tal Mizrahi , "draft-ietf-sfc-oam-framework@ietf.org" , Martin Vigoureux , "sfc-chairs@ietf.org" Thread-Topic: Document Action: 'Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework' to Informational RFC (draft-ietf-sfc-oam-framework-15.txt) Thread-Index: AQHWVGXVSYhjvFDcr0O8jTOijsPInKj8JxYAgAAW2QA= Date: Tue, 7 Jul 2020 15:29:13 +0000 Message-ID: <4B464CE2-D6CC-463C-95A6-2F3FF8FE6601@cisco.com> References: <159412993107.28047.14290730342077938448@ietfa.amsl.com> <1e85722e-a731-fbb0-8fc4-1bdd44611db7@joelhalpern.com> In-Reply-To: <1e85722e-a731-fbb0-8fc4-1bdd44611db7@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a97b7a63-b1d8-4355-b135-08d8228a80b4 x-ms-traffictypediagnostic: BN8PR11MB3794: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0457F11EAF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h9FrmUF5ejnrgQhyx24K4MGTZSy8VdHQRbnW/5k7nY8Gmb5Cofnn1EXVUgxi4Sgg3sDHxczxK8FIJ9qxqeepFhuORW2ECIfuIgXEZ2Nbpu6gOMANmJQy6KDVSNmJlqKrTlOlMgdho6VLfHk83/0rZQhm/J/f3WVu0QIFQD4Z/eQW3P5uaXpgdzxoVgCReRfG5MA3GtUZJvj3eeVSsThc7BYCkA3tORnKtavs8uQMqtkNCrZpnBNk273QYCdoUrXByYM+CIATwJ19wS0BVmcdg0q4KCIZJXfu7RhlnVGraqpUzENftdlX0KXa09hBxIeSOw3EFK9z41LGPhG8ZnlrRF/pZ11dDhWyDG0hYhlLrpmHaJ4iDlpVwJFfvNgQVGysdS/We4z6kiRdhNA6pDAHYQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(346002)(39860400002)(376002)(2616005)(36756003)(966005)(53546011)(4326008)(66574015)(83380400001)(6916009)(478600001)(6506007)(66476007)(5660300002)(186003)(316002)(6512007)(33656002)(66446008)(71200400001)(26005)(6486002)(86362001)(91956017)(64756008)(76116006)(54906003)(66556008)(8936002)(2906002)(66946007)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: lW8fwTEebPWta+FJiYwSQP4NyIg5K1WUPen0/p4NpnKmbNpzi0BrRzXI9t6vffsDAMLu0sjSKVMwhsmDJ3BSwxhob8tNrd1/K35UUdFPf1golAH8HT3y7pibg94ouzgR0XeanHWHL4DvgZyD0koXyk/1kta/AqH4fKRHDrX7w3OKk0bSTix6Vo5zKx300RchFJBwRZErYMdnpaTOb7jtcGFg+DW7n5FlZutAu22xWEdd5fVB8Ol5NovGMUM82oSy5ZICnPTC/Ldj0sjEFz6zmDLkbIbYmWK2zAMBKfOlPkUouBm3wTwu279u1DVZatNxxxfVJipgPKpVDr5HfKxm5B87YErIO1pRALHG6eNiHFV8RrcG6ktguI4snGgUd1DS55aQxpqPY21qQpY+QFgyGKLuUotZb4vrzOfUp3z+rc8X6KC/nSBpScDIh2ejTHXFWVBjfFPiuVN2DJgGlZKI1zbTPtOhtsHA13wyT5rKPhNu7eLHZ3rcZIwbLGImgZEF x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <6858D9274B3F2B429946F3DB43DF60CF@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR11MB3635.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a97b7a63-b1d8-4355-b135-08d8228a80b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2020 15:29:13.1772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I/rY5UKXuePQSN8SjSP3LSA7v7OJnG7CBLys5hds2yJ0Si86Z+onfK0P+mc+fh3Sa4mIxGJV7hQQnP/PW601HA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3794 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [sfc] Document Action: 'Service Function Chaining (SFC) Operations, Administration and Maintenance (OAM) Framework' to Informational RFC (draft-ietf-sfc-oam-framework-15.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 15:29:19 -0000 And congrats to the chairs as well :-)=20 More importantly to the WG, another milestone completed, and a solid framew= ork for any forthcoming OAM work. Thanks! Carlos. > On Jul 7, 2020, at 10:07 AM, Joel M. Halpern wrote: >=20 > Congratulations to the authors, shepherd, and WG on another useful docume= nt moving to RFC. >=20 > Thank you, > Joel >=20 > On 7/7/2020 9:52 AM, The IESG wrote: >> The IESG has approved the following document: >> - 'Service Function Chaining (SFC) Operations, Administration and >> Maintenance (OAM) Framework' >> (draft-ietf-sfc-oam-framework-15.txt) as Informational RFC >> This document is the product of the Service Function Chaining Working Gr= oup. >> The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin >> Vigoureux. >> A URL of this Internet Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/ >> Technical Summary >> This document provides a reference framework for Operations, >> Administration and Maintenance (OAM) for Service Function Chaining >> (SFC). >> Working Group Summary >> There were several (5) revisions of the document as part of WG LC whi= ch substantially improved and clarified the document. >> Document Quality >> There were multiple reviews of this document, the quality of which is= satisfactory. >> Personnel >> Document Shepherd: Tal Mizrahi >> Responsible AD: Martin Vigoureux From nobody Sat Jul 25 14:06:01 2020 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AC33A0B1F; Sat, 25 Jul 2020 14:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 1yUzZSH6CK1T; Sat, 25 Jul 2020 14:05:40 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 C20283A0B0A; Sat, 25 Jul 2020 14:05:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BDdrg4Jgtz6G9jT; Sat, 25 Jul 2020 14:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1595711139; bh=CJ9+ODxjvFN9ewNuyXDlH4bVPTiFwZNYGdthX5aroWE=; h=Subject:References:To:From:Date:In-Reply-To:From; b=IYnkJ2qE+tMB6h47GUpFTkf+pRsUMDPdwrbONZXqzBe3AqiHa+Ez5E69xfkBYcpdW WHIJcdLEAwwoUUpJkB00Jp6SxQQjorvWyz7vTjlQe1Sr2zOCBITRIGpD2GmzvoJ9hm tI/ershEreE1vgW2OvInbYck1mNrspzNlf/uYLOE= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BDdrf6tFSz6G9dQ; Sat, 25 Jul 2020 14:05:38 -0700 (PDT) References: To: "lisp@ietf.org" , "sfc@ietf.org" , "spring@ietf.org" From: Joel Halpern X-Forwarded-Message-Id: Message-ID: Date: Sat, 25 Jul 2020 17:05:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Fwd: Encourage people to visit NomCom during office hours X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 21:05:50 -0000 Forwarding for your information as requested by the nomcom chair. Thank you, Joel -------- Forwarded Message -------- Subject: Encourage people to visit NomCom during office hours Date: Sat, 25 Jul 2020 20:16:18 +0000 From: STARK, BARBARA H To: 'Working Group Chairs' Hi WG Chairs, Could you let your groups know that if anyone is interested in finding out more about NomCom or about standing for an I* position (or just wants to say Hi), they can visit with NomCom during office hours next week? Thx, Barbara Here is the message I sent to the ietf list: ------------------------------------------------------------------------------------------------------------------------------- I wanted to let everyone know that NomCom will be holding some office hours next week. If you want to stop by and talk with us (just to say Hi, ask about NomCom, ask about being a nominee for the various I* positions, etc.), we'd love to see and hear from you. The date and times (which are also posted on the IETF 108 Agenda) are: Monday, July 27, 16:00-17:00 UTC WebEx: https://ietf.webex.com/ietf/j.php?MTID=m13c41ae118e538b6d25efb25d41307ee Tuesday, July 28, 09:30-10:30 UTC WebEx: https://ietf.webex.com/ietf/j.php?MTID=m6132b48c3eac5469a41043ce55dada20 Thursday, July 30, 20:00-21:00 UTC WebEx: https://ietf.webex.com/ietf/j..php?MTID=mf7ce451931e35818fd7b3bf44abd1026 In addition to being available by WebEx, those of us who can will simultaneously be on Gather.Town (possibly in a special NomCom corner). To find us, the easiest way is to go to the Participants list (at right of the Gather screen), find "Barbara Stark", left click on my name and select "Locate". See you next week! Barbara