[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Generic Textual Conventions
> Hi,
>
> I agree with Keith on all points. I'll be interested to see
> the original arguments.
> What were the goals you were trying to achieve with the IANA proposal?
>
Far too often I see people do very generic TCs in technology or protocol
specific MIB modules. Look for a definition of Milliseconds as an example.
So I tell these people that I like them to prefix their TC names with
the mpodulename. For example SspmMicroSeconds in SSPM mib..
Of course that is kind of strange too, because it is really a generic TC,
but for such a generic TC, I would like to see them in one place. We do not
want everyone who wants to use the geenric MicroSeconds TC to have to depend
on the advancement of the SSPM MIB.
If we were to do a generic TC MIB document that gets updated all the time,
then it will stay at PS and so docs who import have a tough time to advance.
So I thought... let us make then IANA-GENERIC-TC-MIB items, which is
(maybe a bit sneaky) bypass when it comes to normative references for
DS and STD docs.
Anyway, those were my considerations.
We might also be able to do a BCP that we keep updating.
I think that DS and STD can depend (normative) on a BCP.
I bet some of you will say/think: STUPID CRLs...
Oh well... we can continue to wait if NEWTRK will resolve any of this.
I doubt it, but in any event it will take at least another year I suspect.
> Dbh
>
>
> > -----Original Message-----
> > From: owner-mreview@ops.ietf.org
> > [mailto:owner-mreview@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> > Sent: Tuesday, April 06, 2004 8:14 AM
> > To: Mreview (E-mail)
> > Cc: Keith McCloghrie (E-mail)
> > Subject: 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.
> >
> >
> >
>