BIND 10 #1078: Update RESLIB/RESOLVER message descriptions

[BIND 10 Development]

#1078: Update RESLIB/RESOLVER message descriptions
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110712
                   Priority:  minor  |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => UnAssigned
 * status:  assigned => reviewing


Comment:

 Note that the message IDs were updated in a previous ticket: the updated
 message ID is given where relevant.

 > some string formating have brackets... use %1 or <%1> ? or is that for a
 "tuple" only?
 Message have been altered so that the "<>" form is only used for a
 name/class/type tuple.

 > RESLIB_TESTSERV says conflicting debugging and not debug and " As it
 should never be seen in normal operation, it is a warning message instead
 of a debug message." is too verbose, not needed here
 Altered.

 > RESLIB_TIMEOUT error will be reported where?
 Altered.  It now just says that the query has timed out.

 > RESOLVER_AXFRTCP says "AXFR request" and "received a NOTIFY" and
 RESOLVER_AXFRUDP says "AXFR request" and "received a NOTIFY" -- well which
 is it? (a NOTIFY is a hint to do an SOA serial check)
 Now RESOLVER_AXFR_TCP and RESOLVER_AXFR_UDP, the description has been
 altered.

 > RESOLVER_CLTMOSMALL does BIND 10 fail to start? then what is used?
 default? minimum?
 Now RESOLVER_CLIENT_TIME_SMALL, the check only occurs when the
 configuration is being updated.  On error, the update is rejected.  The
 description haas been changed and similar text changes have been applied
 to the messages "query timeout too small" and "lookup timeout too small".

 > RESOLVER_CLTMOSMALL is there a corresponding too large?
 The code does not check for too large a value.

 > Can RESOLVER_CONFIGERR be separated into programmer error and user error
 with different log ID? Should it say to file a bug report?
 Ticket #1094 has been raised for this.

 > style: some have incomplete / poor grammar for saying it is a debug
 message while some have complete separate sentence for that.
 The text has been changed.

 > RESOLVER_DNSMSGSENT what details?
 Now RESOLVER_DNS_MESSAGE_SENT, the description should indicate what is
 being sent.

 > RESOLVER_FAILED does this means that b10-resolver process will end?
 Yes - this has been made clear in the message description.

 > RESOLVER_FWDADDR why could it appear multiple times?
 Now RESOLVER_FORWARD_ADDRESS, the description has been changed to clarify
 the point.

 > RESOLVER_FWDQUERY what checks?
 Now RESOLVER_FORWARD_QUERY, some of the checks are listed in the
 description.

 > RESOLVER_LKTMOSMALL does BIND 10 fail to start? Or what does it use? The
 default? minimum?
 > RESOLVER_LKTMOSMALL is there a too large too?
 Now RESOLVER_LOOKUP_TIME_SMALL.  See comments for
 RESOLVER_CLIENT_TIME_SMALL.

 > RESOLVER_NFYNOTAUTH how to correspond this to the sender of the message?
 (log that too?)
 Now RESOLVER_NOTIFY_RECEIVED.  Ticket #1095 has been created to cover
 this.

 > RESOLVER_NORMQUERY what checks?
 Now RESOLVER_NORMAL_QUERY.  Description has been updated.

 > RESOLVER_NOROOTADDR add more details? Should this really be a warning?
 (isn't it just informational and normal?)
 Now RESOLVER_NO_ROOT_ADDRESS.  Not certain about this; it appears to be
 generated if "root_addresses" appears in the configuration but there are
 no addresses associated with the item.  In that case, if the resolver can
 proceed by getting the addresses from elsewhere, this is rightly a
 warning.

 > RESOLVER_NOTIN why can't handle other classes in a query? (And
 description should say this is a query?)
 Now RESOLVER_NON_IN_PACKET.  At present, the resolver only handles queries
 for the IN class (as well as the
 CH query for version.bind).

 > RESOLVER_NOTONEQUES typo: "entires"? (entries?) (while I don't recall
 seeing it, where is it documented one question is limit? even RFC 1035
 hints multiple questions could be asked.)
 Typos corrected.  As to multiple questions, I'm not sure that it is
 documented anywhere.  I've looked and the closest I could get was a
 mention in http://www.ietf.org/proceedings/42/I-D/draft-ietf-dnsind-
 edns-03.txt

 > RESOLVER_QUTMOSMALL should it show the minimum? does BIND 10 fail to
 start? Or does it use default? or minimum?
 > RESOLVER_QUTMOSMALL is there a corresponding too large error? (but maybe
 the existing ID should be for both: out of range.)
 Now RESOLVER_QUERY_TIME_SMALL, see comment for RESOLVER_CLIENT_TIME_SMALL.

 > RESOLVER_RECVMSG description say "DNS"?
 Now RESOLVER_DNS_MESSAGE_RECEIVED.

 > RESOLVER_ROOTADDR why multiple times?
 Issued once per root address.  The message ID is now
 RESOLVER_SET_ROOT_ADDRESS and the description explains why it is issued
 multiple times.

 > RESOLVER_SETPARAM "interval to resolver" and "continuing to resolver"
 should be "resolve"? Too many colons? "resolve gives up" should be
 "resolver"?
 Now RESOLVER_SET_PARAMS.  Typos corrected.

 > Maybe this description is way too long -- two paragraphs is too long?
 I don't think there is any lenght that is too long or too short - it
 depends on the message.  In this case, unless the timeouts are documented
 elsewhere and we can refer to that documentation, the explanation is OK
 here.


 > RESOLVER_SHUTDOWN, RESOLVER_STARTED are too noisy for default logging?
 should be debug mode only?
 See previous comment.

 > RESOLVER_STARTING description should mention command line arguments?
 It does.

 > RESOLVER_UNEXRESP not enough information? so response doesn't match up
 with an existing outbound query (wrong port, address, name, class)?
 Now RESOLVER_UNEXPECTED_RESPONSE.  The description has been updated to
 explain that the resolver had received a response packet on the port on
 which it is listening for queries.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1078#comment:3>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development