The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] IANA Considerations for RSVP
Sorry, accidentally narrowed the list. Date: Thu, 23 Jan 2003 12:08:11 -0500 From: Scott W Brim <sbrim@cisco.com> To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: IANA Considerations for RSVP On Wed, Jan 22, 2003 09:40:12PM +0000, Bob Braden allegedly wrote: > 3. The IANA Considerations draft should be published as an RFC, > perhaps after updating. Here are some issues that might affect > this update. All good ideas, but they still don't lead to integration. In ATM you find a (personal opinion) hodgepodge of overlapping capabilities in the signaling IEs because of the lack of strict control and insistence on coordinated engineering. Keep the idea of a separate name space in the back pocket and try for better. Incrementally, perhaps have just one more name class, "non-IETF" and insist on a statement that the group proposing the new extension document how it interacts with existing ones. But, if you're going to do that, you could insist on that documentation and not have the different categories. Whatever you think we can pull off. > Must there be an Internet Draft? An RFC? We have > tended towards the RFC, but the result is less than > satisfactory. These extensions are typically > documented in some 373- page document published (or > more often hidden) by the other standards body. The > I-D/RFC that is written for registration presents only > a superficial summary of the data structures to be > defined, with no context of explanation, and a > reference to the real 373 page document. There must be an RFC, even if status is informational. documentation must be in space that's visible to users of RSVP, and that means publicly visible, not restricted to members of bodies who are requesting the extensions. .Scott |
|