FW: Initial review of draft-nelson-rfc2618bis-00.txt

["David B Harrington" <ietfdbh@comcast.net>]

Hi,

Here is the advice I gave to David Nelson about the design of the
RADEXT MIB modules.
I haven't reviewed the current documents to see how they have been
done.
Feel free to correct my recommendation and to make alternative
recommendations.

David Harrington
dbharrington@comcast.net



> -----Original Message-----
> From: David B Harrington [mailto:ietfdbh@comcast.net] 
> Sent: Wednesday, February 02, 2005 5:36 PM
> To: 'Nelson, David'
> Subject: RE: Initial review of draft-nelson-rfc2618bis-00.txt
> 
> Hi,
> 
> See draft-ietf-mib-review-guidelines-04.txt for the latest 
> collection of CLRs - "crappy little rules" - oh excuse me, I 
> meant to say "clarifying language rules".
> 
> I haven't written any modules that augmented another table, 
> so I'm not sure how the OID and names are handled. I'll need 
> to look around for examples and guidelines. I would expect 
> that you simply IMPORT xxxTable and xxxEntry and then add 
> objects to the entry, but I'm not certain.
> 
> You may have trouble getting this approach past the IESG if 
> you don't deprecate the IPAddress objects. 
> I suggest adding the new objects and deprecating the 
> IPAddress objects.
> 
> If you use AUGMENTS, there should be a one-to-one 
> correspondence between the base table and the augmenting 
> columns. If the relationship is sparse, i.e. only applies to 
> some of the rows, then you should use an INDEX clause that 
> matches the base table. See mib-guidelines section 4.6.4.
> 
> So adding the InetAddress objects only for IPv6-addressable 
> servers and keeping the IPAddress objects for IPv4 servers 
> means you'd probably have a sparse relationship. 
> 
> Since InetAddress could provide both the IPv4 and IPv6 
> addresses (and is extensibile if new IP versions comes along) 
> I think you'll have trouble justifying keeping the IPv4-only 
> objects since they are defined using a data type that is NOT 
> RECOMMENDED. Implementors can always keep them for backwards 
> compatibility purposes if the IPAddress objects are deprecated.
> 
> I suggest that the MODULE-IDENTITY be assigned to {mib-2 TBA} 
> and then define notifications (0), objects(1), and 
> compliances(2) under that. See appendices in the mib 
> guidelines. I may change that opinion depending on how 
> augmenting modules should be handled, but that would be my 
> advice at this time.
> 
> The MODULE-IDENTITY revision says "initial version as 
> published in RFC2618" If this is an augments rather than an 
> update, I think that would be incorrect. It would only be 
> correct if this document included the initial definitions here.
> 
> radiusAuthServerEntryExt has the same OID as radiusAuthServerEntry
> I think convention recommends that Entry be on the end of the 
> word, so radiusAuthServerExtEntry and 
> radiusAuthServerExtTable. Compilers may complain if you don't 
> follow the convention.
> 
> You will need a section that describes the relationship to 
> other mibs, especially 2618.
> 
> How's that for a starter?
> 
> David Harrington
> dbharrington@comcast.net
> 
> 
> 
> 
> > -----Original Message-----
> > From: Nelson, David [mailto:dnelson@enterasys.com] 
> > Sent: Wednesday, February 02, 2005 4:30 PM
> > To: ietfdbh@comcast.net
> > Subject: Initial review of draft-nelson-rfc2618bis-00.txt
> > 
> > Dave,
> > 
> > I think I've mastered the basic mechanics of Cooktop (XML 
> Editor) and
> > XML2RFC (TCL script), and have produced a first version of 
> one of the
> > RADIUS Update MIB I-Ds.  The consensus of the WG was to go the
> > "AUGMENTS" route, rather that recycling the base RFCs (2618-21).
> > 
> > Attached is 2618bis.  I'm aware that there are typos, and
formatting
> > issues.  What I'd like to ask of you now is an initial read 
> of whether
> > the structure is correct.  Am I going down the right path?  
> Once I get
> > one of these correct, I believe the other three will be "step and
> > repeat", so to speak.
> > 
> > BTW, the default behavior of XML2RFC of starting a new page for
each
> > top-level section number is rather annoying!  Any ideas on that?
> > 
> > Regards,
> >  
> > Dave
> >  
> > David B. Nelson
> > Enterasys Networks, Inc.
> > 50 Minuteman Road
> > Andover, MA 01810-1008
> > Phone: (978) 684-1330  
> > E-mail: dnelson@enterasys.com
> >