Ted Lemon <[email protected]> writes: > (I realize that I took a while responding as well; this isn't intended > to imply a criticism, but I figured I should let you know.)
Not a problem. It's not like I can talk! >> *** NOFIX Point 3-- >> >> I don't think you've specifically excluded RRtypes not mentioned in >> section >> 3.2. It's seems obvious to me based on what's stated in section 2 that >> the >> intention of the document is to only support these two RRtypes, but I >> think it >> is necessary to say so explicitly, if that is in fact what is intended. >> If >> something else is intended, text explaining what is intended should be >> added. >> E.g., if it's okay for cooperating child name servers to set bits not >> listed >> here, and for cooperating parent name servers to process them, you should >> say >> so. >> >> WJH: This is stated, and I think you missed it. Section >> 2.1.1.2.1 (about the type bit map field) states (slightly >> different based on a comment from Stephen, who did see it): >> >> Specifically: a parental agent must not just copy the data >> and must understand the semantics associated with an bit in >> the Type Bit Map field that has been set to 1. >> >> Let me know if you think this is insufficient. > > Again, recollection is foggy, but e.g. what if some implementation > decides it would be clever to use child synchronization to update DS > records? You say in the introduction that this document isn't > supposed to support doing that, but you don't explicitly exclude DS > records anywhere. This concern is (IIRC) what triggered the comment. Due to some other comments, the following text was put into place and is already in my (not yet published) document. This exists in the security considerations: Thus, implementations of this protocol MUST NOT use it to synchronize DS records, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records. Similarly, future documents extending this protocol MUST NOT offer the ability to synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records. For such a solution, please see the complimentary solution [RFC7344] for maintaining security delegation information. Does this (end-of-a) paragraph solve your problem? -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
