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 20:55 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 F2DDB12D0C2 for <i2rs@ietfa.amsl.com>; Sun, 28 Aug 2016 13:55:52 -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 GaMsyUzwypwo for <i2rs@ietfa.amsl.com>; Sun, 28 Aug 2016 13:55:51 -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 A5C4D12B051 for <i2rs@ietf.org>; Sun, 28 Aug 2016 13:55:51 -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> <020801d20141$d9acd3d0$8d067b70$@ndzh.com> <3a28683e-1e65-632c-4a9d-1e77a7e4fe28@cisco.com> <000001d20169$98fd59e0$caf80da0$@ndzh.com> <74928d20-79f1-6604-b051-02e118f98592@cisco.com>
In-Reply-To: <74928d20-79f1-6604-b051-02e118f98592@cisco.com>
Date: Sun, 28 Aug 2016 16:54:30 -0400
Message-ID: <000c01d2016e$5fc4a980$1f4dfc80$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKK2u9RuXRaZ/qKcZ/TddJhjST0/QFB/MGCAm8F7EsCjBpmIQEUTZScAWL+zOCep4N44A==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/00AZAuu_501U93xI3aamNTC4Xco>
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 20:55:53 -0000

Joe: 

I will send out version 16 shortly. 

Sue 

-----Original Message-----
From: Joe Clarke [mailto:jclarke@cisco.com] 
Sent: Sunday, August 28, 2016 4:33 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/28/16 16:20, Susan Hares wrote:
> Joe:
>
> Let's start with the overview, and then go down to words.
>
> My concern:
> The phrasing of this impacts the OPSTATE discussions for Juergen.  
> Juergen is pushing for ephemeral to just be operational state.  Other 
> drafts are pushing for ephemeral state to be configuration and 
> ephemeral state.  I have suggested a different model in the
protocol-strawman for I2RS.
>
> What is important in this document is to indicate that ephemeral 
> models have both configuration and operational state.

Agreed.

>
> Words:
>
> This statement words for me in the beginning of section 3.
> /Ephemeral state is defined as potentially including in a data model 
> ephemeral configuration and operational state which is flagged as 
> ephemeral./
>
> If this works, for you as well - I'll create a version 16.

Yes, this works.

Joe

>
> Sue
>
> -----Original Message-----
> From: Joe Clarke [mailto:jclarke@cisco.com]
> Sent: Sunday, August 28, 2016 4:05 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/28/16 11:35, Susan Hares wrote:
>>> 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.
>
> To be clear, I think this is somewhat semantic.  A device has one 
> state that is made of a number of related things.  But this 
> terminology not a stopping thing for me.
>
> In the new text above, would the following not satisfy Jürgen's comment?
>
> /Ephemeral state is defined as potentially including in a data model 
> ephemeral configuration and operational state which is flagged as 
> ephemeral./
>
> Note: I simply drop the second "state" as this seems a bit clearer to 
> be (i.e., before it stated, essentially, that ephemeral state includes 
> 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.
>
> Thanks and understood.
>
>> Works for me (WFM):   The complete sentences would be:
>>
>> As part of this requirement, the I2SR protocol should support:
>
> s/I2SR/I2RS/ :-)
>
>>  - 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.
>
> Works for me.
>
>> If you confirm
>
> Thanks, Sue.
>
> Joe
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>