Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 28 July 2016 23:20 UTC
Return-Path: <jmh@joelhalpern.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 B4DCC12D988 for <i2rs@ietfa.amsl.com>; Thu, 28 Jul 2016 16:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 gK5Ad3KAEkpw for <i2rs@ietfa.amsl.com>; Thu, 28 Jul 2016 16:20:53 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D318D12D975 for <i2rs@ietf.org>; Thu, 28 Jul 2016 16:20:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BF0F41C0139; Thu, 28 Jul 2016 16:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1469748053; bh=jRxgajDYTzroSVQcolge/sncZpbCUIwOW6P9Xj/ksu4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pkH1fdE3FBbjBX1SsJTAELoVtY1EO47J+og7SRRIVbNiukYJhHc23sUDxxrtmLyjk vWB63ebxNB9kTXzce+ZNJ3q8OQ7QWUY9DZ5KZTlFNUwkeSw0+rCwkMSuhaUcrmzoGD MXbZIHM+ig2MKJm7hNSgYMR3LqZPnDfyV4zfZlfE=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 53EA01C0052; Thu, 28 Jul 2016 16:20:51 -0700 (PDT)
To: Susan Hares <shares@ndzh.com>, 'Yasuhiro Ohara' <yasu@nttv6.jp>, andy@yumaworks.com
References: <eniiljkadm7ncjq8p2nkjn9d.1469003679596@email.android.com> <1d3b708a-f8f3-b1e1-cf1d-bc09a87dba4f@cisco.com> <CABCOCHRA1_ZGChup9UT=NamPX2gPd88e6MtW8MBXB9_1Bw915A@mail.gmail.com> <20160720.131214.916054873597495950.yasu@nttv6.jp> <44f801d1e911$e4d1b700$ae752500$@ndzh.com> <87bb4a02-1314-6aae-e15b-10e77bdedc78@joelhalpern.com> <484801d1e925$39ae96e0$ad0bc4a0$@ndzh.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <757ad29d-f87d-1f24-d6f9-649e5f364593@joelhalpern.com>
Date: Thu, 28 Jul 2016 19:20:02 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <484801d1e925$39ae96e0$ad0bc4a0$@ndzh.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/0ahClM-rRfOlWFFtX9G_1sFfMos>
Cc: rwilton@cisco.com, i2rs@ietf.org, jclarke@cisco.com, 7riw77@gmail.com
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
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: Thu, 28 Jul 2016 23:20:57 -0000
Thanks Sue. Just to confirm, I agree that there is no need to change the requirement. Yours, Joel On 7/28/16 7:10 PM, Susan Hares wrote: > Joel: > > You are 100% on the following points. > > 1) The requirements do not mandate re-evaluation after a client's priority > changes. > 2) The requirements do not made storing the client-ID indirectly. > 3) Requirements permit re-evaluation of local config with relative priority, > but do not > > Yasuhiro pointed out what would happen if there was no re-evaluation. > Implementations may - as I did, chose to re-evaluate priority compared to > the local configure. > > I believe that implementation experience will provide us with insights on > scaling. I am providing initial coding structures, but I have not run the > code with 5K, 10K or 100K results to see what happens. As an implementer, I > am just providing information. > > As WG Chair, I am not recommending we change the requirements. We had a > lengthy discussion that came to this conclusion. I am allowing over the > weekend in case someone wants to comment before we do the final 1 week WG LC > for changed text. > > Sue Hares > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, July 28, 2016 6:40 PM > To: Susan Hares; 'Yasuhiro Ohara'; andy@yumaworks.com > Cc: rwilton@cisco.com; i2rs@ietf.org; jclarke@cisco.com; 7riw77@gmail.com > Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. > ephemeral) > > As a minor point, and assuming I have understood the quesiton, I do not > believe the requirements mandate re-evaluation. > > As far as I can tell, we have specified that the priority is that in use at > the time of application of the I2RS request. > And we have permitted the priority to be stored as anb indirect through the > client ID, but we have not required that. > > Thus, an implementation which chooses to use the indirection may shift the > priority associated with an operation. > > It seems to me that this permits reevaluation of relative priority compared > with local config. But does not require it. > And that is the only re-evaluation that is permitted, as there is nothing > else to compare with. > > Yours, > Joel > > On 7/28/16 4:52 PM, Susan Hares wrote: >> Yasuhiro: >> >> <developer hat on> >> In my developer hat, I agree with you and Andy. >> >> As an Implementer I have created a mechanism that will easily >> re-evaluate queue a re-evaluation of all routes which client priority > changes. >> >> Here's the back structure: >> >> Per connection : >> >> Session-id - pointer to structure which has >> 1) customer pointer --> customer-id, priority, opaque id >> (this is part of a list of clients ordered by customer id, >> followed by priority) >> 2) transport pointer ---> transport ID (src >> IP/src-port/dst >> IP/dst-port) >> 3) last rcv action info --> seq #, function > (read/write/rpc) >> 4) last response info --> (read rsp, write rsp, rpc response, >> 5) notification- seq #, function, >> >> Client 1 could have: >> Client-1, 5, xyz >> And have a priority change (due to AAA) to >> Client-1, 3, zzz >> >> My client table would have >> Pointer 1 - Local config, 5, null >> Pointer 2 - client-1, 8, xyz >> Pointer 3 - client-1, 3, zzz >> Pointer 4 - client 3, 6, bbb' >> >> My transport table >> >> >> My session ID table would have >> Entry 1: Customer pointer - pointer 1 >> Transport-pointer - null >> Last action info - null >> Last response info - null >> Last notification - null >> >> Entry 2: Customer pointer - pointer 2 >> Transport pointer - transport-pointer-1 >> Last receive action info - 5, write >> Last response info - 5, write-rsp >> Last notification - 1, notify-rpc >> >> Entry 3: Customer pointer - pointer 3 >> Transport pointer - transport-pointer-1 >> Last action info - 6, write >> Last response info - 6 write-response >> Last notification - 3, notify write >> >> Entry 4: Customer pointer - pointer 4 >> Transport pointer - transport-pointer-2 >> Last receive action info - null >> Last response - null >> Last notify - null >> >> >> Each route has: >> Route (A) >> ---> session-id pointer >> ---> rt_rtc - route change structure >> ---> which has pointer to session ID of client >> requesting change. >> >> If the session-id changes because the customer-id changes, then a >> background process walks the route list comparing customer-pointer, >> and new customer-pointer. If it find a new customer pointer, then it >> places a rt_rtc request structure into the route, and links the route to a >> change structure. If we have 10,000 routes associated with a client, >> then the background process changes the routes in groups - until all >> routes on are processed. >> >> [A million routes could be handled by the I2RS route updates, but the >> processing time would exceed the time for a simple BGP - so I think >> this is not the target for I2RS]. >> >> While this background process is running, if a new route write (rpc or >> write) for a specific route comes - then the route processes the >> comparison with client route. >> The rt_rtc change structure would record two changes: >> a) the initial routes change to new priority >> b) the new routes change via a client-3 for route-id with a higher >> priority, >> then the new route change takes precedence. >> >> The I2RS agent, can respond to the I2RS client-3 that the write succeeds. >> 1) To Entry 4 would add a write sequence #1, response #1] , >> 2) to Entry 2 Notify (sequence #4) to client-1 that its write has been >> overwritten by a higher priority client >> >> I agree that if you do not re-process the routes associated with an >> I2RS client, the priority values are out of sync and some comparison >> fail that should have succeeded. >> >> I disagree with the WG decision to not process priority changes to >> individual routes. If people wanted to indicate that the processing >> of the priority change did not need to be immediately, I think the > background >> process works. If this is what the WG meant, then I think this is >> reasonable. >> >> One thing the text says, is that ephemeral routes are compared with a >> priority, and then ephemeral is compared against Local Configuration. > Your >> assignment illustrates the point, so I did not correct it. >> >> <developer hat off> >> >> <WG chair hat on> >> The WG had a long discussion, and came to agreement on not processing >> past routes. >> However, I am raising the issue for until 8/1/2016 when I will start a >> 1 week WG LC on the changes put in ephemeral state. >> Russ White will judge this WG LC since I am a co-author on the >> ephemeral state draft. >> <WG hat off> >> >> Sue >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Yasuhiro Ohara >> Sent: Wednesday, July 20, 2016 7:12 AM >> To: andy@yumaworks.com >> Cc: rwilton@cisco.com; i2rs@ietf.org; jclarke@cisco.com; >> shares@ndzh.com; 7riw77@gmail.com >> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. >> ephemeral) >> >> >> I think I tend to agree with Andy. >> >> I couldn't read all the draft yet so I may be missing something >> important, please correct me then. >> >> First, I think we definitely is going to need the re-evaluation of all >> routes when the client priority changes. >> (I think this is against the WG's discussion today) >> >> Given that the priority of Local-config: 5 and of Client-A: 8, suppose >> we >> have: >> >> A.B.C.D/M nexthop Y, by Client-A, priority 8 (best) A.B.C.D/M nexthop >> X, by Local-config, priority 5 >> >> then Client-A changed its priority to 3. >> >> If we don't re-evaluate: >> A.B.C.D/M nexthop Y, by Client-A, priority 3 (best) A.B.C.D/M nexthop >> X, by Local-config, priority 5 which is very odd situation to me. >> [Sue: I agree with this point. My solution processes the priority >> change. ] >> >> With re-evaluation: >> A.B.C.D/M nexthop X, by Local-config, priority 5 (best) A.B.C.D/M >> nexthop Y, by Client-A, priority 3 I think this should be the correct > behavior. >> [Sue: I agree with you.] >> >> Similar things happen if we have Client-B with priority 6. >> >> I think we should have the list of clients in the agent. >> Client-A: priority 8 >> Client-B: priority 6 >> >> [Sue: I have listed created a list of clients. See my methodology >> above. ] >> >> Then all the client have to do to change his priority is to let the >> agent know that the change of priority 8->3. >> >> [Sue: You have to know which routes are associated with the client. >> If the client changes the priority, then you have to re-evaluate it. >> If you are gathering a set of changes per route from multiple clients >> or from multiple writes, then the route changes structure could be >> useful. >> >> That will be way much less from the huge traffic that we would be >> needed to change when millions of routes are related to the Client-A. >> [Sue: Here, we never assumed that the client would send the different >> priority. We assumed this priority came from AAA changing the priority. >> Therefore, the real challenge is the processing of the change in >> priority per route. ] >> >> I may be missing the context totally... sorry in the case. >> [Sue: 90% correct, the only thing not aligned with my answer is the >> client ID priority is changed by AAA (radius, diameter or some other AAA > process). >> >> Best regards, >> Yasu >> >> Thank you for the question. >> >> From: Andy Bierman <andy@yumaworks.com> >> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. >> ephemeral) >> Date: Wed, 20 Jul 2016 02:37:51 -0700 >> Message-ID: >> <CABCOCHRA1_ZGChup9UT=NamPX2gPd88e6MtW8MBXB9_1Bw915A@mail.gmail.com> >> >>> Hi, >>> >>> the text in REQ-07 does not say anything about client identity, but >>> Sue's comments in the NETCONF WG meeting indicate that the client ID >>> is saved, not the priority. >>> >>> This does not seem to work if client priority can change. >>> If priority is changed, then it seems that all the overlays affected >>> need to be adjusted so the operational state reflects the new priority. >>> >>> It seems to me that I2RS will require per-node storage of a client ID >>> and a priority to prevent this re-evaluation. >>> However, if the operator changes a client-ID priority they probably >>> want all the nodes re-evaluated. This applies to ephemeral-only, not >>> just local config vs. ephemeral. >>> >>> >>> Andy >>> >>> >>> On Wed, Jul 20, 2016 at 2:18 AM, Joe Clarke <jclarke@cisco.com> wrote: >>> >>>> On 7/20/16 05:10, Robert Wilton -X (rwilton - ENSOFT LIMITED at >>>> Cisco) >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Sorry, but I can't make the I2RS meeting because I'm presenting at >>>>> the end of NETCONF. >>>>> >>>>> I've spoken to Sue and understand that the requirement isn't >>>>> changing here - just the text to describe it. >>>>> >>>>> I think that I'm OK with this new text. >>>>> >>>>> One suggestion: Possibly It might help if the text made it clear >>>>> that the priotiy resolution applies to the complete set of >>>>> ephemeral config vs the complete set of local config. I.e. the >>>>> requirement is not asking for priority resolution between the two >>>>> config sets on a per datanode basis. >>>>> >>>> >>>> Yes, I had assumed that in my text, but I agree, this should be clear. >>>> i, >>>> >>> >>> >>>> Functionally, in my head, I imagine local config to act like an I2RS >>>> client. Clients don't have a per-data node priority. They have an >>>> overall priority. >>>> >>>> Is this consistent with what you're stating here? >>>> >>>> Joe >>>> >>>> >>>>> But I strongly support getting the requirements draft completed, >>>>> and hence I suspect that whatever text that you agree in the 2nd >>>>> I2RS meeting will be fine. >>>>> >>>>> Thanks, >>>>> Rob >>>>> >>>>> >>>>> Sent from my XperiaT tablet >>>>> >>>>> ---- Joe Clarke (jclarke) 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:jclarke@cisco.com] >>>>>> Sent: Wednesday, July 20, 2016 3:40 AM >>>>>> To: Susan Hares; 'Russ White'; i2rs@ietf.org >>>>>> 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:7riw77@gmail.com] >>>>>>> Sent: Wednesday, July 20, 2016 2:09 AM >>>>>>> To: 'Joe Clarke'; 'Susan Hares'; i2rs@ietf.org >>>>>>> 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 >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Robert Wilton
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Andy Bierman
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Russ White
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joel M. Halpern
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Juergen Schoenwaelder
- [i2rs] Comments on Ephemeral-REQ-07 (local config… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Alia Atlas
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Joe Clarke
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Russ White
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Yasuhiro Ohara
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Juergen Schoenwaelder
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Susan Hares
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… jmh.direct
- Re: [i2rs] Comments on Ephemeral-REQ-07 (local co… Juergen Schoenwaelder