[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dnsext] Re: ASSET and NEGATIVE RRTYPE requests
Andrew and all
Ok, and much clearer thank you. Maybe the RRTYPE conditions
need review, or revision, I'll do my own review of that myself, which
I haven't done in awhile.
Glad to now hear/read that there actually was a review under ASSET.
That wasn't clear before regarding the requester. My understanding
was that the requester did not respond to questions regarding their
request and thus the request was rejected on that basis. So what
was the actual reason the request was rejected after the review, do
you happen to know?
Andrew Sullivan wrote:
> Hi,
>
> On Wed, Dec 17, 2008 at 05:33:01PM -0800, Jeffrey A. Williams wrote:
> > Andrew and all,
> >
> > So than essentially the rejection is due to lack of a review.
> > That's ok, but weak. Perhaps keeping this "On Hold" would
> > have been a better decision?
>
> Do you mean for the case of the request for NEGATIVE, or the request
> for ASSET?
>
> If the former, no, it was not for lack of review, but in fact due to
> an explicit request on the part of the original requester, which came
> out of comments posted by people who had reviewed the request.
>
> If the latter, then it was also not for lack of review; rather, it was
> due to the review uncovering that the request did not meet the
> conditions for RRTYPE assignment under the expert review procedure.
>
> Note that there is no "on hold" status. Because we were early in the
> application of these procedures, and because RFC 5395 had not yet
> actually been published, it seemed ok to me to be a little more
> cautious, which translated into taking longer than the procedures
> officially allow. But the RFC is quite clear that the public comment
> period is between 3 and 6 weeks, after which the expert is supposed to
> render its decision fairly quickly. If the expert does not promptly
> render a decision, IANA is directed to mark the request rejected, so
> the procedure defaults to "no". My note was really just a formal
> recognition of that state of affairs.
>
> There isn't anything that prevents people from submitting a new
> request that is substantially the same, while having addressed the
> remarks.
>
> Also, please remember that the RFC 5395 procedures are supposed to
> be low-barrier RRTYPE assignments for relatively uncontroversial
> cases. If you need an RRTYPE assignment that requires special care,
> unusual rules, or anything of that sort, then the right thing to do is
> RRTYPE assignment by standards action; this requires deeper review,
> because the last call mechanism is used and consensus has to be
> declared. Expert review doesn't depend on those things; on the other
> hand, it is more likely to result in rejection if there is anything
> slightly unusual about the request.
>
> Is that clearer?
>
> A
>
> --
> Andrew Sullivan
> ajs@shinkuro.com
> Shinkuro, Inc.
>
> --
> 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/>
Regards,
Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln
"YES WE CAN!" Barack ( Berry ) Obama
"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt
"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng. INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1@ix.netcom.com
My Phone: 214-244-4827
--
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/>