Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g92DNkic025853 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Oct 2002 15:23:47 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g92DNac03705; Wed, 2 Oct 2002 09:23:36 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 15:23:35 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , bwijnen@lucent.com Cc: Network Management Research Group Date: Wed, 2 Oct 2002 15:23:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] RE: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Thanks, will do. So it will be on IESG agenda on 17 Oct. Thanks, Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: woensdag 2 oktober 2002 15:01 > To: bwijnen@lucent.com > Cc: Network Management Research Group > Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] > > > > >>>>> Wijnen, Bert (Bert) writes: > > Bert> So the question: should I expect another rev, or do you think > Bert> you/we appropriately answered all questions and do not need > Bert> another rev. I need to know by the end of the week. If so, then > Bert> I can put it on IESG agenda for 17 October > > I have gone through all messages generated on this subject and my > conclusion is that we do not have to spin another revision. The only > change I have is an editorial one (usage of hyphens) which we can > probably handle during the RFC author review period. Given this, I > would be happy if you can put this document on the IESG agenda. > > /js > > -- > Juergen Schoenwaelder > > > Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g92D1E9b024120 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 2 Oct 2002 15:01:14 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g92D1BHt008821 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 2 Oct 2002 15:01:11 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id g92D1BH5008818; Wed, 2 Oct 2002 15:01:11 +0200 Date: Wed, 2 Oct 2002 15:01:11 +0200 Message-Id: <200210021301.g92D1BH5008818@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: Network Management Research Group In-reply-to: (bwijnen@lucent.com) References: X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Subject: [nmrg] Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Wijnen, Bert (Bert) writes: Bert> So the question: should I expect another rev, or do you think Bert> you/we appropriately answered all questions and do not need Bert> another rev. I need to know by the end of the week. If so, then Bert> I can put it on IESG agenda for 17 October I have gone through all messages generated on this subject and my conclusion is that we do not have to spin another revision. The only change I have is an editorial one (usage of hyphens) which we can probably handle during the RFC author review period. Given this, I would be happy if you can put this document on the IESG agenda. /js -- Juergen Schoenwaelder Received: from cosium01.intelliden.net ([12.41.186.248]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g92AZn6n016592; Wed, 2 Oct 2002 12:35:50 +0200 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 04:35:44 -0600 Message-ID: From: John Strassner To: Juergen Schoenwaelder , Network Management Research Group Subject: RE: [nmrg] [remoore@us.ibm.com: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] Date: Wed, 2 Oct 2002 04:35:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C269FF.74758130" X-Spam-Status: No, hits=2.9 required=5.0 tests=SUBJ_HAS_SPACES,MIME_NULL_BLOCK,MAILTO_LINK version=2.20 X-Spam-Level: ** Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C269FF.74758130 Content-Type: text/plain Hi Juergen, Here's my comments; I'm pulling up Bob's points for easier reference. Bob writes: 1. Section 3, first paragraph: "An IM can be implemented in different ways and mapped upon different protocols; IMs are therefore protocol neutral." In my experience it isn't quite so clear-cut. The reality is that when a group of people experienced in a given DM set out to define an IM, the IM takes on the flavor of the DM. (I'm not suggesting anything nefarious here - - more like what happens when you don't clean out your coffee-maker well enough before using it to brew tea.) So, for example, there are "whiffs" of LDAP in some parts of the DMTF CIM model. I disagree. If an IM is influenced by people experienced in writing DMs, then shame on them for not keeping the IM protocol neutral. Past mistakes may have been done by groups in the past, but I would hope that we would do better in the future. The IMs being defined in the TMF are indeed protocol neutral and independent of DM influences. Furthermore, there are strong database influences in CIM (the concept of "keys", the concept of weak relationships, etc.). I note that neither of these are pertinent to LDAP, and am not sure what Bob is referring to. Bob writes: But I'm not just making a point about what people do; there are objective differences here as well. A figure like the one at the top of page 4 suggests that the mappings to the three IMs are equally easy, This is certainly not the case. If, for example, you IM has the datatype "real" in it, it's much easier to map it to GDMO than it is to map it to SMI. I disagree. An IM should be free to use a standard set of datatypes, such as those defined in the UML. Mapping to a DM may be hard (e.g., good luck mapping to a real in LDAP!) but that should not be the problem of the IM - that should instead be the problem of the mapping between the IM and a DM. Bob writes: If the scope of this document is *just* about defining the two terms IM and DM, then maybe what's there is OK. But to the extent that it slides over into being a BCP, then I think it would be better if it acknowledged these realities. I thought that this draft was going to be issued as informational. If it is going to be issued as a BCP, then it needs more work to show how best practices are used to constuct IMs and DMs as well as mappings between them. I don't think that the above two issues need mentioning, but wouldn't object if additional clarifications were added. Bob writes: 2. It seems a little odd that the RFC 2252 DM for LDAP isn't mentioned in any of the examples, since, between the IETF and DMTF, that's the case where (to my knowledge) we have the most extensive set of IM-->DM mappings. One could certainly mention the LDAP DM. But the LDAP DM is NOT defined in 2252! All 2252 does is define attribute syntaxes for use with the protocol. I think that we should leave well enough alone... regards, John John Strassner Chief Strategy Officer Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 USA phone: +1.719.785.0648 FAX: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] Sent: Tuesday, September 24, 2002 6:09 AM To: Network Management Research Group Subject: [nmrg] [remoore@us.ibm.com: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] Any comments on this? /js ------- Start of forwarded message ------- Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC) To: "Wijnen, Bert (Bert)" Cc: mibs@ops.ietf.org From: Robert Moore Date: Fri, 20 Sep 2002 12:21:34 -0400 Sender: owner-mibs@ops.ietf.org Precedence: bulk X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Bert, I think this is a useful document, that definitely warrants publication. I have only a couple of relatively minor comments: 1. Section 3, first paragraph: "An IM can be implemented in different ways and mapped upon different protocols; IMs are therefore protocol neutral." In my experience it isn't quite so clear-cut. The reality is that when a group of people experienced in a given DM set out to define an IM, the IM takes on the flavor of the DM. (I'm not suggesting anything nefarious here - - more like what happens when you don't clean out your coffee-maker well enough before using it to brew tea.) So, for example, there are "whiffs" of LDAP in some parts of the DMTF CIM model. But I'm not just making a point about what people do; there are objective differences here as well. A figure like the one at the top of page 4 suggests that the mappings to the three IMs are equally easy, This is certainly not the case. If, for example, you IM has the datatype "real" in it, it's much easier to map it to GDMO than it is to map it to SMI. If the scope of this document is *just* about defining the two terms IM and DM, then maybe what's there is OK. But to the extent that it slides over into being a BCP, then I think it would be better if it acknowledged these realities. 2. It seems a little odd that the RFC 2252 DM for LDAP isn't mentioned in any of the examples, since, between the IETF and DMTF, that's the case where (to my knowledge) we have the most extensive set of IM-->DM mappings. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com ------- End of forwarded message ------- -- !! This message is brought to you via the `nmrg' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. ------_=_NextPart_001_01C269FF.74758130 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [nmrg] [remoore@us.ibm.com: Re: draft-irtf-nmrg-im-dm-02.txt = (Informational RFC)]

Hi Juergen,

Here's my comments; I'm pulling up Bob's points for = easier reference.

Bob writes:
1. Section 3, first paragraph: "An IM can be = implemented in different ways and mapped upon different protocols; IMs = are therefore protocol neutral." In my experience it isn't quite = so clear-cut.  The reality is that when a group of people = experienced in a given DM set out to define an IM, the IM takes on the = flavor of the DM.  (I'm not suggesting anything nefarious here - - = more like what happens when you don't clean out your coffee-maker well = enough before using it to brew tea.)  So, for example, there are = "whiffs" of LDAP in some parts of the DMTF CIM = model.

<js>
I disagree. If an IM is influenced by people = experienced in writing DMs, then shame on them for not keeping the IM = protocol neutral. Past mistakes may have been done by groups in the = past, but I would hope that we would do better in the future. The IMs = being defined in the TMF are indeed protocol neutral and independent of = DM influences.

Furthermore, there are strong database influences in = CIM (the concept of "keys", the concept of weak = relationships, etc.). I note that neither of these are pertinent to = LDAP, and am not sure what Bob is referring to. </js>

Bob writes:
But I'm not just making a point about what people = do; there are objective differences here as well.  A figure like = the one at the top of page 4 suggests that the mappings to the three = IMs are equally easy,  This is certainly not the case.  If, = for example, you IM has the datatype "real" in it, it's much = easier to map it to GDMO than it is to map it to SMI.

<js>
I disagree. An IM should be free to use a standard = set of datatypes, such as those defined in the UML. Mapping to a DM may = be hard (e.g., good luck mapping to a real in LDAP!) but that should = not be the problem of the IM - that should instead be the problem of = the mapping between the IM and a DM. </js>

Bob writes:
If the scope of this document is *just* about = defining the two terms IM and DM, then maybe what's there is OK.  = But to the extent that it slides over into being a BCP, then I think it = would be better if it acknowledged these realities.

<js>
I thought that this draft was going to be issued as = informational. If it is going to be issued as a BCP, then it needs more = work to show how best practices are used to constuct IMs and DMs as = well as mappings between them.

I don't think that the above two issues need = mentioning, but wouldn't object if additional clarifications were = added. </js>

Bob writes:
2. It seems a little odd that the RFC 2252 DM for = LDAP isn't mentioned in any of the examples, since, between the IETF = and DMTF,  that's the case where (to my knowledge) we have the = most extensive set of IM-->DM mappings.

<js>
One could certainly mention the LDAP DM. But the = LDAP DM is NOT defined in 2252! All 2252 does is define attribute = syntaxes for use with the protocol. I think that we should leave well = enough alone...</js>

regards,
John
 
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO  80903  USA
phone: +1.719.785.0648
  FAX: +1.719.785.0644
email: john.strassner@intelliden.com
 


-----Original Message-----
From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
Sent: Tuesday, September 24, 2002 6:09 AM
To: Network Management Research Group
Subject: [nmrg] [remoore@us.ibm.com: Re: = draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]



Any comments on this?

/js

------- Start of forwarded message -------
Subject: Re: draft-irtf-nmrg-im-dm-02.txt = (Informational RFC)
To: "Wijnen, Bert (Bert)" = <bwijnen@lucent.com>
Cc: mibs@ops.ietf.org
From: Robert Moore <remoore@us.ibm.com>
Date: Fri, 20 Sep 2002 12:21:34 -0400
Sender: owner-mibs@ops.ietf.org
Precedence: bulk
X-Spam-Status: No, hits=3D0.0 required=3D5.0 = tests=3D version=3D2.20

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;   


Bert,

I think this is a useful document, that definitely = warrants publication.  I have only a couple of relatively minor = comments:

1. Section 3, first paragraph: "An IM can be = implemented in different ways and mapped upon different protocols; IMs = are therefore protocol neutral." In my experience it isn't quite = so clear-cut.  The reality is that when a group of people = experienced in a given DM set out to define an IM, the IM takes on the = flavor of the DM.  (I'm not suggesting anything nefarious = here

- - more like what happens when you don't clean out = your coffee-maker well enough before using it to brew tea.)  So, = for example, there are "whiffs" of LDAP in some parts of the = DMTF CIM model.

But I'm not just making a point about what people do; = there are objective differences here as well.  A figure like the = one at the top of page 4 suggests that the mappings to the three IMs = are equally easy,  This is certainly not the case.  If, for = example, you IM has the datatype "real" in it, it's much = easier to map it to GDMO than it is to map it to SMI.

If the scope of this document is *just* about = defining the two terms IM and DM, then maybe what's there is OK.  = But to the extent that it slides over into being a BCP, then I think it = would be better if it acknowledged these realities.

2. It seems a little odd that the RFC 2252 DM for = LDAP isn't mentioned in any of the examples, since, between the IETF = and DMTF,  that's the case where (to my knowledge) we have the = most extensive set of IM-->DM mappings.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com
------- End of forwarded message -------
--
!! This message is brought to you via the `nmrg' = mailing list. !! Please do not reply to this message to unsubscribe. To = unsubscribe or adjust !! your settings, send a mail message to = <nmrg-request@ibr.cs.tu-bs.de> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.=

------_=_NextPart_001_01C269FF.74758130-- Received: from cosium01.intelliden.net ([12.41.186.248]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g92AZM6n016553; Wed, 2 Oct 2002 12:35:23 +0200 Received: by cosium01.intelliden.net with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Oct 2002 04:35:04 -0600 Message-ID: From: John Strassner To: Aiko Pras , Juergen Schoenwaelder Cc: Network Management Research Group Subject: RE: [nmrg] [remoore@us.ibm.com: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] Date: Wed, 2 Oct 2002 04:34:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C269FF.59D2A830" X-Spam-Status: No, hits=2.9 required=5.0 tests=SUBJ_HAS_SPACES,MIME_NULL_BLOCK,MAILTO_LINK version=2.20 X-Spam-Level: ** Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C269FF.59D2A830 Content-Type: text/plain I'm happy to provide references to LDAP, but why? It is no more nor less important than any other DM mapping (though proper LDAP mapping is probably less understood. ;-) ). Still, if you want this, please let me know and I'll help - I'm the co-chair of LDUP and on the LDAP Directorate (similar to the MIB Doctors). regards, John John Strassner Chief Strategy Officer Intelliden Corporation 90 South Cascade Avenue Colorado Springs, CO 80903 USA phone: +1.719.785.0648 FAX: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Aiko Pras [mailto:pras@ctit.utwente.nl] Sent: Wednesday, September 25, 2002 4:23 AM To: Juergen Schoenwaelder Cc: Network Management Research Group Subject: Re: [nmrg] [remoore@us.ibm.com: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] Comments inline Juergen Schoenwaelder wrote: > Any comments on this? > > /js > > ------- Start of forwarded message ------- > Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC) > To: "Wijnen, Bert (Bert)" > Cc: mibs@ops.ietf.org > From: Robert Moore > Date: Fri, 20 Sep 2002 12:21:34 -0400 > Sender: owner-mibs@ops.ietf.org > Precedence: bulk > X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 > > > > > > > Bert, > > I think this is a useful document, that definitely warrants > publication. I have only a couple of relatively minor comments: > > 1. Section 3, first paragraph: "An IM can be implemented in different > ways and mapped upon different protocols; IMs are therefore protocol > neutral." In my experience it isn't quite so clear-cut. The reality > is that when a group of people experienced in a given DM set out to > define an IM, the IM takes on the flavor of the DM. (I'm not > suggesting anything nefarious here > - - more like what happens when you don't clean out your coffee-maker well > enough before using it to brew tea.) So, for example, there are "whiffs" > of LDAP in some parts of the DMTF CIM model. > > But I'm not just making a point about what people do; there are > objective differences here as well. A figure like the one at the top > of page 4 suggests that the mappings to the three IMs are equally > easy, That is not what the picture is supposed to say. The picture says something about the (theoretical) possibility to map an IM to multiple DMs. I agree that certain mappings are easier then others, but again, that was not what the picture was intended to show. > This is > certainly not the case. If, for example, you IM has the datatype > "real" in it, it's much easier to map it to GDMO than it is to map it > to SMI. > > If the scope of this document is *just* about defining the two terms > IM and DM, then maybe what's there is OK. But to the extent that it > slides over into being a BCP, then I think it would be better if it > acknowledged these realities. I believe the intention is an informational RFC, not a BCP > > 2. It seems a little odd that the RFC 2252 DM for LDAP isn't mentioned > in any of the examples, since, between the IETF and DMTF, that's the > case where (to my knowledge) we have the most extensive set of IM-->DM > mappings. The "RFC" describes the results of a previous NMRG meeting. It would have been nice if we would have invited more LDAP experts; in that case we would surely have come up with better references to LDAP -- !! This message is brought to you via the `nmrg' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. ------_=_NextPart_001_01C269FF.59D2A830 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [nmrg] [remoore@us.ibm.com: Re: draft-irtf-nmrg-im-dm-02.txt = (Informational RFC)]

I'm happy to provide references to LDAP, but why? It = is no more nor less important than any other DM mapping (though proper = LDAP mapping is probably less understood. ;-) ). Still, if you want = this, please let me know and I'll help - I'm the co-chair of LDUP and = on the LDAP Directorate (similar to the MIB Doctors).

regards,
John
 
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO  80903  USA
phone: +1.719.785.0648
  FAX: +1.719.785.0644
email: john.strassner@intelliden.com
 


-----Original Message-----
From: Aiko Pras [mailto:pras@ctit.utwente.nl] =
Sent: Wednesday, September 25, 2002 4:23 AM
To: Juergen Schoenwaelder
Cc: Network Management Research Group
Subject: Re: [nmrg] [remoore@us.ibm.com: Re: = draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]


Comments inline

Juergen Schoenwaelder wrote:
> Any comments on this?
>
> /js
>
> ------- Start of forwarded message = -------
> Subject: Re: draft-irtf-nmrg-im-dm-02.txt = (Informational RFC)
> To: "Wijnen, Bert (Bert)" = <bwijnen@lucent.com>
> Cc: mibs@ops.ietf.org
> From: Robert Moore = <remoore@us.ibm.com>
> Date: Fri, 20 Sep 2002 12:21:34 -0400
> Sender: owner-mibs@ops.ietf.org
> Precedence: bulk
> X-Spam-Status: No, hits=3D0.0 required=3D5.0 = tests=3D version=3D2.20
>
>          = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;     
>          = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;     
>          = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;     
>
>
> Bert,
>
> I think this is a useful document, that = definitely warrants
> publication.  I have only a couple of = relatively minor comments:
>
> 1. Section 3, first paragraph: "An IM can = be implemented in different
> ways and mapped upon different protocols; IMs = are therefore protocol
> neutral." In my experience it isn't quite = so clear-cut.  The reality
> is that when a group of people experienced in a = given DM set out to
> define an IM, the IM takes on the flavor of the = DM.  (I'm not
> suggesting anything nefarious here
> - - more like what happens when you don't clean = out your coffee-maker well
> enough before using it to brew tea.)  So, = for example, there are "whiffs"
> of LDAP in some parts of the DMTF CIM = model.
>
> But I'm not just making a point about what = people do; there are
> objective differences here as well.  A = figure like the one at the top
> of page 4 suggests that the mappings to the = three IMs are equally
> easy,
That is not what the picture is supposed to say. The = picture says
something about the (theoretical) possibility to map = an IM to multiple
DMs. I agree that certain mappings are easier then = others, but again,
that was not what the picture was intended to = show.

>  This is
> certainly not the case.  If, for example, = you IM has the datatype
> "real" in it, it's much easier to map = it to GDMO than it is to map it
> to SMI.
>
> If the scope of this document is *just* about = defining the two terms
> IM and DM, then maybe what's there is OK.  = But to the extent that it
> slides over into being a BCP, then I think it = would be better if it
> acknowledged these realities.
I believe the intention is an informational RFC, not = a BCP

>
> 2. It seems a little odd that the RFC 2252 DM = for LDAP isn't mentioned
> in any of the examples, since, between the IETF = and DMTF,  that's the
> case where (to my knowledge) we have the most = extensive set of IM-->DM
> mappings.
The "RFC" describes the results of a = previous NMRG meeting. It would
have been
nice if we would have invited more LDAP experts; in = that case we would
surely
have come up with better references to LDAP

--
!! This message is brought to you via the `nmrg' = mailing list. !! Please do not reply to this message to unsubscribe. To = unsubscribe or adjust !! your settings, send a mail message to = <nmrg-request@ibr.cs.tu-bs.de> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.=

------_=_NextPart_001_01C269FF.59D2A830--