> From: Brian E Carpenter
> Reality is different - the outside world expects to hear from us.
I would guess that nobody (almost nobody?)in the IETF objects to I*
leadership representing our views at such things; in fact, I suspect most of
us would find it positively very desirable for th
> From: Randy Bush
> we are in a big problem, and this is one major part. two decades of
> lack of coherent architectural oversight is another symptom of this.
I have two issues with your observation.
First, while I agree we've been deficient in architecture, from personal
experienc
> From: Melinda Shore
>> The IETF worked quite well (and produced a lot of good stuff) back in,
>> e.g. the Phill Gross era, when I am pretty sure Phill's model of his
>> job was indeed as a 'facilitator', not a 'leader' in the sense you
>> seem to be thinking of.
> Becau
> From: Arturo Servin
> Then we have a big problem as organization, we are then leaderless.
I'm not sure this is true. The IETF worked quite well (and produced a lot of
good stuff) back in, e.g. the Phill Gross era, when I am pretty sure Phill's
model of his job was indeed as a 'facilita
> From: Phillip Hallam-Baker
> I have argued for junking the DARPA constitution for years. It was
> designed to keep power in the hands of the few while the rest of the
> organization didn't worry their pretty heads about it.
Factually incorrect in a number of ways. The NomComm s
> From: Andrew Sullivan
> I merely request that we, all of us, attend to the difference between
> "the IAB Chair says" and "the IAB says".
We may attend to it, but we are unable to make sure that the rest of the world
pays attention to that nuance.
> From: SM
> In my humbl
> From: Dave Crocker
> Except that essentially all services other than email have gained
> popularity in centralized form, including IM. So there appear to be
> some important and difficult operational and usability barriers,
> standing in the way of more truly distributed app
> From: Martin Sustrik
> Isn't it the other way round? That exactly because IETF process is open
> it's relatively easy for anyone to secretly introduce a backdoor into a
> protocol?
> ...
> With IETF standard there can very well be several unknown backdoors
> introduc
> From: Hannes Tschofenig
> * Prefer performance over privacy in protocol designs
You forgot:
* Prefer privacy over performance in protocol designs
and its cousin:
* Prefer privacy over usability in protocol designs
both of which, as we have seen extensively over the last cou
> From: Steve Crocker
> Are we conflating back doors in implementations with back doors in
> protocol specifications?
Good point, but I was thinking specifically of protocol specs, since that's
what the IETF turns out.
> It's certainly a conceptual possibility for there to be a
> From: Hector Santos
> I would even suggest that all I-D authors, at the very least, should
> need to register with the IETF to submit documents.
Oddly enough, back in the Dark Ages (i.e. the ARPANET), the DDN maintained
such a registry, and so if you Google 'NC3 ARPANET' you will
Probably best if we keep the politics off the IETF list.
Noel
> From: =?ISO-8859-1?Q?Roger_J=F8rgensen?=
> Isn't the payload the important part to protect?
Ecrypting only the headers was a suggestion for the case where the routers
don't have enough spare crunch to encrypt the entire payload of every packet.
Whether that would do anything useful, o
> From: =?ISO-8859-1?Q?Roger_J=F8rgensen?=
> The userbase and deployment are relative small atm so it's doable to
> get fast deployment to.
Alas, now that I think about the practicalities I don't think the average
router has enough spare computing power to completely encrypt all
> From: Scott Brim
> The encapsulation is not much of an obstacle to packet examination.
There was actually a proposal a couple of weeks back in the WG to encrypt all
traffic on the inter-xTR stage.
The win in doing it in the xTRs, of course, is that you don't have to go
change all the
> From: Scott Brim
> LISP does nothing for decentralization. Traffic still flows
> hierarchically
Umm, no. In fact, one of LISP's architectural scaling issues is that it's
non-hierarchical, so xTRs have neighbour fanouts that are much larger than
typical packet switches. In basic uni
> From: Spencer Dawkins
> I have to wonder whether weakening crypto systems to allow pervasive
> passive monitoring by "national agencies" would weaken them enough for
> technologically savvy corporations to monitor their competitors, for
> instance.
More importantly, if cryp
> From: Scott Brim
> I wouldn't focus on government surveillance per se. The IETF should
> consider that breaking privacy is much easier than it used to be ...
> right now the Internet's weakness in privacy is far from "better". The
> mandatory security considerations section
> From: Martin Millnert
> Bruce was ... suggesting that encrypting everything on the wire makes
> both metadata and payload collection from wires less valuable. Here
> comes the key point: Encrypting everything on the wire raises the cost
> for untargeted mass surveillance sig
> From: Phillip Hallam-Baker
> S/MIME is almost what we need to secure email.
If by "secure email" you mean 'render email impervious to being looked at
while on the wire', perhaps. If, however, you mean 'render it secure from
ever being looked at by anyone else', no way.
Even if it's st
> From: Dean Willis
> The [IETF] .. needs dedicate its next meeting to this task. This is
> an emergency, and demands an emergency response.
The thing is that I'm not sure how much of this is the NSA 'breaking'
protocols/algorithms, and how much is finding ways past/around that secur
> From: Ted Lemon
> I would personally love it if IETF did another Munich meeting, because
> I haven't been there since I was seven, and I've always wanted to go back
"Many fine lunches and dinners". Some things never change...
Noel
> From: Brian E Carpenter
> Thanks for the careful explanations.
I'll second that; it does seem that some tweaking may be in order.
> Clearly the Trust shouldn't have blanket permission to abandon or
> dispose of assets
When the time comes to draft actual wording, I would sugge
> From: Phillip Hallam-Baker
> The ISPs had a clear interest in killing of NAT which threatened the
> ISP business model.
So this is rather amusing: you're trying to tell me that ISPs wanted to kill
NAT, and I have other people telling me NAT was an intergral part of ISPs'
master pla
> From: Simon Leinen
> In the eyes of your ISP, you were misbehaving, because you were
> violating their assumption that you would use ONE (1) computer with that
> connection. If you had been what they consider an honest citizen, you
> would have gotten a "commercial" connect
> From: Barry Leiba
> They have: they are keyed off the suffix-less URIs. That's why they
> want us to use those.
That doesn't change the point that breaking URLs in _previously-published,
static_ documents is a Bad Thing.
Noel
> From: Joe Touch
> "what people want" (ISP operators, or at least some of them), was an
> artificial way to differentiate home customers from commercial
> providers.
> I.e., they wanted to create a differentiation that wasn't part of the
> Internet architecture, so they p
> From: Keith Moore
Great message. One idea:
> WG meeting sessions aren't scheduled to encourage discussion, but to
> discourage it. At meeting after meeting, in several different areas, I
> see the lion's share of the time devoted to presentations rather than
> discussion.
> From: Roland Bless
> we probably need to do something on reducing the number of _broken_
> middleboxes (or their implementations respectively) - I'm not focusing
> on NAT boxes here.
> ...
> I think it's clear that we will not get rid of them, but if I hear
> about b
> From: Abdussalam Baryun
> no one in IETF have been participating for longer than 30 years
The IETF was a renaming of things that existed before the formal first IETF
(in January, 1986). It's a direct descendant of the first 'TCP Working Group'
meeting, held in Washington DC on March 12
> From: "Livingood, Jason"
> FWIW, I think for most larger companies with multi-billion dollar
> revenues streams it is less about the up-front fees to apply &
> operationalize a gTLD than the long term business potential.
I guess I'm missing something. How exactly is having a gT
> From: Phillip Hallam-Baker
> for many years it was IETF ideology that NATs were a terrible thing
> that had to be killed. A position I suspect was largely driven by some
> aggressive lobbying by rent-seeking ISPs looking to collect fees on a
> per device basis rather than pe
> From: Melinda Shore
> I agree that this is probably not appropriate for publication as an RFC
> but it would certainly be useful to find someplace for it in the wiki.
Actually, it would be good to have a series of these (or maybe one page with
a number of sections): we could also
for names, where X is the given initial, the Yyyy the family name. Do we
want to change that, or just say 'sorry, family-first people, you'll have to
mangle your name to fit the RFC format'?
(That happens already in other cases, BTW. I'm called by my _middle_ name -
which cau
> From: "John Levine"
> what's different in Berlin from Paris and Prague and Maastricht.
The Germans have more 'zealous' tax collectors? :-)
Noel
> From: Scott Brim
> Please someone find and share the UUCP message where the body said "I
> don't understand the concern about too many message headers."
I don't know about there being a UUCP one, but here:
http://www.chiappa.net/~jnc/humour/net.header
is the ARPANET one.
> From: j...@mercury.lcs.mit.edu (Noel Chiappa)
> Yet.
PS: I probably should have added a ":-)" to that. Sorry, it's early, the
brain's not firing on all cylinders yet, and I was so entranced by the chance
to set the record for the shortest ever IETF list e-mail... :-)
Noel
> From: "Adrian Farrel"
> "told not to post" is, AFAIK only achievable through a posting ban,
> which you don't seem to have received.
Yet.
Noel
> From: John Curran
> the proposed language also increases the possibility of "capture" (i.e.
> the ability of an single organization to inappropriately skew the
> outcome of the process)
Why not just say directly that 'to prevent "capture", no more than X% of
the NomCom may wor
> From: Randy Bush
> there appears to be a problem with your mail system. mail which is
> clearly from the 1950s is appearing on the ietf list.
You're right about it having fallen through a time warp - but you got the
sign wrong. It's from the future, not the past.
Noel
> From: Doug Barton
> their work has been ignored and/or shouted down since it doesn't fit
> the narrative.
The usual fate of those who care more about the data than the herd-meme of the
moment. For a good example of this in action, those who are unfamiliar with
the work of Barbara M
> From: Melinda Shore
> it's likely that for a few cycles nomcoms will try to be "sensitive" to
> the question of the underrepresentation of women and then it will be
> back to business as usual ...
> It's unusual for people to voluntarily surrender their privilege.
Yes, the
> From: David Morris
> I've wondered for some time whether the reported bytes is the whole
> message I send included context quotes, or if there is an attempt by
> the summary logic to factor out quoted content.
I think it's a _feature_ to count the included content, so that peop
> From: "cb.list6"
> the emergent complex dynamical system we call the internet ... which is
> almost completely zero compliant to the e2e principle. Not that e2e is
> the wrong principle, but ipv4 could not support it as of 10+ years ago.
> Hence, nearly every internet node i
> From: Andrew Sullivan
> It's always April 1st somewhere on the Net?
Especially if you (or your packets, to be precise) can travel backwards in
time
Noel
> From: Melinda Shore
> If everybody serving that gatekeeper function comes from a similar
> background (western white guy working for a large manufacturer)
To toy with Godwin's law for a moment - this sounds rather like western white
guy physics...
Noel
> Subject: Re: Martians
> "Martian" is nice expression.
Weren't 'unusual' packets called 'Martians' at some early stage of Internet
work? It certainly has history in the IETF as a term of art, I think that's
it.
Noel
> From: Eric Burger
> With my legal services hat on, with the US joining the rest of the
> world with first-to-file, those few weeks of publication could mean the
> difference between a free and open standard and a NPE swooping in and
> attempting to tax the industry.
If that
> From: t.p.
> is this something that the IETF should be involved with or is it better
> handled by those who are developping LTE etc?
I would _like_ to think it's better done by the IETF, since congestion
control/response more or less has to be done on an end-end basis, so trying
t
> From: John Day
> I remember when a modem came with an 'acoustic coupler' because
> connecting it directly to the phone line was illegal.
> No, there was nothing illegal about it. The reason for acoustic
> couplers was that the RJ-11 had been invented yet and it was a pain to
> From: IETF Chair
> The ARPANET transitioned to TCP/IP on 1 January 1983. That was 30 years
> ago,
It's very hard indeed to fully grasp that it's only been 30 years. My kids
(now roughly 20) live in what is in some ways an entirely different world to
the one I grew up in.
Many tech
> From: "George, Wes"
>> Allocation != reservation.
> You're hairsplitting on semantics in a way that is mostly unhelpful to
> the discussion at hand.
I _thought_ that the point of the messages from Geoff and others (who were
questioning about how there were no details in the do
> From: "George, Wes"
> I don't think that expecting code to handle two blocks (the
> experimental one and the permanent one) is asking too much
We disagree. For me, it's extra code/complexity, and it buys you absolutely
nothing at all.
> If a single permanent allocation that ne
> From: Geoff Huston
I don't have any comment, one way or another, on what seems to be the basic
point of your note (about what role, if any, the IETF should play in
allocation).
However, there was one aspect I wanted to comment on (it's not clear, reading
your note, if this was clear in you
> From: Cameron Byrne
>> So it has transferred costs for communicating with site X from
>> 'everyone with a core table, everywhere in the entire network' to
>> 'just the people who are actually trying to communicate with site X'.
>> This is bad... how?
I didn't see an answer
> From: Cameron Byrne
>> If LISP succeeds, this results in significant reduction in core table
>> sizes for everyone.
> Not everyone. Only people who carry core tables.
'this results in significant reduction in core table sizes for everyone who
has core tables' sounds a bit taut
> From:
> the routing integration between none-LISP and LISP internet, how are
> that going to work? The current document isn't clear enough on that as
> I see it.
The way the routing will work would take a couple of PhD theses to fully
cover (I know of one that's already underwa
> From: Russ Housley
> And, the community does not have rough consensus for simply declaring
> his seat vacant under the current set of BCPs.
Why not, I cannot fathom, because as SM has pointed out (hat tip), RFC 4333,
"IAOC Member Selection Guidelines and Process", has text which i
> From: Doug Barton
> Removal from office _is_ considered a punitive action
Sorry all, but my bogometer just blew out.
He isn't being turfed out of his post (in a high-level sense); he quit.
He simply wasn't polite or thoughtful enough to do so formally, instead of by
just going catato
> From: Doug Barton
> When Marshall was appointed the rules we have now were in place.
> To change the rules now, and then apply them to this situation is by
> definition retroactive.
By that logic, _any_ change to any rule involving, say, the IESG (repeat for
all other I* bodie
> From: Barry Leiba
>> We're all agreed that the IETF in plenary mode (i.e. all of us) can
>> change any/all policy/procedures, right?
> Alas, that's not how we do things.
Wrong. That's exactly how we do things. Any piece of electronic paper you
point to to argue otherwise was
> From: David Morris
> someone unsatisfied with a business decision by the adjusted IAOC
> membership could sue based on documented process not being followed to
> appoint the membership.
Nothing can stop someone from filing a suit, no matter what you do (even if
you do follow pr
> From: Doug Barton
> recalling someone from one of these positions _should_ be hard to do,
> and should not be undertaken lightly.
No disagreement there - but we're not trying to recall him because of actions
he took, things he said, etc, etc.
Like I said, I think the US's federal
> From: Doug Barton
> You've also snipped out the entire portion of my message where I talked
> about actually changing the procedure
I happened to see one point I wanted to say something about (the 'hum group'
thingy), that's all.
And now that I've thought about this whole thing a
> From: Michael StJohns
> When would you consider the office vacant?
The complete data on what attempts had been made to communicate with him were
given to us all, so we can all form our own individual opinion as to whether
sufficient conditions had been met.
> I'm currently in jury
{Apologies for the bunched reply - I was offline for a bit, now trying to
catch up without inundating the list.}
> From: Theodore Ts'o
> Do we need to wait until someone who has made significant contribution
> to have passed away before we recognize their contributions?
> ...
> From: Michael StJohns
>> The IAOC is requesting feedback from the community concerning a
>> vacancy that the IAOC feels is not adequately covered by existing IETF
>> rules.
> I'm not sure why the IAOC thinks that the recall procedure shouldn't be
> followed.
Because it
>> Not that I object to the creation of such a construct - far from it
>> ..
>> So it's not a replacement for a Hall of Fame, which people might read,
>> or scan through, in its entirety.
> From: Scott Brim
> you're assuming that being remembered on an IETF wiki should b
> From: Scott Brim
> If this memorial wiki page could be open to anyone who ever contributed
> to any I* and for whom there was at least one person who wanted to
> contribute the information, then fine.
Then it turns into (effectively) a phone book - and I don't know too many
peo
> From: Randy Bush
> i am not sure abha or jon would want to be on such a list. remember
> them and honor and carry on their work, don't memorialize them.
I hear you, but I am also mindful of human nature - and people often
(usually?) tend to be startlingly non-conversant with histor
> The IESG has received a request from the author to consider the
> following document:
> 'Automated Updates of DNS Security (DNSSEC) Trust Anchors,' RFC 5011
> as an Internet Standard.
> ...
> The IESG plans to make a decision in the next few weeks, and solicits
> final
> From: "Eggert, Lars"
>> The IESG has received a request from an individual submitter to
>> consider the following document:
>> - 'Obsoleting the Endpoint Identifier (EID) Option'
>> as Proposed Standard
> Have the original authors [sic - JNC] been contacted?
Alas, t
> The IESG has received a request from an individual submitter to
> consider the following document:
> - 'Formally Deprecating some IPv4 Options'
> ...
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.
This seems like
> From: Dave Crocker
> Apparently you consider the IRTF, IAB and RFC Editor all to be outside
> the IETF.
You apparently seem (from this) to think they're not? Wow.
Noel
> From: Randy Bush
> i say scott should teach emacs :)
Epsilon, dude! Who the heck wants to write their editor extensions in freaking
LISP? :-)
Noel
> From: Stephane Bortzmeyer
> I strongly regret that "Commerce" has a specific mention, among all the
> other uses of the Internet. The network is not only open for business!
I hear you, but unless the Internet were a money-making system it would not
have grown as quickly, or as larg
> From: Yoav Nir
> These operators are (hypothetically) Libyan citizens, right? Residents
> of Libya who could go to jail for routing around the problem. Most
> likely on a charge of espionage.
That worked pretty well for Qaddhafi. Oh, wait... Yes, it cost some whom he
did catch,
> From: John C Klensin
> It is worth remembering that in the most critical part of that period,
> the IETF wasn't developing/pushing TCP/IP in the marketplace but had
> its face firmly immersed in the KoolAid trough
Ahem. There were quite a few of us in the IETF sphere who were n
> From: "Andrew G. Malis"
> 260-bit address should be sufficient to [s]address[/s] _name_ every
> atom in the universe
YPIF.
Noel
h
> From: Yoav Nir
> I live in the same house. My computer is connected to the same socket
> in the wall.
That's your physical location. Irrelevant (basically) ato the network.
> All I changed was the ISP. Why do we call the = thing that's changed
> "location"?
'Location' in
> From: Yoav Nir
> For organizations renumbering is more painful, but as long as there's
> plenty of time to prepare - it should be manageable. If it's too
> painful, there are provider independent addresses, but how many really
> need them?
Or we could separate location and
> From: m...@sap.com (Martin Rex)
> To me, IPv6 PA prefixes look like a pretty useless feature (from the
> customer perspective).
Far be it from me to defend IPv6, but... I don't see the case here.
Our house is pretty typical of the _average_ consumer - we have a provider
suppplied
> From: Phillip Hallam-Baker
> to stop such things as 'Information terrorism' which is their term for
> freedom of speech.
:-)
> The current governance structure of the Internet does more than merely
> prevent other governments from gaining control of the Internet, it
>
> From: Yoshihiro Ohba
> Probably nothing can be perfect when defining "affiliation", but I
> think some definition can help reducing hidden conflict of interests.
I suspect that unless it is done very carefully, any more extensive definition
is simply going to open additional potent
> From: Ole Jacobsen
> using the American "quotation outside punctuation rule."
Ugh. There may be uglier typographic conventions, but off the top of my head,
I can't come up with one.
Noel
> From: James Polk
> outstanding - now we can't meet that whole year... ;-)
Particularly since in _my_ religion, our religious days consist of the set of
days which _aren't_ religious holidays in any other religion... :-)
Noel
FYI; this seems relevant to us:
Tech Rivals Push Copycats Battle To The Hill
http://www.politico.com/news/stories/0712/78219.html
Excerpts:
"Apple and Microsoft are telling regulators and lawmakers that not all patents
are created equal. They say patents that have been developed by companies
> From: Stephan Wenger
> Hi Noel,
> "Affiliate" is overly broad, and undefined and therefore not supported
> by BCP79.
??? My suggested text did not include "affiliate"? Maybe you're looking at
someone else's text?
Noel
> From: Peter Saint-Andre
> traditionally the IPR rules have applied to real people
Well, like you, I don't want to get into a rathole on this. Yes, nothing we
do can absolutely stop patents going unknown about (e.g. patents from
entities which don't participate), but I would prefer to b
> From: Peter Saint-Andre
> With all due respect, that sentence could be improved.
Agree with others; splitting it up into two simpler sentences is an
improvement.
A tweak, though (you lost something in the second sentence):
Anything that you write, say, or discuss in the IETF, form
> From: Yoav Nir
> I've started working on draft-nir-ipv6-were-finally-deploying-it but
> I'm not sure what format would be an appropriate submission format in
> the 23rd century.
The Emperor finds your lack of faith... disturbing.
Noel
> From: Peter Saint-Andre
> It's bad enough that many IETFers speak in a highly colloquial fashion
> at our meetings. ... Showing up at your first IETF meeting is quite
> enough of "taking the plunge" [1] for most people.
If it's meeting attendees one is worried about, I'd have t
> From: Simon Perreault
> I think colloquialisms may often be as hard to understand as excellent
> but seldom-used vocabulary.
Indeed - and now that we have this really cool Internet thingy (it's odd to
think that young people have no memory of what the world was like before a
large
> From: Margaret Wasserman
I know I said I was going to stay out of this, but your note provoked some
generic architectural thoughts which I thought some might find interesting.
> NPTv6 has a great advantage over ... tunnel-based ID/LOC
> solutions in that the packet format of NPTv6
> From: Steven Bellovin
> NAT didn't really exist when the basic shape of v6 was selected.
I didn't use the term "IPv6" deliberately, and I'm not going to get into a
(pointless) debate about it now. However, I want to set the historical
record straight on this specific point, for any fut
> From: Doug Barton
> My comments were directed towards those who still have the mindset,
> "NAT is the enemy, and must be slain at all costs!"
In semi-defense of that attitude, NAT (architecturally) _is_ a crock - it puts
'brittle' (because it's hard to replicate, manage, etc) state
> From: Russ Housley
> There is no option in Mailman to specify attachment-stripping by
> user, only by list.
So? Have 'ietf@ietf.org' send a copy to to a new list, 'ietf-strippedietf.org'
(the latter being set in Mailman to strip), and those who prefer their IETF
email without inclu
Since there's no way to pick one choice which will make most people happy
(whichever one is picked, the proponents of the other will be unhappy), maybe
we should try and avoid making a choice? We could have two different back-end
distributions versions of the list: one which strips attachments, and
> From: John Scudder
> On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:
>> It may take engineering and evaluating some cache management
>> schemes
> Isn't it relevant to the architecture document, that it be possible
> for a reader to judge whether the architecture is
> From: John Scudder
> Re cache management schemes, I think that depends on whether you
> mean "system level behavior" of a small-scale system, or one
> operating at large scale or under some kind of stress. The earlier
> discussion notwithstanding, for practical purposes cach
1 - 100 of 510 matches
Mail list logo
