Thanks Linda. I do not agree with 3444, as it is informational, and relies on 3198 for a real definition. I don't really see the point of 3444.
My point was that if you are going to call something an info model, then it should describe objects, hopefully in an object-oriented way. What I see is a confusion between what is an object, what is an attribute, and what is a relationship. That confusion must be cleared up before we can consider WG adoption. best regards, John On Thu, Nov 2, 2017 at 2:17 PM, Linda Dunbar <linda.dun...@huawei.com> wrote: > John, > > > > Thank you very much for identifying some of the issues of the IM draft. > Agree with you that we need to resolve the conflicts with the “capability > I-D”. I hope we can make some progress in IETF100. > > > > Per RFC 3444, the information model can be loosely defined, as long as it > lays out the needed information elements. I understand not everyone agree > with RFC3444. But before changes to RFC3444 is made, we should allow people > to name their draft based on RFC3444. > > > > Once become WG draft, the WG can contribute and make it correct. > > > > Linda > > > > > > *From:* John Strassner [mailto:straz...@gmail.com] > *Sent:* Thursday, November 02, 2017 3:09 PM > *To:* Yoav Nir <ynir.i...@gmail.com>; John Strassner <straz...@gmail.com> > *Cc:* John Strassner <john.sc.strass...@huawei.com>; Mr. Jaehoon Paul > Jeong <jaehoon.p...@gmail.com>; i2nsf@ietf.org; Linda Dunbar < > linda.dun...@huawei.com> > *Subject:* Re: [I2nsf] Request for WG Adoption Call for I2NSF Data Model > Drafts > > > > Hi Yoav, > > > > I understand the adoption practice :-) > > > > What I don't understand is why draft-kumar is titled "Information Model > for Consumer-Facing Interface", as it is not an information model. > > > > In addition, this draft conflicts with the capability I-D, which has > already been adopted. For example, the very first object that is described > is a Policy object, which "represents a mechanism to express a Security > Policy by Security Admin (i.e., I2NSF User) using Consumer-Facing interface > toward Security Controller; the policy would be enforced on an NSF." This > object conflicts with the SecurityECAPolicyRule object defined in the > capability draft. > > > Especially because there is a normative requirement in the next line of > the kumar draft ("The Policy object SHALL have following information"). > > > > Now, if I look at this object, I can make the following comments: > > - The information specified is a mixture of attributes and relationships > to other objects, but the actual format and syntax is not specified > > - Name and descriptions SHOULD NOT be defined in this spec: they are > inherited from external specs as defined in the Capability draft > > - Multi-tenancy SHOULD NOT be defined as an attribute! This appears to > be a set of relationships to other objects > > - End-Group SHOULD NOT be defined as an attribute, appears to be > relationships to other objects, and has problems in its definition > > - Threat-Feed SHOULD NOT be defined as an attribute, appears to be > relationships to other objects, and has problems in its definition > > - Telemetry Data SHOULD NOT be a "field" > > - Rules (see below) > > - Owner (see below) > > > > What really bothers me is the "Rules" field. This is completely > contradictory to the capability draft. Please re-examine it. > > > > So, if you are asking if I support WG adoption, then the answer is NO. > However, my point was that this draft, besides not being organized as an > information model, is in too incomplete a state to start working on - all I > have is questions. > > > > regards, > > john > > > > > > On Thu, Nov 2, 2017 at 11:39 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi, John > > > > On 2 Nov 2017, at 7:08, John Strassner <john.sc.strass...@huawei.com> > wrote: > > > > <snip/> > > > > Second, my worry is that draft-kumar is not ready. It is not an > information model; rather, it is (at best) requirements that could be > turned into an information model. In addition, it needs to be integrated > with the existing capability draft. Note that it is absolutely essential > that we only have a single information model. Having multiple information > models is akin to having multiple dictionaries; what inevitably happens is > that the same concept is defined in multiple conflicting ways. I suggest > that this document be examined in more detail to determine how best to > proceed. I have already talked to Frank about that. > > > > I’d like to point out that a draft that gets adopted does not need to be > ready for publication. It only needs to be good enough to be a starting > point for work by the working group. > > > > At present, draft-kumar is the product of its seven authors. They can put > whatever they want in this document and they don’t need anyone to agree to > any changes. > > > > What adoption changes is that the group gets change control, so if the > group decides that the IM should be added in this draft, that is what > happens; and if the group decides that it should be merged with the > capabilities draft, that is fine as well. It is not the usual way to have > a working group work on an individual draft. If we want to work on this, we > adopt it and make it ready. We don’t wait for individual authors to make > their draft ready for publications and then adopt it followed immediately > by working group last call. > > > > I agree that we may want to spend some time on the list of documents > before adopting them, but getting to start work on the content of these > documents is what this group is chartered to do. > > > > Yoav > > > > > > > -- > > regards, > > John > -- regards, John
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
