Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15)

"Susan Hares" <shares@ndzh.com> Sun, 28 August 2016 15:37 UTC

Return-Path: <shares@ndzh.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 E713012B010 for <i2rs@ietfa.amsl.com>; Sun, 28 Aug 2016 08:37:08 -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 kbX1Jb_octjf for <i2rs@ietfa.amsl.com>; Sun, 28 Aug 2016 08:37:07 -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 A548512B00B for <i2rs@ietf.org>; Sun, 28 Aug 2016 08:37:07 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166;
From: "Susan Hares" <shares@ndzh.com>
To: "'Joe Clarke'" <jclarke@cisco.com>, <i2rs@ietf.org>
References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com>
In-Reply-To: <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com>
Date: Sun, 28 Aug 2016 11:35:47 -0400
Message-ID: <020801d20141$d9acd3d0$8d067b70$@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: AQKK2u9RuXRaZ/qKcZ/TddJhjST0/QFB/MGCnuK1AHA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/6ZCvMXw6LhhKkRB6m8dC-dliFw8>
Cc: russ@riw.us, 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15)
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: Sun, 28 Aug 2016 15:37:09 -0000

Joe:

I'm sorry I missed responding you on August 2nd.  It appears I wrote the
message and then did not send it.    Please see comments below.  All changes
except the ephemeral state--> ephemeral configuration work for me (WFM).
Would you take a moment to look at that point, and then I will release a
version with the changes. 

Sue 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke
Sent: Tuesday, August 2, 2016 12:38 PM
To: Susan Hares; i2rs@ietf.org
Cc: russ@riw.us; 'Alia Atlas'
Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to
8/15)

On 8/2/16 09:18, Susan Hares wrote:
>> This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt.  This 
>> draft received a "hum" of consensus at IETF 96, and we are now taking 
>> the final text to a WG Last Call.  Please send your comments on the 
>> requirements to the WG list.

>I think this is good.  A general comment I have is that "ephemeral state"
is used in a number of places where I think "ephemeral configuration" should
be used.  >This may be a nit, but the device has one state that is dictated
by the various configuration types and the operational state.  This was
raised in BA in the meetings >as well.

>My recommendation is to replace "ephemeral state" with "ephemeral 
>configuration".   It's not a show-stopper the way it is, but I think the 
>latter is a bit clearer.

We had agreed that "ephemeral state" as what is defined in section 3.  Do
you think clarifying this in the text would be better: 

Old/Ephemeral state is defined as potentially including both ephemeral
configured state and operational state. /
New/Ephemeral state is defined as potentially including in a data model
ephemeral configuration state and operational state which is flagged as
ephemeral./

Without this explicit comment, Juergen did not consider Ephemeral-REQ--01
thru Ephemeral-REQ-04 to be specific enough.  

>One nit I notice is a mixed use of Client/client Agent/agent.  Per the last
round of RFCs, we are normalizing on client and agent (lowercase).

I will fix in version-16.  You are correct.  After we agree upon the use of
ephemeral state. 

>Section 7, bullet 2:  This text reads strangely:
>
>OLD TEXT:
>
>The I2RS protocol MUST support the
>      ability to have data nodes MAY store I2RS client identity and not
>      the effective priority of the I2RS client at the time the data
>      node is stored.

>PROPOSED NEW TEXT:
>
>The I2RS protocol MUST support the ability to have data nodes store I2RS
client identity and not the effective priority of the I2RS client at
> the time the data node is stored.

Warning: I am re-writing the ephemeral-protocol-security-requirements so,
the reference in bullet may change.  You new text works for me. 

>Section 8: I2RS is written "I2SR"
I will fix in version -16 of the text.  Thank you. 

>Section 8: This text is odd
>OLD TEXT:
>multiple operations in one or more messages handling can handle
>     errors within the set of operations in many ways.

>I'm stumped.  This doesn't read as a requirement per se.  Yes, the I2RS
protocol can support multiple operations within one message or multiple
messages.  Based >on the fact that atomicity is not provided, an error in
one message will have no effect on other messages, even if they are related.
So maybe:
>PROPOSED NEW TEXT:
>
>multiple operations in one or more messages; though errors in one message
or operation will have no effect on other messages or commands even if they
are >related

Works for me (WFM):   The complete sentences would be: 

As part of this requirement, the I2SR protocol should support:
 - multiple operations in one or more messages; though errors in one message
or operation will have no effect on other messages or commands even if they
are related. 
- No multi-message commands SHOULD cause errors to be inserted into the I2RS
ephemeral state.

>Section 9:
OLD TEXT:
>requirements SHOULD be understood to be expanded to to include
>
>NEW TEXT:
>
>requirements SHOULD be understood to be expanded to include

Works for me (WFM). 

If you confirm 

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