The text I comment to says "individual ephemeral configuration changes" - I was not able to infer from this that it was supposed to imply "individual I2RS clients".
/js On Wed, Jul 20, 2016 at 01:41:26PM +0200, jmh.direct wrote: > > The reason I referred to individual I2RS clients is that different clients > have different priorities. The previous text referred to "ephemeral > priority" which needed clarification. > I referred to changes because the only time priority is relevant is when > something changes. > And the proposed new text loses the emphasis on associating a priority with > local config. > Yours,Joel > > Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone > -------- Original message --------From: Juergen Schoenwaelder > <[email protected]> Date: 7/20/16 1:19 PM (GMT+01:00) > To: Susan Hares <[email protected]> Cc: "'Joel M. Halpern'" > <[email protected]>, 'Joe Clarke' <[email protected]>, 'Russ White' > <[email protected]>, [email protected] Subject: Re: [i2rs] Comments on > Ephemeral-REQ-07 (local config vs. ephemeral) > What is the purpose of the word 'individual' in the sentence? Why does > it talk about 'changes'? Isn't it simply the data that takes > precedence? Or is the idea to have this linked to changes of data, > i.e., how a change was carried out? > > I actually find the text related to this in RFC 7921 more helpful > since RFC 7921 provides more insight that priority is associated > with an I2RS client. Perhaps Req-07 should just say: > > Req-07: The I2RS protocol MUST support a priority mechanism to > resolve any possible conflicts with local configuration as described > in RFC 7921. > > This way we avoid having multiple definitions that may interact in > weird ways. (This might also apply to other requirements where perhaps > a simple pointer to RFC 7921 would be easier and safer than attempts > to reformulate things.) > > /js > > PS: I do not want to further complicate things so please feel free > to ignore this. > > On Wed, Jul 20, 2016 at 06:49:27AM -0400, Susan Hares wrote: > > I'm fine with this revision. Anyone else wish to change this version? > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern > > Sent: Wednesday, July 20, 2016 5:25 AM > > To: Joe Clarke; Susan Hares; 'Russ White'; [email protected] > > Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. > > ephemeral) > > > > That wording may well lead readers to think that Ephemeral configuration, > > considered as a whole, has a priority. Since that is not true, I would like > > to further refine this. How about: > > > > Req-07: Local configuration MUST have a priority that is comparable with the > > I2RS Agent priority for making changes. This priority will determine > > whether local configuration changes or individual ephemeral configuration > > changes take precedence. The I2RS protocol MUST support his mechanism. > > > > Yours, > > Joel > > > > On 7/20/16 4:05 AM, Joe Clarke wrote: > > > On 7/20/16 03:42, Susan Hares wrote: > > >> Joe: > > >> Yes - you are correct. Can you help me state this requirement -07 > > >> better? > > > > > > What about: > > > > > > Ephemeral-REQ-07: Ephemeral configuration and local configuration MUST > > > each have a priority. This priority will determine whether ephemeral > > > configuration or local configuration take precedence. The I2RS > > > protocol MUST support this mechanism. > > > > > > Is this clear and correct enough? > > > > > > Joe > > > > > >> > > >> Sue > > >> > > >> -----Original Message----- > > >> From: Joe Clarke [mailto:[email protected]] > > >> Sent: Wednesday, July 20, 2016 3:40 AM > > >> To: Susan Hares; 'Russ White'; [email protected] > > >> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. > > >> ephemeral) > > >> > > >> On 7/20/16 02:18, Susan Hares wrote: > > >>> <WG hat off> <author hat on> > > >>> > > >>> Here's text that might replace it: > > >>> > > >>> Ephemeral-REQ-07: Ephemeral configuration state MUST be able to set > > >>> a priority on local configuration and ephemeral state. Based on > > >>> this priority implementations MUST be able to provide a mechanism to > > >>> choose which takes precedence. The I2RS Protocol MUST be able to > > >>> support this > > >> mechanisms. > > >>> > > >>> Any thoughts? > > >> > > >> I'm a bit confused by the first sentence. I think what you're > > >> stating is that both ephemeral and local configurations MUST have a > > priority. > > >> This priority will determine whether ephemeral configuration or local > > >> configuration take precedence. The I2RS protocol MUST support this > > >> mechanism. > > >> > > >> Am I correct in my interpretation? > > >> > > >> Joe > > >> > > >>> > > >>> Sue > > >>> > > >>> -----Original Message----- > > >>> From: Russ White [mailto:[email protected]] > > >>> Sent: Wednesday, July 20, 2016 2:09 AM > > >>> To: 'Joe Clarke'; 'Susan Hares'; [email protected] > > >>> Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. > > >>> ephemeral) > > >>> > > >>> > > >>> (wg chair hat off) -- > > >>> > > >>>> I think the idea of extending I2RS priority to local config > > >>>> operators > > >>> (e.g., CLI) > > >>>> will still work. Let's take knob 1. Knob 1 is kind of like the > > >>>> on/off > > >>> switch. If I > > >>>> don't want I2RS to have any effect on operational state, I'd have > > >>>> this > > >>> off. In > > >>>> the I2RS priority case, by default my local config could will have > > >>>> the > > >>> highest > > >>>> priority (let's say that's 255 to make it concrete). In this case > > >>>> no > > >>> ephemeral > > >>>> config can win. > > >>> > > >>> I wanted to extend Joe's remarks a bit... On reflection, I actually > > >>> think having priority + "this wins" bits is rather confusing, and > > >>> opens the door to all sorts of strange behavior. Say I have two > > >>> items thus -- > > >>> > > >>> Local config item -- priority 100 > > >>> I2RS config item -- priority 200, don't overwrite bit set > > >>> > > >>> If the higher priority is supposed to win, then which item should > > >>> the operator find in the resulting running config? Should it be the > > >>> I2RS version, because the priority is higher, or the local config, > > >>> because the "don't overwrite" bit is set? There doesn't seem to be > > >>> any clear way to interpret such a situation. > > >>> > > >>> It's better to have a single "thing" that determines which > > >>> configuration among many wins, rather than two. > > >>> > > >>> -r > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > i2rs mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > 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/> > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- 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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
