Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id TAA10913 for nmrg-outgoing; Wed, 27 Sep 2000 19:46:29 +0200 (MET DST) Received: from baxter.tollbridgetech.com (host120-106.tollbridgetech.com [205.178.120.106] (may be forged)) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id TAA10905; Wed, 27 Sep 2000 19:46:25 +0200 (MET DST) Received: from DPERKINS-NB1 ([10.2.254.25]) by baxter.tollbridgetech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R6BLJ2QP; Wed, 27 Sep 2000 10:41:19 -0700 Message-Id: <4.1.20000927102600.00a2b170@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 27 Sep 2000 10:44:17 -0700 To: Harald Alvestrand , Frank Strauss , nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Subject: Re: [nmrg] First thoughts on new SMIng grammar In-Reply-To: <4.3.2.7.2.20000927113903.0604a130@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 2226 Lines: 59 HI, Lets first talk about something that we DO NOT want. I believe that one of the major failings of CMIP was that it allowed (and encouraged) MIB designers to create new data types. This had the really bad cost of requiring agents and management applications to be "recompiled" to support a new data type. For example, if you had a MIB browser and you got a new MIB module with new data types, you would have to recompile to support the data type. This was because the "on the wire" encodings were extended. This was also needed to support filters! Also, I've seen CMIP MIB definitions that had choice inside choice inside choice. It looked like the MIB designer tried to support everything in one definition. (From the examples I saw, this was the worst in action and notification data.) Trying to understand definitions with complex choices is really difficult, and I don't remember a language that does a good job with this. Please note that I do wish that we had more "complex" types, and a complete set of base types. For example, I wish there was the type "sequence" (not sequence of). However, I believe that it would abused if it was not documented properly. The name-space issue is important and should be solved. However with it comes the "version control" issue. Just a few responses... Regards, /david t. perkins At 11:44 AM 09/27/2000 +0200, Harald Alvestrand wrote: >thoughts, please ignore if already trashed to death: > >- do we want complex types? >we could formalize the link between address type and address (for instance) >by declaring a construct group, which would instantiate to 2 MIB variables. >probably make a default mapping to .1 and .2 with an override >capability to be able to represent older MIBs > >- do we want polymorphic types, where types inherited from the same base >type can have different representations? > >- do we want abstract types, which do not specify their format? > >- do we want to muck around with namespace? The excessive number of "naming >conventions" in old SMI indicates to me either a lack of more powerful >notational tools or a lack of proper namespace management. > >sniping from the sidelines, just passing by..... > > Harald > > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA22657 for nmrg-outgoing; Wed, 27 Sep 2000 15:10:31 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA22627; Wed, 27 Sep 2000 15:10:16 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA09688; Wed, 27 Sep 2000 15:10:16 +0200 Date: Wed, 27 Sep 2000 15:10:16 +0200 Message-Id: <200009271310.PAA09688@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Harald@Alvestrand.no CC: strauss@ibr.cs.tu-bs.de, nmrg@ibr.cs.tu-bs.de In-reply-to: <4.3.2.7.2.20000927113903.0604a130@127.0.0.1> (message from Harald Alvestrand on Wed, 27 Sep 2000 11:44:00 +0200) Subject: Re: [nmrg] First thoughts on new SMIng grammar References: <4.3.2.7.2.20000927113903.0604a130@127.0.0.1> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 2674 Lines: 59 >>>>> Harald Alvestrand writes: Harald> thoughts, please ignore if already trashed to death: Harald> - do we want complex types? we could formalize the link Harald> between address type and address (for instance) by declaring a Harald> construct group, which would instantiate to 2 MIB variables. Harald> probably make a default mapping to .1 and .2 with an Harald> override capability to be able to represent older MIBs This is more or less what we have in mind. See the class InetEndpoint in the example Frank posted to this list. This groups an InetAddressType and an InetAddress together. Note that the OID assignement is a matter of the mapping of the InetEndpoint class into an SNMP table. Harald> - do we want polymorphic types, where types inherited from the Harald> same base type can have different representations? Harald> - do we want abstract types, which do not specify their Harald> format? In the example, we have derived InetAddressIPv4 and InetAddressIPv6 from InetAddress (which is again derived from OctetString). So InetAddress more or less acts as a base type for IPv4 and IPv6 addresses. So an InetAddress is abstract in the sense that it is silent about a version specific address format. And it is polymorphic in the sense that derived types can define different representations. Harald> - do we want to muck around with namespace? The excessive Harald> number of "naming conventions" in old SMI indicates to me Harald> either a lack of more powerful notational tools or a lack of Harald> proper namespace management. there has always been the policy that identifiers should be unique so that you can just refer to a short name and everybody knows what is meant. Hence we have all the prefixes to make descriptors globally unique. Furthermore, many names are used carry additional semantics (e.g. where a points to) because there are no better ways to express these things. Finally, there is the rule that everything is implicitely exported - which implies that you choose long names just to avoid any name clashes. In other words: I think that we need not fundamentally change the namespaces concept. But we need to re-consider some language features such as "everything is implicitly exported" in order to get rid of some of the reasons that have lead to the excessive number of "naming conventions" in the past. Thanks for your feedback. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA12477 for nmrg-outgoing; Wed, 27 Sep 2000 12:22:55 +0200 (MET DST) Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA12469; Wed, 27 Sep 2000 12:22:47 +0200 (MET DST) Received: from HALVESTR-8KCDT.maxware.no (ams-vpdn-client-342.cisco.com [144.254.47.90]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id MAA15936; Wed, 27 Sep 2000 12:22:40 +0200 Message-Id: <4.3.2.7.2.20000927113903.0604a130@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Sep 2000 11:44:00 +0200 To: Frank Strauss , nmrg@ibr.cs.tu-bs.de From: Harald Alvestrand Subject: Re: [nmrg] First thoughts on new SMIng grammar In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 815 Lines: 22 thoughts, please ignore if already trashed to death: - do we want complex types? we could formalize the link between address type and address (for instance) by declaring a construct group, which would instantiate to 2 MIB variables. probably make a default mapping to .1 and .2 with an override capability to be able to represent older MIBs - do we want polymorphic types, where types inherited from the same base type can have different representations? - do we want abstract types, which do not specify their format? - do we want to muck around with namespace? The excessive number of "naming conventions" in old SMI indicates to me either a lack of more powerful notational tools or a lack of proper namespace management. sniping from the sidelines, just passing by..... Harald Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA26730 for nmrg-outgoing; Wed, 20 Sep 2000 18:25:34 +0200 (MET DST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA26713; Wed, 20 Sep 2000 18:25:31 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA16610; Wed, 20 Sep 2000 18:25:30 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] First thoughts on new SMIng grammar Date: 20 Sep 2000 18:25:30 +0200 Message-ID: User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 7915 Lines: 266 Hi! As expressed on the last meeting, I played with some examples of MIB/PIB fragments to get a first feeling on how a new grammar could look like. I think that it's not yet reasonable to define a formal ABNF grammar at this point in time. Today, Juergen and I discussed some first details and below is what we have now as a first proposal on type definitions, unions, class definitions, class inheritance, containment, and mappings to target architectures. Don't expect too much. There are lots of `...' and concepts not yet handled (structured types, annotations, compliance statements, ...) We think that the conversion of more real world MIBs and PIBs could help significantly. David, maybe you find time to pick a `well known' PIB and try to write its contents down in the grammar that you have mind after reading the examples below. Juergen and I will do the same for a well known MIB, presumably the IF-MIB. I'll be on vacation until the end of this month. I hope this can help to make progress during the next days. Frank typedef InetPort { type Unsigned32(0..65535); description "Represents an Inet port number."; }; typedef InetProtocol { type Unsigned32(0..255); description "Represents an Inet protocol number."; }; typedef InetAddress { type OctetString; description "Represents an arbitrary InetAddress."; }; typedef InetPrefixLen { type Unsigned32; description "..."; }; typedef InetAddressIPv4 { type InetAddress (4); format "1d.1d.1d.1d"; description "Represents an IPv4 network address: octets contents encoding 1-4 IP address network-byte order If there is a corresponding InetAddress.type attribute its value is ipv4(1)."; }; typedef InetPrefixLenIPv4 { type InetPrefixLen(0..32); description "..."; }; typedef InetAddressIPv6 { type InetAddress (16 | 20); format "2x:2x:2x:2x:2x:2x:2x:2x%4d"; description "Represents an IPv6 network address: octets contents encoding 1-16 IPv6 address network-byte order 17-20 scope identifier network-byte order If there is a corresponding InetAddress.type attribute its value is ipv6(2). The scope identifier (bytes 17-20) MUST NOT be present for global IPv6 addresses. For non-global IPv6 addresses (e.g. link-local or site-local addresses), the scope identifier MUST always be present. It contains a link identifier for link-local and a site identifier for site-local IPv6 addresses. The scope identifier MUST disambiguate identical address values. For link-local addresses, the scope identifier will typically be the interface index (ifIndex as defined in the IF-MIB, RFC 2233) of the interface on which the address is configured. The scope identifier may contain the special value 0 which refers to the default scope. The default scope may be used in cases where the valid scope identifier is not known (e.g., a management application needs to write a site-local InetAddressIPv6 address without knowing the site identifier value). The default scope SHOULD NOT be used as an easy way out in cases where the scope identifier for a non-global IPv6 is known."; }; typedef InetPrefixLenIPv6 { type InetPrefixLen(0..128); description "..."; }; typedef InetAddressDNS { type InetAddress (1..255); format "255a"; description "Represents a DNS domain name. The name SHOULD be fully qualified whenever possible. If there is a corresponding InetAddress.type attribute its value is dns(16). The descriptions of objects of this type must fully describe how (and when) such names are to be resolved to IP addresses."; }; class InetEndpoint { // conflicting namespaces of classes/types ? attribute type { type Enumeration(unknown(0), ipv4(1), ipv6(2), dns(16)); access readwrite; description "A value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding address object is a zero-length string. It may also be used to indicate an IP address which is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 type. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 type. dns(16) A DNS domain name as defined by the InetAddressDNS type. The type SHOULD NOT be subtyped in object type definitions to support future extensions. It MAY be subtyped in compliance statements in order to require only a subset of these address types for a compliant implementation."; }; attribute InetAddress address { typemap type { map ipv4 InetAddressIPv4, map ipv6 InetAddressIPv6, map dns InetAddressDNS }; access readwrite; description "Denotes a generic Internet address. An address value is always interpreted within the context of the type value. The type attribute defines the context."; }; }; class Subnet { attribute InetEndpoint inetAddress { // class InetEndpoint; // keyword `class' or `type'? description "..."; }; attribute InetPrefixLen prefixLen { // type Unsigned32; typemap inetAddress.type { map ipv4 InetPrefixLenIPv4; map ipv6 InetPrefixLenIPv6; } access readwrite; description "..."; }; }; class PortRange { attribute InetPort start { access readwrite; description "..."; }; attribute InetPort end { access readwrite; description "..."; }; }; class BaseFilter { attribute DisplayString name { access readwrite; description "..."; }; attribute Counter64 byteCount { access readonly; description "..."; }; attribute Counter64 packetCount { access readonly; description "..."; }; }; class FiveTupleFilter : BaseFilter { attribute SubNet srcSubNet { description "..."; // description optional?! }; attribute SubNet dstSubNet { description "..."; }; attribute PortRange srcPortRange { description "..."; }; attribute PortRange dstPortRange { description "..."; }; attribute InetProtocol protocol { access readwrite; description "..."; }; }; // target architecture specific mappings snmp filterMib { oid mib-2.xxx; table filterTable { oid filterMib.42; index (filterName); implements FiveTupleFilter { column filterName name; // implicit oid: foo.42.1.1 column filterBytes byteCount; column filterPackets packetCount; column filterSrcType srcSubNet.inetAddress.type; column filterSrcAddress srcSubNet.inetAddress.address; column filterSrcPrefixLen srcSubNet.prefixlen; column filterDstType dstSubNet.inetAddress.type; column filterDstAddress dstSubNet.inetAddress.address; column filterDstPrefixLen dstSubNet.prefixlen; column filterSrcPortStart srcPortRange.start; column filterSrcPortEnd srcPortRange.end; column filterDstPortStart dstPortRange.start; column filterDstPortEnd dstPortRange.end; column filterProtocol protocol; }; description "..."; }; scalars filterStats { ... }; }; cops filterPib { oid xxx.yyy; table filterTable { ... }; }; diameter ... Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA26433 for nmrg-outgoing; Wed, 20 Sep 2000 18:21:40 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id SAA26425; Wed, 20 Sep 2000 18:21:39 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA12305; Wed, 20 Sep 2000 18:21:39 +0200 Date: Wed, 20 Sep 2000 18:21:39 +0200 Message-Id: <200009201621.SAA12305@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] new mailing list members Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 766 Lines: 19 I have added Keith McCloghrie and David Durham to the NMRG list so that we can use this mailing list to work on some more SMIng details. Frank has made some progress on the syntactic aspects. We also found a number of new issues in the details - as expected. I am currently researching work on object-relational database systems and more specifically ODMG . This seems very closely related and we may want to borrow ideas/inspirations from that area. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA28289 for nmrg-outgoing; Tue, 19 Sep 2000 17:36:57 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA28280; Tue, 19 Sep 2000 17:36:54 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA13427; Tue, 19 Sep 2000 17:36:54 +0200 Date: Tue, 19 Sep 2000 17:36:54 +0200 Message-Id: <200009191536.RAA13427@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] minutes from the 7th NMRG meeting Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 21532 Lines: 552 Below are the minutes from the 7th NMRG meeting in Kleinheubach. /js The 7th NMRG meeting was held in Schloss Kleinheubach from 6-8 September 2000. The participants were (in alphabetic order): HD Heiko Dassow (T-Nova) DD David Durham (Intel) KM Keith McCloghrie (Cisco) JS Juergen Schoenwaelder (TU Braunschweig) FS Frank Strauss (TU Braunschweig) BW Bert Wijnen (Lucent) *arrived later* The local host of the meeting was T-Nova, the research and development devision of Deutsche Telekom. T-Nova provided excellent meeting facilities and the overall organization was of high quality. In fact, T-Nova set a new milestone as a local host which will be hard to top. The following minutes summarize the intensive discussions during the 7th NMRG meeting. The minutes do not always strictly follow the chronological order to keep the topics organized. The minutes were compiled by JS from notes taken by JS and DD. 0. Summary The meeting started with an attempt to identify the feature differences between SPPI, SMIng and the current SMIv2. Afterwards, the participants collected a list of new features that could be added to a future SMI which resulted in a kind of a wish-list. The rest of the meeting was spent discussing each feature in detail in order to understand whether it is feasible and useful to support it in a future SMIng revision. Some time was spent at the end of the meeting to discuss how to make progress on incorporating the accepted new features in the next SMIng revision and to assign tasks to volunteers. 1. SPPI and SMIng Differences from SMIv2 New features in the SPPI: + EXTENDS keyword for sparse table augmentations + UNIQUENESS clause to identify set of columns that uniquely identify a row + PIB-REFERENCES clause to type references to other tables + SUBJECT-CATEGORIES to identify sets of related PIB modules + PIB-INDEX clause to identify the COPS instance identification + Unsigned64 and Integer64 base types + PIB-ACCESS instead of MAX-ACCESS clauses + PIB-MIN-ACCESS instead of MIN-ACCESS clauses + INSTALL-ERRORS clause to define specific error codes for row creation + New TCs for instance identification and references ("pointers") + PIB-TAG clause for identifying a tag target column with tag references - no scalars - no Counter32, Counter64, Gauge32, Opaque - no object access clauses - no notifications - no agent capabilities (left for further study) New features in the SMIng: + all table existence relationships (augments, expands, extends, reorders) + Unsigned64 and Integer64 base types + Float32, Float64 and Float128 base types based on IEEE floating point types + Type system allows to derive types from existing types + single group statement replaces OBJECT-GROUP and NOTIFICATION-GROUP macros + create statement instead of read-create access mode + new syntax based on a small set of core syntax rules + language extensibility mechanism + annotation mechanism + constraints on statement ordering to reduce the number of forward references to the required minimum + units/format/default statements on type and column definitions + implied status current if status statement is absent + removes redundant SEQUENCE statements for table row definitions + redefines some previous base types (e.g. Counter32) as derived types + deprecates IpAddress (now a derived type) - no agent capabilities (left as an extension) A quick discussion revealed that the current create statement in SMIng may be problematic as there is currently no way to lower the create requirement in a compliance statement. Another issue raised was to require from a MIB compiler the (perhaps selected) understanding of extensions. Comments were made to make the SMIng syntax even less verbose. Some attendees expressed that they dislike the fact that SMIng has no equivalent to the SEQUENCE definition since they help human readers to gain an overview of a table definition. 2. Feature Wishlist o structured types o discriminated unions o arrays o nesting of structured types o required support of language extensions o handling of possible annotation conflicts o templates for reoccurring definitions (RMON example) o implied OID assignments o objects instead of tables/rows o support for explicit inheritance o multiple inheritance o constraints on possible combinations of values etc. o instance identification for multiple protocols that use different naming schemes without enforcing a global naming system o explicit support for associations (cardinality, ...) o containment (which may imply that classes act as types) o logical groupings (similar to SPPI subject categories) o methods/operations o readjust compliance and capabilities definitions 3. Feature Discussion 3.1 Classes (aka templates) There seem to be many MIB tables which need similar columns. RMON2 control tables are one example. Another example is the typical RowStatus, StorageType, OwnerString triple being used in many tables. Templates may be a way to define such combinations once and to use them when needed. Note that templates itself must specify descriptors. Templates seem to be truly useful only if they are used with multiple attributes. A question was whether the same thing can be achieved in principal with complex types. The answer was that complex types provide atomic access while templates provide only attribute specific atomic access. An issue was raised whether templates make generic tables with table extensions (such as the ifTable) less likely to appear since it is too easy to just instantiate an ifTable template. This potential misuse may be addressed by proper education. Another question raised was how templates relate to the concept of sub-classing in an OO world. Later during the meeting, it was observed that templates are in fact classes and nested templates (classes) represent inheritance while table extensions are purely instance specific and not the same as inheritance. The following observations were made: - Table extensions are useful if you need a common place where instances exist. For example, it is very useful to have all interfaces listed in the ifTable and to provide extension tables for interface type specific details. On the other hand, it does not seem to be useful to have a common place where all RowStatus and StorageType objects are listed (since this would put severe constraints on the table indexing schemes). - Classes (templates) are useful if you do not want a common place where all instances exist, but you still want to introduce a common structure across many MIBs. This common structure makes MIB definitions more compact and provides valuable information to code generators that understand the semantics associated with certain classes. - Structured types (like DateAndTime) make sense if you never have to access the elements of the structured type separately. In other words, structured types means atomic access with an internal structure. DD provided the following example how classes (templates) may help to provide reusable OO definitions that are later mapped to a tabular repository structure for use with SNMP and COPS: class A { attribute a1 {...}; ... }; class B : A { attribute b1 {...}; ... }; table Y { implements B (a1, ..., b1, ...); extends table X; create (...); oid xxx.42; }; Note that the implements statement requires to list the attributes that are actually implemented. The order of the attribute list can be used to automatically assign OID values. Note well that class definitions can be imported and hence it is possible that class and table definitions evolve at different speeds. 3.2 Containment Containment of classes is another concept that seems to be very valuable. The first example used during the meeting was that of a Rectangle class which contains several Points to define the rectangle: class Point { attribute x { ... }; attribute y { ... }; ... }; class Rectangle { attribute Point A { ... }; attribute Point B { ... }; ... }; table YY { implements Rectangle (A.x, A.y, B.x, B.y); index (A.x, A.y, B.x, B.y); ... } Note that it is necessary to "flatten" the containment hierarchy when mapping the classes into a tabular structure, which means that we need to have a hierarchical naming scheme at least in the class layer. Another less abstract example was provided by DD which combines inheritance and containment: class Subnet { attribute inetAddress { ... }; attribute inetPrefix { ... }; }; class PortRange { attribute startPort { ... }; attribute endPort { ... }; }; class BaseFilter { attribute filterName { ... }; attribute byteCount { ... }; attribute packetCount { ... }; }; class FiveTupleFilter : BaseFilter { attribute Subnet srcSubNet { ... }; attribute Subnet dstSubNet { ... }; attribute PortRange srcPortRange { ... }; attribute PortRange dstPortRange { ... }; attribute protocol { ... }; }; table FilterTable { implements FiveTupleFilter ( filterName, byteCount, packetCount, srcSubNet.inetAddress, srcSubNet.inetPrefix, dstSubNet.inetAddress, dstSubNet.inetPrefix, srcPortRange.startPort, srcPortRange.endPort, dstPortRange.startPort, dstPortRange.endPort, protocol); index (filterName); ... }; 3.3 Types SMIng extends the SMIv2/SPPI type system by allowing new types to be derived from existing types. Other frequently suggested features are structured types, discriminated unions and arrays. It was recognized that whatever addition made to the SMIng language should honor the fact that compound types must be restricted in size and that compound types only make sense where atomic access to the data is required. In other words, containment should be used as much as possible if no atomic access is needed. Structured types are generally considered to be worthwhile to add. We already have structured types (such as DateAndTime) but we simply lack a good mechanism to define them in a machine readable way. MIB authors sometimes use DISPLAY-HINTS to fill this niche. The question was raised whether it is needed to support nesting of structured types. Disallowing nested structured types may help to put bounds on the complexity of compound types and to force people to use containment for real complex things. Another issue was the encoding of compound types. One way to encode compound types is to use ASN.1/BER rules. Another one would be to use a more lightweight set of encoding rules that encode fixed length numbers in network byte order, which is typically what existing structured types such as DateAndTime already use. An argument was made that a set of lightweight encoding rules is a better approach since these types are usually dealt with in application code where programmers are usually not aware of ASN.1/BER functions. This reflects a separation between application specific types (defined by the SMIng) and the core protocol data types. Discriminated unions are only needed in some special cases. However, in these cases (generic network addresses, distributed management MIBs), not having discriminated unions is rather painful. It seems to be worthwhile to support discriminated unions if it is possible to support them without major additions in complexity. There was agreement that arrays are not really needed and that they are hard to get right given the constraints imposed by the SNMP protocol. 3.4 Instance Identification SNMP and COPS-PR have different instance identification schemes. Other protocols that might use SMIng may introduce even more instance identification schemes. The SMIng specification should therefore separate instance identification from the set of reusable data definitions and provide instance identification specific mechanisms in the mappings to certain repository structures. 3.5 Methods The addition of general methods to the SMIng is controversial. Methods need to have well defined transactional semantics to be useful. The general use of methods may imply RPC-like procedures to be defined in the SMIng syntax. The primary target protocols SNMP and COPS-PR do not provide support for method invocations. So adding support for methods into SMIng at this point in time may turn out to be a hard problem to solve if this requires to also enhance protocols. However, it may as well be possible to implement RPC style method calls on top of a data model technology. JS pointed out that the SPPI install/remove access resembles constructor/destructor methods in OO systems (or create/delete operations in CMIP). Furthermore, SNMP MIBs lack a mechanism to define signatures for typical set operations. The fact that an SNMP set can carry varbinds in any obscure order adds significant complexity, raises implementation costs and handicaps interoperability. Being able to at least define signatures for typical set operations may be very valuable (although it may lead to a situation where people do not implement the full set semantics required by the SNMP specifications). It seems there are several ways to proceed: (i) Solve the method problem and constructors/destructors fall out as special cases. (ii) Solve the constructors/destructors case and leave generic methods for a future extension/revision (when the protocols are ready to support them). (iii) Solve the constructors/destructors case and provide some support (e.g. signatures for write operations) on top of a pure data definition model. (iv) Only provide protocol specific hooks so that the handling of methods and constructors/destructors is a pure protocol specific subject. It seems that (iv) is not a very desirable solution. Some more time was spent on constructors. It was noted that the SMI read-create access is really a combination of read-write for the particular column and create for the whole table/row. SMIng reflects this by introducing a create statement and removing the read-create access mode. It may be reasonable to extend the SMIng create statement and to map it into protocol specific mechanisms (COPS-PR install and SNMP RowStatus, perhaps with a well defines signature). The create statement should also define the create specific error conditions (which maps to SPPI's INSTALL-ERRORS clause). A similar mechanism may be needed for destructors (e.g. a delete statement) since a separate delete may be required in cases where instances are created by the managed device and it is only possible to delete them via management operations. 3.6 Relationships SMIng provides explicit keywords to identify all the table existence relationships. SPPI provides only the subset that makes sense for SPPI since COPS-PR does not support complex instance identifications. In addition to table existence relationships, there are a number of inter-table relationships usually represented by using some sort of pointers. SPPI introduces "typed" pointers in the form of references to table entries, where the PIB-REFERENCE clause defines the target table. This allows to express n:0..1 relationships. SPPI also introduces tag lists, where the PIB-TAG clause identifies the attribute being pointed to. This allows to express n:m relationships with the additional constraint that a tagged instance can only belong to exactly one tag list. The SNMP target MIB introduced a tagging mechanism for n:m relationships where a tagged instance can belong to multiple tag lists. In the subsequent discussion, issues were raised about the data type being used to build tag lists: strings versus numbers versus instance identifications (numbers in COPS-PR or OID fragments in SNMP). But this is basically a type issue which is independent of the data definition language - so it seems to be sufficient to have mechanisms in place which allow to properly constrain a pointing attribute to another table or columns within a table. It was not clear whether SMIng should establish additional constraints for pointer/tagging types to prevent people from using dynamic values such as ifOperStatus value up(1) as a tag to refer to all active interfaces. The conclusion was that SMIng should support mechanisms for constrained pointers to represent inter-table relationships and a set of associated type definitions that provide suitable semantics. 3.7 Constraints Constraints are a general mechanism to make specifications more precise. It was noted that the SMIng language (as well as SMIv2 and SPPI languages) already covers some constraints. However, it is possible to define even more constraints, such as constraints between attribute values or constraints on the existence of certain instances. It was also noted that trying to be too precise is sometimes causing headaches when the modeled technology evolves over time. The SMIv2 rules are actually often bended because definitions (e.g. size and range constraints) are sometimes too restrictive. Other proposals that are related to the concept of constraints try to express machine readable information which can be used to divide the states reported by a MIB module into good and bad states. A well-known constraint language is the object constraint language (OCL) which is part of the UML effort. During the discussion, a number of useful constraints were identified and it turned out to be unclear whether OCL can actually express them. The general conclusion was that constraints and a potential interface to an OCL like language may be useful but needs much more research. 3.8 Subject Categories There was a discussion on the concept of subject categories introduced by the SPPI. One of the questions raised was how subject categories relate to SNMP contexts. It turns out that SNMP contexts are not precisely defined. In particular, SNMP contexts do not seem to require that context spaces are separated. It seems to be possible that instances can exist in multiple contexts at the same time. Subject categories require "non-shared" instances. Looking at it from a COPS-PR perspective, subject categories are a mechanism to avoid figuring out dynamically at runtime which client-type to use. It also seems useful to assign subject categories statically (at compiler-time). Otherwise, if they were defined at "run-time", it would be very hard to write applications (e.g., PDP applications) because the application-writer wouldn't know in advance what selection of PIB modules would be accessible to his application. The subsequent discussion revealed that subject categories have a global name space and that assigning values and labels in PIB modules rather than a centralized place may turn out to cause serious problems. It is also unclear how the concept of subject categories will be used in practice and how many of them will be introduced. Establishing a central registry for subject categories may work fine for the IETF - but it may be problematic for vendor specific subject categories. The argument for assigning subject categories in PIB modules was that a compiler can easily detect the omission of an assignment. The discussion stopped without clear results. The SPPI folks probably want to think more about this concept and alternate assignment or identification mechanisms. IANA may be a way out to get at least non-conflicting number and label assignments. 4. Plan of Actions A discussion was held about the appropriate set of documents needed to define SMIng and the mappings to at least COPS-PR and SNMP. The proposed set of documents looks as follows: (1) SMIng Language Specification The specification of the language, including the ABNF for the syntax and a textual description of each language feature. (2) Common SMIng Definitions Common definitions of core data types and core classes. It seems useful to separate them from the language specification itself since some (e.g. RowStatus) may have lengthy descriptions. (3) Guidelines for Using SMIng Since SMIng offers many new features, there is a need to have a document which helps to educate authors of SMIng modules on how to use them. A set of good examples should go into this document. (4) SMIng Mapping to SNMP This document defines how SMIng data definitions can be used with the SNMP protocol. (5) SMIng Mapping to COPS-PR This document defines how SMIng data definitions can be used with the COPS-PR protocol. In addition, it may be desirable to define an XML SMIng exchange format, based on the DTD proposed in . Such a format can be optimized to machine readability while the SMIng syntax is optimized to be concise and human friendly. In order to make progress on SMIng, the following plan of actions was agreed upon: (a) JS writes up minutes and circulates them within a week (b) FS will take the lead to come up with an updated syntax for SMIng. A first proposal should appear within two weeks. (c) Once the syntax is available, DD will work out examples that can help to identify open issues and which will be a basis to better communicate core SMIng ideas. (d) KM will help JS and FS to write parts of the SMIng specification starting 4 weeks after the NMRG meeting (when he is back from vacation). (e) The ID cutoff for the December IETF is expected to be early November, depending on the rules for new IRTF documents. Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA02089 for nmrg-outgoing; Tue, 5 Sep 2000 14:31:48 +0200 (MET DST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA02084 for ; Tue, 5 Sep 2000 14:31:47 +0200 (MET DST) Received: from ica.epfl.ch (jpmf@tcomhp33.epfl.ch [128.178.151.24]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id OAA11151; Tue, 5 Sep 2000 14:31:45 +0200 (MET DST) Message-Id: <200009051231.OAA11151@icasun1.epfl.ch> X-Mailer: exmh version 2.1.1 10/15/1999 From: "J.P. Martin-Flatin" To: nmrg@ibr.cs.tu-bs.de Reply-To: "J.P. Martin-Flatin" Subject: Re: [nmrg] Common Information Structure In-reply-to: Your message of "Mon, 04 Sep 2000 23:53:36 METDST." <4.1.20000904235146.041469f0@mail.scruznet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Sep 2000 14:31:45 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 1216 Lines: 38 On Mon, 04 Sep 2000 23:53:36 -0700, "David T. Perkins" wrote: > > The document looks like an updated and "politically correct" version > of ASN.1. Why recycle an approach that has failed to live up to > its potential. Please find below an element of answer. JP >From: "Rutt, T E (Tom)" >Cc: adtf@omg.org, telecom@omg.org >Subject: RE: Common Information Structure document >Date: Tue, 29 Aug 2000 15:50:01 -0400 > >I was asked by the TMF to be a liaison to the OMG >on some of these data representation subjects. > >It turns out the TMF (TeleManagement Forum) is a firm >believer in UML for writing Specificaitons which are neutral >with respect to the underlying communication paradigm (e.g., >CORBA vs, CMIP, vs. XML etc). > >They have a need for data types to use in signatures for >UML operations which are not strictly tied to CORBA IDL. > >Thus they want a profile for UML , which defines generic >data types. Their example, in the liaison, is based on ASN.1. > >I think they would like the ADTF to look at the spec, and to >give the TMN guidance on how to form a profile for UML in this >subject area. > >Tom Rutt >Lucent Technologies >Tel: _1 732 949 7862 >email: terutt@lucent.com Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id JAA14715 for nmrg-outgoing; Tue, 5 Sep 2000 09:46:48 +0200 (MET DST) Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA14707; Tue, 5 Sep 2000 09:46:45 +0200 (MET DST) Received: from dperkins-nb1 ([24.15.219.251]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20000905074552.ZACK12879.femail4.sdc1.sfba.home.com@dperkins-nb1>; Tue, 5 Sep 2000 00:45:52 -0700 Message-Id: <4.1.20000905003333.0416fb50@mail.scruznet.com> Message-Id: <4.1.20000905003333.0416fb50@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 05 Sep 2000 00:35:33 -0700 To: Andy Bierman , Juergen Schoenwaelder From: "David T. Perkins" Subject: Re: [nmrg] Re: sming/sppi/smiv2 integration meeting details Cc: nmrg@ibr.cs.tu-bs.de, kzm@cisco.com, david.durham@intel.com, heiko.dassow@telekom.de In-Reply-To: <39AFD384.5AEEF03@cisco.com> References: <200008291921.MAA03368@ups.cisco.com> <200009011535.RAA05125@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 3153 Lines: 84 HI, I agree and support Andy's view, and unfortunately work commitments are keeping me away. Sorry. Regards, /david t. perkins At 09:04 AM 09/01/2000 -0700, Andy Bierman wrote: >Hi Juergen, > >> >> >>>>> Keith McCloghrie writes: >> >> Keith> So, >> >> Keith> option b) would be best, if you can resolve it quickly. >> Keith> option c) would be OK, if it's within driving distance. >> >> I have worked hard on option b) and I finally got very friendly help >> from T-Nova, the research organization of the Deutsche Telekom. They >> arranged a meeting room for us in some conference facilities which are >> located in a castle at the Main river about a hour drive from the >> Frankfurt airport. So here are the details: >> > >I am not going to be able to attend this meeting, but I appreciate >the invitation very much. As I emphatically stated at the NIM BOF, >I am strongly in favor of this work. I don't really agree with Keith >that it is independent of the NIM effort, but I do agree that >this work is long overdue, and a WG should be formed ASAP. >(Maybe that's what Keith meant :-) > >Maybe I could attend the next meeting, hopefully a WG meeting >at IETF #49 in San Diego. > >Andy > >> Tagungshotel Schloss Kleinheubach >> Schlosspark 1 >> 63924 Kleinheubach >> Germany >> >> Tel. +49 9371 401-0 >> Fax. +49 9371 401 107 >> email >> >> A very nice photo of the location can be found here: >> >> >> >> I have reserved a few rooms in the hotel so that we can actually stay >> over night in the castle. The rates are very reasonable - about 100 DM >> which amounts to roughly US $ 50 these days. Please contact the hotel >> and tell them when you will arrive and how long you are going to >> stay. >> >> If you experience any problems with the room reservation or you have >> any other urgent question, you can as well contact Uli Gruen >> from T-Nova who did a great job of organizing >> this nice meeting place for us. >> >> The web page has a map (under "Anreise") which explains how you reach >> Kleinheubach from Frankfurt airport by car. The meeting place is >> directly located at the street B 469. So from the airport, just take >> highway <3>. Leave at the exist "Stockstadt" and take the B 469 south >> until you reach Kleinheubach. The whole trip should not take more than >> an hour. >> >> You can find all this information including the map and the picture on >> >> in case the other URL does not work for you. >> >> Sorry that it took so long to get the meeting location finalized. If >> you are interested, then I can tell you the whole story over a beer or >> a glass of wine next week. >> >> /js >> >> -- >> Juergen Schoenwaelder Technical University Braunschweig >> Dept. Operating Systems & Computer Networks >> Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany >> Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id IAA11456 for nmrg-outgoing; Tue, 5 Sep 2000 08:51:47 +0200 (MET DST) Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id IAA11448 for ; Tue, 5 Sep 2000 08:51:43 +0200 (MET DST) Received: from dperkins-nb1 ([24.15.219.251]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20000905065050.XAMX12879.femail4.sdc1.sfba.home.com@dperkins-nb1>; Mon, 4 Sep 2000 23:50:50 -0700 Message-Id: <4.1.20000904235146.041469f0@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 04 Sep 2000 23:53:36 -0700 To: "J.P. Martin-Flatin" , nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Subject: Re: [nmrg] Common Information Structure In-Reply-To: <200008291409.QAA13285@icasun1.epfl.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 789 Lines: 28 HI, The document looks like an updated and "politically correct" version of ASN.1. Why recycle an approach that has failed to live up to its potential. Regards, /david t. perkins At 04:09 PM 08/29/2000 +0200, J.P. Martin-Flatin wrote: >>Date: Fri, 25 Aug 2000 17:35:14 -0400 >>To: adtf@omg.org, telecom@omg.org >>From: Andrew Watson >>Subject: Common Information Structure document >> >>Good Afternoon, >> >>We have received a document from Telemanagement Forum describing the Common >>Information Structure methodology they have developed for use in >>protocol-neutral modelling. It has been filed as document ad/00-08-13: >> >> http://cgi.omg.org/cgi-bin/doc?ad/00-08-13 >> >> Regards, >> >> Andrew > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id VAA21839 for nmrg-outgoing; Fri, 1 Sep 2000 21:24:20 +0200 (MET DST) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id VAA21831; Fri, 1 Sep 2000 21:24:18 +0200 (MET DST) Received: (from kzm@localhost) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA18825; Fri, 1 Sep 2000 12:23:46 -0700 (PDT) From: Keith McCloghrie Message-Id: <200009011923.MAA18825@ups.cisco.com> Subject: [nmrg] Re: sming/sppi/smiv2 integration meeting details To: david.durham@intel.com (Durham, David) Date: Fri, 1 Sep 2000 12:23:46 -0700 (PDT) Cc: schoenw@ibr.cs.tu-bs.de ('Juergen Schoenwaelder'), nmrg@ibr.cs.tu-bs.de, kzm@cisco.com, david.durham@intel.com (Durham David), abierman@cisco.com, heiko.dassow@telekom.de In-Reply-To: <10C8636AE359D4119118009027AE99873A38FA@FMSMSX34> from "Durham, David" at Sep 01, 2000 12:17:38 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 3043 Lines: 85 I'll be there too. Thanks for your hard work, Juergen. Keith. > Very good. I will be there. > Thanks Juergen, > -Dave > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > > Sent: Friday, September 01, 2000 8:36 AM > > To: nmrg@ibr.cs.tu-bs.de > > Cc: kzm@cisco.com; david.durham@intel.com; abierman@cisco.com; > > heiko.dassow@telekom.de > > Subject: Re: sming/sppi/smiv2 integration meeting details > > > > > > > > >>>>> Keith McCloghrie writes: > > > > Keith> So, > > > > Keith> option b) would be best, if you can resolve it quickly. > > Keith> option c) would be OK, if it's within driving distance. > > > > I have worked hard on option b) and I finally got very friendly help > > from T-Nova, the research organization of the Deutsche Telekom. They > > arranged a meeting room for us in some conference facilities which are > > located in a castle at the Main river about a hour drive from the > > Frankfurt airport. So here are the details: > > > > Tagungshotel Schloss Kleinheubach > > Schlosspark 1 > > 63924 Kleinheubach > > Germany > > > > Tel. +49 9371 401-0 > > Fax. +49 9371 401 107 > > email > > > > A very nice photo of the location can be found here: > > > > > > > > I have reserved a few rooms in the hotel so that we can actually stay > > over night in the castle. The rates are very reasonable - about 100 DM > > which amounts to roughly US $ 50 these days. Please contact the hotel > > and tell them when you will arrive and how long you are going to > > stay. > > > > If you experience any problems with the room reservation or you have > > any other urgent question, you can as well contact Uli Gruen > > from T-Nova who did a great job of organizing > > this nice meeting place for us. > > > > The web page has a map (under "Anreise") which explains how you reach > > Kleinheubach from Frankfurt airport by car. The meeting place is > > directly located at the street B 469. So from the airport, just take > > highway <3>. Leave at the exist "Stockstadt" and take the B 469 south > > until you reach Kleinheubach. The whole trip should not take more than > > an hour. > > > > You can find all this information including the map and the picture on > > > einheubach/> > > in case the other URL does not work for you. > > > > Sorry that it took so long to get the meeting location finalized. If > > you are interested, then I can tell you the whole story over a beer or > > a glass of wine next week. > > > > /js > > > > -- > > Juergen Schoenwaelder Technical University Braunschweig > > Dept. Operating Systems & Computer Networks > > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 > > Braunschweig, Germany > > Fax: +49 531 391 5936 > > > > > > > > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id VAA21645 for nmrg-outgoing; Fri, 1 Sep 2000 21:19:54 +0200 (MET DST) Received: from thalia.fm.intel.com ([132.233.247.11]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id VAA21637; Fri, 1 Sep 2000 21:19:52 +0200 (MET DST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id TAA02848; Fri, 1 Sep 2000 19:18:58 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 01 Sep 2000 19:17:58 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Sep 2000 12:17:39 -0700 Message-ID: <10C8636AE359D4119118009027AE99873A38FA@FMSMSX34> From: "Durham, David" To: "'Juergen Schoenwaelder'" , nmrg@ibr.cs.tu-bs.de Cc: kzm@cisco.com, "Durham, David" , abierman@cisco.com, heiko.dassow@telekom.de Subject: [nmrg] RE: sming/sppi/smiv2 integration meeting details Date: Fri, 1 Sep 2000 12:17:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 2815 Lines: 79 Very good. I will be there. Thanks Juergen, -Dave > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: Friday, September 01, 2000 8:36 AM > To: nmrg@ibr.cs.tu-bs.de > Cc: kzm@cisco.com; david.durham@intel.com; abierman@cisco.com; > heiko.dassow@telekom.de > Subject: Re: sming/sppi/smiv2 integration meeting details > > > > >>>>> Keith McCloghrie writes: > > Keith> So, > > Keith> option b) would be best, if you can resolve it quickly. > Keith> option c) would be OK, if it's within driving distance. > > I have worked hard on option b) and I finally got very friendly help > from T-Nova, the research organization of the Deutsche Telekom. They > arranged a meeting room for us in some conference facilities which are > located in a castle at the Main river about a hour drive from the > Frankfurt airport. So here are the details: > > Tagungshotel Schloss Kleinheubach > Schlosspark 1 > 63924 Kleinheubach > Germany > > Tel. +49 9371 401-0 > Fax. +49 9371 401 107 > email > > A very nice photo of the location can be found here: > > > > I have reserved a few rooms in the hotel so that we can actually stay > over night in the castle. The rates are very reasonable - about 100 DM > which amounts to roughly US $ 50 these days. Please contact the hotel > and tell them when you will arrive and how long you are going to > stay. > > If you experience any problems with the room reservation or you have > any other urgent question, you can as well contact Uli Gruen > from T-Nova who did a great job of organizing > this nice meeting place for us. > > The web page has a map (under "Anreise") which explains how you reach > Kleinheubach from Frankfurt airport by car. The meeting place is > directly located at the street B 469. So from the airport, just take > highway <3>. Leave at the exist "Stockstadt" and take the B 469 south > until you reach Kleinheubach. The whole trip should not take more than > an hour. > > You can find all this information including the map and the picture on > einheubach/> > in case the other URL does not work for you. > > Sorry that it took so long to get the meeting location finalized. If > you are interested, then I can tell you the whole story over a beer or > a glass of wine next week. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 > Braunschweig, Germany > Fax: +49 531 391 5936 > > > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA10401 for nmrg-outgoing; Fri, 1 Sep 2000 17:56:42 +0200 (MET DST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA10393; Fri, 1 Sep 2000 17:56:40 +0200 (MET DST) Received: from fedex.cisco.com (fedex.cisco.com [171.69.18.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA14738; Fri, 1 Sep 2000 08:56:24 -0700 (PDT) Received: from cisco.com ([10.19.253.250]) by fedex.cisco.com (Mirapoint) with ESMTP id ACO09464 (AUTH abierman); Fri, 1 Sep 2000 08:55:32 -0700 (PDT) Message-ID: <39AFD384.5AEEF03@cisco.com> Date: Fri, 01 Sep 2000 09:04:20 -0700 From: Andy Bierman Organization: Cisco Systems, Inc. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: nmrg@ibr.cs.tu-bs.de, kzm@cisco.com, david.durham@intel.com, heiko.dassow@telekom.de Subject: [nmrg] Re: sming/sppi/smiv2 integration meeting details References: <200008291921.MAA03368@ups.cisco.com> <200009011535.RAA05125@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 2898 Lines: 75 Hi Juergen, > > >>>>> Keith McCloghrie writes: > > Keith> So, > > Keith> option b) would be best, if you can resolve it quickly. > Keith> option c) would be OK, if it's within driving distance. > > I have worked hard on option b) and I finally got very friendly help > from T-Nova, the research organization of the Deutsche Telekom. They > arranged a meeting room for us in some conference facilities which are > located in a castle at the Main river about a hour drive from the > Frankfurt airport. So here are the details: > I am not going to be able to attend this meeting, but I appreciate the invitation very much. As I emphatically stated at the NIM BOF, I am strongly in favor of this work. I don't really agree with Keith that it is independent of the NIM effort, but I do agree that this work is long overdue, and a WG should be formed ASAP. (Maybe that's what Keith meant :-) Maybe I could attend the next meeting, hopefully a WG meeting at IETF #49 in San Diego. Andy > Tagungshotel Schloss Kleinheubach > Schlosspark 1 > 63924 Kleinheubach > Germany > > Tel. +49 9371 401-0 > Fax. +49 9371 401 107 > email > > A very nice photo of the location can be found here: > > > > I have reserved a few rooms in the hotel so that we can actually stay > over night in the castle. The rates are very reasonable - about 100 DM > which amounts to roughly US $ 50 these days. Please contact the hotel > and tell them when you will arrive and how long you are going to > stay. > > If you experience any problems with the room reservation or you have > any other urgent question, you can as well contact Uli Gruen > from T-Nova who did a great job of organizing > this nice meeting place for us. > > The web page has a map (under "Anreise") which explains how you reach > Kleinheubach from Frankfurt airport by car. The meeting place is > directly located at the street B 469. So from the airport, just take > highway <3>. Leave at the exist "Stockstadt" and take the B 469 south > until you reach Kleinheubach. The whole trip should not take more than > an hour. > > You can find all this information including the map and the picture on > > in case the other URL does not work for you. > > Sorry that it took so long to get the meeting location finalized. If > you are interested, then I can tell you the whole story over a beer or > a glass of wine next week. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA09195 for nmrg-outgoing; Fri, 1 Sep 2000 17:36:19 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA09175; Fri, 1 Sep 2000 17:35:55 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA05125; Fri, 1 Sep 2000 17:35:55 +0200 Date: Fri, 1 Sep 2000 17:35:55 +0200 Message-Id: <200009011535.RAA05125@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de CC: kzm@cisco.com, david.durham@intel.com, abierman@cisco.com, heiko.dassow@telekom.de In-reply-to: <200008291921.MAA03368@ups.cisco.com> (message from Keith McCloghrie on Tue, 29 Aug 2000 12:21:24 -0700 (PDT)) Subject: [nmrg] Re: sming/sppi/smiv2 integration meeting details References: <200008291921.MAA03368@ups.cisco.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 2311 Lines: 62 >>>>> Keith McCloghrie writes: Keith> So, Keith> option b) would be best, if you can resolve it quickly. Keith> option c) would be OK, if it's within driving distance. I have worked hard on option b) and I finally got very friendly help from T-Nova, the research organization of the Deutsche Telekom. They arranged a meeting room for us in some conference facilities which are located in a castle at the Main river about a hour drive from the Frankfurt airport. So here are the details: Tagungshotel Schloss Kleinheubach Schlosspark 1 63924 Kleinheubach Germany Tel. +49 9371 401-0 Fax. +49 9371 401 107 email A very nice photo of the location can be found here: I have reserved a few rooms in the hotel so that we can actually stay over night in the castle. The rates are very reasonable - about 100 DM which amounts to roughly US $ 50 these days. Please contact the hotel and tell them when you will arrive and how long you are going to stay. If you experience any problems with the room reservation or you have any other urgent question, you can as well contact Uli Gruen from T-Nova who did a great job of organizing this nice meeting place for us. The web page has a map (under "Anreise") which explains how you reach Kleinheubach from Frankfurt airport by car. The meeting place is directly located at the street B 469. So from the airport, just take highway <3>. Leave at the exist "Stockstadt" and take the B 469 south until you reach Kleinheubach. The whole trip should not take more than an hour. You can find all this information including the map and the picture on in case the other URL does not work for you. Sorry that it took so long to get the meeting location finalized. If you are interested, then I can tell you the whole story over a beer or a glass of wine next week. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936