From nobody Sat Oct 1 20:00:00 2016 Return-Path: <7riw77@gmail.com> X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2E212B0A3 for ; Sat, 1 Oct 2016 19:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, 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 KfhQlVnU9vpJ for ; Sat, 1 Oct 2016 19:59:58 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 6DA8612B01C for ; Sat, 1 Oct 2016 19:59:58 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id j69so91631109itb.0 for ; Sat, 01 Oct 2016 19:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=C2Dkofz7aCo3px1z53e7iAX9s6d62cNuH1Ybmfqsmis=; b=bVAUXnGWpXIZJpw6RdUR7o9K5S1MPL/0D5qP6sx+fXUtVV/jrITgnhMtKreIkJZVbB VmFIaeFU3onZ7JDGPIBwmnNlH3FAu/5VG0QuG9Pd3ieWID+g3Et9SxhvMBox6BTJoIkV KiI4FsohYho0SR+d49lyRBycpWSen/w+sV1hFY4u6/HG80UqspeQfc6McgsoRAH2LgPa hqaJa6gsgV+84y429AR24UIxW0aIqDAYv6Jk6VsY4HeM6LxVQNgLRnQgQHnlCxMGwMBQ HKE0H7q6/WcaT4eduA65Ewp8CjbSfjdFbQAb7CQtBLEi9e2piL3XrjUFpz6KPGTNPp7t h5CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=C2Dkofz7aCo3px1z53e7iAX9s6d62cNuH1Ybmfqsmis=; b=XVrtWC5aLA11/1HtDJYaHspPoG2pQqpENy8Q1aZZMLp2ubf3OSVl9IEXTTX+c0QuPx fQNr13JhhaKNhko4wTyrG9CFt3uGCO/b0D1Pr9zDlvKnj87DE7kuJ5JZ5FKeUgm3NRNL jqY1Y3RZsBEznR37fsvtNRciYfEzdgOzbAGX0yU1Yx7docU/3zJv1dBd9RR6R9kBDvWN H46rTXf5Z7AeqOGup03DEluDQUTkcszH9La0/hu7CKnpfhGUPgHVEHwCDhmg3fioSDcK Pn4/ERlHoIcdEdgCDOL14wuyV+9L4ypnG4o5cFmoBhOaqcGRUbe91+wh+m9XaeJlxhry Ym+A== X-Gm-Message-State: AA6/9RkPjq5lSLcvjoDmFWpRPajtFLFKUkNDGvdHa1wK6z4ch21Ftp4wSCDnm0IWYATv3A== X-Received: by 10.36.192.193 with SMTP id u184mr10921448itf.91.1475377197562; Sat, 01 Oct 2016 19:59:57 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id 63sm5086942itz.7.2016.10.01.19.59.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Oct 2016 19:59:57 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: Date: Sat, 1 Oct 2016 22:59:54 -0400 Message-ID: <000b01d21c59$0e0a7880$2a1f6980$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIcV0OKgh3iy5ZkQsGomkg6hZaL0w== Content-Language: en-us Archived-At: Subject: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al... X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 02:59:59 -0000 Y'all -- I would like to suggest we add one more next hop type in section 2.4 of draft-ietf-i2rs-rib-data-model, and sections 2.4 & 7.2 of draft-ietf-i2rs-rib-info-model to include a nexthop type that tells the forwarding device to not use a particular next hop without sending traffic to dev/null. The specific case is this -- assume I have an ECMP group with 32 or 64 entries. In this group, I want to pin one flow to a particular set of links, while making certain some other set of flows do _not_ use those links. The only way to accomplish this today would be to replace every route with the same ECMP group to provide a different set of next hops for each one. It would be cleaner to have a construction that says, "take this next hop out of all ECMP groups, so it is only used when specified by this client," or some such. Maybe something like this in section 7.2 of the rib data model might work -- == 7.4. Remove from ECMP next hop If the a particular route is marked "remove from ECMP," then any routes which recurse onto this next hop as part of an ECMP group will remove any paths using this route as a next hop from the ECMP group. This allows the I2RS controller to remove ECMP traffic from a particular next hop to attain finer grained control over the use of specific links to which particular elephant flows may be pinned, or which may be otherwise congested, etc. == I don't know of any implementation that could do this right now, but this seems like a useful addition to the set of available next hops (?). :-) Russ From nobody Sun Oct 2 15:20:48 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A497812B03D for ; Sun, 2 Oct 2016 15:20:47 -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 6NMbxz-Gt1TE for ; Sun, 2 Oct 2016 15:20:46 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 2753212B025 for ; Sun, 2 Oct 2016 15:20:46 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e6so1303344pfk.1 for ; Sun, 02 Oct 2016 15:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YTbFZhECSYosvzguKiOCN1/AKxg3/zjgCzvVOB6O2A=; b=zGTaEfkw4nl24T44xuPCD5TYYxffj0GmuJd+DNp6RKP9yUIVnrD+tXmXXgSoN9T45u b9UaHudpdvQlBFyu1k2c/K49dKf7obbJ2HsCJdzRlFNUmD/vUo+/BD9ZVE6ZU8JAgzhN qtillvZuoQIjblYM/gdxtVraFETRU8bm4MADRwW/J6YDWcwN8fVKeS/yRmGxlwhJU0rG xPGtVMYnWrixK9lzHTaqMYqAODSaqzUn58GO89wqrrFgxn3JCY67kBnrwOpQgxFzD8Qb aG3VfM06M1qADvJXwdoC9Gr1hX5xe//HcyfiYYRUvfMhWngXOBivjEFskZqQ/snsSLPH xP1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YTbFZhECSYosvzguKiOCN1/AKxg3/zjgCzvVOB6O2A=; b=UY/dYK5VVCAN9lyc0D3mCpYDQP2NkDGSDF98G4nb3dQ9FKB0xAHs3MvulioUQl3WVv Gx+lrvY7M9CVwb+qgDO9FvKsNMMquFDaMg+YaqN1PHecTF4nGdd4aByfnJRamfstldF6 IpOk5DJkcw+e8BfQ+CKwx331hDRV+Eju2aSWL2rDU7o8LXBICKqICDzSKdV9Ry0dfWwu N85c77fv93oy7bYfPiyi2UsT1Ti96X7L2kJq9bEj94Ih43ly8KxtJiPgY2mGsv+UGeU2 YAsI3wFlQBc8bMMeMU69akLHcc0wTbJ/qg9baMXK3nKPPcyluO20IzG28aTEwX5kAaZ1 DVcw== X-Gm-Message-State: AA6/9RnfztSAp3IqlHUrJ34gLzEK+IVoK/UkW7Q3qCxUbwmz2K8G3jyEO9uaQSCL+YUeNg== X-Received: by 10.98.55.71 with SMTP id e68mr31979295pfa.147.1475446845640; Sun, 02 Oct 2016 15:20:45 -0700 (PDT) Received: from [10.243.3.206] (mobile-166-176-56-30.mycingular.net. [166.176.56.30]) by smtp.gmail.com with ESMTPSA id c64sm35712256pfa.0.2016.10.02.15.20.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Oct 2016 15:20:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14A456) In-Reply-To: <000b01d21c59$0e0a7880$2a1f6980$@gmail.com> Date: Sun, 2 Oct 2016 15:20:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5010C073-5BB9-48A1-8491-C975F2338728@gmail.com> References: <000b01d21c59$0e0a7880$2a1f6980$@gmail.com> To: Russ White <7riw77@gmail.com> Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al... X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 22:20:47 -0000 Russ, What would be the semantics of such NH? Don't use for forwarding at all? Don't use for forwarding within ECMP bunde?= Don't use in ECMP but use otherwise? Regards, Jeff > On Oct 1, 2016, at 7:59 PM, Russ White <7riw77@gmail.com> wrote: >=20 > Y'all --=20 >=20 > I would like to suggest we add one more next hop type in section 2.4 of > draft-ietf-i2rs-rib-data-model, and sections 2.4 & 7.2 of > draft-ietf-i2rs-rib-info-model to include a nexthop type that tells the > forwarding device to not use a particular next hop without sending traffic= > to dev/null. The specific case is this -- assume I have an ECMP group with= > 32 or 64 entries. In this group, I want to pin one flow to a particular se= t > of links, while making certain some other set of flows do _not_ use those > links. The only way to accomplish this today would be to replace every rou= te > with the same ECMP group to provide a different set of next hops for each > one. It would be cleaner to have a construction that says, "take this next= > hop out of all ECMP groups, so it is only used when specified by this > client," or some such. >=20 > Maybe something like this in section 7.2 of the rib data model might work -= - >=20 > =3D=3D > 7.4. Remove from ECMP next hop >=20 > If the a particular route is marked "remove from ECMP," then any routes > which recurse onto this next hop as part of an ECMP group will remove any > paths using this route as a next hop from the ECMP group. This allows the > I2RS controller to remove ECMP traffic from a particular next hop to attai= n > finer grained control over the use of specific links to which particular > elephant flows may be pinned, or which may be otherwise congested, etc. > =3D=3D >=20 > I don't know of any implementation that could do this right now, but this > seems like a useful addition to the set of available next hops (?). >=20 > :-) >=20 > Russ >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Oct 2 15:29:26 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291FA12B0FF for ; Sun, 2 Oct 2016 15:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_HELO_PASS=-0.001, SPF_PASS=-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 torYPVG-BoQH for ; Sun, 2 Oct 2016 15:29:22 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 B71BB12B0F4 for ; Sun, 2 Oct 2016 15:29:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9FCDF1C0D44; Sun, 2 Oct 2016 15:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1475447362; bh=4K8PeEXPFO7w5SmqH9LC7HFet/FPv8136vr3VvTzIJI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YZ8HxDoJXcs5Ym8DIGOBoSqtv7ZyZN7Z3ZJTMSdC9P83DD/+Gina404u7w8NPYSnA F5jziNf4NsfkzaDmyKlclfHiEs5j+ES1JSiw+aMHxD9/Y1A+BU71xQORY9QgPl0qQB 4JiH2P2gIQQ2rOeT5mvVYjyZS6oGmbZezyFioxDw= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4328E1C05A0; Sun, 2 Oct 2016 15:29:21 -0700 (PDT) To: Jeff Tantsura , Russ White <7riw77@gmail.com> References: <000b01d21c59$0e0a7880$2a1f6980$@gmail.com> <5010C073-5BB9-48A1-8491-C975F2338728@gmail.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 2 Oct 2016 18:29:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <5010C073-5BB9-48A1-8491-C975F2338728@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al... X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2016 22:29:24 -0000 To add to that, I am wondering about ading this now. Unless I am confused, and we have also made a serious mistake, the model is quite extensible. It is highly likely that we will add additional next hop types in the future. If we do not yet know of any use for this particularly one, why add it now? Yours, Joel On 10/2/16 6:20 PM, Jeff Tantsura wrote: > Russ, > > What would be the semantics of such NH? > Don't use for forwarding at all? Don't use for forwarding within ECMP bunde? Don't use in ECMP but use otherwise? > > Regards, > Jeff > >> On Oct 1, 2016, at 7:59 PM, Russ White <7riw77@gmail.com> wrote: >> >> Y'all -- >> >> I would like to suggest we add one more next hop type in section 2.4 of >> draft-ietf-i2rs-rib-data-model, and sections 2.4 & 7.2 of >> draft-ietf-i2rs-rib-info-model to include a nexthop type that tells the >> forwarding device to not use a particular next hop without sending traffic >> to dev/null. The specific case is this -- assume I have an ECMP group with >> 32 or 64 entries. In this group, I want to pin one flow to a particular set >> of links, while making certain some other set of flows do _not_ use those >> links. The only way to accomplish this today would be to replace every route >> with the same ECMP group to provide a different set of next hops for each >> one. It would be cleaner to have a construction that says, "take this next >> hop out of all ECMP groups, so it is only used when specified by this >> client," or some such. >> >> Maybe something like this in section 7.2 of the rib data model might work -- >> >> == >> 7.4. Remove from ECMP next hop >> >> If the a particular route is marked "remove from ECMP," then any routes >> which recurse onto this next hop as part of an ECMP group will remove any >> paths using this route as a next hop from the ECMP group. This allows the >> I2RS controller to remove ECMP traffic from a particular next hop to attain >> finer grained control over the use of specific links to which particular >> elephant flows may be pinned, or which may be otherwise congested, etc. >> == >> >> I don't know of any implementation that could do this right now, but this >> seems like a useful addition to the set of available next hops (?). >> >> :-) >> >> Russ >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Oct 3 03:45:08 2016 Return-Path: <7riw77@gmail.com> X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7023312B1C7 for ; Mon, 3 Oct 2016 03:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, 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 R9kUI_u3_Q95 for ; Mon, 3 Oct 2016 03:45:04 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 6347E12B1B3 for ; Mon, 3 Oct 2016 03:45:04 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id j129so150509706qkd.1 for ; Mon, 03 Oct 2016 03:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Fpd7ky/nJtBBJX6TQFjTgPJRaoc/r8mE11dliNgE4IA=; b=GeeBUpXKFouFxWSKoSAIgB5Jp4ivIiKOA8Sf6b4YapnqfJEiKcEy7n7qzzGKjxzWtM OJt/YaUs+wgLh9m6E5OUDGKNMPJpBg0hWvK0Zq1+Gzpu7Pz76/mA1UuGNTq0EiINie7G +g87pyg0QeOGwCmWP1AlDV+e2fi4qJF29BDjLVO4BgnnTniPEDuroM9u40xOqvYWqnLu 94QAhpSbOKEXBpJVvyUDkuwtlMCnV5Ob4gHj3Sb4WnZWyo2zZH2qlokLpubPDpG7djSO Smzfq8oIzhjCzVM9Vp11DZdp8hfoX8OwunveZEINfTYAL3kYnESAVFGNcuRJdXfEnuSZ s5qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Fpd7ky/nJtBBJX6TQFjTgPJRaoc/r8mE11dliNgE4IA=; b=WwJcH0NBR1uhENAtrUyUr5uIR1YlhkiUq6apZr2LRjrds3Pv9v0jEbPtMpEhQxN7AK pTXiLbNCaMq4fh4X6lEa+6sIUkWZmgCN7MhfLQepweOT8U+S2gMtfgeqkkdGaUDJUfUl uODI5VrtrbUzJLsTq4NqOpCLbQpxQvvE8eBiQVX3mUv8U0V92FLeLGc+PgD3ftfwqiqJ M2Y3uu/ojQvLMHJ16rAhEi6xn8xieAOy2e9NLYAbDkNnpbPjKzt3KsJ4soBs59rOGfJN n8BDu0rlTmiMLiGOvKbtsGoDaIdUv4keAWcnR2WpiVCAQ50wQfcWopBzlh9mwQ17FwTN 2TWw== X-Gm-Message-State: AA6/9RmiAC98moeMWHqXCREHvzeLNAIhH0aivY4BT/R/ttJBEdyZNzrD1z1ElwUlxV+xDw== X-Received: by 10.55.209.207 with SMTP id o76mr3648756qkl.276.1475491503515; Mon, 03 Oct 2016 03:45:03 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id t35sm2551166qta.23.2016.10.03.03.45.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Oct 2016 03:45:03 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Jeff Tantsura'" References: <000b01d21c59$0e0a7880$2a1f6980$@gmail.com> <5010C073-5BB9-48A1-8491-C975F2338728@gmail.com> In-Reply-To: <5010C073-5BB9-48A1-8491-C975F2338728@gmail.com> Date: Mon, 3 Oct 2016 06:44:59 -0400 Message-ID: <007e01d21d63$30c09160$9241b420$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJvMHXZL2W1YKTA2DnmC+V+0w+s6AFZCLE+n1GcX7A= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al... X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 10:45:05 -0000 > What would be the semantics of such NH? > Don't use for forwarding at all? Don't use for forwarding within ECMP bunde? > Don't use in ECMP but use otherwise? "Don't use as a next hop in an ECMP bundle but use otherwise..." The problem I'm having (to answer Joel's follow on question) is this isn't really a "route," but specific to a particular route that's being used (even if connected) as a next hop -- so it's not really a new "next hop" type, I don't think... Rather, it would be a way to override the use of an existing route for recursion by other routes -- I don't know if this is possible in the current models. Thoughts? :-) Russ From nobody Mon Oct 3 10:15:37 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D67DB12942F; Mon, 3 Oct 2016 10:15:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147551493587.29632.6445764774340299886.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2016 10:15:35 -0700 Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, The IESG , jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, rfc-editor@rfc-editor.org Subject: [i2rs] Document Action: 'I2RS Security Related Requirements' to Informational RFC (draft-ietf-i2rs-protocol-security-requirements-17.txt) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2016 17:15:36 -0000 The IESG has approved the following document: - 'I2RS Security Related Requirements' (draft-ietf-i2rs-protocol-security-requirements-17.txt) as Informational RFC This document is the product of the Interface to the Routing System Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ Technical Summary This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. Working Group Summary Working consensus for requirements was honed over 6 months (May -Nov 2015). WG LC done with All of requirement drafts 10/6/2015 to 10/20/2015 Document Quality This draft comes out of discussion with the I2RS WG and various security experts, and security directorate reviewers. The last SEC-DIR messages on this topic was: http://www.ietf.org/mail-archive/web/secdir/current/msg05942.html last message: http://www.ietf.org/mail-archive/web/secdir/current/msg05964.html NETCONF: It has been reviewed by the NETCONF WG (July 2015, Nov 2015), and all issues were declared resolved as of November 2015. A significant number of vendors have indicated their plan to expand existing protocols to create an IRS amalgamate protocol. A list includes the following: Cisco, Juniper, Huawei, Ericsson, Google, Packetdesign (Client software) and others. Personnel Document shepherd: Jeff Haas AD: Alia Atlas From nobody Tue Oct 4 08:47:25 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD791295EF for ; Tue, 4 Oct 2016 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYEW3f8V2ogS for ; Tue, 4 Oct 2016 08:47:22 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17111295C9 for ; Tue, 4 Oct 2016 08:47:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.175.11; From: "Susan Hares" To: "'Linda Dunbar'" , References: <20c001d21348$831721b0$89456510$@ndzh.com> <48E1A67CB9CA044EADFEAB87D814BFF64A8D27B5@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F657F49D8A@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F49D8A@dfweml501-mbb> Date: Tue, 4 Oct 2016 11:45:15 -0400 Message-ID: <0e7301d21e56$4d9cd430$e8d67c90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E74_01D21E34.C68C6CB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGd+gow88rPsNFqB1p29RyAoHO3IgIE7NTcAi+nwLqg3uiuoA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Benoit Claise' , 'Russ White' , 'Alia Atlas' Subject: Re: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo-05.txt extended and draft-ietf-i2rs-yang-l3-network-topo-06.txt ( X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 15:47:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E74_01D21E34.C68C6CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS WG: The topology models have passed WG LC. These drafts will be forwarded to the IESG for publication this week. draft-ietf-i2rs-yang-network-topo draft-ietf-i2rs-yang-l3-topology Sue Hares and Russ White From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, September 20, 2016 10:09 AM To: i2rs@ietf.org Cc: 'Benoit Claise' ; 'Russ White' ; 'Alia Atlas' Subject: [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo-05.txt extended and draft-ietf-i2rs-yang-l3-network-topo-06.txt ( This begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-04.txt (9/20 to 10/4) and draft-ietf-i2rs-yang-l3-network-topo-06.txt from 9/20 to 10/3. https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ In considering this draft, the I2RS WG should consider: 1) Does the implementations of this draft in ODL open source code base sufficient experience on the Yang drafts? 2) Does anyone know of other implementations of this model? 3) Do you believe this Yang model is stable enough to publish and distribute to yang libraries? We did a WG LC in August, but we suspect this got caught in the August vacation email. Sue Hares and Russ White Co-chairs ------=_NextPart_000_0E74_01D21E34.C68C6CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS WG:

 

The = topology models have passed WG LC.  These drafts will be forwarded = to the IESG for publication this week.

 

draft-ietf-i2rs-yang-network-topo

draft-ietf-i2rs-yang-l3-topology =

 

Sue Hares and Russ White =

 

From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, September 20, = 2016 10:09 AM
To: i2rs@ietf.org
Cc: 'Benoit = Claise' <bclaise@cisco.com>; 'Russ = White' <russ@riw.us>; 'Alia = Atlas' <akatlas@gmail.com>
Subject= : [i2rs] WG LC on draft-ietf-i2rs-yang-network-topo-05.txt extended = and draft-ietf-i2rs-yang-l3-network-topo-06.txt = (

 

This begins a 2 week WG LC on = draft-ietf-i2rs-yang-network-topo-04.txt (9/20 to 10/4) and = draft-ietf-i2rs-yang-l3-network-topo-06.txt from 9/20 to 10/3. =  

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/<=
o:p>

In considering this draft, the I2RS WG = should consider:

1)      = Does the = implementations of this draft in ODL open source code base sufficient = experience on the Yang drafts?

2)      = Does anyone know of = other implementations of this model?

3)      =  Do you believe = this Yang model is stable enough to publish and distribute to yang = libraries?

 We did a WG LC in August, but we = suspect this got caught in the August vacation email.  =

Sue Hares and Russ = White

Co-chairs

 

------=_NextPart_000_0E74_01D21E34.C68C6CB0-- From nobody Tue Oct 4 19:37:12 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D08127077; Tue, 4 Oct 2016 19:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tkuoddw3oLBd; Tue, 4 Oct 2016 19:37:09 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A66127076; Tue, 4 Oct 2016 19:37:06 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i129so149268250ywb.0; Tue, 04 Oct 2016 19:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=2njB3YfBIgeTAuj/zGkJbmRMVdz4pRBlWpXs1ktp5Cg=; b=oNYw51O8uLEu01sf+6GZjQxr8XZyfpotQln+Oixqsx8YZJnfVUsH6taBj3yG7EFtQ9 9w3yYiehfsdtp1t2NqSCUwTIJmfMi9QF/98BSnyQbp+Cw/C+7yYIWEL26wgV8Fu62jae faZWqpMP4s4Ihnn5U/HGq1GXFNj71lb4xau8fdXtxy0fl/rsDNz7wm5s7FapTADBbLmV mrDVr3kKK8u8zhf7QgHJF9b58LZiWA3gH2UeGtQ+7WOWY448F+i2t138U+Zfu0pODe+Z Bxz47MsG9q3V0anl7M5eW6vDd1lM6EDnOlMC2dmpkL0i9jx66qJtvUcqB6Q+mOT6XQn9 FUyg== 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=2njB3YfBIgeTAuj/zGkJbmRMVdz4pRBlWpXs1ktp5Cg=; b=ULbyROw/fC/5TLp+Nvtxzyoq+wTjjh6nYeXGgn+CvFazOhhfLW0ksOZf+y5bUHpL/N fN2DgWBiVPDTLbZPCacXtklhxjn7AnsD537ib3eIfw01Utajb9n5SdP+I9yCkUCNTFo2 MczRirS4ubkytvbqv70lHRVRSTKO4O9S6D8LHsETX1vWU1fyVYW3LM4YVj4xBCdRm7i8 d7YQEsLjm7+J1NgvBhS0X89uXBye2cBBtuaFFRYCZSv/BXbrEEGlB3mUWLh6zrwSdX2l tdww/BXZQ5cCcBShgdenb6m07HZjjBICPvsnSjdcxLfj2VeGKKqRttw+S9RXhPFfY1W0 tETg== X-Gm-Message-State: AA6/9RnRqBBOVrtM+PpKuDBQBXnaSoa+4XzYmhSuAqMO5Y7AcD2ts2Vd9+D+owmQSmRX0JbvEf2O6WunXle7Jg== X-Received: by 10.13.235.16 with SMTP id u16mr5260479ywe.323.1475635025361; Tue, 04 Oct 2016 19:37:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.56.132 with HTTP; Tue, 4 Oct 2016 19:37:04 -0700 (PDT) From: Alia Atlas Date: Tue, 4 Oct 2016 22:37:04 -0400 Message-ID: To: "i2rs@ietf.org" , draft-ietf-i2rs-ephemeral-state@ietf.org Content-Type: multipart/alternative; boundary=94eb2c086dea81419d053e150d25 Archived-At: Subject: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 02:37:11 -0000 --94eb2c086dea81419d053e150d25 Content-Type: text/plain; charset=UTF-8 Hi, As is customary, I have done my AD review of draft-ietf-i2rs-ephemeral-state-18. First, I would like to thank Sue and Jeff for their hard work pulling this document together in an effort to add clarity to the requirements. I do have a number of comments - many relatively minor. Assuming a fast turn-around, as usual from I2RS, we should be able to have this on the Oct 27 telechat - which will mean it needs to enter IETF Last Call before the end of this week. Here is my review: Major: 1) Ephemeral-REQ-12: This specifies that a notification be sent to the original client, regardless of whether it won or lost the priority collision. I had assumed that the notification would go to either the requesting client or the original client depending on which one lost the priority comparison. I have some concerns about an indirect flood of notifications caused by a requesting client that has the lower priority. Regardless, clarifying that the lower-priority client is notified is important. Minor: a) Intro: Remove "3 suggest protocol strawman" as something that the I2RS requirements must do. I know that is how the process has been working out - but it isn't dictated by the technology at all - as the other 2 are. Similarly, replace the following paragraph "The purpose of these requirements and the suggested protocol strawman is to provide a quick turnaround on creating the I2RS protocol." with something like "The purpose of these requirements is to ensure clarity during I2RS protocol creation." b) Section 2: "The following are ten requirements that [RFC7921] contains which provide context for the ephemeral data state requirements given in sections 3-8:" How about "The following are requirements distilled from [RFC7921] that provide context for..." 1) Not relevant for ephemeral - this matters for pub/sub (suggest removal) 2) Relevant for ephemeral b/c of vague performance requirements on possible solutions. 3) What changes if the data model is protocol dependent? Is this just that the model may be an augmentation/extension of an existing module? 4) Absolutely - keep 5) Absolutely - keep 6) Remove - not relevant for ephemeral just security requirements 7) Remove - not relevant for ephemeral just security requirements 8) Absolutely - keep (but says storing secondary identity on deletion when that isn't mentioned for (4) b/c it's about priority - so clarify slightly) 9) Absolutely - keep 10) Remove - not relevant for ephemeral c) Sec 3.3 bullet 2: This refers to YANG data model instead of YANG module as in bullet 1. If there's a reason for the difference, please clarify and otherwise make consistent. d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements. Please consolidate into a section of "The changes to NETCONF and the conceptual changes to RESTCONF are" e) Sec 8: I found this pull-out unclear. "multiple operations in one or more messages; though errors in message or operation will have no effect on other messages or commands even they are related." I think you mean "Multiple operations in one message can be sent. However an error in one operation MUST NOT stop additional operations from being carried out nor can it cause previous operations in the same message to be rolled back." Nits: i) Abstract: "attempting to meet I2RS needs has to provide"/ "attempting to meet the needs of I2RS has to provide" ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" please expand acronyms iii) Sec 5 last sentence: Either missing a ( or has an unneeded ). iv) Ephemeral-REQ-11: "I2RS Protocol I2RS Protocol" repeated --94eb2c086dea81419d053e150d25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As is customary, I have done my AD = review of=C2=A0draft-ietf-i2rs-ephemeral-state-18.=C2=A0 First, I would lik= e to thank Sue and Jeff for their hard work pulling this document together = in an effort to add clarity to the requirements.

I do have a number of comments - many relatively minor.=C2=A0 Assuming a= fast turn-around, as usual from I2RS, we should be able to have this on th= e Oct 27 telechat - which will mean it needs to enter IETF Last Call before= the end of this week.

Here is my review:

Major:

1) Ephemeral-REQ-12: = =C2=A0This specifies that a notification be sent to the
original = client, regardless of whether it won or lost the priority collision.
<= div>I had assumed that the notification would go to either the requesting c= lient
or the original client depending on which one lost the prio= rity comparison.
I have some concerns about an indirect flood of = notifications caused by a
requesting client that has the lower pr= iority.=C2=A0 Regardless, clarifying that
the lower-priority clie= nt is notified is important.



Minor:
a) Intro: Remove "3 suggest protocol strawma= n" as something that
=C2=A0 =C2=A0the I2RS requirements must= do.=C2=A0 I know that is how the process
=C2=A0 =C2=A0has been w= orking out - but it isn't dictated by the technology
=C2=A0 = =C2=A0at all - as the other 2 are.=C2=A0 Similarly, replace the following
=C2=A0 =C2=A0paragraph "The purpose of these requirements and= the suggested
=C2=A0 =C2=A0protocol strawman is to provide a qui= ck turnaround on creating
=C2=A0 =C2=A0the I2RS protocol." w= ith something like "The purpose of these
=C2=A0 =C2=A0requir= ements is to ensure clarity during I2RS protocol creation."
=
b) Section 2: =C2=A0"The following are ten requirements= that [RFC7921]
=C2=A0 =C2=A0contains which provide context for t= he ephemeral data state
=C2=A0 =C2=A0requirements given in sectio= ns 3-8:"
=C2=A0 =C2=A0 =C2=A0 How about "The following = are requirements distilled from [RFC7921]
=C2=A0 =C2=A0 =C2=A0tha= t provide context for..."

=C2=A0 =C2=A0 1) = =C2=A0Not relevant for ephemeral - this matters for pub/sub (suggest remova= l)
=C2=A0 =C2=A0 2) =C2=A0Relevant for ephemeral b/c of vague per= formance requirements on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 possible sol= utions.
=C2=A0 =C2=A0 3) =C2=A0What changes if the data model is = protocol dependent?=C2=A0 Is this just that
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 the model may be an augmentation/extension of an existing module?
=C2=A0 =C2=A0 4) =C2=A0Absolutely - keep
=C2=A0 =C2=A0 5)= =C2=A0Absolutely - keep
=C2=A0 =C2=A0 6) =C2=A0Remove - not rele= vant for ephemeral just security requirements
=C2=A0 =C2=A0 7) = =C2=A0Remove - not relevant for ephemeral just security requirements
<= div>=C2=A0 =C2=A0 8) =C2=A0Absolutely - keep (but says storing secondary id= entity on deletion when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that isn'= t mentioned for (4) b/c it's about priority - so clarify slightly)
=C2=A0 =C2=A0 9) =C2=A0Absolutely - keep
=C2=A0 =C2=A010) = =C2=A0Remove - not relevant for ephemeral

c) Sec 3= .3 bullet 2: =C2=A0This refers to YANG data model instead of YANG module as=
=C2=A0 =C2=A0in bullet 1.=C2=A0 If there's a reason for the = difference, please clarify and otherwise
=C2=A0 =C2=A0make consis= tent.

d) Sec 5 & 6 for NETCONF and RESTCONF ar= e the same requirements.=C2=A0 Please
consolidate into a section = of "The changes to NETCONF and the conceptual changes to RESTCONF are&= quot;

e) Sec 8: =C2=A0I found this pull-out unclea= r. =C2=A0"multiple operations in one
=C2=A0 =C2=A0 =C2=A0 or= more messages; though errors in
=C2=A0 =C2=A0 =C2=A0 message or = operation will have no effect on other messages or
=C2=A0 =C2=A0 = =C2=A0 commands even they are related."

=C2= =A0 =C2=A0 =C2=A0I think you mean "Multiple operations in one message = can be sent.=C2=A0 However
=C2=A0 =C2=A0 =C2=A0an error in one op= eration MUST NOT stop additional operations from being
=C2=A0 =C2= =A0 =C2=A0carried out nor can it cause previous operations in the same mess= age to
=C2=A0 =C2=A0 =C2=A0be rolled back."

Nits:

i) Abstract: "attempting to me= et I2RS needs has to provide"/
"attempting to meet the = needs of I2RS has to provide"

ii) 3.2: "= MPLS LSP-ID or BGP IN-RIB" =C2=A0please expand acronyms

=
iii) Sec 5 last sentence: =C2=A0Either missing a ( or has an unn= eeded ).

iv) Ephemeral-REQ-11: =C2=A0"I2RS Pr= otocol I2RS Protocol" repeated

--94eb2c086dea81419d053e150d25-- From nobody Wed Oct 5 00:25:43 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553D71294B7; Wed, 5 Oct 2016 00:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_HELO_PASS=-0.001, SPF_PASS=-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 Eyvsy1NaJCnh; Wed, 5 Oct 2016 00:25:40 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 B9820127A91; Wed, 5 Oct 2016 00:25:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9D4171C0D02; Wed, 5 Oct 2016 00:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1475652340; bh=u8pTR9SDDn9nka6eMEvUG86jWmvxKLVeWD9zWSvsSH8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Lo95I0pMP2ZPhMHf7pb6a0otdSLGr5V9e3y8DgPNzS+SHizhIC8abMsw0yAWfriAD qPsAiBswq6ABPNtsLoemEx+kTt/nkLmuoQyiNNw7RSFus3SLySKv01Tftyk7jb2/mV 6RCUBdoWThqXQ+Yxwf538FYo1rKA0IHGpdFd/kA4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [88.131.67.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7C2AF1C00A0; Wed, 5 Oct 2016 00:25:39 -0700 (PDT) To: Alia Atlas , "i2rs@ietf.org" , draft-ietf-i2rs-ephemeral-state@ietf.org References: From: "Joel M. Halpern" Message-ID: Date: Wed, 5 Oct 2016 03:25:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.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: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 - REQ-12 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 07:25:42 -0000 We probably should tweak the wording on REQ-12. The notification is only needed when the new operation succeeds. When the new operation fails, the requester will receive an error, and the original state is still there, so no notification is needed. I should have realized that in my earlier review. Suggested fix, add text at left margin: Ephemeral-REQ-12: When a collision occurs as two clients are trying to write the same data node, this collision is considered an error and priorities were created to give a deterministic result. When there is a collision, and the data node is changed, a notification (which includes indicating data node the collision occurred on) MUST BE sent to the original client to give the original client a chance to deal with the issues surrounding the collision. The original client may need to fix their state. Yours, Joel On 10/4/16 10:37 PM, Alia Atlas wrote: > Hi, > > As is customary, I have done my AD review > of draft-ietf-i2rs-ephemeral-state-18. First, I would like to thank Sue > and Jeff for their hard work pulling this document together in an effort > to add clarity to the requirements. > > I do have a number of comments - many relatively minor. Assuming a fast > turn-around, as usual from I2RS, we should be able to have this on the > Oct 27 telechat - which will mean it needs to enter IETF Last Call > before the end of this week. > > Here is my review: > > Major: > > 1) Ephemeral-REQ-12: This specifies that a notification be sent to the > original client, regardless of whether it won or lost the priority > collision. > I had assumed that the notification would go to either the requesting client > or the original client depending on which one lost the priority comparison. > I have some concerns about an indirect flood of notifications caused by a > requesting client that has the lower priority. Regardless, clarifying that > the lower-priority client is notified is important. > > > > Minor: > a) Intro: Remove "3 suggest protocol strawman" as something that > the I2RS requirements must do. I know that is how the process > has been working out - but it isn't dictated by the technology > at all - as the other 2 are. Similarly, replace the following > paragraph "The purpose of these requirements and the suggested > protocol strawman is to provide a quick turnaround on creating > the I2RS protocol." with something like "The purpose of these > requirements is to ensure clarity during I2RS protocol creation." > > b) Section 2: "The following are ten requirements that [RFC7921] > contains which provide context for the ephemeral data state > requirements given in sections 3-8:" > How about "The following are requirements distilled from [RFC7921] > that provide context for..." > > 1) Not relevant for ephemeral - this matters for pub/sub (suggest > removal) > 2) Relevant for ephemeral b/c of vague performance requirements on > possible solutions. > 3) What changes if the data model is protocol dependent? Is this > just that > the model may be an augmentation/extension of an existing module? > 4) Absolutely - keep > 5) Absolutely - keep > 6) Remove - not relevant for ephemeral just security requirements > 7) Remove - not relevant for ephemeral just security requirements > 8) Absolutely - keep (but says storing secondary identity on > deletion when > that isn't mentioned for (4) b/c it's about priority - so > clarify slightly) > 9) Absolutely - keep > 10) Remove - not relevant for ephemeral > > c) Sec 3.3 bullet 2: This refers to YANG data model instead of YANG > module as > in bullet 1. If there's a reason for the difference, please clarify > and otherwise > make consistent. > > d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements. Please > consolidate into a section of "The changes to NETCONF and the conceptual > changes to RESTCONF are" > > e) Sec 8: I found this pull-out unclear. "multiple operations in one > or more messages; though errors in > message or operation will have no effect on other messages or > commands even they are related." > > I think you mean "Multiple operations in one message can be sent. > However > an error in one operation MUST NOT stop additional operations from > being > carried out nor can it cause previous operations in the same message to > be rolled back." > > Nits: > > i) Abstract: "attempting to meet I2RS needs has to provide"/ > "attempting to meet the needs of I2RS has to provide" > > ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" please expand acronyms > > iii) Sec 5 last sentence: Either missing a ( or has an unneeded ). > > iv) Ephemeral-REQ-11: "I2RS Protocol I2RS Protocol" repeated > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Oct 5 05:53:06 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382B1296E8; Wed, 5 Oct 2016 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdGmSsv3ZiQp; Wed, 5 Oct 2016 05:53:02 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 5B6511296D8; Wed, 5 Oct 2016 05:53:02 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t193so78800645ywc.2; Wed, 05 Oct 2016 05:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gfdNVwj59YNeKmNmAWKL3thu9l3SJevybPsCfug6QAM=; b=0jq7Lm6GCo4yQTo/5nHkm4hmfZe/J4+4T0bud3ujWwfpWP9J9Xvf2XC0ylFfco/wn7 0W+0UsNaEax+tx7qvqhug9TTjx4ojVKjbtJKhbRyxEtCHk63erj5nLH1Cy4b2PUoJnFb h7XA6bKJOMjF7u3k00cH274fu7iBWQWU73ZeS4GrQQBCBkqyvv3X+RHd6nGfM37HjgVN uHX5BtCwzbldKk8RlPhsik0NFpL/pEVXLfOvLrfgMc9Kwn9hGC3ALLEf+cvgbz3kuX2+ i67kx5zgrOFfgMk57RmfNSCAX4efQzMSj5EVEWUO71bsFuZsv1EfzMggVE6xEELKvod8 Oo5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gfdNVwj59YNeKmNmAWKL3thu9l3SJevybPsCfug6QAM=; b=QKLNUnaR1G/DQ2GTZn6nIzTHlBgee7rb9dzS+AFzHB8VrqJLB69kEE1z9KYYUbnWRV aMx3a58gHDPTiyKZI/hvTNSSVAu4z128aMO7DI5P343N2rPOSCu4KMH6wk/QvHeN+Tkm d6M5pde8ojwgRwBvt+LcfRZDAWQFZWN1EKas91tDpeLGNrJvCqx+8q2Sk0k4JXTdCeeO E6/fZ5LDufIB3OtVg3Kzyku75kF0CYY0qcqyZinGJw7nDIMz78iPJevyAAydalKzSeZy SF3LjZSCbB+y2lcZ217vYy/9jdDGsf72cgSYgnepHjxwbdvRUJ/fvqD+J92S0B9V0QuU Qp5Q== X-Gm-Message-State: AA6/9RmlbYT69T2wdNq7U9Jct3P1Hy0jSOmDTC877C52d8A307d3m79wayxCjgwO3AMjL9TlF0mvKDH8bvogJg== X-Received: by 10.37.196.197 with SMTP id u188mr6763887ybf.19.1475671981560; Wed, 05 Oct 2016 05:53:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.56.133 with HTTP; Wed, 5 Oct 2016 05:53:00 -0700 (PDT) Received: by 10.129.56.133 with HTTP; Wed, 5 Oct 2016 05:53:00 -0700 (PDT) In-Reply-To: References: From: Alia Atlas Date: Wed, 5 Oct 2016 08:53:00 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=94eb2c054820441953053e1da844 Archived-At: Cc: i2rs@ietf.org, draft-ietf-i2rs-ephemeral-state@ietf.org Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 - REQ-12 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 12:53:05 -0000 --94eb2c054820441953053e1da844 Content-Type: text/plain; charset=UTF-8 LGTM On Oct 5, 2016 3:25 AM, "Joel M. Halpern" wrote: > We probably should tweak the wording on REQ-12. The notification is only > needed when the new operation succeeds. > When the new operation fails, the requester will receive an error, and the > original state is still there, so no notification is needed. I should have > realized that in my earlier review. > > Suggested fix, add text at left margin: > Ephemeral-REQ-12: When a collision occurs as two clients are trying > to write the same data node, this collision is considered an error > and priorities were created to give a deterministic result. When > there is a collision, > and the data node is changed, > a notification (which includes indicating data > node the collision occurred on) MUST BE sent to the original client > to give the original client a chance to deal with the issues > surrounding the collision. The original client may need to fix their > state. > > Yours, > Joel > > On 10/4/16 10:37 PM, Alia Atlas wrote: > >> Hi, >> >> As is customary, I have done my AD review >> of draft-ietf-i2rs-ephemeral-state-18. First, I would like to thank Sue >> and Jeff for their hard work pulling this document together in an effort >> to add clarity to the requirements. >> >> I do have a number of comments - many relatively minor. Assuming a fast >> turn-around, as usual from I2RS, we should be able to have this on the >> Oct 27 telechat - which will mean it needs to enter IETF Last Call >> before the end of this week. >> >> Here is my review: >> >> Major: >> >> 1) Ephemeral-REQ-12: This specifies that a notification be sent to the >> original client, regardless of whether it won or lost the priority >> collision. >> I had assumed that the notification would go to either the requesting >> client >> or the original client depending on which one lost the priority >> comparison. >> I have some concerns about an indirect flood of notifications caused by a >> requesting client that has the lower priority. Regardless, clarifying >> that >> the lower-priority client is notified is important. >> >> >> >> Minor: >> a) Intro: Remove "3 suggest protocol strawman" as something that >> the I2RS requirements must do. I know that is how the process >> has been working out - but it isn't dictated by the technology >> at all - as the other 2 are. Similarly, replace the following >> paragraph "The purpose of these requirements and the suggested >> protocol strawman is to provide a quick turnaround on creating >> the I2RS protocol." with something like "The purpose of these >> requirements is to ensure clarity during I2RS protocol creation." >> >> b) Section 2: "The following are ten requirements that [RFC7921] >> contains which provide context for the ephemeral data state >> requirements given in sections 3-8:" >> How about "The following are requirements distilled from [RFC7921] >> that provide context for..." >> >> 1) Not relevant for ephemeral - this matters for pub/sub (suggest >> removal) >> 2) Relevant for ephemeral b/c of vague performance requirements on >> possible solutions. >> 3) What changes if the data model is protocol dependent? Is this >> just that >> the model may be an augmentation/extension of an existing module? >> 4) Absolutely - keep >> 5) Absolutely - keep >> 6) Remove - not relevant for ephemeral just security requirements >> 7) Remove - not relevant for ephemeral just security requirements >> 8) Absolutely - keep (but says storing secondary identity on >> deletion when >> that isn't mentioned for (4) b/c it's about priority - so >> clarify slightly) >> 9) Absolutely - keep >> 10) Remove - not relevant for ephemeral >> >> c) Sec 3.3 bullet 2: This refers to YANG data model instead of YANG >> module as >> in bullet 1. If there's a reason for the difference, please clarify >> and otherwise >> make consistent. >> >> d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements. Please >> consolidate into a section of "The changes to NETCONF and the conceptual >> changes to RESTCONF are" >> >> e) Sec 8: I found this pull-out unclear. "multiple operations in one >> or more messages; though errors in >> message or operation will have no effect on other messages or >> commands even they are related." >> >> I think you mean "Multiple operations in one message can be sent. >> However >> an error in one operation MUST NOT stop additional operations from >> being >> carried out nor can it cause previous operations in the same message >> to >> be rolled back." >> >> Nits: >> >> i) Abstract: "attempting to meet I2RS needs has to provide"/ >> "attempting to meet the needs of I2RS has to provide" >> >> ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" please expand acronyms >> >> iii) Sec 5 last sentence: Either missing a ( or has an unneeded ). >> >> iv) Ephemeral-REQ-11: "I2RS Protocol I2RS Protocol" repeated >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> --94eb2c054820441953053e1da844 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

LGTM


On Oct 5, 2016 3:= 25 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:
We probably should tweak the wording on REQ-12.=C2=A0 The= notification is only needed when the new operation succeeds.
When the new operation fails, the requester will receive an error, and the = original state is still there, so no notification is needed.=C2=A0 I should= have realized that in my earlier review.

Suggested fix, add text at left margin:
=C2=A0 =C2=A0Ephemeral-REQ-12: When a collision occurs as two clients are t= rying
=C2=A0 =C2=A0to write the same data node, this collision is considered an e= rror
=C2=A0 =C2=A0and priorities were created to give a deterministic result.=C2= =A0 When
=C2=A0 =C2=A0there is a collision,
and the data node is changed,
=C2=A0 =C2=A0 =C2=A0 a notification (which includes indicating data
=C2=A0 =C2=A0node the collision occurred on) MUST BE sent to the original c= lient
=C2=A0 =C2=A0to give the original client a chance to deal with the issues =C2=A0 =C2=A0surrounding the collision.=C2=A0 The original client may need = to fix their
=C2=A0 =C2=A0state.

Yours,
Joel

On 10/4/16 10:37 PM, Alia Atlas wrote:
Hi,

As is customary, I have done my AD review
of draft-ietf-i2rs-ephemeral-state-18.=C2=A0 First, I would like to th= ank Sue
and Jeff for their hard work pulling this document together in an effort to add clarity to the requirements.

I do have a number of comments - many relatively minor.=C2=A0 Assuming a fa= st
turn-around, as usual from I2RS, we should be able to have this on the
Oct 27 telechat - which will mean it needs to enter IETF Last Call
before the end of this week.

Here is my review:

Major:

1) Ephemeral-REQ-12:=C2=A0 This specifies that a notification be sent to th= e
original client, regardless of whether it won or lost the priority
collision.
I had assumed that the notification would go to either the requesting clien= t
or the original client depending on which one lost the priority comparison.=
I have some concerns about an indirect flood of notifications caused by a requesting client that has the lower priority.=C2=A0 Regardless, clarifying= that
the lower-priority client is notified is important.



Minor:
a) Intro: Remove "3 suggest protocol strawman" as something that<= br> =C2=A0 =C2=A0the I2RS requirements must do.=C2=A0 I know that is how the pr= ocess
=C2=A0 =C2=A0has been working out - but it isn't dictated by the techno= logy
=C2=A0 =C2=A0at all - as the other 2 are.=C2=A0 Similarly, replace the foll= owing
=C2=A0 =C2=A0paragraph "The purpose of these requirements and the sugg= ested
=C2=A0 =C2=A0protocol strawman is to provide a quick turnaround on creating=
=C2=A0 =C2=A0the I2RS protocol." with something like "The purpose= of these
=C2=A0 =C2=A0requirements is to ensure clarity during I2RS protocol creatio= n."

b) Section 2:=C2=A0 "The following are ten requirements that [RFC7921]=
=C2=A0 =C2=A0contains which provide context for the ephemeral data state =C2=A0 =C2=A0requirements given in sections 3-8:"
=C2=A0 =C2=A0 =C2=A0 How about "The following are requirements distill= ed from [RFC7921]
=C2=A0 =C2=A0 =C2=A0that provide context for..."

=C2=A0 =C2=A0 1)=C2=A0 Not relevant for ephemeral - this matters for pub/su= b (suggest
removal)
=C2=A0 =C2=A0 2)=C2=A0 Relevant for ephemeral b/c of vague performance requ= irements on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 possible solutions.
=C2=A0 =C2=A0 3)=C2=A0 What changes if the data model is protocol dependent= ?=C2=A0 Is this
just that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the model may be an augmentation/extension of a= n existing module?
=C2=A0 =C2=A0 4)=C2=A0 Absolutely - keep
=C2=A0 =C2=A0 5)=C2=A0 Absolutely - keep
=C2=A0 =C2=A0 6)=C2=A0 Remove - not relevant for ephemeral just security re= quirements
=C2=A0 =C2=A0 7)=C2=A0 Remove - not relevant for ephemeral just security re= quirements
=C2=A0 =C2=A0 8)=C2=A0 Absolutely - keep (but says storing secondary identi= ty on
deletion when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that isn't mentioned for (4) b/c it's a= bout priority - so
clarify slightly)
=C2=A0 =C2=A0 9)=C2=A0 Absolutely - keep
=C2=A0 =C2=A010)=C2=A0 Remove - not relevant for ephemeral

c) Sec 3.3 bullet 2:=C2=A0 This refers to YANG data model instead of YANG module as
=C2=A0 =C2=A0in bullet 1.=C2=A0 If there's a reason for the difference,= please clarify
and otherwise
=C2=A0 =C2=A0make consistent.

d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements.=C2=A0 = Please
consolidate into a section of "The changes to NETCONF and the conceptu= al
changes to RESTCONF are"

e) Sec 8:=C2=A0 I found this pull-out unclear.=C2=A0 "multiple operati= ons in one
=C2=A0 =C2=A0 =C2=A0 or more messages; though errors in
=C2=A0 =C2=A0 =C2=A0 message or operation will have no effect on other mess= ages or
=C2=A0 =C2=A0 =C2=A0 commands even they are related."

=C2=A0 =C2=A0 =C2=A0I think you mean "Multiple operations in one messa= ge can be sent.
However
=C2=A0 =C2=A0 =C2=A0an error in one operation MUST NOT stop additional oper= ations from
being
=C2=A0 =C2=A0 =C2=A0carried out nor can it cause previous operations in the= same message to
=C2=A0 =C2=A0 =C2=A0be rolled back."

Nits:

i) Abstract: "attempting to meet I2RS needs has to provide"/
"attempting to meet the needs of I2RS has to provide"

ii) 3.2: "MPLS LSP-ID or BGP IN-RIB"=C2=A0 please expand acronyms=

iii) Sec 5 last sentence:=C2=A0 Either missing a ( or has an unneeded ).
iv) Ephemeral-REQ-11:=C2=A0 "I2RS Protocol I2RS Protocol" repeate= d



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

--94eb2c054820441953053e1da844-- From nobody Wed Oct 5 06:20:43 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9334E129704; Wed, 5 Oct 2016 06:20:39 -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.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147567363959.21415.11265435272620327387.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2016 06:20:39 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-19.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:20:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-19.txt Pages : 11 Date : 2016-10-05 Abstract: The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-19 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 Oct 5 06:22:06 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9DA129714; Wed, 5 Oct 2016 06:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AERFJKRRDNM; Wed, 5 Oct 2016 06:22:00 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DECC129701; Wed, 5 Oct 2016 06:21:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.177.17; From: "Susan Hares" To: "'Alia Atlas'" , , References: In-Reply-To: Date: Wed, 5 Oct 2016 09:19:57 -0400 Message-ID: <00f101d21f0b$2c1a7b40$844f71c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01D21EE9.A50DBD40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJEWnCRA1gKX3+Ky0Nk/LZ+ROoH95+1VqJg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeff Haas' , 'Joel Halpern' Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:22:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F2_01D21EE9.A50DBD40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alia: =20 I=E2=80=99ve updated version 19 with the changes. The only change I did = not implement was to combine section 5 and 6. The NETCONF group asked = us not to combine these two sections. I left these two sections intact. = Does this work for you? =20 =20 =20 Sue=20 =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Tuesday, October 4, 2016 10:37 PM To: i2rs@ietf.org; draft-ietf-i2rs-ephemeral-state@ietf.org Subject: AD review of draft-ietf-i2rs-ephemeral-state-18 =20 Hi, =20 As is customary, I have done my AD review of = draft-ietf-i2rs-ephemeral-state-18. First, I would like to thank Sue = and Jeff for their hard work pulling this document together in an effort = to add clarity to the requirements. =20 I do have a number of comments - many relatively minor. Assuming a fast = turn-around, as usual from I2RS, we should be able to have this on the = Oct 27 telechat - which will mean it needs to enter IETF Last Call = before the end of this week. =20 Here is my review: =20 Major: =20 1) Ephemeral-REQ-12: This specifies that a notification be sent to the original client, regardless of whether it won or lost the priority = collision. I had assumed that the notification would go to either the requesting = client or the original client depending on which one lost the priority = comparison. I have some concerns about an indirect flood of notifications caused by = a requesting client that has the lower priority. Regardless, clarifying = that the lower-priority client is notified is important. =20 =20 =20 Minor: a) Intro: Remove "3 suggest protocol strawman" as something that the I2RS requirements must do. I know that is how the process has been working out - but it isn't dictated by the technology at all - as the other 2 are. Similarly, replace the following paragraph "The purpose of these requirements and the suggested protocol strawman is to provide a quick turnaround on creating the I2RS protocol." with something like "The purpose of these requirements is to ensure clarity during I2RS protocol creation." =20 b) Section 2: "The following are ten requirements that [RFC7921] contains which provide context for the ephemeral data state requirements given in sections 3-8:" How about "The following are requirements distilled from [RFC7921] that provide context for..." =20 1) Not relevant for ephemeral - this matters for pub/sub (suggest = removal) 2) Relevant for ephemeral b/c of vague performance requirements on possible solutions. 3) What changes if the data model is protocol dependent? Is this = just that the model may be an augmentation/extension of an existing = module? 4) Absolutely - keep 5) Absolutely - keep 6) Remove - not relevant for ephemeral just security requirements 7) Remove - not relevant for ephemeral just security requirements 8) Absolutely - keep (but says storing secondary identity on = deletion when that isn't mentioned for (4) b/c it's about priority - so = clarify slightly) 9) Absolutely - keep 10) Remove - not relevant for ephemeral =20 c) Sec 3.3 bullet 2: This refers to YANG data model instead of YANG = module as in bullet 1. If there's a reason for the difference, please clarify = and otherwise make consistent. =20 d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements. Please consolidate into a section of "The changes to NETCONF and the conceptual = changes to RESTCONF are" =20 e) Sec 8: I found this pull-out unclear. "multiple operations in one or more messages; though errors in message or operation will have no effect on other messages or commands even they are related." =20 I think you mean "Multiple operations in one message can be sent. = However an error in one operation MUST NOT stop additional operations from = being carried out nor can it cause previous operations in the same = message to be rolled back." =20 Nits: =20 i) Abstract: "attempting to meet I2RS needs has to provide"/ "attempting to meet the needs of I2RS has to provide" =20 ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" please expand acronyms =20 iii) Sec 5 last sentence: Either missing a ( or has an unneeded ). =20 iv) Ephemeral-REQ-11: "I2RS Protocol I2RS Protocol" repeated =20 ------=_NextPart_000_00F2_01D21EE9.A50DBD40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Alia:

 

I=E2=80=99ve updated version 19 with the changes. The only change I = did not implement was to combine section 5 and 6.=C2=A0=C2=A0 The = NETCONF group asked us not to combine these two sections. =C2=A0I left = these two sections intact. =C2=A0=C2=A0Does this work for you? = =C2=A0

 

 

Sue

 

From:= = Alia Atlas [mailto:akatlas@gmail.com]
Sent: Tuesday, October = 4, 2016 10:37 PM
To: i2rs@ietf.org; = draft-ietf-i2rs-ephemeral-state@ietf.org
Subject: AD review of = draft-ietf-i2rs-ephemeral-state-18

 

Hi,

 

As is customary, I have done my AD review = of draft-ietf-i2rs-ephemeral-state-18.  First, I would like to = thank Sue and Jeff for their hard work pulling this document together in = an effort to add clarity to the = requirements.

 

I = do have a number of comments - many relatively minor.  Assuming a = fast turn-around, as usual from I2RS, we should be able to have this on = the Oct 27 telechat - which will mean it needs to enter IETF Last Call = before the end of this week.

 

Here is my review:

 

Major:

 

1) Ephemeral-REQ-12:  This specifies that a = notification be sent to the

original client, regardless of whether it won or lost = the priority collision.

I = had assumed that the notification would go to either the requesting = client

or the original = client depending on which one lost the priority = comparison.

I have some = concerns about an indirect flood of notifications caused by = a

requesting client that = has the lower priority.  Regardless, clarifying = that

the lower-priority = client is notified is important.

 

 

 

Minor:

a) Intro: Remove "3 suggest protocol = strawman" as something that

   the I2RS requirements must do.  I = know that is how the process

   has been working out - but it isn't = dictated by the technology

   at all - as the other 2 are.  = Similarly, replace the following

   paragraph "The purpose of these = requirements and the suggested

   protocol strawman is to provide a quick = turnaround on creating

   the I2RS protocol." with something = like "The purpose of these

   requirements is to ensure clarity during = I2RS protocol creation."

 

b) Section 2:  "The following are ten = requirements that [RFC7921]

   contains which provide context for the = ephemeral data state

   requirements given in sections = 3-8:"

    =   How about "The following are requirements distilled from = [RFC7921]

    =  that provide context for..."

 

    1)  Not relevant for ephemeral - = this matters for pub/sub (suggest removal)

    2)  Relevant for ephemeral b/c of = vague performance requirements on

        possible = solutions.

    = 3)  What changes if the data model is protocol dependent?  Is = this just that

  =       the model may be an augmentation/extension of an = existing module?

  =   4)  Absolutely - keep

    5)  Absolutely - = keep

    6) =  Remove - not relevant for ephemeral just security = requirements

    = 7)  Remove - not relevant for ephemeral just security = requirements

    = 8)  Absolutely - keep (but says storing secondary identity on = deletion when

  =       that isn't mentioned for (4) b/c it's about = priority - so clarify slightly)

    9)  Absolutely - = keep

   10) =  Remove - not relevant for ephemeral

 

c) Sec 3.3 bullet 2:  This refers to YANG data = model instead of YANG module as

   in bullet 1.  If there's a reason = for the difference, please clarify and = otherwise

  =  make consistent.

 

d) Sec 5 & 6 for NETCONF and RESTCONF are the same = requirements.  Please

consolidate into a section of "The changes to = NETCONF and the conceptual changes to RESTCONF = are"

 

e) Sec 8:  I found this pull-out unclear. =  "multiple operations in one

      or more messages; though errors = in

      = message or operation will have no effect on other messages = or

      = commands even they are related."

 

     I think you mean "Multiple = operations in one message can be sent.  = However

    =  an error in one operation MUST NOT stop additional operations from = being

    =  carried out nor can it cause previous operations in the same = message to

    =  be rolled back."

 

Nits:

 

i) Abstract: "attempting to meet I2RS needs has = to provide"/

"attempting to meet the needs of I2RS has to = provide"

 

ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" =  please expand acronyms

 

iii) Sec 5 last sentence:  Either missing a ( or = has an unneeded ).

 

iv) Ephemeral-REQ-11:  "I2RS Protocol I2RS = Protocol" repeated

 

------=_NextPart_000_00F2_01D21EE9.A50DBD40-- From nobody Wed Oct 5 06:31:50 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D721129700; Wed, 5 Oct 2016 06:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ML0h6XPw7r7; Wed, 5 Oct 2016 06:31:47 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083A81296FC; Wed, 5 Oct 2016 06:31:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.177.17; From: "Susan Hares" To: "'Joel M. Halpern'" , "'Alia Atlas'" , , References: In-Reply-To: Date: Wed, 5 Oct 2016 09:30:13 -0400 Message-ID: <00fe01d21f0c$9aab1e60$d0015b20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJEWnCRA1gKX3+Ky0Nk/LZ+ROoH9wHOfzdhn6bwRsA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 - REQ-12 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:31:48 -0000 Joel: WFM - see inclusion in version 19. Sue -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, October 5, 2016 3:26 AM To: Alia Atlas; i2rs@ietf.org; draft-ietf-i2rs-ephemeral-state@ietf.org Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 - REQ-12 We probably should tweak the wording on REQ-12. The notification is only needed when the new operation succeeds. When the new operation fails, the requester will receive an error, and the original state is still there, so no notification is needed. I should have realized that in my earlier review. Suggested fix, add text at left margin: Ephemeral-REQ-12: When a collision occurs as two clients are trying to write the same data node, this collision is considered an error and priorities were created to give a deterministic result. When there is a collision, and the data node is changed, a notification (which includes indicating data node the collision occurred on) MUST BE sent to the original client to give the original client a chance to deal with the issues surrounding the collision. The original client may need to fix their state. Yours, Joel On 10/4/16 10:37 PM, Alia Atlas wrote: > Hi, > > As is customary, I have done my AD review of > draft-ietf-i2rs-ephemeral-state-18. First, I would like to thank Sue > and Jeff for their hard work pulling this document together in an > effort to add clarity to the requirements. > > I do have a number of comments - many relatively minor. Assuming a > fast turn-around, as usual from I2RS, we should be able to have this > on the Oct 27 telechat - which will mean it needs to enter IETF Last > Call before the end of this week. > > Here is my review: > > Major: > > 1) Ephemeral-REQ-12: This specifies that a notification be sent to > the original client, regardless of whether it won or lost the priority > collision. > I had assumed that the notification would go to either the requesting > client or the original client depending on which one lost the priority comparison. > I have some concerns about an indirect flood of notifications caused > by a requesting client that has the lower priority. Regardless, > clarifying that the lower-priority client is notified is important. > > > > Minor: > a) Intro: Remove "3 suggest protocol strawman" as something that > the I2RS requirements must do. I know that is how the process > has been working out - but it isn't dictated by the technology > at all - as the other 2 are. Similarly, replace the following > paragraph "The purpose of these requirements and the suggested > protocol strawman is to provide a quick turnaround on creating > the I2RS protocol." with something like "The purpose of these > requirements is to ensure clarity during I2RS protocol creation." > > b) Section 2: "The following are ten requirements that [RFC7921] > contains which provide context for the ephemeral data state > requirements given in sections 3-8:" > How about "The following are requirements distilled from [RFC7921] > that provide context for..." > > 1) Not relevant for ephemeral - this matters for pub/sub (suggest > removal) > 2) Relevant for ephemeral b/c of vague performance requirements on > possible solutions. > 3) What changes if the data model is protocol dependent? Is this > just that > the model may be an augmentation/extension of an existing module? > 4) Absolutely - keep > 5) Absolutely - keep > 6) Remove - not relevant for ephemeral just security requirements > 7) Remove - not relevant for ephemeral just security requirements > 8) Absolutely - keep (but says storing secondary identity on > deletion when > that isn't mentioned for (4) b/c it's about priority - so > clarify slightly) > 9) Absolutely - keep > 10) Remove - not relevant for ephemeral > > c) Sec 3.3 bullet 2: This refers to YANG data model instead of YANG > module as > in bullet 1. If there's a reason for the difference, please > clarify and otherwise > make consistent. > > d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements. > Please consolidate into a section of "The changes to NETCONF and the > conceptual changes to RESTCONF are" > > e) Sec 8: I found this pull-out unclear. "multiple operations in one > or more messages; though errors in > message or operation will have no effect on other messages or > commands even they are related." > > I think you mean "Multiple operations in one message can be sent. > However > an error in one operation MUST NOT stop additional operations > from being > carried out nor can it cause previous operations in the same message to > be rolled back." > > Nits: > > i) Abstract: "attempting to meet I2RS needs has to provide"/ > "attempting to meet the needs of I2RS has to provide" > > ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" please expand acronyms > > iii) Sec 5 last sentence: Either missing a ( or has an unneeded ). > > iv) Ephemeral-REQ-11: "I2RS Protocol I2RS Protocol" repeated > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Oct 5 07:14:13 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB165129743; Wed, 5 Oct 2016 07:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MABvw4VFo5w5; Wed, 5 Oct 2016 07:14:08 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 3C6B5129741; Wed, 5 Oct 2016 07:14:08 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id t193so81300055ywc.2; Wed, 05 Oct 2016 07:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jT29/xOhr7Rw1Ww6S7WXTu6wzz2X6MgRnYseEor1BnI=; b=vuCBMGq8MQ1s2svulW2tOlvCmTOzHfa2TOafOVj6G2bIPo/2FhS+hLvUhER3jmYQvS 6Aoq4B5b/CPrJd6WMyE1fi9BZsG34aUEkEC0osrPYZlDXDp3QF8ju+8rZC7Y2l28K3jQ tqWXeT4MTQrriK3U/1PH6PrsDil6Wi0l/nHTw1V1OYLFFrm2WwWyXopzZRBmy9ZAXaq2 Eu5ovJh2hEeLq/xJpr7RULr55BLk7418XmsEg0tkAZ0OVriNMqgPjD4/bwEYwkESrVQd zLnBqxXw1lqza92PZgGen1xo19jA9Rpk/x7SjG8lx1r0R0V9D1U3wvdWAQYpsRUzHfcy QjeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jT29/xOhr7Rw1Ww6S7WXTu6wzz2X6MgRnYseEor1BnI=; b=muk2YLJYcALdd24A6k5AWCLFpBIT4+1UkEvwZaDZEY752LeJE+NmyvnV7+njCB4Pxs pOI4AO5Ed/Ps3l7J9XQEZFNTJyQ8ATKSpv8R4340exGPNA63BqzkHNHn4UmOf/pASNkU 2k2iij+hgwfXtM0VsFX9OWc6BHQCYl4Kz7ZdgArjxE2STetia/G6J1Tmx4vt92V5QZCs ZrJrgZoh0JSpmPIbQw0Zk+Fd+nPnFfXaLMicm5HxbJFj5OJXXtexlvYTBox5JF26WUpD Lb0TiBOSowQPi3fv1yLVGJiRV7LiVhQmvIXVjAE+fsf6AWLIEKUjDQAGJeoDOStO3hcW bUlw== X-Gm-Message-State: AA6/9RnLKl1ScxHMIB+wTzVXiEGb/R3cO2GdZnMrOkMpj3h0K/S+STDRBZ48qt8pyDFGIOJJSIQ2wTSPms+Exg== X-Received: by 10.129.113.67 with SMTP id m64mr2662336ywc.227.1475676847281; Wed, 05 Oct 2016 07:14:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.56.133 with HTTP; Wed, 5 Oct 2016 07:14:06 -0700 (PDT) In-Reply-To: <00f101d21f0b$2c1a7b40$844f71c0$@ndzh.com> References: <00f101d21f0b$2c1a7b40$844f71c0$@ndzh.com> From: Alia Atlas Date: Wed, 5 Oct 2016 10:14:06 -0400 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a1141c1424935bd053e1ecafb Archived-At: Cc: Jeff Haas , "i2rs@ietf.org" , Joel Halpern , draft-ietf-i2rs-ephemeral-state@ietf.org Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 14:14:12 -0000 --001a1141c1424935bd053e1ecafb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sue, This looks good - thanks. I will put it into IETF Last Call. Regards, Alia On Wed, Oct 5, 2016 at 9:19 AM, Susan Hares wrote: > Alia: > > > > I=E2=80=99ve updated version 19 with the changes. The only change I did n= ot > implement was to combine section 5 and 6. The NETCONF group asked us no= t > to combine these two sections. I left these two sections intact. Does > this work for you? > > > > > > Sue > > > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* Tuesday, October 4, 2016 10:37 PM > *To:* i2rs@ietf.org; draft-ietf-i2rs-ephemeral-state@ietf.org > *Subject:* AD review of draft-ietf-i2rs-ephemeral-state-18 > > > > Hi, > > > > As is customary, I have done my AD review of draft-ietf-i2rs-ephemeral-st= ate-18. > First, I would like to thank Sue and Jeff for their hard work pulling thi= s > document together in an effort to add clarity to the requirements. > > > > I do have a number of comments - many relatively minor. Assuming a fast > turn-around, as usual from I2RS, we should be able to have this on the Oc= t > 27 telechat - which will mean it needs to enter IETF Last Call before the > end of this week. > > > > Here is my review: > > > > Major: > > > > 1) Ephemeral-REQ-12: This specifies that a notification be sent to the > > original client, regardless of whether it won or lost the priority > collision. > > I had assumed that the notification would go to either the requesting > client > > or the original client depending on which one lost the priority compariso= n. > > I have some concerns about an indirect flood of notifications caused by a > > requesting client that has the lower priority. Regardless, clarifying th= at > > the lower-priority client is notified is important. > > > > > > > > Minor: > > a) Intro: Remove "3 suggest protocol strawman" as something that > > the I2RS requirements must do. I know that is how the process > > has been working out - but it isn't dictated by the technology > > at all - as the other 2 are. Similarly, replace the following > > paragraph "The purpose of these requirements and the suggested > > protocol strawman is to provide a quick turnaround on creating > > the I2RS protocol." with something like "The purpose of these > > requirements is to ensure clarity during I2RS protocol creation." > > > > b) Section 2: "The following are ten requirements that [RFC7921] > > contains which provide context for the ephemeral data state > > requirements given in sections 3-8:" > > How about "The following are requirements distilled from [RFC7921] > > that provide context for..." > > > > 1) Not relevant for ephemeral - this matters for pub/sub (suggest > removal) > > 2) Relevant for ephemeral b/c of vague performance requirements on > > possible solutions. > > 3) What changes if the data model is protocol dependent? Is this > just that > > the model may be an augmentation/extension of an existing module? > > 4) Absolutely - keep > > 5) Absolutely - keep > > 6) Remove - not relevant for ephemeral just security requirements > > 7) Remove - not relevant for ephemeral just security requirements > > 8) Absolutely - keep (but says storing secondary identity on deletio= n > when > > that isn't mentioned for (4) b/c it's about priority - so clarify > slightly) > > 9) Absolutely - keep > > 10) Remove - not relevant for ephemeral > > > > c) Sec 3.3 bullet 2: This refers to YANG data model instead of YANG > module as > > in bullet 1. If there's a reason for the difference, please clarify > and otherwise > > make consistent. > > > > d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements. Please > > consolidate into a section of "The changes to NETCONF and the conceptual > changes to RESTCONF are" > > > > e) Sec 8: I found this pull-out unclear. "multiple operations in one > > or more messages; though errors in > > message or operation will have no effect on other messages or > > commands even they are related." > > > > I think you mean "Multiple operations in one message can be sent. > However > > an error in one operation MUST NOT stop additional operations from > being > > carried out nor can it cause previous operations in the same message > to > > be rolled back." > > > > Nits: > > > > i) Abstract: "attempting to meet I2RS needs has to provide"/ > > "attempting to meet the needs of I2RS has to provide" > > > > ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" please expand acronyms > > > > iii) Sec 5 last sentence: Either missing a ( or has an unneeded ). > > > > iv) Ephemeral-REQ-11: "I2RS Protocol I2RS Protocol" repeated > > > --001a1141c1424935bd053e1ecafb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sue,

This looks good - thanks.=C2=A0 I = will put it into IETF Last Call.

Regards,
Alia

On Wed, Oct 5, 2016 at 9:19 AM, Susan Hares <shares@ndzh.com> wrote:

Alia:

<= p class=3D"MsoNormal">=C2=A0

I=E2=80=99ve updated= version 19 with the changes. The only change I did not implement was to co= mbine section 5 and 6.=C2=A0=C2=A0 The NETCONF group asked us not to combin= e these two sections.=C2=A0 I left these two sections intact. =C2=A0=C2=A0D= oes this work for you? =C2=A0

=C2=A0

=C2=A0

Sue

=C2=A0

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: Tu= esday, October 4, 2016 10:37 PM
To: i2rs@ietf.org; draft-ietf-i2rs-ephemeral-= state@ietf.org
Subject: AD review of draft-ietf-i2rs-ephemera= l-state-18

=C2=A0

Hi,

=C2=A0

As is customary, I have done my AD review of=C2=A0draft= -ietf-i2rs-ephemeral-state-18.=C2=A0 First, I would like to thank Sue = and Jeff for their hard work pulling this document together in an effort to= add clarity to the requirements.

=C2=A0

I do ha= ve a number of comments - many relatively minor.=C2=A0 Assuming a fast turn= -around, as usual from I2RS, we should be able to have this on the Oct 27 t= elechat - which will mean it needs to enter IETF Last Call before the end o= f this week.

=C2= =A0

Here is my review:

=C2=A0

Major:

=C2=A0

1)= Ephemeral-REQ-12: =C2=A0This specifies that a notification be sent to the<= u>

original client, regardl= ess of whether it won or lost the priority collision.

I had assumed that the notification would go = to either the requesting client

or the original client depending on which one lost the priority com= parison.

I have some con= cerns about an indirect flood of notifications caused by a

requesting client that has the lower pri= ority.=C2=A0 Regardless, clarifying that

the lower-priority client is notified is important.=

=C2=A0

=

=C2=A0

=C2=A0

Minor:=

a) Intro: Remove "= 3 suggest protocol strawman" as something that

=

=C2=A0 =C2=A0the I2RS requirements must do.=C2= =A0 I know that is how the process

=C2=A0 =C2=A0has been working out - but it isn't dictated by= the technology

=C2=A0 = =C2=A0at all - as the other 2 are.=C2=A0 Similarly, replace the following

=C2=A0 =C2=A0paragraph &q= uot;The purpose of these requirements and the suggested

=C2=A0 =C2=A0protocol strawman is to provid= e a quick turnaround on creating

=C2=A0 =C2=A0the I2RS protocol." with something like "Th= e purpose of these

=C2= =A0 =C2=A0requirements is to ensure clarity during I2RS protocol creation.&= quot;

=C2=A0

b) Section 2: =C2=A0"The follo= wing are ten requirements that [RFC7921]

=C2=A0 =C2=A0contains which provide context for the epheme= ral data state

=C2=A0 = =C2=A0requirements given in sections 3-8:"

=C2=A0 =C2=A0 =C2=A0 How about "The following = are requirements distilled from [RFC7921]

=C2=A0 =C2=A0 =C2=A0that provide context for..."<= /u>

=C2=A0

=C2=A0 =C2=A0 1) =C2=A0Not relevant for ephe= meral - this matters for pub/sub (suggest removal)

<= div>

=C2=A0 =C2=A0 2) =C2=A0Relevant for ephemeral b/= c of vague performance requirements on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 possible solutions.

=C2=A0 =C2=A0 3) =C2=A0What changes = if the data model is protocol dependent?=C2=A0 Is this just that<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the mo= del may be an augmentation/extension of an existing module?

=C2=A0 =C2=A0 4) =C2=A0Absolutely - kee= p

=C2=A0 =C2=A0 5) =C2= =A0Absolutely - keep

=C2= =A0 =C2=A0 6) =C2=A0Remove - not relevant for ephemeral just security requi= rements

=C2=A0 =C2=A0 7)= =C2=A0Remove - not relevant for ephemeral just security requirements

=C2=A0 =C2=A0 8) =C2=A0Absolu= tely - keep (but says storing secondary identity on deletion when=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 that = isn't mentioned for (4) b/c it's about priority - so clarify slight= ly)

=C2=A0 =C2=A0 9) =C2= =A0Absolutely - keep

=C2= =A0 =C2=A010) =C2=A0Remove - not relevant for ephemeral

=C2=A0

c) Sec 3.3 bullet 2: =C2=A0This refers to YANG data model in= stead of YANG module as

= =C2=A0 =C2=A0in bullet 1.=C2=A0 If there's a reason for the difference,= please clarify and otherwise

=C2=A0 =C2=A0make consistent.

=C2=A0

d) Se= c 5 & 6 for NETCONF and RESTCONF are the same requirements.=C2=A0 Pleas= e

consolidate into a sec= tion of "The changes to NETCONF and the conceptual changes to RESTCONF= are"

=C2=A0=

e) Sec 8: =C2=A0I found this p= ull-out unclear. =C2=A0"multiple operations in one

=C2=A0 =C2=A0 =C2=A0 or more messages; thou= gh errors in

=C2=A0 =C2= =A0 =C2=A0 message or operation will have no effect on other messages or=

=C2=A0 =C2=A0 =C2=A0 comma= nds even they are related."

=C2=A0

=C2=A0 = =C2=A0 =C2=A0I think you mean "Multiple operations in one message can = be sent.=C2=A0 However

= =C2=A0 =C2=A0 =C2=A0an error in one operation MUST NOT stop additional oper= ations from being

=C2=A0= =C2=A0 =C2=A0carried out nor can it cause previous operations in the same = message to

=C2=A0 =C2=A0= =C2=A0be rolled back."

=C2=A0

Nits:=

=C2=A0

=

i) Abstract: "attempting to meet I2RS need= s has to provide"/

= "attempting to meet the needs of I2RS has to provide"

=C2=A0

=

ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" =C2= =A0please expand acronyms

=C2=A0

iii) Sec 5 last= sentence: =C2=A0Either missing a ( or has an unneeded ).

=

=C2=A0

iv) Ephemeral-REQ-11: =C2=A0"I2RS Protocol I2RS Proto= col" repeated

=C2=A0

<= /div>
--001a1141c1424935bd053e1ecafb-- From nobody Wed Oct 5 07:51:52 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E2712977C; Wed, 5 Oct 2016 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.517 X-Spam-Level: X-Spam-Status: No, score=-17.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=-2.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 6-hJoWDCmoOg; Wed, 5 Oct 2016 07:51:48 -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 F321F129633; Wed, 5 Oct 2016 07:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5943; q=dns/txt; s=iport; t=1475679105; x=1476888705; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tXUh8yRmg01qwEzpcJQDoFhunt3BK9BP1jYkIRb5LYM=; b=lTcZGM5pTrDZAgm/eXN33g70tVg6axrXbmbD5uwR+kYCAjIYwKY0uahX zsZxSu9tYU4CnlSqL3BrBHVmRlj6MyqzYFelh3UiKo72X/m5l8W8M88Zo Uj741/O8ijNbP+LamtSoshXIAJduVMAAEUa5NtW4qxL7hsA/aexqmdbQA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAgCAEvVX/5JdJa1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9AQEBAQEeVypSjTKWfpQqggkbC4V6AoFxOBQBAgEBAQEBAQF?= =?us-ascii?q?eJ4RhAQEBAwEBAQE1LwcXBAsOAwQBAQEnBycfCQgGAQwGAgEBFwSIJwgOuR8BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARkFhjyBfQiCUIQXCYYFAQSTeIYCj3cCgWyEZoM?= =?us-ascii?q?UhguMc4N+HjZLhHUiNIYHgi8BAQE?= X-IronPort-AV: E=Sophos;i="5.31,449,1473120000"; d="scan'208";a="330201569" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2016 14:51:44 +0000 Received: from [10.150.55.100] (dhcp-10-150-55-100.cisco.com [10.150.55.100]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u95EpiiN024761; Wed, 5 Oct 2016 14:51:44 GMT To: Susan Hares , "'Joel M. Halpern'" , "'Alia Atlas'" , i2rs@ietf.org, draft-ietf-i2rs-ephemeral-state@ietf.org References: <00fe01d21f0c$9aab1e60$d0015b20$@ndzh.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <41914992-d094-d6c5-b3e4-a7960cae29bb@cisco.com> Date: Wed, 5 Oct 2016 10:51:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <00fe01d21f0c$9aab1e60$d0015b20$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 - REQ-12 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 14:51:51 -0000 On 10/5/16 09:30, Susan Hares wrote: > Joel: > > WFM - see inclusion in version 19. Agreed. And I agree with Alia's comment. The overwriting client should just succeed. Why let them know (again) that it worked via a notification. Joe > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, October 5, 2016 3:26 AM > To: Alia Atlas; i2rs@ietf.org; draft-ietf-i2rs-ephemeral-state@ietf.org > Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18 - REQ-12 > > We probably should tweak the wording on REQ-12. The notification is only > needed when the new operation succeeds. > When the new operation fails, the requester will receive an error, and the > original state is still there, so no notification is needed. I should have > realized that in my earlier review. > > Suggested fix, add text at left margin: > Ephemeral-REQ-12: When a collision occurs as two clients are trying > to write the same data node, this collision is considered an error > and priorities were created to give a deterministic result. When > there is a collision, > and the data node is changed, > a notification (which includes indicating data > node the collision occurred on) MUST BE sent to the original client > to give the original client a chance to deal with the issues > surrounding the collision. The original client may need to fix their > state. > > Yours, > Joel > > On 10/4/16 10:37 PM, Alia Atlas wrote: >> Hi, >> >> As is customary, I have done my AD review of >> draft-ietf-i2rs-ephemeral-state-18. First, I would like to thank Sue >> and Jeff for their hard work pulling this document together in an >> effort to add clarity to the requirements. >> >> I do have a number of comments - many relatively minor. Assuming a >> fast turn-around, as usual from I2RS, we should be able to have this >> on the Oct 27 telechat - which will mean it needs to enter IETF Last >> Call before the end of this week. >> >> Here is my review: >> >> Major: >> >> 1) Ephemeral-REQ-12: This specifies that a notification be sent to >> the original client, regardless of whether it won or lost the priority >> collision. >> I had assumed that the notification would go to either the requesting >> client or the original client depending on which one lost the priority > comparison. >> I have some concerns about an indirect flood of notifications caused >> by a requesting client that has the lower priority. Regardless, >> clarifying that the lower-priority client is notified is important. >> >> >> >> Minor: >> a) Intro: Remove "3 suggest protocol strawman" as something that >> the I2RS requirements must do. I know that is how the process >> has been working out - but it isn't dictated by the technology >> at all - as the other 2 are. Similarly, replace the following >> paragraph "The purpose of these requirements and the suggested >> protocol strawman is to provide a quick turnaround on creating >> the I2RS protocol." with something like "The purpose of these >> requirements is to ensure clarity during I2RS protocol creation." >> >> b) Section 2: "The following are ten requirements that [RFC7921] >> contains which provide context for the ephemeral data state >> requirements given in sections 3-8:" >> How about "The following are requirements distilled from [RFC7921] >> that provide context for..." >> >> 1) Not relevant for ephemeral - this matters for pub/sub (suggest >> removal) >> 2) Relevant for ephemeral b/c of vague performance requirements on >> possible solutions. >> 3) What changes if the data model is protocol dependent? Is this >> just that >> the model may be an augmentation/extension of an existing module? >> 4) Absolutely - keep >> 5) Absolutely - keep >> 6) Remove - not relevant for ephemeral just security requirements >> 7) Remove - not relevant for ephemeral just security requirements >> 8) Absolutely - keep (but says storing secondary identity on >> deletion when >> that isn't mentioned for (4) b/c it's about priority - so >> clarify slightly) >> 9) Absolutely - keep >> 10) Remove - not relevant for ephemeral >> >> c) Sec 3.3 bullet 2: This refers to YANG data model instead of YANG >> module as >> in bullet 1. If there's a reason for the difference, please >> clarify and otherwise >> make consistent. >> >> d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements. >> Please consolidate into a section of "The changes to NETCONF and the >> conceptual changes to RESTCONF are" >> >> e) Sec 8: I found this pull-out unclear. "multiple operations in one >> or more messages; though errors in >> message or operation will have no effect on other messages or >> commands even they are related." >> >> I think you mean "Multiple operations in one message can be sent. >> However >> an error in one operation MUST NOT stop additional operations >> from being >> carried out nor can it cause previous operations in the same message > to >> be rolled back." >> >> Nits: >> >> i) Abstract: "attempting to meet I2RS needs has to provide"/ >> "attempting to meet the needs of I2RS has to provide" >> >> ii) 3.2: "MPLS LSP-ID or BGP IN-RIB" please expand acronyms >> >> iii) Sec 5 last sentence: Either missing a ( or has an unneeded ). >> >> iv) Ephemeral-REQ-11: "I2RS Protocol I2RS Protocol" repeated >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Oct 5 08:28:28 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A9512978B; Wed, 5 Oct 2016 08:28:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147568130311.21423.7592782916823055435.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2016 08:28:23 -0700 Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org, akatlas@gmail.com Subject: [i2rs] Last Call: (I2RS Ephemeral State Requirements) to Informational RFC X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 15:28:23 -0000 The IESG has received a request from the Interface to the Routing System WG (i2rs) to consider the following document: - 'I2RS Ephemeral State Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-10-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Oct 5 13:48:21 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0912946D; Wed, 5 Oct 2016 13:48:19 -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.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147570049988.28207.14386322453500155045.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2016 13:48:19 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-pkt-eca-data-model-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 20:48:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : Filter-Based Packet Forwarding ECA Policy Authors : Susan Hares Qin Wu Russ White Filename : draft-ietf-i2rs-pkt-eca-data-model-02.txt Pages : 55 Date : 2016-10-05 Abstract: This document describes the yang data model for packet forwarding policy that filters received packets and forwards (or drops) the packets. Prior to forwarding the packets out other interfaces, some of the fields in the packets may be modified. If one considers the packet reception an event, this packet policy is a minimalistic Event-Match Condition-Action policy. This policy controls forwarding of packets received by a routing device on one or more interfaces on which this policy is enabled. The policy is composed of an ordered list of policy rules. Each policy policy rule contains a set of match conditions that filters for packets plus a set of actions to modify the packet and forward packets. The match conditions can match tuples in multiple layers (L1-L4, application), interface received on, and and other conditions regarding the packet (size of packet, time of day). The modify packet actions allow for setting things within the packet plus decapsulation and encapsulation packet. The forwarding actions include forwarding via interfaces, tunnels, or nexthops and dropping the packet. The policy model can be used with the session ephemeral (BGP Flow Specifications), reboot ephemeral state (I2RS ephemeral), and non-ephemeral routing/forwarding state (e.g. configuration state ). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-pkt-eca-data-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-pkt-eca-data-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-pkt-eca-data-model-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 Thu Oct 6 02:40:51 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC245129941; Thu, 6 Oct 2016 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.411 X-Spam-Level: X-Spam-Status: No, score=-16.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, 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 odpNy3MPL5zS; Thu, 6 Oct 2016 02:40:45 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F031295C6; Thu, 6 Oct 2016 02:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1475746845; x=1476956445; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=8j2F1lJbuRYZlYWgWiLtJ9ISpjx/bYI1G2JWVVX8lyc=; b=HGI7gkSVLZGFXwVkAs+1E3DAhLFSIR2Mk1SLV2q+q5jgla8/P86PUn0S hLTUjsebdazin/5nE2jgSa6C0J4hhweKlCXwnd+JMKCctDoukHNzp27t6 q2b1KgkTnjg1E9xd9o/RfcD41984CfnxToMeULiKJgfh9bY01w+82aHFX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AwBQG/ZX/xbLJq1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBgz0BAQEBAXUqUo0yqRyCD4ILJoV6EYIgFAECAQEBAQEBAV4nhQsVQTUCJgJ?= =?us-ascii?q?sCAEBiEoOsSSNIYEHhTWBfYdrgjiCWwEEgUqYNYYoiVOBWAFjhy2GC4knh08eN?= =?us-ascii?q?holBQeEXDw0AYg/AQEB?= X-IronPort-AV: E=Sophos;i="5.31,453,1473120000"; d="scan'208";a="647198908" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2016 09:40:40 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u969eewo006007; Thu, 6 Oct 2016 09:40:40 GMT To: draft-ietf-i2rs-pkt-eca-data-model@ietf.org From: Benoit Claise Message-ID: Date: Thu, 6 Oct 2016 11:40:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: [i2rs] draft-ietf-i2rs-pkt-eca-data-model: YANG compilation issue. X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 09:40:50 -0000 Hi, See http://www.claise.be/IETFYANGPageCompilation.html And don't forget that the yangvalidator.org can help you. Regards, Benoit From nobody Fri Oct 7 10:06:46 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F511129663 for ; Fri, 7 Oct 2016 10:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 h5dqvnSf6E5H for ; Fri, 7 Oct 2016 10:06:42 -0700 (PDT) Received: from nm26-vm3.bullet.mail.gq1.yahoo.com (nm26-vm3.bullet.mail.gq1.yahoo.com [98.136.216.130]) (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 926521295EF for ; Fri, 7 Oct 2016 10:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475860002; bh=oUZauuO4E1g6mHv27/SnwrQLEk52d7r+FtXjaNXbONY=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=lvcV4toxyYUIc5LWyfI7mCcYuMM8kOx7K2UW5de0hayrolwDXwWjbfziZ0GeiHfN9KQ88EAeI4+ohBv6IWPtMc8D1hicXFBnjm87SOt2cj+6fcciizLRbWbYQ95xTW3jG80ZD7NGm6KvdwyOd4t4xDxC0SQWWp4k9L6TERK4xQhs4vTufB0sIlXiP5Lui/nihacpKgYyV8+JUd/77Rx0NuvFWjmwuTE/iuSnFc4yuj1iKBDgPxZc/+CaBpWZu78doXMCUbevyOrCWpLlWMc2H2S2+nVgKHBI3Kt41EBzq6F7QbLTDr7II0B++HoHq1BUFuy1Uk565VcnnWeXAWzBug== Received: from [98.137.12.175] by nm26.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2016 17:06:42 -0000 Received: from [208.71.42.212] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 07 Oct 2016 17:06:42 -0000 Received: from [127.0.0.1] by smtp223.mail.gq1.yahoo.com with NNFMP; 07 Oct 2016 17:06:42 -0000 X-Yahoo-Newman-Id: 264816.85285.bm@smtp223.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: a9mo79QVM1ntQsRRstJYA1XLcaTEnH4FHd5BHdJzUQxM4AX 2ewUkiZf1qs9FoAyMuS6i7H.XNKEvvj9VIsim_Bd.UypOcq5mt070aot7XyS WLHesyzuWJOTPqe2o6AkewXNwbKR8I_15_937HX7Wqr5SEKctypQSvdQHjCq 19wkNq91mJq3zeHfFnywOem2iypew7viWX74JS0H3vVAmEbQTRwA6iStiFKC Z7vQEFBCo07CT_LeNMSyPC_uhbI0VN5bMz.13aY8PoEmT30xdfyZ_5SLdZkr mmT2sn1Kw1sDGs05jdruEnqkDTZBdRVm1xpBSg0zmxgyP8aMK3x0Cl1Nnd3P yeJqcXn7n.TjS.tH71z0jsLw_wSJxZuFqGaiq8npTqBlSd5V_wCLl1IMkJ40 m9a9ORO1xtoPJW3_z9xB6bbu9AV07rtZ2hWeFEb3FhaxoVTy7G4yWauz.dwk AqVo2ETCvergSPkaIOJKsjJFrvAcBzEVgamCeJ_BQaM7k19g5F4wDUm3Yjy_ sy1H46zZfFVk3RSPUhQHMz9Q5rj.E10VGa2jaF2RFHL7Io6R_6MtQ X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/14.6.6.160626 Date: Fri, 07 Oct 2016 10:06:34 -0700 From: Nitin Bahadur To: "Joel M. Halpern" , Jeff Tantsura , Russ White <7riw77@gmail.com> Message-ID: Thread-Topic: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al... References: <000b01d21c59$0e0a7880$2a1f6980$@gmail.com> <5010C073-5BB9-48A1-8491-C975F2338728@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al... X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:06:44 -0000 This use-case is a little too specific. I can see that having a =B3new nexthop type=B2 might assist with dynamic flow manipulations without causing packet drops. We just have to be careful about adding this to the main draft, since it opens up to more and more special cases being added after WG LC. On 10/2/16, 3:29 PM, "i2rs on behalf of Joel M. Halpern" wrote: >To add to that, I am wondering about ading this now. Unless I am >confused, and we have also made a serious mistake, the model is quite >extensible. It is highly likely that we will add additional next hop >types in the future. If we do not yet know of any use for this >particularly one, why add it now? > >Yours, >Joel > >On 10/2/16 6:20 PM, Jeff Tantsura wrote: >> Russ, >> >> What would be the semantics of such NH? >> Don't use for forwarding at all? Don't use for forwarding within ECMP >>bunde? Don't use in ECMP but use otherwise? >> >> Regards, >> Jeff >> >>> On Oct 1, 2016, at 7:59 PM, Russ White <7riw77@gmail.com> wrote: >>> >>> Y'all -- >>> >>> I would like to suggest we add one more next hop type in section 2.4 of >>> draft-ietf-i2rs-rib-data-model, and sections 2.4 & 7.2 of >>> draft-ietf-i2rs-rib-info-model to include a nexthop type that tells the >>> forwarding device to not use a particular next hop without sending >>>traffic >>> to dev/null. The specific case is this -- assume I have an ECMP group >>>with >>> 32 or 64 entries. In this group, I want to pin one flow to a >>>particular set >>> of links, while making certain some other set of flows do _not_ use >>>those >>> links. The only way to accomplish this today would be to replace every >>>route >>> with the same ECMP group to provide a different set of next hops for >>>each >>> one. It would be cleaner to have a construction that says, "take this >>>next >>> hop out of all ECMP groups, so it is only used when specified by this >>> client," or some such. >>> >>> Maybe something like this in section 7.2 of the rib data model might >>>work -- >>> >>> =3D=3D >>> 7.4. Remove from ECMP next hop >>> >>> If the a particular route is marked "remove from ECMP," then any routes >>> which recurse onto this next hop as part of an ECMP group will remove >>>any >>> paths using this route as a next hop from the ECMP group. This allows >>>the >>> I2RS controller to remove ECMP traffic from a particular next hop to >>>attain >>> finer grained control over the use of specific links to which >>>particular >>> elephant flows may be pinned, or which may be otherwise congested, etc. >>> =3D=3D >>> >>> I don't know of any implementation that could do this right now, but >>>this >>> seems like a useful addition to the set of available next hops (?). >>> >>> :-) >>> >>> Russ >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Oct 21 16:26:44 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A15FD12996A; Fri, 21 Oct 2016 16:21:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207965.28214.643503855848296101.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:19 -0700 Archived-At: Cc: i2rs@ietf.org, akatlas@gmail.com Subject: [i2rs] i2rs - Requested sessions have been scheduled for IETF 97 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:20 -0000 Dear Susan Hares, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. i2rs Session 1 (2:00:00) Monday, Afternoon Session I 1330-1530 Room Name: Studio 2 size: 80 --------------------------------------------- i2rs Session 2 (1:00:00) Wednesday, Afternoon Session II 1520-1620 Room Name: Studio 2 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Interface to the Routing System Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: idr trill i2nsf rtgarea rtgwg netconf netmod Second Priority: bess nfvrg sdnrg sidr Special Requests: --------------------------------------------------------- From nobody Mon Oct 24 03:32:17 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5542B1293DC; Mon, 24 Oct 2016 03:32:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147730513633.15463.2064365068681638626.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 03:32:16 -0700 Archived-At: Cc: jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-ephemeral-state-19=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 10:32:16 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two comments: 1) "I2RS requires ephemeral state; i.e. state that does not persist across reboots." -> why? Maybe add 1-2 sentences about the use (case) in the introduction. 2) Are all these requirements specific to ephemeral state? I would assume that some requirements are more general, e.g. don't you need priorities also for all other state updates? From nobody Mon Oct 24 04:17:41 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06A9129675; Mon, 24 Oct 2016 04:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhGSHkKHEiAu; Mon, 24 Oct 2016 04:17:32 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2A21294EF; Mon, 24 Oct 2016 04:17:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.86.225; From: "Susan Hares" To: "'Mirja Kuehlewind'" , "'The IESG'" References: <147730513633.15463.2064365068681638626.idtracker@ietfa.amsl.com> In-Reply-To: <147730513633.15463.2064365068681638626.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 07:15:36 -0400 Message-ID: <098b01d22de7$f4edb4c0$dec91e40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFZ376eBA7GLubUqS2dij+H/4ZjJaGoD56w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-ephemeral-state-19=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 11:17:34 -0000 Mirja:=20 1) "I2RS requires ephemeral state; i.e. state that does not persist across reboots." -> why? Maybe add 1-2 sentences about = the use (case) in the introduction. I will add a few sentences to the introduction. =20 2) Are all these requirements specific to ephemeral state? I would = assume that some requirements are more general, e.g. don't you need = priorities also for all other state updates? All of these requirements are required in order to do ephemeral state. = I2RS is specified to have data which is just ephemeral state. So... I'm = not sure what the question is.=20 Sue=20 -----Original Message----- From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]=20 Sent: Monday, October 24, 2016 6:32 AM To: The IESG Cc: draft-ietf-i2rs-ephemeral-state@ietf.org; Joe Clarke; = i2rs-chairs@ietf.org; jclarke@cisco.com; i2rs@ietf.org Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two comments: 1) "I2RS requires ephemeral state; i.e. state that does not persist across reboots." -> why? Maybe add 1-2 sentences about = the use (case) in the introduction. 2) Are all these requirements specific to ephemeral state? I would = assume that some requirements are more general, e.g. don't you need = priorities also for all other state updates? From nobody Mon Oct 24 06:18:46 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20312957A for ; Mon, 24 Oct 2016 06:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbohK5strbKU for ; Mon, 24 Oct 2016 06:18:40 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DE912957E for ; Mon, 24 Oct 2016 06:18:38 -0700 (PDT) Received: (qmail 32074 invoked from network); 24 Oct 2016 15:18:26 +0200 Received: from p5dec2f7e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.126) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 Oct 2016 15:18:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <098b01d22de7$f4edb4c0$dec91e40$@ndzh.com> Date: Mon, 24 Oct 2016 15:18:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <83CFB624-2DFD-4E87-9559-798015D7BA53@kuehlewind.net> References: <147730513633.15463.2064365068681638626.idtracker@ietfa.amsl.com> <098b01d22de7$f4edb4c0$dec91e40$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-ephemeral-state-19=3A_=28with_COMMENT=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 13:18:44 -0000 Hi Susan, > I2RS is specified to have data which is just ephemeral state. Missed that part. So basically you only need to address comment one and = mention that. Thanks, Mirja > Am 24.10.2016 um 13:15 schrieb Susan Hares : >=20 > Mirja:=20 >=20 >=20 > 1) "I2RS requires ephemeral state; i.e. state that does > not persist across reboots." -> why? Maybe add 1-2 sentences about = the use (case) in the introduction. >=20 > I will add a few sentences to the introduction. =20 >=20 > 2) Are all these requirements specific to ephemeral state? I would = assume that some requirements are more general, e.g. don't you need = priorities also for all other state updates? >=20 > All of these requirements are required in order to do ephemeral state. = I2RS is specified to have data which is just ephemeral state. So... = I'm not sure what the question is.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net]=20 > Sent: Monday, October 24, 2016 6:32 AM > To: The IESG > Cc: draft-ietf-i2rs-ephemeral-state@ietf.org; Joe Clarke; = i2rs-chairs@ietf.org; jclarke@cisco.com; i2rs@ietf.org > Subject: Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2rs-ephemeral-state-19: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Two comments: >=20 > 1) "I2RS requires ephemeral state; i.e. state that does > not persist across reboots." -> why? Maybe add 1-2 sentences about = the use (case) in the introduction. >=20 > 2) Are all these requirements specific to ephemeral state? I would = assume that some requirements are more general, e.g. don't you need = priorities also for all other state updates? >=20 >=20 >=20 From nobody Mon Oct 24 13:21:49 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A0312999B; Mon, 24 Oct 2016 13:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147734050340.20010.2027288476371888158.idtracker@ietfa.amsl.com> Date: Mon, 24 Oct 2016 13:21:43 -0700 Archived-At: Cc: jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 20:21:43 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Ephemeral-REQ-12: "were created" seems wrong. (Oh, and "MUST BE" isn't 2119 language:-) From nobody Tue Oct 25 12:52:56 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 491C11299B2; Tue, 25 Oct 2016 12:52:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147742517429.1472.11822233551240489297.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2016 12:52:54 -0700 Archived-At: Cc: jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 19:52:54 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm curious about the requirements on YANG and NETCONF/RESTCONF. Does this contemplate changes to those? Criteria to determine if they are acceptable choices? From nobody Tue Oct 25 13:38:36 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840DF129B42; Tue, 25 Oct 2016 13:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYwKAPo7BA0R; Tue, 25 Oct 2016 13:38:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 771C112966C; Tue, 25 Oct 2016 13:38:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8A90A1E337; Tue, 25 Oct 2016 16:40:34 -0400 (EDT) Date: Tue, 25 Oct 2016 16:40:34 -0400 From: Jeffrey Haas To: Ben Campbell Message-ID: <20161025204034.GD23262@pfrc.org> References: <147742517429.1472.11822233551240489297.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147742517429.1472.11822233551240489297.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 20:38:15 -0000 Ben, On Tue, Oct 25, 2016 at 12:52:54PM -0700, Ben Campbell wrote: > I'm curious about the requirements on YANG and NETCONF/RESTCONF. Does > this contemplate changes to those? Criteria to determine if they are > acceptable choices? Over the last several years, i2rs offered several examples of what such a change would look like. The netmod/netconf groups have made it rather clear that they wish to be the ones that provide the standardization for that work. This document states requirements. Work in those groups that satisfy the requirements will be sufficient. -- Jeff (who has a feeling it'll resemble stuff we've talked about anyway...) From nobody Wed Oct 26 00:03:08 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87246129442; Wed, 26 Oct 2016 00:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147746538654.18955.10864682823495677451.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2016 00:03:06 -0700 Archived-At: Cc: jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 07:03:06 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am surprised to see MUST level requirements on YANG "Ephemeral-REQ-06: YANG MUST have the ability to do the following:" and further requirements on NETCONF (REQ-09) and RESTCONF (REQ-10) in this document. Are there associated drafts in the respective WGs to make sure these requirements are met? From nobody Wed Oct 26 07:09:13 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0D6129BB9; Wed, 26 Oct 2016 07:09:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147749094996.28125.2028873762410036124.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2016 07:09:09 -0700 Archived-At: Cc: jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 14:09:10 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 9: s/Pub-Sub-REQ-03: The subscription service must support/Pub-Sub-REQ-03: The subscription service MUST support/ (I'm assuming that was the intent, anyway) From nobody Thu Oct 27 04:38:47 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3722129CF9; Thu, 27 Oct 2016 04:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-KqmeR2-vXu; Thu, 27 Oct 2016 04:38:32 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A6D129D79; Thu, 27 Oct 2016 04:38:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.87.48; From: "Susan Hares" To: "'Alissa Cooper'" , "'The IESG'" References: <147749094996.28125.2028873762410036124.idtracker@ietfa.amsl.com> In-Reply-To: <147749094996.28125.2028873762410036124.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 07:36:36 -0400 Message-ID: <312201d23046$60a58570$21f09050$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+rEnKijddPNP2f1oBXyxrl7ntiaBjNBMw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:38:36 -0000 Alissa: Thank you for catching this. Version 20 makes this change. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: Wednesday, October 26, 2016 10:09 AM To: The IESG Cc: jclarke@cisco.com; draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; i2rs@ietf.org Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 9: s/Pub-Sub-REQ-03: The subscription service must support/Pub-Sub-REQ-03: The subscription service MUST support/ (I'm assuming that was the intent, anyway) _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Oct 27 04:42:15 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81750129D89; Thu, 27 Oct 2016 04:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5qD4CZWhPnQ; Thu, 27 Oct 2016 04:42:08 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F2F129D83; Thu, 27 Oct 2016 04:42:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.87.48; From: "Susan Hares" To: "'Stephen Farrell'" , "'The IESG'" References: <147734050340.20010.2027288476371888158.idtracker@ietfa.amsl.com> In-Reply-To: <147734050340.20010.2027288476371888158.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 07:40:08 -0400 Message-ID: <312401d23046$df5661f0$9e0325d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHda51giYo6AZxcFCI12Wv7zu1SRKCltlUA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:42:13 -0000 Stephen thank you for catching this error. Ephemeral-REQ-12: When a collision occurs as two clients are trying to write the same data node, this collision is considered an error. The I2RS priorities are used to provide a deterministic resolution to the conflict. When there is a collision, and the data node is changed, a notification (which includes indicating data node the collision occurred on) MUST BE sent to the original client to give the original client a chance to deal with the issues surrounding the collision. The original client may need to fix their state. I've included this in version 20. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: Monday, October 24, 2016 4:22 PM To: The IESG Cc: jclarke@cisco.com; draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; i2rs@ietf.org Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Ephemeral-REQ-12: "were created" seems wrong. (Oh, and "MUST BE" isn't 2119 language:-) _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Oct 27 04:44:59 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9620129D82; Thu, 27 Oct 2016 04:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK0LJ9qutF8A; Thu, 27 Oct 2016 04:44:57 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBDE129A80; Thu, 27 Oct 2016 04:44:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.87.48; From: "Susan Hares" To: "'Suresh Krishnan'" , "'The IESG'" References: <147746538654.18955.10864682823495677451.idtracker@ietfa.amsl.com> In-Reply-To: <147746538654.18955.10864682823495677451.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 07:42:58 -0400 Message-ID: <312601d23047$444fd6e0$ccef84a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH6num+kmwtVgHcFlHwxbeynPQpn6BrT/xg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 11:44:58 -0000 Suresh: The NETCONF and NETMOD groups have asked the I2RS to specify the requirements, and not the specific solutions. We have done implementations based on NETCONF/RESTCONF that solve these issues, and described the mechanisms. However, the NETCONF and NETMOD groups have asked us only to provide requirements. All the solutions must be discussed in the NETCONF/NETMOD working groups. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Wednesday, October 26, 2016 3:03 AM To: The IESG Cc: jclarke@cisco.com; draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; i2rs@ietf.org Subject: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-19: 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-i2rs-ephemeral-state/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am surprised to see MUST level requirements on YANG "Ephemeral-REQ-06: YANG MUST have the ability to do the following:" and further requirements on NETCONF (REQ-09) and RESTCONF (REQ-10) in this document. Are there associated drafts in the respective WGs to make sure these requirements are met? _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Oct 27 05:02:09 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EA7129505; Thu, 27 Oct 2016 05:02:04 -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.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147756972421.24606.8307287369463161047.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 05:02:04 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-20.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:02:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-20.txt Pages : 11 Date : 2016-10-27 Abstract: The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 27 05:03:08 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F22129A88; Thu, 27 Oct 2016 05:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147756978661.24643.15919752806670541040.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 05:03:06 -0700 Archived-At: Cc: lionel.morand@orange.com, jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:03:07 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- - The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. I guess you mean RFC 7950. RFC7950 should be a normative reference. - I read the abstract and title: clearly this is about ephemeral state. I2RS Ephemeral State Requirements draft-ietf-i2rs-ephemeral-state-19.txt Abstract The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. Why (re-hashing) requirements not related to ephemeral? What the goal of this section 2? It seems more like adding confusing that being helpful. Too many requirements from different documents in I2RS: "distilling" them between documents is looking for troubles. note: section 9 title " Pub/Sub Requirements Expanded for Ephemeral State" and content area clear - I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state. I should be missing something. Examples would help me. - Clarification: Ephemeral-REQ-12: When a collision occurs as two clients are trying to write the same data node I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients? Note: multiple instances of "clients" (as opposed to I2RS clients) in the doc. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: - Section 5 versus 6 For NETCONF: 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). For RESTCONF: 2. The ephemeral state must support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). must versus MUST. If there are some language subtleties here, I didn't grasp them. - "To support Multi-Headed Control," Multi-Headed Control? I guess I know what you mean, but expressed like this (capitalized), I'm looking for a well-known, well-defined term. Later on, I see "Multi-headed control" - s/yang/YANG - Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol remove one "I2RS protocol" instance - Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: I would remove: "(e.g. NETCONF/RESTCONF + yang)" - "MUST BE" = MUST Belgium :-) Pretty good feedback from Lionel Morand's OPS DIR review: 1. Introduction The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. Additionally, the I2RS Working group has chosen to re-use two existing protocols, NETCONF [RFC6241] and its similar but lighter- weight relative RESTCONF [I-D.ietf-netconf-restconf], as the protocols for carrying I2RS. What does re-use of a protocol mean? Re-use means that while YANG, NETCONF and RESTCONF are a good starting basis for the I2RS protocol, the creation of the I2RS protocol implementations requires that the I2RS requirements 1. select features from YANG, NETCONF, and RESTCONF per version of the I2RS protocol (See sections 4, 5, and 6) 2. propose additions to YANG, NETCONF, and RESTCONF per version of the I2RS protocol for key functions (ephemeral state, protocol security, publication/subscription service, traceability), The purpose of these requirements is to ensure clarity during I2RS protocol creation. [LM] The aim of the document is not so clear. The working assumption is : re-use but with "addition". What does addition mean? Who is in charge to check that the proposed "additions" can be supported by YANG/NETCONF/RESTCONF without protocol updates? Where is the need to first derive specific requirements from RFC7921 and then check if they can be fulfilled by the model and the protocols, instead of doing both in the same document? 2. Review of Requirements from I2RS architecture document The I2RS architecture defines important high-level requirements for the I2RS protocol. The following are requirements distilled from [RFC7921] that provide context for the ephemeral data state requirements given in sections 3-8: [LM] What is the meaning of "distilled" here? Are these requirements explicitly part of the RFC7921 or the requirements listed in this draft may be "relative" or even complementary requirements compared to the RFC7921? 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, with real-time guarantees on getting data from an I2RS agent by an I2RS client. [LM] Is it a requirement related to the I2RS protocol or to the transport protocol? 2. I2RS agent MUST record the client identity when a node is created or modified. The I2RS agent SHOULD to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded. [LM] I think that the first sentence is not so related to the I2RS protocol but rather to the mechanism to provision the I2RS agent with this info (e.g. AAA). 3. An I2RS Client identity MUST have only one priority for the client's identifier. A collision on writes is considered an error, but the priority associated with each client identifier is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use [LM] If I'm correct, "First entry wins" is for clients associated with the same priority, right? If it is, it is not only about 'higher' priority. 4. I2RS Client's secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written. Just like the primary client identity, the secondary identity SHOULD only be recorded when the data node is written. [LM] Not sure of the relevance of this requirement in the context of the I2RS protocol design if this info is opaque for the agent. 5. I2RS agent MAY have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS agent. [LM] This requirement seems to imply that the priority associated with the client ID is transitively associated with the client's entry in the I2RS agent. If it is, this requirement should be clarified along with Req 3 or just after. 3.1. Persistence Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. [LM] this one is related to Req 8 and is about a "MUST" regarding the YANG model. As defined in RFC7950 (recently published), there are only two flavors of data managed with YANG: configuration data and state data, differentiated by the "config" statement with the argument the string "true" or "false". This requirement seems to imply a new "flavor" i.e. ephemeral state, which seems not compatible with the existing model that cannot be accommodated using a Boolean value. Does it mean that a new version of the YANG model would be required to fulfil this requirement? [LM] Most of the other requirements are derived from and/or dependent on the req 1. [LM] Other specific comments: 5. NETCONF Features for Ephemeral State 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). [LM] I wonder how this impacts the recommendation on the use of configuration lock mechanism when it is known that multiple instances may update the same configuration data as per RFC6241. Here, it seems that the priority is able to override the lock in place, which is not allowed in NETCONF. Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: o the data nodes MAY store I2RS client identity and not the effective priority at the time the data node is stored. [LM] This requirement seems to be in contradiction with the one given in section 2 i.e. "I2RS agent MUST record the client identity when a node is created or modified.". If I'm correct, the "MAY" applies only to the "effective priority" and not to the I2RS Id storage. o The priority MAY be dynamically changed by AAA, but the exact actions are part of the protocol definition as long as collisions are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. [LM] there are several references to the use of AAA-based solutions for priority handling. Does it require any action in RADEXT or Dime to support these requirements, at least as a default standard mechanism for I2RS? From nobody Thu Oct 27 05:05:02 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09EE1293DC; Thu, 27 Oct 2016 05:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzd_rR8f5aZO; Thu, 27 Oct 2016 05:04:56 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354AE128DF6; Thu, 27 Oct 2016 05:04:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.87.48; From: "Susan Hares" To: "'Benoit Claise'" , "'The IESG'" References: <147756978661.24643.15919752806670541040.idtracker@ietfa.amsl.com> In-Reply-To: <147756978661.24643.15919752806670541040.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 08:02:58 -0400 Message-ID: <327101d2304a$0f7bf220$2e73d660$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7esXTuTJLyJcbZQYOx+Iy4htfKqFpnnIQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org, lionel.morand@orange.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:05:01 -0000 Benoit: I will be glad to address these comments. It is a little difficult when they come at 7:44am on Thursday morning. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Thursday, October 27, 2016 8:03 AM To: The IESG Cc: lionel.morand@orange.com; jclarke@cisco.com; draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; i2rs@ietf.org Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- - The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. I guess you mean RFC 7950. RFC7950 should be a normative reference. - I read the abstract and title: clearly this is about ephemeral state. I2RS Ephemeral State Requirements draft-ietf-i2rs-ephemeral-state-19.txt Abstract The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. Why (re-hashing) requirements not related to ephemeral? What the goal of this section 2? It seems more like adding confusing that being helpful. Too many requirements from different documents in I2RS: "distilling" them between documents is looking for troubles. note: section 9 title " Pub/Sub Requirements Expanded for Ephemeral State" and content area clear - I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state. I should be missing something. Examples would help me. - Clarification: Ephemeral-REQ-12: When a collision occurs as two clients are trying to write the same data node I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients? Note: multiple instances of "clients" (as opposed to I2RS clients) in the doc. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: - Section 5 versus 6 For NETCONF: 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). For RESTCONF: 2. The ephemeral state must support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). must versus MUST. If there are some language subtleties here, I didn't grasp them. - "To support Multi-Headed Control," Multi-Headed Control? I guess I know what you mean, but expressed like this (capitalized), I'm looking for a well-known, well-defined term. Later on, I see "Multi-headed control" - s/yang/YANG - Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol remove one "I2RS protocol" instance - Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: I would remove: "(e.g. NETCONF/RESTCONF + yang)" - "MUST BE" = MUST Belgium :-) Pretty good feedback from Lionel Morand's OPS DIR review: 1. Introduction The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. Additionally, the I2RS Working group has chosen to re-use two existing protocols, NETCONF [RFC6241] and its similar but lighter- weight relative RESTCONF [I-D.ietf-netconf-restconf], as the protocols for carrying I2RS. What does re-use of a protocol mean? Re-use means that while YANG, NETCONF and RESTCONF are a good starting basis for the I2RS protocol, the creation of the I2RS protocol implementations requires that the I2RS requirements 1. select features from YANG, NETCONF, and RESTCONF per version of the I2RS protocol (See sections 4, 5, and 6) 2. propose additions to YANG, NETCONF, and RESTCONF per version of the I2RS protocol for key functions (ephemeral state, protocol security, publication/subscription service, traceability), The purpose of these requirements is to ensure clarity during I2RS protocol creation. [LM] The aim of the document is not so clear. The working assumption is : re-use but with "addition". What does addition mean? Who is in charge to check that the proposed "additions" can be supported by YANG/NETCONF/RESTCONF without protocol updates? Where is the need to first derive specific requirements from RFC7921 and then check if they can be fulfilled by the model and the protocols, instead of doing both in the same document? 2. Review of Requirements from I2RS architecture document The I2RS architecture defines important high-level requirements for the I2RS protocol. The following are requirements distilled from [RFC7921] that provide context for the ephemeral data state requirements given in sections 3-8: [LM] What is the meaning of "distilled" here? Are these requirements explicitly part of the RFC7921 or the requirements listed in this draft may be "relative" or even complementary requirements compared to the RFC7921? 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, with real-time guarantees on getting data from an I2RS agent by an I2RS client. [LM] Is it a requirement related to the I2RS protocol or to the transport protocol? 2. I2RS agent MUST record the client identity when a node is created or modified. The I2RS agent SHOULD to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded. [LM] I think that the first sentence is not so related to the I2RS protocol but rather to the mechanism to provision the I2RS agent with this info (e.g. AAA). 3. An I2RS Client identity MUST have only one priority for the client's identifier. A collision on writes is considered an error, but the priority associated with each client identifier is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use [LM] If I'm correct, "First entry wins" is for clients associated with the same priority, right? If it is, it is not only about 'higher' priority. 4. I2RS Client's secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written. Just like the primary client identity, the secondary identity SHOULD only be recorded when the data node is written. [LM] Not sure of the relevance of this requirement in the context of the I2RS protocol design if this info is opaque for the agent. 5. I2RS agent MAY have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS agent. [LM] This requirement seems to imply that the priority associated with the client ID is transitively associated with the client's entry in the I2RS agent. If it is, this requirement should be clarified along with Req 3 or just after. 3.1. Persistence Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. [LM] this one is related to Req 8 and is about a "MUST" regarding the YANG model. As defined in RFC7950 (recently published), there are only two flavors of data managed with YANG: configuration data and state data, differentiated by the "config" statement with the argument the string "true" or "false". This requirement seems to imply a new "flavor" i.e. ephemeral state, which seems not compatible with the existing model that cannot be accommodated using a Boolean value. Does it mean that a new version of the YANG model would be required to fulfil this requirement? [LM] Most of the other requirements are derived from and/or dependent on the req 1. [LM] Other specific comments: 5. NETCONF Features for Ephemeral State 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). [LM] I wonder how this impacts the recommendation on the use of configuration lock mechanism when it is known that multiple instances may update the same configuration data as per RFC6241. Here, it seems that the priority is able to override the lock in place, which is not allowed in NETCONF. Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: o the data nodes MAY store I2RS client identity and not the effective priority at the time the data node is stored. [LM] This requirement seems to be in contradiction with the one given in section 2 i.e. "I2RS agent MUST record the client identity when a node is created or modified.". If I'm correct, the "MAY" applies only to the "effective priority" and not to the I2RS Id storage. o The priority MAY be dynamically changed by AAA, but the exact actions are part of the protocol definition as long as collisions are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. [LM] there are several references to the use of AAA-based solutions for priority handling. Does it require any action in RADEXT or Dime to support these requirements, at least as a default standard mechanism for I2RS? _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Oct 27 05:09:37 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B91129A8E; Thu, 27 Oct 2016 05:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.953 X-Spam-Level: X-Spam-Status: No, score=-14.953 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.431, SPF_HELO_PASS=-0.001, 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 uGZ104tnVyin; Thu, 27 Oct 2016 05:09:27 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D42129A89; Thu, 27 Oct 2016 05:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12822; q=dns/txt; s=iport; t=1477570166; x=1478779766; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Yh16f8l7Yty4gHN4/Bq8aFEAW9XlZQ4DOu03hUZE+Og=; b=hWfx/7pndsVkdE2Iflo9PD0naLB3KVSaaSrHGxQ5MSHePAxaIOwYz1VR HmSLXKmc1eVMvnPeuUSB7f+tu0b8pJt2m13Ho1AlmcS5P1NrmbGgJYAxG nh7XAYVRe6KMyVfSyrsxq3abEQhO12BP2WCI5DjS+ineSFJIey3VcaZIa w=; X-IronPort-AV: E=Sophos;i="5.31,404,1473120000"; d="scan'208";a="647688714" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2016 12:09:24 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9RC9NY2008394; Thu, 27 Oct 2016 12:09:24 GMT To: Susan Hares , "'The IESG'" References: <147756978661.24643.15919752806670541040.idtracker@ietfa.amsl.com> <327101d2304a$0f7bf220$2e73d660$@ndzh.com> From: Benoit Claise Message-ID: <195afd1c-5ca3-6ec3-3927-fe0aaf65bdd7@cisco.com> Date: Thu, 27 Oct 2016 14:09:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <327101d2304a$0f7bf220$2e73d660$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, lionel.morand@orange.com, jclarke@cisco.com, i2rs-chairs@ietf.org, draft-ietf-i2rs-ephemeral-state@ietf.org, Benoit Claise Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:09:31 -0000 Understood Sue. Nobody is asking the impossible. Also, let's not forget that a DISCUSS should serve as discussion points. Regards, Benoit > Benoit: > > I will be glad to address these comments. It is a little difficult when > they come at 7:44am on Thursday morning. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Thursday, October 27, 2016 8:03 AM > To: The IESG > Cc: lionel.morand@orange.com; jclarke@cisco.com; > draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; > i2rs@ietf.org > Subject: [i2rs] Benoit Claise's Discuss on > draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) > > Benoit Claise has entered the following ballot position for > draft-ietf-i2rs-ephemeral-state-20: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > - > The I2RS Working Group has chosen to use the YANG data modeling > language [RFC6020] as the basis to implement its mechanisms. > > I guess you mean RFC 7950. > RFC7950 should be a normative reference. > > > - > I read the abstract and title: clearly this is about ephemeral state. > > I2RS Ephemeral State Requirements > draft-ietf-i2rs-ephemeral-state-19.txt > > Abstract > > The I2RS (interface to the routing system) Architecture document > (RFC7921) abstractly describes a number of requirements for ephemeral > state (in terms of capabilities and behaviors) which any protocol > suite attempting to meet the needs of I2RS has to provide. This > document describes, in detail, requirements for ephemeral state for > those implementing the I2RS protocol. > > And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's > DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. > Why (re-hashing) requirements not related to ephemeral? > What the goal of this section 2? > It seems more like adding confusing that being helpful. Too many > requirements from different documents in I2RS: "distilling" them between > documents is looking for troubles. > note: section 9 title " > Pub/Sub Requirements Expanded for Ephemeral State" and content area clear > > > > > - I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? > > Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints > that refer to operational state, this includes potentially fast > changing or short lived operational state nodes, > > > Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- > ephemeral state as a constraint. Non-ephemeral state can be > configuration state or operational state. > > I should be missing something. Examples would help me. > > - Clarification: > Ephemeral-REQ-12: When a collision occurs as two clients are trying > to write the same data node > > I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients? > Note: multiple instances of "clients" (as opposed to I2RS clients) in the > doc. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Editorial: > - Section 5 versus 6 > For NETCONF: > 2. The ephemeral state MUST support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > For RESTCONF: > 2. The ephemeral state must support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > > must versus MUST. If there are some language subtleties here, I didn't grasp > them. > > - "To support Multi-Headed Control," > Multi-Headed Control? I guess I know what you mean, but expressed like this > (capitalized), I'm looking for a well-known, well-defined term. > Later on, I see "Multi-headed control" > > - s/yang/YANG > > - > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol > > remove one "I2RS protocol" instance > > - > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order > to support I2RS client identity and priority: > > I would remove: "(e.g. NETCONF/RESTCONF + yang)" > > > - "MUST BE" = MUST Belgium :-) > > Pretty good feedback from Lionel Morand's OPS DIR review: > > 1. Introduction > > The I2RS Working Group has chosen to use the YANG data modeling > language [RFC6020] as the basis to implement its mechanisms. > > Additionally, the I2RS Working group has chosen to re-use two > existing protocols, NETCONF [RFC6241] and its similar but lighter- > weight relative RESTCONF [I-D.ietf-netconf-restconf], as the > protocols for carrying I2RS. > > What does re-use of a protocol mean? Re-use means that while YANG, > NETCONF and RESTCONF are a good starting basis for the I2RS protocol, > the creation of the I2RS protocol implementations requires that the > I2RS requirements > > 1. select features from YANG, NETCONF, and RESTCONF per version of > the I2RS protocol (See sections 4, 5, and 6) > > 2. propose additions to YANG, NETCONF, and RESTCONF per version of > the I2RS protocol for key functions (ephemeral state, protocol > security, publication/subscription service, traceability), > > The purpose of these requirements is to ensure clarity during I2RS > protocol creation. > > [LM] The aim of the document is not so clear. The working assumption is : > re-use but with "addition". > What does addition mean? Who is in charge to check that the proposed > "additions" can be supported by YANG/NETCONF/RESTCONF without protocol > updates? Where is the need to first derive specific requirements from > RFC7921 and then check if they can be fulfilled by the model and the > protocols, instead of doing both in the same document? > > 2. Review of Requirements from I2RS architecture document > > The I2RS architecture defines important high-level requirements for > the I2RS protocol. The following are requirements distilled from > [RFC7921] that provide context for the ephemeral data state > requirements given in sections 3-8: > > [LM] What is the meaning of "distilled" here? Are these requirements > explicitly part of the RFC7921 or the requirements listed in this draft may > be "relative" or even complementary requirements compared to the RFC7921? > > 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous > interface, with real-time guarantees on getting data from an I2RS > agent by an I2RS client. > > [LM] Is it a requirement related to the I2RS protocol or to the transport > protocol? > > 2. I2RS agent MUST record the client identity when a node is created > or modified. The I2RS agent SHOULD to be able to read the client > identity of a node and use the client identity's associated > priority to resolve conflicts. The secondary identity is useful > for traceability and may also be recorded. > > [LM] I think that the first sentence is not so related to the I2RS protocol > but rather to the mechanism to provision the I2RS agent with this info (e.g. > AAA). > > 3. An I2RS Client identity MUST have only one priority for the > client's identifier. A collision on writes is considered an > error, but the priority associated with each client identifier is > utilized to compare requests from two different clients in order > to modify an existing node entry. Only an entry from a client > which is higher priority can modify an existing entry (First > entry wins). Priority only has meaning at the time of use > > [LM] If I'm correct, "First entry wins" is for clients associated with the > same priority, right? If it is, it is not only about 'higher' > priority. > > 4. I2RS Client's secondary identity data is read-only meta-data that > is recorded by the I2RS agent associated with a data model's node > is written. Just like the primary client identity, the secondary > identity SHOULD only be recorded when the data node is written. > > [LM] Not sure of the relevance of this requirement in the context of the > I2RS protocol design if this info is opaque for the agent. > > 5. I2RS agent MAY have a lower priority I2RS client attempting to > modify a higher priority client's entry in a data model. The > filtering out of lower priority clients attempting to write or > modify a higher priority client's entry in a data model SHOULD be > effectively handled and not put an undue strain on the I2RS > agent. > > [LM] This requirement seems to imply that the priority associated with the > client ID is transitively associated with the client's entry in the I2RS > agent. If it is, this requirement should be clarified along with Req > 3 or just after. > > 3.1. Persistence > > Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does > not persist across reboots. If state must be restored, it should be > done solely by replay actions from the I2RS client via the I2RS > agent. > > [LM] this one is related to Req 8 and is about a "MUST" regarding the YANG > model. As defined in RFC7950 (recently published), there are only two > flavors of data managed with YANG: configuration data and state data, > differentiated by the "config" statement with the argument the string "true" > or "false". This requirement seems to imply a new "flavor" i.e. > ephemeral state, which seems not compatible with the existing model that > cannot be accommodated using a Boolean value. Does it mean that a new > version of the YANG model would be required to fulfil this requirement? > > [LM] Most of the other requirements are derived from and/or dependent on the > req 1. > > [LM] Other specific comments: > > 5. NETCONF Features for Ephemeral State > > 2. The ephemeral state MUST support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > > [LM] I wonder how this impacts the recommendation on the use of > configuration lock mechanism when it is known that multiple instances may > update the same configuration data as per RFC6241. Here, it seems that the > priority is able to override the lock in place, which is not allowed in > NETCONF. > > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order > to support I2RS client identity and priority: > > o the data nodes MAY store I2RS client identity and not the > effective priority at the time the data node is stored. > > [LM] This requirement seems to be in contradiction with the one given in > section 2 i.e. "I2RS agent MUST record the client identity when a node is > created or modified.". If I'm correct, the "MAY" applies only to the > "effective priority" and not to the I2RS Id storage. > > o The priority MAY be dynamically changed by AAA, but the exact > actions are part of the protocol definition as long as collisions > are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, > and Ephemeral-REQ-14. > > [LM] there are several references to the use of AAA-based solutions for > priority handling. Does it require any action in RADEXT or Dime to support > these requirements, at least as a default standard mechanism for I2RS? > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > . > From nobody Thu Oct 27 05:21:10 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28E1294DF; Thu, 27 Oct 2016 05:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7QPPmIQawp5t; Thu, 27 Oct 2016 05:21:09 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 02A0A12945D; Thu, 27 Oct 2016 05:21:08 -0700 (PDT) X-AuditID: c6180641-e87ff70000000a0b-4f-58119ccc544c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 57.DB.02571.CCC91185; Thu, 27 Oct 2016 08:21:01 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0319.002; Thu, 27 Oct 2016 08:21:06 -0400 From: Suresh Krishnan To: Susan Hares , 'The IESG' Thread-Topic: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) Thread-Index: AQHSL1cE07kXRaUJ4km9mdDPT7+zDw== Date: Thu, 27 Oct 2016 12:21:05 +0000 Message-ID: References: <147746538654.18955.10864682823495677451.idtracker@ietfa.amsl.com> <312601d23047$444fd6e0$ccef84a0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPrO7ZOYIRBjtWm1gse93BZvHhWDOb xboZH1gsZvyZyGyx7+ofRos/b16xOLB5TPm9kdVjyZKfTB6zX19nDWCO4rJJSc3JLEst0rdL 4Mq4cn4HU0Ena8WGFRcZGxj7WboYOTkkBEwk/n78ytbFyMUhJLCBUWLfrouMEM5yRol7J6Yz glSxAVVt2PmZCcQWEbCVmHD5LFgHs8ANRon3p3aygySEBbIkptw7zApRlC3RsWMdC4StJ/Fp 9TWgBg4OFgFViY9XE0HCvAK+EkemP2YDsYUEqiW6u86AtTIKiEl8P7UGbBezgLjErSfzmSAu FZBYsuc8M4QtKvHy8T9WCFtJYs7ra8wQ9ToSC3Z/YoOwtSWWLXzNDLFLUOLkzCcsExhFZiEZ OwtJyywkLbOQtCxgZFnFyFFaXJCTm25kuIkRGCnHJNgcdzDu7fU8xCjAwajEw7ugTiBCiDWx rLgy9xCjBAezkgivwgfBCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK810PuhwsJpCeWpGanphak FsFkmTg4pRoYmZsbgsMjjr250/v5g+wCMX/BxNf5v+75M5pmxJ5Kd7zBuVLN9UJDoJzH3Gnx Ze/WnCjZpJ6kcL1P11T98scLxzVuXa/1zN29TnxS/gdP8eT9oWXy+Ue5/s7blJFbzXpBN/Lz k85nUzfbT5XNOXIpSjDf5LTIt2R1C/2ZMfsuyESGJYqcYS1SYinOSDTUYi4qTgQAqhrTipAC AAA= Archived-At: Cc: "draft-ietf-i2rs-ephemeral-state@ietf.org" , "i2rs@ietf.org" , "jclarke@cisco.com" , "i2rs-chairs@ietf.org" Subject: Re: [i2rs] Suresh Krishnan's No Objection on draft-ietf-i2rs-ephemeral-state-19: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:21:10 -0000 On 10/27/2016 07:44 AM, Susan Hares wrote:=0A= > Suresh:=0A= >=0A= > The NETCONF and NETMOD groups have asked the I2RS to specify the=0A= > requirements, and not the specific solutions. We have done=0A= > implementations based on NETCONF/RESTCONF that solve these issues, and=0A= > described the mechanisms. However, the NETCONF and=0A= > NETMOD groups have asked us only to provide requirements. All the soluti= ons=0A= > must be discussed in the NETCONF/NETMOD working groups.=0A= =0A= Thanks for clarifying Sue. I am happy as long at the other WGs are aware of= =0A= the requirements.=0A= =0A= Regards=0A= Suresh=0A= =0A= From nobody Thu Oct 27 05:26:17 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E3A129512; Thu, 27 Oct 2016 05:26:12 -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.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147757117287.24571.13662492221851980863.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 05:26:12 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-21.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:26:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-21.txt Pages : 11 Date : 2016-10-27 Abstract: The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 27 05:28:41 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DAA12946F; Thu, 27 Oct 2016 05:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeNUP6vkSnew; Thu, 27 Oct 2016 05:28:31 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260F1129507; Thu, 27 Oct 2016 05:28:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.36.87.48; From: "Susan Hares" To: "'Benoit Claise'" , "'The IESG'" References: <147756978661.24643.15919752806670541040.idtracker@ietfa.amsl.com> <327101d2304a$0f7bf220$2e73d660$@ndzh.com> <195afd1c-5ca3-6ec3-3927-fe0aaf65bdd7@cisco.com> In-Reply-To: <195afd1c-5ca3-6ec3-3927-fe0aaf65bdd7@cisco.com> Date: Thu, 27 Oct 2016 08:26:23 -0400 Message-ID: <33e401d2304d$55377ac0$ffa67040$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7esXTuTJLyJcbZQYOx+Iy4htfKgGMo6UYApPayP+hSJ/h8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs@ietf.org, jclarke@cisco.com, i2rs-chairs@ietf.org, lionel.morand@orange.com Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 12:28:33 -0000 Benoit: It is the timing that is problematic. With a late discuss, I have no ability to respond. With no ability to respond, this gets delayed until after IETF 97. I hope Version 21 addresses your DISCUSS comments. Sue -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Thursday, October 27, 2016 8:09 AM To: Susan Hares; 'The IESG' Cc: lionel.morand@orange.com; jclarke@cisco.com; draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; i2rs@ietf.org; Benoit Claise Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) Understood Sue. Nobody is asking the impossible. Also, let's not forget that a DISCUSS should serve as discussion points. Regards, Benoit > Benoit: > > I will be glad to address these comments. It is a little difficult > when they come at 7:44am on Thursday morning. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Thursday, October 27, 2016 8:03 AM > To: The IESG > Cc: lionel.morand@orange.com; jclarke@cisco.com; > draft-ietf-i2rs-ephemeral-state@ietf.org; i2rs-chairs@ietf.org; > i2rs@ietf.org > Subject: [i2rs] Benoit Claise's Discuss on > draft-ietf-i2rs-ephemeral-state-20: (with DISCUSS and COMMENT) > > Benoit Claise has entered the following ballot position for > draft-ietf-i2rs-ephemeral-state-20: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > - > The I2RS Working Group has chosen to use the YANG data modeling > language [RFC6020] as the basis to implement its mechanisms. > > I guess you mean RFC 7950. > RFC7950 should be a normative reference. > > > - > I read the abstract and title: clearly this is about ephemeral state. > > I2RS Ephemeral State Requirements > draft-ietf-i2rs-ephemeral-state-19.txt > > Abstract > > The I2RS (interface to the routing system) Architecture document > (RFC7921) abstractly describes a number of requirements for ephemeral > state (in terms of capabilities and behaviors) which any protocol > suite attempting to meet the needs of I2RS has to provide. This > document describes, in detail, requirements for ephemeral state for > those implementing the I2RS protocol. > > And in section 2, I see requirements "distilled" (btw, I agree with > Alvaro's > DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. > Why (re-hashing) requirements not related to ephemeral? > What the goal of this section 2? > It seems more like adding confusing that being helpful. Too many > requirements from different documents in I2RS: "distilling" them > between documents is looking for troubles. > note: section 9 title " > Pub/Sub Requirements Expanded for Ephemeral State" and content area > clear > > > > > - I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? > > Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints > that refer to operational state, this includes potentially fast > changing or short lived operational state nodes, > > > Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- > ephemeral state as a constraint. Non-ephemeral state can be > configuration state or operational state. > > I should be missing something. Examples would help me. > > - Clarification: > Ephemeral-REQ-12: When a collision occurs as two clients are trying > to write the same data node > > I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients? > Note: multiple instances of "clients" (as opposed to I2RS clients) in > the doc. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Editorial: > - Section 5 versus 6 > For NETCONF: > 2. The ephemeral state MUST support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > For RESTCONF: > 2. The ephemeral state must support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > > must versus MUST. If there are some language subtleties here, I didn't > grasp them. > > - "To support Multi-Headed Control," > Multi-Headed Control? I guess I know what you mean, but expressed like > this (capitalized), I'm looking for a well-known, well-defined term. > Later on, I see "Multi-headed control" > > - s/yang/YANG > > - > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol > > remove one "I2RS protocol" instance > > - > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order > to support I2RS client identity and priority: > > I would remove: "(e.g. NETCONF/RESTCONF + yang)" > > > - "MUST BE" = MUST Belgium :-) > > Pretty good feedback from Lionel Morand's OPS DIR review: > > 1. Introduction > > The I2RS Working Group has chosen to use the YANG data modeling > language [RFC6020] as the basis to implement its mechanisms. > > Additionally, the I2RS Working group has chosen to re-use two > existing protocols, NETCONF [RFC6241] and its similar but lighter- > weight relative RESTCONF [I-D.ietf-netconf-restconf], as the > protocols for carrying I2RS. > > What does re-use of a protocol mean? Re-use means that while YANG, > NETCONF and RESTCONF are a good starting basis for the I2RS protocol, > the creation of the I2RS protocol implementations requires that the > I2RS requirements > > 1. select features from YANG, NETCONF, and RESTCONF per version of > the I2RS protocol (See sections 4, 5, and 6) > > 2. propose additions to YANG, NETCONF, and RESTCONF per version of > the I2RS protocol for key functions (ephemeral state, protocol > security, publication/subscription service, traceability), > > The purpose of these requirements is to ensure clarity during I2RS > protocol creation. > > [LM] The aim of the document is not so clear. The working assumption is : > re-use but with "addition". > What does addition mean? Who is in charge to check that the proposed > "additions" can be supported by YANG/NETCONF/RESTCONF without protocol > updates? Where is the need to first derive specific requirements from > RFC7921 and then check if they can be fulfilled by the model and the > protocols, instead of doing both in the same document? > > 2. Review of Requirements from I2RS architecture document > > The I2RS architecture defines important high-level requirements for > the I2RS protocol. The following are requirements distilled from > [RFC7921] that provide context for the ephemeral data state > requirements given in sections 3-8: > > [LM] What is the meaning of "distilled" here? Are these requirements > explicitly part of the RFC7921 or the requirements listed in this > draft may be "relative" or even complementary requirements compared to the RFC7921? > > 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous > interface, with real-time guarantees on getting data from an I2RS > agent by an I2RS client. > > [LM] Is it a requirement related to the I2RS protocol or to the > transport protocol? > > 2. I2RS agent MUST record the client identity when a node is created > or modified. The I2RS agent SHOULD to be able to read the client > identity of a node and use the client identity's associated > priority to resolve conflicts. The secondary identity is useful > for traceability and may also be recorded. > > [LM] I think that the first sentence is not so related to the I2RS > protocol but rather to the mechanism to provision the I2RS agent with this info (e.g. > AAA). > > 3. An I2RS Client identity MUST have only one priority for the > client's identifier. A collision on writes is considered an > error, but the priority associated with each client identifier is > utilized to compare requests from two different clients in order > to modify an existing node entry. Only an entry from a client > which is higher priority can modify an existing entry (First > entry wins). Priority only has meaning at the time of use > > [LM] If I'm correct, "First entry wins" is for clients associated with > the same priority, right? If it is, it is not only about 'higher' > priority. > > 4. I2RS Client's secondary identity data is read-only meta-data that > is recorded by the I2RS agent associated with a data model's node > is written. Just like the primary client identity, the secondary > identity SHOULD only be recorded when the data node is written. > > [LM] Not sure of the relevance of this requirement in the context of > the I2RS protocol design if this info is opaque for the agent. > > 5. I2RS agent MAY have a lower priority I2RS client attempting to > modify a higher priority client's entry in a data model. The > filtering out of lower priority clients attempting to write or > modify a higher priority client's entry in a data model SHOULD be > effectively handled and not put an undue strain on the I2RS > agent. > > [LM] This requirement seems to imply that the priority associated with > the client ID is transitively associated with the client's entry in > the I2RS agent. If it is, this requirement should be clarified along > with Req > 3 or just after. > > 3.1. Persistence > > Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does > not persist across reboots. If state must be restored, it should be > done solely by replay actions from the I2RS client via the I2RS > agent. > > [LM] this one is related to Req 8 and is about a "MUST" regarding the > YANG model. As defined in RFC7950 (recently published), there are only > two flavors of data managed with YANG: configuration data and state > data, differentiated by the "config" statement with the argument the string "true" > or "false". This requirement seems to imply a new "flavor" i.e. > ephemeral state, which seems not compatible with the existing model > that cannot be accommodated using a Boolean value. Does it mean that a > new version of the YANG model would be required to fulfil this requirement? > > [LM] Most of the other requirements are derived from and/or dependent > on the req 1. > > [LM] Other specific comments: > > 5. NETCONF Features for Ephemeral State > > 2. The ephemeral state MUST support notification of write conflicts > using the priority requirements defined in section 7 below (see > requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). > > [LM] I wonder how this impacts the recommendation on the use of > configuration lock mechanism when it is known that multiple instances > may update the same configuration data as per RFC6241. Here, it seems > that the priority is able to override the lock in place, which is not > allowed in NETCONF. > > Ephemeral-REQ-11: The following requirements must be supported by the > I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order > to support I2RS client identity and priority: > > o the data nodes MAY store I2RS client identity and not the > effective priority at the time the data node is stored. > > [LM] This requirement seems to be in contradiction with the one given > in section 2 i.e. "I2RS agent MUST record the client identity when a > node is created or modified.". If I'm correct, the "MAY" applies only > to the "effective priority" and not to the I2RS Id storage. > > o The priority MAY be dynamically changed by AAA, but the exact > actions are part of the protocol definition as long as collisions > are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, > and Ephemeral-REQ-14. > > [LM] there are several references to the use of AAA-based solutions > for priority handling. Does it require any action in RADEXT or Dime to > support these requirements, at least as a default standard mechanism for I2RS? > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > . > From nobody Thu Oct 27 07:42:17 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C16E11294F4; Thu, 27 Oct 2016 07:42:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147757932878.24622.7313175188587806961.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 07:42:08 -0700 Archived-At: Cc: lionel.morand@orange.com, jclarke@cisco.com, draft-ietf-i2rs-ephemeral-state@ietf.org, i2rs-chairs@ietf.org, i2rs@ietf.org Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-ephemeral-state-21: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 14:42:13 -0000 Benoit Claise has entered the following ballot position for draft-ietf-i2rs-ephemeral-state-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- - I read the abstract and title: clearly this is about ephemeral state. I2RS Ephemeral State Requirements draft-ietf-i2rs-ephemeral-state-19.txt Abstract The I2RS (interface to the routing system) Architecture document (RFC7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) which any protocol suite attempting to meet the needs of I2RS has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. Why (re-hashing) requirements not related to ephemeral? What the goal of this section 2? It seems more like adding confusing that being helpful. Too many requirements from different documents in I2RS: "distilling" them between documents is looking for troubles. note: section 9 title " Pub/Sub Requirements Expanded for Ephemeral State" and content area clear - I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4? Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints that refer to operational state, this includes potentially fast changing or short lived operational state nodes, Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- ephemeral state as a constraint. Non-ephemeral state can be configuration state or operational state. I should be missing something. Examples would help me. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: - Section 5 versus 6 For NETCONF: 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). For RESTCONF: 2. The ephemeral state must support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). must versus MUST. If there are some language subtleties here, I didn't grasp them. - "To support Multi-Headed Control," Multi-Headed Control? I guess I know what you mean, but expressed like this (capitalized), I'm looking for a well-known, well-defined term. Later on, I see "Multi-headed control" - s/yang/YANG - Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol remove one "I2RS protocol" instance - Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: I would remove: "(e.g. NETCONF/RESTCONF + yang)" - "MUST BE" = MUST Belgium :-) Pretty good feedback from Lionel Morand's OPS DIR review: 1. Introduction The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. Additionally, the I2RS Working group has chosen to re-use two existing protocols, NETCONF [RFC6241] and its similar but lighter- weight relative RESTCONF [I-D.ietf-netconf-restconf], as the protocols for carrying I2RS. What does re-use of a protocol mean? Re-use means that while YANG, NETCONF and RESTCONF are a good starting basis for the I2RS protocol, the creation of the I2RS protocol implementations requires that the I2RS requirements 1. select features from YANG, NETCONF, and RESTCONF per version of the I2RS protocol (See sections 4, 5, and 6) 2. propose additions to YANG, NETCONF, and RESTCONF per version of the I2RS protocol for key functions (ephemeral state, protocol security, publication/subscription service, traceability), The purpose of these requirements is to ensure clarity during I2RS protocol creation. [LM] The aim of the document is not so clear. The working assumption is : re-use but with "addition". What does addition mean? Who is in charge to check that the proposed "additions" can be supported by YANG/NETCONF/RESTCONF without protocol updates? Where is the need to first derive specific requirements from RFC7921 and then check if they can be fulfilled by the model and the protocols, instead of doing both in the same document? 2. Review of Requirements from I2RS architecture document The I2RS architecture defines important high-level requirements for the I2RS protocol. The following are requirements distilled from [RFC7921] that provide context for the ephemeral data state requirements given in sections 3-8: [LM] What is the meaning of "distilled" here? Are these requirements explicitly part of the RFC7921 or the requirements listed in this draft may be "relative" or even complementary requirements compared to the RFC7921? 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, with real-time guarantees on getting data from an I2RS agent by an I2RS client. [LM] Is it a requirement related to the I2RS protocol or to the transport protocol? 2. I2RS agent MUST record the client identity when a node is created or modified. The I2RS agent SHOULD to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded. [LM] I think that the first sentence is not so related to the I2RS protocol but rather to the mechanism to provision the I2RS agent with this info (e.g. AAA). 3. An I2RS Client identity MUST have only one priority for the client's identifier. A collision on writes is considered an error, but the priority associated with each client identifier is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use [LM] If I'm correct, "First entry wins" is for clients associated with the same priority, right? If it is, it is not only about 'higher' priority. 4. I2RS Client's secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written. Just like the primary client identity, the secondary identity SHOULD only be recorded when the data node is written. [LM] Not sure of the relevance of this requirement in the context of the I2RS protocol design if this info is opaque for the agent. 5. I2RS agent MAY have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS agent. [LM] This requirement seems to imply that the priority associated with the client ID is transitively associated with the client's entry in the I2RS agent. If it is, this requirement should be clarified along with Req 3 or just after. 3.1. Persistence Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does not persist across reboots. If state must be restored, it should be done solely by replay actions from the I2RS client via the I2RS agent. [LM] this one is related to Req 8 and is about a "MUST" regarding the YANG model. As defined in RFC7950 (recently published), there are only two flavors of data managed with YANG: configuration data and state data, differentiated by the "config" statement with the argument the string "true" or "false". This requirement seems to imply a new "flavor" i.e. ephemeral state, which seems not compatible with the existing model that cannot be accommodated using a Boolean value. Does it mean that a new version of the YANG model would be required to fulfil this requirement? [LM] Most of the other requirements are derived from and/or dependent on the req 1. [LM] Other specific comments: 5. NETCONF Features for Ephemeral State 2. The ephemeral state MUST support notification of write conflicts using the priority requirements defined in section 7 below (see requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). [LM] I wonder how this impacts the recommendation on the use of configuration lock mechanism when it is known that multiple instances may update the same configuration data as per RFC6241. Here, it seems that the priority is able to override the lock in place, which is not allowed in NETCONF. Ephemeral-REQ-11: The following requirements must be supported by the I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order to support I2RS client identity and priority: o the data nodes MAY store I2RS client identity and not the effective priority at the time the data node is stored. [LM] This requirement seems to be in contradiction with the one given in section 2 i.e. "I2RS agent MUST record the client identity when a node is created or modified.". If I'm correct, the "MAY" applies only to the "effective priority" and not to the I2RS Id storage. o The priority MAY be dynamically changed by AAA, but the exact actions are part of the protocol definition as long as collisions are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. [LM] there are several references to the use of AAA-based solutions for priority handling. Does it require any action in RADEXT or Dime to support these requirements, at least as a default standard mechanism for I2RS? From nobody Mon Oct 31 08:51:01 2016 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EE5129795 for ; Mon, 31 Oct 2016 08:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 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=-1.497, 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 VqrJFSXQDIg7 for ; Mon, 31 Oct 2016 08:50:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8631297E4 for ; Mon, 31 Oct 2016 08:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2297; q=dns/txt; s=iport; t=1477929058; x=1479138658; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=de+m7H+FdvcQoyl3FQdWs4i22xWPoyUXPZIJYQ0M8q8=; b=aCGMehYVDRDAbRLJUG66E8hqbWNwyqPDlYnv7rDmIBCUcMQP/8m6eWj7 thCdVYY6D6NVWwe35CZ0HOzxBno0eXq+hzEl6o5Bmi7TmEUhYO6gf1uoq 5bGmDOdfodsUZM73gIwbqEf9MZOVzfgvAUq4JG4mTI9jOln7xM3BofNhS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgAQaBdY/5pdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR9bJ44JqzyCB4guPxQBAgEBAQEBAQFiHQuFDBVuCAImAks?= =?us-ascii?q?UDQgBAYhQoFyPcYxcAQEIAiWBB4U2gX2KI4JcBZoYgT6OcoFuiAQjhW+REx42Y?= =?us-ascii?q?IUuIog9AQEB?= X-IronPort-AV: E=Sophos;i="5.31,575,1473120000"; d="scan'208";a="165749791" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2016 15:50:58 +0000 Received: from [10.150.55.152] (dhcp-10-150-55-152.cisco.com [10.150.55.152]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9VFovdf012582 for ; Mon, 31 Oct 2016 15:50:58 GMT To: "i2rs@ietf.org" From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <8a6cde88-3f3d-958f-e32a-7df701e843e5@cisco.com> Date: Mon, 31 Oct 2016 11:50:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [i2rs] Comments on draft-ietf-i2rs-ephemeral-state-21 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 15:51:00 -0000 I have read through the latest -21 rev of draft-ietf-i2rs-ephemeral-state, and I'd like to raise some additional (mostly minor) comments: Section 1: OLD: The I2RS Architecture document [RFC7921] abstractly documents a number of requirements for implementing the I2RS requirements NEW: The I2RS Architecture document [RFC7921] abstractly documents a number of requirements for implementing the I2RS. === You talk about YANG as a data modeling language and NETCONF/RESTCONF as protocols. Good. However, in section 1, you go on to say: What does re-use of a protocol mean? Re-use means that while YANG, NETCONF and RESTCONF are a good starting basis for the I2RS protocol YANG is not a protocol. This is a nit, but perhaps YANG can be dropped from this sentence since it speaks to _protocol_ re-use. Either that, or say something like: What does re-use mean in this case? Re-use means that while YANG, NETCONF and RESTCONF are good starting points for defining the I2RS data model and protocol... === Section 2: The requirements are technically distilled from RFC7921 AND RFC7920 now. === Section 2, bullet 1: OLD: The I2RS protocol SHOULD support an interface asynchronous programmatic interface interface with properties of described in section 5 of [RFC7920] (e.g. high throughput) with support for target information streams, filtered evens, and thresholded events (real-time events) sent by an I2RS agent to an I2RS Client (Key points from section 1.1 of [RFC7921]). NEW: The I2RS protocol SHOULD support an asynchronous programmatic interface interface with properties of described in section 5 of [RFC7920] (e.g. high throughput) with support for target information streams, filtered evens, and thresholded events (real-time events) sent by an I2RS agent to an I2RS Client (Key points from section 1.1 of [RFC7921]). === Do a pass through this doc to lowercase the 'c' in client. You have a number of cases that read "I2RS Client" where we previously standardized on "I2RS client." === Section 7: OLD: MUST BE NEW: MUST be (This has been called out by others.) Joe