Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

["Susan Hares" <[e-mail]>]

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.  

 

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.   

 

 

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.
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.   

 

Cheerily, 

Sue Hares 

 

part4

 

 

-----Original Message-----
From: Martin Bjorklund [mailto:[e-mail]] 
Sent: Monday, January 23, 2017 1:47 PM
To: [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

 

"Susan Hares" < <mailto:[e-mail]> [e-mail]> wrote:

> Martin: 

> 

> Answers inline. 

> 

> -----Original Message-----

> From: i2rs [ <mailto:[e-mail]> mailto:[e-mail]]
On Behalf Of Martin 

> Bjorklund

> Sent: Monday, January 23, 2017 10:32 AM

> To:  <mailto:[e-mail]> [e-mail]

> Cc:  <mailto:[e-mail]> [e-mail];
<mailto:[e-mail]>
[e-mail];

>  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]>
[e-mail]; 

>  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]> [e-mail]

> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on

> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> 

> "Susan Hares" < <mailto:[e-mail]> [e-mail]> 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:[e-mail]> mailto:[e-mail]]

> > Sent: Monday, January 23, 2017 6:47 AM

> > To:  <mailto:[e-mail]> [e-mail]

> > Cc:  <mailto:[e-mail]>
[e-mail];

> >  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]>
[e-mail]; 

> >  <mailto:[e-mail]>
[e-mail];  <mailto:[e-mail]> [e-mail]; 

> >  <mailto:[e-mail]> [e-mail]

> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on

> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> > 

> >  

> > 

> > Hi,

> > 

> >  

> > 

> > "Susan Hares" < < <mailto:[e-mail]> mailto:[e-mail]>
<mailto:[e-mail]> [e-mail]> 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:[e-mail]>
mailto:[e-mail]>

> >  <mailto:[e-mail]>
mailto:[e-mail]]

> > 

> > > Sent: Monday, January 23, 2017 3:39 AM

> > 

> > > To: Susan Hares

> > 

> > > Cc: 'Kathleen Moriarty'; 'The IESG';

> > 

> > >  < <mailto:[e-mail]>
mailto:[e-mail]>

> >  <mailto:[e-mail]>
[e-mail];  < <mailto:[e-mail]>
mailto:[e-mail]> 

> >  <mailto:[e-mail]> [e-mail];

> > 

> > >  < <mailto:[e-mail]> mailto:[e-mail]>
<mailto:[e-mail]> [e-mail]

> > 

> > > 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:[e-mail]>
mailto:[e-mail]>

> >  <mailto:[e-mail]>
mailto:[e-mail]]

> > 

> > > > Sent: Thursday, January 19, 2017 10:34 AM

> > 

> > > > To: Susan Hares

> > 

> > > > Cc: 'Kathleen Moriarty'; 'The IESG';

> > 

> > > >  < <mailto:[e-mail]>
mailto:[e-mail]>

> >  <mailto:[e-mail]>
[e-mail];  < <mailto:[e-mail]>
mailto:[e-mail]> 

> >  <mailto:[e-mail]> [e-mail];

> > 

> > > >  < <mailto:[e-mail]> mailto:[e-mail]>
<mailto:[e-mail]> [e-mail]

> > 

> > > > 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:[e-mail]>
mailto:[e-mail]>

> >  <mailto:[e-mail]>
mailto:[e-mail]]

> > 

> > > > > Sent: Wednesday, January 18, 2017 9:44 PM

> > 

> > > > > To: The IESG

> > 

> > > > > Cc:  < <mailto:[e-mail]>
mailto:[e-mail]>

> >  <mailto:[e-mail]>
[e-mail];  < <mailto:[e-mail]>
mailto:[e-mail]> 

> >  <mailto:[e-mail]> [e-mail];

> > 

> > > > >  < <mailto:[e-mail]> mailto:[e-mail]>
<mailto:[e-mail]> [e-mail];

> > < <mailto:[e-mail]> mailto:[e-mail]>
<mailto:[e-mail]> [e-mail];  < <mailto:[e-mail]>
mailto:[e-mail]> 

> >  <mailto:[e-mail]> [e-mail]

> > 

> > > > > 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:[e-mail]> mailto:[e-mail]>
<mailto:[e-mail]> [e-mail]

> > 

> > > > >  < <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: [phone]         Campus Ring 1 | 28759 Bremen |
Germany

> > 

> > > > Fax:   [phone]         < <
<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: [phone]         Campus Ring 1 | 28759 Bremen | Germany

> > 

> > > Fax:   [phone]         < < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>

> >  <http://www.jacobs-university.de/> http://www.jacobs-university.de/>

> > 

> > > 

> > 

> > > _______________________________________________

> > 

> > > i2rs mailing list

> > 

> > >  < <mailto:[e-mail]> mailto:[e-mail]>
<mailto:[e-mail]> [e-mail]

> > 

> > >  < <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:[e-mail]> [e-mail]

>  <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

>