Re: ORCID - unique identifiers for contributors

[George Michaelson]

Currently, IETF standards activity carries little or no weight for an
academic career profile. It doesn't appear to have a weighting compared to
peer review publication. I think this is a shame, because the contribution
is as substantive, if not more so. And, since time is limited and choices
have to be made, I believe good students/postdocs don't come into our space
because the payback isn't there compared to submission into the peer-review
process.

(happy to be corrected. this is a belief, not a proven theory)

On that basis, things we do which make it easier for academic and research
assessment processes for STEM careers to consider our work as 'worthy' are
good and useful, because they help to direct skilled new brains into our
zombie pool.

I think ORCID would be the kind of thing which helps.

-G


On Wed, Sep 18, 2013 at 11:08 AM, John Levine  wrote:

> >Having an IETF identity is OK if all you ever publish is in the IETF.
> Some of our
> >participants also publish at other SDOs such as IEEE, W3C, ITU, and quite
> a few publish
> >Academic papers. Using the same identifier for all these places would be
> useful, and
> >that single identifier is not going to be an @ietf.org email address.
>
> If you want Yahoo mail or gmail or pobox.com, you know where to find it.
>
> Or people here are, I expect, mostly able to arrange for their own
> vanity domains.
>
> R's,
> John, ab...@no.sp.am
>

Re: Faraday cages...

[George Michaelson]

On Fri, Aug 9, 2013 at 11:05 AM, Keith Moore wrote:

>
> Would being able to reliably know exactly who said everything that was
> said in a WG meeting visibly improve the quality of our standards?   If the
> answer is not a clear "yes" (and I don't think it is) then I suggest that
> this topic is a distraction.
>
> Keith
>
>
With this I heartily agree. I think there is nothing to see here which will
really make much difference, or cannot be solved in other ways after the
event anyway. The problem is not one which technology can solve, because
the problem isn't that kind of problem.

Re: Faraday cages...

[George Michaelson]

Philip, I'm not disagreeing. I responded to Keith's mail relating what we
do to what was done harvesting WiFi. Like the store, we're in a room. we're
in a world of implied and actual consent (you do actually have to give some
consents when you register for IETF)

-G


On Fri, Aug 9, 2013 at 10:48 AM, Phillip Hallam-Baker wrote:

> On Thu, Aug 8, 2013 at 8:31 PM, George Michaelson wrote:
>
>> When next you walk into a target or big W, ask to see the conditions of
>> entry. Along with implied consent to have your bags checked at any time,
>> you have probably given consent to be video'ed and tracked at their behest.
>> The poster is on the wall somewhere usually. Your statutory rights cannot
>> be abrogated but equally, the grey areas have been 'informed'.
>>
>
> The efficacy of such notices has not been tested in court and when they
> are tested it is likely to cost the target about $2 million+ in legal fees.
>
> Since the IETF meets around the world the last thing we need is to spend
> time checking the legality of the badge at the mic system. And even though
> the IETF is not likely to be a target, I would hate to have some of the
> less popular with governments organizations I am involved in copy what the
> IETF does and then find themselves being targeted with a selective
> prosecution.
>
> Barcodes have the potential to work really well and require almost no
> change from current practice. The only downside to a barcode is that they
> are slightly easier to forge. Though in the IETF context, forgery would
> likely consist of people copying other people's badges for fun rather than
> to avoid paying.
>
>
> --
> Website: http://hallambaker.com/
>

Re: Faraday cages...

[George Michaelson]

When next you walk into a target or big W, ask to see the conditions of
entry. Along with implied consent to have your bags checked at any time,
you have probably given consent to be video'ed and tracked at their behest.
The poster is on the wall somewhere usually. Your statutory rights cannot
be abrogated but equally, the grey areas have been 'informed'.

BT tracking inside the store is passive collection of data you are
radiating. The store's use of the BT location and timing of presence
against shelves is private information of immense value to them. They share
it for mutual benefit with suppliers, or for money. I doubt they give much
away.

The large international scroogle rhyming company was compiling third party
uses of the data to inform location as a service, and were not solely
collecting information inside their own physical territory you entered,
with implied consent: they were harvesting data in the public space and
then providing insight into that data into the public space.

They relate because its harvesting RF. They don't relate in much else to my
mind.

-G


On Fri, Aug 9, 2013 at 10:22 AM, Keith Moore wrote:

> On 08/08/2013 07:41 PM, Phillip Hallam-Baker wrote:
>
>> Hmmm didn't a certain large company whose name rhymes with scroogle
>> recently get whacked with a huge fine for violating privacy in a similar
>> manner in the EU?
>>
>
> The rules are different for large companies with funny names.
>
> Keith
>
>

Re: IETF Meeting in South America

[George Michaelson]

yes, I made a facetious posting because I sensed that we were discussing
outcomes on a basis of 'nothing happened' when in fact, I think by scale,
Australian participation reflects if not exceeds our numerical role in
standards development and Internet matters. There is reason to believe we
do accrete people by bringing a roadshow to town. Expensive way to accrete
matter. Australia is a G20 participant and a net donor into development of
standards worldwide, and ICT. So, its arguable "we didn't need the help" of
a local meeting.

At risk of alienating my comrades from locations seeking to attract an IETF
for local development/inclusiveness and the like reasons, I think John gets
to the nub of the matter: the wider community cost, borne by all attendees
as a 'silent tax' is really very high, for this outcome. We need to be
explicit this is what we're doing. The ISOC grants are probably a more cost
effective way of boosting participation from outlier economies right now.

So lets be explicit. This is a standards-setting body, which is discussing
outreach, inclusiveness, wider participation outcomes, and the cost
consequences on attendance where the core motivation is standards setting.
If the core motivations are changing, maybe that drives things in a
different way?

[I loved BA when I went there for a LacNIC meeting. I worry about becoming
a standards tourist.]

Re: IETF Meeting in South America

[George Michaelson]

I went to Adelaide. it was my first IETF. I am now an IETF
regular-irregular, of 10+ years standing. So, proof by example, it
increased Australian participation by at least 1.

In fact, I think by scale, Australians punch above their weight. Especially
if you include americans who live in Australia, Australians who live in the
mainland of the USA.

I think IETF going to Adelaide had net positive effects on Australian
participation. Small. but real.

-G


On Wed, May 29, 2013 at 1:19 PM,  wrote:

> Melinda,
>
> can you confine yourself to disagreeing with something I actually said?
>
> Thanks so much!
>
> Lloyd Wood
> http://sat-net.com/L.Wood/
>
>
> 
> From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda
> Shore [melinda.sh...@gmail.com]
> Sent: 29 May 2013 03:47
> To: ietf@ietf.org
> Subject: Re: IETF Meeting in South America
>
> On 5/28/13 6:27 PM, Arturo Servin wrote:
> >   Going to Buenos Aires, Sao Paulo, Mexico City or Santiago will
> always
> > split audiences as these are the major tech hubs in the region (also add
> > Bogota, Lima, San Jose and other cities). So, I think it is not
> > comparable with Australia.
>
> I actually don't agree with Lloyd that the reason that the Australian
> meeting didn't lead to increased Australian participation was that it
> was because it was in Adelaide.  I don't expect a South American
> meeting in any South American city to lead to an increase in Latin
> American participation, either.
>
> Melinda
>
>
>

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

[George Michaelson]

s/12/16/ wrt 2002: doh. the principle stands. 2002://16 did not imply a 
reservation to a /12 and would have been given less than a /16 if the 
technology had allowed it.

-G

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

[George Michaelson]

On 16/11/2012, at 7:24 AM, Dino Farinacci  wrote:
> 
>> Secondly, you appear to assume these allocations to EID can simply use 
>> current RIR practices. The problem is that you need to understand what 
>> needs-based and justification means in process terms: Hostmasters in the RIR 
>> system try very hard not to be placed in a position of making arbitrary 
>> subjective decisions: they have processes which are designed to ask for 
>> objective justifications to specify why an allocation should take place, and 
>> at what scale. Those objective criteria face addresses as addresses. not EID.
> 
> No, I am not making any assumptions either way. How allocation gets done is 
> subject to more work.

Maybe this is something you could come to an RIR meeting and present on or 
discuss? We've got an APNIC/APRICOT coming up early in 2013 and I am sure you'd 
be welcomed to submit some content. Its good to talk about these things.


> 
>> For an example: IPv6 address allocation process currently is implemented 
>> using sparse allocation (binary chop with some modifications) in the APNIC 
>> region. This maximises space around allocations to equalise the distribution 
>> of free blocks such that the commons, the unallocated space, remains as 
>> usefully large as possible and when the next binary stride is entered, there 
>> is some understanding its going to be applied in common to all occupants of 
>> that region of space (in terms of the size of hole around them, which is not 
>> a reservation per se, but provides for risk-management of future growth to 
>> the largest extent).
> 
> There is no special semantics of EIDs that require you to change this. EIDs 
> are just addresses that do not get injected into the underlying routing 
> system. Other than that, they are just like any other address an RIR 
> allocates.

But by not being injected in the routing system they've already got a 
qualification against normal allocations, which are for globally routed 
addresses. So if under current criteria, somebody fronts to the RIR system and 
asks for a unique address assignment NOT to be globally routed, what do you 
think happens?

We try not to 'just make it up on the fly' -If there is going to be an EID 
space, shared footprint, with this behaviour, it will need to be documented in 
RIR policy.

> 
>> We're really quite proud of sparse: its extended the life of the /12 we 
>> occupy quite markedly. What impact will EID have on this? Is sparse an 
>> appropriate allocation engine to use for EID? What if eg you have 
>> expectations of almost-geographic aspects of address management in EID. 
>> Doesn't that require documentation as a process? And, you may be specifying 
>> a cost on the RIR system, to engineer support for the new allocation logic. 
>> If it doesn't logically fit in sparse allocation, we need to know. And we 
>> need to know why.
> 
> What Joel said.

4.  Expected use


   Sites planning to deploy LISP may request a prefix in the IPv6 EID
   Block.  Such prefix will be used for routing and endpoint
   identification inside the site requesting it.  Mappings related to
   such prefix, or part of it, will be made available through the
   mapping system in use or registered to one or more Map Server(s).
   Too guarantee reachability from the Legacy Internet the prefix could
   be announced in the BGP routing infrastructure by one or more
   PITR(s), possibly as part of a larger prefix, AGGREGATING several
   prefixes of several sites.

[my emphasis]


> 
7.  Routing Considerations


   In order to provide connectivity between the Legacy Internet and LISP
   sites, PITRs announcing large AGGREGATES of the IPv6 EID Block could
   be deployed.  By doing so, PITRs will attract traffic destined to
   LISP sites in order to encapsulate and forward it toward the specific
   destination LISP site.  Routers in the Legacy Internet must treat
   announcements of prefixes from the IPv6 EID Block as normal
   announcements, applying best current practice for traffic engineering
   and security.

[my emphasis]

thats in the 03 draft. So, naievely, I read that as meaning global unicast 
Aggregation. If it refers inside LISP only and is not implying aggregatable 
assignment to end entities holding EID, if EID are unique only and can be 
sparse and disjoint, Thats good to know.


>> EID are not going to be used like 'normal' addresses. So, the normal 
>> justifications don't look entirely
> 
> Define how a 'normal address" is used.

globally routable (normally) for starters. With assignment dynamics which 
relate an end-site to a customer, so with some scaling which reflects demand 
and the depth of network complexity to achieve it. Which is specified at time 
of assignment and tracked for subsequent reallocation/growth. 

Address management has costs btw. I expect many people in this community are 
concerned by that and there are times quite unpleasant language is used about 
the RIR process and its cost recovery needs, 

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

[George Michaelson]

Dino, to come back on topic. I understand the drafts purpose is to request a 
block of IPv6 address be delegated for this specific purpose, from IANA. The 
request is to the IAB. So, its a request for architectural aspects of 
addressing, facing an experiment.

a /12 is a very large amount of space. This demands rigour in the process to 
apply, even a reservation requires a sense of why, and justification. "we think 
its about right" isn't appropriate and the document needs more work to specify 
why a 16, and why a /12, and what the implications are of eg a smaller 
allocation under a /16 reservation, or some other size (a /32 even, for which 
there are both precedents, in experimental allocations, and an existing process 
inside the RIR address management framework).

Secondly, you appear to assume these allocations to EID can simply use current 
RIR practices. The problem is that you need to understand what needs-based and 
justification means in process terms: Hostmasters in the RIR system try very 
hard not to be placed in a position of making arbitrary subjective decisions: 
they have processes which are designed to ask for objective justifications to 
specify why an allocation should take place, and at what scale. Those objective 
criteria face addresses as addresses. not EID.

For an example: IPv6 address allocation process currently is implemented using 
sparse allocation (binary chop with some modifications) in the APNIC region. 
This maximises space around allocations to equalise the distribution of free 
blocks such that the commons, the unallocated space, remains as usefully large 
as possible and when the next binary stride is entered, there is some 
understanding its going to be applied in common to all occupants of that region 
of space (in terms of the size of hole around them, which is not a reservation 
per se, but provides for risk-management of future growth to the largest 
extent).

We're really quite proud of sparse: its extended the life of the /12 we occupy 
quite markedly. What impact will EID have on this? Is sparse an appropriate 
allocation engine to use for EID? What if eg you have expectations of 
almost-geographic aspects of address management in EID. Doesn't that require 
documentation as a process? And, you may be specifying a cost on the RIR 
system, to engineer support for the new allocation logic. If it doesn't 
logically fit in sparse allocation, we need to know. And we need to know why.

EID are not going to be used like 'normal' addresses. So, the normal 
justifications don't look entirely appropriate to me from 10,000ft. The 
document needs to say "maybe we need to understand the allocation processes 
that the RIR should objectively apply" or maybe you need to step outside of 
draft space and engage inside the RIR policy process and seek a global policy 
which can document the process.

To ask for an IANA allocation without having undertaken this process looks 
wrong to me. So, I stand by my concern the document isn't ready for IETF last 
call: it hasn't addressed substantive issues around the process and 
expectations of address/registry function, to manage the /16, and it hasn't 
documented the basis of asking for a /16 in the first place, or a /12 
reservation.

cheers

-George

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

[George Michaelson]

I think this document isn't ready for IETF last call.

I think the context of an experimental assignment which heads to
distributing IPv6 addresses to end-entities, even if the experiment
is not intended to be globally routable, poses questions about how
the address management function is going to work. Can the working
group be asked to discuss how this is meant to be interpreted in
the light of RFC2050 based processes? It might avoid future pain
if its clear how the IAB and the RIR understand these addresses and
their management.

The experiment has all the attributes of a general, wide-ranging
address distribution and management activity. I haven't seen any
substantive discussion of this in the WG mailing lists, and I'm
worried this hasn't been documented, or understood.

cheers

-George

Re: Change in I-D announcement format

[George Michaelson]

put bluntly, we all know the mail tools we're using to process these mails, and 
the mails could be a damn sight more tractable for tools than they are.

ever tried sorting drafts by subject line?

that old draft-random-group-something-KEYWORD-version is really suckful for 
something as basic as .. sorting.

gonna change that religion? I don't think so.

-G

PS can all the emacs users please not pile on with 'works for me (smirk)" 
responses, I know you LISPoids have this dealt with. Some of us lost enough 
braincells to use GUI, and the GUI really don't like IETF Draft subjectlines. 
They mask almost all the useful bits, and expose almost all the useless bits.

Re: IPv6 traffic distribution

[George Michaelson]

I have updated the graph to include 6rd, based on my understanding that the 
prefixes of the form 2a01:e3xx: are your 6rd space.

There is *other* FreeNet space, which appears to do things, but I sense its not 
part of the 6rd deployment since the numberforms in the lower /64 appear to be 
infrastructure assignment, not classic customer space forms.

Please let me know if I have this wrong.

You will notice that this count places Free/6rd at a far lower relative % of 
unique DNS than the measures of traffic and sources people discussing here. I 
think this bears thinking about.

http://labs.apnic.net/dns-measurement/

-George

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

Re: IPv6 traffic distribution

[George Michaelson]

On 29/07/2011, at 8:03 AM, Joel Jaeggli wrote:

> agree but if you're trying to discriminate it by:
> 
> "This graph shows the daily unique queried reverse addresses by type."
> 
> you can't.
> 


Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's 
declared ranges in RIPE whois but it was pointed out to me that dealing with 
one ISP like this skews things.

After all, other ISps also deploy 6rd, and Comcast do some kind of related work.

I can put in a 6rd line, if thats what people *want*

-G
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 traffic distribution

[George Michaelson]

you may like to look at

http://labs.apnic.net/dns-measurement/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-v6ops-6to4-to-historic (yet again)

[George Michaelson]

I have considered the issues I had facing 6to4 deprecation, and in the light of 
what you propose here, and other discussions, I support this course of action.

-George

On 25/07/2011, at 10:30 AM, Ronald Bonica wrote:

> Folks,
> 
> After some discussion, the IESG is attempting to determine whether there is 
> IETF consensus to do the following:
> 
> - add a new section to draft-ietf-v6ops-6to4-to-historic
> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL
> 
> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and 
> convert their status to HISTORIC. It will also contain a new section 
> describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. 
> The new section will say that:
> 
> - 6-to-4 should not be configured by default on any implementation (hosts, 
> cpe routers, other)
> - vendors will decide whether/when 6-to-4 will be removed from 
> implementations. Likewise, operators will decide whether/when 6-to-4 relays 
> will be removed from their networks. The status of RFCs 3056 and 3068 should 
> not be interpreted as a recommendation to remove 6-to-4 at any particular 
> time.
> 
> 
> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it 
> clarifies the meaning of "HISTORIC" in this particular case, it does not set 
> a precedent for any future case.
> 
> Please post your views on this course of action by August 8, 2011.
> 
> 
>   Ron Bonica
>as OPS Area AD>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: Fisking vs Top-Posting

[George Michaelson]

UI like the iPhone make top-post for short responses almost unavoidably easier.

"7 vital signs of a with-it manager from mars or venus (your choice)" books 
very probably also recommend it, I notice that people who move from strict 
technical roles into managerial ones are very prone to doing a +1 or "I agree" 
or "go ahead" as a top post with the entire thread retained.

the same people also complain when I trim.

So its a combination of pathological behaviours, UI, and dominance behaviour

-G
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: All these discussions about meeting venues

[George Michaelson]

in another time and place, we invented killfiles because this class of 
discussion proves so counter-productive, its better not to see it.

I posit that IETF venue discussions map 1:1 onto godwins law.

I suggest that we separate consensus over standards from IETF process over 
venues, and let the IAOC decide on our behalf, flaws and all, where, and when 
we meet. If we are able to give input to the IAOC, I am more than content for 
that to happen OFF LIST. We devolve these decisions to others because over 
time, its proven more workable than mass-consensus.

My impression of what some people seem to want, is that their personal 
constraint-set be applied globally. I've never found that to be a good social 
principle. While it means excluding some participation, I think that in a 
meeting cycle like ours, with the issues ours faces, that was always going to 
happen. So, rather than take one, or five, or ten, noisy and rebarbative 
people's drive to flood mailing lists with noise, I suggest we accept the 
consequences of devolving decisions to smaller sets of people, like the IAOC.

The best we can hope for, is that the pain is shared around.  With over 1000 
participants, it is likely that some peoples constraint set will take them out 
of attendance EVER. Again, while not desirable, its provably already happened. 
Why this is conflated into a general failure, rather than a very sad, but 
unavoidable necessary single-point failure I do not understand. 

I might add that if the excluded party feels this is oppressive, I am sorry. It 
is not intended to be. But, at some level, sooner or later, you have to be 
willing to say "I'm the problem here, not the remaining 999 people who have 
lesser constraints"

We do this all the time, when we elect local officials, at all levels of 
government. We accept the consequences of a disjoin between what WE want, and 
what THEY can achieve.

"its not fair" is really really bad, when its one or two voices against the 
wider community interest. "its not fair, but I accept its going to exclude me" 
is far better.

BTW, I am already aware I am functionally excluded from many things. IETF 
unscheduled WG meetings for instance. I do not flood this, or other WG 
complaining. I accept the inevitable.

Please, please, can we stop feeding this pernicious troll-subject.

-George
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fix the Friday attendance bug: make the technicalplenary the last IETF session, like it was before

[George Michaelson]

I wish to add a specific point to this.

I also raised a proposal for over-weekend meetings a few years back. I feel 
that the attendees to US IETF, which have often predominated, but in the 
general sense the attendees to IETF who fly for more than 12h to get there, 
suffer a material disadvantage from the monday-friday timing.

We loose two weekends, every IETF.

the proposal to shift to mid-week start-end has the material advantage to these 
people that they now loose only one weekend, as does everyone else.

Therefore, from a Benthamite 'maximal good to maximal people' sense, this is a 
better model.

I recognize that very strongly held views, including faith-related issues, lie 
here. I do not wish to disrespect these beliefs.

-George
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IAB/IAOC/IETF Trust Minutes

[George Michaelson]

Sorry for top-post.

in a purely personal capacity, having spent many MANY hours jabber  
scribing in a number of WG (IPFIX, DNSext/DNSop/SIDR, plenary):


Its a thankless (mostly) task.

its exhausting for more than 30min without a break.

its impossible to participate in a WG discussion an jabber scribe.  
therefore to scribe is to take yourself out of the loop (tm) in the  
substance of the discussion.


Chairs oftentimes fail to recognize the timliness of jabber-scribe  
forced interventions into the room. You can't scribe and queue at the  
microphone.


There are disputes in WG about what is, or is not, a proper record of  
the session and I don't think its fair to put a jabber scribe in the  
position of possibly being held 'on the record' for what they scribe.


Having said which, as a best-effort assistance, and as a vehicle for  
rapid noting the flow of activity in a group, I'm all for it.


-George

On 28/10/2009, at 3:01 PM, Joel Jaeggli wrote:




Dave CROCKER wrote:



SM wrote:

Posting documents in a format that involves text files with very
long lines that require horizontal scrolling with many systems
is not a favor to the community or an aid to ready
comprehensibility.


wraping long lines is not a new technology



A stray thought:

While it is always better to have an explicitly appointed scribe, I
wonder whether a collaborative approach might help in the situations
lacking this.


they could simply be recorded, post-production is prohibitively
expensive for a time and workflow perspective but raw recording have
some utility if you are willing to spend the cycles to reconstruct
events from them.


I'm thinking that a jabber session for a meeting would permit all
participants to post their comments of what is happening as the  
meeting
progresses.  This would not be a public session; its sole purpose  
would
be to make an archive of notes that could then be lightly massaged  
into

minutes.

If everyone in the meeting is recruited to assist, I suspect the  
result

could be reasonably comprehensive.

d/

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


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

Re: ESTA (Electronic System for Travel Authorization)

[George Michaelson]

write your auth number down.

once you complete an app, the number is valid for 2+ years with  
modifications to travel plans each time, but, and this is a killer:  
the web app will NOT send you a reminder of your number, and if you  
'reapply' you get bounced 5 forms in.


if you can't remember it, there is no apparent way to recover the  
number. :-(


(I posted on risks about it)

-G

On 01/03/2009, at 10:06 AM, Jaap Akkerhuis wrote:


The USG has a new program out which requires people to use this for
the Visa Waiver Prgogram and other stuff. I forgot the right URL
and used google to find it back. To my suprise I got various of
hits for various sites offering me to send a pdf-file for $ 49.95
or more telling me how to fill in the form.

The real site is something like
.

Don't get duped.

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


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

Re: IETF62 Network and Terminal Room Information

[George Michaelson]

Caveat: I am not an RF engineer. I am no longer trusted to do much network
config by my team. I run NetBSD rather than a commercial OS and can
probably be regarded as a (l)user.

We're a mix of platforms, probably more diverse than most smaller, dense
deployments. Few of us get to CeBIT or other situations likely to be like
this, for worst-case networking. You can't compare this to the density
problem of normal offices.

I'm not convinced the RF sharing in the A/B/G world works well with older
cards, and I am sure we have some people who are using pre-'gold' lucent
chipsets locked at 2mbit. 

I saw a lot of non-printable SSID. I saw a lot of non-IETF, non-hotel SSID.
Some I think are in the area, some were undoubtedly the ad-hoc nonsense
which crops up. 

I got better WiFi in the Irish Pub.

I am not sure the range of SSID helped. the WEP ssid probably shouldn't be
even remotely close to 'ietf62' and having ietf62-wep didn't help me all
the time (this is classic 'problem between chair and keyboard' stuff)

We have people who freak their power budget. I don't think this is in the
wider community interest. 

We have people who run two cards at once. They probably get a good outcome
but I wonder if it helps everyone around them to have two cards
cataleptically bouncing between the same channel

We have people on laptops with bad engineering. some laptops with built-in
WiFi have truly awful issues with large pods of water and fat moving
between them and the base-station, some appear to prefer being in specific
orientation.

I was routinely seeing 8+ base stations on 2 channels. I've said this to
people in the NOC, and not yet been contradicted but isn't it meant to be a
bad idea to have that many base stations visible on the same channel? I
thought even spread spectrum had limits to how much RF you could use with
other people.

The reports that turning off one of A or G improved things makes me think
this has a lot to do with the link layer, the RF.

the DHCP service was odd. If the net is not actually congested, then why
would a DHCP server take so long to serve? I don't see why the beast was
stuck in backoff land for so long. Of course, if it too was seeing
melt-down of the carrier, the ARP must have been lost along with all the
good bits, but when the net was palpably 'up' -Why does a DHCP server
struggle? If its not scaling for a large flat net, should we be walking
back to smaller partitions, or to some other address discovery service
which does scale to large flat nets?

Not all Mac users had a good time. This is often a clue that things are bad
in the infrastructure. I don't have one, and they love to tell me how
perfect it was for them on their MacOS, but they just weren't doing it, and
I think that also says there was something wrong out there on the aether.

I respect the effort the NOC put in. I know its hard to do this stuff, I do
it writ small on far smaller conferences, and I know how hard it can be to
make it fly when the users are grumpy. But we're not going to get to a
better place without recognizing this was NOT a good network, even
relatively speaking inside the history of IETF nets.

-George

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

Re: Friday @ IETF61?

[George Michaelson]

On Thu, 2 Sep 2004 20:41:50 +1000 George Michaelson <[EMAIL PROTECTED]> wrote:

>On Thu, 2 Sep 2004 13:36:39 +0300 "Romascanu, Dan (Dan)" <[EMAIL PROTECTED]> wrote:
>
>>I do not believe that this is achievable. With the majority of other standards 
>>organizations meetings and industry events building their schedules on a week basis, 
>>avoiding major conflicts in the participants calendars would become an even more 
>>challenging task, close to mission impossible.
>
>I do not believe this is true. 

actually, its been pointed out to me this is painfully true. There are also
loosers in re-scheduling. Some people will not benefit from my idea. Possibly
many people. bodies like IEEE do back-to-back scheduling. (sigh)
 
-George

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Friday @ IETF61?

[George Michaelson]

On Thu, 2 Sep 2004 13:36:39 +0300 "Romascanu, Dan (Dan)" <[EMAIL PROTECTED]> wrote:

>I do not believe that this is achievable. With the majority of other standards 
>organizations meetings and industry events building their schedules on a week basis, 
>avoiding major conflicts in the participants calendars would become an even more 
>challenging task, close to mission impossible.

I do not believe this is true. 

In fact, if no other body is using weekends, it only increases the chance that
IETF can squeeze into schedules, because it can exploit dead time the other
meetings cannot.

I suspect most attendees do not share this exposure either. But almost ALL
non-US resident attendees have borne this non-financial, social cost since
the inception of a week-long, working-week model.

-George

>Dan
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
>> Behalf Of George Michaelson
>> Sent: 02 September, 2004 1:05 PM
>> To: [EMAIL PROTECTED]
>> Cc: Harald Tveit Alvestrand; Tim Chown; [EMAIL PROTECTED]
>> Subject: Re: Friday @ IETF61?
>> 
>> 
>> 
>> I call again for meetings run over the weekend. midweek to midweek.
>> 
>> 1) cheaper hotel rates for attendees. weekends are cheaper.
>> 
>> 2) less congestion in airports for flights. 
>> 
>> 3) for Europe and Asia, attendance in the USA becomes a loss 
>> of two weekends
>>(one either side) and for the Americans, NO weekend. This 
>> would be fairer
>>for everyone, and mean we had a cheaper, more productive time.
>> 
>> -George
>> 
>> ___
>> Ietf mailing list
>> [EMAIL PROTECTED]
>> https://www1.ietf.org/mailman/listinfo/ietf
>> 


-- 
George Michaelson   |  APNIC |  See you at APNIC 18
Email: [EMAIL PROTECTED]|  PO Box 2131 Milton|  Nadi, Fiji
Phone: +61 7 3858 3150  |  QLD 4064 Australia|  31 Aug -3 Sep 2004
  Fax: +61 7 3858 3199  |  http://www.apnic.net  |  www.apnic.net/meetings/18

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Friday @ IETF61?

[George Michaelson]

I call again for meetings run over the weekend. midweek to midweek.

1) cheaper hotel rates for attendees. weekends are cheaper.

2) less congestion in airports for flights. 

3) for Europe and Asia, attendance in the USA becomes a loss of two weekends
   (one either side) and for the Americans, NO weekend. This would be fairer
   for everyone, and mean we had a cheaper, more productive time.

-George

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: YATS? Re: T-shirts, and some suggestions for future ietf meetings

[George Michaelson]

Jon Crowcroft told us in UCL-CS back in '85 that the pre-IETF meetings were
smoke filled rooms, including uniforms with medal-bars out to the elbows...

-George

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: No MBONE access

[George Michaelson]

Just a pov. 

I love MBONE. I see no reason not to try and have it.

for APNIC member meetings we decided to go with Quicktime RTSP: and SDP: url
encoded streams. they worked well. one onsite, one offsite. avoid congestion.

they have really bad scaling for hundreds of people. but lets be realistic here,
the IETF isn't actually the same as Kylies underwear show: it has a small set
of people who could live off refeeds if need be.

So, while it has costs, I say: why not do both?

also, the rtsp: and sdp: instances would have worked over multicast. MBONE is
not an encoding, its a point of view. Quicktime over MBONE is fine for me, and
Quicktime alongside MBONE is fine for me too.

judging from jabber, we have <20 people who would really have meshed this way
if needed. we could have done p2p feeds if needed. labour costs, effort. but 
technology wise, it works.

-George

Re: no multicast of IETF plenaries

[George Michaelson]

On Tue, 15 Jul 2003 12:41:58 -0700 Ross Finlayson <[EMAIL PROTECTED]> wrote:

> At 12:06 PM 7/15/03, Jeffrey I. Schiller wrote:
> >I too would appreciate the plenaries being multicasted.
> 
> Me too :-)  (But failing that, please try to make the recorded video 
> available promptly.)
> 
>  Ross.
> 

Why not pipe the audio to the location with the mixing desk and feed, so its at
worst 0.5 plenaries? it will actually be more, the audio is far more significant
than the video in this respect.

Having done some meeting multicasting in conference centers and having seen this
one, which is fully wired for simultaneous translation, I can't believe there
isn't 75-Ohm audio cabling between all halls via patch panels...

cheers
-George

-- 
George Michaelson   |  APNIC
Email: [EMAIL PROTECTED]|  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

IETF jabber howto pointers please?

[George Michaelson]

Could somebody re-post a pointer to the canonical 'IETF jabber' howto please?

the various archived documents seem to be a twisty maze. the archives for
sessions I found were for March, nothing current.

-George

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[George Michaelson]

Just because I *have* a NAT box to use at home doesn't mean I *like* NAT.

I expect to find deployment of IPv6 at home challenging, in part because I've
already spent my 'five-year-plan' funds on networks for home. 

Its the same road-trap digital TV is caught in: people do not rush out and buy
even small communications/technology investments as throw-away devices. TV sets
last for 5-10 years. Hi-Fi sets last even longer. $5 low-fi radios last almost
forever, sliding down the hierarchy from the living room, to the kitchen, to the
garage. 

I expect my Nat box to last another two or three years. I do not expect the
vendor to be able to ship an IPv6 ready image for this box. Therefore I will
have to convince the 'house funding committee' to let me replace this box before
its real end-of-life window. That is hard, set against the cost of painting the
house, or urgent repairs to the steps, or replacing the VHS recorder by a DVD
player.

If a massive volume of IPv6 ready NAT or other boxes arrived on the market right
now, I do not think the take-up would be explosive. The early adopters might buy
in but it would require the *default* configuration to new players to be fully
V6 enabled, and even then the rollover time in the home segment would be
measured in years.

NAT is irrelevant to this IPv6 deployment thing. its neither an obstruction nor
a benefit. The business cycle and non-financial motivations about spending and
lifestyle are just as relevant, if not more so.

If my home network supplier let me have multiple IPv4 DHCP addresses that
were routable behind the cable box, I would probably still keep this NAT box,
even if I did turn off NAT. 

I still have my recordplayer connected to my Hi-Fi even if I don't play records
much.

 cheers

-George

please change the subject line

[George Michaelson]

Dean, please can you change the subject line. If you are going to complain to
the IETF about process, I have absolutely no desire to be brought into it, and
it certainly isn't part of anything I conciously wanted to initiate in my
posting. 

cheers

-George

Re: movies vs chat logs

[George Michaelson]

I found the jabber logs helped me decide when to move between sessions, when
micro-timing of schedules wasn't apparent and I had to be in 'both' sessions.

I found sidebar conversations carried the subjective information you missed. I
don't think we can yet intuit the consensus of the room to put that into
jabber in the wide, one mans bozo is another mans guru and all that...

I think you are right to characterize the recordings as 'being there with
sanity checks' -The jabber stuff was a way I found I could meet two goals:

1) let other people know whats going on in the room

2) compile the data which the WG chair wanted as a log of the session
   tending towards the official minutes

On the whole, I liked having the jabber even if the value is moot. Writing a
jabber log is very painful. RSI returns!

cheers

-george

Microsoft uses 'darknet' to refer to PTP overlays: what do we call misuse of unallocated address space?

[George Michaelson]

Microsoft is now using the name 'darknet' to refer to the overlay networks of
point to point filesharing in their Digital Rights Management (DRM) position
papers in conferences.

So, in the public eye, this neologism has probably now been taken to mean this
activity,

Rather than descend into hacker/cracker discussions, what is a good label to
use when referring to people who usurp unallocated IPv4 address space, and
arrange for it to be BGP visible in the classic DFZ network? I had thought
that *this* was being called the dark net, but I'm not confident that tag will
survive the behemoth...

-George

Re: After 1 day... Re: text conferencing at the 55th IETF

[George Michaelson]

Looking for words to express the sense of frustration when you have a bloody
interesting session, you have saved bloody interesting Qs from the floor, you
have people on jabber who want to see the stuff, and the f***$%#^D network
dies on you, so you can't put the stuff into the jabber session at the
murphys-law point of most utility...

-George

when does wavelan die at Minneapolis? Friday?

[George Michaelson]

So is teardown on a non-IETF day scheduled for 4am or 5am?

No, really: How long can the itnerant ex-attendee sit in the lounge and
be on line? Or, how long at the Britpub with the feed?

-George

PS I have been dying to ask: does anybody measure the size of the suspected
   pool of locals who get slashdotted into driving 40ks for free connectivity?

   not that you'd want to stop this mind, but I do wonder if some of the
   bodies are actually *only* here for the 802.11

Re: IETF Meetings - High Registration Fees

[George Michaelson]

I'm intrigued that the reggo figures say attendance is shrinking. Amazed
but also delighted in a way, because there is no question smaller is
more functional. Obviously sad for those who can't attend, I'm not
saying this is unequivocally wonderful or anything. 

The thing is, it doesn't *feel* smaller.

So is this a significant trend, and is it proving to continue?

-George
--
George Michaelson   |  APNIC
Email: [EMAIL PROTECTED]|  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3100  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

Re: 10 years and no ubiquitous security

[George Michaelson]

> But Bill, I'm trying to understand what your point is.  We can't force 
> people to use security.  IPsec is standard in most major business 
> operating systems (Win2K, Solaris, *BSD, etc.) and available for for 
> Linux.  There are hardware solutions -- I have a small IPsec box with 
> me in Minneapolis.  But except for VPN scenarios, most people choose 
> not to use it.  I think there's a lesson there, but I fail to see how 
> Steve Kent or any of the other players in the history of IPsec are at 
> all at fault.  
> 
>   --Steve Bellovin, http://www.research.att.com/~smb

I would like to comment on the other issue in this paragraph, about why
IPSEC deployment might lack vigour.

I set up VPN over IPSEC on a national academic network with 40mbit backbone
and 10/100 mbit site linkspeeds. the best end-to-end performance I could get
was 2mbit rising to 3-4 burst, and I was flooded by fragmented IP.

Stuff like pMTU end-to-end is absolutely vital to make non-aware clients
and servers cope with encapsulated protocols.

I have also played with the client side code, and found that UDP protocols
like Windows SMB do not work well on noisy/long-delay links. THis repeats
the experience of encapsulated LAT some of us ex-DECheads remember: you
can't fix bad protocol experiences by wrapping them in better protocols
if the end-to-end behaviour depends on the badness (eg timer dependencies)

Please don't get me wrong: I use IPSEC, I like IPSEC, but I have to 
recognize that off the beaten track, or for some (very useful) contexts
it turns out not to work as well as we'd like, for reasons probably not
to do with IPSEC per se, but the general state of the network.

When you factor in that most of the 'simple' things can be done equally
well in SSH, or by less clued people using non-secured tunnels, it gets
harder to do a sell on IPSEC. which is a shame, because I really like
IP layer abstracted methods, and the idea of generic infrastructure rather
than applications-level point solutions.

cheers
-George
--
George Michaelson   |  APNIC
Email: [EMAIL PROTECTED]|  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3100  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

Re: What is at stake?

[George Michaelson]

> 'Australia's fallen off the net again!'

Actually, that was Britain in 1985/6, when the BBN butterfly lacked sufficient
memory to handle the routes and the UK dropped off the bottom.  Ah, where
would we be without fixed price contracts. no cash, no fixums. 

Better yet the hosts.txt file and telnet death on a 60 second login: timeout
before it could scan the file...

So if the IETF doesn't manage the Internet, how come it keeps defining MIBs?

Judging by the IRTF session on content, the lawyers own it all anyway...

cheers
-George

Re: What is at stake?

[George Michaelson]

We'll know when the Internet 'matters' on this measure, when they
take the management and oversight away from the IETF.

Like all other conspiracy theories, this falls down on defining
who 'they' are and 'matters'.

Australian State and Federal statistics on Internet only began a couple
of years ago. But Australia was connected back in '87/'88. 

I think Jon Crowcrofts descriptions of the 'smoke filled room' days
which proceeded the IETF might dispute the idea that 'they' ever
a) failed to know what they were doing or b) relinquished control
in the first place.

What is at stake, is that its very late, and we all need to stop
sending email.

-George

NAT patent

[George Michaelson]

So, its the silly season, we don't have enough traffic on the lists since
the CFP spam got quashed. I'm bored of the Olympics coverage.

Who'se gonna put a toe in the water over the NAT patent?

My guess is that we should run a pool on the first person to post suggesting
its a good thing (tm) since "NAT ARE EVIL" and the work of the devil anyway.

My money is on people whose first names start with K or V.

cheers [ducks for cover]

    -George
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: imode far superior to wap

[George Michaelson]

There are actually operational issues if not standards related ones here.

Discussion in Australia about management of the .AU ccTLD is discussing
amongst other things services like !Banggo for WAPsters who cannot stand
to try and type alpha URI and are therefore using a numeric redirection
schema to get short URL off the number-pad to jump off to websites.

This has a direct impact on what people think DNS is providing, what
'addressing' and naming mean for mixed-protocol/application contexts, and
probably some societal/governance issues as well.

The horror, the horror...

cheers
-George
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: novel use of URL space

[George Michaelson]

  > http://rfc2826.x42.com/ (try for any rfc)
  
  operationally, useably, ... how is this more useful than putting the rfc
  after the slash, e.g.
  
http://x42.com/rfc2826
  
  what's it get me, other than less dns hits?

you can do a rfc-centric  implementation of further functionality so that
its document/context or document/markup or document/cross-ref.

sure, you can do all that via a cgi, but this way, its document-centric
ie all the sub-features if you do them, hang from the name of the document.

Its not *that* neat an idea, but it had some attraction to me. Actually
the wider idea of embedding information in DNS like that also seems to be
either evil or sweet, depending on how you look at it.
  
costs heaps of overhead for sure!

-george
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

novel use of URL space

[George Michaelson]

I found this via the tasty bits site:

http://rfc2826.x42.com/ (try for any rfc)

The idea certainly isn't copyright, and it has a compelling simplicity
which makes me think the IETF could consider adopting it when it
promotes 'canonical' URLs for accessing the standards.

Its probably not such a good idea for the drafts mind you!

comments?

-George
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: Is WAP mobile Internet??

[George Michaelson]

  Jon Postel would have said: If it speaks IP (UDP/TCP are not
  necessary), then it's Internet, else not.
  
I thought part of the argument was about capitalization of the I. if its
lowercase, then its using IP, if its uppercase then you can expect to use
global Internet addresses and achieve a substantive amount of end-to-end
connectivity. Of course, that was before NAT.

  However, during the 1980s the IAB tried to float the concept of an
  extended Internet defined by email connectivity.

Is this different to John Quartermains Matrix definition? Gosh, how
prescient to choose that word...
  
-George

--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: VIRUS WARNING

[George Michaelson]

  
  Hmm.. the Morris worm of 1988.  What are the other 2?
  
Piers Dick Lauder and Bob Kummerfeld implemented Mail/sendfile *@*
(yes, wildcards both sides of the user@host name form) in ACSnet prior
to this. It was designed to be used amongst other things, to do s/w updates
to all ACSnet subscribers. And it worked over IP as well as an applications
layer over TCP/IP, gated into sendmail.

The one time I saw them use it, it killed my sendmail by n->n*m explosion
of outbound mails. And as soon as I deleted one from mqueue, another 20
came in.


Mike Lesk claimed UUCP was invented for similar reasons and I seem to recall
some more than proof of concept uux methods to re-create forwarding data but
thats probably never been exploited in an IP network.

Then there are the checkgroups message flows in News...

cheers
-George  
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: IPv6: Past mistakes repeated?

[George Michaelson]

  I think the only reason this hasn't happened in the phone system is due
  to resistance by humans to reading, writing, and entering very long
  strings of digits.  Unfortunately, computers aren't as fussy.

My experience is that as people become more (internationally) mobile their
use of IDD +xx   form number spec becomes more common.

Likewise with major slices of the UK and Australia recently renumbered, people
were forced to ditch their paper investment in old numbers and dropped into
line in a semi-standard form of representation which has to be full-number
aligned, because the new digits are in front of the old semi-optional prefixes.

In other words, the old '7 digits is all people can handle' rule is melting
in the face of a larger pool of people who have to use longer digit strings.

cheers
    -George
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: draft-ietf-nat-protocol-complications-02.txt

[George Michaelson]

I think there are interesting things happening in DNS. I wrote a not very
good paper for AUUG a few years back noting an error rate in DNS above 10%
for the mirror site I do stats on.

Reviewing the figures for yesterday I get 9.75% unresolvable which is pretty
close to Bill Mannings figure.

But then I checked over the last 116 days since the start of the year. I find
that for a deployed site, logging IP and DNS name into CLF format (so I can
use analog) for ftp ,rsync and www I get:

avg=15.288431, lo=4.213000, hi=33.265000

I think Bill is saying what really exists in DNS. I'm saying what a box
deployed in the field can expect to see. Its pretty damn variable and its
a lot worse than the DNS records would themselves suggest. Remember that
DNS is timebound with timeouts in client code, uses UDP and is subject to
the same kind of loss issues as the general datapath.

(this is on a client base of around 3000 hosts, weighted for Australia/NZ)

cheers
-George
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: Email messages: How large is too large?

[George Michaelson]

  > What's the SOLUTION?
  
  :
  * ^Subject:.*How large is too large
  /dev/null
  
  procmail is your friend
  
  randy


Great solution for the last mile. Shame it makes some people pay to import
what they will throw away...

-George 
--
George Michaelson |  DSTC Pty Ltd
Email: [EMAIL PROTECTED]|  University of Qld 4072
Phone: +61 7 3365 4310|  Australia
  Fax: +61 7 3365 4311|  http://www.dstc.edu.au

Re: Email messages: How large is too large?

[George Michaelson]

  
  I remain to be convinced that problems handling large messages have
  much if anything to do with the modern ESMTP protocol. It seems to me
  that it has a lot more to do with implementation and deployment.

Amen!

A few observations:

Many places depend on mailers which operate as 'parallel to serial' gateways
taking apparently decoupled, asynchronous mail submission and queueing them
into a single linear pass. Therefore while the size of an object for the
submitter has no apparent 'cost' in delay terms, if more than 1 hop exists
between the sender and recipient, then for disinterested third parties there
can be quite substantive issues:

o big mail delays other peoples service
o big mail impacts on service providers in the wider sense who have
  no 'contractual obligations' or SLA/QoS signoff with the sender or
  the recipient.

End users have a low conciousness of list size. Therefore sending large
attachments to 'mail' can mean a n->oo expansion (ok, not infinity, but
certainly better than 2*n expansion) of data in flow. This has to be set
against sending a 'pointer to pickup' which will only cause m*n expansion
based on http://www.dstc.edu.au