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

From: "Robert Snively" <[email-masked]>
Date: Mon, 3 May 2004 10:04:26 -0700

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.

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

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

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 3 May 2004 11:06:48 -0700 (PDT)

> 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.
 
> information in the MIB.  "Dynamic" does not even have that
 
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.