Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18

Alia Atlas <akatlas@gmail.com> Wed, 05 October 2016 14:14 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 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: <CAG4d1rccNuy1OuUHkhQok=jrnVnqR06TmBR5sV6OoqxaWMj31Q@mail.gmail.com> <00f101d21f0b$2c1a7b40$844f71c0$@ndzh.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 5 Oct 2016 10:14:06 -0400
Message-ID: <CAG4d1rdwe7X9q_uTb+XP3cArqmFATSG+XA8WXOoAjFv61=unyw@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a1141c1424935bd053e1ecafb
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/gFlVdqY8ckjbkQWdcfgfm-gY11Q>
Cc: Jeff Haas <jhaas@juniper.net>, "i2rs@ietf.org" <i2rs@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, 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\)" <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 14:14:12 -0000

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 <shares@ndzh.com> wrote:

> Alia:
>
>
>
> I’ve 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?
>
>
>
>
>
> 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
>
>
>