On 1/2/2014 8:35 AM, Stephen Farrell wrote:
On 01/02/2014 01:26 PM, Scott Brim wrote:
On Jan 2, 2014 8:18 AM, "Stephen Farrell" <stephen.farrell@xxxxxxxxx> wrote:
And so with this one - stating only the high level requirement
is the right thing to do for now
Would it be better to leave this one informational and not make it a BCP?
There's extremely little in it that is Practice. The next level down is
where we would add more specific guidelines and BCPs.
See the quote from 2026 in my response to Dave - what is wrong
with following that and making a statement of principle as a
BCP?
There should be no need for all BCPs to have lots and lots of
detail surely.
And FWIW, I do think it'll be easier to get WGs to properly
consider the attack/threats if this is a BCP.
I also think it'll be cleaner to update as a BCP, if and
when we wanted to add more detail, but that's a minor detail.
The key problem is to get the WG to consider anyway despite any BCP or
document of any status. We should not have to be told what is "right
or wrong" to consider when it comes ethical engineering. We all know
what is "bad" when we see it. Right?
Well, perhaps not. I will use an example with this whole effort to do
the "right thing" when it comes to privacy and security.
Consider the super fast track APPS-DISCUSS WG draft proposed standard
that is currently in LC:
http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-05
This RRVS idea deals with an extremely risky potential concept to
REUSE EMAIL ADDRESSES/IDS. The RRVS proposes an unclear method with
claims it can offer a secured and safe way to allow email hosting
sites the ability to offer reusable email addresses. There are
claims that this is in production mode, yet, there is no means to do
general broad mail network interop testing. There are no interop
reports as far as I can see. However, that are published (google
reseached) reports and concerns for:
- Privacy, Security Leaks and
- (Email) Identity Lost
I will add:
- Increased SPAM that are currently blocked but accepted for
transferred ids.
All that, and I'm accused of bringing "Layer Nine" (whatever that
means) to the table. If so, so be it. I feel I am doing my job
product manager and as a potential implementator of this RRVS proposal.
I believe this is what Stephen Farrell's draft is all about -- to get
people to better consider what are the potential issues. In the case
of RRVS, as it is written as a proposed standard but an experimental
status proposal to be further explored before the IETF accepts and
advocates any idea that has a high potential to leak private, secured
information, a risk for identity lost and reopens SPAM to transferred
targets.
Isn't the purpose of this draft to get people to better engineer IETF
sanctioned protocols in secured, safe ways without hampering progress?
Sure, we all know there is a balance, but some are so obvious such
as this RRVS that it is already filled with "Layer Nine" and as
"conflict of interest" rush to completely track that is mind numbing.
Its become too overwhelming and you risk getting the negative label to
speaking up. The fact is, the concept is good, but it still needs
more work.
So be it.
I guess we can use a strong document to throw at people when they
begin to ignore you. Hopefully, its shouldn't have to come to that
each and every time. Its exhausting.
I vote to make any new document related to better IETF engineering a BCP.
--
HLS