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

From: "jmh.direct" <[email-masked]>
Date: Tue, 15 Mar 2016 12:11:05 +0100

With regard to splitting  (or not) EPRIM from GPIM, there is a tension.  On one hand, you don't need to understand EPRIM to understand GPIM.  But people seem to find the details useful for understanding why the GPIM has the shown structure.  Some folks are even saying they need more details to understand it.So while we could split the two, I think people would find it harder to understand.
Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Bert Wijnen (IETF)" <[email-masked]> Date: 3/15/2016  10:09 AM  (GMT+01:00) To: John Strassner <[email-masked]>, Jason Coleman <[email-masked]> Cc: Joel Halpern <[email-masked]>, [email-masked] Subject: Re: [Supa] Fwd: I-D Action:
  draft-strassner-supa-generic-policy-info-model-04.txt 
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:
>    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>
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: "jmh.direct" <[email-masked]>
Date: Tue, 15 Mar 2016 12:37:03 +0100

Those should be informative references.  Sorry.Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Bert Wijnen (IETF)" <[email-masked]> Date: 3/15/2016  10:05 AM  (GMT+01:00) To: John Strassner <[email-masked]>, Jason Coleman <[email-masked]> Cc: Joel Halpern <[email-masked]>, [email-masked] Subject: Re: [Supa] Fwd: I-D Action:
  draft-strassner-supa-generic-policy-info-model-04.txt 
On 15/03/16 03:18, John Strassner wrote:
>
>  - 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
> <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>
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