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

[Alia Atlas <[e-mail]>]

First, to be very clear.  This document has WG consensus - confirmed over
multiple WGLCs - in the I2RS WG.
This thread is to resolve the concerns expressed by the ADs about specific
aspects of this document.

Second, by having a requirement for indicating in the model - whether for
the whole model or per leaf - that
the data may be sent over an insecure transport, this encourages limiting
the standard use of an insecure
transport to exactly those models or data that requires it for a given
use-case.

I do see this as limited to certain types of use-cases and the ability to
mount a model differently allows the
flexibility of describing a particular model as acceptable for insecure
transport rather than requiring a leaf-by-leaf
indication.

The use of insecure transport is to accommodate use-cases that were not in
the scope initially considered
for NetConf/RestConf.

Regards,
Alia

On Fri, Aug 19, 2016 at 12:32 PM, Andy Bierman <[e-mail]> wrote:

>
>
> On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares <[e-mail]> wrote:
>
>> Andy:
>>
>>
>>
>> I have been thinking about your question for 30 minutes.   Let me put
>> down a few of my personal opinions:
>>
>>
>>
>> 1)      Most (99%) of the ephemeral data models will not allow
>> non-secure transport.
>>
>> 2)       If any ephemeral data models have an insecure section, the
>> review and consensus for a standards model should take longer.
>>
>> I hope we can streamline the normal Yang model review.  [It would be nice
>> to streamline features additions for NETCONF/RESTCONF as well].
>>
>>
>>
>
> I hope you are right that it will almost always be easy for a WG
> to decide this issue for each leaf.
>
> We already have "security tagging" in NACM, and this has not caused delays.
> This is the opposite decision -- Is this data so sensitive that the NACM
> default
> access control needs to block writes (nacm:default-deny-write) or block
> all access
> (nacm:default-deny-all)?
>
> These extensions are used in ietf-system.yang, not just in the NACM RFC.
> They can be used anywhere and a NACM implementation MUST enforce
> the extension semantics.
>
> If YANG Push had similar requirements (i.e, MUST NOT send data in the clear
> that is not tagged with the appropriate extension) and the review criteria
> is clear,
> then this approach should be OK.
>
>
> Andy
>
>
> 3)      I prefer to have the non-secure sections of a data model moved to
>> a separate date model, and the data model marked as insecure.
>>
>> [I do not know if we could use the library function to mark the data
>> model in meta-language.]
>>
>> However, until we complete the mount schema work – I do not know if this
>> is workable.
>>
>>
>>
>> Would it help if I changed version -08 to
>>
>> Old/
>>
>>    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. /
>>
>> New:/
>>
>>       A non-secure transport can be used for publishing telemetry data or
>> other
>>
>>      Operational state that was specifically indicated to be
>> non-confidential in the data model.
>>
>>     /
>>
>>
>>
>> Sue
>>
>>
>>
>>
>>
>> *From:* i2rs [mailto:[e-mail]] *On Behalf Of *Susan Hares
>> *Sent:* Friday, August 19, 2016 10:59 AM
>> *To:* 'Andy Bierman'; 'Lou Berger'
>> *Cc:* [e-mail]; 'Alissa Cooper'; 'Juergen Schoenwaelder';
>> [e-mail]; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel
>> Halpern'; [e-mail]
>> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
>> COMMENT)
>>
>>
>>
>> Andy:
>>
>>
>>
>> Thank you for your comments.   Perhaps you can provide for the IESG the
>> list of things that are needed to move a Yang module forward in the IETF.
>>
>>
>>
>> Sue
>>
>>
>>
>> *From:* Andy Bierman [mailto:[e-mail] <[e-mail]>]
>> *Sent:* Friday, August 19, 2016 10:24 AM
>> *To:* Lou Berger
>> *Cc:* Susan Hares; Juergen Schoenwaelder; [e-mail]; Alissa Cooper;
>> [e-mail]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel
>> Halpern; [e-mail]
>> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
>> COMMENT)
>>
>>
>>
>> Hi,
>>
>>
>>
>> I agree with Juergen.
>>
>> There are already too many details that need consensus to move
>>
>> a YANG module forward in the IETF.  It takes too long already.
>>
>>
>>
>> We could have been tagging MIB objects all along, but we don't.
>>
>> Imagine if there was a debate for every single OBJECT-TYPE macro
>>
>> "is this leaf OK for noAuth/noPriv?"
>>
>>
>>
>> Are there even clear SEC-DIR guidelines on how one would decide this
>>
>> debate in a WG? Does SEC-DIR really want to be flooded with review
>>
>> requests so they become a bottleneck in YANG RFC publication process?
>>
>>
>>
>> Standardized insecure access is a big change from what we have done
>>
>> for 30 years.  There could be a good reason why we left this out of scope
>>
>> all this time.
>>
>>
>>
>>
>>
>> Andy
>>
>>
>>
>>
>>
>> On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger <[e-mail]> wrote:
>>
>>
>> Sue,
>>
>> My message said three things:
>>
>> 1) Juergen's comment resonates with me.
>>
>> 2) I think the current text is acceptable.
>>
>> 3) I see changing the SHOULD to a MUST as problematic.
>> I understood one of the other messages on this thread proposing this
>> change which is what triggered my message.   If I misunderstood that
>> message, feel free to interpret my message as supporting the current
>> text in question.
>>
>> Note that I am only speaking for myself (including in my role as NETMOD
>> co-chair) and not representing the consensus opinion of any WG.
>>
>> Lou
>> On 8/19/2016 8:07 AM, Susan Hares wrote:
>> > Lou:
>> >
>> > I am clear that Juergen does not want not want to place transport
>> requirements within the data model for NETMOD.  His opinion was considered
>> in the rough for the I2RS WG. If this requirement is a problem for
>> NETCONF/NETMOD,  the text currently says:
>> >
>> > REQ-SEC-09 states:
>> >
>> >   The default mode of transport is secure so data models SHOULD clearly
>> annotate what data nodes can be
>> >    passed over an insecure connection.
>> >
>> > However, if this means the NETCONF/NETMOD WG will not even entertain
>> proposal for marking the insecure functions in yang text -- then the two WG
>> (I2RS/NETMOD) have a problem and should stop this standardization process
>> going forward.
>> >
>> > Sue
>> >
>> >
>> > -----Original Message-----
>> > From: Lou Berger [mailto:[e-mail]]
>> > Sent: Friday, August 19, 2016 7:34 AM
>> > To: Susan Hares; 'Juergen Schoenwaelder'
>> > Cc: [e-mail]; 'Alissa Cooper'; [e-mail]; 'Kathleen
>> Moriarty'; 'IESG'; [e-mail]; 'Joel Halpern';
>> [e-mail]
>> > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
>> COMMENT)
>> >
>> > Sue,
>> >
>> >     I don't see Juergen as arguing against model access via non-secure
>> transport. I read his point as that the transport security requirements
>> don't belong scattered within a data model.
>> >
>> > I have to say that from a model complexity (definition, process,
>> review, implementation - take your pick) , language and NETMOD co-chair
>> perspective, his comment resonates with me.
>> >
>> > I think this makes the key text:
>> >
>> >    The default mode of transport is
>> >    secure so data models SHOULD clearly annotate what data nodes can be
>> >    passed over an insecure connection.
>> >
>> >
>> > As this isn't a MUST, I personally think we can live with the text and
>> we can debate the issue further in the context of specific solutions.  I
>> would strongly object to this being changed to a MUST, or if the document
>> is changed to make transport (security) requirements identified within data
>> models a requirement.
>> >
>> > Lou
>> >
>> > On 8/19/2016 6:49 AM, Susan Hares wrote:
>> >> Juergen:
>> >>
>> >> You have laid out the two options:   a) link the data-model to the
>> non-secure transport, and b) do not link the data to the non-secure
>> transport.   I agree with you that past models did not link past SNMP MIB
>> data model to the transport.  Existing NETCONF models do not link it to the
>> transport.   As you have indicated, you disagreed in the I2RS WG and we
>> found consensus was to include the non-secure transport.
>> >>
>> >> I2RS was created to build things as an interface to the routing
>> environment.   The operators clearly informed the I2RS group of this need
>> during the requirement setting phase prior to the time I was chair.  The
>> reason I continue to press for this capability is their input, and the
>> existing use cases I listed previously in this mail:
>> >>
>> >> a) public information - BGP route views,
>> >> b) specific well know up events - such as public-web site up
>> >> c) specific network service events - interface to particular public
>> LAN up.
>> >>
>> >> As you know, we do not have any I2RS data models that specify this
>> feature at this time.   I suspect after we get through this lengthy
>> requirement phase, the operators may begin to specify new models that have
>> this feature.
>> >>
>> >> Sue
>> >>
>> >> -----Original Message-----
>> >> From: Juergen Schoenwaelder
>> >> [mailto:[e-mail]]
>> >> Sent: Friday, August 19, 2016 4:58 AM
>> >> To: Susan Hares
>> >> Cc: 'Alissa Cooper'; 'Joel Halpern'; [e-mail];
>> >> [e-mail]; 'Kathleen Moriarty'; 'IESG'; [e-mail];
>> >> [e-mail]
>> >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>> >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
>> >> COMMENT)
>> >>
>> >> I repeat my technical argument: While there may be deployments where
>> non-secure transports may be reasonable to use, defining these situations
>> statically as part of data model schemas does not follow established
>> practices. The IETF has a long tradition of standardizing data models that
>> can be used in a variety of operational contexts and I do not see reasons
>> why we should move away from that basic approach.
>> >>
>> >> /js
>> >>
>> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares 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:[e-mail]]
>> >>> Sent: Thursday, August 18, 2016 12:54 PM
>> >>> To: Joel Halpern
>> >>> Cc: Susan Hares; Juergen Schoenwaelder; [e-mail];
>> >>> [e-mail]; Kathleen Moriarty; IESG; [e-mail];
>> >>> [e-mail]
>> >>> 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 <
>> [e-mail]> 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:[e-mail]]
>> >>>> Sent: Thursday, August 18, 2016 9:17 AM
>> >>>> To: 'Juergen Schoenwaelder' <[e-mail]>
>> >>>> Cc: [e-mail]; [e-mail]; 'Kathleen Moriarty'
>> >>>> <[e-mail]>; 'The IESG' <[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)
>> >>>>
>> >>>> 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:[e-mail]]
>> >>>> Sent: Thursday, August 18, 2016 9:06 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)
>> >>>>
>> >>>> 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:[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
>> >>>>>
>> >>>> --
>> >>>> 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
>>
>>
>>
>
>