(I hope HTML is off…) Here’s my concern. Most RFCs assume the target audience is the implementer and this sentence makes it explicit. (Not being said pejorative sense, and, um, no pun intended.) For a large part of the deployment, the code will be pulled off the git-shelf by operators and put into service. The operators will be at the mercy of the developer’s inclusion or exclusion of knobs and meters to configure the code to do the right thing. The idea stuck in the back of my head is ensuring that implementers knowingly include a way for a authorization-to-send policy to be specified (made explicit), even if the policy is “all can see anything.” How about this then: Implementers need to consider the policy and privacy implications of returning information that was not explicitly requested. Servers ought to support means to ensure that any information sent is done in accordance with local policy, including what is found in a search. This is meant to be a reminder within the scope of “other things found while searching.” Local policy is the catch-all used in DNSSEC RFCs to cover anything an operator may elect to do. From: Andy Newton <andy@xxxxxxxx> Date: Tuesday, October 28, 2014 at 9:31 To: Edward Lewis <edward.lewis@xxxxxxxxx> Cc: Scott Hollenbeck <shollenbeck@xxxxxxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, "iesg@xxxxxxxx" <iesg@xxxxxxxx>, "weirds@xxxxxxxx" <weirds@xxxxxxxx> Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration Data Access Protocol Query Format) to Proposed Standard > >On Oct 24, 2014, at 7:03 PM, Edward Lewis <edward.lewis@xxxxxxxxx> wrote: > >> As far as HTML in email, I just don’t care anymore. ;) >> >> If by “public information” you mean information that anyone can access, >> then an anonymous user is explicitly permitted to be sent it. If by >> “anonymous” you mean a user without a proven identity, then any >> information deemed consumable by the general public is explicitly >> permitted to be sent. >> > >It’s the word “explicitly” which is confusing me. How is it “explicit” >that they are permitted access to the information? Are you assuming a >specific authorization scheme or security service? Are you >assuming/imposing some sort of public notification? > >> Just being pedantic. >> >> Perhaps the second sentence is redundant, but I do see a difference >>(which >> may be moot) in placing restrictions on what is sent vs. what can be >> received. > >I agree. There is a difference and that the sentence is redundant. As it >stands I find it adds more confusion and does not really add a useful >benefit. > >-andy > > >> From: Andy Newton <andy@xxxxxxxx> >> Date: Friday, October 24, 2014 at 14:00 >> To: Edward Lewis <edward.lewis@xxxxxxxxx>, "Hollenbeck, Scott" >> <shollenbeck@xxxxxxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, >> "iesg@xxxxxxxx" <iesg@xxxxxxxx> >> Cc: "weirds@xxxxxxxx" <weirds@xxxxxxxx> >> Subject: Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> >> (Registration Data Access Protocol Query Format) to Proposed Standard >> >> >>> I missed this due to all the HTML in the email... >>> >>>>> >>>>> How about this? >>>>> >>>>> OLD: >>>>> "Implementers need to consider the policy and privacy implications of >>>>> returning information that was not explicitly requested." >>>>> >>>>> NEW: >>>>> "Implementers need to consider the policy and privacy implications of >>>>> returning information that was not explicitly requested. Clients >>>>>should >>>>> only receive information that they are explicitly authorized to >>>>> receive." >>>> >>>> AlmostŠ²Servers should only send information that clients are >>>>explicitly >>>> authorized to receive.² >>>> >>>> The way it is worded is impossible to "enforce." >>> >>> How does this work with anonymous access to public information, which >>>is >>> how this information is served today? How do I ³explicitly" authorize >>>an >>> anonymous user? I think the old text above is good enough and find the >>> next text (both versions) to be confusing. >>> >>> -andy
<<attachment: smime.p7s>>