RE: Comments on RADIUS MIB documents - MIB Doctor Review

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

> OK, so no one's interested in discussing this.  :-(

taking offense - I did comment on this actually :-)

> I'm asking that the WG members proactively respond, indicating
> acceptance of the MIB Doctors recommendations, or rejection of the
> recommendations together with a rationale for doing so.  Once we have
> determined consensus on this, then I will be able to issue the next
> draft version. I'd like to keep this task on schedule.

Better prepare a strong argument to reject the MIB Doctor recommendations. It's not that the WG does not have this option, but both the MIB Doctor reviewer and the Area Director came with clear arguments IMO that demonstrated that the path that was taken by the WG creates an interoperability problem between existing implementations of the previous set of RFCs and 2618-2621. 

I am in favor of following the recommendations. 

Regards,

Dan



> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David
> Sent: 05 May, 2005 6:52 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Comments on RADIUS MIB documents - MIB Doctor Review
> 
> 
> > I am forwarding some RADIUS MIB comments to the WG list, with the
> > author's permission.
> > 
> > I'd like to solicit the WG's opinion on structuring of IPv6 address
> > support in the RADIUS MIBs, based on the attached comments.
> 
> OK, so no one's interested in discussing this.  :-(
> 
> The WG chose, during a couple of IETF meetings, to pursue the slightly
> novel approach of augmenting the existing MIB tables with a set of
> IPV4/IPv6 address types, and leaving RFC 2618-2621 untouched, and
> un-deprecated.  There was not much explicit discussion on 
> *why* this was
> the WG's preference.  My personal assumption was that implementers of
> IPv4-only products didn't want to see the existing MIBs obsoleted or
> deprecated, because someone (a customer or a marketing manager) might
> request the successor MIBs to be implemented in the next release.  The
> real reason might be something altogether different, of course.
> 
> In any event, we have expert review comments on the proposed MIBs that
> indicate that this novel augmentation approach is undesirable.  The
> suggestion is to update all of the MIBs, deprecating the tables in RFC
> 2618-2621.
> 
> I'm asking that the WG members proactively respond, indicating
> acceptance of the MIB Doctors recommendations, or rejection of the
> recommendations together with a rationale for doing so.  Once we have
> determined consensus on this, then I will be able to issue the next
> draft version. I'd like to keep this task on schedule.
> 
> Thanks!
> 
> 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>