On Wed, 21 Nov 2001, Dan Grossman wrote:
> Once again we get to the I-D deadline and once again there are concerns that
> need to be addressed.
well, yes.
I've sent off my usual long list of mostly-minor editing nits on -07
to Phil (Date: Wed, 21 Nov 2001 19:48:36 +0000 (GMT) 8K of text) -
this long draft took several hours to read and comment on, I struggled
to find the time today, and if my herculean polishing efforts aren't
taken into account in the limited remaining time while Phil and Dan
battle it out I'll be slightly peeved.
This last-minute stuff and compressing all editing/revision/peer
review of changes to a WG draft as close as possible to the submission
deadline really isn't fun for supposedly-involved listed contributors
like Dan and me. Earlier availability of Phil's -07 draft would have
been helpful.
and the worst thing is, I could see all this coming. I predicted to
the chairs, like, WEEKS ago that all this would happen. I must be,
like, _psychic_ or something.
> Generally it is fair to say that mechanisms that are not bundled with the
> dominant operating system and/or browsers and/or web servers and/or mail
> clients cannot be said to be broadly deployed (sorry PGP, SSH and IPSEC).
It's only fair to the vendor of the dominant operating system to say
that.
(I understand Windows XP has IPSec bundled.
Might not be enabled by default, mind.)
These mechanisms are widely deployed. Multiple implementations. Freely
available.
> Nonetheless, end-to-end security mechanisms are not used as widely as
> might be desired. However, the group could not reach consensus on
> whether subnetwork designers should be actively encouraged to
> implement mechanisms to protect user data.
>
> The majority of the working group held that subnetwork security
>
> Dan: > Since when does the IETF have majorities and minorities!!! Did we
> take a vote ;-)?
wasn't it hummed in London after a zillion IPSec mafia advocates had
taken the mike?
> This is an extremely prejudicial statement. The previous
> wording was something to the effect of one point of view held (or something
> like that). If we insist on using adjectives, we could refer this as the
> purist point of view (versus the pragmatic point of view), but I think our
> audience can make up their own minds when presented with facts rather than
> opinions.
If the audience can make up its own mind, you can then have no
objection to that 'prejudicial statement'. Like it or not, it _is_ a
majority view in the WG, and both viewpoints are carefully framed in
identical 'the argument is' formats.
Earlier discussion of this revised text would have been good...
> This viewpoint
> recognizes that many security policies implicitly assume that the entire
> end-to-end path is composed of a series of concatenated links that are
> nominally physically secured. That is, these policies assume that all
> endpoints of all links are trusted and that access to the physical media by
> attackers is difficult.
You're not willing to critique the set of security policies that the
text you present advocates? Doesn't use of a subnetwork include
specification of an appropriate security policy? In fact, doesn't the
subnetwork create the policy?
(and doesn't Lessig write reams about this stuff?)
I do have a problem with this prejudicial presentation of these
'many security policies'.
> Please replace this text, in its entirety, with the following, and
> please don't make editorial "improvements" that dilute or disparge
> the point. I'm also going to make a direct request that chairs
> intervene here to ensure that the editor faithfully captures the
> points raised without injecting his personal opinions.
It could be argued that you're attempting to inject your personal
opinions without editing or review, and I'd have a problem with that
too.
> We therefore recommend that subnetwork vendors who choose to
> ^^^
> subnetwork designers: this document is also directed to standards bodies, and
> this is the terminology we've used throughout the draft
yup.
(I do think there should be an earlier and perhaps more mention of
traffic analysis; it's going to become more and more significant, and
it's imo still underplayed in this draft.)
L.
compromise: commutative.
<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST