sming meeting minutes draft...
"Durham, David" <[email protected]> Mon, 16 Dec 2002 01:12:54 -0800
| Newsgroups | gmane.ietf.sming |
|---|---|
| Message-ID | <[email protected]> |
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_01C2A4E3.512E8590
Content-Type: text/plain
SMIng Meeting Minutes from IETF55:
TUESDAY, November 19, 2002 Time: 1930-2200
Minute takers: Ravi Sahita
Minutes reported by David Durham
WG Chair: David Durham
Issue: Updated documents have not been produced. We need volunteers to
progress the SMI-DS related document set. Need more participation on the
mailing list.
Chair:
Revisited Charter and Milestones. Updated charter was put on the mailing
list. No issues raised on the list, no issues raised at the meeting either.
According to the charter milestones we are a year behind. The original
milestones assumed the nmrg documents which were complete, but the wg chose
to investigate the smi-ds route. We will still need a few iterations on the
smi-ds/v3 documents before they will be complete. The current proposed list
of documents in priority order is:
- 1. SMIv3 Language Definition: Andy Bierman
- 2. Capabilities MIB: Andy Bierman: DONE
- 3. SMIv3 Guidelines
- 4. Transition from SMIv2
- 5. SMIv3 MIB Modules (core types)
- 6. INET Modules (textual conventions)
- 7. RFC 2580 Conformance Updates
We need volunteers for the documents or the wg will shut down, and the smi
will not progress. Previous volunteers for the guidelines and transition
documents are waiting for the language definition. In principle, people
support the smi-ds work, but we will need people to sign up to get the work
done. Likewise from the discussion at the wg meeting it seems that there is
a lot of waffling on how we proceed item by item through the open issues
listed below.
Wes Hardaker presented SMIng enhancements that would be useful to his OOPS
proposal:
Nested data structures such as Subarrays in arrays (eg. where you can have
multiple interfaces and multiple addresses assigned to each interface) make
indexing subelements difficult. Wes proposes that internal indices are given
a local number. Advantage is that we have a local index to it including
external indexes. This enbables all elements to be mapped to an OID.
Something like:
INDEXS otherIndex
FROM otherTable ::= {base 1}
What does this have to do with the SMI: If you pick an augmentation table.
Not a problem for previous SMI structures, but problematic to have nested
structures because need to go down to the index.
There was a lot of discussion whether or not this is useful. It provides a
way to separate the data instance index part of the oid from the data type
part of the oid. There was concern that this mechanism would affect
transpartent forward translations from SMIv2 MIBs, but this will apprarently
only affect new SMIv3 definitions where there is nesting and not SMIv2
stuff. Andy made it clear we should only have one version of the SMI and not
create the need to continually support two versions. There was no consensus
in the room that this was a necessary or appropriate language mechanism. Wes
was to post to the list some cases where this is valuable, removing oids
where possible, to better support compression because his new PDUs have a
base root oid.
Next it was pointed out that external augmentations are a pain from the
protocol's perspective with multiple random OID assignments. Any chance we
can fix this in SMIv3 via a forced local extension node?: Currently, if the
agent doesn't have the MIB definition locally, the agent needs to interpret
the oids without the MIB. One thing that makes augmentation tables difficult
is that if you don't know an agent supports the table you wouldn't know to
get it. It helps understanding for those who are trying to query agents.
Andy pointed out his original proposal fixed this by having a 0.enterprise
ID where you could augment right inline the oid hierarchy, but this went
away when the indices were all grouped back on the right of the oid to
preserve forward mapping of existing tables. Wes proposes that this is only
for new structures in SMIv3, but Andy believe we really need to go back to
understand the importance with the forward translation because we don't want
to have two versions of the smi going forward. The purpose is to make the
new oops protocol mappings work better with SMIv3 structures.
Again, there was no consensus in the room around this proposal. More thought
is needed to fully understand what the problem is before we add more syntax
to the smi, and Wes volunteered to elaborate on the problem on the mailing
list.
Next, Wes suggests that smiv3 notifications should be able to contain
structs and possibly even arrays. Currently only support for single objects.
Example: would like to be able to send all addresses associated with linkup.
It would be nice to support new notifications with more complex/complete
data (like syslog). The limited data that snmpv3 notifications support is a
reason why operators use prefer to use syslog instead of snmp. Wes is trying
to define new PDUs to make access to new more complete structures easier.
This affects smiv3 because notifications would now be able to support
aggregate types instead of just base types, but this would not be backwards
with snmpv3. There was more support in the room for this proposal over the
rest, however, enabling backward compatibility w/ snmpv3 requires more
thought.
Andy Bierman presents the SMIv3 Open issues:
* NULL choice for union types:
Like and SQL NULL value. Want to be able to create a template for a generic
table (eg. RMON control entry)... can create an instance of that table and
leave out stuff that you didn't need in your usage scenario. In sming it was
implements X and implements Y but not Z, which is like partial inheritance.
Instead, he proposes the parent gets to tell you what it can pick and
choose, so it's not equivalent to partial inheritance. Still, Andy is not
convinced that this is worth the trouble it might cause.
* Oid naming for aggresgates and sub-aggregates:
How to tell you want to access row three down in the second nested array. DH
suggested having a zero to apply on the left to distinguish the constant
part from the instance identifier part. This may be a moot point if the
protocol changes, and you don't get the support in SNMPv3 for it, so you
only support the fancy new aggregate new stuff with new protocol. Also
weren't sure if adding .0's everywhere is backward compatible. One of the
examples where it doesn't work is where it is 1.6.1... Other organizations
my have oids with 0's in them. The only rule is that the last subidentifier
per object can't be 0. You can't number interior nodes with zero. If have a
nested array want to get internal array now. Want more granularity to get
one or get everything.
Andy would advocate doing new things with the new protocol and not trying to
retrofit into the existing SNMPv3 protocol. They should still work with
snmpv3, but they will be suboptimal there.
The issue was raised that when you have multiple levels of nesting in your
oid, then your encoding rules either result in ambiguities or undesirable
behaviors in get next and get bulk. Andy believes that if you are trying to
get a leaf, and all the indices are on the right, there are no ambiguities.
The suboptimal behavior of get next is the same bad behavior that we already
have today. The orders that we got were always suboptimal. Getting rows
would be correct, but we instead get the columns. Still, the worst case and
the specific issue was poor behavior with unions, because the order is
questionable.
DD: Why not having a separate branch for all new SMIv3 structure. Having
naming that is helpful to us instead of being in the way. If you have only
one layer of nesting then it falls out that the indicies are on the right,
because they are in the right place anyway. Bring this to the list, too
complex to deal with now. Juergen previously had objections to putting the
new definitions under a new branch, he thought it would break things.
* NOTIFICATION definitions in TYPEs:
Proposal to move notifications into the types to be more OO-like. It is not
always true a notification can be tied to a specific set of data, however.
Also not sure what problem this issue solves. Juergen previously also wanted
master NOTIFICATION (link up), and derived NOTIFICATIONs. Suggestion was to
take this to the list until we can understand what Juergen wanted to do
originally. Moving on...
* Inline vs. by-reference TYPEs and VARs:
Extend types by inline or by reference and only allow named types. Interim
decided that we only do it by reference, never inline. By reference allows
all constructs to be reusable. Adds some complexity in terms of versioning.
We would never allow a type to be silently extended, you would have to clone
it. Another issue is it makes MIBs harder to read because you have to search
for type definitions. Some have suggested that this makes things unreadable.
Turns out that people think referencing things by type is an annoyance. Some
things are simply not meant to be reused. The MIB writer has to have some
responsibility with the freedom. Inline definitions should be allowed to aid
readability. *** The consensus in the room was to kill the proposal to force
all types to be reusable. ***
* Descriptor naming issues for TYPEs.
BCP document would define what the limit is for different protocol mappings,
and the current limit that names are to be restricted to <=32/64 will be
eliminated. Hums agree.
Require uniqueness only within the scope of the parent node. Can you have
descriptors that define the same data types. It needs to be fully qualified.
It is important to distinguish between the name of the type (eg. TC) and the
name of an object (the oid). This discussion is specifically around type
descriptors. You can use the module name descriptor to find import name
clashes.
Finally, it was suggested we move to XML style names; mixed case with
hypens. Hums agreed this would be good to do.
* Conformance section changes to support SMIv3.
Existing MODULE-SOMPLIANCE macro won't work for SMIv3 objects. Descriptors
are not unique within the module. Existing problems with SMIv2 need to be
fixed such as OBJECT clauses for INDEX objects. Need to create a construct
for each complex VAR declaration... Could fully specify attribute names; but
it would be better to have a shorthand notation. Andy suggests he will work
on this offline, it's not an open issue, he just needs to finish it.
* Change control issues for variables
Need to be able to add new attributes to existing VARs, just as we add new
columns to an existing table now. We should be able to create a new type
which is a superset of an old type and allow VAR SYNTAX to change. Use
conformance section for version identification. Allow the writer to replace
FooType with BarType which is a superset of FooType. This could be done with
a Cut & paste operation, and can only add new definitions to the end. If it
is defining a subclass, need to increase the naming depth. It would be
useful to have an include clause since we want to be able to compose new
object definitions from the old definitions. This is specifically for change
control. Only semantics of fooType need to stay the same, just need to add
columns to a table in a radically new way.
* SMI syntax changes
Many syntax changes proposed by at the last interim. Need to decide case by
case on the mailing list. Examples: Imports; LEAF, NODE or ATTRIBUTE;
OBJECT-GROUP ->GROUP; NOTIFICATION-GROUP -> GROUP; Base type names; Remove
MODULE - this module should be implied. There were no comments. There was
little support for syntax changes in the room.
* Migration of SMIv2 CLRs to SMIv3
Suggestion was to take them out of the SMI and put them into a separate
document particular to a protocol mapping. But we don't want to put the sign
that says no left on main and collect it with all other crappy little road
signs and put them in the same place. But, at the same time, we need to make
the language document somewhat future proof so when protocols are upgraded,
we don't have to update the full standard document... Concensus in the room
was to put these rules in a separate informational document & thus easier to
change.
* Support for Configuration:
Need to distinguish between different types of objects: Configuraton (acl
list, bgp peer, users/passwords) vs. Control (per-session debug commands,
reset card) vs. State (ifOperStatus) vs. Statistics (eg. ifInOctets). Need
mechanism to describe high-level configuration methods:Could be purely
documentation, but they need to be clearly specified in the MIB document...
These could be more, such as the minimum procedural requirements for a
particular task. Don't call these methods! Call them use cases or scenarios.
Specifically what is needed: Mechanism to describe what has to be created in
initial PDU, what can be edited after creation, what is the cascading
deletion order, etc.
* Support for XML naming , XSD translation.
It would make the IETF more consistent if the SMI were to be the base
definition for everything, XML, COPS-PR etc. Would like to make sure there
is only one data definition, regardless of the number of protocols. Some
hints to make language definitions easier: Need to identify XML Namespace
for MIB; Add optional XML-NAMESPACE "<URI>" clause in MODULE-IDENTITIY, or
use XML namespace MODULE name; Need to identify XML element names: Optional
XML-NAME "string" clause in TYPE or VAR constructs used to override
descriptor as element name. Need to map ARRAY population characteristics to
minOccurs, maxOccurs attributes.
The question was raised, why so much emphasis on XML. Some question if it
was appropriate to put XML name mappings inline vs. in a separate XML
mapping document as there could be a separate sppi mappings document. Given
Andy's suggestions for support of XML naming, some expressed that perhaps a
better outcome of this wg effort would be to declare that XMLSchema should
replace the SMI.
------_=_NextPart_001_01C2A4E3.512E8590
Content-Type: text/html
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (filtered)">
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>SMIng Meeting Minutes from IETF55:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal style='text-autospace:none'><font
size=2 face="Courier New"><span style='font-size:10.0pt;font-family:"Courier New"'>TUESDAY,
November 19, 2002</span></font><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'> Time: 1930-2200</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Minute takers: </span></font>Ravi Sahita</p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Minutes reported by David Durham</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>WG Chair: David Durham</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Issue: Updated documents have not been produced. We need volunteers to
progress the SMI-DS related document set. Need more participation on the
mailing list.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Chair:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Revisited Charter and Milestones. Updated charter was put on the
mailing list. No issues raised on the list, no issues raised at the meeting
either. According to the charter milestones we are a year behind. The original
milestones assumed the nmrg documents which were complete, but the wg chose to
investigate the smi-ds route. We will still need a few iterations on the
smi-ds/v3 documents before they will be complete. The current proposed list of
documents in priority order is:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font>1. SMIv3 Language Definition: Andy Bierman</p>
<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font>2. Capabilities MIB: Andy Bierman: DONE</p>
<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font>3. SMIv3 Guidelines </p>
<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font>4. Transition from SMIv2</p>
<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font>5. SMIv3 MIB Modules (core types)</p>
<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font>6. INET Modules (textual conventions)</p>
<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>-<font size=1
face="Times New Roman"><span style='font:7.0pt "Times New Roman"'>
</span></font></span></font>7. RFC 2580 Conformance Updates </p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>We need volunteers for the documents or the wg will shut down, and the smi
will not progress. Previous volunteers for the guidelines and transition
documents are waiting for the language definition. In principle, people support
the smi-ds work, but we will need people to sign up to get the work done.
Likewise from the discussion at the wg meeting it seems that there is a lot of
waffling on how we proceed item by item through the open issues listed below.
</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Wes Hardaker presented SMIng enhancements that would be useful to his OOPS
proposal:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Nested data structures such as Subarrays in arrays (eg. where you can
have multiple interfaces and multiple addresses assigned to each interface)
make indexing subelements difficult. Wes proposes that internal indices are
given a local number. Advantage is that we have a local index to it including
external indexes. This enbables all elements to be mapped to an OID. Something
like:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> INDEXS
otherIndex</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> FROM
otherTable ::= {base 1}</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>What does this have to do with the SMI: If you pick an augmentation
table. Not a problem for previous SMI structures, but problematic to have
nested structures because need to go down to the index. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>There was a lot of discussion whether or not this is useful. It
provides a way to separate the data instance index part of the oid from the
data type part of the oid. There was concern that this mechanism would affect transpartent
forward translations from SMIv2 MIBs, but this will apprarently only affect new
SMIv3 definitions where there is nesting and not SMIv2 stuff. Andy made it
clear we should only have one version of the SMI and not create the need to
continually support two versions. There was no consensus in the room that this
was a necessary or appropriate language mechanism. Wes was to post to the list
some cases where this is valuable, removing oids where possible, to better
support compression because his new PDUs have a base root oid. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Next it was pointed out that external augmentations are a pain from the
protocol's perspective with multiple random OID assignments. Any
chance we can fix this in SMIv3 via a forced local extension node?: Currently,
if the agent doesn't have the MIB definition locally, the agent needs to
interpret the oids without the MIB. One thing that makes augmentation tables
difficult is that if you don't know an agent supports the table you
wouldn't know to get it. It helps understanding for those who are trying
to query agents. Andy pointed out his original proposal fixed this by having a 0.enterprise
ID where you could augment right inline the oid hierarchy, but this went away
when the indices were all grouped back on the right of the oid to preserve
forward mapping of existing tables. Wes proposes that this is only for new
structures in SMIv3, but Andy believe we really need to go back to understand
the importance with the forward translation because we don't want to have
two versions of the smi going forward. The purpose is to make the new oops protocol
mappings work better with SMIv3 structures. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Again, there was no consensus in the room around this proposal. More
thought is needed to fully understand what the problem is before we add more
syntax to the smi, and Wes volunteered to elaborate on the problem on the
mailing list.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Next, Wes suggests that smiv3 notifications should be able to contain structs
and possibly even arrays. Currently only support for single objects. Example:
would like to be able to send all addresses associated with linkup. It would be
nice to support new notifications with more complex/complete data (like syslog).
The limited data that snmpv3 notifications support is a reason why operators use
prefer to use syslog instead of snmp. Wes is trying to define new PDUs to make
access to new more complete structures easier. This affects smiv3 because
notifications would now be able to support aggregate types instead of just base
types, but this would not be backwards with snmpv3. There was more support in
the room for this proposal over the rest, however, enabling backward
compatibility w/ snmpv3 requires more thought. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Andy Bierman presents the SMIv3 Open issues:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* NULL choice for union types:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Like and SQL NULL value. Want to be able to create a template for a
generic table (eg. RMON control entry)... can create an instance of that table
and leave out stuff that you didn't need in your usage scenario. In sming
it was implements X and implements Y but not Z, which is like partial
inheritance. Instead, he proposes the parent gets to tell you what it can pick
and choose, so it's not equivalent to partial inheritance. Still, Andy is
not convinced that this is worth the trouble it might cause. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Oid naming for aggresgates and sub-aggregates:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>How to tell you want to access row three down in the second nested
array. DH suggested having a zero to apply on the left to distinguish the
constant part from the instance identifier part. This may be a moot point if
the protocol changes, and you don't get the support in SNMPv3 for it, so
you only support the fancy new aggregate new stuff with new protocol. Also
weren't sure if adding .0's everywhere is backward compatible. One
of the examples where it doesn't work is where it is 1.6.1... Other
organizations my have oids with 0's in them. The only rule is that the last
subidentifier per object can't be 0. You can't number interior
nodes with zero. If have a nested array want to get internal array now. Want
more granularity to get one or get everything. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Andy would advocate doing new things with the new protocol and not
trying to retrofit into the existing SNMPv3 protocol. They should still work
with snmpv3, but they will be suboptimal there.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>The issue was raised that when you have multiple levels of nesting in
your oid, then your encoding rules either result in ambiguities or undesirable
behaviors in get next and get bulk. Andy believes that if you are trying to get
a leaf, and all the indices are on the right, there are no ambiguities. The suboptimal
behavior of get next is the same bad behavior that we already have today. The
orders that we got were always suboptimal. Getting rows would be correct, but
we instead get the columns. Still, the worst case and the specific issue was
poor behavior with unions, because the order is questionable. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>DD: Why not having a separate branch for all new SMIv3 structure.
Having naming that is helpful to us instead of being in the way. If you have
only one layer of nesting then it falls out that the indicies are on the right,
because they are in the right place anyway. Bring this to the list, too complex
to deal with now. Juergen previously had objections to putting the new
definitions under a new branch, he thought it would break things.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* NOTIFICATION definitions in TYPEs:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Proposal to move notifications into the types to be more OO-like. It is
not always true a notification can be tied to a specific set of data, however.
Also not sure what problem this issue solves. Juergen previously also wanted
master NOTIFICATION (link up), and derived NOTIFICATIONs. Suggestion was to
take this to the list until we can understand what Juergen wanted to do
originally. Moving on...</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Inline vs. by-reference TYPEs and VARs:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Extend types by inline or by reference and only allow named types.
Interim decided that we only do it by reference, never inline. By reference
allows all constructs to be reusable. Adds some complexity in terms of
versioning. We would never allow a type to be silently extended, you would have
to clone it. Another issue is it makes MIBs harder to read because you have to
search for type definitions. Some have suggested that this makes things
unreadable. Turns out that people think referencing things by type is an
annoyance. Some things are simply not meant to be reused. The MIB writer has to
have some responsibility with the freedom. Inline definitions should be allowed
to aid readability. *** The consensus in the room was to kill the proposal to
force all types to be reusable. ***</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Descriptor naming issues for TYPEs. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>BCP document would define what the limit is for different protocol mappings,
and the current limit that names are to be restricted to <=32/64 will be
eliminated. Hums agree.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Require uniqueness only within the scope of the parent node. Can you
have descriptors that define the same data types. It needs to be fully
qualified. It is important to distinguish between the name of the type (eg. TC)
and the name of an object (the oid). This discussion is specifically around
type descriptors. You can use the module name descriptor to find import
name clashes.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Finally, it was suggested we move to XML style names; mixed case with hypens.
Hums agreed this would be good to do.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Conformance section changes to support SMIv3. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Existing MODULE-SOMPLIANCE macro won't work for SMIv3 objects.
Descriptors are not unique within the module. Existing problems with SMIv2 need
to be fixed such as OBJECT clauses for INDEX objects. Need to create a construct
for each complex VAR declaration... Could fully specify attribute names; but
it would be better to have a shorthand notation. Andy suggests he will work on
this offline, it's not an open issue, he just needs to finish it. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Change control issues for variables</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Need to be able to add new attributes to existing VARs, just as we add
new columns to an existing table now. We should be able to create a new type
which is a superset of an old type and allow VAR SYNTAX to change. Use
conformance section for version identification. Allow the writer to replace FooType
with BarType which is a superset of FooType. This could be done with a Cut
& paste operation, and can only add new definitions to the end. If it is
defining a subclass, need to increase the naming depth. It would be useful to
have an include clause since we want to be able to compose new object
definitions from the old definitions. This is specifically for change control.
Only semantics of fooType need to stay the same, just need to add columns to a
table in a radically new way. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* SMI syntax changes</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Many syntax changes proposed by at the last interim. Need to decide
case by case on the mailing list. Examples: Imports; LEAF, NODE or ATTRIBUTE; OBJECT-GROUP
->GROUP; NOTIFICATION-GROUP -> GROUP; Base type names; Remove MODULE
- this module should be implied. There were no comments. There was little
support for syntax changes in the room.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Migration of SMIv2 CLRs to SMIv3</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Suggestion was to take them out of the SMI and put them into a separate
document particular to a protocol mapping. But we don't want to put the
sign that says no left on main and collect it with all other crappy little road
signs and put them in the same place. But, at the same time, we need to make
the language document somewhat future proof so when protocols are upgraded, we
don't have to update the full standard document... Concensus in the
room was to put these rules in a separate informational document & thus easier
to change. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Support for Configuration:</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Need to distinguish between different types of objects: Configuraton (acl
list, bgp peer, users/passwords) vs. Control (per-session debug commands, reset
card) vs. State (ifOperStatus) vs. Statistics (eg. ifInOctets). Need mechanism
to describe high-level configuration methods:Could be purely documentation, but
they need to be clearly specified in the MIB document... These could be
more, such as the minimum procedural requirements for a particular task.
Don't call these methods! Call them use cases or scenarios. Specifically
what is needed: Mechanism to describe what has to be created in initial PDU, what
can be edited after creation, what is the cascading deletion order, etc. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>* Support for XML naming , XSD translation.</span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>It would make the IETF more consistent if the SMI were to be the base
definition for everything, XML, COPS-PR etc. Would like to make sure there is
only one data definition, regardless of the number of protocols. Some hints to
make language definitions easier: Need to identify XML Namespace for MIB; Add optional
XML-NAMESPACE "<URI>" clause in MODULE-IDENTITIY, or use XML
namespace MODULE name; Need to identify XML element names: Optional XML-NAME
"string" clause in TYPE or VAR constructs used to override
descriptor as element name. Need to map ARRAY population characteristics to minOccurs,
maxOccurs attributes. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>The question was raised, why so much emphasis on XML. Some question if
it was appropriate to put XML name mappings inline vs. in a separate XML
mapping document as there could be a separate sppi mappings document. Given
Andy's suggestions for support of XML naming, some expressed that perhaps
a better outcome of this wg effort would be to declare that XMLSchema should
replace the SMI. </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> </span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> </span></font></p>
</div>
</body>
</html>
------_=_NextPart_001_01C2A4E3.512E8590--