[i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18
Alia Atlas <akatlas@gmail.com> Wed, 05 October 2016 02:37 UTC
Return-Path: <akatlas@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 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 <akatlas@gmail.com>
Date: Tue, 04 Oct 2016 22:37:04 -0400
Message-ID: <CAG4d1rccNuy1OuUHkhQok=jrnVnqR06TmBR5sV6OoqxaWMj31Q@mail.gmail.com>
To: "i2rs@ietf.org" <i2rs@ietf.org>, draft-ietf-i2rs-ephemeral-state@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c086dea81419d053e150d25"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/mI5g-8if16p24xZAoD1UKd0JfhA>
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\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 02:37:11 -0000
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] AD review of draft-ietf-i2rs-ephemeral-sta… Alia Atlas
- Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral… Joel M. Halpern
- Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral… Alia Atlas
- Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral… Susan Hares
- Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral… Susan Hares
- Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral… Alia Atlas
- Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral… Joe Clarke