Re: Proposal to define a simple architecture to differentiate legitimate bulk email from Spam (UBE)

[Bill Strahm]

Why is this even difficult.  I have yet to see a firm proposal (ie. an
Internet Draft), and once there is one, it is a simple matter of asking an AD
to sponsor a BOF to see if there is interest in forming a working group to 
solve the problem.  I remember sitting through several YATP (Yet another
Tunnelling Protocol) BOFs years ago, I don't see what the problem is with
creating some YASPP BOFs (Yet Another Spam Prevention Protocol).

This is the IETF, that is the IETF process... Why are we arguing here about
killing it without having a firm proposal, and a BOF chartered to form a WG
to go solve the problem.  Any more breath we waste now doesn't help anybody.

My challenge - Go forth - publish your protocol in ID form, contact the 
correct APP (probably) area AD and get a BOF in Minneapolis - Convince the
IETF in general there that a WG should be chartered to solve the problem.
Go and solve the problem

Bill

On Tue, Sep 09, 2003 at 01:41:33PM -0400, Dean Anderson wrote:
> My apologies for this message.  This discussion is winding down. Iljitsch
> makes some interesting points, to which I have tried to respond
> thoughtfully.
> 
>   --Dean
> 
> On Tue, 9 Sep 2003, Iljitsch van Beijnum wrote:
> 
> > On maandag, sep 8, 2003, at 17:30 Europe/Amsterdam, Dean Anderson wrote:
> >
> > >> Nobody cares. Making a roof 100.00% impervious to water molecules
> > >> may be impossible, but that doesn't mean we have to resign to getting
> > >> wet every time it rains.
> >
> > > People care because when someone comes around saying "you can have a
> > > 100%
> > > impervious roof if only you jump through these inconvenient hoops", we
> > > know that they are wrong, and don't need to waste time considering how
> > > inconvenient the hoops are.
> >
> > Your analogy doesn't fly. Our email protocols have holes big enough to
> > drive a truck through. Is it unreasonable when people ask the IETF
> > leadership for a place to work on this?
> 
> I don't think our email protocols have any holes at all. They can be
> abused. But mere abuse is not a "hole".
> 
> > > "We", meaning the IETF, care, because this is very useful aid to
> > > deciding what to work on. We know that we need to focus on leak
> > > stoppage, not trying to invent leak-proof protocols.  There is no
> > > point researching something that is impossible.
> >
> > Let's first define our goal before declaring it impossible to reach.
> 
> Well, I think the goal has been stated: Create an abuse-free email
> protocol.  That goal is impossible. Thus, we have abusable protocols.
> 
> Perhaps you have a different goal in mind, but it doesn't sound like you
> accept the premise that it impossible to create an abuse-free protocol.
> 
> > >>> After I first posted this on IETF a while back, someone suggested
> > >>> that covert channels require cooperation, and that spam therefore
> > >>> isn't a covert channel.
> >
> > >> Where does this covert channel stuff come from anyway?
> >
> > > What do you mean?
> >
> > The jump from "spam" to "covert channel" isn't immediately obvious. And
> > if any proof of why spam is a covert channel has been offered, I've
> > managed to miss it.
> 
> The NCSC's definition refers to ANY communication not authorized by the
> security model.  Note that the term "Covert Channel" is frequently
> associated with Multilevel Secure Operating Systems. The liturature uses
> other terms to describe the same concept: "information leakage", "sneaky
> signalling", "hidden data flows", "side channels". So you must not get too
> caught up in the peculiarities of operating systems.  The concept is quite
> general.
> 
> It is immediately obvious that covert channels have 3 characteristics: It
> is a CHANNEL, it is COVERT, and it VIOLATES SECURITY POLICY. (Caps for
> emphasis of definition, not loudness.)
> 
> 
> CHANNEL:  Spam is a type of Email. Email is a channel transfering signals
> from A to B. Email is really a subchannel of the internet, which is a
> subchannel of the PSTN, public and private fiber networks, etc.
> 
> COVERT: Spam is hidden in so far as possible from the system operators. It
> is an unintended communication in that the system operators intended that
> only non-broadcast, solicited commercial communication flow. This not an
> exclusive list of what is permitted, but illustrates that spam isn't
> permitted.
> 
> VIOLATES SECURITY POLICY:  System Operators specified an acceptable use
> policy that outlines what is permitted and what is not permitted. UCE is
> not permitted.  Various methods have been implemented to enforce this
> policy.
> 
> 
> > >> the spammer's achilles heel is that they need to send out incredible
> > >> amounts of email in order to fulfill their objectives, whichever
> > >> those are. Detecting bulk mail is doable, and it shouldn't be too
> > >> hard to come up with something to differentiate legitimate bulk
> > >> emailing from spam. For instance, we can reverse the burden of proof
> > >> here and only allow

Re: Proposal to define a simple architecture to differentiate legitimate bulk email from Spam (UBE)

[Bill Strahm]

Very nice.  I say to post an Internet Draft - you post a link to a simple 
archived e-mail.  The IETF process starts with an Internet Draft - without it
we are all just wasting time.  An internet draft is a concrete proposal that
can be discussed, archived, debated successfully, etc.

I challenge you to take your e-mail posting and turn it into an Internet Draft
with a legitimate security section (since you are solving a security problem)
then post a single message to this list showing the internet draft, and a
mailing list that people can join if they are interested in discussing it
further.  

>From there it is easy to determine if there is enough interest in forming a BOF
in Minnesota ( or S. Korea in March ) to forward the work in a Working Group.

The problem you have run into is you haven't taken the first step, which is to
simply submit an Internet Draft to the Internet Drafts editor... very simple
process with no politics in the way.  From there you can pursue forming a 
Working Group (where you will get your first taste of politics).  Being that
you haven't taken the first step (publishing an Internet Draft) I am not sure
you "really" meet the charter (Ok, yes you do, but putting out a draft is SO
important - it should be the first step) and you have allowed the topic to grow
WAY beyond initial discussions (I am actually waiting for Harold to post one
of his famous Top n Talker lists soon).  The next step is to get a mailing
list somewhere and move the discussion off of this list onto that list

Bill
On Wed, Sep 10, 2003 at 05:10:06AM +0800, Shelby Moore wrote:
> >Why is this even difficult.  I have yet to see a firm proposal (ie. an
> >Internet Draft),...
> >My challenge - Go forth - publish your protocol in ID form...
> 
> 
> 1. I remind you to read my initial post that started this thread:
> 
> http://www1.ietf.org/mail-archive/ietf/Current/msg22035.html
> 
> "Request for opinions on whether to creating a working group or publish the 
> following idea as an internet draft?"
> 
> I think that qualifes under "initial discussion" of the charter of this list (see #2 
> below).
> 
> 
> 2. And to read the charter for this mailing list:
> 
> http://www.ietf.org/maillist.html
> 
> "This list is meant for initial discussion only. Discussions that fall within the 
> area of any working group or well established list should be moved to such more 
> specific forum..."
> 
> 
> 3. Just a fews posts back in this thread, it was suggested that IRTF would be a 
> better forum for anti-spam proposals and discussions, and I agreed (to consider it 
> if possible and applicable).
> 
> However there is a another line of discussion in this thread pertaining to general 
> information theory and modeling of channels which is still winding down ("initial 
> discussion") and seems quite general to internet engineering.
> 
> 
> 4. The basic difficulty has been those violating the charter of the list:
> 
> http://www.ietf.org/maillist.html
> 
> "Unprofessional commentary, regardless of the general subject." such as the "Kook" 
> thread offshoot that someone started.
> 
> Shelby Moore
> http://AntiViotic.com

Re: Adding [ietf] considered harmful

[Bill Strahm]

Hmmm,

I am wondering if running this e-mail thread is adding a couple years worth of 6byte 
additions to the subject.

Seems silly to me - I prefer lists to do this - makes many peoples life easier - 
doesn't make anyones life harder (and frankly if 6 bytes is going to blow your 
bandwidth budget - you have worse troubles than this proposal)

Please consider this as someone who thinks it is a good idea because some people want 
it - regardless if they can jump through 10 more hoops and get the same functionality 
with filters (on what ? - I hate it when people bcc: mailing lists and you loose the 
from/cc field containing the mailing list you are filtering on) - procmail (oppps what 
about the people that don't use that, etc.

Bill
On Thu, Dec 18, 2003 at 10:39:21AM +1200, Franck Martin wrote:
> Because we, people on the road, use various mail systems and even web
> based mail, where the filters are not applied yet...
> 
> Why such a war for just 6 characters, while all mailing lists do it?
> 
> Have you been out there?
> 
> Let's give it a try and see...
> 
> Cheers
> 
> On Thu, 2003-12-18 at 04:26, Keith Moore wrote:
> 
> > > 
> > > would it be asking too much to add [ietf]  to the subject line of each message?
> > 
> > yes.  it's completely redundant information, and it interferes with readability,
> > particularly on small displays.
> > 
> > why don't you get a better mail reader that lets you classify mail as it arrives?
> > that is a much better way to distinguish one list's traffic from another.
> 
> 
> Franck Martin
> [EMAIL PROTECTED]
> SOPAC, Fiji
> GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
> "Toute connaissance est une reponse a une question" G.Bachelard

Re: I-D ACTION:draft-etal-ietf-analysis-00.txt

[Bill Strahm]

On Thu, Mar 28, 2002 at 03:31:05PM -0500, John Stracke wrote:
> >John Stracke wrote:
> >> And the authors do caution that their numbers are blind to the quality 
> of 
> >> the RFCs.  Their point, though, is that looking at the easy metrics is 
> >> better than not measuring anything at all;
> >
> >Wrong information is worse than no information. If the results don't 
> >mean anything,
> 
> They don't mean *much*, but I wouldn't say they mean *nothing*.
> 
> >why measure?
> 
> As a research effort.  The current draft admits that the results are not 
> directly useful.  But we'll never get techniques that do give useful 
> results unless somebody starts trying.
>
An interesting problem with measuring, is that you tend to get what you measure for.  
If the purpose of the IETF is to push out large quantities of RFCs, then this is of
course a great metric.  If the purpose of the IETF is to push out a small number of
high quality drafts, this is not the metric to use.

I am reminded that early in my career I was in a company that was driven by the 
KLOC metric.  They had determined that the product would have 150ish KLOC in it
and so had every programmer report the number of KLOC they had contributed that week.

One week I was looking through the code I had inherited and realized that I had two
copies of a set of utilities that did the same code.  I spent a day or two removing
one set, and porting that half of code to use the other set of utilities (Basically
I had inherited two developers code).  Well my KLOC for the week was somewhere in 
the -10 range, and it was a month before I started going positive again.  My reviews
sucked, but it was the right thing to do.

Becareful what you measure, because that is the behaviour you will get

Bill 

Re: draft-iab-unsaf-considerations-01.txt

[Bill Strahm]

Pretty much any of the large providers that only provide 
10/8 addresses to their custommers...
I believe AOL for one does this and it wouldn't surprise me if 
most of the large cable providers do something silly like this
at the low end (You can always pay more for a real IP address)

Bill
On Fri, Apr 05, 2002 at 02:25:49PM -0500, John Stracke wrote:
> >>Also, I think it would be helpful to know how commonly twice-NAT is
> >>deployed, but I don't have any data there.
> >
> >I believe (at least) twice-NAT is fairly common. I have a NATting router
> >between by cable access modem and my home's local area network, and my
> >cable access provider has a NATting router between the cable access
> >network and the public internet.
> 
> What cable provider is this, so that we can avoid them?
> 
> /\
> |John Stracke|Principal Engineer |
> |[EMAIL PROTECTED]   |Incentive Systems, Inc.|
> |http://www.incentivesystems.com |My opinions are my own.|
> ||
> |See what bilateral symmetry can do for YOU! |
> \/
> 

Re: IPR at IETF 54

[Bill Strahm]

On Thu, 30 May 2002, RJ Atkinson wrote:

>
> On Thursday, May 30, 2002, at 09:48 , Melinda Shore wrote:
> > Here's one for starters: there's no guidance on how or whether to
> > treat differences in licensing terms for competing proposals.  It
> > would be nice to be able to say that all other things being more-or-
> > less equal we should prefer technology which will be available
> > royalty-free,
>
>   Agree.
>
>   My druthers would be to have an IETF policy explicitly saying that
> the first
> choice is to use unencumbered technology if it can be made to work,
> second choice
> is encumbered but royalty-free technology, and last choice is "fair and
> reasonable
> licence terms" (or whatever the equivalent correct legal wording might be
> for that last).
>
>   And it would be good to have a conventional template for the
> royalty-free
> licence -- one that the IETF's legal counsel has reviewed and believes
> is acceptable
> for IETF purposes.
I disagree with this, I don't think the IETF can afford to keep a staff of
lawyers working on determining the licencing statements of all of the
standards being churned out.

That said, I don't think it would do any good anyway, lets say the IETF
lawyer gives his Okey Dokie, then my company implements the standard and a
problem with the licencing terms comes up... Who do I go sue, the IETF ???

I hope not, but that could be creating a legal liability for the IETF if
its lawyers make statements on the licencing terms of protocols...

Bill

RE: modems

[Bill Strahm]

I'll go a little farther...

Common configurations for modems leave the speaker on during
handshaking, but turn it off during normal data traffic...

When I was doing a lot of modem programming I remember there were ATA
commands that would turn off the speaker, or leave it on all the time...
Really want to annoy a coworker, leave their modem configured not to
turn off the speaker...

Now the shrieking is basically the sound protocol that lets both ends
know how to communicate... Each sound has its own meaning and I believe
is still backwards compatible to 300 baud... (Haven't played with modems
since the 14.4 days myself though, so that could have changed with the
56K modems)

There are some good books on the topic depending on what you want to
know

Bill
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
David Frascone
Sent: Tuesday, June 11, 2002 7:47 AM
To: Pankaj Bhandari
Cc: Bill Cunningham; [EMAIL PROTECTED]
Subject: Re: modems

Ummm . . . how 'bout:  During handshaking the modem's speaker is on.



On Tuesday, 11 Jun 2002, Pankaj Bhandari wrote:
> Screeching occurs during handshaking.
> 
> During the handshaking, the frequency is audible, thats the reason for
screeching.
> 
> 
> > -Original Message-
> > From:   Bill Cunningham [SMTP:[EMAIL PROTECTED]]
> > Sent:   Tuesday, June 11, 2002 12:53 PM
> > To: [EMAIL PROTECTED]
> > Subject:modems
> >
> > I know modems communicate on the physical layer by electrical pulses
or
> > binaries sent on copper wires. Is that screeching you hear
electrical
> > communication? Computers don't communicate by screeching...or do
they?
> >
> 

-- 
David Frascone

   Winston Peters, a rebel without a caucus.

RE: postings to ietf mailing lists

[Bill Strahm]

Can't say about other maillist software, but the software that runs the
@ietf.org lists allows this, you can subscribe from as many addresses as
you want, and only get mail sent to a single address...

This works well for people that can't control what their company does as
far as @foo.company.com where foo seems to change quite a bit...

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, June 12, 2002 5:31 AM
To: [EMAIL PROTECTED]
Subject: postings to ietf mailing lists

i have noticed that some ietf working groups don't anymore allow
postings except from addresses that have subscribed to the list.  this
not good unless there is a way to register another email address from
which postings are allowed.  the reason is that many people don't want
to get any mailing list traffic to their personal mail boxes and
therefore have subscribed an alias rather than their own personal email
address.

could it be made a policy of ietf mailing lists to include support for a
posting address that is not the same as subscription address?  some
mailing lists already do this, but not all.

-- juha

RE: ECN and ISOC: request for help...

[Bill Strahm]

I don't see why this is embarrasing.  I have no problems with people
setting up filtering rules that say DENY-ALL accept packets that I
EXPLICITLY know what every bit does, and I want to allow it...

That said, ECN is a relatively recent addition to the suite and I
wouldn't expect all firewalling rules to be setup to use it (I believe
that some of the bits involved have been used by other experimental
protocols for other things).  For this reason I don't think this
behavior is as bad or embarrassing as you think it is.  

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Franck Martin
Sent: Tuesday, July 23, 2002 10:17 PM
To: 'Gary E. Miller'; Christian Huitema
Cc: ietf
Subject: RE: ECN and ISOC: request for help...


I'm not in a campaign to promote ECN, or anything... I'm saying that
ISOC web site is not reachable if you enable ECN, which RFC793(standard)
or RFC3168(proposed Standard) talk about.

I don't want to talk about what is a standard or what is not... What is
compliant or not...

Will there be anybody to volunteer and fix the routers leading to ISOC
web site, mailing lists, e-mail addresses and so on?

This is what my message is all about. Please IETF members in Washington
DC, Area, please give a call to ISOC and offer some help...

This is embarrassing, that's all

Cheers.

Franck Martin
Network and Database Development Officer
SOPAC South Pacific Applied Geoscience Commission
Fiji
E-mail: [EMAIL PROTECTED]  
Web site: http://www.sopac.org/
 Support FMaps: http://fmaps.sourceforge.net/
 
Certificate: https://www.sopac.org/ssl/ 

This e-mail is intended for its addresses only. Do not forward this
e-mail without approval. The views expressed in this e-mail may not be
necessarily the views of SOPAC.



-Original Message-
From: Gary E. Miller [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 24 July 2002 3:02 
To: Christian Huitema
Cc: ietf
Subject: RE: ECN and ISOC: request for help...


Yo Christian!

Actually, RFC 3168 has nothing to do with it.  The issue is RFC 793.

RFC 793 is a "Standard", not a "Proposed Standard"

RFC 793 lists the bits later used by ECN as "Reserved".  Computer
programs are supposed to ignore "Reserved" bits unless they really know
what they are doing.

If a router treats bits in the header as required by the STANDARD RFC
793 then RFC 3168 will cause no harm.I do not have a copy of Baker
handy, but I bet it agrees.

RGDS
GARY

---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Tue, 23 Jul 2002, Christian Huitema wrote:

> So, if you are on a campaign to promote ECN, then maybe you should 
> first try to promote this specification to the next standard level... 
> You may also want to take a stab at revising the "Requirements for IP 
> Version 4 Routers"; the last edition, RFC 1812 by Fred Baker, dates 
> from June 1995.

RE: Report on Peering and Transit Economics (etc)

[Bill Strahm]

All I have to say is "WOW" A three page executive summary.  I am afraid
to read the rest... Guess I will have to see what is going on especially
when they start talking about ICANN (At the VERY bottom) I'd love to
know how that fits into Peering and Transit economics


Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Gordon Cook
Sent: Sunday, September 29, 2002 9:46 AM
To: [EMAIL PROTECTED]
Subject: Report on Peering and Transit Economics (etc)


I have published an extremely detailed report on the economics, 
technology, and politics of peering and transit.  At 
http://cookreport.com/11.08-09.shtml you will find the complete 
introductory article, contents and  list of 25 contributors to the 
effort.  The report centers on interviews with Bill Woodcock, an 
essay / critique by Farooq Hussain and an edited version of the 6 
weeks of discussion by the 25 contributors.

I  include here the executive summary from the report.  This summary 
is not on my web site and I am not posting it elsewhere.

Executive Summary

Whither the Policy, Technology, and Economics of the Interconnection 
of the Internet?

The collapse of the industry and of the price of bandwidth is 
bringing significant changes into the ways in which ISPs and the 
remnants of the Old Guard of Tier 1 backbones interconnect.

Some people who are affected have made some significant steps in 
using NetFlow data in developing tools that are being refined into 
what can function as bandwidth cost management systems.  We identify 
several explorations being taken in this direction and explore what 
looks to be the most refined developed by Bill Woodcock with the 
assistance of Alex Tudor at Agilent Labs.

Bill has developed a philosophy of interconnection that appears to 
have a sound  business model behind it.  Bill's approach was 
developed from the point of view of a small ISP that needs to 
understand with as much precision as possible what it does cost to 
get its bandwidth delivered.  His model says that ISPs that are 
multi-homed and have their own leased line customers need to peer as 
much and as cheaply as possible.  They also need to have two reliable 
transit providers in case one fails.  As long as their peering can 
cut over to transit if it fails, he points out that economics would 
seem to demand delivery of as much bandwidth by cheap peering as 
possible to cut down on the requirement for expensive transit 
bandwidth.

ISPs need to avoid local loop charges from their LECs and acquire 
their own back haul to an exchange for inexpensive peering and if 
possible a different exchange or exchanges for more reliable transit. 
In order to figure how to most cost effectively architect their 
networks they need to take and manipulate NetFlow samples of their 
traffic in order to identify potential new peers via a study of the 
traffic being delivered by their transit providers.  If they have 
automated tools to take samples from appropriate points, they can 
over time get clear pictures of how their traffic is evolving through 
actual NetFlow path analysis.

But Woodcock's colleagues seem to agree that he has done something 
unique.  He explains it in writing for the first time in this issue 
of the COOK Report.  Namely he does what he calls synthetic path 
analysis by tacking his actual path data and doing a series of "what 
if" transformations on that data.  With the help of Alex Tudor from 
Agilent labs he explains using actual data from January 31 2002 how 
this synthetic analysis can be applied so that for the first time an 
ISP, by plugging circuit cost data into its modeling software, can 
know how much it really does cost to deliver its bits.

These ideas are new. While our experts agreed that perhaps 100 ISPs 
may be doing some form of actual NetFlow data analysis, virtually no 
one except Woodcock had done the synthetic path analysis.  Avi 
Freedman in his position as Chief Network Scientist at Akamai has had 
ample occasion to use network routing and DNS to figure out data 
flows.  After studying Bill Woodcock's explanation found that he had 
evidence from his own related experience that indicated Bill's 
approach seemed valid. He points out that since 1999 he has been 
doing a "what if" analysis on "Akamai flows" similar to Woodcock's 
synthetic path analysis on router flows.

Our 50,000 word eight week long discussion involving 25 different 
people contains a quite interesting dialog between the Avi and Bill 
as they compare their approaches to the problem and conclude that the 
ideas appear to be valid. However, we must also point out that Bill's 
synthetic path analysis is not meant to be  the sole criterion on 
which to base peering and transit decisions.  Once they have 
identified potentially good peers, ISPs will find that factors of 
geography and costs of interconnection at various exchanges may 
become decisive factors in making their final decisions.

Although the largest c

RE: TCP/IP Terms

[Bill Strahm]

I always figured it was based on the number of managers that you have on
the project, one manager for each layer...  At least that is how it was
done at a previous company I worked for...



Models are very nice to help you get people to think about something the
same way.  Of course the best engineers that I know, understand the
model, but think way outside it... Letting unique solutions that break
the model, but deliver better results...

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave
Crocker
Sent: Tuesday, October 08, 2002 12:25 PM
To: Robert Elz
Cc: [EMAIL PROTECTED]
Subject: Re: TCP/IP Terms 


At 11:38 PM 10/7/2002 +0700, Robert Elz wrote:
>Attempting to give these things absolute numbers, other than for ease 
>of reference in some particular context is lunacy.

Not that I disagree with your primary point, it is worth noting that
there 
is some basis for hovering about 7, for an *overall* model.

It's that memory limit thing (7, plus or minus 2.)  The plus or minus is

statistical, so if you want to make sure that people really have no
trouble 
grokking the total set, 5 is a better choice.

d/


Dave Crocker 
TribalWise, Inc. 
tel +1.408.246.8253; fax +1.408.850.1850

RE: Palladium (TCP/MS)

[Bill Strahm]

Well the first thing you have to realize is that there is no such thing
as TCP/MS, and there for any answer you get would be highly speculative
at best.

This is a huge red herring, based on speculation that for some unknown
reason, Microsoft will Embrace/Extend/Extinguish the IP protocol and
successfully be able to put their own protocol (MS) onto the internet in
such a way that you will be required to use a MS product to use the
internet...

I don't know about you but I find the whole scenario dubious at best,
and this whole thread is becoming a massive troll

Bill
(Who is getting ready to take his lunch and eat it rather than feeding
trolls)

-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-ietf@;IETF.ORG] On Behalf Of Sean
Jones
Sent: Wednesday, October 23, 2002 1:38 AM
To: [EMAIL PROTECTED]
Subject: RE: Palladium (TCP/MS) 


Good Morning Valdis

Thank you for your prompt reply. Perhaps I did not phrase my question
properly. 

I know what PTR records are, I know how TCP/IP works & etc (I've done a
routed IP network or two, and worked at an ISP for a while) so please
let me re-phrase my question.

Why is a PTR (or DNS) record with MS TCP different from the standard
TCP/IP record? 

(Perhaps it is me in my ignorance, or lack of understanding :o) )

Regards

Sean

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:Valdis.Kletnieks@;vt.edu]
> Sent: 22 October 2002 18:39
> To: Sean Jones
> Cc: [EMAIL PROTECTED]
> Subject: Re: Palladium (TCP/MS)
> 
> 
> On Tue, 22 Oct 2002 16:42:03 BST, Sean Jones said:
> > Forgive my ignorance, but what the heck do you mean?
> 
> % dig -x 207.46.230.218
> 
> ;;  ANSWER SECTION:
> 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.com.
> 218.230.46.207.in-addr.arpa. 2665 INPTR microsoft.net.
> 218.230.46.207.in-addr.arpa. 2665 INPTR 
> www.domestic.microsoft.com.
> 218.230.46.207.in-addr.arpa. 2665 INPTR www.us.microsoft.com.
> 
> Of course, it isn't that simple - those 4 PTR entries each
> point back at a
> multihomed host. I was about ready to throw a yellow flag and a 5-yard
> procedural penalty until I double-checked RFC2181, section 
> 10.2 - that's legal.
> 
> Gonna need a lot longer ACL on that Cisco to actually make it
> work (don't
> forget all their msft.net servers.
> 
> Bringing it back to IETF territory now:  Is there a need for
> an RFC for
> "best practices" in securing the download of software updates (DNSSEC,
> PGP signatures, etc)?  The two scariest things about online 
> updates (at least
> while wearing my security hat) are the MITM attack (as 
> demonstrated against
> Apple) and the hacked download attack (as has hit 
> windowsupdate, openssh,
> sendmail, and others).  If it's WG fodder, I'd specifically 
> declare the
> question of whether the patch *works* as off-topic - the task 
> is merely
> verifying that the bits are the correct bits, and from the 
> correct vendor.
> -- 
>   Valdis Kletnieks
>   Computer Systems Senior Engineer
>   Virginia Tech
> 
> 

RE: namedroppers mismanagement, continued

[Bill Strahm]

Keith,
I almost agree with you... Except here is the problem...

The [EMAIL PROTECTED] mailing list has 17 request(s) waiting for your
consideration at:

https://www1.ietf.org/mailman/admindb/ipoverib

I'll go ahead and remove the 17 messages trying to sell sex, toner
cartridges, stuff in char sets I don't even know what they are...

No I don't want random people sending stuff to a low volume list ( a
couple messages a week is normal ) so I think asking people to subscribe
is a low overhead task... You don't even have to receive the mail
traffic.

It is also not in the communities interest to slog through 100's of
spams to find a usefull nugget of truth either.

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Keith Moore
Sent: Tuesday, November 26, 2002 6:41 AM
To: Eliot Lear
Cc: D. J. Bernstein; [EMAIL PROTECTED]
Subject: Re: namedroppers mismanagement, continued


>   Join the list already.  How hard is that for a so-called mail guru?

there are valid reasons to post to a list when you're not subscribed, or
from a different address from the one you use for your subscription.

and it's not in the community's interest to ignore useful input.

RE: namedroppers mismanagement, continued

[Bill Strahm]

Ok... I have to know...

Randy,

Can you please put [EMAIL PROTECTED] on the approved posters list for
namedroppers ?

Isn't it as simple as that ?

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Keith Moore
Sent: Thursday, November 28, 2002 10:18 AM
To: Erik Nordmark
Cc: [EMAIL PROTECTED]
Subject: Re: namedroppers mismanagement, continued 


> If folks need to post all the time from a different
> address than their subscription address *they* should take the step to

> get that posting address added to the approved posters list.

that might be fine, except

- in the current situation, even postings from occasional posters 
  are being blocked.  and when postings are blocked, the message is 
  terse and cryptic (even insulting) and contains no clue about how 
  to workaround the problem

- getting on the "approved posters" list is not well documented or
  understood.  for some list software this is a manual operation 
  requiring the list admin to edit a file; on others it is under
  control of the subscriber but he/she has to "subscribe" the alternate
  address using some obscure option like /NOMAIL.
 
I've run several IETF lists myself and I know how much of a pain it is
to filter out spam.  Yes, the process is error prone.  Yes it's 
a pain to keep approving posts from the same person (though it's 
easy to fix that problem, and no I don't think adding that person to an
approved posters lists is assuming too much).  And yet I still don't
think that namedroppers is being managed appropriately.

Can we please fix this problem which has gone on for several years and
stop pretending that this behavior is acceptable?

Keith

RE: namedroppers mismanagement, continued

[Bill Strahm]

I don't know about others, but I use the IETF mailing list service to
manage the list.  If you want to send a message all it takes is a
subscribe, but please don't send me any e-mails... Very easy to do with
a Webpage...

This only guarantees that I won't see your mail and possibly make a
mistake, hopefully I don't make too many mistakes, but I am human

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 26, 2002 2:33 PM
To: [EMAIL PROTECTED]
Cc: 'Keith Moore'; [EMAIL PROTECTED]
Subject: Re: namedroppers mismanagement, continued


> No I don't want random people sending stuff to a low volume list ( a
> couple messages a week is normal ) so I think asking people to
> subscribe is a low overhead task...

I understand where you are coming from, but too many IETF working
groups' output has suffered from lack of outside input.  Certainly it's
reasonable to expect frequent contributors to at least get on an
"allowed posters" list, but it's not reasonable to exclude occasional
input from others.

Keith

RE: namedroppers, continued

[Bill Strahm]

Silly question,

But you DO know what it will take to get your message to be immediately
seen by the list, you just aren't willing to do it... 

I believe the problem is in your court, easily solved and it is not time
to move on to something that might be slightly productive

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of D.
J. Bernstein
Sent: Friday, November 29, 2002 3:22 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: namedroppers, continued


Keith claims that allowing ``contributions from outsiders'' requires
delay and manual review. That claim is absurd. Immediately bounce the
message to the ``outsider,'' with instructions explaining how to have
the message sent to subscribers; end of problem.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

RE: Reminder: Deadline for input on sub-ip discussion

[Bill Strahm]

I have an interesting set of questions for you Harold,
1) How effective would the IESG be with 2 more members, more effective,
or less
2) What would happen to any "new" IESG members in the SUB-IP area, if
the area is shut down ?

In otherwords, does the IESG think that a two new members would help
overall effectiveness, or make it lower

If the consensus of the IESG is that adding more members would make them
less effective go with the victim/temporary route.

If the consensus of the IESG is that adding two members would make the
IESG more effective, lets look at making it permanent, or have a place
to put the extra members when the "temporary" area shuts down.

In other words what makes that IESG more effective 

Bill


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Harald Tveit Alvestrand
Sent: Monday, December 09, 2002 1:22 PM
To: [EMAIL PROTECTED]
Subject: Reminder: Deadline for input on sub-ip discussion


All,

On Wed Dec 4th, we asked for input to help us decide on the future of
the SUB-IP Area. See our posting at

  http://www.ietf.org/mail-archive/ietf/Current/msg18370.html

We had a large majority of people at the SUBIP Area meeting in Atlanta
expressing that they want the area to be long(er) lived. This will be
part of our input.

But we need/want to hear from the IETF community. So please express your
opionion (and the reasoning behind it) asap on [EMAIL PROTECTED], but 
certainly before Thursday Dec 12th 10am US Eastern time.

As expressed in the above posting (with data points and discussion 
included),
the 3 choices for the SUB-IP Area seem to be:

  1/ move WGs (back) to permanent areas: migrate the SUB-IP
 working groups to other IETF areas sometime soon, likely before
next
 summer and close the SUB-IP area. Also, reconstitute the SUB-IP
(and/or
 other) directorates to ensure the continued coordination between
the
 remaining WGs.

  2/ establish a long-term area: decide that the SUB-IP
 area will be a long-term one, clearly define its charter, and ask
the
 nomcom to select one or two people to be Area Directors

  3/ status quo: continue the SUB-IP Area as a temporary,
 ad-hoc effort, much as it has been, with the IESG selecting two
sitting
 ADs to continue the effort that Bert & Scott have been doing. But
maybe
 give more responsibility to the working group's technical advisors,
 normally the AD from the area where the working group might
otherwise
 live.

The opinions expressed so far seem to show clearly that the community is

divided on the issue, with perhaps some preference for the status quo 
(alternative 3).

If you have a strong preference for one (or two) of these, and have not
yet 
said so, please indicate your opinion (and your reasons) by mail to 
[EMAIL PROTECTED] before Thursday.

Thank you!

  Harald Alvestrand, for the IESG

(please repost this message where appropriate)

RE: DNSEXT WGLC Summary: AXFR clarify

[Bill Strahm]

Please god NO...

I hope EVERYONE deeply involved in a WG documentation process has deep
DEEP conflict of interest problems.  I mean if we are not working on the
things we are documenting, how will we know if they work or not.  Saying
that WG chairs can not work for companies that need the efforts of the
WG seems like setting up a big failure, there are checks and balances,
you don't like what the chairs of a WG are doing, talk to the ADs, don't
like what the ADs say go to the IAB... This is a documented process.

I do not know about the DNS WG, but most working groups that I am aware
of also have two co-chairs, usually from different companies/areas - and
I know that my co-chair and I have to be in agreement on "char"
descisions, reducing the effect of one of us having a massive conflict
of interest.

Please do not require conflict of interest rules to enter the IETF, this
isn't the government, we NEED this to work

Bill Strahm

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, December 18, 2002 1:34 PM
To: Stephane Bortzmeyer
Cc: D. J. Bernstein; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: DNSEXT WGLC Summary: AXFR clarify 


On Tue, 17 Dec 2002 10:53:28 +0100, Stephane Bortzmeyer said:
> On Tue, Dec 17, 2002 at 08:58:22AM -,
>  D. J. Bernstein <[EMAIL PROTECTED]> wrote
>  a message of 26 lines which said:
> 
> > DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, 
> > writes:
> 
> For me, this is too much.

Now, on the *one* hand, I'd be surprised indeed if the chair of DNSEXT
had NOT been paid by somebody to do BIND consulting somewhere along the
line.

On the other hand, if Olafur is in fact making a living doing BIND9
development and coding for ISC or one of their clients, that might be
called a "conflict of interest" when the issue at hand is that a
specific document is "too BIND9 specific".

Personally, I'm OK with Olafur making money doing BIND.  I'm even OK on
him possibly making more if the draft becomes an RFC in its current
state.  I admit I've looked through RFC2026 and found nothing about
disclosure of conflict of interest(*).  I hate making more work for the
AD and IESG, but I think at least a "We've talked to Olafur and do/dont
think there's a problem" is called for.

(*) I'll let wiser people than I decide if there should be such a
section in a son-of-2026
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech

RE: DNSEXT WGLC Summary: AXFR clarify

[Bill Strahm]

Well just one person will not be able to create rough concensus, except
in a VERY small group.  Saying that someone MUST be wanting to produce
an inferior document because they were paid to create a product based on
the spec is not fair to any participants.  I claim that MANY, if not
MOST IETF participants are paid one way or another based on the
specifications that they are working on.

If a document has technical problems for the minority of participants
(i.e. the non-rough concensus) this doesn't mean there are technical
problems...

That said I have not heard of anyone who is told... You will get a
(large sum of money) if the draft you have written gets through the IETF
without any changes.  I would assume that anyone who took that as a
bonus stipulation, wasn't expecting to get paid...

I consider it part of my job to monitor the IETF and tell my employer
what I believe the decisions are going to be, what changes might be
coming, and how close to an RFC a given draft is.  

Bill

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, December 18, 2002 3:03 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: DNSEXT WGLC Summary: AXFR clarify 


> I hope EVERYONE deeply involved in a WG documentation process has deep

> DEEP conflict of interest problems.

seems a bit of a stretch.  it's one thing to have an interest in
producing a technically sound outcome; quite another to have an interest
in producing a particular outcome even when it has technical problems.

Keith

RE: Dan Bernstein's issues about namedroppers list operation

[Bill Strahm]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of D.
J. Bernstein
Sent: Wednesday, January 15, 2003 4:59 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Dan Bernstein's issues about namedroppers list operation


Thomas Narten writes:
> One can debate whether including the specific information cited above 
> was the right thing to do

That's the paragraph Bush added to other people's messages.

Bush added a different paragraph to my messages. (The ones he didn't
throw away, that is.) In that paragraph, he specifically included my
private subscription address, which hadn't appeared anywhere in the
messages I actually sent.

Unintentional, eh?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Re: Financial state of the IETF - to be presented Wednesday

[Bill Strahm]

I tend to disagree with you Ross,

First it is not excessive by definition because we are not covering our costs.  Second 
I don't think it is excessive because I know of MANY weeklong conferences that want in 
the order of 1000-1700 registration fees...

I can see how this is VERY different between someone whos company pays (who cares it 
isn't my money) and someone on a grant, sending themselves (every penny counts, cause 
money I don't spend going to an IETF meeting goes into my pocket that lets me spend it 
on my little girl... or pick your favorite way of spending money)

The other thing that will be interesting is how do the IETF meeting expenses scale 
with participation... Do we spend 300,000K regardless of how many show up, or as the 
number of attendies goes up we spend more money and if so how much more

Bill
On Mon, Mar 17, 2003 at 11:17:31AM -0800, Ross Finlayson wrote:
> At 10:22 AM 3/17/03, you wrote:
> >I'm having quite a hard time seeing what the problem is here, but maybe I'm
> >missing something... Based on Harald's analysis the  projected annual
> >shortfall is in the region of $350,000 per annum. Assuming ~5,000 attendees
> >per annum, that equates to ~$70 per year per attendee.
> 
> The trouble with this analysis is that the 5000 attendees each year are not 
> all different people.  Many, if not most, people attend more than one IETF 
> meeting per year.
> 
> A more accurate analysis would be: A shortfall of $350,000 per annum means 
> ~$120,000 per IETF meeting.  So, if 1200 people attend each IETF meeting, 
> then that means $120 extra per person.  (Or, if 2400 people attend each 
> IETF meeting, then that means $60 extra per person.)
> 
> (Personally, I think that even the current $425 fee feels excessive, 
> especially in the current economic climate.)
> 
>  Ross.
> 

Re: CLOSE ASRG NOW IT HAS FAILED

[Bill Strahm]

I am always leary about business models that I don't understand how they
make money.  So tell me, how will mail-archive.com make money to guarantee
that it will be around in 2050, 2100, and beyond.

I am not all that interested in a mail archive that might exist for a few
months, or a year, frankly I prefer the mail archives that the IETF
provides for my list, if the IETF goes out of business, then I don't think
the archives of the IETF will be all that interesting anymore

Bill

On Mon, 16 Jun 2003, Michael Froomkin - U.Miami School of Law wrote:

> My understanding is that The Mail Archive
> (http://www.mail-archive.com/lists.html)  will provide free storage for
> mailing lists.  I think every WG list should be permanetly archived in
> this manner.
>
> On Mon, 16 Jun 2003, Dean Anderson wrote:
>
> > Disks are cheap.  250Gig is under $400, and works just fine for slightly
> > long term storage.
> >
> > --Dean
> >
> > On Mon, 16 Jun 2003, Paul Hoffman / IMC wrote:
> >
> > > At 11:27 AM -0600 6/16/03, Vernon Schryver wrote:
> > > >All contributions that are rejected
> > > >by any moderators (including spam filters) of any IRTF or IETF mailing
> > > >lists must be archived and should be published on web pages somewhere.
> > >
> > > FWIW, some of the IETF WG mailing lists that IMC runs get >10 spams a
> > > day, and often get the virus/trojans that are >120K each. This is not
> > > an insignificant amount of junk to wade through when looking for
> > > proof of moderator badness/goodness.
> > >
> > > And there's also the problem of robots that harvest everything,
> > > regardless of your robots.txt file. If we had a system like you
> > > describe, it would be believable that the archives would get a fair
> > > number of hits from people searching for pr0n but finding our archive
> > > of spam instead.
> > >
> > > I think that having all bounces (for whatever reason) archived is
> > > fine; I think having it as "web pages somewhere" is overkill. Access
> > > to one of the big text archives can be a trivial password given to
> > > anyone who wants it for research purposes.
> > >
> > > --Paul Hoffman, Director
> > > --Internet Mail Consortium
> > >
> > >
> >
> >
> >
>
> --
>   Please visit http://www.icannwatch.org
> A. Michael Froomkin   |Professor of Law|   [EMAIL PROTECTED]
> U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
> +1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
> -->It's hot here.<--
>
>

Re: re the plenary discussion on partial checksums

[Bill Strahm]

Ok, I have to ask a silly question (not like that would be a first on this list)

Why, oh WHY would I want to receive a known corrupted packet ?

Are we talking about someone thinks they can eeke out 1% more performance
because their phy/mac can cut over immediately rather than wait for the packet
and verify the checksum ??? (or compute it on the sending side)

I guess I don't see the benefit, I guess rather than a hardware L2 check, you 
rely on something in your hardware later up to fail a check (including a L7
protocol) and drop the frame there ???

I wish I had been there to see the discussion

Bill


On Wed, Jul 16, 2003 at 04:21:47PM -0400, John Stracke wrote:
> Keith Moore wrote:
> 
> >so it seems like what we need is a bit in the IP header to indicate that
> >L2 integrity checks are optional, and to specify for various kinds of
> >IP-over-FOO how to implement that bit in FOO.
> >  
> >
> How would an app know to set this bit? The problem is that different L2s 
> will have different likelihoods of corruption; you may decide that it's 
> safe to set the bit on Ethernet, but not on 802.11*.  And, in general, 
> the app doesn't know all of the L2s that may be involved when it sends a 
> packet.
> 
> -- 
> /==\
> |John Stracke  |[EMAIL PROTECTED]   |
> |Principal Engineer|http://www.centive.com |
> |Centive   |My opinions are my own.|
> |==|
> |Linux: the Unix defragmentation tool. |
> \==/
> 
> 

Re: Securing SNMPv3 via SSH tunnels

[Bill Strahm]

The problem that you have with TCP (and made worse by SSH tunneling on top of
it) is that the number of round trips needed to successfully get a data packet
through is unreasonably high in a situation where you are attempting to 
diagnose a network fault.

The other choice is to leave a LOT of state open (ie. TCP connections)
requiring a lot of extra memory, etc. on the device.  That said there is no 
reason why you can not create a tunnel to a secure environment and run your
SNMP traffic from there.

Bill

On Wed, Aug 06, 2003 at 08:42:49AM -0700, Fleischman, Eric wrote:
> I am seeking to secure SNMPv3 communications (e.g., RFC 3414), trying to protect 
> against its well-known vulnerabilities such as spoofing. Had SNMPv3 run over TCP, 
> instead of UDP as it does, then I perhaps may attempt to protect it via SSH port 
> forwarding (i.e., SSH tunneling). Coincidentally, I've just read a description in 
> Bob Toxen's book "Real World Linux Security" (page 141) about an approach he has 
> apparently used of wrapping UDP in TCP and SSH in order to accomplish SSH port 
> forwarding for UDP-based protocols as well. This makes me wonder whether SNMPv3 may 
> be a viable candidate for SSH tunneling after all. I am wondering whether anybody in 
> the list has any insights as to the viability and weaknesses of this suggested 
> approach. I am especially interested in learning how people on this list secure 
> SNMPv3. Thank you.

Re: A modest proposal - allow the ID repository to hold xml

[Bill Strahm]

I'll give you one good reason.  And that is updating the drafts once
the initial RFC is published.  If the origional XML/.doc/input language of the 
day is available, then I don't have to spend my time converting the text
into a usable form to get the formating done easily.

For this reason only, having origional input would be useful.
(Yes I know, I can always go ask the origional editor for the input source,
but that may take time locating that person and getting access to the
input doc)

Bill
On Tue, Sep 02, 2003 at 11:19:29AM -0700, Paul Hoffman / IMC wrote:
> At 10:47 AM -0700 9/2/03, Eliot Lear wrote:
> >I don't know about about you, Paul, but I'm writing my drafts using 
> >EMACS and Marshall's tool.  That allows for generation of HTML, 
> >NROFF, and text.  The HTML allows for hyperlinks, which is REALLY 
> >nice.
> 
> Great! Why does that mean that the XML input should be published in 
> the Internet Drafts directory along with the text output?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

RE: Excellent choice for summer meeting location!

[Bill Strahm]

I don't know how airline pricing works in .au - but here in the .us it
seems that adding a short flight into a more regional airport can more
than double the cost of an airplane ticket.

Also note that a town of 100,000 will seldom have conference space that
can host a conference that attracts 1500 people - I know of no such
facility in  Hillsboro (where I live) that is outside of Portland (more
a suburb, than a regional center).  I would be interested in knowing
what somewhere like Spokaine, Boise, or other smaller site might have.

Bill 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Dassa
Sent: Monday, January 03, 2005 12:55 PM
To: 'John C Klensin'; 'IETF Discussion'
Subject: RE: Excellent choice for summer meeting location!

|> -Original Message-
|> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
|> On Behalf Of John C Klensin
|> Sent: Tuesday, January 04, 2005 12:19 AM
|> To: [EMAIL PROTECTED]; 'IETF Discussion'
|> Subject: RE: Excellent choice for summer meeting location!
|> Dassa,
|>
|> For better or worse, we've had a preference for locations
|> close to major airports with significant international connections.
|> We haven't been consistent about it (note, e.g., San Diego),
|> but, unlike that other organization whose name starts with "I"
|> (not IEEE, Glen), we have considered it a really bad thing
|> if most of the attendees have to spend two days getting to
|> and/or from a meeting: turning a five-day meeting into an
|> eight- or nine-day one is really hard on those who have
|> other things to do
|> besides going to meetings.I have no idea how the boondocks
|> of NSW would fall on that criterion, but it is what has kept
|> us near or in fairly major cities.
|>

Hello John

I was being a little tongue in cheek but the suggestion of regional
centers
being used is one I pursue for a lot of groups.  Living in the country
in a
smallish city, a lot of meetings occur in the capitals that I and others
just don't get a chance to attend.  I'm sure it would be the same in a
lot
of areas.  I can understand the issues but the benefits all round may
overcome them.  For instance where I live is only an hour flight from
Sydney, you ask, why don't you fly there for meetings and I have to
explain,
being in a regional area, the finances available for travel are limited.
We
tend to get paid less than equilivant workers in the capitals and
companies
out here are less likely to approve spending on non-essential travel.
It is
also a fact that connections out in regional areas are often less than
optimal for most people so this has an impact for online participation.
It
is only recently I was able to get ADSL at home for instance and
operated
for years with a dialup that meant long hours for participation online
and I
missed a lot of broadcasts due to downloading constraints.

My suggestion is the IETF considers moving some meetings out to regional
centres within reasonable travel of the major ingress airports in an
effort
to promote awareness and participation.  Within the States and other
countries, I'm sure there would be some benefits in holding meetings at
cities with populations of 30,000 - 100,000 or so rather than the
capitals
and other major cities with populations into the millions.

There are issues with such locations and they may be insurmountable but
I
would like to see the idea considered.  Given more people making
lifestyle
changes that involve moving away from major cities, it may become more
important in the future.

Darryl (Dassa) Lynch



___
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: Need for an Agenda Cutoff date?

[Bill Strahm]

Brian E Carpenter wrote:
Joe,
There is an agenda cutoff that WG chairs are supposed
to respect. This time it was:
> The agenda for the Working Group is due by Monday,
> February 28 at 12:00 ET (17:00 GMT).
But there were many late agendas and there was a glitch
in the process of posting them.
Guilty (IPoIB WG Chair here) - now solution space
For BOFs, the formal BOF proposal must include an agenda,
and that was due this time on February 21.
We need to try and follow our own rules next time.
Time to get Hard about this - if WG agendas aren't published by the 
cutoff date - the WG doesn't meet.  Anyone I've ever talked to says good 
meeting practice includes publishing an agenda - if there isn't enough 
interest in publishing an agenda, there isn't enough interest in 
attending a meeting.

If a WG is scheduled to meet on the cutoff date and there isn't an 
agenda published on the cutoff - a message goes to the WG chair (and 
maybe to the WG as well) with a warning and if they don't get an agenda 
to the IETF in 24 hours...

CANCEL THE MEETING
Brian - is this going to be your first contribution to the IETF as the 
incoming chair ?

Bill
(who would have had his meeting cancelled today with these rules - but 
this is the right thing to do)

   Brian
Joe Touch wrote:
Hi, all,
With agendas appearing ever later - including last night, the issue 
of cutoff dates should be revisited.

If reading the drafts to be discussed is NOT an issue, then the I-D 
cutoff dates should be dropped.

If reading the drafts IS an issue, then, by correlary, there should 
be a corresponding cutoff date for agendas - e.g., 1 week after the 
last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not 
published for this IETF, WGs that fail to meet that deadline should 
be CANCELLED.

Consider this a proposal, or at least a request.
Joe

___
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: IANA Considerations

[Bill Strahm]

John C Klensin wrote:


--On Wednesday, 06 July, 2005 15:23 -0700 Bob Braden
<[EMAIL PROTECTED]> wrote:

 


 *> harmful, and that the best way to insure coverage of IANA
issues is to have an   *> explicit check for such things as
part of our review process.
   



 


Ned,

As I expect you know, the IANA checks all documents at Last
Call time, and the RFC Editor checks them before publication,
for missing missed IANA actions.  However, redundancy does not
seem to me to be a bad idea.
   



Bob, as I expect you know, the IANA no longer has the staff
skills to perform an in-depth analysis of a document to
determine whether there are issues IANA needs to deal with.
Yes, I think they try, but the whole purpose of this section was
to move toward providing them better instructions and hints than
"go do your own detective work".  I'm grateful that the RFC
Editor continues to make those checks, but it is in everyone's
interest that the IANA actions be understood much earlier in the
process, leaving the RFC Editor review as the safety net of last
resort.

That said, I think we should be paying careful attention to
Bruce's implied suggestion about how template
boilerplate-generators should be constructed.   In terms of the
checking process Ned asks for (and which I still believe is the
right solution) there is a world of difference between a
template that generates:

IANA Considerations
   Nothing for IANA to do

and one that generates 


IANA Considerations
   If you see this text, the author hasn't gotten around
to thinking about this issue.

john

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


 


I actually would prefer
IANA Considerations
   This section left intentionally blank

Reminds me of some wonderful manuals back in the day (and frankly 
currently as well)


Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Ok .. I want my IETF app for my iPad ..

[Bill Strahm]

Tim Bray wrote:

On Sun, Apr 4, 2010 at 11:38 AM, Mark Nottingham  wrote:
  

Step-by-step instructions (with illustrations) for Americans to use their 
credit cards overseas.



Anyhow, it has to be an iPad app, rather than iPhone/iPod-touch,
because the smaller devices can't display 80-char-66-line ASCII
properly.  -T

  
Just thinking what would happen if someone were to propose a Windows 7 
app for the IETF.  Maybe Wordpad to write those pesky ASCII I-Ds, maybe 
a meeting planner, scheduler and calendar, maybe a program to help 
organize and read all of those pesky e-mail lists.  I know someone has 
to have done something like that...


Oh wait - I'll leave you back to your regularly scheduled vendor 
specific lock-in now.


Bill (darn it - 3 days late - but I had to skip April Fools this year)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard

[Bill Strahm]

I saw all of the huff, and while I agree with it, I am more concerned about

Appendix A. IPR Disclosure

   TBD

What does that mean, and more specifically is a document with a TBD 
section really ready for last call at all ?


Bill
Russ Housley wrote:
I misunderstood the original question.  I'll get it fixed or withdraw 
the Last Call.


Russ


At 12:38 AM 2/19/2006, Bill Fenner wrote:


>Can we have a Proposed Standard
>without the IETF having change control?

No.  RFC3978 says, in section 5.2 where it describes the derivative
works limitation that's present in draft-santesson-tls-ume, "These
notices may not be used with any standards-track document".

  Bill




___
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: Last Call: 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations' to Proposed Standard

[Bill Strahm]

Robert Elz wrote:

I cannot see why there's a debate going on here.   If someone, anyone,
can read a spec, and, in good faith, point out a possible ambiguity in
the text, before the doc is finalised, and if fixing it to avoid the problem 
is easy, what possible justification can there be for not adding a few

words to clarify things, and make sure that confusion does not happen?

Whenever someone points out a problem like this, the response should be
something like "OK, if we write it like ... does that make it clear?" or
perhaps "What would you suggest as clearer wording?" but never "It is
clear enough as it is" as the latter is already demonstrated to be false.

My mother can't read internet drafts either.  Should we change our 
language so that my mother can read and comprehend them.


It is assumed that there is a baseline knowledge when we write drafts... 
If you don't know how MIBs work in general - there are a LOT of problems 
that you have to sort out before you can provide technical feedback to 
the community.  Someone who is practiced in the art of 
reading/writting/implementing MIBs isn't going to have a problem with 
strictly monotonically increasing Indexes - knowing what that means, and 
how to implement it and test the implementation for correctness.


Somone who has been watching a rant on the list recently invovling the 
work monotonically increasing, MIGHT see the word and get confused.  I 
am not to worried about that - the document really isn't for their eyes 
anyway (I'm not about to comment on various security drafts either - 
should they be simplified so I can understand them, I hope I am expected 
to put in the work so that I understand them instead)




Certainly it is possible to explain the wording on the list, and convince
the objector that very careful understanding of the context makes the
intent clear - but that does nothing for the next person who comes along
and makes the same interpretation "mistake" (perhaps without even
realising the possibility for ambiguity, but simply interpreting the text
a different way).



Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: cApitalization

[Bill Strahm]

You think that is bad - try going by your legal Middle Name.

Do you know how many systems require a first name and a middle 
initial... Instead of the other way around


F. William "Bill" Strahm
Bob O'Hara (boohara) wrote:

Hear!  Hear!

I also suffer the indignity of having the system "correct" the spelling
of my last name by changing the capitalization.

 -Bob O'Hara (or O'hara as the registration system tells me is correct)
 
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 23, 2006 5:18 AM

To: IETF Discussion
Subject: cApitalization

A small annoyance, but annoying nonetheless:

At previous IETF meetings I had to suffer forced capitalization of my  
name so that "van Beijnum" became "Van Beijnum". Now it's even worse:  
"Van beijnum".


Can the IETF registration processing software please be instructed  
that IETF attendees are generally capable of applying and not  
applying the shift key as per their requirements and preferences?


___
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: Flaw in the design of NoteWell makes Notewell Not Well.

[Bill Strahm]

I don't know about the rest of you - but my sponsor tells me to 
participate and gives me the right to abide by the Note Well.


This is a simple thing for most sponsors to do - so this whole analysis 
is based on a participant that is working without their sponsors knowledge.


Now I am officially done feeding the trolls
Bill
todd glassey wrote:

By the way all and Jorge, you should take this as a formal challenge to
refute - I don't think you can.  I found what I think is a massive flaw (AKA
a "Catch 22") in NoteWell as to how it applies to corporate participants ad
unfortunately, I think it means that the IETF's processes IP induction
process need to be shut down until NOTEWELL can be formally fixed since it
by my take its broken and solicits fraud's in a large number of the IP's it
claims "it owns based" on email submissions.

This email constitutes formal notice
--
If Jorge, the IETF's Advisory or General Counsel as a licensed attorney
wants to pop up and formally for the record say this analysis of the
NoteWell Process ISN'T TRUE then the rest of this post can be ignored, BUT
otherwise this memo constitutes a formal notice of my concerns about the
IETF's Participation Agreement. A very complex contract spread across
numerous documents  which I characterize as "unenforceable based on numerous
frauds it forces Participants who are using their Company Email services and
the ownership of the IP submitted, which must be represented to it through
its design";

So Jorge please formally advise your client as to whether this is true or
not, and instruct them appropriately. I.e. If this post is accurate and
these concerns are real then please instruct your client to immediately
cease any NoteWell type assignment's to the IETF until this matter is
resolved. By the way this also eliminates any submissions to the Editor too
for the same reasons through Corporate Email Gateway's,

Let me explain:

Corporate Entities and their AUP's
--
Corporate Entities who are public or constrained by civil 'standard of care'
laws like SOX or other legislation generally all have a formal HR rule that
each and every employee signs an IT AUP agreement.  Think back folks - did
you sign one of these? The reason is that usually these AUP's contain an
Email specific agreement that says "that the Company owns any and all emails
emanating through their email system" & you folks who are sponsored by some
third party who is constrained under commercial law all probably signed one
of these.

The AUP you signed
-
If you did, I suggest that you READ IT CAREFULLY. If the AUP says the
company/entity owns all the IP that flows through its email gateway then YOU
cannot legally speaking assign those rights to the IETF since YOU DONT OWN
THEM. That means without specific agreements between the Your Sponsor, a
Public Entity, and the IETF, as well as an amended AUP between you as an
Employee  and your Employer, you (the Employee) should not be posting from
the Work address/domain  or system. That also means that without some
specific agreement between the Employer and the IETF there can be no
transfer of IP rights into the IETF.

The IETF's faking this by creating boilerplate which claims that you also
must represent to the IETF that you have these legal capabilities is also an
inducement to commit fraud IMHO since it is very likely that any and all
management of the IETF signed one or more of these IP and AUP controlling
agreements with their sponsors.


NoteWell's Failing
-
NoteWell as it stands today has a statement that any and all email sent to
the IETF becomes the property of the IETF. So then the problem is that the
person sending IP to the IETF through the Corporate GW doesn't own that IP
to assign it to the IETF. Only the Sponsoring Entity could do that.

Knowing that this is true and continuing to violate the agreement may be
fraud by wire
-
This is where it gets messy; the current boiler plate says that to
participate you have to turn over IP you don't own... and per the agreement
you likely signed with your corporate sponsor, to participate in the IETF
through the employer's Email GW you have to convey IP that you NO LONGER
have formal rights to. Further, to protect the IETF you MUST represent to
the IETF that you have this contractual authority; which as it turns out
only very few if any actually do and the misrepresentation of may be a
federal crime.


NoteWell - Private Company's and their IETF participation
-
This makes the IETF's NoteWell provisions ineffective because no matter what
the "Sponsored Employee or Contractor" says once they sign that AUP they
would then  need another specific agreement/exemption to set aside the
claims of the Sponsor to those IP's they were to contribute to the IETF.

No one would issue such a Email Release
-
No one in their right mind

Re: IETF/US General Election

[Bill Strahm]

Be careful offering legal advise.  I believe what you are proposing is a 
state issue.  For example in Oregon we ONLY have mail in ballots.  Other 
states will have varying degrees of absentee balloting - each with their 
own fun interpretations.


Bill
Moskovitz, Ram Austryjak wrote:

You can choose permanent absentee status and vote using paper
indefinitely.


-Original Message-
From: Michael C. StJohns [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 09, 2006 2:43 PM

To: ietf@ietf.org
Subject: IETF/US General Election 


Just a reminder - (and apologies to our non-US participants)

For the first time ever (at least I can't remember another
occurrence) the US bi-annual general elections will occur during an IETF
week.  If you're a US citizen and planning on voting this cycle (and not
from San Diego!), don't forget to submit a request for an absentee
ballot before your state's deadline.

Mike


___
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: Westin Bayshore throwing us out

[Bill Strahm]

Yeah - but who wants to go to Minneapolis one more time

/duck&cover
Bill
Dave Crocker wrote:



Fred Baker wrote:
well, it's gotta be the IAOC's fault then. Tell you what, you can cut 
my IAOC salary in half as a penalty.


Nah.  You deserve every penny you get.  In fact, let's double your 
salary, for taking all this crap from the peanut gallery.



 The IAOC is looking at the coming budget, and about to discuss it 
with the ISOC Board.

...
  That is in part what Ray has been doing in getting hotel contracts 
two years out, and in making a deal with the Hilton company about 
repeat business at Hiltons. But maybe we're willing to pay extra for 
"no construction".


Getting reduced rates has always been a goal and the benefits of signing 
early were discussed perhaps 15 years ago.  So we certainly don't want 
to reverse any of that fine, recent improvement.


Your last sentence is interesting, however, in the idea that we would 
have to pay extra in order to ensure that the hotel does not make it 
impossible for us to do our work.  While that wasn't your wording, I 
think it is a realistic implication.


I keep thinking that folks who rent space are renting the right to use 
it, and that a landlord who makes the space unusable is at fault.  One 
does not need to pay extra for the right; the rent already is the 
payment.  And I think the IETF meeting situation is comparable to 
renting space, albeit with a more interesting payment model.


We still seem to be constantly wandering into hotels for the first time, 
and somehow it's hard to believe that that doesn't cost the IETF a 
premium, if only in staff time learning the new place, especially for 
the net ops folk.  I even wonder whether repeating among a small set of 
venues would not also lead to some relationship building between the 
different staffs, thereby making everything go a lot more smoothly?


d/




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf