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<mailto:ynir.i...@gmail.com>> wrote: Hi, John On 2 Nov 2017, at 7:08, John Strassner <john.sc.strass...@huawei.com<mailto: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
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
