Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
From: Margaret Wasserman <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: "J.P. Martin-Flatin" <[email-masked]>, Network Management Research Group <[email-masked]>
Date: Thu, 26 Sep 2002 11:25:10 -0400
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

>Perhaps changing the wording to something like "the SMIng being
>developed by the IRTF NMRG group" would suffice?

Or why not use an example for which you can actually site a reference?

Although I raised this issue, I don't really care about it enough to
fight over it.  Bert's proposal (basically, just leave it in and
don't worry about it) is fine with me.

Margaret

Date: Wed, 25 Sep 2002 15:01:48 -0400
From: "Dave Sidor" <[email-masked]>
Organization: Nortel Networks
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt  (Informational RFC)]
Sender: [email-masked]

Juergen et al,

See my comments below.

Dave

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)" <[email-masked]>
> Cc: [email-masked]
> From: Robert Moore <[email-masked]>
> Date: Fri, 20 Sep 2002 12:21:34 -0400
> Sender: [email-masked]
> 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.

Two comments:

1) I like to make a distinction between protocol-neutral and
protocol-independent information models, with the latter capable of
being mapped onto any protocol while the former is designed to be mapped
onto a specified set of protocols. However no one else follows this
distinction and so I generally assume they are synonymous in discussions
with others.

2) Whether or not, a protocol-neutral/independent informational model is
biased towards one or more protocols (and associated interface
definition languages) depends on the organization that produced it and
its associated guidelines. Such bias also might be said to be
protocol-neutral or protocol-specific and is usually related to the
language used to describe the information model.

An example of a protocol-neutral bias is the use of UML. Most of the
telecom standards organizations I am familiar with are in a sense biased
towards object-oriented protocols due to their use of UML as the
information model descriptive langauge: it is easier to use UML-based
class descriptions to produce object-oriented data models.

Bias towards one protocol (Bob's example of coffee and tea) however is
much more constraining and should be avoided. At least one organization
I know of exhibited its bias towards a specific protocol by creating an
information model descriptive language built on syntax from that
protocol. Though it allowed other protocols as well, mapping onto them
was not as easy. 

In 3GPP, the protocol-neutral information models are described with UML
(and other mechanisms as well) which minimizes any protocol-specific
bias. To ensure consistency between the information and data models, the
former cannot be published unless accompanied by at least one of the
latter. This rule also allows any pecularities in applying the data
model descriptive language to create the data model to be compensated
for by tweaking the information model, while still ensuring the
information model governs the functionality included in the data model.

Bottom line: Bias in creating information models is always possible and
sometimes deliberate, but its undesirable aspects can be minmized via
the proper guidelines.

> 
> 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.

As noted above, there is always the possibility of bias, but this does
not negate the benefits of distingushing between information and data
models which is one of the points of the RFC.

> 
> 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
> [email-masked]
> ------- 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 <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Date: Wed, 25 Sep 2002 17:47:12 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> Good idea. I suggest the creation of section "Old Internet-Drafts"
JP> between "Work in Progress" and "Presentations". As far as I know,
JP> I-Ds are the only NMRG documents to have a short lifetime.

I started to collect old expired NMRG IDs on the web page since this
is in general useful. However, I do not consider this to be a stable
reference.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Wed, 25 Sep 2002 17:19:05 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt ( Informational RFC)]
Sender: [email-masked]

>>>>> Wijnen, Bert (Bert) writes:

Bert> Also having seen follow on messages from JP and Phil, and
Bert> Juergen, I wonder if the answer to Margaret could be:

Bert> - The paragraph that talks about that SMIng lanaguage in fact
Bert> explains what that language (for which we have not formal/stable
Bert> reference) was trying to achive. And in the context that is the
Bert> important message.  

Very well said. 

[...]

Bert> So we intend to make no change.

This is what I prefer.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Wed, 25 Sep 2002 16:16:03 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: IRTF Network Management Research Group <[email-masked]>
Subject: [nmrg] WSDL and XML
Sender: [email-masked]

Further to our 11th meeting in Osnabrueck, I thought this may be of 
interest to some of you. The Infoset spec is available at:

   http://www.w3.org/TR/xml-infoset/

JP

-------- Original Message --------
Subject: RE: XML and SOAP constraints? (was RE: WSA constraints)
Resent-Date: Mon, 23 Sep 2002 18:59:11 -0400 (EDT)
Resent-From: [email-masked]
Date: Mon, 23 Sep 2002 15:58:38 -0700
From: Ugo Corda <[email-masked]>
To: "'Champion, Mike'" <[email-masked]>, [email-masked]

 >is WSDL defined in terms of XML syntax, or the Infoset?

WSDL 1.1 was defined in terms of XML syntax, but WSDL 1.2 is based on the
Infoset (even though the Draft's language might not have been completely
converted to only using Infoset terms yet).

Ugo

Date: Wed, 25 Sep 2002 15:40:01 +0200
From: Aiko Pras <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: Juergen Schoenwaelder <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt ( Informational RFC)]
Sender: [email-masked]

Wijnen, Bert (Bert) wrote:

> So we intend to make no change.

OK

Aiko

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Aiko Pras <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: RE: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt ( Informational RFC)]
Date: Wed, 25 Sep 2002 15:34:20 +0200
Sender: [email-masked]

> > ------- Start of forwarded message -------
> > Date: Fri, 20 Sep 2002 11:39:16 -0400
> > To: "Wijnen, Bert (Bert)" <[email-masked]>
> > From: Margaret Wasserman <[email-masked]>
> > Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
> > Cc: [email-masked]
> > 
> > At 10:10 AM 9/20/02, Wijnen, Bert (Bert) wrote:
> > 
> >>Hi MIB-ers
> >>
> >>I expect/suspect that this will end up on my desk for AD-review.
> >>So whoever has not seen it or commented on it, pls take a look
> >>and let me know if you have any serious issues or if you feel
> >>this is good work/information that you support.
> > 
> > 
> > The document is generally interesting and informative.
> > 
> > However, it uses the "SMIng developed by the IRTF NMRG group"
> > as an example, without siting any reference documents.  The
> > discussion should be removed or a normative reference to the
> > NMRG version of SMIng should be added.
> > 
> > Margaret
> > ------- End of forwarded message -------
> 
> Aiko:
>
> Probably the NMRG website should have an additional page with "outdated" 
> documents, like old internet-drafts. We could then reference that page.
>
Also having seen follow on messages from JP and Phil, and Juergen, I wonder
if the answer to Margaret could be:

- The paragraph that talks about that SMIng lanaguage in fact explains
  what that language (for which we have not formal/stable reference) was
  trying to achive. And in the context that is the important message.
- We cannot have normative references to "work in Progress" documents,
  but we could add an informative reference to it, it would only
  list the title and the "work in progress" statement and it would
  not list a read draft filename. (if you put it in teh I-D, then RFC
  editor tends to change the name in "work in progress".
- So the pssoible informative reference would not really help get any
  more detail I suspect.

So we intend to make no change.

Bert

To: Juergen Schoenwaelder <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] 
Date: Wed, 25 Sep 2002 09:09:26 -0400
From: Phil Shafer <[email-masked]>
Sender: [email-masked]

Juergen Schoenwaelder writes:
>Theory versus practice. Take an issue of IEEE Communications for
>example and count the number of IDs cited there...

Is the rfc-editor more concerned about this than ieee? I could only
find two rfcs that refer to drafts (2150 and 2189). No clue why these
exceptions were made.....

Thanks,
 Phil

Date: Wed, 25 Sep 2002 14:58:04 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

>>>>> Phil Shafer writes:

Phil> rfc2026 says:

[...]

Theory versus practice. Take an issue of IEEE Communications for
example and count the number of IDs cited there...

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

To: "J.P. Martin-Flatin" <[email-masked]>
cc: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)] 
Date: Wed, 25 Sep 2002 08:36:56 -0400
From: Phil Shafer <[email-masked]>
Sender: [email-masked]

"J.P. Martin-Flatin" writes:
>Good idea. I suggest the creation of section "Old Internet-Drafts" between 
>"Work in Progress" and "Presentations". As far as I know, I-Ds are the only 
>NMRG documents to have a short lifetime.

rfc2026 says:

  2.2  Internet-Drafts
   ...
   An Internet-Draft is NOT a means of "publishing" a specification;
   specifications are published through the RFC mechanism described in
   the previous section.  Internet-Drafts have no formal status, and are
   subject to change or removal at any time.

      ********************************************************
      *                                                      *
      *   Under no circumstances should an Internet-Draft    *
      *   be referenced by any paper, report, or Request-    *
      *   for-Proposal, nor should a vendor claim compliance *
      *   with an Internet-Draft.                            *
      *                                                      *
      ********************************************************

   Note: It is acceptable to reference a standards-track specification
   that may reasonably be expected to be published as an RFC using the
   phrase "Work in Progress"  without referencing an Internet-Draft.
   This may also be done in a standards track document itself  as long
   as the specification in which the reference is made would stand as a
   complete and understandable document with or without the reference to
   the "Work in Progress".

Perhaps changing the wording to something like "the SMIng being
developed by the IRTF NMRG group" would suffice?

Thanks,
 Phil

Date: Wed, 25 Sep 2002 14:08:41 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

Good idea. I suggest the creation of section "Old Internet-Drafts" between 
"Work in Progress" and "Presentations". As far as I know, I-Ds are the only 
NMRG documents to have a short lifetime.

JP

Aiko Pras wrote:
> Probably the NMRG website should have an additional page with "outdated" 
> documents, like old internet-drafts. We could then reference that page.
> 
> Aiko
> 
> Juergen Schoenwaelder wrote:
> 
>> Any comments on this?
>>
>> /js
>>
>> ------- Start of forwarded message -------
>> Date: Fri, 20 Sep 2002 11:39:16 -0400
>> To: "Wijnen, Bert (Bert)" <[email-masked]>
>> From: Margaret Wasserman <[email-masked]>
>> Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
>> Cc: [email-masked]
>> In-Reply-To: <[email-masked]
>>  .lucent.com>
>> Sender: [email-masked]
>> Precedence: bulk
>> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
>>
>> At 10:10 AM 9/20/02, Wijnen, Bert (Bert) wrote:
>>
>>> Hi MIB-ers
>>>
>>> I expect/suspect that this will end up on my desk for AD-review.
>>> So whoever has not seen it or commented on it, pls take a look
>>> and let me know if you have any serious issues or if you feel
>>> this is good work/information that you support.
>>
>>
>>
>> The document is generally interesting and informative.
>>
>> However, it uses the "SMIng developed by the IRTF NMRG group"
>> as an example, without siting any reference documents.  The
>> discussion should be removed or a normative reference to the
>> NMRG version of SMIng should be added.
>>
>> Margaret
>> ------- End of forwarded message -------
> 
> 
> 

Date: Wed, 25 Sep 2002 12:25:31 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

Probably the NMRG website should have an additional page with "outdated" 
documents, like old internet-drafts. We could then reference that page.

Aiko

Juergen Schoenwaelder wrote:
> Any comments on this?
> 
> /js
> 
> ------- Start of forwarded message -------
> Date: Fri, 20 Sep 2002 11:39:16 -0400
> To: "Wijnen, Bert (Bert)" <[email-masked]>
> From: Margaret Wasserman <[email-masked]>
> Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
> Cc: [email-masked]
> In-Reply-To: <[email-masked]
>  .lucent.com>
> Sender: [email-masked]
> Precedence: bulk
> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
> 
> At 10:10 AM 9/20/02, Wijnen, Bert (Bert) wrote:
> 
>>Hi MIB-ers
>>
>>I expect/suspect that this will end up on my desk for AD-review.
>>So whoever has not seen it or commented on it, pls take a look
>>and let me know if you have any serious issues or if you feel
>>this is good work/information that you support.
> 
> 
> The document is generally interesting and informative.
> 
> However, it uses the "SMIng developed by the IRTF NMRG group"
> as an example, without siting any reference documents.  The
> discussion should be removed or a normative reference to the
> NMRG version of SMIng should be added.
> 
> Margaret
> ------- End of forwarded message -------

Date: Wed, 25 Sep 2002 12:22:30 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

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)" <[email-masked]>
> Cc: [email-masked]
> From: Robert Moore <[email-masked]>
> Date: Fri, 20 Sep 2002 12:21:34 -0400
> Sender: [email-masked]
> 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

Date: Tue, 24 Sep 2002 19:04:35 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

Two comments:

We briefly talked about issue #1 in Austin. It is also discussed in my 
Ph.D. thesis and book. Depending on the expressiveness and semantic 
richness of the languages used to specify the IM and DM, the abstractions 
(objects, attributes, operations and relationships) defined in the IM may 
or may not easily map onto data structures in the DM. When they don't, we 
can resort to workarounds (e.g., a real can be encoded as a string), but by 
doing so, we lose some validation power and sometimes some semantics (e.g., 
some DMs cannot express relationships). Perhaps a few sentences could be 
added to the I-D/RFC to make this clear.

In my view, issue #2 is far-fetched. Should Aiko and Juergen decide to 
reference an LDAP document, I think that an LDAP mapping produced by the 
DMTF would be more appropriate here than RFC 2252.

JP

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)" <[email-masked]>
> Cc: [email-masked]
> From: Robert Moore <[email-masked]>
> Date: Fri, 20 Sep 2002 12:21:34 -0400
> Sender: [email-masked]
> 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
> [email-masked]
> ------- End of forwarded message -------

Date: Tue, 24 Sep 2002 14:09:33 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

Any comments on this?

/js

------- Start of forwarded message -------
Date: Fri, 20 Sep 2002 11:39:16 -0400
To: "Wijnen, Bert (Bert)" <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
Cc: [email-masked]
Sender: [email-masked]

At 10:10 AM 9/20/02, Wijnen, Bert (Bert) wrote:
>Hi MIB-ers
>
>I expect/suspect that this will end up on my desk for AD-review.
>So whoever has not seen it or commented on it, pls take a look
>and let me know if you have any serious issues or if you feel
>this is good work/information that you support.

The document is generally interesting and informative.

However, it uses the "SMIng developed by the IRTF NMRG group"
as an example, without siting any reference documents.  The
discussion should be removed or a normative reference to the
NMRG version of SMIng should be added.

Margaret
------- End of forwarded message -------

Date: Tue, 24 Sep 2002 14:09:06 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] [[email-masked]: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)]
Sender: [email-masked]

Any comments on this?

/js

------- Start of forwarded message -------
Subject: Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
From: Robert Moore <[email-masked]>
Date: Fri, 20 Sep 2002 12:21:34 -0400
Sender: [email-masked]
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
[email-masked]
------- End of forwarded message -------

Date: Fri, 20 Sep 2002 10:33:51 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Content-MD5: 33iU9okLAA65TMFcLjxzyA==
Subject: [nmrg] Re: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
Sender: [email-masked]

Greetings,

Thank you for your submission.  The RFC Editor has received your
proposed RFC, and will review the document.  Once the RFC Editor has
reviewed this draft, we will send it to the IESG for a 4 week timeout,
allowing the IESG time to review and comment on this effort.

You can track the progress of your document at:

   http://www.rfc-editor.org/queue.html

Thank you.

RFC Editor

> Date: Fri, 20 Sep 2002 15:22:48 +0200
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: Network Management Research Group <[email-masked]>
> Subject: draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
> 
> 
> On behalf of the NMRG, I would like to ask you to publish
> 
>   Title     : On the Difference between Information Models and Data Models
>   Author(s) : A. Pras, J. Schoenwaelder
>   Filename  : draft-irtf-nmrg-im-dm-02.txt
>   Pages     : 9
>   Date      : 19-Sep-02
> 
> as an Informational RFC. This document has been produced by the
> Network Management Research Group (NMRG) of the IRTF.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>
> 

Date: Fri, 20 Sep 2002 15:22:48 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-im-dm-02.txt (Informational RFC)
Sender: [email-masked]

On behalf of the NMRG, I would like to ask you to publish

  Title     : On the Difference between Information Models and Data Models
  Author(s) : A. Pras, J. Schoenwaelder
  Filename  : draft-irtf-nmrg-im-dm-02.txt
  Pages     : 9
  Date      : 19-Sep-02

as an Informational RFC. This document has been produced by the
Network Management Research Group (NMRG) of the IRTF.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Thu, 19 Sep 2002 14:02:03 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] please post draft-irtf-nmrg-im-dm-02.txt
Sender: [email-masked]

Please post the following document as an Internet Draft:

<http://www.ibr.cs.tu-bs.de/~schoenw/draft-irtf-nmrg-im-dm-02.txt>

Thanks,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Thu, 19 Sep 2002 14:00:10 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-02.txt
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> Please find enclosed the new version that I propose for the I-D. I
JP> have made lots of minor editorial changes plus a few semantic
JP> changes. 

Thanks for all the nice editing you have done. I have included almost
all of your changes into my current version, which reads much better
now. I will post the updated document in a few minutes and once it
appears in the ID archive, I will ask the RFC editor to add this to
his queue.

(So if people want to check my edits, please do so quickly.)

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

From: <[email-masked]>
To: <[email-masked]>
Date: Wed, 18 Sep 2002 22:51:41 +0200
Subject: [nmrg] Osnabrueck Meeting Followup
Sender: [email-masked]

Hi group, 

Sorry for the delay ... 

First, allow me to thank for the invitation! It was a real 
pleasure to get in touch with you. I really learned a lot. 

Following I put together some links which may be of interest to 
you all: 

General XML stuff: 

XML Recommendation: http://www.w3.org/TR/REC-xml 

XML Schema: http://www.w3.org/TR/xmlschema-0/ 
http://www.w3.org/TR/xmlschema-1/ 
http://www.w3.org/TR/xmlschema-2/ 

WSDL v1.2 (the W3C standardized one): http://www.w3.org/TR/wsdl12/ 

Web Service Architecture: 

(Requirements) http://www.w3.org/TR/wsa-reqs 

(Usage Scenarios) http://www.w3.org/TR/ws-arch-scenarios/ 

SOAP v1.2 (the W3C standardized one): 
http://www.w3.org/TR/soap12-part0/ 
http://www.w3.org/TR/soap12-part1/ 
http://www.w3.org/TR/soap12-part2/ 

XPath: http://www.w3.org/TR/xpath 

XQuery (a bit off topic as we concluded, but I decided to include 
it just for information purposes): 
http://www.w3.org/TR/query-semantics/ 
http://www.w3.org/TR/query-datamodel/ 
http://www.w3.org/TR/xquery-operators/ 
http://www.w3.org/TR/xquery/ 
http://www.w3.org/TR/xmlquery-use-cases 

XML-RPC (a SOAP successor): http://www.xmlrpc.com/ 

UDDI (now under standardization by an OASIS working group): 
http://www.oasis-open.org/news/oasis_news_08_28_02.shtml 

BPEL4WS: 
http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/ 

XML Digital Signatures: http://www.w3.org/TR/xmldsig-core/ 

XML Encryption: http://www.w3.org/TR/xmlenc-core/ 

If you feel the need for further input on XML and/or Web Services 
stuff do not hesitate to contact me again. I would be more thank 
happy to assist again. 

Best Regards, 
 Mario 

From: Frank Strauss <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] js notes
Date: 17 Sep 2002 17:26:15 +0200
Lines: 99
Sender: [email-masked]

Hi!

Since I took just a few lines of notes, and Juergen's notes as well as
Margaret's are almost a superset of mine, I just add a few inlined
comments...

JS>   - Dave:

JS>     Dave talks about the different viewpoints of mgmt app developers
JS>     and device implementors. He believes that there should be different
JS>     schemas for data exchange between management applications and between
JS>     management applications and devices.

Add:    In case of communication to the devices, he does not believe in
        XML and he believes that the schema must be forced (as with MIBs)
        and not provided individually by the devices (as with WSDL).

...

JS>   - Olivier:

JS>     Web-Services can play a role between management platforms and
JS>     withing management platforms. Representing configuration as XML
JS>     documents is really helpful. Representation of meta data etc.  is
JS>     all available with XML. Believes that representation of additional
JS>     semantic (e.g. relationships via RDF) is a big step forward.

Add:    Security is a mission.

JS>     Side discussion: SOAP intermediaries can take an RPC call and
JS>     invoke it on multiple boxes.

...

JS>   - Aiko:

JS>     SNMP will not be further developed substantially. Distinction
JS>     between networks and applications starts to disappear. SNMP is not
JS>     going to solve the bigger problems 

Add:    (e.g., configuration management, higher-level service management,
        integration of network-, service-, and desktop-management)

JS>                                       .  Web-Services will be
JS>     implemented and generally available in systems and applications.
JS>     Network management or monitoring is not different than many other
JS>     tasks

Add:    of distributed systems

JS>          . Web-Services will be universally available and easy to use.

...

JS>   Web-Services Technologies:

JS>   SOAP			/* MUST */
JS>   UDDI			/* MAY sometimes be useful */
JS>   WSDL			/* SHOULD (closely related to XML Schema) */
JS>   Architecture WG	/* we do not know that this time */
JS>   XML RPC		/* NOT (is one alternative) */

Add:          / XMC [It was not on the board, but we mentioned it also].

JS>   XML Schema		/* SHOULD (closely related to WSDL) */
JS>   LDAP			/* NO */
JS>   HTTP			/* several transports may be used */
JS>   DBMS			/* NO */

...

JS>   Focus on bandwidth: Dave is willing to accept a small factor of
JS>   bandwidth increase (e.g. 2) but not a magnitude (e.g. 10) or more.
JS>   Margaret says that using less bandwidth is still valuable. Randy
JS>   says that especially out-of-band networks for management are
JS>   expensive.

Add:  Frank regards increased bandwidth and delay for infrequent
      operations to be tolerable, but not for small frequent
      requests/responses.

JS>   Focus on CPU cycles: It is easier to increase the processing power
JS>   of manager platforms compared to the costs of increasing bandwidth.
JS>   It is also expensive to upgrade processors in network elements.

...

JS>   Critical CPU intensive devices are SNMP polling/traphandlers.
JS>   Rule-based event correlation (root cause analysis) are CPU intensive
JS>   and do not distribute well.

Add:  So, CPU consuption is also an issue at top of the manager hierarchy.

JS>   How critical CPU consumption is really depends on the device
JS>   architectures. Cisco routers are much more CPU critical compared to
JS>   Juniper routers.

 -frank

Date: Mon, 16 Sep 2002 10:18:30 -0400
To: [email-masked]
From: Margaret Wasserman <[email-masked]>
Subject: [nmrg] Here are my notes...
Sender: [email-masked]

NMRG Meeting Notes -- September 15 & 16, 2002

DAY ONE
=======

Last meeting in Pisa, discussed future directions in
NM.  Agreed to focus on use of XML/WS, and agreed to
schedule for next meeting.

In the meantime, the IAB has organized a similar WS.
Also came to conclusion that we should look at XML
for device management.

Also, held BOF in Yokohama to discuss use of XML in
device management.

Purpose of this meeting is not to discuss other
options, but to discuss XML/WS, despite the fact that
some people have doubts.

Short Presentations:

Juergen does not think that WS will be used to manage
a device -- too complex on wire and systems, doesn't
meet needs (transaction handling).

Randy think that this is a solution in search of a
problem.  Doesn't meet few needs of problem that he
understands.  Distributed database languages are
closer to what we need than WS.  Classifying WS
as SOAP and UDDI -- SOAP doesn't have what he needs,
and UDDI is useless - don't need specification to
hand to a programmer.

Margaret: [Did not take notes during my own comments.]

Phil:  Ws is needlessly complex and getting more
so (specs are twice as big on each iteration since
XML-RPC).  Also, not aligned with problems of device
management.  Wants RPC that is connection-oriented,
security once for communication, persistent locking.
Send and XML heirarchy and get back an XML heirarchy.
Literal XML encoding for Apache (handles raw XML)
is interesting, but not sure how widely implemented
it is.  In the end, the content is king.  The XML
you are trying to send can be stubbed and converted
to send over any technology... the content is the
bigger issue.

Mario is not here to defend SOAP.  Has been hard to
keep it as simple as it is now... Mario is not
deeply involved in NM.  At least two layers of
the NM problem.  WS are very good for business
integration, bringing business partners together,
etc.  XML is quite verbose on the wire -- doesn't
like the idea of elements (i.e. Cisco routers)
speaking XML on the wire.  MS is developing new
mechanisms for compressed XML.  [Randy's side
comment:  More complex software to save a few
packets on the wire -- Phooey!]

Bert:  Worried/scared about loss of interoperability.
The easier it is to extend something, the harder it
will be to have interoperable systems.  Humans may
be able to interpret extensions, but may lead to
situation where we don't have the same manageable
objects on multiple devices.  Thinks it would be the
wrong thing to try to standardize something right
now -- wait for vendors to play with this for a while
and figure out what the right things are.  Operators
have given us requirements, and we haven't documented
them well yet.  None of the features of XML/WS are
going to address those requirements.

David Perkins:  [Drew on board.]  Believes that XML is
not a good technology for the interface between a device
and the first level manager.  Always been a tension between
management application developers and device implementors
regarding the schema.  He believes that the schema needs
to more closely match what is on the device, rather than
designed to make the management application developer's
job easier.  Higher-level management systems need a
different schema that works better for their high-level
applications.  We have a problem that people who are
writing management applications don't understand routing,
switching, etc.  Need to have teams that combine protocol
experts with application development experts.  Best thing
for community would be to agree that these things really
are different.

Frank thinks that there are many currently unsolved problems.
For example, configuration has not been solved in ~12 years.
Considering a configuration as an XML document seems more
"native" to the task.  However, shipping XML documents around
to monitor a few variable doesn't seem appropriate.  We have
a toolbox of XML tools -- parsers, validators, etc.  They
all exist, we just have to use them.  Could come up with
some solutions by plugging things together.  In SNMP world,
we need to build from scratch, and the tools are often not
good -- buggy, only solve certain problems, etc.  All of
these are advantages to XML-based approach.  WS would allow
complex tasks (set this, if it works, set the other thing,
etc.) to be done in a single step.

Olivier:  Makes distinction between two levels.  Web Services
can play a role between applications and management platform.
Is also an interest between the management platform and a
device to provide configuration as an XML document.  Much
easier to understand configuration as a single XML document
than as a series of SNMP steps (set up a row in one table,
then set this, etc.).  Need XML and schema, not necessarily
bound to WS.  Security is an issue, but work is underway on
security in W3C, etc.  Easy to use XML to enrich the information
model and implement reasoning on top of it.  Sees entire
battery of WS at higher level, and thinks that XML is interesting
for configuration management on devices (but not necessarily
full WS suite).

J.P.:  SNMP solves one problem well -- monitoring resource-
constrained network devices.  Today, we want to do more
complex management of devices that may or may not be resource-
constrained devices.  Today, we only have an open standard
only for monitoring of resource-constrained (or non-resource
constrained) devices.  XML is a good solution, except that
you don't want to bombard resource-constrained devices with
too much data.  In the higher-level application space, we
are not resource constrained.  Current using things like
CORBA (which has many problems) -- now the market is moving
to WS.  WS have learned for problems with CORBA.  Doing much
better standardization in W3C, wide availability in advance
of standardization, much better architecture (bindings, etc.
to separate encapsulation from the data you are sending).
Number of architectural reasons for using WS at application
layer.  Also "trendy", so much engineering time is being
applied in this area.

Aiko:  Not the most positive person, but did take the initiative
to organize this meeting.  Does not think that SNMP will be
further developed in a substantial way.  New management challenges
for monitoring elements, configuring elements, higher-level service
management (SNMP not used here now).  Distinction between NW
and applications is becoming less clear -- need integrated
network management, application management, desktop management.
Pretty clear that SNMP cannot do these things, so we need something
else.  WS will be available on every desktop soon, available for
free for older systems, eventually will be on every machine.
Eventually will be integrated into all sorts of applications (i.e.
running a WS to get a value for a spreadsheet cell).  Monitoring
a network isn't actually different than monitoring stock prices.
Benefits -- common technology, implemented everywhere, easy to
use, everyone can use.  That's why he believes in WS for management.
[Side comments:  David Perkins fundamentally disagrees with
statement that network management is the same as stock quotes.
Randy doesn't think ubiquity equals quality.  Randy ran into Bell
Labs guy who is implementing XML configuration management for OSPF
and BGP, etc.  Has three slides that are very positive on the
topic of XML.]

Bert has some slides from the Bell Lab guys that indicate that
WS offer better security than SNMP (v1?), and can leverage
existing web services security infrastructure.  Bert will mail
the slide(s).

Andreas sent some e-mail this morning as input to the group.
Aiko will forward it to the list.

Scenario Identification:

	1. Single Element Management
		- Monitoring Elements
			- Data collection (via polling or
				push model)
			- Exception Reporting
			- Fault management
		- Configuring Elements
			- Initial Configuration
			- Modification

	2. Multiple Element Management

	3. Manager-to-Manager Communication

	4. Administration within the NOC

Randy:  Configuration is driven from data.  Data is not centralized.
Sales data separate from billing data, separate from NOC data, etc.
Sometimes separate, sometimes together.  Also people are involved,
such as a customer service representative who gets a call "Please
change my account to do this new thing".  Full WS (SOAP/UDDI) will
be better targetted at that level.

                   (--)     ^
                   (DB)--- / \            NMS System
                   (--)   +---+		 (High-level transactions)
                          /  \
                         /    \
                      +---+  +---+
                      |   |  |   |        EMS System
                      +---+  +---+        (Vendor-specific translation)
                       |      /  \
                       |     /    \
                     +--+  +--+  +--+
                     |  |  |  |  |  |     Elements
                     +--+  +--+  +--+

What is the definition of Web Services?

What technologies are included:
	SOAP               (Must be supported)
	UDDI               (May be supported)
	WSDL               (Should be supported? At what level of detail?)
	WS Architecture    (Future oriented?  Not clear what this implies)
	XML RPC            (For tomorrow -- Outside WS umbrella)
	XML-Schema         (Tied to discussion on WSDL.)
	LDAP               (No.  Implementation detail.)
	Web Server         (Not necessarily, SOAP is transport-independent.
			    Do have a need for some transport server.)
	Database           (No)
	P-to-P Transport   (Not necessary.  Transport independent.)

Discussion of WSDL:  Could define a very small set of primitives
(SET, GET, etc.) with data description in the XML schema.  Or could
put more in WSDL (separate primitive to get specific object, etc.).
The more that you put in WSDL, the more useful UDDI becomes to
discover that content.  Doing more at WSDL level may make things
more flexible.

Political issue with UDDI.  MS and IBM have handed over UDDI to
Oasis, so W3C is not doing its own work on discovery.  W3C
architecture group will need to reference a discovery mechanism.

Complex issue involved with what is in WSDL and what is in the
XML schema.

J.P.: By and large, WS is an empty shell at the moment.  Not
meaningful to say that something supports WS if it only implements
SOAP -- further requirements will be forthcoming.

WSDL/Schema Balance Discussion:

Basic approaches:

	1.  Very simple methods in WDSL -- Get/Set
	2.  More extensive generic set of methods -- GetTable,
		Add, Delete, Action (a la CMIP), GetConfig,
		SetConfig (AKA dump & restore)
	3.  Data-specific methods -- GetRoutingTable,
		GetIfInOctets

Would the operations/methods be vendor specific?  Could vendors
extend the set of methods on a per-device basis?  Or would their
be a fixed set of methods for all devices?

General issue:  How much interoperability do we want to encourage?
Trade-off between flexibility and interoperability.  May want to
allow extensibility of the data model, but not extensibility of
the commands/operations?

Discussion of versioning support in WS.  Under discussion in
the architecture group, but not supported by WSDL.

Candidate configuration/restore old configuration/etc.

Transaction handling (called orchestration in W3C-speak)
is defined as part of some proprietary protocols:  WSFL (IBM),
XLANG (MS), or BPEL for WS (MS/IBM -- successor of both
WSFL or XLANG).  W3C is thinking about establishing a working
group for some type of orchestration.

XML schema only provides types for parameters.  Any sort of
function-call or method needs to be defined at the WSDL level,
as part of the API provided by the device, etc.

Discussion of how XML can be used to access indexed or ordered
information.

Indexed information can be accessed using predicates at the end
of an XML path:

	system/login/user[name=phil]

Multiple elements can be included in the predicate portion.

XML does include the ability to walk a list of objects (first,
next, etc.).  So, it supports some concept of ordered objects.
Two boxes may not return the same members of a list in the
same order.

Popping back up to issue of WSDL/XML-Schema balance.  Topic
seems to have been covered fully.

There has been previous discussion in the NMRG about moving
to a more object-oriented approach to network management.
WS isn't object-oriented, and isn't a step in that direction.
The DMTF has a more object-oriented approach, with a way to
call methods associated with objects.  Will the W3C standardize
something like that?  Maybe not...

Dinner:	Rampendahl (near Walhalla hotel, has microbrewery)
	Meet at Walhalla hotel at 7:30pm

Discussion of whether WS is too verbose (uses too much network
bandwidth) for network management.  Not a problem on the
in-band network, but may be a problem when management is run
on an OOB network, if the bandwidth is orders of magnitude
larger than current technologies.

Another issue is latency.  TCP introduces more latency, as
does anything that results in more packet exchanges.

Issues with memory utilization?  A DOM tree will be ~10 times
as large as the XML data being transferred.  But, there are
ways to avoid keeping the whole DOM in memory -- SAX and using
adaptive DOM (freeing the parts of the DOM that aren't needed).

Bert:  One of the main issues with SNMP is the complexity
of implementing MIBs in the devices.  SNMP MIBs are not
implemented immediately when new features are implemented
in products, CLI is implemented instead.  MIBs are then
implemented very slowly, as vendors have no incentive to
implement them promptly.  How will WS relate to this?

Next Topic:  Ease of implementation.

Takes one or two weeks to become familiar with WS tools that
are available.  But, once you are available, it is easy to
implement these things.  Only need a few lines of code in the
server and client -- everything else is libraries, etc.

Engineers working on network management applications are
fundamentally different than the people who are writing the
instrumentation on the devices.

How can we change the approach of hardware developers, so that
they will implement XML management instead of a CLI as their
interface for debugging, beta customers, etc?

DAY TWO
=======

Phil Shafer presented the JunOS XML implementation.
[Hopefully he will send a presentation to the group.]

Believes that his XML product has succeeded because it
is closely tied to his CLI.

Discussion of what type of work makes sense in this
space for the IETF to do.  Bert:  There are a lot of
things that aren't standardizable, etc.  So, is there
anything left here that makes sense for the IETF to
standardize?

Randy:  Differentiate between trying to standardize the
CLI (in XML, text, etc.) and trying to standardize some
mechanisms by which you configure the universe.  How do
we download the configuration in XML?  What is our
transport? There are syntax primitives and transport for
configuring, and then there is the syntax/semantics for
the actual configuration information.  Important to get
agreement on the first part, not on the second.

Bert:  We have a number of security protocols/mechanisms
standardized within the IETF.  Randy:  All routers won't
let us SSH to them, there is no way to ask a router for
its configuration...

If we don't specify all the way down into the standard
data, it may be difficult to set-up authorization for
access to different parts of the data.  Somehow, we'd
have to hand authentication information to the data
handling engine, and it would need to have a vendor-
specific mechanisms (based on the structure of the
data) to control who could access which information.

Issue with the criteria that we use to establish access
control.  Can we get agreeement on a complete authorization
and find-grained action model?  May not be a problem of
getting agreement, but it may not work well in practice.

Where do we go from here?

Seems to be consensus in multiple groups that we would
standardize the transport & the operations, but not the
structure of the data (i.e. schema).

Layering:

+------------+
| Content    | -----> Should remain vendor-specific?
+------------+ --+
| Operations |   |
+------------+   |
| RPC Mech   |   +--> Interesting parts to standardize.
+------------+   |    (We also understand how to do this?)
| Transport  |   |
+------------+ --+

For instance, could use (from bottom up) HTTP, SOAP and
WSDL.  Would need to standardize a set of WSDL operations
to allow network management, such as GET, SET, DUMP, RESTORE,
transaction operations, notification operations, INVOKE?

Trade-offs between using things that are already defined
and finding things that meet our requirements.

What are the commands that we would need to support
(semantics)?

Modeled                +------+   +------+   +------+
Operations             | NMS  |   | NMS  |   | NMS  |
    ^                   +------+   +------+   +------+
    |                   +------+   +------+   +------+
    v                   | D    |   |      |   | T    |
Modeled                | E    |   |      |   | R    |
Data                   | V    |   | EMS  |   | A    |
    ^                   | I    |   |      |   | N    |
    |                   | C    |   |      |   | S    |
    v                   | E    |   |      |   | L    |
Concrete               |      |   |      |   | A    |
Data                   |      |   |      |   | T    |
    ^                   |      |   |      |   | E    |
    |                   |      |   +------+   +------+
    v                   |      |   +------+   +------+
Implementation         |      |   | Dev  |   | Dev  |
                        +------+   +------+   +------+

                          SNMP      Telco       NEW
                          Model     Model       Model

A "configuration" will be treated as an opaque XML document.

We will be trying to solve the problems of security,
transactions and candidate configurations.

If we standardize this in the IETF, why would vendors do
this?  Randy:  Vendors are already doing this type of
thing.  Bert:  No indication that people want to bring
these things together...  Things are driven by what
people already have.

What will the IRTF do as an outcome of this meeting?

Prototype technologies discussed and make technologies
available to each other.  Consider the implications of
considering configuration of an entire network as a
single XML document.  What are the considerations for
a distributed XML document?

Might be useful to write a requirements document and send
it to the W3C.  Should detail what the requirements are
for the WS architecture to be used for network management.
J.P. thought it would be interesting, and Mario had indicated
it would make sense as a W3C note and that the WG would
probably have real interest in this area.  J.P. would
co-author, but can't write it alone.  Aiko is also somewhat
interested.  May need others involved.

David:  Will they say that Oasis is working on this and
the W3C shouldn't be involved?  J.P.:  Doesn't think so.

Phil:  Is anyone here active in the Oasis management group?
No.

What other output?  Bert:  Would like to see someone work
on defining high-level operations that we need.  Aiko:  We
will probably hold a meeting of the NMRG to determine what
the higher-level semantics you need are to manage a network
(as opposed to a particular device), discuss transactions,
etc.  There is already a W3C WG working on transactions for
WS, but we don't know how well-supported it is.

Larry Menton (researcher at Lucent) sent some slides, and
presented them via speaker phone.  Larry has worked at Lucent
Tech for 22 years, involved in NW management, agents and other
data networking products.  [See slides for details of
presentation.]

Discussion of "network management" (a la Randy):

Not managing a single device, but managing multiple devices
at once.

Issues:
	Managing Networks
	Configuration state
		- Transaction Model
	Security Features

Randy presented his "pie in the sky" presentation from the
IAB NM Workshop.

Randy thinks that what Phil is doing for transaction support
in JunOS is "getting close" to what we need at the device
level.

Security discussion:  Randy would prefer a certificate-based
mechanism.  Come up with an identity model, understand security
relationships, create security associates and keys bound to them,
use the keys to verify a request...  [I didn't follow this
that well.]  Should be able to look at the field of network
(not device, _network_) configuration, and come up with a
security model that will work into the next decade.

What we are doing now is horrifyingly primitive.  25 years
from now, we will look back on this as assembly language.
Randy believes that there is an "algebra of trust" that we
should understand -- that's research.  He could probably come
up with a "hack" that would last into the next decade or so.
Aiko:  Pointed out that there are researchers looking at
these things -- doesn't know what they have done.  Randy:
Pointed out lack of computer science in the network -- should
be able to make formal statements about the network that are
verifyable.

Need a security architecture for network management.  Go
from the top down.  Once we know what we need, we can pick
up various pieces and use them as needed.  The pieces are
secure transport, certificate systems, etc.  But, we don't
have an architecture that ties this all together.  We need
an identity model.

Bert:  If you look at the SNMP architecture, where we define
a security name, principals, etc... Is that identity?  Randy:
Yes.  Bert:  Can Randy point out what's wrong with that
architecturally?  Randy:  Identity is a member of a class
and the class has privileges.  Bert:  We have that...

Transaction Handling:

David Perkins claims that the context in SNMP allows the
implementation of a transaction model.  You would create a
MIB table that allows you to manage contexts.  You would create
a new context, do a bunch of sets to that context, etc.  May
want to have some sort of timer that does rollback...??  Once
all of the sets are completed in the new context, you activate
the new context in each device.  If one of them fails, you
roll back to the previous context.

No one is using this mechanism today.  Why?  David:  They
don't understand it.  Bert:  They aren't using SNMP for
configuration, so they don't use this, either.

Randy:  Explain how you can build the "confirm the commit
within one minute, or I will automatically roll back".

There would need to be a context MIB to handle which context(s)
are active at any given time, and when/how they should roll
back, etc.

How does WS/XML make these things easier (or not)?

Randy: XML may be useful, because having the data tagged is
a win.  Much easier to parse tags than free-form text.

David:  Issue may be that vendors don't make it easy to get
ahold of their MIB files?  It seems crazy that the vendors
don't make them easily available.

Send notes to Aiko.

Date: Mon, 16 Sep 2002 16:16:28 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] js notes
Sender: [email-masked]

Meeting starts at 10:15 with all people who are invited:

   1. Randy Bush (ATT, USA)
   2. Olivier Festor (Loria, France)
   3. Mario Jeckle (Daimler-Chrysler)
   4. Jean-Philippe Martin-Flatin (CERN, Switzerland)
   5. Dave Perkins (Riverstone, USA)
   6. Aiko Pras (University of Twente, Netherlands)
   7. Juergen Schoenwaelder (University of Osnabrueck)
   8. Phil Shafer (Juniper Networks, USA)
   9. Frank Strauss (Technical University of Braunschweig, Germany)
  10. Margaret Wasserman (Windriver, USA)
  11. Bert Wijnen (Lucent)

Note takers: Frank and Juergen

Aiko turns the notes into meeting minutes.

* Aiko starts to introduce the background of the meeting (last NMRG
  meeting, IAB meeting, Yokohama XMLCONF BOF, ...)

* Aiko reminds people to be open. Goal is not to produce technology
  drafts but to generate common understanding.

* Randy reminds to identify the problems we are trying to solve.
  We will 

* Lunch break at 12:30.

* Collecting statements...

  - Juergen:

    Does not believe in Web-Services in the interface between devices
    and management applications, because of complexity and performance
    issues and not really addressing the requirements such as
    transactions across devices.

  - Randy:   

    Believes the problem is ill defined and Web-Services is more a
    technology looking for a problem. Randy thinks that distributed
    database technology has probably more in common with the real
    requirements. He also has concerns that UDDI has serious security
    issues.

  - Margaret: 

    Margaret talks about layers in management systems and there might
    be some use of Web-Serivces at the higher layers. But they seem to
    be overkill at the management application - device interface. Web-
    Services might be useful for higher layers (such as service
    management layers).

  - Phil:

    Web-Services is too complex for the device interface. He wants to
    have a connection oriented, persistence technology. SOAP is
    considered too complex and has too many options. But in the end,
    he wants any RPC technology.

  - Mario:

    Mario says it was already hard to keep SOAP specifications not
    growing even faster. Web-Services are intended to bring business
    applications together and he believes Web-Services are easier to
    integrate than CORBA, DCE, ...

  - Bert:

    Bert is worried about interoperability, especially since XML is so
    easy to extend. He wants people to experiment first before
    actually trying to standardize something. He also does not think
    that Web-Services address the requirements.

  - Dave:

    Dave talks about the different viewpoints of mgmt app developers
    and device implementors. He believes that there should be different
    schemas for data exchange between management applications and between
    management applications and devices.

  - Frank:

    Looking at configurations in an XML document format is a big win.
    XML advantage are the many tools are readily available - you just
    have to use them. It is easy to plug things together while with
    SNMP many things have to be written from scratch. Also need to
    move to an RPC style interaction mechanism.

  - Olivier:

    Web-Services can play a role between management platforms and
    withing management platforms. Representing configuration as XML
    documents is really helpful. Representation of meta data etc.  is
    all available with XML. Believes that representation of additional
    semantic (e.g. relationships via RDF) is a big step forward.

    Side discussion: SOAP intermediaries can take an RPC call and
    invoke it on multiple boxes.

  - Jean-Philippe:

    SNMP is good for monitoring resource constraints devices.  Today
    need to do more. Open management exists only for monitoring
    resource constraints devices. For configuration, use XML. Within
    management systems and between management systems, you are in a
    distributed system and you can use CORBA, Web-Services, ...

    (1) Web-Service standardization is faster then CORBA standardization
    (2) Better separation of protocol and data ...
    (3) Web-Services is trendy and should be used in/between management
        systems

  - Aiko:

    SNMP will not be further developed substantially. Distinction
    between networks and applications starts to disappear. SNMP is not
    going to solve the bigger problems. Web-Services will be
    implemented and generally available in systems and applications.
    Network management or monitoring is not different than many other
    tasks. Web-Services will be universally available and easy to use.

* Identifying problems...

  1 Single element management:
    - monitoring
      - regularly scheduled data collection
      - exception reporting
    - configuration
      - initial configuration
      - modifying (partial) configurations
    - northbound reporting (to higher layer managers)

  2 Multiple element management:
    - 

  3 Between management applications:

  4 Integration with internal infrastructure:

  5 Integration with external infrastructure:

  Dave explains that typically today, service orders require the
  collaboration of several organizations to implement the ordered
  service. Dave things that Web-Services are targetted to support the
  communications between the systems that realize the various parts
  that make up a given service. This B2B communication happens within
  a company (different business units) and across companies.

  Randy: Communication happens to be more and more asynchronous the
  higher you climb up the layers (as you are getting closer to human
  beings).

  Phil talks about the translation of the configuration stored in
  databases into formats understood by devices. 

  Margaret: Translation must run below a transaction engine since
  transactions might affect multi vendor devices.

  Phils says that this is exactly the job of an EMS in the TMN model
  and EMSes are vendor and device specific.

* Scope of the meeting...

  Web-Services model might be reasonable for 4/5, but we will not
  focus on level 4/5 in this meeting.

  What is Web-Services? Just SOAP or also UDDI or ...?

  Randy: Web-Services are SOAP, UDDI and WSDL (not XML since XML is
  sitting below).

  Web-Services Technologies:

  SOAP			/* MUST */
  UDDI			/* MAY sometimes be useful */
  WSDL			/* SHOULD (closely related to XML Schema) */
  Architecture WG	/* we do not know that this time */
  XML RPC		/* NOT (is one alternative) */
  XML Schema		/* SHOULD (closely related to WSDL) */
  LDAP			/* NO */
  HTTP			/* several transports may be used */
  DBMS			/* NO */

  JP: Web-Services is what is being standardized in W3C.

  Randy: Includes UDDI (at least from the conceptual space). But
  believes that it is not useful for anything.

  Mario: Should not be bounded by organizations developing standards.

  Phil: The more information you put in WSDL, the more you need UDDI
  to discover the services.

  Frank: It really depends whether we just need a few primitives
  (get/set/...) or many RPC-style primitives. In the later case, there
  would be a need for more WSDL definitions.

  What are the trade-offs between many primitives (operations) and only
  a small set of very basic primitives (operations)?

* Lunch Break

* Granularity of primivites (operations)

  (1) Get/Set/					(WBEM)
  (2) Get/Set/Create/Delete/Commit/Action/..	(richer but more generic)
  (3) per object methods			(data specific methods)

  Vendor extensions in the schema sufficient for (1) and (2), while
  (3) requires an extensibility feature for the primitives (operations).
  Discussion about impact of (3) on interoperability.

  Extending schemas underlying WSDLs is hard and complicated. How do
  you deal with major changes? What about versioning? All you can do
  is to use a new namespace. Versioning will not happen to be in WSDL
  before 1.3, although it is part of the architecture.

  XML schemas support extensibility since you can add new stuff in new
  namespaces and you can mix several namespaces in an XML document. (3)
  seems to have versioning problems.

  Olivier reminds us that XML is just complex data types and not
  objects. XML is static data structures, there is some work on so
  called schema adjuncts.

  Is there transaction support in WSDL? No. There is transaction work
  done by IBM and others on top of WSDL, e.g. BPEL for Web-Services
  (MS, IBM), which replaces WSFL. Within OASIS, there is a proposal
  for transaction support.

  It is possible to embed human readable contents in WSDL files, but
  it is not possible to reference external human readable contents.

  Olivier starts to talk about naming in XML schemas. How does one
  address specific instances with WSDL definitions? One solution would
  be using XPATH.

  Olivier asks whether it is safe to assume that all nodes have unique
  names? It is agreed to be necessary to define a naming scheme in the
  XML schema definitions. 

  JP asks whether it is safe to assume that all data can be reasonably
  organized in a hierarchical containment tree? Randy says it is
  probably not necessary to name everything in the general case.
  There are topological structures that do not directly map into
  hierarchies.

  Canonicalization only removes white spaces but does not change the
  order. Discussion about lists an how they can be defined in xml
  schemas starts.

  A number of us agree that it is good to move into OO direction in
  organizing management data. Not all seem to agree?

  Olivier says that you can have WSDL primitives such as
  INVOKE(<object-name>,<method-name>,<parameters>) which allos to
  treat XML document elements as objects.

* Break

  Web-Services performance issues. Mario talks about a study that SOAP
  performs well if the document is not of a trivial size. Compression
  helps to reduce bandwidth consumption for the price of CPU cycles.

  Focus on bandwidth: Dave is willing to accept a small factor of
  bandwidth increase (e.g. 2) but not a magnitude (e.g. 10) or more.
  Margaret says that using less bandwidth is still valuable. Randy
  says that especially out-of-band networks for management are
  expensive.

  Focus on CPU cycles: It is easier to increase the processing power
  of manager platforms compared to the costs of increasing bandwidth.
  It is also expensive to upgrade processors in network elements.

  Configuration management is usually not time-critical.

  DOM is about 10 times bigger than the XML document. Most CPU cycles
  spend in serializing/deserializing XML documents. Are there any
  comparisons BER versus XML encoding? There is a lack of studies in
  this area. Therefore, never keep a DOM tree if you want to be
  scalable, use SAX or a streaming API (adaptive DOM).

  Critical CPU intensive devices are SNMP polling/traphandlers.
  Rule-based event correlation (root cause analysis) are CPU intensive
  and do not distribute well.

  How critical CPU consumption is really depends on the device
  architectures. Cisco routers are much more CPU critical compared to
  Juniper routers.

  Bert asks: Will Web-Services be easier to implement? Will XML
  schemas be more timely?

  Aiko reports on some experiments to develop a get WSDL
  implementation in WSDL. After learning curve, things are relatively
  simple to implement (both manager and agent).

  Engineering aspects: How can developers brain washed so that the
  first thought when they have a new feature is to write an XML
  interface for it?

  Aiko thinks there are better generic tools available for
  Web-Services compared to SNMP tools.

  Will Web-Services help to realize the multiple device transaction
  semantics?

  Relational was too much of a stretch for engineers. Normalization
  is often not understood.

  Why do people believe that Web-Services will be much more successful
  than previous technologies such as DCE, CORBA, ... Why is SOAP
  better than XML-RPC? Aiko says the key is ease of use and that is
  more important than many other technology issues. The second key
  issue is the availability of many free tools.

  Randy has transaction and security requirements and asks whether
  Web-Services helps to address these problems.

  Why introduce a new technology when it does not address majore parts
  of the hard problems?

  What about security? Does XML digital signature address the
  requirements? XML encryption? Signature and encryption header is
  used to identify identities that send messages.

* End of day one - we will start again at 9:00 on Monday

* Second day - administriva

  When do people leave?

  - Randy, Bert, Juergen leave 16:25
  - Olivier leaves a bit earlier
  - Phone call presentation at 14:00

* What are the XML implementations and differences?

  Phil: 

    Internal management daemon (mgd) completely based on XML. The CLI
    talks XML to the management daemon using a rendering engine. The
    communication is based on an XML RPC mechanism, where the whole
    session is a single XML document. Juniper provides DTDs but only
    because they are needed, XML schema is the way to go. The
    management daemon may pass calls to other daemons via XML. There
    is an SNMP agent as well but there is zero shared code. Phil shows
    some examples an explains the internal workings.

    Juniper had originally a CLI which was not based on
    XML. Internally everything is based on meta-data, which drives the
    rendering and other things. Adding parsers is therefore doable
    without having to touch all parts of the system.

    Naming by elements, usually one element used as a name. There are
    some cases where two elements are needed to identify a data
    object.  The first element(s) are used as key(s).

    Configuration retrieval are selective with path prefixes, not full
    xpath.

    XML elements can have action attributes which describe how a
    certain action is carried out (replace, delete, ...).

    Juniper uses a self-written pull-based parser. Implements a subset
    of XML. Margaret talks about a restricted set of XML in order to
    put parsers into memory constraint systems. Margaret wants to
    lookup what element of XML make parsers too memory hungry.

    Juniper does locking and rollback.

  Dave Perkins talks about Cisco:

    [... note taker not listening...]

  Must the protocol be in XML? Unclear, we had no discussion about
  this yet. Some thought beep might be a good match, but Marshall
  says beep is really overkill for this problem, which makes people
  think.

  Magaret:

  +-----+ +-----+
  | CLI | | WEB |
  +-----+ +-----+
  +---------------------------
  | MBP (moving towards XML)
  +---------------------------
  +-----+ +--------------+
  | MW  | | proprietary  |
  +-----+ |              |
  +-----+ |  xml cmds    |
  | SNMP| +--------------+
  +-----+
  +-----+
  | MIBS|
  +-----+

  Dave says this is a better architecture:

  +-------------+   +------------+
  | SNMP Agent  |   | CLI Parser |
  +-------------+   +------------+
  +-------------+   +------------+
  | SNMP Access |   | CLI Access |
  +-------------+   +------------+
  +------------------------------+
  |        Resource Manager      |
  +------------------------------+

  Dave back talking about Cisco (IE 2100):

  - simple XML tags around CLI commands
  - enterprise / carrier / isp - everybody except isp likes it

  +---+  +---+  +---+
  |   |  |   |  |   | Cisco Works
  +---+  +---+  +---+
    |
    |    +----------+
    |    | IE 2100  | Web Server, LDAP, ...
    |    +----------+
     \  /
  +-----+
  | CLI |
  +-----+

  <t>
    [CLI commands]
  </t>

  Discussion about security, especially authorization. It seems
  necessary to pass the (authenticated) identity down to the
  instrumentation. Can we ever find agreement on how we authorize
  access?

  What is the integration in terms of web services?

  What set of operations do we need?

  Aiko:

  - get/set/create/delete/dump/restore

  Phil:

  - create/delete/update/delete + rollback/lock/unlock
    (update has replace/merge motifiers)

  Junoscript has data entry errors, commit errors and runtime
  errors. An example for the later case are configurations for
  interfaces that do not exist yet in hardware.

  Phil makes a drawing:

  +------+ +-----+ +-----+
  | SNMP | | NMS | |     |   operation
  +------+ +-----+ +-----+       |
                                 |
  +------+ +-----+ +-----+       v
  |      | |     | |     |  modelled data
  |      | | EMS | | EMS |       v
  |      | |     | |     |      data
  |      | +-----+ +-----+       |
  |      |                       |
  |      | +-----+ +-----+       v
  | DEV  | | DEV | | DEV | implementation
  +------+ +-----+ +-----+

* Lunch break

* What next? What do we do with the output of this meeting?

  - People who build Web-Services prototypes should make them
    available for others to experiment with. (Is this not true in
    general?)

  - Write a requirements document for the W3C about what is missing to
    use Web-Services for management?

* Call-in presentation by Larry Menten <[email-masked]>

* Randy wants to talk about

  - networks
  - configuration state (transaction model)
  - security features

  [I have my second chance to understand this "high in the ski" thing...
   ...lets see if this helps to finish the IAB report.]

  A discussion break out about security mechanisms, SNMPs philosophy
  to not rely on external services, ...

  Randy again makes his point that we need to focus on the network not
  the individual boxes.

  What is the problem with authorization? Discussion...

  Can we do all this with SNMP? Yes, contexts can help and in theory
  this is just more MIB objects...

  Junoscript allows to lock things on multiple devices and unlock
  after confirmed commit. Might cause lock contention between multiple
  management applications. Is this acceptable for operators?

  Discussion about SNMP, SQL, good and the world. Yes, this can all be
  added to SNMP. Will anybody use it? After four year, we still have
  not SNMP over TCP and Dave still thinks it is wrong...

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Mon, 16 Sep 2002 07:03:58 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] statement from Andreas Maier
Sender: [email-masked]

During the preparatin of the NMRG meeting, Aiko and I had contacted
several persons. One of them, Andreas Maier from IBM Germany, wanted
to share a position statement since he could not attend the meeting.
See the attached message below.

Note that Andreas is currently not on the NMRG list. So if you want to
reply, please put his email address manually in the To/CC field.

/js

------- Start of forwarded message -------
Importance: Normal
Sensitivity: 
Subject: Writeup of position
To: Juergen Schoenwaelder <[email-masked]>
Cc: Aiko Pras <[email-masked]>
From: "Andreas Maier" <[email-masked]>
Date: Sun, 15 Sep 2002 09:38:21 +0200
X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20

Juergen,
as promised here is a writeup of my position, based upon our mail exchange:

What is happening in the industry regarding management, is that management
islands (network vs. storage vs. servers vs. software vs ...) are coming
together more and more to create integrated management solutions. This
benefits very much from common schemas and protocols. In fact I would go so
far as to say it requires them. This is important to recognize and means
that in such an environment, an area such as network cannot operate on its
own anymore as far as standards for protocols and schemas is concerned.

Now what should the common protocol and schema be ?

For the common schema, I believe that CIM will play a major role. The CIM
schemas cover the largest range of management areas compared to other
schemas, and they seem to get implemented by a number of companies
currently, not only for managing servers but also for network related
resources such as SANs (the SNIA BlueFin CIM model is very much in the
press) or routers. As some of you know, the DMTF has cooperated with other
expert groups in the past, e.g. with the IETF in the PCIM work, and with
the SNIA in the PDP/Bluefin work. We should also be careful to distinguish
CIM schemas and CIMOM instrumentation/infrastructure. One can use the CIM
schemas without using CIMOM infrastructure (as JSR77 or various LDAP
mappings show), particularly one can render CIM schemas as Web Services.
The way how existing SNMP infrastructure could be used this way is that
CIMOM infrastructure or a Web Services infrastructure reaches down to SNMP,
and the SNMP MIBs get mapped into CIM schemas by the use of the
MappingStrings qualifier of CIM.

A well accepted common protocol does not exist yet, and Web Services are a
very good opportunity to become this protocol. Currently, there are
multiple initiatives under way to define a web services based protocol for
management:
   - the OASIS work group "Management Protocol TC", which wants to produce
   an OASIS standard for this. It originally was set up to define a web
   services protocol just for CIMOMs, but this group has broadened their
   scope now to all kinds of underlying instrumentation. I'm participating
   in this work group.
   - there are several company initiatives to use web services for
   management, e.g. OMI from HP or OGSA from us which we standardize in the
   GGF (www.gridforum.org). I'm also participating in this aspect of OGSA.
   - the NMRG as you are well aware of ;-)
If multiple groups define their own flavor of web services based management
protocol each, we would not really advance the industry. I cannot judge at
this point which group will be successful and accepted at the end of the
day. So at this point, let's be aware of the various groups involved in
this area, let's talk between the groups, and let's find ways to foster
integrated management solutions that span across different mgmt areas,
which depends on common protocols and common schemas.

Kind Regards,
Andy

Andreas Maier
IBM Senior Technical Staff Member, eServer Software Design
IBM Lab Boeblingen, [email-masked], +49-7031-16-3654
------- End of forwarded message -------

From: "Larry Menten" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, "Nmrg \(E-mail\)" <[email-masked]>
Date: Sun, 15 Sep 2002 09:54:33 -0400
Subject: [nmrg] Re: IRTF-NMRG.ppt
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C25C9D.E49C3AE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

Sorry for the delay!  I was unavoidably detained
at the medical clinic!  :  )

Attached are updates to the visuals as I had promised
Bert to provide.

Larry

----- Original Message ----- 
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nmrg (E-mail)" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, September 15, 2002 5:23 AM
Subject: FW: IRTF-NMRG.ppt

> Here are the slides from a Lucent/Bell-labs researcher who
> has implemenation of XML-based configuration for OSPF and
> other protocols. Larry has not yet send me the details he
> sort of promised.
> 
> Thanks,
> Bert 
> 
> -----Original Message-----
> From: Larry Menten [mailto:[email-masked]]
> Sent: vrijdag 13 september 2002 16:13
> To: Bert Wijnen
> Subject: IRTF-NMRG.ppt
> 
> Bert,
> 
> Here is a draft of the visuals.  I will prepare some examples
> to support these points and will provide additional material
> to address the issues enumerated in the agenda.  If handouts
> are acceptable, we can provide our viewpoints on those
> additional issues that way.
> 
> Regards,
> 
> Larry
> 
> 

------=_NextPart_000_001F_01C25C9D.E49C3AE0
Content-Type: application/powerpoint;
	name="IRTF-NMRG.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="IRTF-NMRG.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAIAAAAbgMAAAAAAAAA
EAAAcAMAAAEAAAD+////AAAAACkDAAAqAwAAKwMAACwDAAAtAwAALgMAAG8DAACAAwAA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////8A
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////AP//////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////8A//////////////////////////////////////8A////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////8AAAD/AAAA/wAA//8AAP//AP8A/wAAAAAAAAAAAAD/AP//AP//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////AAAAAAAA
AAAAAAAAAAD/AAD/AAAAAAAAAAAAAAAA/wAA/wAA////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////wD/////////////////////
//////8AAP//AP8AAP8A////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////wD/////////////////AP//////////////
////////////////////////////////////////////////////AP//////////////////////
////////////////////////////////////////////////////////////////////////////
//////////8AAAAA/wAAAP8A//8A//8AAP//AAAA/wAAAAAAAAAA/wAAAP//////AAAA//8A////
AAD//wD/AAAA//8AAP8AAP8AAAD/AAD/AP8A/wAAAP8AAAD/AAD//wD/AAAA/wD/AP8AAAAAAAAA
/wAA//8A/wD/AAD/AP///wD/AAAA/wAA//////////////////////////////////////8AAAAA
AP8AAAAAAAD/AAD/AAAA/wAAAAAAAAAAAAAAAAAAAAAAAP///wAAAAD/AAD//wAAAP8AAAAAAAD/
AAD/AAAAAAAAAAAAAAAAAP8AAAAAAAAA/wAA/wAAAAAAAAAA/wAAAAAAAAAAAP8AAP8AAP8A/wAA
AAAA/wAA/wAAAAAAAP///////////////////////////////////////////////////wD/////
/////////////////////////////////////wD//wD/////////AP///////wD///////8A////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////AP//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/wAAAAD/AAAA/wD//wD//wD/AP///wD/AAD/AP8A/wAAAP///wAAAP8AAP//////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////wAAAAAA/wAAAAAA
AP8AAP8A/wAAAP8AAAAAAAAAAAAAAAD//wAAAAAAAAD/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////AP//////AP///wD/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////8A////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////AAD//wD/AP8AAAAA//8A
AAAAAP///wAAAP8A/wAAAP//AP//AP///wAA////AP8AAP8AAAAA/wD/AAAAAP//AP//AAD/AP//
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////wAAAP8A/wAAAAAAAP8AAAAAAAD//wAAAAD/
AP8AAAAA/wAA/wAA//8AAAD//wAAAAD/AAAAAP8A/wAAAAD//wD//wAAAAAA////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////8A//////////////////////////////////////////8A////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////wD///////////////////////8A////////AP//////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////AP8AAAAAAAD/AP///wAA/wD/AAD/AAD/AAD/////AAAA//8A
AAAAAP///wAAAP8AAP8AAP8AAP//AAAA/wAAAAAAAAD/AAD/AP///wAA//8AAAAA//8A////////
////////////////////////////////////////////////////////////////////////////
/////////////wAAAAAAAAAAAAAA//8AAP8AAAAA/wAA/wAAAP8A/wAAAAD/AAAAAAAAAP8AAAAA
AAAAAAAAAAD//wAAAAAAAAAAAAAAAAAA/wAAAP8AAAD/AAAAAAAAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////AP////////////////////8A/////////////////////////wD//////////wD///////8A
//////8A/////////////////////wD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////8A////////
////////////////////////////////////////////AP////8A////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////AAAAAP//AAD/AAAAAAAAAP8AAAD/////AP8A////
AAAA////AAAA////AAAA//8AAP8AAAAAAAAAAP8AAP8AAAD//////wAA/////wAAAAD///8AAP8A
AP8A////////////////////////////////////////////////////////////////////////
/////////////////////wAAAAD/AAAA/wAAAAAAAAAAAAAAAAD//wD/AAAA/wAAAAAAAAAAAP8A
/wAAAAD/AAD/AAAAAAAAAAAAAAAAAAAAAP8A//8AAAD//wAAAAAAAAAAAAD/AAAAAP//////////
////////////////////////////////////////////////////////////////////////////
//////////////////8A//////////////////8A/////////////////wD/AP//////////////
//8A//////////////////////8A/////////////wD/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////AP//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////8A////////////////////////////////////////////
////////////////AP//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////AAAA//8AAAD/AAD//wD/AP//AP8AAAD/AAD//wAAAAD//wAA//8AAAD/AAD/
AAAAAAAA//8AAAD/////////AAD/AP8A////AP8AAAD//wD/////////////////////////////
////////////////////////////////////////////////////////////////////////////
/wAAAAD/AAAA/wAA/wAAAAAA/wAAAAAA/wAAAP8AAAAA//8AAAD/AAAAAAAA/wAAAAAAAAD/AAAA
AP8A//8A/wAA/wAAAP8A/wD/AAAAAAAA////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////AP//////////////////////////////////////////////////AP//////
//////8A////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////+U42/NRs1pzc1Fzc3NzW/Nzc1vzWlozWnNRc1oQM3NaUbNRkVGaUVpaWlG
TGlGaUxGaUZGRm9qb0xpb2qOiG+Uk2+O47F0dY7j446O4451k9KTlJS2lJq2t5q3t5q8t5q8vZq3
vL29vd29vd693cO93r3e3f+94t7/3t7//8P/////////////////////////////////////////
////////zc3/zf/N/83Nzc3/zc3N/83N/83/zf/Nzf/Nzf//zf//////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////N/83/
zf/Nzc3N/83Nzf/N/83Nzc3/zf/Nzc3//83/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////zf/N///Nzc3N/83N/83/
/83Nzc3Nzc3Nzc3N/83Nzf//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////83/zf//////////////////////////////
////zf//////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------=_NextPart_000_001F_01C25C9D.E49C3AE0--

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Nmrg (E-mail)" <[email-masked]>
Cc: [email-masked]
Date: Sun, 15 Sep 2002 11:23:01 +0200
Subject: [nmrg] FW: IRTF-NMRG.ppt
Sender: [email-masked]

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_000_01C25C99.7B1947E2
Content-Type: text/plain

Here are the slides from a Lucent/Bell-labs researcher who
has implemenation of XML-based configuration for OSPF and
other protocols. Larry has not yet send me the details he
sort of promised.

Thanks,
Bert 

-----Original Message-----
From: Larry Menten [mailto:[email-masked]]
Sent: vrijdag 13 september 2002 16:13
To: Bert Wijnen
Subject: IRTF-NMRG.ppt

Bert,

Here is a draft of the visuals.  I will prepare some examples
to support these points and will provide additional material
to address the issues enumerated in the agenda.  If handouts
are acceptable, we can provide our viewpoints on those
additional issues that way.

Regards,

Larry

------_=_NextPart_000_01C25C99.7B1947E2
Content-Type: application/powerpoint;
	name="IRTF-NMRG.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="IRTF-NMRG.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAFAAAAYQIAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAFwCAABdAgAAXgIAAF8CAABgAgAA////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////AP//////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////wD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////AAAAAP8A
/wD//wAA//8A//8A/wD/AP//AAAA//8A//8AAP//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////AAAAAAD/AP8A/wD/AAAA////
AP8AAAAA/wAAAP8AAAD/AAD/////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////wAAAAAA/wAAAP8A/wAAAAD//wAAAAAAAP8AAAD/
AAAAAAAAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////8A////////////////////////////AAD///8A/wAAAP8A////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////AP8A/wAAAP8A////
AAD/////AP///wD/AAD/AP8AAAAA/wD//wAA/wD/AP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////AP//AAAAAAD/AP8A/wAA////AAD//wAA
/wAAAP//AAAAAP8A//8AAP8A/wAA////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////wAA/wAAAAAA/wAAAAAAAAD//wAA/wAAAAAAAAAAAAAAAAD/
AP8AAAD/AAAAAP//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////wD/AP////8A////AAD///////8A/////////wD/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////8AAP8A//8A//8A/wAA/wD//////wD/AP8A/wD/
/wAAAP8A//8AAP//AP//AP8AAAD//wD///8AAP///wAA//8A//8A/wD/AAAAAP8A//8A/wAA////
AP8A/wD//wD/////////////////////////////////////////////////////////////////
////////////////////////AAD/AP//AP8A/wAAAP8AAP//AP8A/wD/AP8AAP8AAP//AAD/AAD/
AP///wAAAAAA//8A/wD/AAD///8AAP//AP//AP8AAAAAAAD/AP//AAAAAP///wD/AAD///8A////
////////////////////////////////////////////////////////////////////////////
/////////wAA/wAA/wD/AP8AAAD/AAD//wD/AP8A/wAAAAD/AAAA/wAA/wAA/wAA//8AAAAAAP//
AAAAAAAAAP//AAD/AAAA/wAAAAAAAAAA/wD//wAAAAD///8A/wAAAP8AAAD/////////////////
////////////////////////////////////////////////////////////////////////////
////////AP8A//////8A////////////////////////AP//////////////////AP8A////////
//8A/////////wD///////////8A/////////////wD/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////AAAA////AAD/AAAAAP8AAP8A/wD///8A//8A//8AAP//AP8AAAD/AP//
/wD//wD//wAA/wAAAP8AAP8A/wAA/wD//wD//wD/AP//////AP8A/wD//wD/AP8A//8A////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////lONvzUbNac3N
Rc3Nzc1vzc3Nb81paM1pzUXNaEDNzWlGzUZFRmlFaWlpRkxpRmlMRmlGRkZvam9MaW9qjohvlJNv
juOxdHWO4+OOjuOOdZPSk5SUtpSatreat7eavLeavL2at7y9vb3dvb3evd3Dvd693t3/veLe/97e
///D/////////////////////////////////////////////////83N/83/zf/Nzc3N/83Nzf/N
zf/N/83/zc3/zc3//83/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////zf/N/83/zc3Nzf/Nzc3/zf/Nzc3N/83/zc3N
///N////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////83/zf//zc3Nzf/Nzf/N///Nzc3Nzc3Nzc3Nzf/Nzc3/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////N/83//////////////////////////////////83/////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAA

------_=_NextPart_000_01C25C99.7B1947E2--

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Randy Bush <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: RE: [nmrg] hotels and saturday dinner
Date: Sun, 15 Sep 2002 10:07:57 +0200
Sender: [email-masked]

Watch out, that may be ITU-T territory

Thanks,
Bert 

> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: zondag 15 september 2002 9:47
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> Subject: Re: [nmrg] hotels and saturday dinner
> 
> 
> > if you are done with them, you can enjoy rfc 3252
> 
> and do we have an xml description of packet-over-sdh/sonet and
> xml for sdh/sonet?
> 
> randy
> 
> -- 
> !! 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

From: Randy Bush <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] hotels and saturday dinner
Date: Sun, 15 Sep 2002 10:46:33 +0300
Sender: [email-masked]

> if you are done with them, you can enjoy rfc 3252

and do we have an xml description of packet-over-sdh/sonet and
xml for sdh/sonet?

randy

Date: Sat, 14 Sep 2002 14:38:24 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Re: nmrg meeting arrival
Sender: [email-masked]

>>>>> Margaret Wasserman writes:

Margaret> Walking sounds fine (assuming the weather holds).  So, I
Margaret> will see you at the Walhalla around 6:40pm...

Margaret> The Walhalla is rather a strange building.  Should we meet
Margaret> at the Walhalla Garten entrance?

I have not been inside so everything is fine with me. :-)

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Sat, 14 Sep 2002 08:37:13 -0400
To: Juergen Schoenwaelder <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: [nmrg] Re: nmrg meeting arrival
Cc: [email-masked]
Sender: [email-masked]

Walking sounds fine (assuming the weather holds).  So, I will
see you at the Walhalla around 6:40pm...

The Walhalla is rather a strange building.  Should we meet
at the Walhalla Garten entrance?

Margaret

At 08:31 AM 9/14/02, Juergen Schoenwaelder wrote:

> >>>>> Margaret Wasserman writes:
>
>Margaret> I have arrived in Osnabrueck.  I am at the Walhalla Hotel,
>Margaret> and I would be happy to join folks for a group dinner, if
>Margaret> one is happening...
>
>Margaret> Just let me know when and where.
>
>I propose to go to the Weinstube Jodukus located at Kommenderiestrasse
>116a. If you do not mind some walking, I will simply pick up folks at
>the Hotels. I will be at Hotel Klute around 6:30 and we can walk
>together from there to the Hotel Walhalla (probably 10 minutes) to
>pick up the other folks and then we can all walk together to Jodukus.
>If the whether is not good, I will either bring my car or we take a
>taxi. I will leave messages in the hotels for those still traveling.
>
>See you later,
>
>/js
>
>--
>Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Sat, 14 Sep 2002 14:31:36 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Re: nmrg meeting arrival
Sender: [email-masked]

>>>>> Margaret Wasserman writes:

Margaret> I have arrived in Osnabrueck.  I am at the Walhalla Hotel,
Margaret> and I would be happy to join folks for a group dinner, if
Margaret> one is happening...

Margaret> Just let me know when and where.

I propose to go to the Weinstube Jodukus located at Kommenderiestrasse
116a. If you do not mind some walking, I will simply pick up folks at
the Hotels. I will be at Hotel Klute around 6:30 and we can walk
together from there to the Hotel Walhalla (probably 10 minutes) to
pick up the other folks and then we can all walk together to Jodukus.
If the whether is not good, I will either bring my car or we take a
taxi. I will leave messages in the hotels for those still traveling.

See you later,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Sat, 14 Sep 2002 08:09:40 -0400
To: Juergen Schoenwaelder <[email-masked]>
From: Margaret Wasserman <[email-masked]>
Subject: Re: [nmrg] Re: nmrg meeting arrival
Cc: Network Management Research Group <[email-masked]>
Sender: [email-masked]

Hi Juergen,

I have arrived in Osnabrueck.  I am at the Walhalla Hotel,
and I would be happy to join folks for a group dinner, if
one is happening...

Just let me know when and where.

BTW, I am staying here through Monday.

Margaret

From: Frank Strauss <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [nmrg] hotels and saturday dinner
Date: 13 Sep 2002 19:56:17 +0200
Lines: 21
Sender: [email-masked]

Hi!

Randy> could you email the list of internet-draft filenames, please.
Randy> it will be useful for those on planes and trains who mirror the
Randy> archive.

Juergen> documents that happen to be internet-drafts are

Juergen> draft-hollenbeck-ietf-xml-guidelines-06.txt
Juergen> draft-shafer-js-xml-api-00.txt
Juergen> draft-megacz-xmc-01.txt

Juergen> if you are done with them, you can enjoy rfc 3252

Two other I-Ds that have also been prepared and proposed for the
XMLCONF BOF at the last IETF meeting:

draft-goddard-xmlconf-survey-00.txt
draft-wasserman-xmlconf-req-00.txt

 -frank

Date: Fri, 13 Sep 2002 19:06:34 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] hotels and saturday dinner
Sender: [email-masked]

>>>>> Randy Bush writes:

Randy> could you email the list of internet-draft filenames, please.
Randy> it will be useful for those on planes and trains who mirror the
Randy> archive.

documents that happen to be internet-drafts are

draft-hollenbeck-ietf-xml-guidelines-06.txt
draft-shafer-js-xml-api-00.txt
draft-megacz-xmc-01.txt

if you are done with them, you can enjoy rfc 3252

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Fri, 13 Sep 2002 19:00:47 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [nmrg] Re: nmrg meeting arrival
Sender: [email-masked]

>>>>> Juergen Schoenwaelder writes:

: I am CC'ing this to all since there are others coming by car
: from the Netherlands. It is actually pretty easy to get to
: the Schloss:
: 
: 1. Leave the A30 at Osnabrueck-Hellern
: 2. Turn left (direction city center)
: 3. Go straight ahead until you see the Schloss on the right side
: 4. Turn right right after the Schloss and try to find a place to 
:    park your car. I guess this won't be a problem on Sunday morning.

Actually, you have to turn right in step 2. to reach the city center
since the exit does turn you into the other direction. (Thanks Frank
for debugging this.)

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Fri, 13 Sep 2002 18:18:11 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] Re: nmrg meeting arrival
Sender: [email-masked]

>>>>> Wijnen, Bert (Bert) writes:

Bert> Correct, I arrive Sunday morning (I need to be at home on
Bert> Saturday eve). I plan to leave around 6am, so I expect to arrive
Bert> around 9:30 (if I do not get lost). If you have any specific
Bert> directions for once I hit the city of Osnabrueck and where I can
Bert> park, that would be great.

I am CC'ing this to all since there are others coming by car from the
Netherlands. It is actually pretty easy to get to the Schloss:

1. Leave the A30 at Osnabrueck-Hellern
2. Turn left (direction city center)
3. Go straight ahead until you see the Schloss on the right side
4. Turn right right after the Schloss and try to find a place to 
   park your car. I guess this won't be a problem on Sunday morning.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

From: Randy Bush <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] updated hotel and contact list
Date: Fri, 13 Sep 2002 19:07:49 +0300
Sender: [email-masked]

it looks like i will miss dinner saturday.  something i need
to do in amsterdam enroute.  so i will not arrive until 21:00

randy

Date: Fri, 13 Sep 2002 17:45:27 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] updated hotel and contact list
Sender: [email-masked]

Some minor updates/corrections lead to this version:

Olivier Festor                  Hotel Klute             Sa-?
Dave Perkins                    Hotel Klute             Sa-Tu
Phil Shafer                     Hotel Walhalla          Sa-?
Juergen Schoenwaelder           Herderstr. 33           Fr-Tu
Margaret Wasserman              Hotel Walhalla          Sa-
Bert Wijnen                     Hotel Walhalla          So-Mo ?
Randy Bush                      Hotel Walhalla          So-Mo ?
Aiko Pras                       Hotel Walhalla (?)      So-Mo
Jean-Philippe Martin-Flatin     Herderstr. 33           So-Mo
Frank Strauss                   Herderstr. 33           So-Mo
Mario Jeckle

Hotel Klute:    +49 541 409120
Hotel Walhalla: +49 541 34910
Herderstr. 33:  +49 175 7883428 (Juergen's cell phone)

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Fri, 13 Sep 2002 14:28:16 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] hotels and saturday dinner
Sender: [email-masked]

Juergen Schoenwaelder wrote:
> And for those who still need reading material, I would like to add RFC
> 3252 "Binary Lexical Octet Ad-hoc Transport" to the reading list.

This is a good RFC. We're currently working on a security extension of it. 
The idea is as follows. You know all future traffic will use port 80. We now 
want to introduce "sub-ports". Basically sub-port 80-A will be all traffic 
that should pass the firewall; 80-B will be blocked by firewalls.

Aiko

From: Randy Bush <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] hotels and saturday dinner
Date: Fri, 13 Sep 2002 14:31:26 +0300
Sender: [email-masked]

could you email the list of internet-draft filenames, please.  it will
be useful for those on planes and trains who mirror the archive.

randy

Date: Fri, 13 Sep 2002 11:41:44 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] hotels and saturday dinner
Sender: [email-masked]

I have compiled the following list which indicates where the various
people will be staying:

Olivier Festor                  Hotel Klute		Sa-?
Phil Shafer                     Hotel Walhalla		Sa-?
Dave Perkins                    Hotel Walhalla		Sa-Tu
Juergen Schoenwaelder           Herderstr. 33		Fr-Tu
Margaret Wasserman              Hotel Walhalla		?
Bert Wijnen                     Hotel Walhalla		So-Mo ?
Randy Bush                      Hotel Walhalla		So-Mo ?
Aiko Pras                       Hotel Walhalla (?)	So-Mo
Jean-Philippe Martin-Flatin     Herderstr. 33		So-Mo
Frank Strauss                   Herderstr. 33		So-Mo
Mario Jeckle

[Herderstr. 33 is my own little apartment in case you wonder and Mario
 will just be in Osnabrueck for the meeting on Sunday.]

I plan to make a dinner reservation in a nice place for Saturday
around 19:00 and I will leave a message at the Hotels for those who
will be in OS on Saturday evening.

And for those who still need reading material, I would like to add RFC
3252 "Binary Lexical Octet Ad-hoc Transport" to the reading list.

Have a good trip to Osnabrueck,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Fri, 13 Sep 2002 11:17:19 +0200
From: Aiko Pras <[email-masked]>
To: Phil Shafer <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: [nmrg] Draft agenda of the IRTF-NMRG meeting on web-services / XML
Sender: [email-masked]

Phil Shafer wrote:
>>- Scenarios
>>   Examples of possible tasks are: monitoring a la MRTG,
>>   configuring individual devices, configuring multiple devices,
>>   open service management, etc.
> 
> 
> Are you looking to get more specific? Configuring a filter/policer
> (one devices); Configure MPLS tunnels (two devices); Configure a
> VPN (multiple devices).

Yes, I want to select at the meeting a couple of examples (not too many) 
which we can work out.

Aiko

Date: Fri, 13 Sep 2002 11:11:25 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] Draft agenda of the IRTF-NMRG meeting on web-services / XML
Sender: [email-masked]

Juergen Schoenwaelder wrote:
>>>>>>Phil Shafer writes:
>>>>>
> 
> Phil> Would it work better to handle the broad topic first, since many
> Phil> of its issues will get discussed in the web-services discussion.
> 
> We managed to get Mario Jeckle (a web services expert) into the
> meeting, but he will only be available on Sunday. This probably
> explains why Aiko plans to focus on web services on Sunday.
> 
> Aiko, correct me if my interpretation is wrong.

You're right

Aiko

Date: Fri, 13 Sep 2002 10:39:45 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] Draft agenda of the IRTF-NMRG meeting on web-services / XML
Sender: [email-masked]

>>>>> Phil Shafer writes:

Phil> Would it work better to handle the broad topic first, since many
Phil> of its issues will get discussed in the web-services discussion.

We managed to get Mario Jeckle (a web services expert) into the
meeting, but he will only be available on Sunday. This probably
explains why Aiko plans to focus on web services on Sunday.

Aiko, correct me if my interpretation is wrong.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

To: Aiko Pras <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Subject: Re: [nmrg] Draft agenda of the IRTF-NMRG meeting on web-services / XML 
Date: Thu, 12 Sep 2002 08:59:34 -0400
From: Phil Shafer <[email-masked]>
Sender: [email-masked]

Aiko Pras writes:
>Below you'll find the draft agenda.

Sounds good.
>In any case I think it would be good to distinguish at the meeting 
>between two main topics:
>1) web-services (SOAP, WSDL, ...) for management: the scope of this
>    topic is narrow
>2) XML for management: in this catagory falls everything that is not
>    web-services, but still based on XML. The scope is therefore
>    quite broad.

Would it work better to handle the broad topic first, since many
of its issues will get discussed in the web-services discussion.

>- Scenarios
>    Examples of possible tasks are: monitoring a la MRTG,
>    configuring individual devices, configuring multiple devices,
>    open service management, etc.

Are you looking to get more specific? Configuring a filter/policer
(one devices); Configure MPLS tunnels (two devices); Configure a
VPN (multiple devices).

Thanks,
 Phil

Date: Thu, 12 Sep 2002 10:47:44 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Aiko Pras <[email-masked]>
Subject: [nmrg] Draft agenda of the IRTF-NMRG meeting on web-services / XML
Sender: [email-masked]

Hi all

The idea of the next IRTF-NMRG meeting is to investigate the advantages
/ disadvantages of using web-services / XML for Internet management.
The meeting can be seen as a follow up of our previous Pisa meeting (in 
which we discussed Network Management Visions), and the june IAB 
workshop (future directions for Internet management). The meeting has 
the form of a workshop; the main outcome will be a better understanding 
of the issue. It is not the intention to produce detailed technical 
specifications.

Below you'll find the draft agenda. In fact the agenda is more a list of 
questions I would like to see answered at the meeting. We may add other 
questions (please give me your input) and we may discuss them in another 
order.

In any case I think it would be good to distinguish at the meeting 
between two main topics:
1) web-services (SOAP, WSDL, ...) for management: the scope of this
    topic is narrow
2) XML for management: in this catagory falls everything that is not
    web-services, but still based on XML. The scope is therefore
    quite broad.

Also I would like to ask all of you to prepare two short presentations, 
in which you summarize the key reasons why you think web-services will 
(not) become important for Internet management (see below).

Note we will have beamer, wireless LAN, whiteboard.

Aiko
-----------------------------------------------------------------------
1) Opening
- roll-call
- assignment of volunteers to write the minutes
- purpose of the meeting
- agenda bashing

2) Web-services for management
- Presentations
    Short presentations (3 minutes per presentation) in which each
    participant identifies the key reasons (not more then 3) why
    he / she believes that web-services will (not) become important
    for Internet management.
- Scenarios
    To streamline the discussion it would be nice to identify a
    couple of management tasks, and use these tasks as running
    examples throughout the meeting. For each of these tasks we
    will discuss how web-services would help / fail to perform
    these tasks.
    Examples of possible tasks are: monitoring a la MRTG,
    configuring individual devices, configuring multiple devices,
    open service management, etc.
- Key technologies
    What are, in our opinion, the key web-services technologies
    for management. For example, will next to SOAP and WSDL,
    UDDI play a role?
- Status
    What is the status of these standards? Are they stable?
    Are there sufficient implementations? Do they interoperate?
- Architecture
    What will be the impact of web-services on our current
    manager-agent architecture? How to deal with notifications?
    How does it relate to distributed management (DISMAN).
- Granularity
    What should be the granularity of web-services for management?
    Should it be low, where we have a specific method for each
    managed object? Or should it be high, where we have a small
    number of generic methods (like Get and Set), for a large number
    of attributes.
- Security
    Is the security provided by web-services good enough for management?
    We should distinguish between transferring management data,
    firewalls, and access to management data. Will there be stable
    technology for security, or will it (in particular access control)
    be a battlefield for the years to come (see MS-Passport versus
    Liberty Alliance)? Can we use the WS-security specification?
- Transactions
    Although SNMP does not support transactions, certain management
    tasks would (most likely) be easier with transactions.
    Should we use the results of other initiatives in this area (like
    ebXML?)
- Performance
    What are the costs of implementing these standards, in terms of
    system load, network load, etc?
- Ease of implementation
    At the "manager" side, how easy is it to build management
    applications that use web-services? What tools are availables?
    Same question for the "agent" side, would it be possible to use
    the same tools to develop CLI and web-services interfaces?
- Migration
    Will there be an evolutionary path, in which we for example
    translate current SMI specifications into WSDL specifications,
    or should we start from scratch. Can we learn from others,
    like the DMTF or the OASIS standards consortium?

3) XML for management
For this part of the meeting the same questions can be discussed as for 
the previous part. Again I would like to start withs short presentations 
to explain why XML will (not) become important

4) Closing of the meeting
- what will we do with the results? Write Internet-drafts / RFCs?
    Propose IETF WGs? Write papers?
- Next meeting
    Where, when, why?

Additional reading
OASIS: http://www.oasis-open.org/news/oasis_news_09_10_02.shtml
WS-security: http://www.verisign.com/wss/wss.pdf
XML Method Call (XMC): draft-megacz-xmc-01.txt
SyncML: http://www.syncml.org/

Date: Thu, 12 Sep 2002 00:05:27 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: IRTF Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-im-dm-02.txt
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------010208020604020604030106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Please find enclosed the new version that I propose for the I-D. I have 
made lots of minor editorial changes plus a few semantic changes. In short:

1) I have taken out the explicit references to the date of the 8th NMRG 
workshop because they made me jump when I read the document. I think we 
should not put in the spotlight that it took us almost two years to produce 
this RFC.

2) Page 3, I have suppressed the term "feeling" because I think we should 
avoid it here. Our work was not triggered by a mere feeling.

3) Page 6, I have moved some material out of the bullet on CIM Schemas in 
order to keep the balance with the previous bullets on PIBs and ITU-T MIBs. 
I have also mentioned that only MOF is normative.

4) Still page 6, I don't like the use of the word "manifested" for indexing 
relationships. Is "documented" any better?

5) Last, I have rephrased Section 5 on Security. If you don't like the new 
wording, "themself" should read "themselves" in the current text.

Juergen, I am sorry that I could not review this document before today. 
Thanks for your patience.

JP

--------------010208020604020604030106
Content-Type: text/plain;
 name="draft-irtf-nmrg-im-dm-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-irtf-nmrg-im-dm-02.txt"

NMRG                                                             A. Pras
Internet-Draft                                      University of Twente
Expires: March 12, 2003                                 J. Schoenwaelder
                                                University of Osnabrueck
                                                      September 12, 2002

      On the Difference between Information Models and Data Models
                      draft-irtf-nmrg-im-dm-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 4, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   There has been ongoing confusion about the differences between
   Information Models and Data Models.  This document explains the
   differences between these terms by analyzing how existing network
   management model specifications (from the IETF and other bodies such
   as the ITU or the DMTF) fit into the universe of Information Models
   and Data Models.

   This memo documents the main results of the 8th workshop of the
   Network Management Research Group (NMRG) of the Internet Research
   Task Force (IRTF) hosted by the University of Texas at Austin.

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 1]

Internet-Draft     Information Models vs. Data Models     September 2002

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3. Information Models . . . . . . . . . . . . . . . . . . . . . . . 4
   4. Data Models  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 7
   6. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 7
      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
      Informative References . . . . . . . . . . . . . . . . . . . . . 8
      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
      Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 2]

Internet-Draft     Information Models vs. Data Models     September 2002

1. Introduction

   Currently multiple languages exist to define managed objects.
   Examples of such languages are the Structure of Management
   Information (SMI) [1], the Structure of Policy Provisioning
   Information (SPPI) [2] and, within the DMTF, the Managed Object
   Format (MOF) [3].  Despite the fact that multiple languages exist,
   a number of people still believe that none of these languages
   really suit all needs.

   There have been many discussions to understand the advantages and
   disadvantages, as well as the main differences, between various
   languages. For instance, the IETF organized a BoF meeting on
   "Network Information Modeling" (NIM) at its 48th meeting. During
   these discussions, it turned out that people had a different
   understanding of the main terms, which caused confusion and long
   arguments. In particular, the meaning of the terms "Information
   Model" (IM) and "Data Model" (DM) is controversial.

   In an attempt to address this issue, the IRTF Network Management
   Research Group (NMRG) dedicated its 8th workshop to harmonizing
   the terminology used in information modeling.  Attendees included
   experts from the IETF, DMTF and ITU, as well as academics who do
   research in this field (see the Acknowledgements section for a
   list of participants).  The main outcome of this very successful
   workshop--a better understanding of the terms "Information Model"
   and "Data Model"--is presented in this document.

   Short definitions of these terms can also be found elsewhere
   (e.g., in RFC 3198 [8]).  Compared to most other documents, this
   one explains the rationale behind the proposed definitions and
   provides examples.

2. Overview

   One of the interesting observations made at the IRTF NMRG workshop
   was that IMs and DMs are different because they serve different
   purposes.

   The main purpose of an IM is to model managed objects at a
   conceptual level, independent of any specific implementations or
   protocols used to transport the data.  The degree of specificity
   (or detail) of the abstractions defined in the IM depends on the
   modeling needs of its designers.  In order to make the overall
   design as clear as possible, an IM should hide all protocol and
   implementation details.  Another important characteristic of an
   IM is that it defines relationships between managed objects.

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 3]

Internet-Draft     Information Models vs. Data Models     September 2002

   DMs, conversely, are defined at a lower level of abstraction and
   include many details.  They are intended for implementors and
   include protocol-specific constructs.

                   IM                --> conceptual/abstract model
                    |                    for designers and
         +----------+---------+          administrators
         |          |         |
         DM        DM         DM     --> concrete/detailed model
                                         for implementors

   The relationship between an IM and DM is shown in the Figure above.
   Since conceptual models can be implemented in different ways,
   multiple DMs can be derived from a single IM.

   Although IMs and DMs serve different purposes, it is not always
   possible to precisely define what kind of details should be
   expressed in an IM and which ones belong in a DM.  There is a gray
   area where IMs and DMs overlap-just like there are gray areas
   between the models produced during the analysis, high-level design
   and low-level design phases in object-oriented software engineering.
   In some cases, it is very difficult to determine whether an
   abstraction belongs an IM or a DM.

3. Information Models

   IMs are primarily useful for designers to describe the managed
   environment, for administrators to understand the modeled objects,
   and for implementors as a guide to the functionality that must be
   described and coded in the DMs.  The terms "conceptual models" and
   "abstract models", which are often used in the literature, relate
   to IMs.  IMs can be implemented in different ways and mapped on
   different protocols. They are protocol neutral.

   An important characteristic of IMs is that they can (and generally
   should) also specify relationships between objects.  Organizations
   may use the contents of an IM to delimit the functionality that
   can be included in a DM.

   IMs can be defined in an informal way, using natural languages such
   as English.  An example of such an IM is provided by RFC 3290 [9],
   which describes a conceptual model of a Diffserv Router and specifies
   the relationships between the components of such a router that need
   to be managed.  Within the IETF, however, it is exceptional that an
   IM be explicitly described, and even more that the IM and DM be
   specified in separate RFCs. In such cases, the document specifying
   the IM is usually an Informational RFC whereas the RFC defining the
   DM usually follows the Standards Track [4].  In general, most of
   the RFCs that define an SNMP Management Information Base (MIB) module
   also include some kind of informal description explaining parts of
   the model behind that MIB module--especially recent RFCs.  Such a
   model can be considered as a draft of an IM.  An example of this is

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 4]

Internet-Draft     Information Models vs. Data Models     September 2002

   RFC 2863, which defines "The Interfaces Group MIB" [10].  But most
   MIBs published to date simply include a rudimentary and incomplete
   description of the underlying IM.  Some MIBs, unfortunately, do not
   include anything that even remotely resembles an IM.

   Alternatively, IMs can be defined using a formal language or a
   semi-structured language.  One of the possibilities to formally
   specify IMs is to use UML class diagrams.  Although such diagrams
   are still rarely used within the IETF, several other organizations
   routinely use them for defining IMs, including the DMTF, the ITU-T
   SG 4, 3GPP SA5, the TeleManagement Forum, and the ATM Forum.  An
   important advantage of UML class diagrams is that they represent
   objects and the relationships between them in a standard graphical
   way.  Because of this graphical representation, designers and
   administrators may find it easier to understand the underlying
   management model.  Although there are other techniques to
   graphically represent objects and relationships--e.g., Entity-
   Relationship (ER) diagrams, UML presents the advantage of being
   widely adopted in industry and taught in universities.  Also, many
   tools for editing UML diagrams are now available.  UML is
   standardized by the Object Management Group (OMG) [5].

   In general, it seems advisable to use object-oriented techniques to
   describe an IM.  In particular, the notions of abstraction and
   encapsulation, as well as the possibility that object definitions
   include methods, are considered to be important.

4. Data Models

   Compared to IMs, DMs define managed objects at a lower level of
   abstraction.  They include implementation- and protocol-specific
   details, e.g. rules that explain how to map managed objects onto
   lower-level protocol constructs.

   The MIB modules defined within the IETF are DMs.  The language
   (syntax) used to define these DMs is called the "Structure of
   Management Information" (SMI) [1] and is derived from ASN.1 [6].

   Most of the management models standardized to date are DMs.
   Examples include:

   o  Policy Information Base (PIB) modules, developed within the
      IETF.  Their syntax is defined by the "Structure of Policy
      Provisioning Information" (SPPI) [2], which is close to SMI
      and is also derived from ASN.1.

   o  Management Information Base (MIB) modules, originally defined
      by the ISO and currently maintained and enhanced by the ITU-T.
      The syntax of these DMs is specified in the "Guidelines for the
      Definition of Managed Objects" (GDMO) [7].  GDMO MIB modules
      make use of object-oriented principles.

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 5]

Internet-Draft     Information Models vs. Data Models     September 2002

   o  CIM Schemas, developed within the DMTF.  The DMTF publishes them
      in two forms: graphical and textual.  The graphical forms use
      UML diagrams and are not normative (because not all details can
      be represented graphically).  They can be downloaded from the
      DMTF Web site in PDF and Visio formats (Visio is a tool to draw
      UML class diagrams.)  The textual forms are normative and
      written in a language called the "Managed Object Format" (MOF)
      [3]. CIM Schemas are object-oriented.

   Because CIM Schemas support a graphical notation whereas IETF MIB
   modules do not, designers and administrators may find it easier to
   understand CIM Schemas than IETF MIB modules.  One could therefore
   argue that CIM Schemas are closer to IMs than IETF MIB modules.

   The Figure below summarizes these examples.  The languages that
   are used to define the DMs are shown between brackets.

                         IM                              --> IM
                          |
       +----------+-------+-------+--------------+
       |          |               |              |
      MIB        PIB          CIM schema      OSI-MIB    --> DM
     (SMI)      (SPPI)          (MOF)          (GDMO)

   To illustrate what details are included in a DM, let us consider the
   example of IETF MIB modules.  As opposed to IMs, IETF MIB modules
   include details such as OID assignments and indexing structures.
   The relationships defined in the IM are implemented as OID pointers
   and indexing relationships are documented in INDEX clauses.  Many
   other implementation-specific details are included, e.g. MAX-ACCESS
   and STATUS clauses and conformance statements.

   A special kind of DM language is the SMIng language defined by the
   IRTF NMRG.  This language was designed at a higher conceptual
   level than SMIv1/SMIv2 and SPPI.  In fact, one of the intentions
   behind SMIng was to stop the proliferation of different DM languages
   within the IETF and to harmonize the various models.  As a result,
   MIB and PIB modules defined in SMIng can be mapped on different
   underlying protocols. There is a mapping on SNMP and another mapping
   on COPS-PR.  SMIng is therefore more protocol neutral than other
   IETF approaches.  It also supports some object-oriented principles
   and provides extension mechanisms that allow the addition of new
   features (e.g., the support for methods).  New features can then be
   used when they are supported by the underlying protocols, without
   breaking SMIng implementations.  Still, SMIng should be considered
   a DM. For instance, to express relationships between managed
   objects, techniques such as UML and ER diagrams still give better
   results because these diagrams are easier to understand.

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 6]

Internet-Draft     Information Models vs. Data Models     September 2002

   Note that the IETF SMING Working Group took a different approach
   and decided not to use the SMIng language defined by the IRTF NMRG.
   Instead, the SMING Working Group is developing a third version of
   SMI (SMIv3) that is primarily targeted towards SNMP, and which
   incorporates only some of the ideas developed within the IRTF NMRG.

5. Security Considerations

   The meaning of the terms "Information Model" and "Data Model" has
   no direct security impact on the Internet.

6. Acknowledgments

   The authors would like to thank everyone who participated in the 8th
   IRTF NMRG workshop (in alphabetic order): Szabolcs Boros, Marcus
   Brunner, David Durham, Dave Harrington, Jean-Philippe Martin-Flatin,
   George Pavlou, Robert Parhonyi, David Perkins, David Sidor, Andrea
   Westerinen and Bert Wijnen.

Normative References

   [1]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
        M. and S. Waldbusser, "Structure of Management Information
        Version 2 (SMIv2)", RFC 2578, STD 59, April 1999.

   [2]  McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
        Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy
        Provisioning Information (SPPI)", RFC 3159, August 2001.

   [3]  Distributed Management Task Force, "Common Information Model
        (CIM) Specification Version 2.2", DSP 0004, June 1999.

   [4]  Bradner, S., "The Internet Standards Process -- Revision 3", RFC
        2026, October 1996.

   [5]  Object Management Group, "Unified Modeling Language (UML),
        Version 1.4", formal/2001-09-67, September 2001.

   [6]  International Organization for Standardization, "Information
        processing systems - Open Systems Interconnection -
        Specification of Abstract  Syntax Notation One (ASN.1)",
        International Standard 8824, December 1987.

   [7]  International Telecommunication Union, "Information technology -
        Open Systems Interconnection  - Structure of Management
        Information:  Guidelines for the Definition of Managed Objects",
        Recommendation X.722, 1992.

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 7]

Internet-Draft     Information Models vs. Data Models     September 2002

Informative References

   [8]   Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
         Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
         Waldbusser, "Terminology for Policy-Based Management", RFC
         3198, November 2001.

   [9]   Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal
         Management Model for Diffserv Routers", RFC 3290, May 2002.

   [10]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
         RFC 2863, June 2000.

Authors' Addresses

   Aiko Pras
   University of Twente
   PO Box 217
   7500 AE Enschede
   The Netherlands

   Phone: +31 53 4893778
   EMail: [email-masked]

   Juergen Schoenwaelder
   University of Osnabrueck
   Albrechtstr. 28
   49069 Osnabrueck
   Germany

   Phone: +49 541 969-2483
   EMail: [email-masked]

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 8]

Internet-Draft     Information Models vs. Data Models     September 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Pras & Schoenwaelder     Expires March 12, 2003                 [Page 9]

--------------010208020604020604030106--

Date: Wed, 11 Sep 2002 10:23:58 -0700
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Meeting on XML at cisco
Sender: [email-masked]

HI,

Ken Crozier at cisco hosted a meeting yesterday to talk about the
use of XML in their IE2100 product. The cisco documentation on
this product is found at the following URL:
   http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ie2100/index.htm

Wes Hardaker, Randy Presuhn, Steve Waldbusser, and Ted Goddard (from
Wind River) attended, plus the cisco development engineers (and a short
visit by Elliot Lear). We talked about many things, but in the end
it looked like there was some agreement about the possible
standardization of using a simple XML wrapper to supply config
content. Soap was thought to be way to heavy weight for this
outer wrapping. Maybe the most important item has the reminder that
existing vendors have a huge code base and to "switch" to a
new management mechanism cannot be done over a "short" period
of 18 months. Any approach must allow parallel operation over
a "5 year transition"!

More later. See you guys either saturday night or sunday morning.

Regards,
/david t. perkins

Date: Wed, 11 Sep 2002 18:29:35 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "J.P. Martin-Flatin" <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-im-dm-01
Sender: [email-masked]

I did not see any further comments and so I have posted the current
version as draft-irtf-nmrg-im-dm-01.txt. I will ask the RFC editor to
publish this version on Friday unless someone manages with very good
arguments to stop me.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 10 Sep 2002 07:39:03 -0700
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] Hotel Osnabrueck 
Sender: [email-masked]

HI,

You guys got all of the rooms, so I'm staying in Hotel Klute,
and will be taking the train with Phil on saturday.

At 08:54 AM 9/10/2002 -0400, Phil Shafer wrote:
>Randy Bush writes:
>>bert, margaret, and i are in the walhalla
>
>Same here. I'm arriving ~5pm Saturday.
>
>Thanks,
> Phil
>-- 
Regards,
/david t. perkins

Date: Tue, 10 Sep 2002 16:29:19 +0200
From: Aiko Pras <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] Hotel Osnabrueck
Sender: [email-masked]

Randy Bush writes:
>bert, margaret, and i are in the walhalla

Bierstrasse and Walhalla sounds like an offer I can't refuse :-)

To: Randy Bush <[email-masked]>
cc: Aiko Pras <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [nmrg] Hotel Osnabrueck 
Date: Tue, 10 Sep 2002 08:54:45 -0400
From: Phil Shafer <[email-masked]>
Sender: [email-masked]

Randy Bush writes:
>bert, margaret, and i are in the walhalla

Same here. I'm arriving ~5pm Saturday.

Thanks,
 Phil

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Aiko Pras <[email-masked]>, [email-masked]
Subject: RE: [nmrg] Hotel Osnabrueck
Date: Tue, 10 Sep 2002 14:51:22 +0200
Sender: [email-masked]

Well, or at least withing crawling distance :-)

Thanks,
Bert 

> -----Original Message-----
> From: Aiko Pras [mailto:[email-masked]]
> Sent: dinsdag 10 september 2002 11:54
> To: [email-masked]
> Subject: [nmrg] Hotel Osnabrueck
> 
> 
> Hi
> 
> Who has already reserved a hotel in Osnabrueck? Since they have good
> beers in Germany, it could be convenient to choose the same hotel...
> 
> Aiko
> -- 
> !! 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 
> <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Date: Tue, 10 Sep 2002 14:03:30 +0200
From: Olivier Festor <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [nmrg] Hotel Osnabrueck
Sender: [email-masked]

I did already make a reservation at :

Akzent-Hotel Klute**
Lotter Strasse 30
Fax: 05414091248
Phone : 0541409120

I will somehow (the transport binding has not been made yet) show up saturday late
afternoon, early evening.

Olivier

Aiko Pras wrote:

> Hi
>
> Who has already reserved a hotel in Osnabrueck? Since they have good
> beers in Germany, it could be convenient to choose the same hotel...
>
> Aiko
> --
> !! 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 <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

From: Randy Bush <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [nmrg] Hotel Osnabrueck
Date: Tue, 10 Sep 2002 04:00:40 -0700
Sender: [email-masked]

bert, margaret, and i are in the walhalla

randy

Date: Tue, 10 Sep 2002 12:03:21 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] dinner on saturday before the meeting
Sender: [email-masked]

Folks who already arrive in Osnabrueck on Saturday might want to join
for dinner on Saturday evening.

If you are interested, please drop me a note and let me know if you
have any dietary constraints. I will then organize something.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 10 Sep 2002 11:57:56 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] please post draft-irtf-nmrg-im-dm-01.txt
Sender: [email-masked]

Please post the following document as an Internet Draft:

<http://www.ibr.cs.tu-bs.de/~schoenw/draft-irtf-nmrg-im-dm-01.txt>

Thanks,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 10 Sep 2002 11:54:02 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [nmrg] Hotel Osnabrueck
Sender: [email-masked]

Hi

Who has already reserved a hotel in Osnabrueck? Since they have good
beers in Germany, it could be convenient to choose the same hotel...

Aiko

Date: Wed, 4 Sep 2002 17:55:50 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] upcoming meeting reading material
Sender: [email-masked]

I added pointers to some more interesting/relevant documents to the
meeting web page:

* Latency Performance of SOAP Implementations
  http://joe.lindsay.net/webservices/rutgers-p2p-p2pws02-soap.pdf

* XMC (a variant of XML-RPC)
  http://www.ietf.org/internet-drafts/draft-megacz-xmc-01.txt

Enjoy,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

From: "Andrea Westerinen" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, "Juergen Schoenwaelder" <[email-masked]>, "Network Management Research Group" <[email-masked]>
Subject: RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Date: Tue, 3 Sep 2002 16:18:07 -0700
Importance: Normal
Sender: [email-masked]

published_documents.php lists all the DSPs.  From there, you can hyperlink
to http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf.  I was trying to
list the complete DSP reference as opposed to the specific DSP0004.

Sorry for any confusion.
Andrea

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, September 03, 2002 4:12 PM
To: Andrea Westerinen; Juergen Schoenwaelder; Network Management
Research Group
Subject: RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status

Andrea writes:

> 7. Could you have reference [3] include the URL
>    http://www.dmtf.org/standards/published_documents.php?
> This is where DSP 0004 is permanently located.

Mmm... in the latest PCLS doc I see:

   http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf

So what is the authoritative place?

>
> Thanks.
> Andrea
>
Bert

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Andrea Westerinen <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Date: Wed, 4 Sep 2002 01:12:07 +0200 
Sender: [email-masked]

Andrea writes:

> 7. Could you have reference [3] include the URL
>    http://www.dmtf.org/standards/published_documents.php?  
> This is where DSP 0004 is permanently located.

Mmm... in the latest PCLS doc I see:

   http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf

So what is the authoritative place?

> 
> Thanks.
> Andrea
> 
Bert

From: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Date: Tue, 3 Sep 2002 13:58:46 -0700
Importance: Normal
Sender: [email-masked]

OK - since you feel so strongly about this :-).
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Schoenwaelder
Sent: Tuesday, September 03, 2002 1:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt status

>>>>> Andrea Westerinen writes:

Andrea> About reference [3]... If you don't add the DMTF document URL
Andrea> that is ok with me, but you do have a URL in reference [11].

So I will take out [11] - it is not really needed. :-)

Andrea> IMHO, it would help the readers of this document to (at least)
Andrea> get the high level URLs for DMTF (www.dmtf.org), OMG, ITU, etc
Andrea> since they might not know where to look for the references.

Except ITU, things are really extremely simple that even small kids
are likely to guess them correctly:

IRTF -> www.irtf.org
DMTF -> www.dmtf.org
OMG  -> www.omg.org
ITU  -> www.itu.int (but remarkably, www.itu.org works as well ;-)
ISO  -> www.iso.org

So rather adding the obvious letter combinations, I am now serious to
drop [11] altogether.

/js

--
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>
--
!! 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 <[email-masked]>
!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Date: Tue, 3 Sep 2002 22:51:46 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Sender: [email-masked]

>>>>> Andrea Westerinen writes:

Andrea> About reference [3]... If you don't add the DMTF document URL
Andrea> that is ok with me, but you do have a URL in reference [11].

So I will take out [11] - it is not really needed. :-)

Andrea> IMHO, it would help the readers of this document to (at least)
Andrea> get the high level URLs for DMTF (www.dmtf.org), OMG, ITU, etc
Andrea> since they might not know where to look for the references.

Except ITU, things are really extremely simple that even small kids
are likely to guess them correctly:

IRTF -> www.irtf.org
DMTF -> www.dmtf.org
OMG  -> www.omg.org
ITU  -> www.itu.int (but remarkably, www.itu.org works as well ;-)
ISO  -> www.iso.org

So rather adding the obvious letter combinations, I am now serious to
drop [11] altogether.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

From: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Date: Tue, 3 Sep 2002 13:40:07 -0700
Importance: Normal
Sender: [email-masked]

Discussion points up here:
- Your revised wording of #3 is ok with me.
- About reference [3]... If you don't add the DMTF document URL that is ok
with me, but you do have a URL in reference [11].  IMHO, it would help the
readers of this document to (at least) get the high level URLs for DMTF
(www.dmtf.org), OMG, ITU, etc since they might not know where to look for
the references.

Andrea

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, September 03, 2002 1:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt status

>>>>> Andrea Westerinen writes:

Andrea> A couple of comments on the draft:

Andrea> 1. The sentence, "In particularly the terms "Information
Andrea> Model" (IM) and "Data Model" (DM) (Section 1) turned out to be
Andrea> controversial."  should read "In PARTICULAR ...."

fixed

Andrea> 2. The sentence, "... its outcome, which is a better
Andrea> understanding of the terms "Information Model" and "Data
Andrea> Model", as presented in this document." (Section 1) should
Andrea> read "... its outcome, ..., IS presented in this document."

fixed

Andrea> 3. The sentence, "The purpose of an IM is to model managed
Andrea> objects at a high conceptual level, which is easy to
Andrea> understand for the human designer or human manager.  ..."
Andrea> (Section 2) needs some clarification.  "High conceptual level"
Andrea> implies broad concepts, but IMs can define detailed data. I
Andrea> would say "The purpose of an IM is to model managed objects as
Andrea> abstractions, independent of specific implementations or
Andrea> protocols used to transport the data.  The degree of
Andrea> specificity (or detail) of the IM is dependent on the modeling
Andrea> needs of its designers."

I would like to keep "conceptual level" in that sentence because we
use this word later on in several places. What about this:

     The purpose of an IM is to model managed objects at a conceptual
     level as abstractions, independent of specific implementations or
     protocols used to transport the data.  The degree of specificity
     (or detail) of the IM is dependent on the modeling needs of its
     designers.

Andrea> 4. I do not understand the importance of "managers" in the
Andrea> following sentence, "An IM is primarily useful for designers
Andrea> and managers" (Section 3). I would expand the sentence and use
Andrea> the "guide" word from John Strassner's mail - "An IM is
Andrea> primarily useful for designers to describe the managed
Andrea> environment, for managers to understand the modeled objects,
Andrea> and for implementors as a guide to the functionality that must
Andrea> be described and coded in their DMs."

fine with me

Andrea> 5. The following sentence is not grammatically correct and
Andrea> should be reworded.  "SMIng also supports some object-oriented
Andrea> principles and provides an extension mechanism which allows to
Andrea> add more features such as support for methods when the
Andrea> protocols support them without breaking SMIng
Andrea> implementations." (Section 4) My suggestion would be: "SMIng
Andrea> also supports some object-oriented principles and provides
Andrea> extension mechanisms allowing the addition of new features
Andrea> (such as support for methods).  New features can then be used
Andrea> when supported by underlying protocols, without breaking SMIng
Andrea> implementations."

fixed

Andrea> 6. The sentence, "Instead, the SMIng working group currently
Andrea> focusses resources on developing a third version of the SMI
Andrea> (SMIv3) which ..."  (Section 4) should be simplified as
Andrea> "Instead the SMIng working group is developing a third version
Andrea> of the SMI (SMIv3) which ..."

fixed

Andrea> 7. Could you have reference [3] include the URL
Andrea> http://www.dmtf.org/standards/published_documents.php?  This
Andrea> is where DSP 0004 is permanently located.

Not sure (a) how I do that with xml2rfc and (b) if I like to go down
the path of adding URLs to references at all (I am old fashioned).

/js

--
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 3 Sep 2002 22:17:51 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Sender: [email-masked]

>>>>> Andrea Westerinen writes:

Andrea> A couple of comments on the draft:

Andrea> 1. The sentence, "In particularly the terms "Information
Andrea> Model" (IM) and "Data Model" (DM) (Section 1) turned out to be
Andrea> controversial."  should read "In PARTICULAR ...."

fixed

Andrea> 2. The sentence, "... its outcome, which is a better
Andrea> understanding of the terms "Information Model" and "Data
Andrea> Model", as presented in this document." (Section 1) should
Andrea> read "... its outcome, ..., IS presented in this document."

fixed

Andrea> 3. The sentence, "The purpose of an IM is to model managed
Andrea> objects at a high conceptual level, which is easy to
Andrea> understand for the human designer or human manager.  ..."
Andrea> (Section 2) needs some clarification.  "High conceptual level"
Andrea> implies broad concepts, but IMs can define detailed data. I
Andrea> would say "The purpose of an IM is to model managed objects as
Andrea> abstractions, independent of specific implementations or
Andrea> protocols used to transport the data.  The degree of
Andrea> specificity (or detail) of the IM is dependent on the modeling
Andrea> needs of its designers."

I would like to keep "conceptual level" in that sentence because we
use this word later on in several places. What about this:

     The purpose of an IM is to model managed objects at a conceptual
     level as abstractions, independent of specific implementations or
     protocols used to transport the data.  The degree of specificity
     (or detail) of the IM is dependent on the modeling needs of its
     designers.

Andrea> 4. I do not understand the importance of "managers" in the
Andrea> following sentence, "An IM is primarily useful for designers
Andrea> and managers" (Section 3). I would expand the sentence and use
Andrea> the "guide" word from John Strassner's mail - "An IM is
Andrea> primarily useful for designers to describe the managed
Andrea> environment, for managers to understand the modeled objects,
Andrea> and for implementors as a guide to the functionality that must
Andrea> be described and coded in their DMs."

fine with me

Andrea> 5. The following sentence is not grammatically correct and
Andrea> should be reworded.  "SMIng also supports some object-oriented
Andrea> principles and provides an extension mechanism which allows to
Andrea> add more features such as support for methods when the
Andrea> protocols support them without breaking SMIng
Andrea> implementations." (Section 4) My suggestion would be: "SMIng
Andrea> also supports some object-oriented principles and provides
Andrea> extension mechanisms allowing the addition of new features
Andrea> (such as support for methods).  New features can then be used
Andrea> when supported by underlying protocols, without breaking SMIng
Andrea> implementations."

fixed

Andrea> 6. The sentence, "Instead, the SMIng working group currently
Andrea> focusses resources on developing a third version of the SMI
Andrea> (SMIv3) which ..."  (Section 4) should be simplified as
Andrea> "Instead the SMIng working group is developing a third version
Andrea> of the SMI (SMIv3) which ..."

fixed

Andrea> 7. Could you have reference [3] include the URL
Andrea> http://www.dmtf.org/standards/published_documents.php?  This
Andrea> is where DSP 0004 is permanently located.

Not sure (a) how I do that with xml2rfc and (b) if I like to go down
the path of adding URLs to references at all (I am old fashioned).

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

From: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, "Network Management Research Group" <[email-masked]>
Subject: RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Date: Tue, 3 Sep 2002 12:57:49 -0700
Importance: Normal
Sender: [email-masked]

A couple of comments on the draft:

1. The sentence, "In particularly the terms "Information Model" (IM)
   and "Data Model" (DM) (Section 1) turned out to be controversial."
   should read "In PARTICULAR ...."

2. The sentence, "... its outcome,
   which is a better understanding of the terms "Information Model" and
   "Data Model", as presented in this document." (Section 1) should read
   "... its outcome, ..., IS presented in this document."

3. The sentence, "The purpose of an IM is to model managed objects at a
   high conceptual level, which is easy to understand for the human
   designer or human manager.   ..." (Section 2) needs some clarification.
   "High conceptual level" implies broad concepts, but IMs can define
   detailed data. I would say "The purpose of an IM is to model managed
   objects as abstractions, independent of specific implementations or
   protocols used to transport the data.  The degree of specificity
   (or detail) of the IM is dependent on the modeling needs of its
   designers."

4. I do not understand the importance of "managers" in the following
   sentence, "An IM is primarily useful for designers and managers"
   (Section 3). I would expand the sentence and use the "guide" word
   from John Strassner's mail - "An IM is primarily useful for designers to
   describe the managed environment, for managers to understand the
   modeled objects, and for implementors as a guide to the functionality
   that must be described and coded in their DMs."

5. The following sentence is not grammatically correct and should be
   reworded.  "SMIng also supports some object-oriented principles and
   provides an extension mechanism which allows to add more features
   such as support for methods when the protocols support them without
   breaking SMIng implementations." (Section 4) My suggestion would be:
   "SMIng also supports some object-oriented principles and provides
   extension mechanisms allowing the addition of new features (such as
   support for methods).  New features can then be used when supported
   by underlying protocols, without breaking SMIng implementations."

6. The sentence, "Instead, the SMIng working group currently focusses
   resources on developing a third version of the SMI (SMIv3) which ..."
   (Section 4) should be simplified as "Instead the SMIng working group
   is developing a third version of the SMI (SMIv3) which ..."

7. Could you have reference [3] include the URL
   http://www.dmtf.org/standards/published_documents.php?  This is where
   DSP 0004 is permanently located.

Thanks.
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Schoenwaelder
Sent: Monday, September 02, 2002 1:59 AM
To: Network Management Research Group
Subject: [nmrg] draft-irtf-nmrg-im-dm-00.txt status

I have made the changes discussed recently on this list. The result is
now available at <http://www.ibr.cs.tu-bs.de/~schoenw/im-dm.txt>.

The basic changes are:

1) Added the following sentence to section 3:

   Organizations may use the contents of an information model to
   delimit the functionality that can be included in a data model.

2) Split the references section into informative and normative as
   proposed recently on this list.

If I do not hear any strong objections by Wednesday evening (European
time), I will post this document as an ID and ask the RFC editor to
publish it as Informational RFC.

/js

--
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>
--
!! 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 <[email-masked]>
!! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Date: Mon, 2 Sep 2002 13:24:38 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> Juergen, Aiko,

JP> I think we should delay the publication of this document by one
JP> month. As it is, I do not have the feeling that it is mature
JP> enough to become an RFC.

JP> First, it still requires some polishing. For instance, there is a
JP> typo in the first paragraph of Section 1: "suites" should read
JP> "suits". Another example is the last sentence of Section 1,
JP> paragraph 3: it is grammatically incorrect. A number of other
JP> minor changes are still required, in my view.

Both fixed now. If you found more editorial problems, please send them
to the list quickly.

JP> Second, I do not think that there is enough consensus within the
JP> group to publish this document as it is. For instance, I think
JP> that the points raised by John Strassner should be discussed
JP> further. We may not all agree, but we need more consensus.

The document does not use "constrain" so I think we are fine.

JP> Third, our thoughts have evolved since the December 2000
JP> meeting. In my opinion, this I-D presents more than the sole
JP> outcome of this workshop. I thus disagree with the last sentence
JP> of Section 1, paragraph 3. This workshop triggered a distributed
JP> research effort that led to this I-D, an IEEE ComMag paper still
JP> under review, my DBTel 2001 paper, etc.

It is my understanding that this document indeed aims to describe what
happened at the workshop and in my view actually does describe what
happened at the workshop. It was not the goal to describe any research
work that was triggered by the workshop.

JP> Fourth, I need more time to work on this I-D. Its first public
JP> release was June 28, so we have had only two months to review and
JP> discuss it so far.  This is too short for me, I was too busy
JP> during this summer to thoroughly review it. I may not be the only
JP> NMRG member in this situation.

We just need to move on. The workshop was in December 2000 and it is
more than time that we get this out. Furthermore, the whole document
including all the boilerplate stuff is just 9 pages - so reading it
should not take months.

JP> Is there a particular reason for quickly publishing this I-D as an
JP> RFC, or could we still work on it and try to improve it? Could the
JP> target date for sending it to the RFC Editor be set to October 1?
JP> Information modeling is an important topic. We should not rush the
JP> publication of this RFC before it is mature.

I am fine to give you another week to list (preferably with concrete
wording changes) your issues. But note: the scope of this document is
the a clarification of the terms. The scope is not an in depth
discussion about how to implement information modeling right. If you
want to have a paragraph added to point to more recent research work
in this area, that is fine with me (if Aiko also agrees).

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Mon, 02 Sep 2002 12:49:09 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Sender: [email-masked]

Juergen, Aiko,

I think we should delay the publication of this document by one month. As 
it is, I do not have the feeling that it is mature enough to become an RFC.

First, it still requires some polishing. For instance, there is a typo in 
the first paragraph of Section 1: "suites" should read "suits". Another 
example is the last sentence of Section 1, paragraph 3: it is grammatically 
incorrect. A number of other minor changes are still required, in my view.

Second, I do not think that there is enough consensus within the group to 
publish this document as it is. For instance, I think that the points 
raised by John Strassner should be discussed further. We may not all agree, 
but we need more consensus.

Third, our thoughts have evolved since the December 2000 meeting. In my 
opinion, this I-D presents more than the sole outcome of this workshop. I 
thus disagree with the last sentence of Section 1, paragraph 3. This 
workshop triggered a distributed research effort that led to this I-D, an 
IEEE ComMag paper still under review, my DBTel 2001 paper, etc.

Fourth, I need more time to work on this I-D. Its first public release was 
June 28, so we have had only two months to review and discuss it so far. 
This is too short for me, I was too busy during this summer to thoroughly 
review it. I may not be the only NMRG member in this situation.

Is there a particular reason for quickly publishing this I-D as an RFC, or 
could we still work on it and try to improve it? Could the target date for 
sending it to the RFC Editor be set to October 1? Information modeling is 
an important topic. We should not rush the publication of this RFC before 
it is mature.

JP

Juergen Schoenwaelder wrote:
> I have made the changes discussed recently on this list. The result is
> now available at <http://www.ibr.cs.tu-bs.de/~schoenw/im-dm.txt>.
> 
> The basic changes are:
> 
> 1) Added the following sentence to section 3:
> 
>    Organizations may use the contents of an information model to
>    delimit the functionality that can be included in a data model.
> 
> 2) Split the references section into informative and normative as
>    proposed recently on this list.
> 
> If I do not hear any strong objections by Wednesday evening (European
> time), I will post this document as an ID and ask the RFC editor to
> publish it as Informational RFC.
> 
> /js

Date: Mon, 2 Sep 2002 10:58:41 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Sender: [email-masked]

I have made the changes discussed recently on this list. The result is
now available at <http://www.ibr.cs.tu-bs.de/~schoenw/im-dm.txt>.

The basic changes are:

1) Added the following sentence to section 3:

   Organizations may use the contents of an information model to
   delimit the functionality that can be included in a data model.

2) Split the references section into informative and normative as
   proposed recently on this list.

If I do not hear any strong objections by Wednesday evening (European
time), I will post this document as an ID and ask the RFC editor to
publish it as Informational RFC.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

From: John Strassner <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status
Date: Sat, 31 Aug 2002 17:13:33 -0600
Sender: [email-masked]

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_01C25144.06CD77B0
Content-Type: text/plain

Hi Juergen,

No, not really. I also am somewhat uncomfortable with the use of the word
"constrain". I prefer the word "guide". There's nothing in an information
model that "constrains" (as in "restricts") what can or cannot be
implemented in a particular data model. Indeed, the information model
shouldn't have a clue about the capabilities of different data models, or
else it will be unduly influenced by them.

In thinking about this further, I suppose that the use of "constrain" was to
try and emphasize the practice of not adding new functionality in the data
model that was not represented in the information model. I agree that this
is an admirable goal, but would feel more comfortable in it being stated as
a goal, not as a property of the information model.

I hope this helps.

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: [email-masked] 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, August 30, 2002 2:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt status

>>>>> John Strassner writes:

John> I don't think that an IM constrains a DM. An IM guides the 
John> development of a DM. An obvious counter-example is if an IM 
John> specifies a composition class, and the target DM is a directory. 
John> Directories will implement this using DIT containment, which is a 
John> server directive, not by literally following the IM and building 
John> an entry to represent the composition class.

[...]

So are you trying to say that you agree with the following wordings?

> I suggest "organizations may use the scope of an IM to constrain the 
> scope of a DM" or "organizations may use the contents of an 
> information model to delimit the functionality that can be included in 
> a data model."

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

------_=_NextPart_001_01C25144.06CD77B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [nmrg] draft-irtf-nmrg-im-dm-00.txt status</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Juergen,</FONT>
</P>

<P><FONT SIZE=3D2>No, not really. I also am somewhat uncomfortable with =
the use of the word &quot;constrain&quot;. I prefer the word =
&quot;guide&quot;. There's nothing in an information model that =
&quot;constrains&quot; (as in &quot;restricts&quot;) what can or cannot =
be implemented in a particular data model. Indeed, the information =
model shouldn't have a clue about the capabilities of different data =
models, or else it will be unduly influenced by them.</FONT></P>

<P><FONT SIZE=3D2>In thinking about this further, I suppose that the =
use of &quot;constrain&quot; was to try and emphasize the practice of =
not adding new functionality in the data model that was not represented =
in the information model. I agree that this is an admirable goal, but =
would feel more comfortable in it being stated as a goal, not as a =
property of the information model.</FONT></P>

<P><FONT SIZE=3D2>I hope this helps.</FONT>
</P>

<P><FONT SIZE=3D2>regards,</FONT>
<BR><FONT SIZE=3D2>John</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>John Strassner</FONT>
<BR><FONT SIZE=3D2>Chief Strategy Officer</FONT>
<BR><FONT SIZE=3D2>Intelliden Corporation</FONT>
<BR><FONT SIZE=3D2>90 South Cascade Avenue</FONT>
<BR><FONT SIZE=3D2>Colorado Springs, CO&nbsp; 80903&nbsp; USA</FONT>
<BR><FONT SIZE=3D2>phone: +1.719.785.0648</FONT>
<BR><FONT SIZE=3D2>&nbsp; FAX: +1.719.785.0644</FONT>
<BR><FONT SIZE=3D2>email: [email-masked] </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Juergen Schoenwaelder [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, August 30, 2002 2:52 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [nmrg] draft-irtf-nmrg-im-dm-00.txt =
status</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&gt; John Strassner writes:</FONT>
</P>

<P><FONT SIZE=3D2>John&gt; I don't think that an IM constrains a DM. An =
IM guides the </FONT>
<BR><FONT SIZE=3D2>John&gt; development of a DM. An obvious =
counter-example is if an IM </FONT>
<BR><FONT SIZE=3D2>John&gt; specifies a composition class, and the =
target DM is a directory. </FONT>
<BR><FONT SIZE=3D2>John&gt; Directories will implement this using DIT =
containment, which is a </FONT>
<BR><FONT SIZE=3D2>John&gt; server directive, not by literally =
following the IM and building </FONT>
<BR><FONT SIZE=3D2>John&gt; an entry to represent the composition =
class.</FONT>
</P>

<P><FONT SIZE=3D2>[...]</FONT>
</P>

<P><FONT SIZE=3D2>So are you trying to say that you agree with the =
following wordings?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I suggest &quot;organizations may use the scope =
of an IM to constrain the </FONT>
<BR><FONT SIZE=3D2>&gt; scope of a DM&quot; or &quot;organizations may =
use the contents of an </FONT>
<BR><FONT SIZE=3D2>&gt; information model to delimit the functionality =
that can be included in </FONT>
<BR><FONT SIZE=3D2>&gt; a data model.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>/js</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Juergen Schoenwaelder&nbsp;&nbsp;&nbsp; &lt;<A =
HREF=3D"http://www.informatik.uni-osnabrueck.de/schoenw/" =
TARGET=3D"_blank">http://www.informatik.uni-osnabrueck.de/schoenw/</A>&g=
t;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C25144.06CD77B0--