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

From: Keith McCloghrie <[email-masked]>
Date: Sun, 2 May 2004 10:56:46 -0700 (PDT)

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

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

---

From: Keith McCloghrie <[email-masked]>
Date: Sun, 2 May 2004 11:08:32 -0700 (PDT)

Mike,
 
> >"I think Keith is correct that not having a standard to reference is
> >	insufficient to remove "dynamic", as this would also entail
> >	also removing "other" and "unknown", which does not appear to
> >	be a desired outcome.
> 
> "Other" and "Unknown" are (as is stated) used to indicate that (for
> the case of 'other') the agent can determine the port type and it is
> NOT any of those types identified in the MIB.  "Unknown" indicates the
> agent is unable to ascertain its type (be it any of those identified or
> other).  It is an accepted mechanism in MIB's to provide an agent a
> mechanism to report it as such.
>
> Based on the above, I don't accept the logic that because 'other' and
> 'unknown' are not specified in any standard and that dynamic is ALSO
> not specified in any standard then "other" an "unknown" should also be
> removed from the MIB.

I think you've inverted the logic that I intended to convey; let me try
again: "there's no reference for 'dynamic'" is an insufficient reason
to remove it, because if that reason only was sufficient then 'other'
and 'unknown' would also have to be removed. which would clearly be a
mistake.
 
> As for the use of dynamic, it is my opinion that if the specified
> states of a port can be determined (and documented in the MIB), then
> dynamic has no value.  And, from an implementor's perspective, if
> dynamic is added to the MIB, when does one report "dynamic" versus
> G-port, GL_port, FNL_port (or other specified port types)?
>
> If it is to 'future-proof' the MIB, what does 'future_port_type' (aka
> 'dynamic') tell me that 'other' does not?  Help me understand.  Maybe
> someone can point to where this has been successfully implemented (not
> just documented) in other MIBs so we can use this as a model for
> future-proofing our FC MIB's.  As an application vendor, "dynamic"
> doesn't add any additional value as specified today.
 
I am obviously guilty of doing a poor job of editing the MIB.
Please see my message to Bob Snieveley for what I hope is a better
definition which will answer your questions.
 
Keith.