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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 05 October 2016 07:25 UTC

Return-Path: <jmh@joelhalpern.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 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 <akatlas@gmail.com>, "i2rs@ietf.org" <i2rs@ietf.org>, draft-ietf-i2rs-ephemeral-state@ietf.org
References: <CAG4d1rccNuy1OuUHkhQok=jrnVnqR06TmBR5sV6OoqxaWMj31Q@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f931ee98-583a-d67a-02e7-66a5e1681e1b@joelhalpern.com>
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: <CAG4d1rccNuy1OuUHkhQok=jrnVnqR06TmBR5sV6OoqxaWMj31Q@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/-Ytd_7ut2rOuYQbe7zcffamHJuQ>
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\)" <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 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
>