DS> Has the numeric OID actually changed? Robert> Yep. It changed by one.
Oops - missed that. DS> My gut reaction is to wait - stick with what you've got at the moment DS> When this finally appears as an RFC, then *that's* the time to rename DS> the implementation files, etc. Once it's got that far, it's unlikely to DS> change again. Robert> Sounds reasonable. The only reason I asked is that we are rapidly Robert> approaching 5.2. So the question was, should we release the code Robert> with the wrong name. As long as this isn't going to be part of the default build, then I don't see a problem with that. If someone is explicitly turning on experimental code, then they've got to be prepared for things to change subsequently. That's what experimental means. If this was going to be the default configuration, then I'd argue differently, but while the MIB is still in I-Draft, then it feels premature to make that switch. DS> Will the ipNetToPhysicalTable be included by default, or an optional DS> module (to be configured in explicitly) ? Robert> The current cvs is either/or. The --enable-mfd-rewrites would Robert> enable the new modules, and exclude the others. And the default is to use the traditional code - yes? Robert> The plan was then to go back and re-write the os specific portions Robert> of the old tables to use the new data access code. Yup - I should think so too! Having duplicate implementations is fine as an interim measure, but long term, there's no point in keeping both. I'd probably expect that the agent should continue to support the traditional tables as well, for compatibility with existing N/M applications that expect to query for this information. But as long as they all report on the same underlying data, that shouldn't be a significant overhead. Dave ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
