Re: Re: MIB Doctor review: publish draft-ietf-disman-remops-mib-v2-06.txt

Juergen Quittek <[email protected]> Mon, 12 Dec 2005 04:09:26 +0100
Newsgroups gmane.ietf.disman
Message-ID <C6D6820CBFD4A748369267F4@[192.168.1.129]>
Dear all,

Below please find the outcome of the discussion I had with
MIB doctor Juergen Schoenwaelder on the remops MIB modules:

--On 08.11.2005 18:10 Uhr +0100 Juergen Quittek wrote:

> Dear all,
>
> One IETF meeting ago, I promised a follow-up of the
> message below for finalizing the discussion of remops
> issues that Juergen Schoenwaelder raised in the MIB
> doctor review.
>
> I am very sorry for delaying this follow-up until today!
>
> After reviewing again all issues that Juergen S. raised,
> I found only two non-editorial issues that are still open:
>
> 1. Referring to the hostent structure
>
>>  I am not sure the hostent structure is really needed to say that a
>>  host may have multiple interfaces (IP addresses) and that multiple
>>  names may be given to the same interface (IP address). (The
>>  motivation is again to remove IPv4 only API specifics which may
>>  mislead implementors.)
>
> I agree on this comment addressing the section 3.3.3 on the
> lookupResultsTable.  This section needs to be re-written in order
> to become independent of the IP version.

Please find a suggestion for a new section 3.3.3 lookupResultsTable
in the diff between the last version (-06) and the current draft of
version -07 at

  <ftp://ftp.netlab.nec.de/pub/internet-drafts/diff-06-07.html>.

Also there please find some further changes concerning the generalization
of references to functions gethostbyname() and gethostbyaddr() in
  - section 1.3 Lookup
  - the beginning of section 3. Structure of the MIBs
  - the last paragraph of section 3.3.2 lookupCtlTable
  - object definition of lookupCtlTable
  - object definition of lookupCtlEntry
  - object definition of lookupCtlTargetAddressType
  - object definition of lookupResultsTable

> 2. pingCtlRowStatus in the minimum compliance statement?
>
>>  Is there a rationale why pingCtlRowStatus is not required in the
>>  minimum compliance statement? As it stands, I can have an
>>  implementation which supports the volatile(2) storage type but I am
>>  kind of left alone how to create entries. Please explain what the
>>  goal was you were trying to achieve with this construction.

Juergen's concern about a conflict between pingCtlRowStatus and
pingCtlStorageType does not apply here. Both objects are independent
from each other.

We further discussed whether it makes sense or not to have pingCtlRowStatus
not required in the minimum compliance statement.  The semantics of
pingCtlRowStatus restrict the use of setting this object to creating
and deleting rows.  Activating rows is performed by setting object
pingCtlAdminStatus.  So there is no need for a minimum implementation
to support this object.

The conclusion would be to keep this object and the corresponding compliance
statements as they are.

    Juergen Q.
-- 
Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de