ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-weirds-rdap-query-15.txt> (Registration Data Access Protocol Query Format) to Proposed Standard

2014-10-28 10:35:03
(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(_at_)arin(_dot_)net>
Date:  Tuesday, October 28, 2014 at 9:31
To:  Edward Lewis <edward(_dot_)lewis(_at_)icann(_dot_)org>
Cc:  Scott Hollenbeck <shollenbeck(_at_)verisign(_dot_)com>, 
"ietf(_at_)ietf(_dot_)org"
<ietf(_at_)ietf(_dot_)org>, "iesg(_at_)ietf(_dot_)org" 
<iesg(_at_)ietf(_dot_)org>, "weirds(_at_)ietf(_dot_)org"
<weirds(_at_)ietf(_dot_)org>
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(_dot_)lewis(_at_)icann(_dot_)org> 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(_at_)arin(_dot_)net>
Date:  Friday, October 24, 2014 at 14:00
To:  Edward Lewis <edward(_dot_)lewis(_at_)icann(_dot_)org>, "Hollenbeck, 
Scott"
<shollenbeck(_at_)verisign(_dot_)com>, "ietf(_at_)ietf(_dot_)org" 
<ietf(_at_)ietf(_dot_)org>,
"iesg(_at_)ietf(_dot_)org" <iesg(_at_)ietf(_dot_)org>
Cc:  "weirds(_at_)ietf(_dot_)org" <weirds(_at_)ietf(_dot_)org>
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
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>