神明達哉 <jin...@wide.ad.jp> writes: [... lots of agreement snipped; thanks! ...]
>> 3. Query for the child zone's data records, as required by the CSYNC >> record's Type Bit Map field >> >> * Note: if any of the resulting records being queried are not >> authoritative within the child zone but rather in a grandchild >> or deeper, SOA record queries must be made for the >> grandchildren as well. > > The parental agent will first need to identify the name of the > grandchild zone and its server addresses to send this second SOA query by > sending some additional queries, since these addresses (records) may > not be in the parent zone as glue. This might be obvious from the > context, but I think it's worth noting explicitly. > > We might also say the parental agent may (MAY?) just give up the > synchronization attempt if it detects the need for the search in > grandchildren due to the operational complexity. But that's not a > strong opinion; I'd leave it to you. Ok, how about this: 3. Query for the child zone's data records, as required by the CSYNC record's Type Bit Map field * Note: if any of the resulting records being queried are not authoritative within the child zone but rather in a grandchild or deeper, SOA record queries must be made for the grandchildren. This will require the parental agent to determine where the child/grandchild zone cuts occur. Because of the additional operational complexity, parental agents MAY choose not to support this protocol with children making use of records that are authoritative in the grandchildren. (I liked the idea of the MAY) -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop