[Gen-art] Re: LC Review: draft-ietf-disman-remops-mib-v2-09.txt

"Joel M. Halpern" <joel@stevecrocker.com> Wed, 15 March 2006 00:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJne-00024D-GS; Tue, 14 Mar 2006 19:23:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJnc-000245-Vn; Tue, 14 Mar 2006 19:23:36 -0500
Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJJnb-0003UB-O5; Tue, 14 Mar 2006 19:23:36 -0500
Received: from user-2ivf91m.dsl.mindspring.com ([165.247.164.54] helo=JMHLap3.stevecrocker.com) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FJJnT-0001gG-00; Tue, 14 Mar 2006 19:23:28 -0500
Message-Id: <7.0.1.0.0.20060314191951.032f1038@stevecrocker.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 14 Mar 2006 19:23:23 -0500
To: Juergen Quittek <quittek@netlab.nec.de>, Mary Barnes <mary.barnes@nortel.com>, gen-art@ietf.org
From: "Joel M. Halpern" <joel@stevecrocker.com>
In-Reply-To: <69669820960C84F7A53340CC@[192.168.1.128]>
References: <E3F9D87C63E2774390FE67C924EC99BB0AB3D6E8@zrc2hxm1.corp.nortel.com> <7.0.1.0.0.20060306171715.0329f8c0@stevecrocker.com> <69669820960C84F7A53340CC@[192.168.1.128]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, Bert Wijnen <bwijnen@lucent.com>, disman@ietf.org, quittek@ccrle.nec.de
Subject: [Gen-art] Re: LC Review: draft-ietf-disman-remops-mib-v2-09.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

(Not copying the agreements...)

This is progress.  I actually was not clear reading the MIB whether 
the local lookup or the DNS lookup was expected.
Something similar needs to be done to the earlier references to 
gethostbyName() etc.
A little bit of text about the number->name direction would also be 
helpful, to explain why that is needed here.

Yours,
Joel

At 07:10 PM 3/14/2006, Juergen Quittek wrote:
>>If the intent is explicitly to cause local caching / config tables to be
>>visible to the MIB, then we MUST say that.  If the intent is to perform a DNS
>>lookup from that host (forward or reverse) then we need to say that.
>
>As stated above, my view is that the MIB module should return whatever an
>application would receive.  This should be clarified in section 3.3.3.
>What about
>
>OLD:
>3.3.3.  lookupResultsTable
>
>   The lookupResultsTable is used to store the results of lookup
>   operations.  The lookupResultsTable is initially indexed by the same
>   index elements that the lookupCtlTable contains (lookupCtlOwnerIndex
>   and lookupCtlOperationName) but has a third index element,
>   lookupResultsIndex (Unsigned32 textual convention), in order to
>   associate multiple results with the same lookupCtlEntry.
>
>NEW:
>3.3.3.  lookupResultsTable
>
>   The lookupResultsTable is used to store the results of lookup
>   operations.  Results to be reported here SHOULD be results of
>   a lookup function that is commonly used by applications at the
>   managed node. This implies that results are not necessarily
>   consistent with the results of a pure DNS lookup at the
>   managed node, but may be influenced by local lookup tables or
>   other source of information, depending on the configuration of
>   the managed node.
>
>   The lookupResultsTable is initially indexed by the same
>   index elements that the lookupCtlTable contains (lookupCtlOwnerIndex
>   and lookupCtlOperationName) but has a third index element,
>   lookupResultsIndex (Unsigned32 textual convention), in order to
>   associate multiple results with the same lookupCtlEntry.
>
>?


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art