Re: Q-03: inclusion of KEY records in additional records section

[Ólafur Guðmundsson <ogud@ogud.com>]

<DS editor hat on>
After reading all the postings on this it is not clear to me what
the working group wants.

As far as I can tell there are 3 options have been put forward,
to replace the RFC2535 rules (that do not make sense anymore).
It is not clear if anyone of the proposals has a significantly more
following than the other two.
Listed below in order of frequency of inclusion of KEY RRset
in additional section:
	1. Always include covering KEY
	2. Include covering KEY on referral only
	3. Never

Please express preference on which rule to pick, and why.

If rule 1 or 2 is selected we need to set rules about inclusion order.
Current RFC2535 rules say address glue has higher priority than KEY, this
is a good rule. The open issue is do we need to specify in what order
multiple KEY RRsets are included?
	Example: QNAME: com. QTYPE: NS
	Answer section:  NS set signed by com.
	Additional section: glue addresses signed by gtld-servers.net.

Should inability to include one or both of the KEY RRsets cause the
TC bit to be set ? (RFC2535 said no)

	Olafur 

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>