There is nothing ART specific with which I have concerns.

That said, my comments on section 5 and 6 I really think need to be dealt with before I would say this document is "Ready". The other items are strictly editorial:

Section 2:

   *  There are exceptional procedural or legal reasons that force the	
	  target of the normative reference to be an informational or	
	  historical RFC or to be at a lower standards level than the	
	  referring document.
 	      
I think your example needs an example, as I have no idea what one of these procedural and particularly legal reasons might be.

Section 4.1:

															Such	
   decisions should be noted in the document shepherd writeup [RFC4858]	
   so the IESG is aware at the time of its review why the annotation is	
   absent.

I suggest moving this out to the last paragraph of the section and amplify a bit:

   When the document is prepared to submit to the IESG for approval, a
   document shepherd writeup [RFC4858] is normally written. This writeup
   should contain a description of any downrefs that appear in the
   document and should make particular note of any downref that is not
   identified by an annotation in the References section.
   
Section 4.2:

   Such documents are added to the "Downref Registry".
   
I would add "described in section 7."

   This procedure is not to be used if the proper step is to move the	
   document to which the reference is being made into the appropriate	
   category.  It is not intended as an easy way out of normal process.	
   Rather, the procedure is intended for dealing with specific cases	
   where putting particular documents into the required category is	
   problematic and unlikely ever to happen.	

s/category/status/g

Section 5 as written doesn't make sense anymore. First, the downref model doesn't only apply to "published Standards-Track RFCs at lower maturity levels"; it also applies to Informational and Experimental documents. But the rest is simply repetitive with the last paragraph of 4.2. If you need to keep any of the last paragraph of section 5, edit it into the last paragraph of section 4.2, or replace it. Otherwise, I would strike the entire section at this point.

Section 6 seems to be an update or replacement of RFC 2026 section 7. At the very least, a reference in this document is in order and a description of the difference between the two is warranted. I would explicitly call out that this document updates 2026 section 7.