I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

My only concern about the security considerations section is related to self-references necessary in the responses to cache results.  Is it possible to create a poisoned cache based on the self-reference?  What should a client do in order to protect itself from such an attack.

Otherwise, the security considerations for this draft are adequate in my opinion, although I will state that the vast majority of the security considerations are actually included by reference.  (I would have more comments about the submitted weirds security considerations not being adequate than what is stated in this draft.)  I would like to see the privacy section mentioned in the security considerations section and possibly referenced from the security considerations section.  

After reading the draft, it is my view that this draft primarily describes the data models to return weirds queries and nothing in this data model *appears* to change any current practice with regards to privacy.

GENERAL COMMENTS:

Caching was mentioned once or twice, but not particularly described in the draft.  I believe that topic should be covered more or removed.

I found the text overall reasonably well written, but without any motivating text to the descriptions.  Additionally, the examples dominate the text and tracing JSON nesting between "[" and "{" for multiple pages is quite difficult.


NITS:

Section 1.2:  
	". . . is specified in four sections:"  followed by a numbered list of 5 items.
	
	"A response to a search for multiple
   objects yields a JSON object that contains an array of JSON objects
   that are the subject of the search" =>  subject should be "subjects"
   
Example starting on page 18:
	On page 20 it states that the example has status, port43, networks, and autnums.  I don't see those in the example.
	
	
Section 10.2.1
	#2 & #5 are duplicates.
	#3 & #6 differ only in the statement about trying again later.  (Permanent vs. transient failure message?  Maybe permanent/transient could be included in the "Value:" field.)
	


--
Chris Inacio
inacio at cert.org