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

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

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:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, August 18, 2016 8:14 AM
To: Susan Hares
Cc: [e-mail]; [e-mail]; 'Kathleen Moriarty'; 'The IESG';
[e-mail]; [e-mail]
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:[e-mail]]
> Sent: Thursday, August 18, 2016 3:32 AM
> To: Susan Hares
> Cc: 'Kathleen Moriarty'; 'The IESG'; [e-mail]; [e-mail]; 
> [e-mail]; 
> [e-mail]
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> 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/>

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs