Subject: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 11 Mar 2016 20:10:33 +0100

Finally went through the whole document. Pffff many many pages.
And sect 4.5 with subsections just  states:

    This section will be completed in the next revision of this
    document.

Oh well

I am not ready to say yes or no for "WG adoption". The document feels very complex
to me. I need to re-read it at least one or two more times in order to get it all.

But I do have some comments/remarks/questions of the bat:
some of this is nits, but since I was composing a list of comments anyways
I figured I might as well add them.
- in the document you speak of cardinality and multiplicity.
    are they used as synonyms of each other, of does one have a different
    meaning than the other?
- on page 12 and 13 you talk about IM and DM and refer to RFC3198.
    I would think that a reference to RFC3444 would also make sense.
    As an informative reference. It explains a lot about the difference
    between the 2.
    Actually, I wonder if referencing 3198 is wise. It also contains a lot of
    stuff that never really took off in IETF or the industry. For exmplae
    it talks about SPPI, PIB and COPS-PR, which we (IETF) are in the process
    of declaring it HISTORIC. So why would we overload younger people
    with all that now more or less irrelevant material?
- page 14:

     In this context, "manage" means that at least create, read,
     query, update, and delete functions are supported.

    Is there a difference between "read" an "query"
    is CRUD not enough?
- page 16

    This principle is one of the key characteristics
    that is NOT followed in [4], [6], [RFC3060], and [RFC3460].

    That may very well be true, but why is this relevant? And why would that
    make RFC3060 and 3460 NORMATIVE references?

    I see some more references to these 2 documents, They all seem to indicate
    that something was wrong in those fcs or that we do things different.
    I do not see why that has to be NORMATIVE

- section: 3.3.5. Association Class
    AM I missing D in the picture? Or am I just not understanding this at all?

- please expand acronym RM-ODP's om page 23

- when I see figure 2, then I wonder why we do not split of EPRIM in to a separate
    document?

- please expand LSIM on page 27

- It seems you want to make absolutely sure that we:
          Please see Appendix A for a comparison to previous work.
    it occurs manty times. oh well

- I do not find this text (on page30):

    It is often necessary to construct groups of policies. The GPIM
    follows [2] and [5], and uses the composite pattern [11] to
    implement this functionality

    easy to read. One has to go to the reference section to figure out
    what (big) documents is refered to. Then, when I see DEN and SID. I start to worry.
    IIRC I once called SID the "spaghetti bowl of spaghetti bowls". COMPLEX and just
    the UNION of everything else as opposed to the INTERSECTION off all other specs.
    But that maybe a personal issue that no one else shares?

- In figure 5
    Why is the left subclass tagged as type C (Concrete) ? It does not have to be, does it?

- When I read on page 38:

    A SUPAPolicySource MAY be mapped to a role (e.g., using the
    role-object pattern [11]);

    Then I get the feeling that [11] would be normative, no? I guess I need to understand
    [11] in order to use that role-object pattern.

- page 50 towards bottom:

    Similarly, all SUPA classes are attributes are both uniquely

    for the first occurence of "are" I suspect s/are/and/ ??

- I see at various places text aka

     SUPAPolicyStructure was abstracted
     from DEN-ng [2], and a version of this class is in the process of
     being added to [5]

    Is that something we need to exactly know for each object? Would it not be better to
    state somewhere in an aknowledgement section or in the introduction that we have build
    on and used some of DEN-ng?

- I see double negation aka:

          which is an enumerated non-negative integer
    Would it not be better and clearer to just say
           whic is  a nonzero positive integer?
    mmm I see that zero is also a value that can occur.
    In SNMP we never wanted to use zero. Because it can often
    occur as an error when not initialized (yet).

- sometimes I see

     If the value of this attribute is true

    other times I see

     If the value of this attribute is TRUE

   I guess it is better to be consistent and choose between the lowercase and uppercase.

- I see (for example) this enumerated list multiple times:

       0:  undefined
       1:  String
       2:  GUID
       3:  UUID
       4:  URI
       5:  FQDN

     In SMI (SNMP) we used Textual Conventions for that. Is there such a thing or
     can/should we consider such a thing for GPIM too?

- I see:

5.3.2.6.2. The Attribute "supaPolExecFailTakeActionName[1..n]"

     This is an optional array of string attributes that identifies the

    Mmmm in the prigrammin languages that I know (not too many I must confess,
    but still multiple), arrays are indexed from [0..n-1]. SO I wonder if this could
    lead to mis-understandings and/or programming errors.

    later on you use [0..n], so maybe this is just a typo.

- section 5.7.2.1
    Pls expand acronums OCL, QVT, SAT that are all use here for the 1st time
    in the document I believe. Maybe a reference to each will also be helpful.

- page 91
    pls expand acronyms DNF and CNF (used for the first time here I believe)

Bert

On 12/02/16 22:26, Joel Halpern wrote:
> Below is the announcement of the revision of the Generic Information Model for the SUPA work.  John has done the heavy lifting on 
> this, with help from Jason and myself.
>
> Over the last several months, we have made a lot of changes to this model.
>
> We really need working group review and comment on this.
>
> We will be working with the team that produced the earlier YANG models to drive a new YANG model that reflects this information 
> model.  So if we have made mistakes here, we need to know ASAP.
>
> In the absence of significant concerns, once we have gotten a YANG model derived, we will also ask for WG adoption of this document.
>
> So please, read it and comment.
>
> Yours,
> Joel
>
>
> -------- Forwarded Message --------
> Subject: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt
> Date: Fri, 12 Feb 2016 11:09:50 -0800
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>         Title           : Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA)
>         Authors         : John Strassner
>                           Joel Halpern
>                           Jason Coleman
>     Filename        : draft-strassner-supa-generic-policy-info-model-04.txt
>     Pages           : 115
>     Date            : 2016-02-12
>
> Abstract:
>    This document defines an information model for representing
>    policies using a common extensible framework that is independent
>    of language, protocol, repository. It is also independent of the
>    level of abstraction of the content and meaning of a policy.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-strassner-supa-generic-policy-info-model/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-strassner-supa-generic-policy-info-model-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-strassner-supa-generic-policy-info-model-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>

---

From: John Strassner <[email-masked]>
Date: Mon, 14 Mar 2016 19:18:55 -0700

Hi Bert,

comments below using <jcs>..</jcs>

...

 - in the document you speak of cardinality and multiplicity.
   are they used as synonyms of each other, of does one have a different
   meaning than the other?
<jcs>
Multiplicity refers to the relationship (i.e., association, aggregation, or
composition) as a whole. It consists of two cardinalities, one for each side
of the relationship. We will update the terminology to clarify this.
</jcs>

 - on page 12 and 13 you talk about IM and DM and refer to RFC3198.
   I would think that a reference to RFC3444 would also make sense.
   As an informative reference. It explains a lot about the difference
   between the 2.
<jcs>
I used RFC3198 because RFC3444 does not provide a definition; it provides
a discussion. In addition, it contains some errors (e.g., it says that UML
is a
"formal language", which is incorrect.

However, your suggestion is a good one - we will work in a reference of
RFC3444 somewhere...
</jcs>

    Actually, I wonder if referencing 3198 is wise. It also contains a lot
of
<jcs>
See above
</jcs>

 - page 14:

   Is there a difference between "read" an "query"
   is CRUD not enough?
<jcs>
"Read" is, at least to me, a simple command to provide a result. In
contrast,
"Query" is a more complex operation that may involve pre- and/or post-
processing of the results of the operation.

Note that many people think of SQL as a query language; in that case, the
definition of query expands to include data definition, data control, and
data
manipulation languages.

Would you like the above text included?
</jcs>

 - page 16

   I see some more references to these 2 documents, They all seem to
indicate
   that something was wrong in those fcs or that we do things different.
   I do not see why that has to be NORMATIVE
<jcs>
This is relevant because it is a key design principle for scalable and
extensible information models.

I'm happy to make PCIM and PCIMe INFORMATIVE, good catch.
</jcs>

 - section: 3.3.5. Association Class
   AM I missing D in the picture? Or am I just not understanding this at
all?
<jcs>
Sorry, D is the association. Fixed.
</jcs>

<jcs>
Done.
</jcs>

 - when I see figure 2, then I wonder why we do not split of EPRIM in to a
separate
   document?
<jcs>
The thinking was:
   1) there would be a lot of repeated text, and
   2) it would be difficult for readers - they would have to have two
documents
       open at the same time to understand the work
</jcs>

 - please expand LSIM on page 27
<jcs>
LSIM was defined on page 11, but sure, no problem
</jcs>

 - It seems you want to make absolutely sure that we:
         Please see Appendix A for a comparison to previous work.
   it occurs manty times. oh well
<jcs>
It occurs 7 times. This happened as other WGs were starting
to use PCIM, and were confused what the difference was
between SUPA and PCIM
</jcs>

   easy to read. One has to go to the reference section to figure out
   what (big) documents is refered to. Then, when I see DEN and SID. I
start to worry.
   IIRC I once called SID the "spaghetti bowl of spaghetti bowls". COMPLEX
and just
   the UNION of everything else as opposed to the INTERSECTION off all
other specs.
   But that maybe a personal issue that no one else shares?
<jcs>
The point was to talk about the composite pattern ([11]) and note that it
is used
in many other works; two of those are [2] and [5].
</jcs>

 - In figure 5
   Why is the left subclass tagged as type C (Concrete) ? It does not have
to be, does it?
<jcs>
Oops, sorry about that, FIXED.
</jcs>

   Then I get the feeling that [11] would be normative, no? I guess I need
to understand
   [11] in order to use that role-object pattern.
<jcs>
[11] defines the original role-object pattern; there are many variants (but
all are
similar). I'll fix the wording.
</jcs>

<jcs>
Oops, good catch. FIXED.
</jcs>

   Is that something we need to exactly know for each object? Would it not
be better to
   state somewhere in an aknowledgement section or in the introduction that
we have build
   on and used some of DEN-ng?
<jcs>
I didn't want to give the impression that everything was DEN-ng, but ok
</jcs>

         which is an enumerated non-negative integer
   Would it not be better and clearer to just say
          whic is  a nonzero positive integer?
   mmm I see that zero is also a value that can occur.
   In SNMP we never wanted to use zero. Because it can often
   occur as an error when not initialized (yet).
<jcs>
Here, we use 0 as an explicit error, and link that to system
initialization. I guess this could be changed if people want it.
</jcs>

 - sometimes I see

   other times I see

  I guess it is better to be consistent and choose between the lowercase
and uppercase.
<jcs>
OK
</jcs>

      0:  undefined
      1:  String
      2:  GUID
      3:  UUID
      4:  URI
      5:  FQDN

    In SMI (SNMP) we used Textual Conventions for that. Is there such a
thing or
    can/should we consider such a thing for GPIM too?
<jcs>
We are trying to make the UML as generic as possible. UML enums complicate
the model, and require relationships that could be misleading to data model
developers that are not well-versed in UML. In the data model, we will use
proper enumerations.
</jcs>

 - I see:

   Mmmm in the prigrammin languages that I know (not too many I must
confess,
   but still multiple), arrays are indexed from [0..n-1]. SO I wonder if
this could
   lead to mis-understandings and/or programming errors.

    later on you use [0..n], so maybe this is just a typo.
<jcs>
Both are UML-ese for defining a collection; it is not referring to indexing
an array
</jcs>

 - section 5.7.2.1
   Pls expand acronums OCL, QVT, SAT that are all use here for the 1st time
   in the document I believe. Maybe a reference to each will also be
helpful.
<jcs>
Good idea, thanks!
</jcs>

 - page 91
   pls expand acronyms DNF and CNF (used for the first time here I believe)
<jcs>
They were defined in 3.1, but agreed, and FIXED
</jcs>

 regards,
John

On Fri, Mar 11, 2016 at 11:10 AM, Bert Wijnen (IETF) <[email-masked]>
wrote:

>> Below is the announcement of the revision of the Generic Information
>> Model for the SUPA work.  John has done the heavy lifting on this, with
>> help from Jason and myself.
>>
>> We will be working with the team that produced the earlier YANG models to
>> drive a new YANG model that reflects this information model.  So if we have
>> made mistakes here, we need to know ASAP.
>>
>> In the absence of significant concerns, once we have gotten a YANG model
>> derived, we will also ask for WG adoption of this document.
>>
>>     Filename        :
>> draft-strassner-supa-generic-policy-info-model-04.txt
>>     Pages           : 115
>>     Date            : 2016-02-12
>>
>> Abstract:

-- 
regards,
John

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Mar 2016 08:10:49 +0100

> However, your suggestion is a good one - we will work in a reference of

RFC 3444 says:

   [...] One of the possibilities to formally
   specify IMs is to use class diagrams of the Unified Modeling Language
   (UML).

Note that RFC 3444 makes a distinction between informally defined IMs
(e.g, using natural language) and formally defined IMs (using a
notational system, i.e, a formalism).

   IMs can be defined in an informal way, using natural languages such
   as English.

   Alternatively, IMs can be defined using a formal language or a semi-
   formal structured language.

Hence, I am not convinced that RFC 3444 contains an _error_.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Mar 2016 09:59:55 +0100

Thanks John,

W.r.t. the below (RFC3198 reference):

Since you (as far as I could tell) only use a couple fo definitions, maybe
it is better (and faster for the reader) if you just repeat them in
the IM document.

Bert
On 15/03/16 03:18, John Strassner wrote:
> a discussion. In addition, it contains some errors (e.g., it says that UML is a

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Mar 2016 10:02:28 +0100

On 15/03/16 03:18, John Strassner wrote:
> "Read" is, at least to me, a simple command to provide a result. In contrast,
> definition of query expands to include data definition, data control, and data
> manipulation languages.
>
Ah. Thanks. I guess it would be good to indeed explain the difference.

Would you see access control to be different for a query as opposed to
a read? That is where my question came from.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Mar 2016 10:05:30 +0100

> I'm happy to make PCIM and PCIMe INFORMATIVE, good catch.
I can see that it may be relevant. but that indeed does not
mean it is normative. I think it can be (for some) extra
background reading for better understanding as to why things
are done here the way they are done.

I think moving it to the informative section would be good.

In the past (when I was still writing lots of code, unfortunately
I am not doing much of that these days), I always looked at the
normative referenes and figured that I better understand those
documents completely before I would start implementing anything.

Thank,
Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Mar 2016 10:09:11 +0100

On 15/03/16 03:18, John Strassner wrote:
>    2) it would be difficult for readers - they would have to have two documents
Mmmmm.... now I am really getting worried.
Are you saying i MUST understand EPRIM in order to
understand GPIM ?????

That would not be good. The other way around, YES.

So if I want to expand GPIM with a IM for declarative,
then (I hope) there should be no need to understand/read
EPRIM. So I would not have to be bothered with it, no?
I should be able to do a DPRIM document without
reading or understanding EPRIM.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Mar 2016 10:12:40 +0100

> LSIM was defined on page 11, but sure, no problem
Sorry. I had missed that one.
In that case then there is no formal need to repeat.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 15 Mar 2016 10:21:44 +0100

On 15/03/16 03:18, John Strassner wrote:
> Both are UML-ese for defining a collection; it is not referring to indexing an array
> </jcs>

Mmmm I I guess I demonstrated, my knowledge about UML is
very limited. But when I see that notation, and the next sentence
is: This is an optional array of string attributes that identifies the
Then is it just me who thinks that [1..n] indicates the index
into the array? Maybe se, then pls ignore. If there are others
who were put on the wrong footing by that, then pls speak up,
because then maybe we should make it clearer.

But still, in some cases you use [1..n] and in other cases [0..n]
So is there a difference between those 2, and if so, what is it?
Pls document (unless this is all 100% clear to UML folk, then
maybe I should just study UML first; I hope not though)

Bert

---

From: John Strassner <[email-masked]>
Date: Tue, 15 Mar 2016 14:02:49 -0700

RFC3444 says:
  "One of the possibilities to formally specify IMs is to use class
   diagrams of the Unified Modeling Language (UML)."

Since UML is **not** a formal language, it is therefore an error
to state that an IM can be formally specified using UML

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 15 Mar 2016 14:04:19 -0700

Hi Bert,

OK, thanks for your help. DONE.

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 15 Mar 2016 14:08:51 -0700

You're welcome. Apologies for not being more clear in the first place.

I would indeed see access control for a query as different; read is
different than execute, for example. When I implemented RBAC and
ABAC systems, we often made separate privileges for query, due to
the additional processing involved.

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 15 Mar 2016 14:10:34 -0700

For the record, I agree with you and Joel - these should be informative.
Sorry!

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 15 Mar 2016 14:22:39 -0700

On 15/03/16 03:18, John Strassner wrote:
>>> - when I see figure 2, then I wonder why we do not split of EPRIM
>>> in to a separate  document?
>>   < jcs>
>>   The thinking was:
>>         documents open at the same time to understand the work
>>   < /jcs>

No, I MUST understand GPIM to understand EPRIM (since EPRIM
extends GPIM). Note that this is a proper extension, as the EPRIM
does not define any new classes that are not subclassed from a
GPIM class.

>   reading or understanding EPRIM.

Yes, if you want to extend the GPIM, you do not need to
use the EPRIM.

Note that you could further refine the EPRIM as well.

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 15 Mar 2016 14:24:28 -0700

Hi Bert,

this is a good observation. We will better document these
semantics. And you're right, there should be no need for
you to study UML...

regards,
John

-- 
regards,
John

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2016 12:13:42 +0100

The context of the sentence in RFC 3444 is in contrast to information
models informally written in free form text. UML does add a formalism
and hence the model is _formally specified_. (Whether UML is a formal
language is a different question and likely depends on the definition
of 'formal language' we would have to agree on.) I disagree RFC 3444
has an error here. (But all this is likely not relevant for SUPA so
lets just disagree.)

/js

---

From: Zhoutianran <[email-masked]>
Date: Wed, 16 Mar 2016 16:36:15 +0000

My concern is I am afraid when I am reading your document, I am studying UML.

________________________________
发件人: Supa [[email-masked]] 代表 John Strassner [[email-masked]]
发送时间: 2016年3月16日 5:24
收件人: Bert Wijnen (IETF); John Strassner
抄送: Jason Coleman; Joel Halpern; [email-masked]
主题: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt

Hi Bert,

regards,
John

On Tue, Mar 15, 2016 at 2:21 AM, Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
On 15/03/16 03:18, John Strassner wrote:

 - I see:

Bert

--
regards,
John

---

From: Zhoutianran <[email-masked]>
Date: Wed, 16 Mar 2016 16:40:49 +0000

I would like to learn what makes a formal language.

If IM cannot be formally specified using UML, then in what way we can formally describe the IM?

Thanks,

Tianran

________________________________
发件人: Supa [[email-masked]] 代表 John Strassner [[email-masked]]
发送时间: 2016年3月16日 5:02
收件人: Juergen Schoenwaelder; John Strassner; Bert Wijnen (IETF); Jason Coleman; Joel Halpern; [email-masked]
主题: Re: [Supa] Fwd: I-D Action: draft-strassner-supa-generic-policy-info-model-04.txt

RFC3444 says:

On Tue, Mar 15, 2016 at 12:10 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

RFC 3444 says:

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 16 Mar 2016 09:50:54 -0700

That could apply to sections 3.2.3 and 3.3 specifically; otherwise, I
fail to understand your concern.

On Wed, Mar 16, 2016 at 9:36 AM, Zhoutianran <[email-masked]> wrote:

> ------------------------------
> *发件人:* Supa [[email-masked]] 代表 John Strassner [[email-masked]]
> *发送时间:* 2016年3月16日 5:24
> *收件人:* Bert Wijnen (IETF); John Strassner
> *抄送:* Jason Coleman; Joel Halpern; [email-masked]
> *主题:* Re: [Supa] Fwd: I-D Action:

-- 
regards,
John