RE: Generic Textual Conventions

["Harrington, David" <dbh@enterasys.com>]

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?

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.
> 
> 
>