"Susan Hares" <[email protected]> wrote: > Martin: > > > > I'm pulling your questions to the top of this email. > > > > Question 1: Ok. Just to make sure I understand this correctly - these > topology models are intended to be I2RS-specific, and they cannot be used > for any other purpose. If anyone needs a general topology model outside of > the I2RS protocol, they will have to design their own model. Is this > correct? > > > > Response 1: Not really.
Ok, so are you saying that the models are in fact generic, and can be used outside of I2RS? I.e., they *can* be used with the normal configuration datastores? > Most of the topology models I have seen abide by the concepts found in the > I2RS topology model. See the diagram below. The 6 differences for > security listed in my draft are: 1) different mandatory transport for > NETCONF (use RFC7895), 2) support for priority for write conflicts plus > secondary opaque identifier for tracing, 3) optional insecure protocol, 4) > different data store, 5) different validations for data store(optional), > and 6) different NACM policy (optional) plus backend policy (to/from routing > protocols, to/from system). Using RESTCONF (which is fine as is) is an > option that I suspect most Topology models will use. > > > > The current topology models implemented tend to 1) use RESTCONF, 2) use > read-only and do not support tracing, 3) do not allow insecure protocols, > and 4) operate as a different data store (that is they load from internal > protocols), and 6) may use different NACM policy (for nodes) and provide > some logic for back-end policy. What needs to be refined is the > client-write Topology models based on the I2RS Control Plane datastore (e.g. > or read-data datastore or write data datastore) . This concept is coming > from the netmod working group > draft-ietf-netmod-ietf-revised-datastores-00.txt. The netmod WG has cycled > on many different ways to handle I2RS ephemeral data store, and settled on > this proposal. Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly work-in-progress, and (2) none of the topology drafts reference draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a solution in that draft, it is not very clear to the reader. > Questions 2: To me, it feels weird that a model that is designed solely for > the I2RS protocol is published *before* the details of the I2RS protocol are > defined. But it this is what the WG wants, then a note that explains this > would be useful. I assume that the idea is that vendors will use some > proprietary mechanism for now. > > > > Response: Due to the wide spread use of the topology models, the I2RS WG > passed WG LC on these YANG models and Benoit Claise review felt it was ok. Since the documents don't mention it, I think that some people might have missed the fact that these models are intended to be used solely for the I2RS protocol - if that is correct; I must admit that I am a bit confused at this point. > The benefit in this approach is that the main structures are stable. The > deficit is that adding the I2RS protocol definitions could cause changes. > The I2RS protocol depends on the revised data store model > (draft-ietf-netmod-revised-datastores, the revised NACM > (draft-ietf-netconf-rfc6536bis-00.txt, the advances in the notification and > pub/sub solutions, and proposals for I2RS protocol implementation in NETCONF > and RESTCONF. I have individual proposal for the I2RS protocol (get-data > datastore and write-data datastore) that I would like some private review of > these proposals prior to sending them to NETCONF. /martin > > > > Cheerily, > > Sue Hares > > > > part4 > > > > > > -----Original Message----- > From: Martin Bjorklund [mailto:[email protected]] > Sent: Monday, January 23, 2017 1:47 PM > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > "Susan Hares" < <mailto:[email protected]> [email protected]> wrote: > > > Martin: > > > > > > Answers inline. > > > > > > -----Original Message----- > > > From: i2rs [ <mailto:[email protected]> mailto:[email protected]] > On Behalf Of Martin > > > Bjorklund > > > Sent: Monday, January 23, 2017 10:32 AM > > > To: <mailto:[email protected]> [email protected] > > > Cc: <mailto:[email protected]> [email protected]; > <mailto:[email protected]> > [email protected]; > > > <mailto:[email protected]> > [email protected]; <mailto:[email protected]> > [email protected]; > > > <mailto:[email protected]> > [email protected]; <mailto:[email protected]> [email protected] > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > "Susan Hares" < <mailto:[email protected]> [email protected]> wrote: > > > >> Martin: > > > >> > > > >> > > > >> > > > >> Thank you for your insightful questions. My answer to your > > > >> questions come from my understanding of the > > > >> draft-ietf-netmod-revised-datastores-00 > > > and > > > >> discussions with that design team at IETF 97. We have been moving > many > > > >> things in parallel at the IETF rather than do single threaded work. > The > > > >> Topoology work was completed 1 year in advance of the > > > >> draft-ietf-netmod-revised-datastores-00.txt. > > > > > > >Right; this is why I think an additional note in these modules are > > > necessary. If you just read these topoly drafts, you will find a > > > normal YANG module that has a "config true" subtree. > > > >Without additional guidance, it is not clear that these data models > > > >"do not > > > utilize the configuration data store" (if this is true). > > > > > > Sue: Sounds like a good idea. I'll suggest this to the authors as the > > > document shepherd. > > > > > > >> #1) model's nodes are "config true", and that "The YANG module > > > >> defined in this memo is designed to be accessed via the NETCONF > > > >> protocol". If it is true that these data models do not utilize the > > > >> configuration data stores, what does the "server-provided" leaf, > > > >> and the text about > > > "client-configured" > > > >> in section 4.4.10 of draft-ietf-i2rs-yang-network-topo refer to? > > > >> > > > >> If the server-provided leaf is true, it indicates that the data is > > > >> populated by the I2RS Agent (aka netconf server) > > > > > > >Doesn't this procedure involve the normal configuration data stores? > > > >If it does, I think we're good. If it doesn't, I think the > > > >additional note > > > should be added. > > > > > > Sue: The model is in the I2RS control plane data store. According to > > > draft-ietf-netmod-revised-datatstores-00.txt this is note the normal > > > configuration data store. > > > > Ok. Just to make sure I understand this correctly - these topology models > are intended to be I2RS-specific, and they cannot be used for any other > purpose. If anyone needs a general topology model outside of the I2RS > protocol, they will have to design their own model. Is this correct? > > > > > Does a note in the text plus a note at the beginning of the data model > > > suffice? > > > > To me, it feels weird that a model that is designed solely for the I2RS > protocol is published *before* the details of the I2RS protocol are defined. > But it this is what the WG wants, then a note that explains this would be > useful. I assume that the idea is that vendors will use some proprietary > mechanism for now. > > > > > > > >> rather than the I2RS Client (aka > > > >> netconf client). The I2RS architecture has aligned the two > > > architecture > > > >> concepts so the I2RS protocol is designed to be a re-use protocol > > > >> for the NETCONF protocol and the RESTCONF protocols as its message > > > >> transport protocols. > > > >> > > > >> draft-ietf-netmod-revised-datastores-00 states the following three > > > >> suggestions for supporting different datastores: > > > >> > > > >> > > > >> o For systems supporting <intended> or <applied> configuration > > > >> > > > >> datastores, the <get-config/> operation may be used to > > > >> retrieve > > > >> > > > >> data stored in these new datastores. > > > >> > > > >> > > > >> > > > >> o A new operation should be added to retrieve the operational > > > >> state > > > >> > > > >> data store (e.g., <get-state/>). An alternative is to define > > > >> a > > > >> > > > >> new operation to retrieve data from any datastore (e.g., > > > >> > > > >> <get-data> with the name of the datastore as a parameter). > > > >> In > > > >> > > > >> principle <get-config/> could work but it would be a > > > >> confusing > > > >> > > > >> name. > > > >> > > > >> > > > >> > > > >> o The <get/> operation will be deprecated since it returns data > > > >> from > > > >> > > > >> two datastores that may overlap in the revised datastore model. > > > >> > > > >> > > > >> > > > >> Based on this input, the I2RS ephemeral control plane data store > > > >> should use a "get-data I2RS-ephemeral" to get data from the I2RS > > > ephemeral data store > > > >> (CT, RW). To retrieve information from the applied configuration data > > > >> store, the "get-config" may be used. To retrieve state from the > > > >> operational state "get-state" should be used. > > > >> > > > >> > > > >> 2) Your suggestion to add another note about configuration true > > > >> > > > >> The config "true" is being implemented as the > > > >> draft-ietf-netmod-revised-datastores-00 suggests in section 5 (see > > > diagram). > > > >> It is just in a different data store. Where and how the data store > > > >> information is stored, is unclear to me at this time. Where do you > > > >> think it belongs? > > > > > > > I always thought that the topology models could be written to > > > > through the > > > normal configuration data stores, in which case the server would set > > > the "server-provided" leaf to "false". It seems that you have some > > > other mechanism in mind? > > > > > > The design team for drat-ietf-netmod-revised-datastores-00.txt > > > indicated that the client written topology with "server-provided" leaf set > to "false" > > > is written in the I2RS Control Plane data store. > > > > Ok. As you might know, I am the editor for > drat-ietf-netmod-revised-datastores-00, and thus part of the design team, > and I haven't seen any discussion about this. Was it discussed on the I2RS > ML? > > > > > > /martin > > > > > > > An I2RS implementation > > > then combines the I2RS Control Plane data store with the intended > > > configuration data store (based on internal configuration knobs) and > > > installs this in a node. A client can query the topology data nodes > > > in the applied configuration data store. The response giving the > > > topology nodes will indicate that a dynamic control plane protocol > inserted these nodes. > > > > > > I am only trying to interpret the netmod design and align the I2RS > > > data models (topology, RIB, FB-RIB) to this design. > > > > > > Thank you for your suggestions on the data model. > > > > > > Sue Hares > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > 3) implementations > > > > > > > > > > > > > > > > Right now, the ODL implementation can utilize "get-config" to obtain > > > > the I2RS topology model since the I2RS topology database has no > > > > equivalent in the intended config. After the > > > > draft-ietf-netmod-revised-datastore is implemented, the "get-config" > > > > will return from the applied configuration the Topology model with > > > > an > > > indication that it is dynamic (see > > > > draft-ietf-netmod-revised-datastores-00.txt section 8. The ODL > > > > implementation can simply augment its current get-config with an > > > indication > > > > that the topology model is a "dynamic" data store. > > > > > > > > > > > > > > > > As another example, my understanding is that a change to the ConfD > > > > implementation would be to allow a "get-data" and "write-data" that > allows > > > > the specification of a data store such as the I2RS data store. A > > > > get-config of the applied data store should have a "dynamic" flag > > > > for the topology database. > > > > > > > > > > > > > > > > 4) Notifications - I am unclear how these are tagged to a datastore, > > > > but I am behind on event email. > > > > > > > > > > > > > > > > Cheerily, > > > > > > > > > > > > > > > > Sue > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [ <mailto:[email protected]> mailto:[email protected]] > > > > Sent: Monday, January 23, 2017 6:47 AM > > > > To: <mailto:[email protected]> [email protected] > > > > Cc: <mailto:[email protected]> > [email protected]; > > > > <mailto:[email protected]> > [email protected]; <mailto:[email protected]> > [email protected]; > > > > <mailto:[email protected]> > [email protected]; <mailto:[email protected]> [email protected]; > > > > <mailto:[email protected]> [email protected] > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > "Susan Hares" < < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected]> wrote: > > > > > > > > > Juergen: > > > > > > > > > > > > > > > > > > Let's focus on your second point. The topology drafts are I2RS > > > > > drafts > > > > > > > > > designed for the I2RS ephemeral control plane data store. How can > > > these > > > > be > > > > > > > > > generic YANG modules when the following is true: > > > > > > > > > > > > > > > > > > 1) I2RS Data models do not utilize the configuration data store, > > > > > > > > > > > > > > > > This was not clear to me. I note that the data model's nodes are > > > > "config true", and that "The YANG module defined in this memo is > > > > designed to be accessed via the NETCONF protocol". > > > > > > > > > > > > > > > > If it is true that these data models do not utilize the > > > > configuration data stores, what does the "server-provided" leaf, and > > > > the text about "client-configured" in section 4.4.10 of > > > > draft-ietf-i2rs-yang-network-topo refer to? > > > > > > > > > > > > > > > > If in fact this is correct, I think it would be helpful if a note > > > > was added to the YANG modules, that explains that these models are > > > > not supposed to be implemented in the same way as other "config > > > > true" data models. In the best of worlds it would also describe how > > > > they are supposed to be implemented (but I assume that this is up to > > > > each vendor > > > for now). > > > > > > > > > > > > > > > > I also note that it is not clear how such models would be advertised > > > > by a NETCONF server. > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I2RS Data Models do not require the same validation as > > > > > > > > > configuration data store, > > > > > > > > > 3) I2RS Data models require the use of priority to handle the > > > > > > > > > multi-write contention problem into the I2RS Control Plane data > > > > > store, > > > > > > > > > 4) I2RS require TLS with X.509v3 over TCP for the > > > > > > > > > mandatory-to-implement transport, > > > > > > > > > > > > > > > > > > Do you disagree with draft-ietf-netmod-revised-datastores? If so, > > > > > > > > > the discussion should be taken up with netmod WG list. > > > > > > > > > Do you disagree with i2rs-protocol-security-requirements? That > > > > > issue > > > > > > > > > is closed based on IESG approval. > > > > > > > > > > > > > > > > > > Sue Hares > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Juergen Schoenwaelder > > > > > > > > > [ < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> > mailto:[email protected]] > > > > > > > > > Sent: Monday, January 23, 2017 3:39 AM > > > > > > > > > To: Susan Hares > > > > > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > > > > < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> > [email protected]; < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> [email protected]; > > > > > > > > > < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected] > > > > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > > > Susan, > > > > > > > > > > > > > > > > > > I consider tagging a YANG object statically and universally in the > > > > > > > > > data model as "does not need secure communication" fundamentally > > > > > > > > > flawed; I am not having an issue with insecure communication in > > > > > certain > > > > deployment contexts. > > > > > > > > > > > > > > > > > > The topology drafts are regular generic YANG models that just > > > > > happen > > > > > > > > > to be done in I2RS - I believe that using the generic YANG > > > > > security > > > > > > > > > guidelines we have is good enough to progress these drafts. > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote: > > > > > > > > > > Juergen: > > > > > > > > > > > > > > > > > > > > I recognize that dislike insecure communication. You made a > > > > > > similar > > > > > > > > > > comment during the WG LC and IETF review of > > > > > > > > > > draft-ietf-i2rs-protocol-security-requirements. However, the > > > > > > > > > > draft-ietf-i2rs-protocol-security-requirements were passed by > > > > > > the > > > > > > > > > > I2RS WG and approved by the IESG for RFC publication and it > > > > > > contains > > > > > > > > > > the non-secure communication. The mandate from the I2RS WG for > > > > > > this > > > > > > > > > > shepherd/co-chair is clear. > > > > > > > > > > > > > > > > > > > > As the shepherd for the topology drafts, I try to write-up > > > > > > something > > > > > > > > > > that might address Kathleen's Moriarty's concerns about the > > > > > > topology > > > > > > > > > > draft's security issues about privacy and the I2RS ephemeral > > > > > > control > > > > > > > > > > plane > > > > > > > > > data > > > > > > > > > > store. I welcome an open discussion on my ideas > > > > > > > > > > ( > > > > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-cons > > > > > > id > > > > > > er> > > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider> > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider). > > > > > > > > > The > > > > > > > > > > yang doctor's YANG security consideration template > > > > > > > > > > ( < <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> > > > > <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and > > > > > > > > > > the privacy related RFCs (RFC6973) note that some information is > > > > sensitive. > > > > > > > > > > Hopefully, this document extends these guidelines to a new data > store. > > > > > > > > > > > > > > > > > > > > > > > Cheerily, > > > > > > > > > > Sue Hares > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Juergen Schoenwaelder > > > > > > > > > > [ < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> > mailto:[email protected]] > > > > > > > > > > Sent: Thursday, January 19, 2017 10:34 AM > > > > > > > > > > To: Susan Hares > > > > > > > > > > Cc: 'Kathleen Moriarty'; 'The IESG'; > > > > > > > > > > < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> > [email protected]; < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> [email protected]; > > > > > > > > > > < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected] > > > > > > > > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > > > > > For what it is worth, I find the notion that data models may be > > > > > > > > > > written for a specific non-secure transport plain broken. There > > > > > > is > > > > > > > > > > hardly any content of a data model I can think of which is > > > > > > generally > > > > > > > > > > suitable for insecure transports. > > > > > > > > > > > > > > > > > > > > Can we please kill this idea of _standardizing_ information that > > > > > > is > > > > > > > > > > suitable to send over non-secure transports? I really do not see > > > > > > how > > > > > > > > > > the IETF can make a claim that a given piece of information is > > > > > > never > > > > > > > > > > worth protecting (= suitable for non-secure transports). > > > > > > > > > > > > > > > > > > > > Note that I am fine if in a certain trusted tightly-coupled > > > > > > > > > > deployment information is shipped in whatever way but this is > > > > > > then a > > > > > > > > > > property of the _deployment_ and not a property of the > _information_. > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > > On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote: > > > > > > > > > > > Kathleen: > > > > > > > > > > > > > > > > > > > > > > I have written a draft suggesting a template for the I2RS YANG > > > > > > > > > > > modules > > > > > > > > > > which are designed to exist in the I2RS Ephemeral Control Plane > > > > > > data > > > > store > > > > > > > > > > (configuration and operational state). > > > > > > > > > > > > > > > > > > > > > > Draft location: > > > > > > > > > > > > > > > > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-co > > > > > > > ns > > > > > > > ide> > > > > <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside> > https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-conside > > > > > > > > > > > r/ > > > > > > > > > > > > > > > > > > > > > > I would appreciate an email discussion with the security ADs, > > > > > > > > > > > OPS/NM ADs, > > > > > > > > > > and Routing AD (Alia Atlas). I agree that this I2RS YANG data > > > > > > model > > > > > > > > > > (L3) and the base I2RS topology model should both provide > > > > > > updated > > > > > > > > > > YANG Security Considerations sections. I would appreciate if > > > > > > Benoit > > > > > > > > > > or you hold a discuss until we sort out these issues. > > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > > Sue > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Kathleen Moriarty [ > > > > > > > < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> > mailto:[email protected]] > > > > > > > > > > > Sent: Wednesday, January 18, 2017 9:44 PM > > > > > > > > > > > To: The IESG > > > > > > > > > > > Cc: < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> > [email protected]; < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> [email protected]; > > > > > > > > > > > < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected]; > > > > < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected]; < <mailto:[email protected]> > mailto:[email protected]> > > > > <mailto:[email protected]> [email protected] > > > > > > > > > > > Subject: Kathleen Moriarty's No Objection on > > > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > > > > > > > > > > > > > > > > > Kathleen Moriarty has entered the following ballot position > > > > > > > for > > > > > > > > > > > draft-ietf-i2rs-yang-l3-topology-08: No Objection > > > > > > > > > > > > > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > > > > to > > > > > > > > > > > all email addresses included in the To and CC lines. (Feel > > > > > > > free to > > > > > > > > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please refer to > > > > > > > > > > > < <https://www.ietf.org/iesg/statement/discuss-criteria.html> > https://www.ietf.org/iesg/statement/discuss-criteria.html> > > > > <https://www.ietf.org/iesg/statement/discuss-criteria.html> > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found > here: > > > > > > > > > > > > > > > > > > <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topo > > > > > > > lo > > > > > > > gy/> > > > > <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > -- > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > COMMENT: > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > -- > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > I agree with Alissa's comment that the YANG module security > > > > > > > > > > > consideration > > > > > > > > > > section guidelines need to be followed and this shouldn't go > > > > > > forward > > > > > > > > > > until that is corrected. I'm told it will be, thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > i2rs mailing list > > > > > > > > > > > < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected] > > > > > > > > > > > < <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs> > > > > <https://www.ietf.org/mailman/listinfo/i2rs> > 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/> http://www.jacobs-university.de/> > > > > <http://www.jacobs-university.de/> http://www.jacobs-university.de/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > 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/> > http://www.jacobs-university.de/> > > > > <http://www.jacobs-university.de/> http://www.jacobs-university.de/> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > i2rs mailing list > > > > > > > > > < <mailto:[email protected]> mailto:[email protected]> > <mailto:[email protected]> [email protected] > > > > > > > > > < <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs> > > > > <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > <mailto:[email protected]> [email protected] > > > <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
