Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt

Hi,
Thanks for comments.
This draft intends to specify the common response format. So we put more
focus on the technical part. In this version, just a brief paragraph before
section 3.1 is provided related to policy.
Having read the policy & tech thread, IMHO, both the authentication
mechanism and policy making will affect the query and response drafts. The
authentication mechanism supplies the technical solution, and policy
decisions raise the specific requirements. Until now ,at least I am not
quite clear about the authentication mechanism that will be adopted and the
specific requirements for differential classes of service. 
So, I think the above work should be done in parallel, in which way, the
protocol could be improved better.
We have done some research wok on authentication, but need more help and
contribution from experts on web authentication and security. We also
welcome more comments from policy experts, providing some specific
requirements for the draft.

Thanks & regards,
Linlin Zhou
CNNIC

> -----Original Message-----
> From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf
Of
> Andrew Sullivan
> Sent: Tuesday, June 12, 2012 10:42 PM
> To: weirds@ietf.org
> Subject: Re: [weirds] FW: I-D Action:
draft-kong-dnrd-ap-response-json-00.txt
> 
> On Tue, Jun 12, 2012 at 10:04:55PM +0800, Ning Kong wrote:
> 
> > I think you put forward a general issue. IMO, the HTTP draft
> > (draft-designteam-weirds-using-http-00) as the common infrastructure
> > document is suitable to cover this point. For example, a new section
(e.g.
> > 5.5 Unauthorized Answers) may be added to propose the corresponding
> > response mechanisms.
> 
> This raises an interesting and vexing issue, I think.
> 
> As we're working now, we are talking about responses and requests.
> But in a REST context, it seems to me, you either get the resource or you
don't.
> 
> One of the goals so far has been to permit differential levels of service
> depending on credentials.  (I believe quite strongly that if we do not
provide
> that functionality, we will have completely botched this work.)
> 
> It seems to me therefore that data we return must be much more linked and
> much less cohesive.  For instance, in the present draft, the response for
> domains includes contact data, nameserver data, and so on.  But instead,
> that all ought to be linked data, so that it is possible to return the
appropriate
> response (e.g. the data vs. http
> 401 or 403 errors) depending on who asks for it.  It seems also that it
might
> be possible to create a roll-up type resource that provides all the
answers in
> one go, at the cost of authorization being the denied if any of the
underlying
> resource permissions aren't available.
> 
> Thoughts?
> 
> Best,
> 
> A
> 
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds