[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>
From: Ray.Bellis@nominet.org.uk
Date: Fri, 26 Feb 2010 10:14:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1267179297; x=1298715297; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[ietf -provreg]=20draft-gould-rfc4310bis-06.txt=20Submitted=20f or=20Review|Date:=20Fri,=2026=20Feb=202010=2010:14:55=20+ 0000|Message-ID:=20<OFFF4D1C80.209E83D8-ON802576D6.003746 35-802576D6.00384C63@nominet.org.uk>|To:=20James=20Gould =20<jgould@verisign.com>|Cc:=20EPP=20Provreg=20<ietf-prov reg@cafax.se>|MIME-Version:=201.0|In-Reply-To:=20<C7AC7B8 8.37B22%jgould@verisign.com>|References:=20<C79AE64E.3762 0%jgould@verisign.com>=20<C7AC7B88.37B22%jgould@verisign. com>; bh=uKruY112f7KPN35H/A+0cKkURQ3sATNVg4E/3gHBcsc=; b=C3Tw9Z5Qg36sVXs+gnp3rbuB9N+gVUDaWzYcp9JOb0+3VLRaTR89nDmm O1uxFJH2aeTjyj7Ri5VuDHjZTYAZPUq1Ch40wsu0ofkKIZdmNToFgZrOU VJXMAydHDB/nkgq;
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=Z2J1K267LllFC/PYJBM3mYfofnZeqBZXg6ZB0LsnS65ydYLoBeDzBh78 sMbcg0SO/1kNjc56u+Ac8oKkxphU73h+X8/O5poUSC+y+V3Zz59IK36s0 jHjDBDtUsf+IlOp;
In-Reply-To: <C7AC7B88.37B22%jgould@verisign.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review


> I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt
> which includes the feedback that I received so far and will be the
> basis for the IESG review.  Please let me know if you have any
> feedback to the latest draft.

Not being an EPP guru, what's the rationale for requiring a 2102 error if the server doesn't support <secDNS:update urgent="1"> or <secDNS:maxSigLife> ?

I would have thought that Postel's law should apply, otherwise a registrar has to have advance knowledge of which registries support those elements and which don't, and alter their submitted XML accordingly.  I can't immediately see how any harm would come from simply ignoring those elements.

Also, I note that §4 says that a server MUST support either <secDNS:dsData> or <secDNS:keyData>, but not both (unless in transition from one to the other).  However I can find no guidance on what should happen if the client sends the wrong one.  The schema is clear that it's a choice, but that only affects individual messages, and doesn't reflect the server's capabilities.  

BTW, §10 (Acknowledgements) says that this doc _updates_ 4310 and refers readers to that document's acknowledgements section, whereas elsewhere it's clear that it obsoletes it.  There's also an informative reference to 4310.  I don't believe it's permitted to both obsolete a document and refer to it at the same time.

kind regards,

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
Home | Date list | Subject list