Subject: RE: IANA Considerations

From: "Verma, Rohit (US - Chicago)" <[email-masked]>
Date: Thu, 20 Apr 2000 14:29:15 -0400

For Issue #2:-
We have 2 bytes available for the Attribute Type. Why don't we hand new
AVP's with the precondition that the MSBit for the new AVPs must be 1.

New AVPs 0x80, 0x81 ....0xff
Base Spec AVPs 0x01....0x7f

This precondition it will ensure continuity for the base spec to a large
Attribute Type space.
Also it will be easier for implementations to differentiate between base
spec AVPs and new ones.

Regards
Rohit Verma
Deloitte Consulting
180, N. Stetson Avenue
Chicago, Illinois 60601
Phone:312-374-2475

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Wednesday, April 19, 2000 11:07 PM
To: [email-masked]
Subject: IANA Considerations

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: "W. Mark Townsley" <[email-masked]>
Date: Thu, 20 Apr 2000 22:40:28 -0400

> "Verma, Rohit (US - Chicago)" wrote:
> 
> For Issue #2:-
> We have 2 bytes available for the Attribute Type. Why don't we hand
> new AVP's with the precondition that the MSBit for the new AVPs must
> be 1.
> 
> This precondition it will ensure continuity for the base spec to a
> large Attribute Type space.

Effectively defining a bit field that states "this is part of the base
spec" 

I think this adds unnecessary complexity. Takes a chunk out of the
number space for extensions as well. Adding values to the base spec
should be the exception, not the rule. If we are going to go nuts with
new values, we should separate these out in separate specs 'ala DHCP
anyway. I doubt this is the case.

> Also it will be easier for implementations to differentiate between
> base spec AVPs and new ones.

There is no real need for implementations to be able to do this though.
The only thing choice #2B is trying to do is protect against an RFC that
has a big gap in its list of values. Pros are (1) Readability, and (2)
no need to code around a gap for the base implementation. Cons are (1)
Some obvious confusion, (2) building in a small gap in the overall space
for perhaps no good reason.