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

From: "Mike O'Donnell" <[email-masked]>
Date: Mon, 3 May 2004 12:47:21 -0600

Might I recommend we provide what the requirement is?  I'm reading (at least) two different things here:

1. A desire to 'future-proof' the MIB with respect to port types. 

I may be misintepreting Keith's request, but I understood that was what you meant by 'dynamic' (which I semantically dislike for this use).  The heartburn I have with this is that when we define the 2nd 'new' port type in the future, 'dynamic' becomes ambiguous (unless we create a range as was previously suggested).  I do agree that defining new port types should explicitly define their semantics.

2. A mechanism to convey vendor specific port types.

For case number 2, 'vendor specific other' seems to fulfill a method for allowing a vendor to implement an 'other' port type (recall that 'other' means the agent can and has determined the port type) and the client may issue subsequent queries to determine what the 'vendor unique port' type is and make some sense from that information.

Keith, am I anywhere close to understanding your needs for 'dynamic'?  Or is it both case 1 and 2 above? or?

Mike O

====================== 
Michael E. O'Donnell 
Director Software Architecture 
McDATA Corporation 
4 McDATA Parkway 
Broomfield, Colorado 80021 
720.558.4142 (office) 
303.570.3631 (cel) 
[email-masked] 
======================

-----Original Message-----
From: Robert Snively [mailto:[email-masked]]
Sent: Monday, May 03, 2004 11:04 AM
To: Keith McCloghrie
Cc: [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
********************************

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

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

SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the 
addressee(s) named  above and may contain confidential and privileged 
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader of
this message is not the intended recipient(s) or the employee or agent 
responsible for delivering the message to the intended recipient, you
are hereby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY 
PROHIBITED.

Anyone who receives confidential and privileged information in error should 
notify us immediately by telephone and mail the original message to us at the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions 
apply to that information. (gate01)

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

---

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

Mike,

While I do want to split 'other' into two enumerations, it is only Bob
Sniveley who has proposed "vendor specific other", which is absolutely
NOT the way I want to cut it, because (as I said before) I want
something which can be used for a future T11-specified type which is:

a) not specified in the MIB (and after the RFC is published it will at
least 3 years and probably more like 5 years (or never!!) before we
could get an update published), and

b) which results in an on-the-wire negotiation and/or determination of
the type.

Elizabeth understands want I'm asking for, because her suggestion of a
registry is more than sufficient to meet my "requirement"; the question
is whether a registration is necessary.  The truth is that I don't
really have a "requirement"; before this latest flurry of messages, the
MIB contained 'dynamic'; as we add the new types, I still see potential
future value in something like 'dynamic'; thus, it makes sense to me to
keep it, renamed to whatever you like.

Keith.

PS. I fear that I have been repeating in one message what I have
previously said in another message; if anyone else thinks that also,
then I apologise to them, but ...