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

From: [email-masked]
Date: Tue, 4 May 2004 12:32:22 -0400

----- IANA registry

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

I like the idea of an IANA registry, but for a couple of reasons
other than a potentially high rate of defining new port types:

(1) Fast turnaround: A new port type could be added to an IANA
	registry in a matter of weeks after T11 determines that
	it is appropriate.  Publishing a revised RFC takes months,
	even under ideal conditions, and conditions have not been
	ideal lately ...
(2) Proper review: As part of setting up the registry, we can
	define the process for adding entries, allowing us to give
	IANA explicit written instructions on how to obtain T11's
	concurrence on allocations of new entries.  This would be an
	aspect of Expert Review (cf. RFC 2434), and I would also impose
	a Specification Required requirement that can be satisfied
	by a T11 working version of a standard under development,
	(but not a proposal - I think it's fair to require that T11
	have voted to incorporate the proposed new port type).

I would expect a relatively low rate of new port type definitions
(handful per year at most).

If this makes sense, Elizabeth, Bob and I are at the T10 meetings
in Monterey, and can easily work out how IANA should interact with
T11 in the next few days.

----- MIB types

The distinction between otherFixed and otherDynamic (otherNegotiate)
may be useful because:

- otherFixed means that the port type is not on the list and
      the port will not auto-negotiate to become some other type
	(and specifically won't become one of the known types on
	 the list).
- otherDynamic (or otherNegotiate) means that the port type is
	not on the list, but can auto-negotiate, which could result
	in it becoming one of the listed types (or some otherFixed type).

Assuming that virtual fabric trunking/tagging goes forward in T11,
two examples of port types that are likely to exist are:

- a trunked tagged E_Port (like an E_Port, but carries traffic
	that's tagged with virtual fabric tags).  This would be
	an otherFixed prior to its addition to the enumeration.
- a new type of G_Port that could become a trunked E_Port, in
	addition to all the other things that an existing G_Port
	can become.  This would be an otherDynamic (otherNegotiate)
	prior to its addition to the enumeration.

Do people think this distinction is useful?  If it's useful, then
we'd need to change "dynamic" to "otherDynamic" and "other" to
"otherFixed".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Keith McCloghrie
> Sent: Tuesday, May 04, 2004 9:42 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to 
> remove "dynamic"
> 
> 
> 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.
> 
> > 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.

[... snip ...]

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

---

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

David,

Thank-you.

I have already given my input on the questions you ask.  I'm happy to
leave you to determine the consensus on these issues.

Keith.