[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Generic Textual Conventions
MIB doctors, I was discussing generic textual conventions with
Keith, and I suggested that possybly we should start an IANA
maintained IANA-GENERIC-TC-MIB module or some such.
Below is a discussion between Keith and myself.
Your comments/reactions/suggestions will be appreciated.
Bert
------------
My initial thoughts were something aka:
> I would make it such that the IANA maintains it, but new TCs can
> only be added after IESG approval (with IETF Last Call included and
> all that). It could be in the form of an I-D that gets through the
> normal process of approval, but once approved, the TC(s) are just
> added to IANA TC MIB module and I-D can expire.
>
> If a TC needs to be deprecated/obsoleted and a new one defined,
> then same process.
>
> This part of the process is part of the initial I-D that we DO
> write and that WILL become a BCP RFC.
>
> Does that not sound workable?
> I guess I need to check it with some more people (MIB doctors and IESG),
> but want to hear you opinion first.
To which Keith responded:
My apologies but it's mainly negative:
It seems to me that the way to evaluate the idea is to compare it
with the existing MIB development/publishing process and determine
whether the differences are justified/beneficial.
So, what are the differences?
- IANA does the MIB editing (or at least the final editing) rather than
a technical person like (you or me)
-- that sounds like a disadvantage; in fact, we'd probably have to do
it for them, and they would just be the middleman (slowing down the
process!).
- IANA does the publishing rather than the RFC-Editor
-- that sounds like a disadvantage; IANA's primary task is assigning
numbers, and assigning a number is a minor part of the process
you describe (and in fact the assignment may be of TC descriptor
names rather than any numbers).
- speed of publishing ??
-- I don't see any reason why the IANA process you describe would
be any faster than publishing an RFC. One of the time-consuming
parts of the current process is getting MIB doctor approval.
Being able to "fast-track" these updates through the MIB doctors
would have a more significant effect on speed than having them
published by IANA rather than the RFC-Editor.
- stability of the spec
-- one of the good things about RFCs is their stability. One can
reference an RFC and know that for all time, that reference will
be good. So, I would prefer to reference a RFC rather than a URL
on IANA's web-site.
- ability to specify an update as just the *new* text, rather than
as a whole MIB
-- I don't think this as beneficial as it sounds: while it does
highlight what is changing, the changes also need to be reviewed
in light of what it is updating (e.g., to make sure it doesn't
conflict or overlap with an existing TC), and unless the insertion
instructions are very precise, there will be ambiguity as to the
exact changes; certainly, a review of the final update will be
needed (somewhat like the "48 hour" review before RFCs are
published).
- ability to coordinate mulitple changes at the same time
-- there is a possibility that second and subsequent changes will be
requested even before a previous change has completed the
update/review/publish cycle. Perhaps, IANA would queue the
second and subsequent until the first cycle is complete, and
then start another cycle incorporating all outstanding changes,
but their role here would be in effect a coordinating authority.
- accountability
-- it's not clear whether IANA would do a better job than some
volunteer editor, but being an official duty rather than a
volunteer effort would make it more accountable.
So, I don't see why IANA is the right organization to take on this new
task which seems to me to consist largely of two tasks: coordinating
and publishing. I think that being able to "fast-track" these updates
through the MIB doctors would effect the speed more significantly
than having them published by IANA rather than the RFC-Editor.
Keith.