Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

Andy Bierman <andy@yumaworks.com> Thu, 18 August 2016 21:28 UTC

Return-Path: <andy@yumaworks.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 D473312D692 for <i2rs@ietfa.amsl.com>; Thu, 18 Aug 2016 14:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 FErEZkBwW6gL for <i2rs@ietfa.amsl.com>; Thu, 18 Aug 2016 14:28:03 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1065C12D675 for <i2rs@ietf.org>; Thu, 18 Aug 2016 14:27:59 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id n59so49755012uan.2 for <i2rs@ietf.org>; Thu, 18 Aug 2016 14:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cmb5wRdyWSG8rsJi7posOxo+bs+6D2e8gwhsAU0rvPU=; b=oEBLfIje99zhArbGQZodrj7vHc3M/G1B225ZsNZdHZcL6xeWbaJ5e0LHk8c6sojYU/ AAkji1cHXAtvjKSEBpgfJDK+tC/jJgs0DeSQizlsEnryYpbqB/p157y/LyXqI2qQ8pB6 rFM7A1+gJPWTXI2cjfmYfkjYZLRsjxWfB6q83AYD4RxlnaABx+AsfFv+N1fT6Jpi4h/L lHpjgcj3EtRA71TgG7Be9HwXmKSHNEQcKGf37mMMC7DtGsvZ+BVCzK/c7LyOA9wGQfbJ UF9+yypLqSLDC5lZKx4JAR2X38wqvfxNXXJ/tNfocytmMO/iXsTx7eTeVpo819FZ+1Ai NOoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cmb5wRdyWSG8rsJi7posOxo+bs+6D2e8gwhsAU0rvPU=; b=QqV1flS7ziVeEpI/50twD3sO3s1/b6TFTimPmq7pw3Z6pJrUwnYB6iQAcR4QSNWkCA pnaXL4QUMkh80rzwxPZD0q2U4WJihJY9lKX6xPw4LuKRzIdgU1Q9n9pTlSRKTrHW+FaE eIJBobgnC+POzFY2bP494q+P7KEq63UvJUcdcaHmPHjfn5YqcJMKzBI+gLpJVsWF/YAc H3N2bUhhJ/KyRFigEwjVl5NIpQWFX66cljO51QG2eXeJsqHd0A+xih9KMVzgwS2ophbL 6z28sm9OJ+dd9LJkBCve61NIyrnshViNSo2tSNYNHJuffHIjqWnnApKakZRKTOUtWWKR qeeQ==
X-Gm-Message-State: AEkoousrtvLQ8m75tpwg63Jqu7XlcwmFzPRJ6dEmmKjqdKzVBCzWGnY2I9H2OEXhu0sUReEqV7gYrHh4Xw6L9A==
X-Received: by 10.31.136.70 with SMTP id k67mr2295893vkd.13.1471555678015; Thu, 18 Aug 2016 14:27:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 14:27:57 -0700 (PDT)
In-Reply-To: <00dc01d1f988$f2cec280$d86c4780$@ndzh.com>
References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <F8C205FB-665C-422C-B991-2F97F75CAE42@cooperw.in> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <CABCOCHS-72KK0VgUARynb_19YLA5oM1g1odSLpezuBrq=+dmqg@mail.gmail.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 18 Aug 2016 14:27:57 -0700
Message-ID: <CABCOCHSwz+6=sJX794Ze79+g8MaZQc4VQAEa2gTs2o2PTo0rEg@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a11440bb674b0c6053a5f418b
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/OBBOQCbIfoMxe5krC5iX5dePoME>
X-Mailman-Approved-At: Fri, 19 Aug 2016 04:02:25 -0700
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, Alissa Cooper <alissa@cooperw.in>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, i2rs-chairs@ietf.org, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, IESG <iesg@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, Joel Halpern <joel.halpern@ericsson.com>, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
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, 18 Aug 2016 21:28:07 -0000

On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> wrote:

> Andy:
>
>
>
> Thank you – I thought it was on whether we could implement insecure
> transport in a Yang module.
>
>
>
> The requirement text you are working with is:
>
>
>
>    SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
>    secure transport and optionally MAY be able to transfer data over a
>    non-secure transport.
>
>
>
I do not understand why approving the ok for non-secure transport for some
> modules means the following to you:
>
>
>
> *“ the IETF needs to agree that there could never possibly be any
> deployment that would not want to allow exposure of the data.*
>
> *Not now. Not 20 years from now.”*
>
>
>


I see your point now.
This draft makes no mention of the YANG data model marking objects that can
be nonsecure.


SEC-REQ-08 is fine.
The other requirement (sorry I don't have the number) is the one that
should be removed.


Andy

I had thought that the security-directorate and other reviewers would look
> at each module that is insecure, and  consider whether it was reasonable
> for the use case at this time.   This is what I understood from Russ
> Housley’s first review of this technology.  Since like you, I believe the
> operator is going to  configure what modules are allowed on systems.   I
> agree that this requirement provides a full scope of the work, but
> implementers will require network operators to configure these features on.
>
>
>
> Sue
>
>
>
>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Thursday, August 18, 2016 2:53 PM
> *To:* Susan Hares
> *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder;
> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas;
> draft-ietf-i2rs-protocol-security-requirements@ietf.org
> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
>
>
> Hi,
>
>
>
> I did not think Juergen's comment was about running code.
>
>
>
> In order for a data node to get the "ok-for-nonsecure-transports" approval
>
> in an IETF module, the IETF needs to agree that there could never possibly
> be
>
> any deployment that would not want to allow exposure of the data.
>
> Not now. Not 20 years from now.
>
>
>
> I can see a vendor making that decision for their own proprietary modules,
>
> but it seems less likely for standard modules.
>
>
>
> Seems like the operator is going to have to configure what is allowed
>
> for nonsecure transport anyway, so just let them decide.
>
> I don't really object to the extension or the requirement.
>
> It doesn't help much but it doesn't hurt much either.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares <shares@ndzh.com> wrote:
>
> Alissa:
>
> Just a little input you may not know.  My background is 15 years
> (1995-2010)  developing a routing/switching platform (denoted as GateD)
> which was sold to over 200 companies.   We developed XML and a binary XML
> based product that configured this product.  It could do 100K configuration
> lines and reboot in less than a second on most hardware.  We also provide
> status messages in secure streams and non-secure streams.    I sold early
> version of this code to companies that Alia has worked for  - so she has
> personal viewed the code.   At the height of our work, our development team
> ran to 50 people which I directed (First as VP of Engineering, and then as
> CTO). It is due to this level of experience that Alia selected me for the
> co-chair.   Russ White has understood Cisco's process, and has also
> directed software development teams for routing.
>
> In order to freshen my direct experience with I2RS on open source work, I
> am working on a publically available work in Quagga based on the confD
> product suggested by Cisco.
>
> In contrast, Juergen is a university professor who has worked on
> proto-types.   He is not working on an implementation.   I hope he will.
>
> I hope you will consider this background in my response to your comments
> below.
>
> Sue
>
>
> -----Original Message-----
> From: Alissa Cooper [mailto:alissa@cooperw.in]
> Sent: Thursday, August 18, 2016 12:54 PM
> To: Joel Halpern
> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;
> draft-ietf-i2rs-protocol-security-requirements@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> COMMENT)
>
> Jumping in here because this is relevant to my DISCUSS, hope nobody minds
> (but if you do, I can go back to the other thread).
>
> >> On Aug 18, 2016, at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com>
> wrote:
> >>
> >> Let me try a different take approach to this particular question.
> >>
> >> Let me start by putting aside the question of where things are marked,
> and come back to that afterwards.
> >>
> >> There are a number of cases that I2RS has been asked to cover of high
> rate telemetry data.  This may be BGP update information, it may be
> frequent information about line card activity.  There are other cases, some
> of which have been documented.
> >>
> >> While not completely insensitive, the operators have made clear that
> they see protecting this data as unnecessary.  While I would hope over time
> to move to a domain where all of it is protect, that is not trivial.  As
> the I2RS Architecture points out, it is expected that what we describe as a
> single I2RS >communication between a client and agent is actually
> associated with multiple channels of communication.
> >>
> >> Now, if you want to say that the I2RS protocol requirements cannot
> allow for unprotected channels, I guess we have disconnect between the IESG
> and the WG.
> >>
> >> If we say that we can allow for unprotected channels, we then get to
> the question of which data can be sent over such channels.  While
> architecturally I agree with Juergen that the model is a bad place to
> specify it, the obverse is also true.  Not having some limits on what can
> be sent unprotected >causes concern about insufficient protection.  If I
> recall correctly, earlier security reviews called us to task for being too
> broad in what we allowed.
> >>
> >> So, if the IESG wants us to just allow it anywhere, because the model
> is an awkward place to define the limitation, I can live with that.  What I
> can't live with is being told both that the model is a bad place to define
> it and that there must be restrictions on what is sent unprotected,
> >> without any proposal on how we are to move forward.
>
> > Thank you Joel, this explanation helps me a lot. I think there is a
> disconnect about how the restrictions are expressed. From reading the email
> traffic about this document, it strikes me that trying to express the
> restrictions programmatically doesn’t make much sense in this case.
> > I agree with Juergen that it will be challenging to make a judgment a
> priori in order to bake a restriction into a data model, because data that
> is considered sensitive enough to warrant a secure transport in one
> deployment may not be considered sensitive in another deployment.
> > So for any data elements where there is any question at all about
> whether they might be sensitive (i.e., any data elements that are not
> already routinely made public),
> > I would expect data model authors to end up indicating that they may be
> sent over either secure or insecure transport, which renders the indication
> not useful.
> > Perhaps it would make more sense then to just enumerate in the text the
> cases that motivate the inclusion of protocol support for insecure
> transport:
> >
> > 1. For conveyance of information that is already routinely made public.
> > 2. For line card activity data where there is no likely upgrade path to
> support secure transports in the foreseeable future.
> >
> > Then the normative requirements would be on clients and agents to use
> secure transports unless those clients and agents are deployed where either
> of the operational circumstances above necessitate otherwise.
> > Alissa
>
> Point 1:
> I disagree with Juergen on the difficulty in specifying the sections of
> the yang modules.  I have provided a suggested solution in:
> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawm
> an-03#section-4.5.2.
>
> Given the mount schema functionality, we can mount ephemeral state module
> which augment non-ephemeral state modules which are "in-secure only".
>
> Point 2:
> I am willing to put an enumeration of the use cases in the protocol
> requirement, but I would like to understand the purpose for the
> enumeration.   We are not doing a use case, but a requirements document.
> This information appears to be a "use case" rather than a technical
> description.   What purpose are you looking for this enumeration to
> server.  Are you looking for the enumeration in SEC-REQ-08?
>
> Point 3: Could you review -08.txt on this topic, especially the text
> below.  Given your comments, I believe I should change the last line to a
> MUST.
> New/   The default mode of transport is
>    secure so data models MUST clearly annotate what data nodes can be
>    passed over an insecure connection.
> /
>
> Sue
>
> ===================
> As to the normative requirements (-08.txt) version:
>
> Section 3:
>
>    I2RS allows the use of an insecure transport for portions of data
>    models that clearly indicate the use of an insecure transport.
>    Operators deploying I2RS must determine if they want to populate and
>    deploy the portions of the data model which use insecure transports.
>
> In Section 3.2 in version -08.txt
>
>    SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
>    secure transport and optionally MAY be able to transfer data over a
>    non-secure transport.  A secure transport MUST provide data
>    confidentiality, data integrity, and replay prevention.
>
>    The default I2RS transport is a secure transport.
>
>    A non-secure transport can be used for publishing telemetry data or
>    other operational state that was specifically indicated to non-
>    confidential in the data model in the Yang syntax.
>
>    The configuration of ephemeral data in the I2RS Agent by the I2RS
>    client SHOULD be done over a secure transport.  It is anticipated
>    that the passing of most I2RS ephemeral state operational status
>    SHOULD be done over a secure transport.  As
>    [I-D.ietf-i2rs-ephemeral-state] notes,  a data model MUST indicate
>    whether the transport exchanging the data between I2RS client and
>    I2RS agent is secure or insecure.
>
>    The default mode of transport is
>    secure so data models SHOULD clearly annotate what data nodes can be
>    passed over an insecure connection.
>
> >
> > Yours,
> > Joel
> >
> > -----Original Message-----
> > From: Susan Hares [mailto:shares@ndzh.com]
> > Sent: Thursday, August 18, 2016 9:17 AM
> > To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
> > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'
> > <Kathleen.Moriarty.ietf@gmail.com>om>; 'The IESG' <iesg@ietf.org>rg>;
> > jhaas@pfrc.org;
> > draft-ietf-i2rs-protocol-security-requirements@ietf.org
> > Subject: RE: [i2rs] Kathleen Moriarty's Discuss on
> > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> > COMMENT)
> >
> > Juergen and Kathleen:
> >
> > Let me proceed with two examples: BGP route views data model and the
> event for the web-service data.
> >
> > The content of these data models are designated as exposed to public.
> The routing system only populates the proposed BGP route views data model
> with the data destined for the BGP looking glass.  The policy on the
> routing system indicates what information gets transferred.  The data model
> is completely available to the public.  The Yang Doctors are going to
> review this by seeing the whole model is public and available via
> non-secure means.
> > The security people are going to review this seeing that the whole model
> is public, and available via an unprotect means.  The fact the data model
> is all public should simplify the review.
> >
> > An event from the I2RS RIB that a web-service route is up is the second
> case.  The I2RS RIB has an event based on policy that indicates a
> web-service route is up.  The yang-1.1 doctors must review the content of
> the event text to see it does not break privacy or provide too much
> > information   The event mechanisms will need to work over secure
> transport
> > and insecure transport.  Most of the data will go over the secure
> transport event stream. However, a small amount of information may go over
> the insecure transport stream.
> >
> > First, let me know if my use cases are understandable.  Second, let me
> know if you disagree with this use cases.
> >
> > Fyi -  IESG approved the architecture with the insecure stream.
> >
> > Sue
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:j.schoenwaelder@jacobs-university.de]
> > Sent: Thursday, August 18, 2016 9:06 AM
> > To: Susan Hares
> > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The
> > IESG'; jhaas@pfrc.org;
> > draft-ietf-i2rs-protocol-security-requirements@ietf.org
> > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> > COMMENT)
> >
> > I just do not know on which basis a data model writer can decide whether
> a data object can be exposed in an unprotected way. How are YANG doctors
> going to review this? How are security directorate people going to judge
> this? But as promised, I leave (still puzzled) now.
> >
> > /js
> >
> > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote:
> >> Juergen:
> >>
> >> Yes, we seem to disagree on the value of making it hardwired in the
> model.
> >> For me, the value is a common understanding of deployment
> >> distribution
> > such
> >> as the route-views.   Since the operators argued strongly for this
> point,
> > I
> >> think the best idea is to get it working in code and then see if the
> >> deployment matches the requests.
> >>
> >> Sue
> >>
> >> -----Original Message-----
> >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen
> >> Schoenwaelder
> >> Sent: Thursday, August 18, 2016 8:14 AM
> >> To: Susan Hares
> >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The
> >> IESG'; jhaas@pfrc.org;
> >> draft-ietf-i2rs-protocol-security-requirements@ietf.org
> >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> >> COMMENT)
> >>
> >> Sue,
> >>
> >> I still do not see why the 'mode of exposure' of data benefits from
> >> being hard-wired in the data model. For me, it is a situational and
> >> deployment specific question. But I shut up here since I aired this
> >> concern before (and we simply seem to disagree).
> >>
> >> /js
> >>
> >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote:
> >>> Juergen:
> >>>
> >>> My example is the looking glass servers for the BGP route views
> >>> project
> >>> (http://www.routeviews.org/) or a route indicating the presence of a
> >>> web-server that is public.   For the BGP I2RS route, a yang model could
> >>> replace the looking glass function, and provide events for these
> looking
> >>> glass functions.    For the web-server route,  an event be sent when
> > that
> >>> one route is added.
> >>>
> >>> Sue
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Juergen Schoenwaelder
> >>> [mailto:j.schoenwaelder@jacobs-university.de]
> >>> Sent: Thursday, August 18, 2016 3:32 AM
> >>> To: Susan Hares
> >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;
> >>> i2rs-chairs@ietf.org;
> >>> draft-ietf-i2rs-protocol-security-requirements@ietf.org
> >>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> >>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
> >>> COMMENT)
> >>>
> >>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote:
> >>>> ------------------------------------------------------------------
> >>>> --
> >>>> --
> >>>> COMMENT:
> >>>> ------------------------------------------------------------------
> >>>> --
> >>>> --
> >>>>
> >>>>> Section 3:
> >>>>> Can you clarify the second to last sentence?  Do you mean there
> >>>>> are
> >>> sections that indicate an insecure transport should be used?
> >>>>>  I2RS allows the use of an
> >>>>> insecure transport for portions of data models that clearly
> >>>>> indicate  insecure transport.
> >>>>
> >>>>> Perhaps:
> >>>>> I2RS allows the use of an
> >>>>> insecure transport for portions of data models that clearly
> >>>>> indicate the use of an  insecure transport.
> >>>
> >>> I still wonder how a data model writer can reasonably decide whether
> >>> a piece of information can be shipped safely over an insecure
> >>> transport since this decision often depends on the specifics of a
> >>> deployment
> >> situation.
> >>>
> >>> /js
> >>>
> >>> PS: I hope we do not end up with defining data multiple times (once
> >>>    for insecure transport and once for secured transports).
> >>>
> >>> --
> >>> 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
> >>> i2rs@ietf.org
> >>> 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
> >> i2rs@ietf.org
> >> 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
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
>