BIND 10 #2521: support generic version of rdata::createRdata(text) in RRSIG, DHCID, OPT RDATA

[BIND 10 Development]

#2521: support generic version of rdata::createRdata(text) in RRSIG, DHCID, OPT
RDATA
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  pselkirk
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130423
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:17 pselkirk]:

 > > - I'm not sure if we want to allow "1H" etc for the original TTL
 > >   field:

 > I don't see anything in RFC 4034 or 4035 that constrains the
 presentation format of the Original TTL field.
 >
 > I know Mark doesn't consider it a bug in BIND 9, but I don't know why
 the decision was made, so I wouldn't be able to explain it beyond "it's
 what BIND 9 does".
 >
 > My instinct is to say "it's a TTL field, treat it like any other TTL
 field". But it's practically moot, given that (as you said) the RR is
 generated by a tool, and all the tools express Original TTL in seconds.

 I'd leave it to you, as long as it's documented and tested.

 > > - For documentation, I'd also refer to RFC4034, saying the allowed
 > >   format basically conforms to the RFC.
 >
 > I'm not sure what you mean by "basically conforms".

 Maybe basically was redundant or confusing.  I just meant the
 implementation should accept the text representation described in
 RFC4034 (and "basically" only that representation).

 > Also, should the documentation for each Rdata class reference the RFC
 that it implements? Only about a third of them do.

 I think it's okay to be case-by-case basis.  In the case of RRSIG, I
 thought it's more convenient to just refer to the RFC than repeating
 the description of each field ourselves.  In other simpler RDATA, e.g,
 NS, it wouldn't matter much.

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