At 05:47 14-10-2013, Tony Rutkowski wrote:
Most users make their choice of provider
and platform based on factors such as:
cost, performance, ease of use, SPAM
and malware reduction, image (i.e.,
account/domain name), mobility,
identity theft mitigation, familiarity,
and social feature sets. Like credit
card fraud protection, some of those
features require a lot of invasive knowledge.
Fortunately, there are a lot of providers
competing in the marketplace.
I could do a study to find out which provider is popular in the
IETF. The result would probably be gmail.com. There aren't that
many providers competing in the marketplace. It is difficult to
compete when most users want a free service. For what it is worth,
there hasn't been any noticeable shift in providers used by IETF participants.
So as many have opined, the IETF is a
technical standards body, not an evangelical
organization for socio-political views, and
hopefully will continue to do what it
does well - produce usable protocols - and
leave the implementation choices to others
based on their assessment of the risk.
If the IETF is a technical standards body it should not discuss about
privacy in its specifications. That would not go down well in
practice as other bodies will point out that the IETF is designing
standards without any thought to how it affects the users.
Security considerations are mandatory for IETF specifications. I
gather that there would be some guidance in that section so that
people making implementation choices can assess the risks.
The topic in the subject line is about mandatory-to-implement. If
the feature is not available in an implementation the user has less
choices. The default setting also matters. If a feature is off by
default the average user won't turn it on. Note that some
implementations usually make that choice based on feedback from the
users. As an example, if the key length chosen by the user is
considered as insecure, the implementation might generate a warning
or exit with an error message.
Regards,
-sm
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
