Subject: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

From: [email-masked]
Date: Sat, 4 Jul 2015 11:25:29 +0800

Hello J. Haas and S. Hares,

I have some doubt about "draft-ietf-i2rs-ephemeral-state-00".

1.Chapter 6 Requirements regarding Identity, Secondary-Identity and 
Priority

I2RS permits RPC operation to carry priority and a secondary identity as 
attribute parameters.
In this draft, it describes that "This secondary identity meta-data MUST 
be read-only. operations attempting to alter it MUST be silently ignored. 
"
Since identity attribute cannot be changed until the session terminates, 
why don't we permit client to send hello message with such infos during
 session establishment.
 e.g,
    <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         urn:ietf:params:netconf:base:1.0
       </capability>
       <capability>
 
urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=user1&priority=10
       </capability>
     </capabilities>
   </hello>
It means in this session, the secondary-identity is named "user1", the 
default priority is 10 

then,if the session wants to change its priority while RPC operation,as 
follows
     <foo xmlns:i2rs="https://ietf.example.com/i2rs" 
i2rs:i2rs-priority="47">
          ...
    </foo> 
It means now in this session, the secondary-identity is named "user1", the 
priority is 47 

furthermore, we can define <set-i2rs-priority> to change current session's 
priority,such as
    <set-i2rs-priority 
xmlns:i2rs="urn:ietf:params:i2rs:capability:i2rs:1.0">
        <priority>20</priority>
    </set-i2rs-priority>

2.In this draft, Priority is defined as a numeric value,how about its 
range statements? Is "i2rs-priority = 255" is the highest?

3.config ephemeral
In this draft,The YANG "config" keyword is extended,like "config 
true/false/ephemeral" ,and the basic netconf operation should be extended,
like "get-config" "edit-config" and so on.
why don't we define a new kind of operations,like "get-i2rs" "edit-i2rs"? 
Take definition of "get-i2rs" for example.
        rpc get-i2rs {
        description "This operation can be used to get data from i2rs 
data";
        input {
                leaf private {
                        description "If the value is true, it means only 
data owned by 
                                         the same identity will be 
retrieved. Otherwise, all i2rs 
                                         data will be returned.";
                        type boolean;
                        default false;
                }
                anyxml filter {
                        description
                          "Subtree filter to use.";
                }
        }
 
        output {
                anyxml data {
                        description
                          "Copy of the i2rs data that matched
                           the filter criteria (if any).  An empty data 
container
                           indicates that the request did not produce any 
results.";
                }
        }
    }
If it is feasible, i can define others.

[email-masked] 
发件人:  "i2rs" <[email-masked]>
2015/06/24 00:52

收件人
<[email-masked]>, 
抄送
[email-masked]
主题
[i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 This draft is a work item of the Interface to the Routing System Working 
Group of the IETF.

        Title           : I2RS Ephemeral State Requirements
        Authors         : Jeff Haas
                          Susan Hares
                 Filename        : draft-ietf-i2rs-ephemeral-state-00.txt
                 Pages           : 13
                 Date            : 2015-06-23

Abstract:
   This document covers requests to the netmod and netconf Working
   Groups for functionality to support the ephemeral state requirements
   to implement the I2RS architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-00

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 13 Jul 2015 18:46:52 -0400

> It means in this session, the secondary-identity is named "user1", the 

This would be an acceptable means of encoding the secondary-identity.  Does
anyone working on a netconf implementation have any opinions about this form
vs. what is in the draft?

Note that the priority MUST not be user-supplied.  It should be derived from
the credentials.  Letting the user set the priority may be inappropriate
security.

> xmlns:i2rs="urn:ietf:params:i2rs:capability:i2rs:1.0">

I believe having the priority set per-session likely matches our use case.
In the event a different priority is expected, the user would use a
different session with different credentials.

> range statements? Is "i2rs-priority = 255" is the highest?

At the moment, I think we're a bit early on this specific detail.  Once we
have further clarification from the netconf working group, we can clarify
this point.  

> why don't we define a new kind of operations,like "get-i2rs" "edit-i2rs"? 

There has been some level of feedback from the netmod/netconf Working Group
participants that this might be the way to go.  Consider the prior
proposal draft-bjorklund-netmod-operational.

The specific details of this will resolve once the underlying concepts of
how we'll represent the ephemeral configuration state have been better
defined.  The proposals in the current draft are merely discussion points to
try to start a conversation as to what the mechanism could look like.

We're looking forward to that discussion within netconf.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Jul 2015 15:58:22 -0700

> the credentials.  Letting the user set the priority may be inappropriate

This approach would mean that the I2RS client acting as a broker
would need a different session for each secondary client.
It seems more useful to allow the client to use 1 session,
and just require that each edit be from a specific secondary identity.

(e.g., add a secondary-identity parameter to the edit operation).
The proposed solution of an XML attribute allows every node
in an edit to be from a different secondary identity.

> different session with different credentials.

I thought the client priority is configured in advance by the
administrator.  It makes no sense to have each client
state their own priority.  This is useless for resolving conflicts
between clients.

> have further clarification from the netconf working group, we can clarify

IMO, priority 0 is the highest, and can only be used
by the system itself.  Priority 1 is the next highest.

> We're looking forward to that discussion within netconf.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 13 Jul 2015 19:09:52 -0400

Andy,

> in an edit to be from a different secondary identity.

I don't object to moving secondary-identity into something that may be able
to vary on a per-edit transaction.  

I had started to write that priority is associated with their client and
that edits are likely done on behalf of a given secondary-id.  Then I had a
realization prompted by the proxy use case: In order to carry through the
appropriate priority, it would be necessary to similarly carry through the
primary identity in order to have that identity/priority association.  This
seems a bit contrary to the idea of a proxy operating as "root".

Joel/Alia, would you please comment how you intended the multi-headed
control case to operate with regard to associated identity and priority?

> state their own priority.  This is useless for resolving conflicts

Priority associated to client identity is what is intended.

> by the system itself.  Priority 1 is the next highest.

This is probably reasonable.  It also means you've already tripped into the
usual descriptive issue of lower is better; better is not higher. :-)

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jul 2015 19:31:52 -0400

Secondary identity can (and in fact is expected to) change during the 
session an I2RS client has with an I2RS Agent.  Specifically, if the 
client is acting as a broker, it will need to associated different 
operations with different secondary identities.

Priority is, as I understand it, per session.  I tend to think of 
priority as coming from AAA, not from the Client, but that is something 
we can discuss.

Yours,
Joel

---

From: Joel Halpern <[email-masked]>
Date: Mon, 13 Jul 2015 19:37:29 -0400

Yours,
Joel

---

From: Joel Halpern <[email-masked]>
Date: Mon, 13 Jul 2015 19:37:37 -0400

To amplify my previous reply on priority, priority is associated with 
the I2RS Client.  it does not change even if the client is acting on 
behalf of multiple secondary identities.  (If the use case requires that 
variability, use multiple primary identities, with separate sessions.)

Thus, the conflict error behavior is determined by the clients, not by 
what they are doing or the secondary identities they are working on 
behalf of.  The WG considered (and I hope still considers) this 
acceptable on the basis that it is an error case anyway, and all we are 
doing is creating predictable behavior for the rror handling, not 
"correct" behavior.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jul 2015 20:01:21 -0400

In line toi make sure we keep context.
Yours,
Joel

On 7/13/15 7:48 PM, Jeffrey Haas wrote:
> Joel,
>
> On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote:
>> To amplify my previous reply on priority, priority is associated
>> with the I2RS Client.  it does not change even if the client is
>> acting on behalf of multiple secondary identities.  (If the use case
>> requires that variability, use multiple primary identities, with
>> separate sessions.)
>
> To attempt to reduce this to an example:
> Basis case: Multiple clients speaking directly to an agent.  Clients have
> distinct priorities.  Priority causes config to tie-break appropriately
> among the various client interactions.

Yes.

>
> Proxy case: Agent is against as "root" from a proxy, potentially with the
> a single priority.  As long as the proxy maintains the tie-breaking as if it
> had implemented the agent operations, it's okay that the resultant nodes may
> have the same priority associated with them?

Having the client keep track of what it has modified, and noticing if 
there are direct conflicts among the applications it supports is indeed 
a way to handle it.

Note that a client acting on behalf of multiple applications needs to 
make sure it keeps track of what it has done, and on whose behalf, for 
lots of reasons.

>
> Gloss: We still haven't concluded our discussion as to whether the nodes are
> decorated as "owned by an identity" or "have a priority".

 From other discussions, I had assumed nodes had to be decorated with 
the owned-by identity.  In the case of error, when a given clients entry 
is removed due to a higher priority client pre-empting it, the original 
client is to be notified of the error.  If you don't have the owner 
decoration, that is impossible.  Having said that, I was not expecting 
I2RS to give that owner or priority information back in any request, so 
I had always considered it an internal implementation matter how the 
associations were stored.  Returning such information in response to a 
get is a nice-to-have, but is not to the best of my knowledge an I2RS 
requirement.

>
> Note that the gloss has an interesting impact.  If nodes are expected to get
> their priority via identity, this makes things very messy if you don't
> maintain multiple identities to have distinct priorities in the proxy case.

I am not sure where the complications comes from.  The priority comes 
from the client that performed that operation.  That identity needs to 
be available (as noted above).  Secondary identities are recorded for 
traceability.  Again, whether they are actually with the node, or only 
in the log, is not something on which I2RS has expressed a requirement. 
  The requirement is that the information be provided in the request, 
and be logged.

There is a good argument for requiring that the secondary identity be 
returned with any error notifications, so as to make the broker clients 
job more tractable.  But I don't think we said that anywhere.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Jul 2015 18:04:15 -0700

> maintain multiple identities to have distinct priorities in the proxy case.

OK -- it is becoming clearer now -- in order to support a broker, the
priority is saved with the node, not the client.

The operator configured priority is really the "best allowed".
Let's say lower priorities are better, and client A is assigned the
value 10.  That means client A is allowed to use priorities 10 .. 255.

Each edit from client A can have a priority that is associated with
the secondary client.

   <rpc>
      <edit-config>
         <target><ephemeral /></target>
         <config>  ... </config>
         <secondary-identity>app27</secondary-identity>
         <priority>42</priority>
      </edit-config>
   </rpc>

An error is returned if <priority> is 9 or lower in this example.

IMO this is better than requiring client A to open a session as a
different user name for each priority value needed.

-- Jeff

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jul 2015 21:42:45 -0400

The flexibility Jeff has described, and you have commented upon, is 
permitted but not required by (what I understand of) the agreements of 
the WG.  If it can be easily done, it seems like a nice thing to do.

Yours,
Joel

On 7/13/15 9:04 PM, Andy Bierman wrote:
>
>
> On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Joel,
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Jul 2015 19:07:44 -0700

On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern <[email-masked]>
wrote:

> permitted but not required by (what I understand of) the agreements of the
> WG.  If it can be easily done, it seems like a nice thing to do.
>
>
It means the priority, client-ID, and 2nd-id all need to be saved per
subtree.

What happens if a client priority mapping is deleted or does not exist?
Does that client just get the worst possible priority or is it an error
or is all data deleted for that client?

What if the server is aware a client id was removed completely?
Does that matter for existing data for that client?

Yours,

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jul 2015 22:14:56 -0400

Andy, I am not following your comments.  Questions in line below.
Joel

On 7/13/15 10:07 PM, Andy Bierman wrote:
>
>
> On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     permitted but not required by (what I understand of) the agreements
>     of the WG.  If it can be easily done, it seems like a nice thing to do.
>
>

per subtree?  The client-ID needs to be saved with the changed node. 
The secondary ID ought to be saved there, but is not required.  If we 
want to support variable priority, then we would need to record the 
priority.  Otherwise, recording the priority is an implementation 
acceleration, as it is determinable from the client ID.
> or is all data deleted for that client?

What happens if the client permissions are missing from the AAA?  I 
would expect the client to get no permissions.  Similarly, if the client 
priority is missing, the client would get the worst possible priority.

If we support variable, per-request, priority (limited by the AAA 
result) then we need to pick a behavior for when the client omits the 
value.  I don't care if he gets the worst priority or the best priority 
he is permitted (but if we want to support this we should be explicit.)
> Does that matter for existing data for that client?

If the client ID is no longer valid, and if the Agent (not sure what the 
server would be) knows that, then the client would no longer be 
permitted to perform new operations.  I suppose we should write down 
whether, in ushc an event, the clients existing operations are removed 
or the client retains the ability to remove them.  I am inclined to say 
that they should be removed, since the client may not currently have an 
active session, and presumably woudl fail any new attempt to 
authenticate.  This seems to be something we should spell out.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Jul 2015 19:26:41 -0700

On Mon, Jul 13, 2015 at 7:14 PM, Joel M. Halpern <[email-masked]>
wrote:

> per subtree?  The client-ID needs to be saved with the changed node. The
> secondary ID ought to be saved there, but is not required.  If we want to
> support variable priority, then we would need to record the priority.
> Otherwise, recording the priority is an implementation acceleration, as it
> is determinable from the client ID.
>

If the client creates a list entry then the priority applies to the list
node
and its descendants -- that's what I mean by subtree,

Is the 2nd-id sticky?

If /foo is created with 2nd=app21 and it is updated later
with a new value, but no 2nd is provided, is the old 2nd
reported (as per traceability requirements doc?)

Or is the 2nd forgotten by the server as soon as it is logged?
So the update edit would have no 2nd-id (as the request specified)?

> What happens if the client permissions are missing from the AAA?  I would
> expect the client to get no permissions.  Similarly, if the client priority
> is missing, the client would get the worst possible priority.
>
>
Getting worst priority seems correct

> If we support variable, per-request, priority (limited by the AAA result)
> then we need to pick a behavior for when the client omits the value.  I
> don't care if he gets the worst priority or the best priority he is
> permitted (but if we want to support this we should be explicit.)
>
>>
> server would be) knows that, then the client would no longer be permitted
> to perform new operations.  I suppose we should write down whether, in ushc
> an event, the clients existing operations are removed or the client retains
> the ability to remove them.  I am inclined to say that they should be
> removed, since the client may not currently have an active session, and
> presumably woudl fail any new attempt to authenticate.  This seems to be
> something we should spell out.
>
>
>
>>     Yours,
>>     Joel
>>
>>
>>
>> Andy
>>
>>

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jul 2015 22:31:24 -0400

A few more comments below.  Mostly, I think I understand you.
Thanks,
Joel

On 7/13/15 10:26 PM, Andy Bierman wrote:
>
>
> On Mon, Jul 13, 2015 at 7:14 PM, Joel M. Halpern <[email-masked]
>         On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>     The secondary ID ought to be saved there, but is not required.  If
>     we want to support variable priority, then we would need to record
>     the priority.  Otherwise, recording the priority is an
>     implementation acceleration, as it is determinable from the client ID.
>
>
Okay.

> So the update edit would have no 2nd-id (as the request specified)?
2nd ID is,as far as I can tell, per-operation.
If the Client does not send a second ID with a specific operation, then 
the Agent will presume that there is no second ID.  So the early second 
ID (which was logged when the operation was performed) will be removed. 
  And will therefore not be included if a later error message is 
generate.  That is what the client has indicated by not including a 
secondary ID on the operation.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Jul 2015 13:57:51 -0400

Joel,

On Mon, Jul 13, 2015 at 08:01:21PM -0400, Joel M. Halpern wrote:
> the owned-by identity.  In the case of error, when a given clients
> entry is removed due to a higher priority client pre-empting it, the
> original client is to be notified of the error.  If you don't have
> the owner decoration, that is impossible.  Having said that, I was
> not expecting I2RS to give that owner or priority information back
> in any request, so I had always considered it an internal
> implementation matter how the associations were stored.  Returning
> such information in response to a get is a nice-to-have, but is not
> to the best of my knowledge an I2RS requirement.

> I am not sure where the complications comes from.  The priority
> comes from the client that performed that operation.  That identity
> needs to be available (as noted above).  Secondary identities are
> recorded for traceability.  Again, whether they are actually with
> the node, or only in the log, is not something on which I2RS has
> expressed a requirement.  The requirement is that the information be
> provided in the request, and be logged.

User A has priority 10
User B has priority 20
(20 is better than 10 for discussion)
Per-discussion, owner is the meta data that nodes are decorated with for
priority resolution.

If user A writes state foo to an agent directly, foo is owned by A.
If user B writes state bar to an agent directly, bar is owned by B.

foo and bar have priorities 10 and 20 respectively as a consequence of the
priority system mapping clients to priority.

Proxy example:
A and B write above to some proxy, which needs to carry it to some second
system.
Ignore secondary-identity as that is noise for this example.

In order for the remote system to have foo with priority 10 and bar with
priority 20, since priority is tied to client we will either:

1. Require two distinct client IDs to allow the proxied system to store
something with appropriate tie-breaking.
2. Require the distributing agent to resolve the tie-breakers and simply
install the results itself.

You seem to believe that 2 is what will happen.

However, for multi-headed control, there may be more than one agent proxying
to the remote system.  This means that to enforce priority, the priority
needs to carry through to that remote system.  That also means that multiple
users are required, even if they are not A and B above - perhaps root10 and
root20.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Jul 2015 14:01:29 -0400

Andy,

> priority is saved with the node, not the client.

FWIW, I think this is likely the case.  However, the architecture authors
seem to disagree.

> value 10.  That means client A is allowed to use priorities 10 .. 255.

The implication from the architecture seems to be that a client gets one
priority.  This is the point for Alia/Joel to chime in if they disagree with
my interpretation.

>          <secondary-identity>app27</secondary-identity>

I don't believe the expected behavior is that priority is carried as a
protocol parameter.  FWIW, I think this may be useful in the case of a proxy
(as above), but presents interesting security issues since the secondary
identity isn't part of the authentication system.  

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jul 2015 14:22:01 -0400

The architecture does not have a proxy.  It only has Clients, who may be 
acting on behalf of applications.  Those applications are not consider, 
by the I2RS system, to be I2RS Clients.

Secondary identity is not a full proxy mode.  secondary identities are 
not authenticated.  They do not have priorities.  They are included in 
the architecture to ease attribution.

So no, if A and B are applications, working through a common I2RS 
client, then their operations are handled by the client.  The 
requirements only call for the client priority to be assigned to those 
operations.

As a nice-to-have, allowing clients to specify different priorities for 
different operations is acceptable.  But it is not necessary.  Remember 
that even with different priorities, such collisions are considered 
errors.  Priority is for giving predictable results.  It is not expected 
to give the "right" results in terms of application intention.

Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Jul 2015 14:39:51 -0400

Joel,

On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote:
> The architecture does not have a proxy.  It only has Clients, who
> may be acting on behalf of applications.  Those applications are not
> consider, by the I2RS system, to be I2RS Clients.
> 
> Secondary identity is not a full proxy mode.  secondary identities
> are not authenticated.  They do not have priorities.  They are
> included in the architecture to ease attribution.

It is understood that secondary-identity is only a traceability detail.

> requirements only call for the client priority to be assigned to
> those operations.

Given the above, I think it is fair to say that proxies are completely out
of scope.  While this simplifies things, I'm not sure it's the best thing
long-term.

> As a nice-to-have, allowing clients to specify different priorities
> for different operations is acceptable.  But it is not necessary.

As a nice-to-have, I don't believe the architecture clearly explains such an
ability to alter priority.  Please work with Alia to update the architecture
document to clarify this if you believe this property is important.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Jul 2015 20:44:54 +0200

On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote:
 
> different operations is acceptable.  But it is not necessary.

Hm. I thought I understood that the priority is known by the server
and that the authenticated username of the client is used to lookup
the client's priority.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Jul 2015 11:52:55 -0700

> of scope.  While this simplifies things, I'm not sure it's the best thing
The entire northbound API from the client is out of scope.
The secondary identity is just decoration in the standard.

In reality, a broker might be the only client, so its priority
is worthless for resolving conflicts.  The applications using
the broker are the ones needing priority to resolve conflicts.

I can imagine "data-specific controllers" meaning if an app
for vendor X want to write a particular set of data structures,
it goes through the client designed to provide a simplified
(proprietary) API for this purpose.

Since this is all out of scope I suppose it doesn't matter,
but some types of brokers won't work very well.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jul 2015 14:52:48 -0400

In line for emphasis.
Joel

...
> document to clarify this if you believe this property is important.

I don't consider the property of variable priorities important.  You 
raised it in your description.  As far as I am concerned, the 
description Juergen sent to the list (priority is derived by AAA from 
the client identity) meets the requirements.

I am very concerned that as I2RS expresses its requirements, we need to 
be clear which things are requirements, and which things people ahve 
thought of since (such as variable priority) but are not WG requirements.

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 14 Jul 2015 19:05:59 +0000

Jeff, Joel, All

I think declaring  proxy out of I2RS architecture scope is a good thing. Not only this would simplify thing for I2RSs, FWIW it would allow for a single I3RS client to support arbitrary hierarchies of applications.

Igor

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, July 14, 2015 2:40 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt

Joel,

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Jul 2015 12:08:00 -0700

> but some types of brokers won't work very well.

Actually, if there is only 1 client then priority is irrelevant and
the broker will resolve all collisions.  If a broker is not the only client
then its priority is set to the best needed by all the apps using
the broker.

Probably best to just wait and see if a standard broker is ever needed.
I suspect proprietary systems will just add extra parameters
and get around the standard, no matter what WG decision is
getting in the way.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 13 Jul 2015 19:34:42 -0400

Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 13 Jul 2015 19:48:43 -0400

Joel,

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Jul 2015 16:54:44 -0700

> maintain multiple identities to have distinct priorities in the proxy case.
But the secondary identity is just extra meta-data to be stored by
the agent.  If there is a priority associated with each secondary client
then that becomes the client-id.

The design does not directly support different priorities per broker.
The broker needs to pretend to be different clients, and each session
will have a different client-id and priority.  This is non-optimal but not
broken.

-- Jeff

Andy

---

From: "Russ White" <[email-masked]>
Date: Tue, 21 Jul 2015 05:34:16 -0400

> The broker needs to pretend to be different clients, and each session will
> have a different client-id and priority.  This is non-optimal but not broken.

And it's much simpler to implement. It would leave proxies out of scope while allowing those who want to implement proxies a way to do so. In short -- this seems like a good solution.

Russ