On Mon, 2008-10-20 at 20:44 -0500, Nicolas Williams wrote:
> But then:
>
> |In order to
> | maintain data Sensitivity Labeling for such applications, in
> | order to be able to implement routing and Mandatory Access
> | Control decisions in
On Thu, 2007-11-01 at 11:09 -0400, Sam Hartman wrote:
> In many cases the performance of security protocols is not a huge
> issue at all with modern hardware.
Depending on the scope of this effort I see a bunch of things that might
be worth modelling:
- additional compute resources (cpu, memory,
On Sun, 2007-10-28 at 09:05 -0700, Bill Fenner wrote:
> RFC 2026, section 10.4.(D), gives boilerplate to add to a document
> where there is known ipr:
>
> "The IETF has been notified of intellectual property rights
> claimed in regard to some or all of the specification contained
On Mon, 2006-01-23 at 17:45, [EMAIL PROTECTED] wrote:
> Among the results are:
> 1. Slightly more than 25% say their laptop is compatible with 802.11a.
> [Note the IETF 65 NOC for Dallas recommends 802.11a]
>
> 5. Only 1/3 of the respondents expressed satisfaction with the wireless
> connectivit
On Fri, 2005-11-18 at 11:43, Ted Faber wrote:
> I
> > request that the RFC editor will accept xml2rfc as an input format.
>
> I thought they did take it as a supplement or something, which I hope
> indicates that they are considering mo
On Sat, 2005-11-19 at 01:53, Ole Jacobsen wrote:
> A number of folks had nailed up PPP connections from their hotel rooms
> to Sweden, Japan, Germany, you name it.
It seems fitting that 30 IETF's after the host was kind enough to
provide free IP over voice, a different host provided free Voice ove
On Mon, 2005-11-14 at 12:05, Frank Ellermann wrote:
> > Anyone would does not like it is encouraged to suggest one
> > that other folks will like better.
>
> I like Keith's terms MON / MRN (mail originating / receiving
> networks) better, because seen as sets of systems they can be
> different. A
On Thu, 2005-10-27 at 11:51, Eliot Lear wrote:
> Looking at the snippet of the RFC queue you provided, the draft blocked
> on a normative reference to draft-ietf-ipsec-rfc2401bis, which entered
> the queue in April. It references a bunch of other stuff, but they're
> all earlier in the queue,
On Fri, 2005-10-14 at 11:58, Avri Doria wrote:
> I think there needs to be some mention of requirements such as:
>
> - MUST NOT be held in a country whose visa requirements are so
> stringent as to make it impossible or even extremely difficult for
> some participant to attend.
An important f
Ralph's call for volunteers says:
> I have e-mailed acknowledgments to those from whom I have already
> received offers to participate in NomCom 05. If you think you've
> already responded, but did not receive an acknowledgment, please let
me
> know.
I've volunteered, but have not received an ac
On Mon, 2005-10-03 at 13:27, william(at)elan.net wrote:
> potentially they could switch
> to using different CLASS (i.e. like HESIOD is locally used in MIT)
Actually, MIT switched to class IN for Hesiod data years ago because
multiple-class support didn't work as well as hoped. With the data in
On Sat, 2005-10-01 at 12:27, JFC (Jefsey) Morfin wrote:
> ... the monolingual/etc. Internet is the ...
Huh? The Internet is already multilingual. Heck, the message following
yours in my inbox was in a mix of Korean and English.
- Bill
_
On Wed, 2005-09-28 at 16:50, Fleischman, Eric wrote:
> That RFC said "hosts do X" and other devices (which in that era meant
> routers) do Y. They do Y because they are not hosts --
middleboxes are sometimes router-like, and sometimes host-like, and
sometimes both at the same time, and sometimes
On Wed, 2005-09-28 at 12:41, Fleischman, Eric wrote:
> Specifically, when I first became associated with you all in 1992, the
> RFCs of most IETF standards were incomplete and the reference
> implementations (i.e., running code) were what was considered to be
> normative.
I didn't get directly in
On Tue, 2005-09-27 at 10:06, Robert Elz wrote:
> Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
> From:Dean Anderson <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | It is not DNSSEC that is broken.
>
> I have not been following dnsop discussions, but from th
On Fri, 2005-09-16 at 14:36, [EMAIL PROTECTED] wrote:
> If there was a way to lighten-up the IESG review process, then this
> would be a good idea. For example, having a single DISCUSS per Area
> would be one way to reduce this could be one solution.
Why do you think this would make any differenc
On Thu, 2005-08-25 at 14:26, [EMAIL PROTECTED] wrote:
> In any case, I support this appeal to the extent that I believe the conflicts
> need to be resolved prior to publication. I take no position on the means
> by which the conflict is resolved as long as a resolution is reached.
And I wholeheart
On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote:
> are you of the opinion that the IESG should try to police which experiments
> get run on the Internet by refusing to publish RFCs documenting
> possibly-conflicting experments?
It depends on the form of the conflict.
I believe that t
On Thu, 2005-08-25 at 06:48, Pekka Savola wrote:
> I think there needs to be separation of two different kinds of
> documents,
>
> 1) informational, because the normative specification is elsewhere
> (usually another standards organization) and we could reference the
> normative spec directly
On Wed, 2005-08-24 at 19:14, John C Klensin wrote:
> Even if one believes that it is desirable, 3967 already weakens
> traditional norms for documents on the IETF standards track. A
> suggestion that further weakening is needed definitely calls for
> some discussion, at least IMO.
There is con
On Tue, 2005-08-23 at 11:38, Stephane Bortzmeyer wrote:
> Nobody suggested to kill the whois protocol, just the badly written
> and obsolete RFCs which were requiring violations of various european
> laws regarding privacy. Neither ICANN or IETF should specify privacy
> policy for a ccTLD.
I belie
On Thu, 2005-08-11 at 15:40, Stephen Kent wrote:
> I thought that what Russ asked for was not a threat analysis for
> DKIM, but a threat analysis for Internet e-mail, the system that DKIM
> proposes to protect. The idea is that only if we start with a
> characterization of how and why we believe
On Fri, 2005-08-05 at 09:44, Iljitsch van Beijnum wrote:
> ... I believe Leslie said we shouldn't use IETF servers for testing.
>
> In and of itself I fully agree with that statement.
I'd go farther. I strongly disagree.
While the availability and stability of the IETF infrastructure is
import
On Fri, 2005-07-22 at 07:35, Sam Hartman wrote:
> BTW, this conversation and a side conversation with John has convinced
> me that IESG review should involve a call for comments phase.
A call for comments requires having something for the community to
comment on.
Will an internet draft will be r
On Thu, 2005-07-21 at 08:12, Bill Fenner wrote:
> So, e.g., for draft-ietf-ospf-2547-dnbit, is it enough to say "Waiting for
> draft-ietf-l3vpn-ospf-2547 (IESG Evaluation :: AD Followup)
> and draft-ietf-idr-bgp-ext-communities (Approved- Announcement sent)"?
> (Note that the 2nd one is a REF that
On Wed, 2005-07-20 at 12:20, Brian E Carpenter wrote:
> Exactly. "It's in the parking area" is our equivalent of "the check's
> in the mail." Seriously, we can point enquiries about the status of
> a draft to there.
yup. except that the rfc editor queue is not a FIFO.
hopefully the final result
On Tue, 2005-06-28 at 00:15, Scott W Brim wrote:
> In SG13 there was considerable debate, and at the end the
> group *allowed* exploration of the topic through development through a
> new draft recommendation.
assuming, for sake of argument, that the general proposal makes
sense[1], it sounds like
On Tue, 2005-06-21 at 00:28, Nicholas Staff blames the victims:
> whats funny to me is if anything would have given spammers a reason to
> exploit open relays it would have been the blacklists. I mean when
you
> arbitrarily blacklist millions of their ISP's addresses you leave them with
> no oth
Ted,
While I have not been following this issue particularly closely, this
appears to be a case where two experiments are using the same codepoint
to enode data with (allegedly) different meaning.
Specifically (quoting from Frank's message):
>| Sender ID implementations SHOULD interpret the vers
On Wed, 2005-06-01 at 15:48, Sam Hartman wrote:
> That's what I thought too. However that seems to be false. The one
> reference currently in the security considerations section is for an
> attack to distinguish an RC4 stream from a random stream.
A critical parameter to such attacks is the am
On Wed, 2005-05-18 at 04:50, Brian E Carpenter wrote:
> Would it be better if the process required an explicit request for
> more time?
In the face of variable workload it makes no sense to expect
constant-time response from the IESG.
My understanding is that there is no load-levelling on the IE
On Wed, 2005-05-11 at 10:34, Bill Fenner wrote:
> You may be interested in
> http://rtg.ietf.org/~fenner/iesg/rfc-deps.pdf for a visualization that
> I've been fine-tuning for a couple of years; it's auto-generated
> daily.
I bow to your superior graphviz skills.
We need a link to this from the
On Wed, 2005-05-11 at 06:35, Bill Sommerfeld wrote:
> When I went looking at the queue a month or so ago it required work to
> distinguish between a REF to a document already in the queue vs. a REF
> to a document not yet in the editor queue.
.. and, having just done this a second time
On Wed, 2005-05-11 at 04:50, Brian E Carpenter wrote:
> > A delay of that length is generally due to dependencies -- normative
> > references to other documents that are held up.
> >
> > When a document is in the RFC Editor queue, you can query its state via
> > their web site.
>
> But that gi
On Fri, 2005-04-29 at 09:35, Ralph Droms wrote:
> Let me restate for clarity - ADs aren't necessarily more technically
> astute than *all* the rest of us. That is, we need to be careful that
> technical input from ADs isn't automatically assigned extra weight or
> control (veto power).
Indeed. T
On Fri, 2005-04-08 at 09:27, Elwyn davies wrote:
> Xml2rfc has a mechanism for adding comments which is a little bit more
> trouble than M$Word's but works in very similar ways.
>
> You are right that revision marking is not so easy but the various diff
> tools help. Maybe we ought to ask for som
As the next IETF meeting will be in Paris, and France has had something
a reputation for placing strict controls on the use of cryptography, I
took a look..
(This is, of course, a matter of potential concern to those of us who
carry laptops with encryption software for personal use to every IETF
m
On Mon, 2005-03-14 at 06:26, Bruce Campbell wrote:
> The IETF Meeting crew should look at supplying an additional 3 ethernet
> and power drops per room, labelled 'chair', 'presenter' and '(jabber)
> scribe' with the expectation that they be used accordingly.
Power was most assuredly not a proble
On Mon, 2005-03-14 at 03:10, Tim Chown wrote:
> Indeed; there seems to be some 'smart' Alcatel software that is doing
> some ARP/DHCP trickery (at least the APs are Alcatel, so the favourite
> for the s/w is the same vendor...).
>
> Note that my problem all week was getting dis-associated from WLA
On Sat, 2005-03-12 at 08:55, Johan Henriksson wrote:
> my idea is to use encryption (for now - better alternatives might exist);
> if it takes up to 1 minute to encrypt a mail, the cost per mail is
> increased greatly.
this is not new. variants have been proposed under a number of names for
year
On Mon, 2004-12-13 at 20:16, Simon Josefsson wrote:
> I would include "modify" in this clause, or clarify exactly which
> license you are talking about (e.g., GNU Free Documentation License).
IMHO, if "modify" is allowed, the license must require that modified
versions are clearly distinguished f
On Fri, 2004-11-05 at 21:43, Paul Hoffman / VPNC wrote:
> Hmmm. I had no problem about an hour ago coming from the National
> Airport via the Metro. They said over the PA they were going to shut
> down a segment over the weekend but shuttle-bus people around the
> shut-down part.
If we can bel
On Thu, 2004-10-21 at 11:49, Tim Bray wrote:
> I'm with ESR on this one. The W3C bit the bullet and built a
> patent/IPR policy that has integrity and is based on the notion that
> the Net works properly when important components can be built by
> un-funded independents without worrying about g
On Wed, 2004-10-20 at 02:34, Eric S. Raymond wrote:
> I said this: if IETF wants to know what form of patent license will be
> acceptable to the open-source community, the people to ask are Richard
> Stallman (representing FSF) and myself (representing OSI).
>
> Between us (and especially if we ag
On Wed, 2004-10-20 at 02:34, Eric S. Raymond wrote:
> I said this: if IETF wants to know what form of patent license will be
> acceptable to the open-source community, the people to ask are Richard
> Stallman (representing FSF) and myself (representing OSI).
>
> Between us (and especially if we ag
> There are collars and ties at IETF meetings now?
>
> How the mighty has fallen.
Huh? There have been (small numbers of) clued people wearing collars
and ties at just about every IETF I've attended..
- Bill
___
I was last in San Diego in late January of this year. For my
(domestic US) return flight, I arrived at the terminal about an hour
and a half before my (domestic) flight home on a 9:50am Friday morning
flight.
I think there were about a dozen people ahead of me in line for
security in terminal 2 a
> If the filter is after the
> server providing the form page and the SUBMIT button, yes, the
> server received the message. IETF can have a log file before the
> filter (SOP), allowing review of what is filtered.
Substantially similar capabilities are present in all of the SMTP
MTA's I'm familiar
> The server can filter as the IETF wishes (or dare) but there would be no
> problems with black-lists and mail routing affecting the message being
> RECEIVED by the IETF -- which is the point in question.
If a message is blocked by a filter without making a sound, is it
actually received?
> The solution to this self-limitation problem [1], if the Internet MUST be
> the only communication path used by someone, is to use IETF web forms
> that go directly to the server.
It's not a solution. For one, spammers, not content to ruin email,
have been abusing web forms for quite some time
> - Individuals traveling to Korean to attend the IETF meeting
> do not need a visa, as they are traveling to attend a
> non-profit conference. They can stay in Korea up to 30
> day for such purpose and for tourism.
>
> - If you travel to Korea for business purposes, such as
>
> Good point. That's why I favor giving users access to their spam pool
> when they suspect problems, and using challenge/response in certain
> (carefully defined) situations.
> A good filtering mechanism is not nearly as black and white as a blacklist.
so, you're conflating two things here:
> The RBL, and particularly the DUL, are not "good faith," as it is
> well known that both block significant amounts of legitimate,
> non-spam, non-uce, recipient-desired email.
I guess it depends on your definition of "significant". I haven't
noticed a problem, but the amount of spam I get is la
> > If you think there's some violation of law going on here, please be more
> > specific. What law, and in what country?
>
> Try to keep up. A specific citation has already been made.
and already been debunked.
- Bill
> That law reads in part:
>
> "Whoever... knowingly causes the transmission of a program,
> information, code, or command, and as a result of such conduct,
> intentionally causes damage without authorization, to a protected
> computer...shall be punished..."
Except that use of DNSBL's is generall
> If you read the Verisign documentation (which is quite excellent by the
> way) on what they did and what they recommend you will see that they
> thought about this.
I stopped reading the PDF when I saw the "Verisign Proprietary"
labels.
> It is left as an exercise to the reader as to which is m
> If someone tries to send mail and their key is not on the
> recipient's list, the mail is returned to them until they can
> perform a Hashcash calculation consuming a non-trivial amount of CPU
> time, at which point their key is placed on the recipient's list,
> and the sender can retry to send t
> I checked 39USC and 39CFR955 I guess the postal service maintains a list if
> you want to not receive mailing for sexually oriented materials,
> sweepstakes, and pandering solicitations. But that's about it. As far as the
> USPS goes.
I have not yet tried filing a form 1500, but, if you believe
I fail to see why this is such a pressing issue. To be completely
unambiguous, you need to name the protocol. That identifies the
layer, and then "packet" or "datagram" or what-have-you is
unambiguous.
- Bill
> As others have pointed out, the DNS already has the capability
> to store certs. So you could use the DNS as a publication
> method. But is this the only thing a PKI needs? How would
> one revolke a cert that was in the DNS? How can you update
> -every- cached c
> ...actually, this is the only problem the article finds. And,
> yes, I can certainly understand why they consider it a problem: those
> neighbors are getting, for free, the same bandwidth they would if they
> paid for the cable modem service.
It's should not be surprising that this is a hot bu
> > > Somecases. However, ICMPv6 example case, described in the first mail of
> > > this thread, has not been found but already described in the spec; which
> > > is not a bug at all.
> >
> > could you give the RFC or draft name, and quote the text you are worried
> > about?
>
> Yes. Please hav
>If DNSSEC were deployed, I see no reason why SAs could not be
>bound to domain names.
>
> I disagree. IPSEC is about Security at the IP layer, and that means we
> need a security association which is tied to an object which is
> addressable at the IP layer --- an IP address.
except tha
> Convert the I-Ds to ps or pdf files (something hard to change)
Postscript files are straightforward for a postscript hacker to
change. I imagine the same is true for pdf files.
If you want to make the files hard to change, try a pgp signature.
- Bill
> Usage of language does change and meaning does evolve. (has anyone set
> up a VPN sans encryption recently?)
Well, does it count if the encryption doesn't cover the whole path?
I'm aware of a number of ipsec "vpn" hardware vendors out there who
are looking to put encryption in ISP edge "concen
> I would like to propose the introduction of a "no action" period for
> Internet Drafts. Upon (re)publication of an I-D, no action (except
> removal) would be allowed upon the I-D for a short period of time
> (two weeks?). No LAST CALLs, no submission to AD, IESG, RFC-Editor,
> etc.
[
> Its already set up link that, Not that I can ever recall seeing a
> .us.
you have now.
- Bill
> doesn't this require the NAT to use the same inside<->outside address
> binding for the connection between the client and the KDC as for
> the connection between the client and the application server?
> e.g. it seems like the NAT could easily change address bindings
> during the lifetime of a t
The objections I've seen so far to this draft specifically cite
problems from systems such as "transparent web proxies" (which are, in
my experience, usually far from transparent) in the network which
intercept all traffic, regardless of destination address, sent to
specific well-known ports.
A q
> This is the same card as an Apple Airport. It is 802.11 DS, 11Mbps, and
> supports Wire Equivalent Privacy (WEP). The idea here is that you need a key to
> get on the network, but once you're on you can see all the traffic "on the
> wire" that you care to. The Apple software only lets you set a
> At 02:50 PM 12/14/1999 , Christian Huitema wrote:
> >No. This is no different from the present situation. BGP does not recompute
> >routes in case of congestion. It is a problem that we are stuck with today,
> >that multi-address multi-homing actually gives us the hope of solving.
>
>
> Only m
> if multiple addresses are available for a host, the chances are good
> that the paths associated with some of those addresses are significantly
> better, or worse, than others. with IPv4 multihoming, the routing system
> sorts out which path to use. this doesn't work perfectly but at least
> There is also a potential scaling issue of using multiple addresses
> as general purpose multihomging mechanism. This is because if this
> is the case, most of the Internet hosts will end up with multiple
> addresses.
I don't see why this is inherently a problem.
> It's possible that some
> Raw numbers of prefxies are pretty impressive. A IPv4 /20 is 4k "host"
> addresses. An IPv6 /116 is the same sized "chunk" so, the total number of
>
> /20s in the IPv4 world: 1024000 (stuff that into your router)
> /116s in a /48 chunk:34359738368 (is that right?)
that looked a littl
We'll be using the BayStack 650 Wireless devices (IEEE 802.11 FH),
but unfortunately we only have drivers for MS Windows(95,98,NT, 2K)
machines. So, in an effort to make up for our lameness and to
provide support for other platform's I'd like to make an offer.
I'll give you a free
75 matches
Mail list logo
