Re: [dnsext] draft-ietf-dnsext-dnssec-algo-signal-07.txt

On 17 jul 2012, at 19:11, Paul Hoffman wrote:

>> I don't think we have enough information to say one way or the other,
> 
> We disagree, strongly. Until you can show that more than a small fraction of the users of this will have a preference, saying that all of them need to have a preference in order to express it in a list adds a layer of complexity that you cannot show has any value.
> 
>> and the perfect is the enemy of the good.  
> 
> Thats a convenient way of saying "I don't know, but I liked this feature before, so let's leave it in". Some of us prefer not to add superfluous features and would use different trite saying to back our opinions.

Paul, I understand your issue and as one person that was part of the design of NAPTR, user of it, confused user, I completely understand the headache users might get that you talk about. But, while I might have headache over the weight and preference in for example NAPTR, I know people that do use it.

So, let me ask you:

Is this existence of this parameter for you a blocking factor for this document?

I do not mind if you expand a bit because I must as shepherd of this document understand whether what you feel is something that still is in the rough part of rough consensus, and if so that your view should be paused until there is IETF last call and your input goes to IESG.

I can understand if you see these kind of parameters in DNS "go away", but so far we have sort of used them in many RR Types, and maybe what you ask for is a generic change in how we design new RR Types. But the question is whether *THIS* document should be where we take that step on "generic design decisions".

   Patrik

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext