Re: [I2nsf] On Information Models [Was: need some work to improve the consistency of I2NSF Information and data model: maybe a design team?]

[Adrian Farrel]

Hi John,

Thanks for these opinions.

> I personally feel that information in RFC3444 is not as accurate as what is 
> in our set of drafts.

This is a problem for me. RFC 3444 is an IETF consensus RFC and is (according 
to the OPS ADs) current. I don't find any ongoing work proposing to change it.

So if we have some "improvement" on the definitions (in particular of 'data 
model' and 'information model') we need to work out how to proceed. Options are:
a. fall back on RFC 3444 as "good enough"
b. special-case our work as "built on RFC 3444 with additional clarifications"
c. push an update to RFC 3444

I believe c would be expensive, possibly unable to reach a conclusion, and 
probably lengthy.
Option b worries me, but is perhaps the position you would like. It is possible 
we can make this work if we represent our work as a clear set of enhancements 
to RFC 3444.
Option a would be best.

Maybe the way we can take this forward is to briefly list out how our work 
differs from (improves on) RFC 3444.

> Regarding the "one vs many information models", the argument is simple. One 
> of the
> purposes of an information model is to define concepts of use to the managed
> environment. This is done using classes (to define generic concepts), 
> attributes (to 
> define salient  characteristics of a class), and relationships (to define how 
> one class is
> related to, or interacts with, other classes).
>
> Now imagine that there are multiple information models that do this in 
> different ways.
> This is not tenable. It is equivalent to someone trying to translate a 
> foreign language
> using multiple dictionaries that have different definitions.
>
> I have absolutely no objection to building multiple I-Ds that define 
> different aspects of
> our work. However, they must relate to each other. Right now, we have multiple
> information model I-Ds that use various levels of specificity, and do not 
> relate to each
> other. That is my objection.

OK that's good. So we can continue with separate I-Ds (separate modules), but 
we need to get them to be consistent where the pieces of the models impact on 
each other.

I see there is debate on this topic on the list. Good.

Thanks,
Adrian

===

On Mon, Jul 17, 2017 at 2:50 AM, Adrian Farrel  wrote:
Taking John's three points separately (and in reverse order)
 
3) Yes, traceability back from DM to IM is very valuable and is a strong should 
for the WG because the WG has decided that IMs are a deliverable.
 
2) I think we should lean very heavily on RFC3444 for our definition of IM and 
DM. This might not be consistent with every view of those terms, but it is what 
the IETF has consensus on and absent any changes across the OPS area, we should 
stick with it.
 
I am sure that the current documents can be improved to be clearer on what 
information is "in the model" and to separate out other interface-specific 
requirements, but that is "work in progress".
 
1) Consistency across models is important. As is coherence across the whole of 
the I2NSF space. And there will clearly be mapping of information at one 
interface to information at another interface. But I don't quite understand the 
"one IM versus many IMs" discussion. Arguably we could say that the whole 
universe has a single IM, but I think we can also agree that it is convenient 
to break out pieces so that our scope a field of vision is limited. The attempt 
here is to partition the IM into "information modules" that describe the 
information at each interface, and it is convenient to place these pieces 
(modules) in separate documents.
 
Does any of that help?
 
Adrian
 
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of John Strassner
Sent: 16 July 2017 18:36
To: Linda Dunbar; John Strassner
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] need some work to improve the consistency of I2NSF 
Information and data model: maybe a design team?
 
I cannot attend Prague due to family health issues.
 
That being said, I agree with Linda. I see three major problems:
 
   1) There should be one, and only one, information model.
a) It is great to have multiple contributions, but those contributions 
MUST be written to enhance the existing model, not propose a new one
   2) In general, some of the info models are not really **models** per se, but 
rather, requirements for models. 
   3) In general, I cannot trace data model work back to the info model work.
   a) This is especially true for drafts that are trying to use or define 
policies
 
I propose that draft-xibassnez is used for our info model. This means that the 
other info model drafts SHOULD be restructured to add to that draft.
 
I propose that we wait on further data model draft definition until some people 
(I will help) on the design team can formulate guidelines and perhaps examples 
to properly derive data models from our info model.
 
regards,
John
 
On Fri, Jul 14, 2017 at 9:27 AM, Linda Dunbar 

Re: [I2nsf] On Information Models [Was: need some work to improve the consistency of I2NSF Information and data model: maybe a design team?]

[Xialiang (Frank)]

Hi all,
By following the principle of unified information model design, why not 
consider to have 2 individual drafts for each I2NSF interfaces? It’s logically 
reasonable and can avoid the draft being too long to read.

My 2 cents.

B.R.
Frank

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of John Strassner
Sent: Monday, July 17, 2017 7:54 PM
To: Adrian Farrel; John Strassner
Cc: i2nsf@ietf.org; Linda Dunbar
Subject: Re: [I2nsf] On Information Models [Was: need some work to improve the 
consistency of I2NSF Information and data model: maybe a design team?]

Hi Adrian,

I personally feel that information in RFC3444 is not as accurate as what is in 
our set of drafts.

Regarding the "one vs many information models", the argument is simple. One of 
the purposes of an information model is to define concepts of use to the 
managed environment. This is done using classes (to define generic concepts), 
attributes (to define salient characteristics of a class), and relationships 
(to define how one class is related to, or interacts with, other classes).

Now imagine that there are multiple information models that do this in 
different ways. This is not tenable. It is equivalent to someone trying to 
translate a foreign language using multiple dictionaries that have different 
definitions.

I have absolutely no objection to building multiple I-Ds that define different 
aspects of our work. However, they must relate to each other. Right now, we 
have multiple information model I-Ds that use various levels of specificity, 
and do not relate to each other. That is my objection.


regards,
John

On Mon, Jul 17, 2017 at 2:50 AM, Adrian Farrel 
> wrote:
Taking John's three points separately (and in reverse order)

3) Yes, traceability back from DM to IM is very valuable and is a strong should 
for the WG because the WG has decided that IMs are a deliverable.

2) I think we should lean very heavily on RFC3444 for our definition of IM and 
DM. This might not be consistent with every view of those terms, but it is what 
the IETF has consensus on and absent any changes across the OPS area, we should 
stick with it.

I am sure that the current documents can be improved to be clearer on what 
information is "in the model" and to separate out other interface-specific 
requirements, but that is "work in progress".

1) Consistency across models is important. As is coherence across the whole of 
the I2NSF space. And there will clearly be mapping of information at one 
interface to information at another interface. But I don't quite understand the 
"one IM versus many IMs" discussion. Arguably we could say that the whole 
universe has a single IM, but I think we can also agree that it is convenient 
to break out pieces so that our scope a field of vision is limited. The attempt 
here is to partition the IM into "information modules" that describe the 
information at each interface, and it is convenient to place these pieces 
(modules) in separate documents.

Does any of that help?

Adrian

From: I2nsf [mailto:i2nsf-boun...@ietf.org] On 
Behalf Of John Strassner
Sent: 16 July 2017 18:36
To: Linda Dunbar; John Strassner
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] need some work to improve the consistency of I2NSF 
Information and data model: maybe a design team?

I cannot attend Prague due to family health issues.

That being said, I agree with Linda. I see three major problems:

   1) There should be one, and only one, information model.
a) It is great to have multiple contributions, but those contributions 
MUST be written to enhance the existing model, not propose a new one
   2) In general, some of the info models are not really **models** per se, but 
rather, requirements for models.
   3) In general, I cannot trace data model work back to the info model work.
   a) This is especially true for drafts that are trying to use or define 
policies

I propose that draft-xibassnez is used for our info model. This means that the 
other info model drafts SHOULD be restructured to add to that draft.

I propose that we wait on further data model draft definition until some people 
(I will help) on the design team can formulate guidelines and perhaps examples 
to properly derive data models from our info model.

regards,
John

On Fri, Jul 14, 2017 at 9:27 AM, Linda Dunbar 
> wrote:
Thanks to many people contributions. We now have many drafts on the information 
model and data model for I2NSF:

Information model:
draft-xibassnez-i2nsf-capability-02
draft-zhang-i2nsf-info-model-monitoring-04
draft-hyun-i2nsf-registration-interface-im-02
draft-kumar-i2nsf-client-facing-interface-im-03
draft-xia-i2nsf-security-policy-object-01

Data Model:
draft-hares-i2nsf-capability-data-model-03
draft-jeong-i2nsf-consumer-facing-interface-dm-02

Re: [I2nsf] On Information Models [Was: need some work to improve the consistency of I2NSF Information and data model: maybe a design team?]

[John Strassner]

Hi Adrian,

I personally feel that information in RFC3444 is not as accurate as what is
in our set of drafts.

Regarding the "one vs many information models", the argument is simple. One
of the purposes of an information model is to define concepts of use to the
managed environment. This is done using classes (to define generic
concepts), attributes (to define salient characteristics of a class), and
relationships (to define how one class is related to, or interacts with,
other classes).

Now imagine that there are multiple information models that do this in
different ways. This is not tenable. It is equivalent to someone trying to
translate a foreign language using multiple dictionaries that have
different definitions.

I have absolutely no objection to building multiple I-Ds that define
different aspects of our work. However, they must relate to each other.
Right now, we have multiple information model I-Ds that use various levels
of specificity, and do not relate to each other. That is my objection.


regards,
John

On Mon, Jul 17, 2017 at 2:50 AM, Adrian Farrel  wrote:

> Taking John's three points separately (and in reverse order)
>
>
>
> 3) Yes, traceability back from DM to IM is very valuable and is a strong
> should for the WG because the WG has decided that IMs are a deliverable.
>
>
>
> 2) I think we should lean very heavily on RFC3444 for our definition of IM
> and DM. This might not be consistent with every view of those terms, but it
> is what the IETF has consensus on and absent any changes across the OPS
> area, we should stick with it.
>
>
>
> I am sure that the current documents can be improved to be clearer on what
> information is "in the model" and to separate out other interface-specific
> requirements, but that is "work in progress".
>
>
>
> 1) Consistency across models is important. As is coherence across the
> whole of the I2NSF space. And there will clearly be mapping of information
> at one interface to information at another interface. But I don't quite
> understand the "one IM versus many IMs" discussion. Arguably we could say
> that the whole universe has a single IM, but I think we can also agree that
> it is convenient to break out pieces so that our scope a field of vision is
> limited. The attempt here is to partition the IM into "information modules"
> that describe the information at each interface, and it is convenient to
> place these pieces (modules) in separate documents.
>
>
>
> Does any of that help?
>
>
>
> Adrian
>
>
>
> *From:* I2nsf [mailto:i2nsf-boun...@ietf.org] *On Behalf Of *John
> Strassner
> *Sent:* 16 July 2017 18:36
> *To:* Linda Dunbar; John Strassner
> *Cc:* i2nsf@ietf.org
> *Subject:* Re: [I2nsf] need some work to improve the consistency of I2NSF
> Information and data model: maybe a design team?
>
>
>
> I cannot attend Prague due to family health issues.
>
>
>
> That being said, I agree with Linda. I see three major problems:
>
>
>
>1) There should be one, and only one, information model.
>
> a) It is great to have multiple contributions, but those
> contributions MUST be written to enhance the existing model, not propose a
> new one
>
>2) In general, some of the info models are not really **models** per
> se, but rather, requirements for models.
>
>3) In general, I cannot trace data model work back to the info model
> work.
>
>a) This is especially true for drafts that are trying to use or
> define policies
>
>
>
> I propose that draft-xibassnez is used for our info model. This means that
> the other info model drafts SHOULD be restructured to add to that draft.
>
>
>
> I propose that we wait on further data model draft definition until some
> people (I will help) on the design team can formulate guidelines and
> perhaps examples to properly derive data models from our info model.
>
>
>
> regards,
>
> John
>
>
>
> On Fri, Jul 14, 2017 at 9:27 AM, Linda Dunbar 
> wrote:
>
> Thanks to many people contributions. We now have many drafts on the
> information model and data model for I2NSF:
>
>
>
> Information model:
>
> draft-xibassnez-i2nsf-capability-02
>
> draft-zhang-i2nsf-info-model-monitoring-04
>
> draft-hyun-i2nsf-registration-interface-im-02
>
> draft-kumar-i2nsf-client-facing-interface-im-03
>
> draft-xia-i2nsf-security-policy-object-01
>
>
>
> Data Model:
>
> draft-hares-i2nsf-capability-data-model-03
>
> draft-jeong-i2nsf-consumer-facing-interface-dm-02
>
> draft-kim-i2nsf-nsf-facing-interface-data-model-02
>
> draft-hyun-i2nsf-registration-interface-dm-01
>
>
>
>
>
> But the problem is that they are not all consistent.  Extra work is needed
> to improve the consistency for I2NSF information and data models for both
> Client/Consumer facing and NSF facing interfaces.
>
> So we are going to form a design team to work on it.
>
>
>
> If you are interested in participate, please click on this doodle poll:
> https://doodle.com/poll/4ryrcw3993fbf7ca
>
>
>
> For people not in 

[I2nsf] On Information Models [Was: need some work to improve the consistency of I2NSF Information and data model: maybe a design team?]

[Adrian Farrel]

Taking John's three points separately (and in reverse order)
 
3) Yes, traceability back from DM to IM is very valuable and is a strong should 
for the WG because the WG has decided that IMs are a deliverable.
 
2) I think we should lean very heavily on RFC3444 for our definition of IM and 
DM. This might not be consistent with every view of those terms, but it is what 
the IETF has consensus on and absent any changes across the OPS area, we should 
stick with it.
 
I am sure that the current documents can be improved to be clearer on what 
information is "in the model" and to separate out other interface-specific 
requirements, but that is "work in progress".
 
1) Consistency across models is important. As is coherence across the whole of 
the I2NSF space. And there will clearly be mapping of information at one 
interface to information at another interface. But I don't quite understand the 
"one IM versus many IMs" discussion. Arguably we could say that the whole 
universe has a single IM, but I think we can also agree that it is convenient 
to break out pieces so that our scope a field of vision is limited. The attempt 
here is to partition the IM into "information modules" that describe the 
information at each interface, and it is convenient to place these pieces 
(modules) in separate documents.
 
Does any of that help?
 
Adrian
 
From: I2nsf [mailto:i2nsf-boun...@ietf.org] On Behalf Of John Strassner
Sent: 16 July 2017 18:36
To: Linda Dunbar; John Strassner
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] need some work to improve the consistency of I2NSF 
Information and data model: maybe a design team?
 
I cannot attend Prague due to family health issues.
 
That being said, I agree with Linda. I see three major problems:
 
   1) There should be one, and only one, information model.
a) It is great to have multiple contributions, but those contributions 
MUST be written to enhance the existing model, not propose a new one
   2) In general, some of the info models are not really **models** per se, but 
rather, requirements for models. 
   3) In general, I cannot trace data model work back to the info model work.
   a) This is especially true for drafts that are trying to use or define 
policies
 
I propose that draft-xibassnez is used for our info model. This means that the 
other info model drafts SHOULD be restructured to add to that draft.
 
I propose that we wait on further data model draft definition until some people 
(I will help) on the design team can formulate guidelines and perhaps examples 
to properly derive data models from our info model.
 
regards,
John
 
On Fri, Jul 14, 2017 at 9:27 AM, Linda Dunbar  wrote:
Thanks to many people contributions. We now have many drafts on the information 
model and data model for I2NSF:
 
Information model:
draft-xibassnez-i2nsf-capability-02
draft-zhang-i2nsf-info-model-monitoring-04
draft-hyun-i2nsf-registration-interface-im-02
draft-kumar-i2nsf-client-facing-interface-im-03
draft-xia-i2nsf-security-policy-object-01
 
Data Model:
draft-hares-i2nsf-capability-data-model-03
draft-jeong-i2nsf-consumer-facing-interface-dm-02
draft-kim-i2nsf-nsf-facing-interface-data-model-02
draft-hyun-i2nsf-registration-interface-dm-01
 
 
But the problem is that they are not all consistent.  Extra work is needed to 
improve the consistency for I2NSF information and data models for both 
Client/Consumer facing and NSF facing interfaces. 
So we are going to form a design team to work on it. 
 
If you are interested in participate, please click on this doodle poll: 
https://doodle.com/poll/4ryrcw3993fbf7ca
 
For people not in Prague, we can set up a Webex for you to call in. 
 
Thank you very much for the contribution. 
 
Linda & Adrian
 

___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf



-- 
regards,
John
___
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf