Re: [I2rs-proto-dt] I2RS Protocol Document - Please review on Tuesday (10/20/2015)

"Eric Voit (evoit)" <> Mon, 19 October 2015 20:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC7871A9030 for <>; Mon, 19 Oct 2015 13:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iD2Nnw0Zwqbk for <>; Mon, 19 Oct 2015 13:02:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10C081A905D for <>; Mon, 19 Oct 2015 13:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=89271; q=dns/txt; s=iport; t=1445284959; x=1446494559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b3wrM0GWre0mbNjVxTMMd7IQqJjK+PF1/YNsocLkPVU=; b=OyuLIXO6fQrmw/BL74MhsQk/p4FaXbEF/1FhAMv8qjd7DtdDDv60iDCf YE2r+yC5EStwRFI/yOWZV+k9zTGoM2LB3kDfI7OKRKp2JWqsE2faMxm/e ixsS+73RboIDbEmT7y6qp3wGELMt+MaRiLjDTjjVpg0yeOSlHyIkF6sWU E=;
X-Files: I2RS-Ephemeral.docx : 55521
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.17,703,1437436800"; d="rels'?xml'?docx'72,48?scan'72,48,208,217,72,48";a="199063308"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2015 20:02:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t9JK2bmT025622 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 20:02:37 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 15:02:19 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 15:02:19 -0500
From: "Eric Voit (evoit)" <>
To: Susan Hares <>
Thread-Topic: [I2rs-proto-dt] I2RS Protocol Document - Please review on Tuesday (10/20/2015)
Thread-Index: AdEKnJ6Tj1l838LmSjGyQns/830hbQACaVPQ
Date: Mon, 19 Oct 2015 20:02:19 +0000
Message-ID: <>
References: <03c601d10a9c$c407b370$4c171a50$>
In-Reply-To: <03c601d10a9c$c407b370$4c171a50$>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_004_62e8d0be24614ffda609c6c6616b2e6fXCHALN013ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: 'Kent Watsen' <>, "" <>, 'Andy Bierman' <>
Subject: Re: [I2rs-proto-dt] I2RS Protocol Document - Please review on Tuesday (10/20/2015)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: I2RS protocol design team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Oct 2015 20:02:43 -0000

There is good stuff here.  Some thoughts are in the change-marked document enclosed.  I have extracted and highlighted a few of these below....

Section 3
Why is the caching question explicitly disallowed?   Why not just say implications are out-of-scope?

Section 4.2
Why is referential validation a "must not" instead of a "may not"?

Section 4.4
Priority preemption needs more thought.  When may the ephemeral value placed by a higher priority client write no longer visible or relevant?

*        Can my son and I fight over the thermostat on our iPads immediately?   (Hopefully my client has priority so he can't override him)

*        Must I maintain a logged in session to the thermostat to maintain my priority? How long does the ephemeral data maintain the linkage to the originator?  What if that linkage is deleted, can anyone be locked out?

*        If I forget about the thermostat and go on vacation, must by family reboot the thermostat to eventually gain write ownership?
'first-write-wins' is less common that 'last-write-wins' for reasons like this.

Figure 5
It would be good to have more details on how the linkage to the higher priority client is encoded, maintained, and made visible.

Section 9.1 & 9.2
Notification of write conflicts is a complex topic which means much info must be stored about every ephemeral object.   And since mechanisms for delivery of notifications might not exist if a NETCONF session goes down, should the Ephemeral data persist the loss of its originator?


From: I2rs-proto-dt [] On Behalf Of Susan Hares
Sent: Monday, October 19, 2015 2:34 PM
Cc: 'Kent Watsen'; 'Andy Bierman'
Subject: [I2rs-proto-dt] I2RS Protocol Document - Please review on Tuesday (10/20/2015)

HI all:

Here's the I2RS protocol design document.  Would you review this on Tuesday and send me comments?  If it is helpful, we could meet as a design team at 10:00-11:30am.

I would like to get comments and feedback before Wednesday's 10/21/2015 interim meeting.