> >Dan: This paragraph is too long. This is a document about subnets, not
> >applications. To the extent subnet designers are ignorant about these things,
> >it also creates false expectations about widespread deployment and usage.
>
> The whole purpose of this document is to educate the designers of
> subnetworks about the Internet environment in which they are expected
> to operate. I started this effort because I perceived many subnetwork
> designers to be working in a vacuum. I therefore think it entirely
> within scope to enumerate the end-to-end security mechanisms that are
> already available in the Internet architecture to help the subnetwork
> designer decide the importance of providing similar features.
Available, yes. In ubiquitous use, no.
>
> This is *exactly* analogous to the discussion of how the end-to-end
> reliability provided by Internet transport protocols obviates the need
> for "total" reliability in a subnetwork. Otherwise we have unnecessary
> duplication of function.
Bad analogy. TCP is an integral part of the architecture, has been there from
the beginning. All these other mechanisms were kinda added on over the years,
but are still not ubiquitously deployed and used.
>
> >Dan: > Since when does the IETF have majorities and minorities!!! Did we
> >take a vote ;-)? This is an extremely prejudicial statement. The previous
>
> Quite frankly, Dan, I'm being quite charitable here. The "minority"
> consists of one person: you. Otherwise it would have been a clear
> consensus. And you didn't even show up in London to make your case; I
> had to make it for you as best I could, and I am still trying to
> present both points of view in the document as best I can.
I'm not going to engage in a defend/attack. See RFC 3184 concerning personal
attacks and RFC 2026 on a variety of other matters, including the use of
meetings and mailing lists.
>
> I'm still digesting your substitute text. I may put it in just to get
> this over with.
Thank you.
>
> Nevertheless, I suspect you will never be satisfied with the result,
> so all I can suggest at this point is that you document your point of
> view in your own document and publish it as an informational RFC with
> your name on it.
This is a working group document, and subject to working group consensus.
>
> [section on traffic analysis]
>
> >What does this add? Suggest removing this paragraph.
>
> You weren't in London, so you missed the discussion about the utility of
> subnetwork security to thwart traffic analysis. I suggested, and the group
> agreed, to add language addressing this point with the caveat that traffic
> analysis is a very difficult and subtle threat.
I was filled in afterwards. I agree with the first paragraph. It's only the
second that seems unnecessary.
>
> Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST