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 pselkirk):

 Replying to [comment:14 jinmei]:
 > '''rrsig_46.cc'''
 >
 > - I'm not sure if we want to allow "1H" etc for the original TTL
 >   field:
 >
 >   At least BIND 9 doesn't allow this form for this field.  See
 >   https://bugs.isc.org/Ticket/Display.html?id=33305
 >   I'm personally inclined to follow BIND 9, whether it was an
 >   intentional decision, although this is probably too minor and can be
 >   implementation specific.  In either case we need some more
 >   documentation: if we don't allow it, explain it and it's different
 >   from, e.g., SOA and explain the rationale; if we allow it, explain
 >   it's different from BIND 9, explain why (and also update
 >   doc/differences.txt).

 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.

 > - 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".

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

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