神明達哉 <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

Reply via email to