Subject: RE: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" port type for FcPortType

From: [email-masked]
Date: Mon, 3 May 2004 20:00:47 -0700

Hi all,

Instead of using a numerated list directly embedded in the MIB, could we
address this issue through the creation of an IANA registry?

Essentially, what this discussion comes down to is how do we future-proof
the MIB.  I believe that thru the use of a registry we may be able to
accomplish Keith's goal without creating a MIB type that does not have a
definition in today's T11 standards.  Once new port types are defined by
T11, a new port type could be assigned in the registry to correspond to that
type for use in this MIB.

I am not yet sure about the precedence for use of IANA registries with MIBs,
and that is something I would need to consult with the transport and
operations Area Directors, but is this an acceptable solution to everyone?

Thanks,

Elizabeth Rodriguez 

-----Original Message-----
From: Keith McCloghrie [mailto:[email-masked]] 
Sent: Monday, May 03, 2004 11:07 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic" port
type for FcPortType

INCITS T11.5 Mail Reflector
********************************

> The point is that it provides absolutely no information
> that is not present in the "other" category.  If you don't know
> in what sense it is dynamic and what resolutions and algorithms
> are necessary to resolve its dynamic behavior to some other
> behavior, you have gained no information about the port.

But it does, and you do gain information.  Obviously, I am still
failing to make you understand.  Perhaps it's the word "fixed"
which is now the problem; so, let me try again:

 'otherFixed' -- a type which is known to the agent a priori and
                 the port does not perform on-the-wire
                 determination/negotiation, and is not one of these
                 types: 'nPort', 'nlPort', 'fPort' 'flPort', 'ePort'
                 or 'bPort'.
 'otherNegotiate' -- the port type is determined via on-the-wire
                 determination/negotiation, and is not one of these
                 types: 'gPort', 'glPort', 'fnlPort'.

Note: one of these is via on-the-wire determination/negotiation
 and  one is not.  By definition, they ARE different.
 
> "vendor specific other" might be a more useful value than
> dynamic, because that indicates that there is a mechanism
> to determine the "otherness" of the port through vendor 
> specific behaviors, where the vendor and model are known from other
> information in the MIB.  "Dynamic" does not even have that
> grace.
 
No, no, no.  Please don't read vendor-specific into this; it is not
relevant.  You didn't answer my question on whether the new types have
been approved by T11 Ballot yet.  Let me assume that they haven't, and
that someone objects to adding them on that basis, then such ports
would have to be represented by 'otherNegotiate' not by 'otherFixed'.
So, no, 'otherNegotiate' is not vendor-specific.

Keith.

> Bob
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Keith 
> > McCloghrie
> > Sent: Sunday, May 02, 2004 10:57 AM
> > To: Robert Snively
> > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked];
> > [email-masked]
> > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for
> > FcPortType
> > 
> > 
> > INCITS T11.5 Mail Reflector
> > ********************************
> > 
> > Bob,
> > 
> > No, a MIB is not just a specification of syntax; a MIB is required 
> > to define the semantics of objects also.  Otherwise, the MIB has no
> > value to a management application.  So, a MIB with your "pre-specified
> > type values" *would* undergo a change (in semantics) as and when T11
> > defined the semantics.
> > 
> > However, I agree with your recognition of the future need for:
> > 
> > a) "ports with a negotiation algorithm", as well as
> > b) "ports with a pre-established fixed type".
> > 
> > Since we cannot (see above) pre-define such types, if we removed
> > 'dyanmic' then both of these categories would have to be lumped
> > together under 'other'.  The reason to retain 'dynamic' is to allow a
> > management application to distinguish between these two 
> > types.  I don't
> > understand the strong opposition to allowing such a distinction.  How
> > can anyone object to giving a management application more accurate
> > information ??
> > 
> > Perhaps the problem is that I've failed to define/explain them
> > properly, or perhaps it's the word "dynamic" that you don't like.
> > So, how about we take the two current enumerations 'other' 
> > and 'dynamic'
> > and replace them with these two:
> > 
> > 'otherFixed' -- a fixed type (known to the agent) which is not one of
> >        these types: 'nPort', 'nlPort' 'fPort' 'flPort' 
> > 'ePort' or 'bPort'.
> > 'otherNegotiate' -- a type (known to the agent), which is subject to
> >        on-the-wire determination (e.g., by negotiation), but which is
> >        not one of these types: 'gPort', 'glPort', 'fnlPort'.
> > 
> > Keith.
> > 
> > PS. I can't locate the definitions of 'gPort' and 'glPort'.  I note
> > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127)
> > of GS-4, and I would have expected to find G_Port and GL_Port in the
> > same/corresponding sections, but they're not.  Please can you provide
> > me with a document name and section number reference for these two.
> > Or, am I mistaken in assuming that these new types have been approved
> > by T11 Ballot ??
> > 
> > 
> > > Using David Black's consensus call, I will focus on 
> > > the "dynamic" question.
> > > 
> > > I am in agreement with Mike O'Donnell's 
> > > analysis of "unknown" and "other".  I support his
> > > conclusions on "dynamic" (i.e. that it should be
> > > removed as a port type).
> > > 
> > > Keith McLoughrie indicates that dynamic is useful
> > > for future proofing.  I believe that the most effective
> > > mechanism for future proofing would be to remove
> > > "dynamic" as a type, then provide a certain number
> > > of pre-specified type values for future assignment
> > > by INCITS TC T11 standards.  That way, the MIB can remain 
> > unchanged and
> > > the
> > > values be picked up by future T11 standards if they
> > > are ever required.  The number of such values should
> > > be small, since any large number of future variants would
> > > probably require modification to the MIB anyway.
> > > 
> > > That allows both for future definition of ports with a 
> > > negotiation algorithm and ports with a pre-established 
> > > fixed type, something that "dynamic" does not.
> > > 
> > > Robert Snively
> > > 
> > > Brocade Communications Systems, Inc.
> > > 1745 Technology Drive
> > > San Jose, CA 95110
> > > 
> > > +1 408 333 8135
> > > [email-masked] 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > To Unsubscribe:
> > mailto:[email-masked]?subject=unsubscribe
> > 
> > 
> > 
> 
> _______________________________________________
> imss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/imss
> 

To Unsubscribe:
mailto:[email-masked]?subject=unsubscribe

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 4 May 2004 06:41:52 -0700 (PDT)

Hi Elizabeth,
 
There are a couple of cases where IANA assigns enumerated values in
a MIB, e.g., http://www.iana.org/assignments/ianaiftype-mib lists the
latest version of the IANAifType TC which includes all the latest IANA
assignments (including the last one of 'fcipLink' which I believe was
requested by this WG.)

Having IANA do this is necessary when the rate of new assignments is
relatively high (e.g., there are now 224 values defined for IANAifType),
but it has the downside that it increases the number of steps required
to locate the latest assignments.  To find the above URL, the primary
author of that MIB had to go to the IANA web-page and figure out how
to navigate through several web-pages in order to find it.  It's much
simpler for network adminstrators and/or management application
writers to find the assignments when they are listed in the RFC's
version of the MIB.  In other words, I believe whether or not to have a
IANA registry for a particular enumerated value in a MIB is a
trade-off:  worthwhile only if the rate of new assignments is high.

In this case, Bob and Mike are in a much better position to know
whether the rate of defining new port types is liable to be high.

Keith.