Andy, On Mon, Jul 13, 2015 at 06:04:15PM -0700, Andy Bierman wrote: > OK -- it is becoming clearer now -- in order to support a broker, the > priority is saved with the node, not the client.
FWIW, I think this is likely the case. However, the architecture authors seem to disagree. > 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. 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. > 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> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
