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

"Susan Hares" <> Wed, 05 October 2016 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E9DA129714; Wed, 5 Oct 2016 06:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.946
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9AERFJKRRDNM; Wed, 5 Oct 2016 06:22:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (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=;
From: "Susan Hares" <>
To: "'Alia Atlas'" <>, <>, <>
References: <>
In-Reply-To: <>
Date: Wed, 5 Oct 2016 09:19:57 -0400
Message-ID: <00f101d21f0b$2c1a7b40$844f71c0$>
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
Archived-At: <>
Cc: 'Jeff Haas' <>, 'Joel Halpern' <>
Subject: Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18
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



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?  





From: Alia Atlas [] 
Sent: Tuesday, October 4, 2016 10:37 PM
Subject: AD review of draft-ietf-i2rs-ephemeral-state-18




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:




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.





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."




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