IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
The IESG has received a request from Harald Alvestrand to approve an RFC
3683 PR-action ("posting rights" action) for JFC (Jefsey) Morfin as a
result of a pattern of prior warning and posting rights suspensions for
off-topic postings to the LTRU working group and ietf-languages mailing
lists that have not produced a change in behavior. This behavior has been
characterized as a "denial-of-service" attack to disrupt the
consensus-driven process as described in Section 1 of RFC 3683. A timeline
of warnings and posting rights suspensions related to this request is
included below.
The IESG will consider this request. If approved, the PR-action described
in Section 2 of RFC 3683 includes provisions to allow list administrators to
suspend Mr. Morfin's posting rights to the LTRU working group and
ietf-languages mailing list for at least one year. Maintainers of other
IETF mailing lists may also remove posting rights to their mailing lists at
their discretion.
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send any comments to the iesg@ietf.org or
ietf@ietf.org mailing lists by 17 February 2006.
For the IESG,
Scott Hollenbeck
Applications Area Director
--
Private warnings sent for LTRU working group mailing list postings:
7 July 2005
16 July 2005
23 September 2005
26 October 2005
Public warnings and suspensions for LTRU working group and ietf-languages
mailing list postings:
17 March 2005 (ietf-languages warning)
http://www.alvestrand.no/pipermail/ietf-languages/2005-March/003236.html
5 April 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html
12 May 2005 (LTRU suspension)
http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html
26 May 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html
(Used as basis for 4 July suspension.)
15 June 2005 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2005-June/003474.html
4 July 2005 (LTRU suspension)
http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html
(Appealed to AD, appeal upheld, new warning given.)
5 July 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html
15 September 2005 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2005-September/003585.html
26 September 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg03755.html
7 October 2005
PR-Action request sent to IESG
http://www1.ietf.org/mail-archive/web/ietf/current/msg38183.html
15 October 2005 (LTRU warning)
http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html
8 November 2005 (LTRU suspension)
http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html
(Appealed to AD, appeal denied by AD.)
20 November 2005 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2005-November/003811.html
(Appealed to AD/IESG, appeal denied by IESG, appealed to the IAB.)
13 January 2006 (ietf-languages suspension)
http://www.alvestrand.no/pipermail/ietf-languages/2006-January/003854.html
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
Thanks for your comments. I generally agree with your feedback and we'll
revise the document accordingly.
Harald Tveit Alvestrand wrote:
I oppose approval of this document as-is.
Four reasons:
1) FCFS is inappropriate
2) The document gives inadequate context for use
3) The document gives inadequate procedures
4) The definition of "automobile" is wrong
Further explanation:
1) FCFS: This token registry will have value chiefly when the recipient
of such a token has a complete list of tokens available to him, and can
perform adequate localization. Thus, value is maximized if the churn of
the registry is slow. With FCFS, one risks a number of trends that could
jeopardize this (consider registering, in addition to "cafe",
"McDonalds", "Wendy's", "Burger King", "Jack-in-the-box", "7-eleven"...
or in addition to "school", registering "university", "middle school",
"gymnasium", "hochschule", "kindergarten",
"vocational-training-institution")
I consider "expert review", with a list of criteria that includes "names
a type of place not described by any existing token", to be a more
appropriate mechanism.
If we think unlimited growth is a problem, someone needs to be able to
say "no"; if we don't think unlimited growth is a problem, we need to
say so.
2) Inadequate context for use:
The document does not make reference to RPID, except in
"acknowledgement". Thus, it has to be interpreted as stand-alone, and
must contain its own guidance. RPID states:
The element describes the type of place the person is
currently at. This offers the watcher an indication what kind of
communication is likely to be appropriate.
The XML definiton says:
Describes the type of place the person is currently at.
and while I'm not an XML expert, it seems to say that
is a legal construct.
I don't know if it's possible to say whether or not
is different from
.
These things guide the usage of place-types in RPID, but cannot be found
from the registry document.
This document SHOULD give guidance for usage, saying at least:
- whether it's intended that several of these values can be used together
- whether it's intended that a sequence of location types gives a
progressively more precise set of terms (in which case
internationalizing the last type you understand is appropriate) or names
an intersection of the classes (in which case you would have to
internationalize all of them).
- whether having a text string alongside it (the "note" above) is a
recommended practice.
It MAY be appropriate to say something about field of use, like RPID
does ("what types of communication is appropriate" would lead one to
distinguish between "driving a car" and "passenger in a car", while one
could imagine that other usages might want to distinguish between
"expensive restaurant" and "cheap restaurant").
3) Inadequate procedures:
It's a fact of life that any registry will need updating. This document
describes registration, but no updates. It needs to say:
- Who's authorized to update a registration (FCFS, Expert approval,
original registrant, not at all)
- Guidelines for updates (anything-goes, refinements only, redefinitions
with expert approval only)
- Whether registrations can be deleted or not
- Whether there is a mechanism for marking entries as "deprecated, use
this other term"
4) Self explanatory:
automobile:
The entity is in a railroad car.
Nit: The terms show signs of having been alphabetized at one time. They
are no longer alphabetized - "residence" is in a place in the list that
would have been appropriate for "home".
--On mandag, januar 16, 2006 21:33:45 -0500 The IESG
<[EMAIL PROTECTED]> wrote:
The IESG has received a request from the Geographic Location/Privacy WG
to consider the following document:
- 'Location Types Registry '
as a Proposed
Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-30.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-reg
istry-0 3.txt
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Wireless at IETF
In addition to the content suggested below, I think a few words on "Why ad-hoc mode is BAD during IETF meetings" should also be included. Not everyone knows the issues caused by ad-hoc mode (e.g. newbie attendees). Regards and Happy New Year ... Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marshall Eubanks Sent: Sunday, January 15, 2006 4:39 PM To: Harald Tveit Alvestrand Cc: ietf@ietf.org Subject: Re: Wireless at IETF I think (and suggested to the IAOC) that there should be an information sheet and / or web site for each meeting with information on how to determine Ad Hoc Mode, how to turn it off, etc., for all major OS choices. Regards Marshall On Jan 15, 2006, at 4:10 PM, Harald Tveit Alvestrand wrote: > Tangential: > At the IEEE meeting following the IETF, someone asked me "how do I > turn off ad hoc mode". > > I was hard put to find an answer for Windows XP with the standard > drivers (I use 2000 and a Cisco driver kit). > > Suggestion: Make instructions *with screenshots* of how to turn off > ad hoc mode on Windows XP available at the next IETF. > >Harald > > > --On søndag, januar 15, 2006 15:23:01 -0500 Henning Schulzrinne > <[EMAIL PROTECTED]> wrote: > >> http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt describes what >> seems to explain the appearance of IETF6x named computer-to-computer >> wireless networks at IETF meetings. Apparently, there is a >> feature that >> has systems automatically advertise the last AP SSID after >> (involuntary) >> disconnection. The slides are skimpy on details, but provide a >> bit more >> background than the usual "turn of ad-hoc mode" exhortations at IETF >> meetings. >> >> Henning >> >> ___ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf >> > > > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Wireless at IETF
That is solving the problem for ourselves only. 802.11 is a classic case of what happens when unfinished technology is thrown at consumers. Think about VLSI manufacture, thirty or so production steps each with a finite chance of error. If you have a 5% error rate at each stage your overall yield drops to 20% Computers are much more complex than VLSI manufacture, the explanations of the technology are much worse than 95% accurate. All my hardware is allegedly capable of doing WPA or 801.X. I have not got the slightest idea what I would have to do to enable it though, or how it would work, or what the authentication process would be. It is unfortunate that the cryptographic failures in WEP obscured the much more significant usability failures. The wireless world still does not 'get' it. The result is that 70% of wireless access points are open and can be used by Internet criminals to achieve anonymous access. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ed Juskevicius > Sent: Wednesday, January 18, 2006 12:26 PM > To: Marshall Eubanks; Harald Tveit Alvestrand > Cc: ietf@ietf.org > Subject: RE: Wireless at IETF > > In addition to the content suggested below, I think a few > words on "Why ad-hoc mode is BAD during IETF meetings" should > also be included. Not everyone knows the issues caused by > ad-hoc mode (e.g. newbie attendees). > > Regards and Happy New Year ... > > Ed > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Marshall Eubanks > Sent: Sunday, January 15, 2006 4:39 PM > To: Harald Tveit Alvestrand > Cc: ietf@ietf.org > Subject: Re: Wireless at IETF > > > I think (and suggested to the IAOC) that there should be an > information sheet and / or web site for each meeting with > information on how to determine Ad Hoc Mode, how to turn it > off, etc., for all major OS choices. > > Regards > Marshall > > > On Jan 15, 2006, at 4:10 PM, Harald Tveit Alvestrand wrote: > > > Tangential: > > At the IEEE meeting following the IETF, someone asked me "how do I > > turn off ad hoc mode". > > > > I was hard put to find an answer for Windows XP with the standard > > drivers (I use 2000 and a Cisco driver kit). > > > > Suggestion: Make instructions *with screenshots* of how to > turn off ad > > hoc mode on Windows XP available at the next IETF. > > > >Harald > > > > > > --On søndag, januar 15, 2006 15:23:01 -0500 Henning Schulzrinne > > <[EMAIL PROTECTED]> wrote: > > > >> http://www.nmrc.org/pub/present/shmoocon-2006-sn.ppt > describes what > >> seems to explain the appearance of IETF6x named > computer-to-computer > >> wireless networks at IETF meetings. Apparently, there is a > feature > >> that > >> has systems automatically advertise the last AP SSID after > >> (involuntary) > >> disconnection. The slides are skimpy on details, but > provide a bit > >> more background than the usual "turn of ad-hoc mode" > exhortations at > >> IETF meetings. > >> > >> Henning > >> > >> ___ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ietf > >> > > > > > > > > > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wireless at IETF
On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, Phillip wrote: > The result is that 70% of wireless access points are open and can be > used by Internet criminals to achieve anonymous access. Loaded statement? Check. Precise statement? Check. Supported statement? H. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpBsBycFODsA.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Venue Selection Criteria - new (last ?) version
Hi all, I've sent to the secretariat a couple of days ago, version 4 of this document, but is still not there. Meanwhile, you can access to it at: http://www.consulintel.euro6ix.org/ietf/draft-palet-ietf-meeting-venue-selec tion-criteria-04.txt Please, provide your final inputs so we can declare this done ASAP ! One more comment. The network (wired/wireless), terminal room and other technical details, which *are* part of the selection criteria have been moved to a new document (which is already referenced in the venue selection one), to make it easier to read and to differentiate the most "administrative" or logistic things from the rest. I hope to have a first version of this document at the end of this week. Regards, Jordi ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wireless at IETF
In message <[EMAIL PROTECTED]>, Ted Faber writes: > > >On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, Phillip wrote: >> The result is that 70% of wireless access points are open and can be >> used by Internet criminals to achieve anonymous access. > >Loaded statement? Check. >Precise statement? Check. >Supported statement? H. > I'm not sure which part your claiming is unsupported; my own informal measurements agree with the 70% number. I'm not at all convinced that "Internet criminals" use such access points as a major means of access, though. However, Phillip's larger point -- that our security mechanisms and products have lousy user interfaces -- is absolutely correct. It's a major issue. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wireless at IETF
On Wed, Jan 18, 2006 at 02:23:49PM -0500, Steven M. Bellovin wrote: > In message <[EMAIL PROTECTED]>, Ted Faber writes: > > > > > >On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, Phillip wrote: > >> The result is that 70% of wireless access points are open and can be > >> used by Internet criminals to achieve anonymous access. > > > >Loaded statement? Check. > >Precise statement? Check. > >Supported statement? H. > > > > I'm not sure which part your claiming is unsupported; my own informal > measurements agree with the 70% number. I'm not at all convinced that > "Internet criminals" use such access points as a major means of access, > though. Well, none of it's supported. Your statement above about informal measurements is support for your statement of 70% and indirectly of his. "70% are open," meaning 70% of wireless (access points|networks) have no admission control at the link layer seems plausible, but there are lots of things that seem plausible to me that I'm wrong about later. Having a number and not even saying "Bellovin's measurements indicate" always tweaks my interest. Going from an open access point to anonymous criminal access seems much more implausible to me. There are all sorts of hurdles one could put up between "no link level protection" and "anonymous criminal access." But again, I'm wrong all the time and a citation for that much more damning statement would be very welcome. Without one I feel like I'm watching local news. The combination of a very provacative statelment "anonymous criminals access" and precise number makes me uneasy. After all 90% of all statictics are made up. "An awful lot of access points can be used to anonymously get on the Internet for criminal purposes" doesn't concern me as much. But if you found a number somewhere, let me know where, too. A real study is valuable information; an uncited, incorrect (and I don't know it's incorrect) number is hard to kill. > However, Phillip's larger point -- that our security mechanisms and > products have lousy user interfaces -- is absolutely correct. It's a > major issue. I absolutely agree. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpuFtLVeQzA0.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Wireless at IETF
|> -Original Message- |> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] |> On Behalf Of Ted Faber |> Sent: Thursday, January 19, 2006 5:57 AM |> To: ietf@ietf.org |> Subject: Re: Wireless at IETF |> |> On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, |> Phillip wrote: |> > The result is that 70% of wireless access points are open and can be |> > used by Internet criminals to achieve anonymous access. |> |> Loaded statement? Check. |> Precise statement? Check. |> Supported statement? H. I don't see the 70% of access points being open actually. My own figures indicate less than 20% within the local area, information from capital cities tends to suggest a slightly higher figure but certainly not that high. But then, how many wired networks have link layer access controls? I don't see very many of those and implementing it is extremely difficult unless you have everything set up exactly as the hardware has been designed for. For example trying to use password/password combinations instead of token/password has proven problematic in one practical case I'm aware of for activating port locking. It amuses me just how easy it is to walk into a business and plug a system in with full access to the network. Most people/businesses do not appear to have security as a high priority. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FW: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
Hi, Here is the original announcement and the IETF URL. Comments please ! Regards, Jordi -- Mensaje reenviado De: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Responder a: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Fecha: Wed, 18 Jan 2006 15:50:01 -0500 Para: Asunto: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IETF Meeting Venue Selection Criteria Author(s) : J. Palet Filename : draft-palet-ietf-meeting-venue-selection-criteria-04.txt Pages : 18 Date : 2006-1-18 This document provides the IAD with technical and logistic criteria for selecting venues for IETF meetings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection -criteria-04.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-palet-ietf-meeting-venue-selection-criteria-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: "FILE /internet-drafts/draft-palet-ietf-meeting-venue-selection-criteria-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <[EMAIL PROTECTED]> ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -- Fin del mensaje reenviado ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wireless at IETF
On 18-Jan-2006, at 15:35, Dassa wrote: I don't see the 70% of access points being open actually. My own figures indicate less than 20% within the local area, information from capital cities tends to suggest a slightly higher figure but certainly not that high. It depends a lot on the nature of local internet services, I think. Where I live, flate-rate 3-5Mbit/s cable/DSL internet service is cheaper than buying a dedicated phone line to use with a modem at ~56k, and consumer-grade 802.11g access points can be had for a couple of dollars after mail-in rebates. From informal wandering around my residential neighbourhood, I would say that >98% of access points reachable from the street have no access control. Since there are no scary bills that arrive from ISPs at the end of the month if someone outside has been red-lining the DSL, I suspect that people have little incentive to keep other people out. I also suspect that since DSL and cable internet service is so cheap here, for most people it's far more sensible to pay for their own rather than to stand out on the street in the snow with a laptop and a pringles can. I doubt that it's possible to reverse the trend of widespread, unsecured network access. Any manufacturer of access points who turns on security measures by default with a random, device-specific initial password supplied in the documentation is (a) going to have higher production costs, and (b) much higher support costs than competitors who ship everything open and ready to run with no configuration. Maybe it doesn't matter. I struggle with the idea that there might be roving gangs of organised criminals stealing internet access from wifi-equipped black vans. There are surely much cheaper, less labour- intensive ways to gain illicit access to the network than that. (It has certainly been very handy for me, more than once, to be able to use my neighbour's cable modem from my living room via 802.11 while my DSL was down.) If there's a lesson to be learned here, maybe it's this: if you aspire to see your protocol or service reach widespread, consumer- level acceptance, and it is desirable that the service or protocol be deployed securely, remember that if the security is optional nobody will turn it on. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Wireless at IETF
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ted Faber > On Wed, Jan 18, 2006 at 02:23:49PM -0500, Steven M. Bellovin wrote: > > In message <[EMAIL PROTECTED]>, Ted Faber writes: > > > > > > > > >On Wed, Jan 18, 2006 at 10:30:31AM -0800, Hallam-Baker, > Phillip wrote: > > >> The result is that 70% of wireless access points are > open and can > > >> be used by Internet criminals to achieve anonymous access. > > > > > >Loaded statement? Check. > > >Precise statement? Check. > > >Supported statement? H. > > > > > > > I'm not sure which part your claiming is unsupported; my > own informal > > measurements agree with the 70% number. I'm not at all > convinced that > > "Internet criminals" use such access points as a major means of > > access, though. > > Well, none of it's supported. Your statement above about > informal measurements is support for your statement of 70% > and indirectly of his. The figure came from a presentation at an (anti-) Internet crime meeting. I do not remember the source. Although I do have similar concerns about figures like that being repeated without verification it is certainly believable and compatible with my own experience. > Going from an open access point to anonymous criminal access > seems much more implausible to me. There are all sorts of > hurdles one could put up between "no link level protection" > and "anonymous criminal access." But again, I'm wrong all > the time and a citation for that much more damning statement > would be very welcome. Without one I feel like I'm watching > local news. As for the use made by criminals, that has been documented and the frequency is increasing. In one case in Toronto a pedophile was caught surfing the Internet from his car with no trousers on... We see quite a few script kiddie level hackers using open WiFi connections. It would not have been difficult to design WiFi in such a way that it was secure by default. None of the mechanisms provided to consumers has met that requirement. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Location Types Registry' to Proposed Standard
On Wednesday, January 18, 2006 08:30:56 AM +0100 Harald Tveit Alvestrand <[EMAIL PROTECTED]> wrote: I oppose approval of this document as-is. Four reasons: 1) FCFS is inappropriate 2) The document gives inadequate context for use 3) The document gives inadequate procedures Agree. 4) The definition of "automobile" is wrong Eh. It's a protocol constant; they can define it however they want. As long as they let me register 'wyoming' to mean the entity is in a fictional location. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wireless at IETF
On Wed, Jan 18, 2006 at 02:25:56PM -0800, Hallam-Baker, Phillip wrote: > > Well, none of it's supported. Your statement above about > > informal measurements is support for your statement of 70% > > and indirectly of his. > > The figure came from a presentation at an (anti-) Internet crime > meeting. I do not remember the source. > > Although I do have similar concerns about figures like that being > repeated without verification it is certainly believable and compatible > with my own experience. I am being something of a stickler, which isn't your fault. I actually agree with the number's plausibility if it's a measure of networks run without any authentication at the link level. I certainly think the technology is much more insecure than it needs to be. > > > > Going from an open access point to anonymous criminal access > > seems much more implausible to me. There are all sorts of > > hurdles one could put up between "no link level protection" > > and "anonymous criminal access." But again, I'm wrong all > > the time and a citation for that much more damning statement > > would be very welcome. Without one I feel like I'm watching > > local news. > > As for the use made by criminals, that has been documented and the > frequency is increasing. In one case in Toronto a pedophile was caught > surfing the Internet from his car with no trousers on... We see quite a > few script kiddie level hackers using open WiFi connections. One pedophile: check. :-) I'm not sure that the pedophile surfing the net from his paid-for DSL line is any better from a societal perspective, but it might make prosecution easier. I think that predatory behavior does not come disproportionately from WiFi users who gain access through hacking open access points. I can't support that, but my guess is that people tend to stay out of public when committing acts they know to be frowned on by most. It certainly would have been the best interest of the fellow in your example to have been in private. The script-kiddie attacks on WiFi installations are much more on point, IMHO. That's a denial of service that is only possible because the securty system of the media was screwed up. It's much less melodramatic than the fellow wardriving with no pants, though. > It would not have been difficult to design WiFi in such a way that it > was secure by default. None of the mechanisms provided to consumers has > met that requirement. Secure design is usually difficult in my experience, but I agree that it's unfortunate that we didn't do better and haven't really done better. But the situation really is bad enough without adding half-naked pedophiles to the mix. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpMrGw519RTD.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'A Roadmap for TCP Specification Documents' to In formational RFC
If we can make positive comments, I think this is a really useful document to have... -- Eric --> -Original Message- --> From: [EMAIL PROTECTED] --> [mailto:[EMAIL PROTECTED] On Behalf Of The IESG --> Sent: Wednesday, January 18, 2006 4:39 PM --> To: IETF-Announce --> Cc: [EMAIL PROTECTED] --> Subject: Last Call: 'A Roadmap for TCP Specification --> Documents' to Informational RFC --> --> The IESG has received a request from the TCP Maintenance --> and Minor Extensions --> WG to consider the following document: --> --> - 'A Roadmap for TCP Specification Documents ' --> as an Informational RFC --> --> The IESG plans to make a decision in the next few weeks, --> and solicits --> final comments on this action. Please send any comments to the --> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-01. --> --> The file can be obtained via --> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-road --> map-05.txt --> --> --> ___ --> IETF-Announce mailing list --> IETF-Announce@ietf.org --> https://www1.ietf.org/mailman/listinfo/ietf-announce --> ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
Some additional comments on closer reading and a general comment:
This registry intentionally (if you look at the RPID document) is not
meant to directly extend the RPID schema. I suppose that one could
add that any location types added automatically become XML elements
in the urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if
that's appropriate. I think it's appropriate (and necessary to add)
that any registrations must be legal XML element names.
2) Inadequate context for use:
The document does not make reference to RPID, except in
"acknowledgement". Thus, it has to be interpreted as stand-alone,
and must contain its own guidance. RPID states:
These things guide the usage of place-types in RPID, but cannot be
found from the registry document.
Since usage will strongly depend on the context and since this
registry is not limited to RPID, I think this would belong into RPID
(or other documents), not the registry.
This document SHOULD give guidance for usage, saying at least:
- whether it's intended that several of these values can be used
together
I'd assume yes, in general, but defining that seems to be the role of
the protocol using these elements, not a registry.
I think of the registry like a dictionary. A dictionary does not
define which words you can use together.
- whether it's intended that a sequence of location types gives a
progressively more precise set of terms (in which case
internationalizing the last type you understand is appropriate) or
names an intersection of the classes (in which case you would have
to internationalize all of them).
There is no implication of hierarchy. In general, this seems
difficult to achieve since not all location types are hierarchical.
For example, an airport might contain a bank or a shopping-area, but
that does not make either a subcategory of an airport.
I also don't understand the need for I18N, since these are tokens
that would be translated by a local application, not rendered to users.
- whether having a text string alongside it (the "note" above) is a
recommended practice.
That's again an RPID issue. Not every protocol using these tokens
will have notes.
It MAY be appropriate to say something about field of use, like
RPID does ("what types of communication is appropriate" would lead
one to distinguish between "driving a car" and "passenger in a
car", while one could imagine that other usages might want to
distinguish between "expensive restaurant" and "cheap restaurant").
We are not trying to define a service location protocol that
describes numerical properties of locations. I don't know how to rule
this out by legal wording; presumably the expert reviewer can make
common-sense judgement.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Transport layer Protocol Implementation in GLOMOSIM
Hello all; I am student doing My BE in Electronics & Communication Engg. I am starting My BE Final project on stimulation of a Transport layer protocol. The protocol is proposed for mobile multimedia communication over wireless links.I am considering to use the network simulator - GLOMOSIM. Since I am a beginner in the Glomosim. I don't know where to start and how to modify it to make it suit my purpose. please help. Thank you. ~~ << JAGDEESH PRASAD >> ~~ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Transport layer Protocol Implementation in GLOMOSIM
Hello all; I am student doing My BE in Electronics & Communication Engg. I am starting My BE Final project on stimulation of a Transport layer protocol. The protocol is proposed for mobile multimedia communication over wireless links.I am considering to use the network simulator - GLOMOSIM. Since I am a beginner in the Glomosim. I don't know where to start and how to modify it to make it suit my purpose. please help. Thank you. ~~ << JAGDEESH PRASAD >> ~~ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Standard
A different question: Henning Schulzrinne wrote: Some additional comments on closer reading and a general comment: This registry intentionally (if you look at the RPID document) is not meant to directly extend the RPID schema. I suppose that one could add that any location types added automatically become XML elements in the urn:ietf:params:xml:ns:pidf:rpid namespace. I don't know if that's appropriate. Doesn't this make it hard/impossible to check if an RPID document is schema-valid? (I mean keeping some element names in a list that's not a schema.) Perhaps that's not important for this application though. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
