Alvaro: On "A" - and the sections in 1.1 and 6.4.1 you quoted - it is either I2RS data model safe, I2RS protocol safe, I2RS environment safe, or safe for the routing system. The text implies the last one safe for the routing system protocols and RIBs. That's an architecture big-picture comment. If you read more beyond that .. you are reading out of context (IMHO).
On B - you would like to place architecture qualities of the large data flows outbound (e.g. pub-sub), and large data flows inbound (e.g. large updates) in the architecture document. I'm fine with this approach since I2RS is actively working on these features. On this topic, I want to validate the approach and my text with my co-authors (give me a few hours). On L:, I'll add all the RFCs in -14 that are not abbreviation and work with the RFC editor to make sure we are aligned with her policy. On H:, I'll use that text. What I owe you is the joint resolution for "B" in the problem and architecture statement. Let me know if "A" answers works for you. Sue -----Original Message----- From: Alvaro Retana (aretana) [mailto:[email protected]] Sent: Tuesday, March 15, 2016 3:50 PM To: Susan Hares; 'The IESG' Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) On 3/15/16, 2:26 PM, "iesg on behalf of Susan Hares" <[email protected] on behalf of [email protected]> wrote: Sue: Hi! ... >=========== >>A. There are a couple of places where operations are characterized as >>"safe" (1.1 and 6.4.1 < see below), but no >explanation as to what >>"safe" means. It seems to me that these mentions of "safe" go beyond >>authentication and even >authorization to perform a specific >>operation, to the content of the operation itself. I would like to >>see some >>>discussion about how to achieve it, and/or (at least) what the impact >>>may be. > >The definition of "safe" from a security viewpoint was a sufficient >enough discussion that two I2RS requirements documents were created: >1) defining "safe" protocol - >https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requ >ire >ments/ >2) defining "safe" environment - >https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-r >eqs >/ > >The definition of "safe" specifically also depends on the protocol(s) >selected to be combined for the I2RS higher level protocol and the "safe" >environment. Do you want these two documents back-fitted to the >architecture or are you looking for something different? The point I was trying to make is that the use of "safe" in the text I quoted (1.1 and 6.4.1) seems to not be the "safe" used in security: authentication, authorization, encryption, etc. For example, the text in 1.1 says that "I2RS will only permit modification of state that would be safe" -- note that the *modification* is what is characterized as safe, the action itself! The text above made me think about the result of that modification and whether that was considered "safe" in the network -- and what would that be, which is why I asked. As an simple example, consider a modification that would result in the connection to the Client to be lost (adding a route for that destination with an action to drop) -- while the identity, authentication, integrity, authorization, etc. may all check out correctly (I.e. The interaction is secure!), it is obviously not what I would characterize as a "safe" modification. Maybe I'm reading too much into it... ??? > >B. Section 3. (Key Architectural Properties) says that "some >architecture properties such as performance and scaling are not >described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". >However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement >[1], that document has a very, very sparse treatment of performance and >scalability to even attempt to call it a "Key Architectural Property". > >Response: I sent you a question about what you wanted for the problem >statement. I am holding the problem statement because you have not >responded to the scaling. My preferred solution, given that I-D.ietf-i2rs-problem-statement doesn't really say anything about performance and scaling anyway, is to add the discussion in Section 3 of this document. > We have the following things you can see in other documents: > >- The I2RS pub-sub requirements documents look toward the scaling of >large data via the publication and subscription mechanisms. >draft-ietf-i2rs-pub-sub-requirements > >- Potential ability to allow minimal checking on the upload of the >local RIB (in discussion) > draft-ietf-i2rs-usecase-reqs-summary > draft-hares-i2rs-dataflow-req > >These are scaling efforts for the inbound/outbound data flows. Other >reviewers had considered these specifics were not valid in the problem >statement, but perhaps we can work through a compromise where we >discuss the problem of large data inputs/outputs in a constructive >manner. Can you suggest any text? Note that my comment was around the fact that the text mentions performance and scaling as key architectural properties (of the architecture) and there is no discussion related to them. What you point to above are requirements/scaling efforts for specific operations/mechanisms -- which clearly don't represent the architectural view that the other items in Section 3 do. Again, my preference is to see Key Architectural Properties discussed where they belong: in the architecture document. > > >L. Many protocols (routing-related and otherwise) are mentioned without >references. > >Sue: Do you really want all the protocols lists in the diagrams to be >reference? >If so, I am glad to do it. This question is also included in the top. It is common practice to do so. I think that many are well-known and may not need a reference, but not all are included in the RFC Editor Abbreviation List. I'll let you make the call. https://www.rfc-editor.org/materials/abbrev.expansion.txt ... >H. 3.2. (Extensibility) talks about the initial scope of I2RS (without >references). To extend the usability of this document, I would suggest >that the statements of this section be made independent of the fact >that the initial scope may be narrow. IOW, I think you may want the >protocol/data model to be extensible regardless of the size of the >initial scope (even if boiling the ocean to start with, there will >always be opportunities for extensions later). > >Sue: I agree. > >How about this change: > >Old / The scope of the I2RS work is being restricted in the interests >of > achieving a deliverable and deployable result. The I2RS Working > Group is modeling only a subset of the data of interest. It is > clearly desirable for the data models defined in the I2RS to be > useful in more general settings. It should be easy to integrate data > models from the I2RS with other data. Other work should be able to > easily extend it to represent additional aspects of the network > elements or network systems. This reinforces the criticality of > designing the data models to be highly extensible, preferably in a > regular and simple fashion./ > >New / The scope of I2RS work is being designed in phases to provide > deliverable and deployable results at every phase. Each > phase will have a specific set of requirements, and > the I2RS protocol and data models will progress toward these >requirements. > Therefore, it is clearly desirable for the I2RS data models > to be easily and highly extensible to represent additional >aspects of the network elements > or network systems. It should be easy to integrate data > models from the I2RS with other data. This reinforces the >criticality of > designing the data models to be highly extensible, preferably in a > regular and simple fashion/ That works for me. Thanks! Alvaro. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
