I believe - with my knowledge of netconf --what we are missing is the ability to negotiate a proposal in an efficient way. The closest we found so far is an oasis standard.
Happy to discuss it sunday! Yours Daniel On Nov 10, 2016 08:55, "Susan Hares" <sha...@ndzh.com> wrote: > Daniel: > > > > I think RESTCONF/NETCONF can be used for inter-cloud as well as setting > specific configuration. NETCONF has a JSON encoding as well. Therefore, > what we really need to determine is the benefit of your protocol versus the > existing code base changes. I believe my data model does the same things > you are proposing and plugs into the capability model we are developing. > > > > I will send additional comments to the list during the next few days, but > I really hope we can meet on Sunday at the IETF social to discuss these > points. The best result would be to determine the right solution across > multiple protocols (just like NETCONF/RESTCONF/I2RS have done). > > > > Cheers, > > > > Sue > > > > *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *Daniel > Migault > *Sent:* Wednesday, September 21, 2016 9:08 AM > *To:* Susan Hares > *Cc:* i2nsf@ietf.org; Alireza Ranjbar; Linda Dunbar > *Subject:* Re: [I2nsf] Is the "Security Service Function (SSF)" in > draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the > I2NSF-problem-and-use-cases? > > > > Hi Susan, > > I deeply apology for not having read carefully the > draft-hares-i2nsf-ddos-yang-dm-00, but my understanding is that our > protocol would – for example – end up in agreeing using inter-cloud-ddos > NSF with the inter-cloud-ddos NETCONF/YANG model. The remaining > configuration NETCONF/YANG will be done outside of our protocol. > > > > We wondered whether using YANG or JSON and we decided to use JSON as YANG > seemed to us non appropriated for our protocol. That said we might be > completely wrong and would be happy to change if necessary. The reasoning > behind was: > I saw NETCONF/YANG as one way to get operational data or to push a > configuration. In our case, the collaboration agreement seemed different from > a configuration file as a given attribute may have a preset of values. “A”, > “B”, “C” and “D”, but the cloud and the cloudlet may have different policies > regarding the attribute. For example the cloud only accepts “A” “B” and “C” > and the cloudlet only accepts “C” and “D”. In that sense, the purpose of the > our protocol is to let the cloud announce to the cloudlet that it only > accepts answers that are in “A” “B” “C” , and let the cloudlet responds with > “C”. > > One way to do that in YANG would be to have attributes like: > > Attribute-proposal-list and Attribute-chosen, but I am not sure that is > really appropriated. > > > We are happy to receive feed back on your opinion using YANG/JSON! > > BR, > > Daniel > > > > > > On Tue, Sep 13, 2016 at 3:25 PM, Susan Hares <sha...@ndzh.com> wrote: > > Linda and Daniel: > > > > To follow-up on Linda’s second question, this draft appears to be similar > to the draft-inter-cloud-DDOS Yang model (draft-hares-i2nsf-ddos-yang-dm-00). > Is it reasonable to have to different yang models or to make one an > augmentation of the other data model? > > > > It might make sense to have a general collaboration model for inter-domain > SSF functions with the DDOS Yang model as a sub-function. I’ll send some > Yang model interactions offline. > > > > Sue > > > > *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *Linda Dunbar > *Sent:* Monday, September 12, 2016 5:59 PM > *To:* 'Daniel Migault'; Alireza Ranjbar; i2nsf@ietf.org > *Subject:* [I2nsf] Is the “Security Service Function (SSF)” in > draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the > I2NSF-problem-and-use-cases? > > > > Daniel and Alirezza, > > > > Is the “Security Service Function (SSF)” in your draft equivalent to the > Network Security Function (NSF) defined in https://www.ietf.org/id/draft- > ietf-i2nsf-problem-and-use-cases-01.pdf ? > > > > > > NSF: Network Security Function. An NSF is a function that detects abnormal > activity and blocks/mitigates the effect of such abnormal activity in order > to preserve the availability of a network or a service. In addition, the > NSF can help in supporting communication stream integrity and > confidentiality. > > > > Flow-based NSF: An NSF which inspects network flows according to a > > security policy. Flow-based security also means that packets are > > inspected in the order they are received, and without altering > > packets due to the inspection process (e.g., MAC rewrites, TTL > > decrement action, or NAT inspection or changes). > > > > > > If they are the same, can you change the terminology? If they are > different, can you elaborate the differences in your draft? > > > > > > Second question: > > When the “Cloud based services” need network provider to enforce certain > flow rules for the traffic destined to (originated from) the “Cloud based > services”, do you anticipate those flow rules to be applied to specific > SSFs belonging to different administrators? Or can those rules be to the > “controller” of the SSFs belonging to network providers? As described by > https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound- > framework/ ? > > > > > > Thanks, > > Linda > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > >
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
