Subject: IANA Considerations

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Apr 2000 00:06:51 -0400

I initiated discussion with our ADs recently regarding the IANA
considerations in RFC 2661.

There are two decisions we face, and have not reached clear agreement.
I'd like to get a feel of the WGs opinion here.

Issue #1

Currently, a new IETF AVP value may only be requested for RFCs. That is,
after last call and approval by the IESG. In DC we discussed (and agreed
upon) the value in obtaining numbers from IANA here at an earlier stage
so as to reduce the risk of ultimately maintaining two values (the IANA
number and whatever vendor-specific number that was originally
documented). 

We have three choices.

A. Stay where we are, and request IANA numbers only after the RFC
publication is imminent.
B. Write a short RFC modifying the policy.
C. Modify RFC 2661 in the next rev to reflect a new policy, and wait
until it is published before it can be followed.

The new policy might be that a person (such as the WG chair) is
appointed to determine when the WG has sufficient consensus to request a
value. This would typically be at or near the point of last call,
depending on implementation demand and clarity of consensus.

Issue #2

This is simply where to begin handing out new values for AVPs. The
highest value now is 39. We have two choices.

A. Begin at 40
B. Begin at some other value slightly higher, say, 50, so that *if* we
end up adding an AVP or two to the base spec as it advances, we can
remain contiguous in the base spec.

Opinions appreciated. Thanks,

- Mark

---

From: Bill Palter <[email-masked]>
Date: Thu, 20 Apr 2000 09:59:46 -0700

> Would it make it any easier if we defined an 'experimental' vendor ID
> which IANA can allocate AVP types/values out of. The number space could
> mirror the IETF number space (may be hard to manage) so that if adopted
> the type/values remain the same, just the vendor ID changes.
> 
> just a thought,

  I like it......Wonder what we need to do to get a vendor id allocated..
> 
> evan
> -
> 
> "W. Mark Townsley" wrote:
> > 
--
Bill Palter ([email-masked])

---

From: Evan Caves <[email-masked]>
Date: Thu, 20 Apr 2000 09:59:34 -0700

just a thought,

evan
-

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 20 Apr 2000 10:24:32 -0700 (PDT)

hmmm... I'm not sure that this is really the direction that we want. I would
actually ask that we update RFC2661, and state that the numbers are assigned
from a Designated Expert, which is frequently done.

The con: We have to reset the clock before moving to draft standard.

The pro: Number allocation actually works

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 20 Apr 2000 10:48:54 -0700

> B. Write a short RFC modifying the policy.

Good idea.

> remain contiguous in the base spec.

Semi-contiguous, unless all 10 numbers are used.  If none are used, then
there will be a hole; how big a hole is acceptable seems to be highly
implementation-dependent, to the point of being a matter of taste.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Apr 2000 22:18:57 -0400

>   I like it......Wonder what we need to do to get a vendor id allocated..

I doubt the ADs would go for this. Pretty soon, every working group will
want their own Vendor ID. Not a bad idea per se, but additional
adminstrative overhead is often resisted...

However, if we wanted to buck the system, there are a number of
companies that could donate their SMI Enterprise code to us :-) 

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Apr 2000 22:25:16 -0400

> The con: We have to reset the clock before moving to draft standard.

Which clock? We have edits to do anyway and the draft standard goal is
still months away. Are you suggesting that such a change would require
recycling at PS?

> The pro: Number allocation actually works

A nice upshot.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Apr 2000 22:26:22 -0400

> implementation-dependent, to the point of being a matter of taste.

Precisely what I am trying to get a handle on. I know my taste, but
would like to know the WG's taste.

- Mark

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 21 Apr 2000 10:31:16 -0700

> still months away. Are you suggesting that such a change would require

Perhaps the ADs would care to comment on this, but I doubt that this kind of
change would cause recycling at PS, since the change is substantively
administrative rather than technical.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 21 Apr 2000 10:26:31 -0700

> >   I like it......Wonder what we need to do to get a vendor id

I'm not sure what advantage this scheme has over just using the vendor ID of
the primary draft author's company (cisco, MSFT, etc.) in combination w/some
modest coordination of number assignment (perhaps by the WG Chair?).  You're
still likely to have to support 2 AVPs w/the same (or at least similar)
semantics (the "experimental" and the standard)for an indeterminateperiod
after the issuance of the RFC, right?

---

From: Thomas Narten <[email-masked]>
Date: Fri, 21 Apr 2000 15:29:30 -0400

> Perhaps the ADs would care to comment on this, but I doubt that this
> kind of change would cause recycling at PS, since the change is
> substantively administrative rather than technical.

Changing the IANA considerations will have no effect on whether the
document needs to recycle at Proposed or can advance to Draft.

When deciding whether to advance or recycle, interoperability
considerations are the main concern. If a revised document results in
implementations compliant with the old spec no longer being
interoperable with implementations based only on the new, recycling is
required. Otherwise, advancing is probably OK. I.e., you can't advance
if there are substantive changes.

Thomas