Re: NIST documents

[Steve Crocker]

In reference to

> Maybe the openness of the Internet owes a lot to this tradition.

let me offer a comment regarding the RFCs.  There might be a general 
connection, but there wasn't an explicit connection.  The decision that RFCs 
would be freely available and without restriction regarding use came primarily 
from me.  I was part of the team at UCLA, which together with our counterparts 
at SRI, UCSB and Utah developed the initial set of ideas about the Arpanet 
protocols.  When we started to write down our ideas, we wanted to remove all 
barriers for publication and use.  A participant from one of the institutions 
involved in the next round of connections, i.e., not one of the first four, 
expressed concern that his institution would require pre-publication review and 
approval, so we declared RFCs not to be "publications."

There was no directive from DARPA or anyone else in the government nor was 
there even discussion about this policy.  It was a pragmatic decision aimed at 
facilitating maximum communication with minimum overhead and minimum delay.  We 
implicitly assumed there would be formal processes for the "real" documents 
later, and, of course, the RFCs were just a temporary expedient intended to 
last just a few months…

I suppose if the course we set had been antithetical to the U.S. Government's 
wishes, we might have gotten some guidance to do something different, but I 
don't recall the subject ever coming up.  We not only wanted the rules to be as 
unrestrictive as possible, we also wanted to spend as little time as possible 
discussing the rules.

Steve



On Oct 4, 2013, at 8:35 AM, Thierry Moreau  wrote:

> Dearlove, Christopher (UK) wrote:
>> One draft I'm working on [...]
>> (Of course I haven't been able to check the copyright on [NIST documents ...)
> 
> As a author of IT-related documents, you should be aware that, by its 
> constitution plus long lasting tradition, the US government "works of 
> authorship" have no copyright claims on them. The principle being that "we, 
> the people" paid for a civil servant to make a write-up, nobody can claim 
> intellectual property. Maybe the openness of the Internet owes a lot to this 
> tradition.
> 
> So, NIST documents can be used as if in the public domain.
> 
> Bizarrely, the RSA and early public key crypto patents were filed precisely 
> because US government funding was involved, but that's part of a longer story.
> 
> Regards,
> 
> -- 
> - Thierry Moreau
> 
> CONNOTECH Experts-conseils inc.
> 9130 Place de Montgolfier
> Montreal, QC, Canada H2M 2A1
> 
> Tel. +1-514-385-5691

Re: Transparency in Specifications and PRISM-class attacks

[Steve Crocker]

Are we conflating back doors in implementations with back doors in protocol 
specifications?  It's certainly a conceptual possibility for there to be a back 
door in a protocol specification, but I don't recall ever hearing about one.  
On the other hand, back doors, both intended and unintended, in the software 
that implements protocols, are legion.

Steve

On Sep 20, 2013, at 11:25 AM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:

>> 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
>> introduced by different parties, so it's never safe.
> 
> Iff enough people are _carefully_ reviewing specs, that ought to find all the
> backdoors. An open process does have potential issues, but it's also the one
> with the best chance of producing a 'good' product.
> 
>> That being said, wouldn't it make more sense to admit that IETF is not
>> a good platform for devising, say, crypto protocols and act accordingly
>> (use 3rd party protocols ...)?
> 
> You mean, trust another entity, which might have been suborned? How are they
> less likely to have produced something without backdoors than the IETF?
> 
>   Noel

Re: ORCID - unique identifiers for contributors

[Steve Crocker]

I'm in agreement.

We have not had any standards so far regarding maintenance of the validity of 
contact information.  For example, my contact information for the April 1, 1995 
RFC 1776 is:

> Steve Crocker
>CyberCash, Inc.
>2086 Hunters Crest Way
>Vienna, VA 22181
> 
>Phone: +1 703 620 1222
>EMail: croc...@cybercash.com
> 
The email address, phone number and postal address became stale a long time 
ago.  If ORCID is introduced, it's likely to be at least as good as email 
addresses, etc.  Let's avoid or at least defer trying to endow them with 
additional properties such as permanence until there is some experience.

Steve




On Sep 17, 2013, at 12:16 PM, John C Klensin  wrote:

> 
> 
> --On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson
>  wrote:
> 
>> 
>> I did not know about ORCID before this thread.
>> I think it is brilliant, and what I've read about the mandate
>> of orcid.org, and how it is managed, I am enthusiastic.
>> 
>> I agree with what Joel wrote:
>> 
>> Asking for ORCID support in the tool set and asking for IETF
>> endorsement are two very different things.
>> 
>> Having tool support for it is a necessary first step to
>> permitting IETF contributors to gain experience with it.   We
>> need that experience before we can talk about consensus.
>> 
>> So, permit ORCID, but not enforce.
> 
> The more I think about it, the more I think that Andy or someone
> else who understands ORCIDs and the relevant organizations,
> etc., should be working on a URN embedding of the things.  Since
> we already have provisions for URIs in contact information, an
> ORCID namespace would permit the above without additional
> tooling or special RFC Editor decision making.  It would also
> avoid entanglement with and controversies about the rather long
> RFC Editor [re]tooling queue.
> 
> Doing the write-up would require a bit of effort but, in
> principle,
>URN:ORICD:
> is pretty close to trivially obvious.
> 
> Comments about dogfood-eating and not inventing new mechanisms
> when we have existing ones might be inserted by reference here.
> 
>> An interesting second (or third) conversation might be about
>> how I could insert ORCIDs into the meta-data for already
>> published documents. 
> 
> With a URN embedding that question would turn into the much more
> general one about how URIs in contact metadata could be
> retroactively inserted and updated. In some ways, that is
> actually an easier question.
> 
> best,
>   john
> 
> 
> 
> 
> 

Re: What real users think [was: Re: pgp signing in van]

[Steve Crocker]

Actually, I interpret the chemistry professor's comment in a different light.  
It would be possible to design a system where:

o the standard end user software doesn't facilitate editing the other person's 
text, and

o each piece of text is signed.

The result would be a system where a recipient would know whether the person 
who is alleged to have written a piece of the message actually did so, and the 
normal mode of use would be to leave things untouched.  Or, if you edit someone 
else's text, it immediately becomes your text.

Steve




On Sep 9, 2013, at 4:15 PM, Dave Crocker  wrote:

> On 9/9/2013 1:09 PM, Brian E Carpenter wrote:
>> I've just discovered that when
>> you forward or reply to a message, you can just change the other
>> person's text by typing over it! You'd have thought they would
>> make that impossible."
>> 
>> Yes, they should have made that impossible.
> 
> 
> Yeah, the pragmatics of truly independent, distributed processing 
> environments, with limited resources and fundamental human factors barriers 
> really are quite shocking.
> 
> d/
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: What real users think [was: Re: pgp signing in van]

[Steve Crocker]

Yes, I am speaking of what would be possible today with a fresh start.  The 
fresh start would also include signatures and encryption as a required part of 
the design.  (If everyone has to have a key, the key management problems would 
be greatly reduced.)

Steve

On Sep 9, 2013, at 4:36 PM, Dave Crocker  wrote:

> On 9/9/2013 1:27 PM, Steve Crocker wrote:
>> Actually, I interpret the chemistry professor's comment in a
>> different light.  It would be possible to design a system where:
>> 
>> o the standard end user software doesn't facilitate editing the other
>> person's text, and
>> 
>> o each piece of text is signed.
>> 
>> The result would be a system where a recipient would know whether the
>> person who is alleged to have written a piece of the message actually
>> did so, and the normal mode of use would be to leave things
>> untouched.  Or, if you edit someone else's text, it immediately
>> becomes your text.
> 
> 
> The professor's comment was on function, not method. My comment was on
> the limitations to methods available at the time.
> 
> In a controlled environment, with good resources, quite a bit is
> possible. Indeed, server-based "department-level" email products in the
> 1980s did enforce such restrictions. The single-administration servers
> had complete control over the message.
> 
> Distribution with independent administrative authorities makes this a
> very different game. Enforcement by fiat is impossible.
> 
> That's where signing comes in, of course. Modify the content and the
> signature fails. Besides the computational overhead -- which was
> relatively onerous back when the infrastructure was being established --
> this requires that the receiver know and demand that the signature be
> present; this requirement has its own adoption barriers.
> 
> Starting with a blank sheet and today's technologies, the requirement is
> possibly feasible to satisfy -- if we ignore the continuing human
> factors barriers to large scale email authentication. However given the
> resources at the time the operational service was developed, I think it
> wasn't.
> 
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: Remote participants, newcomers, and tutorials (was: IETF87 Audio Streaming Info)

[Steve Crocker]

Well, actually, the IETF is a continuation of the Network Working Group, which 
formed organically in late 1968.  We're a few days short of the 45 year mark.  
The NWG had open meetings, developed the layered architecture and published 
RFCs.

Steve

Sent from my iPhone

On Jul 27, 2013, at 9:07 AM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:

>> 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, 1977.
> 
> And yes, one person who was at that meeting is _still_ participating (he
> sent a message to the IETF list on 21 May, 2013; and had an RFC published
> this month - RFC 6975).
> 
> (And if you consider the Internet work to be connected to the ARPANET - which
> in some ways it is, because the RFC series shades slowly from NCP documents to
> TCP documents - he goes back a lot further than that: to RFC 1!  Thereby
> setting a 'first RFC to last RFC' record that's going to be very hard to beat!
> But I digress...)
> 
>Noel

IETF, ICANN and Whois (Was Re: Last Call: (The Internet Numbers Registry System) to Informational RFC)

[Steve Crocker]

#x27;s a place where the relevant people can get together to get 
their work done.  And, indeed, a number of ICANN people actively participate in 
various IETF working groups.)

The roster of topics active within ICANN at any given time is fully documented 
and publicized, and I invite anyone who is interested to participate.  We 
listen to everyone, and we publish tentative results, tentative policies, etc. 
for everyone to critique.

Let me now turn to Whois.  The Whois system's origins go back to the earliest 
days of the Arpanet.  The roles of technical point of contact and 
administrative point of contact were usually the system administrator and his 
administrative manager for the time-sharing system at the laboratory at that 
site.  Each time-sharing system served somewhere between a few dozen and a few 
hundred users.  The users were not listed, just the administrators for the 
system.  There weren't really any issues of accuracy, privacy or 
accountability.  Today, of course, these terms apply to the registrants and 
supporting personnel for *each* domain name, and there are well over 
100,000,000 domain names registered just within the generic top level domains.  
The country code top level domains are roughly the same number, and their Whois 
structures and policies are each controlled by the individual ccTLD operator 
and their communities.

Last November, the ICANN Board accepted the recommendations of the Whois Review 
Team, an expert group commissioned under the Affirmation of Commitments (AoC) 
ICANN signed with the U.S. Department of Commerce in 2009.  The terms of 
reference included in the AoC continued the original model that the structure 
of Whois remain the same and that access be free and available to everyone.  A 
number of us on the ICANN Board had been concerned for a long time that purpose 
of the Whois system had evolved far away from its original purpose, and that it 
was well past time to take a fresh look at the entire system.  Accordingly, the 
Board initiated an effort, in parallel with acceptance and implementation of 
the Whois Review Team's recommendations, to start with a clean slate and think 
through whether we might be better served by a revised system.  An expert 
working group was assembled and is currently working through these issues.  Its 
output will be a consideration of the issues and recommendations for further 
work.  It is not yet clear whether the result of this effort will lead to a 
large change, a small change, or no change at all.  What is clear is that the 
results of this working group will become fully public, and any decisions will 
come through our usual policy development process.

As I said above, I invite anyone who is interested to participate.

The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have all arisen 
within the ecosystem that accompanies the growth and prevalence of the 
Internet.  It is natural for there to be some tension, competition and rivalry 
among our institutions, but we have all been part of the same grand enterprise, 
we all share the same core values, and we all work toward the same goal of an 
open, innovative, expanding Internet.

Steve Crocker,
Chair, ICANN Board of Directors







On May 17, 2013, at 2:13 PM, John Curran  wrote:

> On May 15, 2013, at 7:50 PM, David Farmer  wrote:
> 
>> So lets play a little hypothetical here;  What if an RIR or ICANN through a 
>> global policy decided Whois Data no longer should be public for overriding 
>> privacy reasons.  My read of Section 5, is that would be proper path for 
>> such a change, and long as the technical guidance of the IETF is considered 
>> in the process.  But then through RFC 2860 and Section 5, if the IETF 
>> objected on technical or architectural grounds, and formally through the 
>> IESG, then the IAB would essentially adjudicate the issue.  And ICANN or the 
>> RIR are obligated to accept the decision of the IAB.  Do I have that right?
> 
> To be abundantly clear, you are hypothesizing a difference of opinion between 
> the 
> IETF/IESG and the ICANN/RIR communities, wherein the technical guidance of 
> the IETF 
> was considered during the ICANN/RIR decision process, but in the end the 
> outcome was 
> contrary to IETF expectations.
> 
> This would be an unfortunate (but not impossible) situation, as many folks in 
> the 
> combined community would likely have been involved during the process trying 
> to 
> figure out why there is such a significant difference in views and 
> facilitating
> sharing of the beliefs and thought processes that underlie the situation.  
> (btw,
> these types of efforts happen in more contexts than just the hypothetical one 
> you 
> suggest, and are a good reason to ask "Have you hugged your AD recently"? ;-)
> 
>> To be clear, I'm not advocating Whois should o

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

[Steve Crocker]

I too have always found at least one of the Crocker brothers {suspicious, 
smart, funny, irrelevant, prescient, handsome, annoying, etc.}. I've never been 
able to tell which is which :)

Sent from my iPad

On Apr 5, 2013, at 9:58 PM, Michael Richardson  wrote:

> 
>> "Loa" == Loa Andersson  writes:
>Loa> thinking about this and assuming that the FTL Communication are 
> deployed
>Loa> in a not too far distant future, wouldn't we have started to receive
>Loa> packets that was sent in the future already now?
> 
> I for one, have always found these Crocker brothers suspicious: always
> seem to have been at the key points in Internet future history.
> I think that they are in fact a single person.  
> One is going forward in time, and the other one backwards. 
> (Which is which, is still open to debate)
> 
> So I claim that we  will have been receiving packets from the future for
> some time now.
> 
> -- 
> ]   Never tell me the odds! | ipv6 mesh networks 
> [ 
> ]   Michael Richardson, Sandelman Software Works| network architect  
> [ 
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [ 
>

Re: Acoustic couplers

[Steve Crocker]

I honestly don't remember whether the plugs were the clunky four pin or the 
then-modern RJ11.  I recall studying RJ11 and RJ45 plugs and sockets at some 
point and discovering that some plugs and sockets had six wires instead of only 
four or two.  I never did learn if they had a different number.  The form 
factor was the same.

This was GTE territory.

Steve

On Jan 3, 2013, at 10:36 AM, John C Klensin  wrote:

> 
> 
> --On Thursday, January 03, 2013 10:10 -0500 Steve Crocker
>  wrote:
> 
>> In 1974 I moved into a condo complex in Marina del Rey near
>> USC-ISI.  As has been my usual practice, I ordered two POTS
>> lines and I went to the phone company to get the phones.  The
>> condo was pre-wired with jacks in each of the major rooms.
>> The phones I got from the phone company came with plugs that
>> were wired for either line 1 or line 2.  It took me a minute
>> of incredulity to understand the system.  Each jack was wired
>> for both lines, and each phone was wired to connect to one or
>> the other of the two lines.  Clever but definitely different
>> from anything I had seen before.  I could move the phones from
>> room to room.  Each phone "knew" whether it was for line 1 or
>> line 2.
> 
> Steve,
> 
> Just out of curiosity and if you remember, were those pre-wired
> jacks the round four-pin puppies, RJ series, or something else?
> I saw those sorts of setups several times with the four-pin
> jacks but never with RJ11/14 ones.  Of course the "knowledge" in
> the phone was about which pair was connected to the screw
> terminals on the inside so, if one ignored the threats and took
> the cover off the phone...
> 
> Equally out of curiosity, was MdR in Pac Bell or GTE territory
> at the time?  I know that some of their policies were different,
> but don't know which ones and what the actual consequences were.
> 
>john
> 

Re: Acoustic couplers

[Steve Crocker]

In 1974 I moved into a condo complex in Marina del Rey near USC-ISI.  As has 
been my usual practice, I ordered two POTS lines and I went to the phone 
company to get the phones.  The condo was pre-wired with jacks in each of the 
major rooms.  The phones I got from the phone company came with plugs that were 
wired for either line 1 or line 2.  It took me a minute of incredulity to 
understand the system.  Each jack was wired for both lines, and each phone was 
wired to connect to one or the other of the two lines.  Clever but definitely 
different from anything I had seen before.  I could move the phones from room 
to room.  Each phone "knew" whether it was for line 1 or line 2.

Steve

On Jan 3, 2013, at 9:52 AM, Dave Crocker  wrote:

> 
> 
> On 1/2/2013 7:08 PM, Ned Freed wrote:
>> Of course. However, we're talking about post-Carterphone here.
>> Carterphone was
>> 1968, and I'm sure four pin plugs were in use by then.
> 
> Not in Los Angeles.  As I recall, all the phone around there were hardwired 
> into the 70s.
> 
> 
>> Also keep in mind that AT&T fought the Carterphone decision for many years.
> 
> So it would seem...
> 
> I went to work at MCI in 1983, building MCI Mail.  Our group was on M street, 
> near corporate HQ.  One morning I got a call telling me to come into work 
> wearing sloppy clothes. (This was normally a 3-piece suit place.)  There had 
> been a fire on the floor above, where the MCI attorneys for the case against 
> AT&T worked.  Lots of water and smoke damage.  The claim was that the fire 
> had burned, um... especially hot...
> 
> 
>> A line mod was probably against the rules irrespective of Carterphone in
>> those
>> days. But had you bought your own phone with a ringer switch and hooked
>> that
> 
> Not allowed at that point.  All user equipment that was wired to the system 
> had to come from the phone company in L.A.
> 
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: In Memoriam IETF web page -- a modest proposal

[Steve Crocker]

After watching the traffic on this, I'm thinking a memorial page is perhaps not 
the first place to focus attention.  Instead, write a memorial RFC for each 
person you think made a significant contribution to the IETF.  The RFC 
Editorial process will provide some vetting on quality.  Use Informational, 
Historic(!) or create a new class.

The memorial page can then list those who have memorial RFCs written for them.

Steve

Re: So, where to repeat? (was: Re: management granularity)

[Steve Crocker]

I'll bet Dublin would be rated higher if the meetings had been downtown.  Same 
for Vienna.

Steve
 
On Aug 7, 2012, at 5:55 PM, Tim Chown wrote:

> Hi,
> 
> My top three repeat venues would be Prague, Minneapolis and Vancouver.  Great 
> meeting venues, with everything you need nearby.
> 
> My least favoured venues have been Dublin, Vienna and Maastricht.
> 
> Of course, you have to experiment to find good repeat venues...
> 
> Tim

Re: Variable length internet addresses in TCP/IP: history

[Steve Crocker]

This is essentially correct.  The apparent conceptual difference is that a 
variable length address looks more like source routing.  The end system owns 
only a small part of the total address; the rest is the network portion, 
fashioned to seem like a source route.  Depending on how the address is 
interpreted, the division of the network portion into routing steps will be 
specified in advance or will be interpreted at each step.  The latter alllows 
gradual evolution of the network by consolidating small switches into larger 
ones.

The transition to CIDR within IPv4 accomplished pretty much the same thing and 
had the same benefits.  Nonetheless, 32 bits just isn't enough.  The only way 
variable length address would have provided a smooth transition is if there had 
been room to increase the length of the address after some years of use.  Well, 
if we had left room in the address field for more than 32 bits, we'd have had 
the same advantage.  But we didn't.

Steve

On Feb 15, 2012, at 4:10 PM, Stephen Sprunk wrote:

> On 15-Feb-12 08:42, Dave CROCKER wrote:
>> As I recall, there was essentially no experience with variable length
>> addresses -- and certainly no production experience -- then or even by
>> the early 90s, when essentially the same decision was made and for
>> essentially the same reason.[1]
>> 
>> It's not that variable length addressing is a bad idea; it's that it
>> didn't get the research work and specification detail it needed, for
>> introduction into what had become critical infrastructure.  What I
>> recall during the IPng discussions of the early 90s was promotion of
>> the /concept/ of variable length addressing but without the
>> experiential base to provide assurance we knew how it would operate.
> 
> The problem with variable-length addressing that, in practice, one needs
> to specify a maximum length.  The result, therefore, is that you don't
> have variable-length addresses at all but rather fixed-length addresses
> with a shorthand encoding for unused bits.
> 
> S
> 
> -- 
> Stephen Sprunk "God does not play dice."  --Albert Einstein
> CCIE #3723 "God is an inveterate gambler, and He throws the
> K5SSSdice at every possible opportunity." --Stephen Hawking
> 
> 
> ___
> 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: Variable length internet addresses in TCP/IP: history

[Steve Crocker]

The word alignment issue was very strong and the router people had considerably 
more influence than the host folks.  I tried to propose variable length 
addressing using four bit nibbles in August 1974 and I got no traction at all.

Steve

Sent from my iPhone

On Feb 14, 2012, at 6:31 PM, Bob Braden  wrote:

> On 2/13/2012 7:53 PM, Noel Chiappa wrote:
>> >  From: Brian E Carpenter
>> 
>> >  The design error was made in the late 1970s, when Louis Pouzin's 
>> advice
>> >  that catenet addresses should be variable length, with a format 
>> prefix,
>> >  was not taken during the design of IPv4.
>> 
>> Ironically, TCP/IP had variable length addresses put in _twice_, and they 
>> were
>> removed both times! (You can't make this stuff up! :-)
> Noel,
> 
> You probably remember this, but...
> 
> Within the ARPA-funded Internet research program that designed IP and TCP, 
> Jon Postel and
> Danny Cohen argued strenuously for variable length addresses. (This must have 
> been
> around 1979. I cannot name most of the other 10 people in the room, but I have
> a clear mental picture of Jon, in the back of the room, fuming over this 
> issue. Jon believed
> intensely in protocol extensibility.)
> 
> However, Vint Cerf, the ARPA program manager, rules against variable length 
> addresses and
> decreed the fixed length 32 bit word-aligned addresses of RFC 791. His 
> argument was that
> TCP/IP had to be simple to implement if it were to succeed (and survive the 
> juggernaut
> of the ISO OSI protocol suite).
> 
> System programmers of that day were familiar with word-aligned data
> structures with fixed offsets, and variable length addresses seemed to be 
> (and in fact
> would be) harder to program and would make packet dumps harder to interpret.
> 
> It was a political as much as a technical judgment, and Vint may have been 
> right ... we
> can never know. We do know that IP eventually succeeded and OSI failed, but it
> was a near thing for awhile. Of course, there were other factors in the 
> success
> of IP, such as Berkeley Unix.
> 
> It is to be noted that when it came time to define IPv6 some 20 years later, 
> the IETF
> stuck with fixed length internet addresses.
> 
> Bob Braden
> 
> ___
> 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: The death John McCarthy

[Steve Crocker]

I was at the MIT AI Lab 1967-68 and at ARPA/IPTO 1961-74 where I funded and 
reviewed the Stanford AI Lab.  Later I based my PhD thesis on McCarthy's memo 
on situational fluents.  I also designed but didn't implement Lisp for the 
Sigma 7.

Later I ran research groups and insisted on Lisp as a requirement.

Steve

Sent from my iPhone

On Oct 31, 2011, at 3:44 PM, todd glassey  wrote:

> On 10/28/2011 1:25 PM, Randy Bush wrote:
 First, as someone who chartered the working group, who has
 implemented Lisp (the programming language) at least four times, and
 who views Dr. McCarthy as a hero I disagree that name is problematic
 or disrespectful. And I almost take offense in the claim that this is
 a generational thing.
>>> And frankly, if there's disrespect to be found here, IMO it lies in
>>> using this sad event as a proxy to criticize some IETF work some
>>> people apparently don't like.
> 
> So how many people here actually knew or worked with John... or what he was 
> working on?  its a relevant question because there seem to be a number of 
> people speaking from authority... so how many of you were around in the 
> 1960's and 1970's at AI (either MIT or SU)?
> 
> I bring this up as t...@suai.edu...
> 
> T///
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> 
> 
> -- 
> Todd S. Glassey
> This is from my personal email account and any materials from this account 
> come with personal disclaimers.
> 
> Further I OPT OUT of any and all commercial emailings.
> 
> ___
> 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: RIP, Einar Stefferud, 1930-2011

[Steve Crocker]

Nathaniel,

Thanks for passing this along.

I had the pleasure of working for Stef almost 50 years ago.  I was a freshman 
at UCLA in 1961.  Stef was on the staff of the Western Data Processing Center 
(WDPC), one of two major data centers IBM had set up with universities to 
foster the use of computing within business schools.  WDPC had the IBM 700/7000 
series scientific computer -- a 709, followed by a 7090, a 7094 and then a 
large 360 series machine.

As it happened, I started to work for Stef exactly on my 17th birthday in 
mid-October, so I remember the date easily.  Stef had previously spent time at 
CMU where, among many other things, he had learned IPL-V, a pioneering list 
processing language that was shortly superseded by LISP.  Stef and his boss had 
a project to write an IPL-V compiler, and although the project didn't reach 
fruition, it opened my eyes to a rich set of possibilities.

Stef was indeed a kind man.  He was a pleasure to work for and I felt very 
fortunate to have encountered him early in my career.  We crossed paths in the 
IETF and in the payments business -- I was involved in a start up competitive 
with First Virtual -- and always enjoyed a lively exchange.  I will miss him.

Steve



On Sep 26, 2011, at 12:51 AM, Nathaniel Borenstein wrote:

> For those who haven't heard, Einar Stefferud passed away this week.  Many of 
> you will remember Stef as an early pioneer of email.  My own remembrance of 
> him can be found here:
> 
> http://blogs.msexchange.org/migration/2011/09/25/an-underappreciated-email-pioneer-einar-stefferud-1930-2011/
> 
> 
> ___
> 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

Is the IAOC responsive?

[Steve Crocker]

In response to Sam's comment re whether the IAOC is responsive and/or 
transparent, if this is indeed a problem it needs to be fixed.  As a founding 
member of the IAOC, I can attest that these two qualities, responsiveness and 
transparency, were the driving concerns that led to the creation of the IASA.

Having served on the IAOC and having watched successive administrations, I know 
first hand the old verity, "You can please all of the people some of the time 
and some of the people all of the time, but you can't please all of the people 
all of the time."  Moreover, it's almost always the people that are unhappy 
that make the most noise.

All of this is normal and to be expected.  That said, the IETF is in full 
control of the IAOC, so if they're not responsive and/or not transparent, it's 
relatively easy to get their attention and/or replace them.  But the more 
likely situation is that different subgroups within the IETF want different 
things, and it's simply impossible to satisfy everybody.  There are surely a 
large fraction of attendees who like having everything in one place and who are 
relatively insensitive to the price.  Whether that should be the prevailing 
answer is up to the overall community.  The IAOC will surely do whatever the 
overall community wants, as long as it's actually feasible.  If the community 
insists on contradictory or impossible results and then insists on blaming the 
IAOC, we'll simply have dysfunctional chaos.

Let's get the facts laid out for all to see, figure out what choices we're 
going to make, and then live with the results.

Thanks,

Steve

Full disclosures:

1. My brother, Dave Crocker, is currently on the IAOC.

2. I did not discuss this with him.  In general, we have different value sets 
with respect to meetings (and many other things).

3. Whenever he and I are aligned, we're almost always right.



On Aug 24, 2011, at 3:28 PM, Sam Hartman wrote:
> 
> 
> 2) If I had to say yes or no in a parliamentary vote of confidence in
> the IAOC, today my answer would probably be no.  I feel that a lot of
> concerns have been raised, and I don't find the responses very
> convincing.  When I've looked into issues with the IAOC, I haven't found
> the visibility necessary to really evaluate things.
> That to me is not a good combination.
> ___
> 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: 25 or 6to4

[Steve Crocker]

I did an interview for BBC Radio for New Year's Day several years ago about the 
early days of developing the Arpanet.  The closing question was why, in 1968, 
we weren't at Woodstock.  I replied, "For us, computers were the drug of 
choice."

Steve

On Jun 22, 2011, at 6:46 AM, Ralph Droms wrote:

> Now that I've swapped back in some more recollections - yes, I did see 
> Chicago perform it live when it was first released - I'm glad you finally 
> cleared up the meaning behind the lyrics.  I always thought the lyrics 
> somehow drug-related ... of course, we thought a lot of lyrics were 
> drug-related then.
> 
> More recently I thought it was about reading drafts for a telechat.
> 
> - Ralph
> 
> On Jun 21, 2011, at 6:18 PM 6/21/11, Peter Saint-Andre wrote:
> 
>> I needed a diversion from reviewing draft-ietf-v6ops-6to4-to-historic
>> and its associated IETF LC comments. Back to my IESG duties now... ;-)
>> 
>> On 6/21/11 4:14 PM, Ralph Droms wrote:
>>> Wow.  An absolute tour de force from someone who *clearly* has too much 
>>> time on his hands.
>>> 
>>> Thanks; made my day.  Well, except for now I've got that long-forgotten 
>>> tune stuck in my head...
>>> 
>>> - Ralph
>>> 
>>> On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote:
>>> 
 A bit of levity about migration to IPv6, with apologies to Robert Lamm
 and with thanks to Dan Wing and Joe Hildebrand...
 
 ###
 
 "Waiting for the break of day" (yes, the dawn will come with the
 universal deployment of IPv6)
 
 "Searching for something to say" (how will we communicate once IPv4 is
 gone?)
 
 "Flashing lights against the sky" (hoping for extraterrestrial
 intervention to solve the problem)
 
 "Giving up I close my eyes" (ignoring IPv4 address exhaustion)
 
 "Staring blindly into space" (have you ever read all the IPv6-related
 specifications in one sitting?)
 
 "Getting up to splash my face" (February 3, 2011 was a wakeup call, no?)
 
 "Wanting just to stay awake" (simply wishing for the Internet to keep
 working)
 
 "Wondering how much I can take" (these v4 to v6 discussions are
 interminable, aren't they?)
 
 "Should I try to do some more?" (pondering the idea of writing an
 Internet-Draft)
 
 "25 or 6to4" (yes, port 25 is the answer -- perhaps the problem will
 solve itself if we all just send more email to ietf@ietf.org!)
 
 ###
 
>> 
> 
> ___
> 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: How to pay $47 for a copy of RFC 793

[Steve Crocker]

Bob,

Thanks!  I had always thought 47 was an uninteresting number.  I wasn't sure if 
it was the least uninteresting number, and if it were, it would automatically 
be interesting(*), but now I see it's interesting even if it's not the least 
uninteresting number :)

Steve

* For those on this list not familiar with math jokes, there's a "proof" there 
are no uninteresting numbers: Suppose some (positive) integers are interesting 
and the rest are uninteresting.  Consider the least of the uninteresting 
numbers.  That's surely an interesting number...



On May 12, 2011, at 5:09 PM, Bob Hinden wrote:

> Steve,
> 
> On May 9, 2011, at 5:05 PM, Steve Crocker wrote:
> 
>> A simpler and more pragmatic approach is to include a statement in the 
>> boilerplate of every RFC that says, "RFCs are available free of charge 
>> online from ..."
>> 
>> The copyright rules would prohibit anyone from removing this statement.  If 
>> someone pays $47 for a copy and then reads this statement, he is unlikely to 
>> pay $47 again.
>> 
> 
> I wonder how they came up with $47?  
> 
> It is such a nice prime number.  See:
> 
>  http://en.wikipedia.org/wiki/47_(number)
> 
> I recommend reading it.  I never knew that a number could be so interesting.
> 
> Bob
> 
> p.s. Maybe this can be the end of this thread...
> 
> 
> 
> 

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

Re: How to pay $47 for a copy of RFC 793

[Steve Crocker]

A simpler and more pragmatic approach is to include a statement in the 
boilerplate of every RFC that says, "RFCs are available free of charge online 
from ..."

The copyright rules would prohibit anyone from removing this statement.  If 
someone pays $47 for a copy and then reads this statement, he is unlikely to 
pay $47 again.

Steve

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

Re: IAOC: delegating ex-officio responsibility

[Steve Crocker]

Minor point: I think the proposal is to delegate authority but not to 
relinquish responsibility.  

Steve

Sent from my iPhone

On Mar 30, 2011, at 8:32 AM, Michael StJohns  wrote:

> Some suggestions:
> 
> 
> Replace "delegate their responsibilities" with ", by written action, delegate 
> specific responsibilities of their position".
> 
> Add after "IESG and IAB respectively."  "A delegation must be reconfirmed if 
> a change in the scope of the delegation is desired."
> 
> Replace "The terms of delegation..." with "The effective duration of 
> delegation shall be selected by the delegator, but shall not extend past the 
> end of that delegator's current term. Delegations may be renewed 
> indefinitely."
> 
> Add at the end "A delegation may be revoked with or without prior notice at 
> any time by the delegating chair or CEO or by action of the confirming body."
> 
> 
> At 07:21 AM 3/30/2011, Olaf Kolkman wrote:
> 
>> Dear Colleagues,
>> 
>> I have just chartered a very short draft that intends to update BCP101. It 
>> can be found at:
>> http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
>> 
>> The draft is very short and contains only a few sentences of substance:
>> 
>>  The IETF chair, the IAB chair, and the ISOC President/CEO may
>>  delegate their responsibilities to other persons.  The delegations by
>>  the IETF chair and the IAB chair need to be confirmed by the IESG and
>>  IAB respectively.  The terms of delegation is for a longer term for
>>  instance aligned with the IESG and IAB appointment cycles (roughly
>>  anual).
>> 
>> John Klensin made me aware he also had a similar idea earlier:
>>  http://tools.ietf.org/id/draft-klensin-iaoc-member-00.txt
>> 
>> The main difference is between his and this draft is that John's I-D makes 
>> the person the chair delegates to a non-voting liaison. I have a small 
>> preference for the IAB and the IESG keeping the control point, and I 
>> implicitly assume that for IASA matters the persons delegated to will 
>> escalate to the chairs and ask for specific guidance when appropriate. I 
>> realize that for the Trust anybody serves on personal title. For the trust 
>> alignment with the IAOC membership is just a practical considerations.
>> 
>> The shared requirement is unloading the I* chairs and the ISOC president and 
>> empowering the people that serve in that role to organize themselves. (I 
>> should have paid more attention to this much earlier.)
>> 
>> I plan to seek a sponsoring AD for getting this I-D published as a BCP 
>> shortly. 
>> 
>> Assuming this is an appropriate list for further discussion,
>> yours,
>> 
>> --Olaf
>> 
>> 
>>  
>> 
>> Olaf M. KolkmanNLnet Labs
>>  Science Park 140, 
>> http://www.nlnetlabs.nl/   1098 XG Amsterdam
>> 
>> 
>> 
>> ___
>> 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: US DoD and IPv6

[Steve Crocker]

Mebbe.  I confess I didn't study the details of the competing proposals at the 
time because I was confident the people who were heavily involved surely had 
things under control.

Steve

On Oct 10, 2010, at 6:41 PM, Dave CROCKER wrote:

> 
> 
> On 10/10/2010 2:51 PM, Steve Crocker wrote:
>> A compatible solution would have been better, but I don't think IPv4... --
>> were designed in a way that permitted a compatible extension.
> 
> 
> Oh?
> 
> Perhaps:
> 
>   1.  Adopt an IPv6 as Steve Deering originally designed it[1]:  A basic 
> upgrade to the IPv4 header, with more address bits, an extensibility 
> mechanisms for adding fields later, and removal of some bits that weren't 
> needed.
> 
>   2.  Define the IPv6 address space as the IPv4 address space, with all 
> zeroes for the higher bits.  (In other words, defer more interesting schemes 
> until later.)
> 
>   3.  Design header translation devices to map between the two formats.
> 
>   4.  Start fielding these implementations.  (That could have started by 1994 
> or so.)
> 
> The "gateways" between v4 and v6 would initially be notably for having almost 
> no work to do and of not losing any information.  In particular, barely 
> qualifies as a "dual" stack.
> 
> With this approach, "incompatibility" between v4 and v6 would only occur when 
> additional addresses, beyond v4's limitations, start to be assigned.
> 
> We must deal with the current reality and make it work, but historical 
> considerations need to factor in the ambitions that dominated during the many 
> years of design.
> 
> The community got ambitious in a fashion that smacked of the overreaching 
> that is often called second system syndrome (although counting the Arpanet, 
> this was really a third system...)
> 
> d/
> 
> [1]  http://tools.ietf.org/html/draft-deering-sip-00
> -- 
> 
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net

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

Re: US DoD and IPv6

[Steve Crocker]

John,

See below for an attempt at a more nuanced position.

Steve

On Oct 8, 2010, at 10:49 AM, John C Klensin wrote:

> 
> 
> --On Friday, October 08, 2010 09:47 -0400 Steve Crocker
>  wrote:
> 
>> Let me say this more strongly.  These two defects, "it wasn't
>> economically feasible ... and it didn't offer any
>> interesting/desirable new capabilities" were mild compared to
>> an even bigger defect: There simply wasn't a technically
>> feasible plan on the table for co-existence and
>> intercommunication of IPv4 and IPv6 networks.
>> 
>> In addition to working our way through the IPv6 adoption and
>> co-existence process, I think it would be useful to do a
>> little soul-searching and ask ourselves if we're so smart, how
>> come we couldn't design a next generation IP protocol and work
>> out a technically viable adoption and co-existence strategy.
>> The "dual stack" approach implicitly assumed everyone would
>> have both an IPv6 and an IPv4 address.  If everyone has both
>> kinds of addresses, that implicitly asserts there's no visible
>> shortage of IPv4 addresses, which is contrary to fundamental
>> reason IPv6 is needed.  Further, although some scenarios
>> suggest IPv4 usage will start to decline steeply once IPv6
>> transport, products and services are widely available, the
>> safer bet is that IPv4 networks will persist for a fairly long
>> time, say 20 to 50 years.
> 
> Steve,
> 
> While I agree with what you say (and most of what Noel says),
> hindsight is pretty easy.   I even agree with your 20 to 50 year
> estimate although an optimist might draw some comfort from how
> quickly CLNP and CONP, TP0 and TP4 (and the rest of the OSI
> machinery), Vines and Netware, etc., disappeared once the
> network effects set in and the writing appeared on the wall.

Predicting timing is the very hardest part of introduction of new technology.  
Sometimes it goes fast; sometimes not.  I'd be surprised if IPv4 disappears in 
substantially less than 20 years.  50 years does seem kind of long, but I think 
that's the right horizon to consider.  If it disappears more quickly, that's 
fine.

To put a slight bit more structure on this, I think there are five epochs:

1. Pure IPv4

2. IPv4 is dominant; IPv6 is showing up in pockets

3. Strong operation of both IPv4 and IPv6

4. IPv6 is dominant but IPv4 is still heavily used

5. IPv6 dominates and IPv4 has essentially disappeared.  (More or less 
symmetric with pure IPv4, but there's likely to be some isolated pockets or 
enclaves.)

We're in the early stages of the second epoch, in my view.

> However, certainly Noel's position was part of the discussion
> 15-odd years ago.   Certainly the positions that IPng must
> either be strictly forward compatible or that it should
> introduce enough new and valuable functionality to make people
> want to incur the pain were part of the discussion.

I don't think these are the only two choices, though I agree that either of 
these would have been more attractive than the position we're in.

In lieu of compatibility, we needed a viable co-existence and transition plan.  
I don't think the dual stack approach was ever viable, no matter how optimistic 
one might have been about the adoption of IPv6.  As I understand it, the idea 
behind dual stack is that all new end systems, all wide area and enterprise 
networks, and all services would become IPv6 capable, and all new systems would 
operate smoothly in both IPv6 and IPv4 mode.  Then, when it was evident that 
everyone who had an IPv4 address also has an IPv6 address, new systems could 
appear that were IPv6 only.  And all of this would happen before IPv4 addresses 
ran out.

I think it would have been -- and still is -- sensible to dissect the picture 
in terms of the different types of players -- end users, enterprise operators, 
ISPs, content providers and perhaps others.  Further, imagine that each type of 
players have a mixture of early, medium and late adopters.  Or, perhaps more 
usefully stated, at any given point in time, some are IPv4-only, some are 
IPv6-only and some are operating in both IPv6 and IPv4 mode.  Is there a 
sequence of transitions that allows each type of player to move through its own 
transitions and still interoperate with everyone else?

Without going into extensive discussion of the details, it seems to me 
inescapable that we would need application level gateways, and that there will 
be some breakage because some of the protocols have IP addresses embedded as 
data.

The good news, from my point of view, is that the requisite steps are now being 
taken to design and build the components that will permit IPv4 and IPv6 systems 
to co-exist and interoperate.

> Nonethe

Re: US DoD and IPv6

[Steve Crocker]

Let me say this more strongly.  These two defects, "it wasn't economically 
feasible ... and it didn't offer any interesting/desirable new capabilities" 
were mild compared to an even bigger defect: There simply wasn't a technically 
feasible plan on the table for co-existence and intercommunication of IPv4 and 
IPv6 networks.

In addition to working our way through the IPv6 adoption and co-existence 
process, I think it would be useful to do a little soul-searching and ask 
ourselves if we're so smart, how come we couldn't design a next generation IP 
protocol and work out a technically viable adoption and co-existence strategy.  
The "dual stack" approach implicitly assumed everyone would have both an IPv6 
and an IPv4 address.  If everyone has both kinds of addresses, that implicitly 
asserts there's no visible shortage of IPv4 addresses, which is contrary to 
fundamental reason IPv6 is needed.  Further, although some scenarios suggest 
IPv4 usage will start to decline steeply once IPv6 transport, products and 
services are widely available, the safer bet is that IPv4 networks will persist 
for a fairly long time, say 20 to 50 years.

Steve




On Oct 8, 2010, at 9:36 AM, Noel Chiappa wrote:

>> From: Keith Moore 
> 
>> What doesn't work well is to have everyone decide for himself how to
>> change the architecture.
> 
> The reason we have/had a free-for-all on the architectural front is that the
> IETF's choice for architectural direction (15 years ago) was non-viable (i.e.
> wrong); it wasn't economically feasible (in terms of providing economic
> benefits to early adopters, or otherwise having an economically viable
> deployment plan), and it didn't offer any interesting/desirable new
> capabilities (which was a big factor in the former).
> 
> With an 'approved direction' that didn't work, having people go off in their
> own directions instead was an inevitable corollary.
> 
> Which is why I am urging the IETF to be _realistic_ now, and accept the world
> as it actually is, and set direction from here on out based on that, and not
> on what we wish would happen. Which means, for instance, that any design for
> architecural change (e.g. introducing separation of location and identity) is
> going to be somewhat ugly, because we don't have a clean sheet of paper to
> work with. It also means accepting that we have multiple naming domains at
> the end-end level, and will for the forseeable future; and trying to work out
> an architectual direction for coping with that ('get rid of it' doesn't
> count). Etc, etc, etc.
> 
>   Noel
> 
> ___
> 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: Revised IAOC Administrative Procedures draft

[Steve Crocker]

I've generally stayed out of this discussion, but let me offer a word  
of support to Bob, et al re maintaining some flexibility.  There are  
two very strong protections already in place in this system.  First,  
the operation of the IAOC -- and IASA -- are fully documented and  
visible.  If the IAOC does something inappropriate, it will become  
visible and everyone will learn from it. Second, bills get paid  
through ISOC's normal processes.  ISOC has a set of controls in place  
to document expenses and make sure they follow the expected set of  
rules.  In addition to these strong protections, a questionable  
expenditure, even if it's several thousand dollars, isn't going to go  
irreparable harm to the IETF or ISOC.  Trying to prescribe a strict  
set of rules in addition to these protections is counterproductive and  
may remove flexibility that's needed for the benefit of the IETF at  
some future time.


The IETF's success, and, indeed, the success of the whole Internet,  
has come from maximum flexibility and minimum a priori rules and  
permissions.  We can easily afford to wait for the IAOC to screw up in  
some egregious fashion before we have to draft and administer rules to  
prevent subsequent abuses.  In the meantime, let the IAOC do its job  
on behalf of the community.


Steve

Full disclosure: I was on the committee that formulated the IAOC and I  
served on the IAOC for a period of time.



On Sep 13, 2010, at 1:16 PM, Marshall Eubanks wrote:



On Sep 13, 2010, at 12:39 PM, Adrian Farrel wrote:


Several interesting responses, thanks.

I agree that detailed rules would be onerous and unable to cope  
with the exceptional circumstances that the condition is intended  
to cover.


On the other hand BCP101 does seem to require some rules.

Dave said:

There are enough hassles for the IAOC tasks; let's wait to impose  
stricter rules until we see clear evidence they are needed.


OK, I think that provides a way forward. Let's put in place a  
mechanisms that allows the flexibility (i.e., not change to the  
"under exceptional circumstances" and "with agreement of the IAOC  
chair or the IAOC"), but remove the risk of surprise by inserting  
"with prior agreement",


I am not sure that the prior agreement is a good idea. What may  
trigger this is something like


IAOC member shows up for IAOC event at X, finds that the room  
reservation (or breakfast or projector or ...) has been canceled (or  
is for the wrong date or ...) and that this problem can be fixed if  
they put down a payment immediately. Most of the rest of the IAOC is  
in transit, and prior agreement in terms of a vote cannot possibly  
be obtained until it may be too late. The missing item in the normal  
course of events would be paid for out of the IASA budget.


If I were to be placed in that situation, I would go ahead, put the  
money down, and hope to be reimbursed, prior authorization or no.



and supply a way of determining whether stricter rules are needed  
by requiring "annual reporting of expenses paid".




I have no problem with that. As a suggestion, let's leave the text  
alone, and add


Any reimbursement of expenses to IAOC members for IAOC expenses will  
be reported in the minutes and in the annual reports by the IAOC  
Chair.


(Such reports are required, and have been given in plenary.)

Marshall


Marshall



Cheers,
Adrian
___
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


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

Re: IPv4 depletion makes CNN

[Steve Crocker]

IPv6 networks and products are maturing but are still not on a par with *IPv4* 
networks and services.

Apologies.

Steve 

Sent from my iPad

On May 27, 2010, at 3:14 PM, Rumbidzayi Gadhula  wrote:

> 
> 
> On 27 May 2010 16:11, Steve Crocker  wrote:
> I agree.  That said, it's a bit challenging to get the right message across.  
> IPv4 hosts will continue to increase for quite a while, but address space 
> will increasingly hard to obtain.  The large growth will come in the IPv6 
> space.  IPv6 networks and products are maturing but are still not yet on a 
> par with IPv6 networks and products.  Anyone want to hazard a guess when  
> they will be fully competitive?  And then there's the problem of 
> interoperability...
> 
> typo or am i lost?
>  
> I think the CNN story carries the wrong message, both in the specifics -- 
> IPv4 won't stop growing anytime soon -- and in the implied conclusion that 
> the Internet will stop growing in 18 months.
> 
> Steve
> 
> Sent from my iPad
> 
> On May 27, 2010, at 2:59 PM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
> 
> >> From: Ole Jacobsen 
> >
> >> this story was written by someone with a clue.
> >
> > Not really. A high marketing FUD / technical content ratio.
> >
> >   Noel
> > ___
> > 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
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv4 depletion makes CNN

[Steve Crocker]

I agree.  That said, it's a bit challenging to get the right message across.  
IPv4 hosts will continue to increase for quite a while, but address space will 
increasingly hard to obtain.  The large growth will come in the IPv6 space.  
IPv6 networks and products are maturing but are still not yet on a par with 
IPv6 networks and products.  Anyone want to hazard a guess when  they will be 
fully competitive?  And then there's the problem of interoperability...

I think the CNN story carries the wrong message, both in the specifics -- IPv4 
won't stop growing anytime soon -- and in the implied conclusion that the 
Internet will stop growing in 18 months.

Steve  

Sent from my iPad

On May 27, 2010, at 2:59 PM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:

>> From: Ole Jacobsen 
> 
>> this story was written by someone with a clue.
> 
> Not really. A high marketing FUD / technical content ratio.
> 
>   Noel
> ___
> 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: Circle of Fifths

[Steve Crocker]

Full disclosure: I serve on the ICANN board of directors, and I chair  
ICANN's Security and Stability Advisory Committee (SSAC).  Both of  
these are volunteer, i.e. unpaid, positions, but ICANN does pay my  
travel expenses for meetings.


It's mildly amusing to see how this thread has drifted from where it  
started.  Also annoying.  See inline for responses.


On Nov 5, 2009, at 12:53 PM, John Levine wrote:


As near as I can make out, ICANN collects bucketloads of cash without
really having any idea why. The only rationale seemed to be to pay a
rather surprising large salary to the CEO.


Agreed, except for the surprise part.  The whole staff is paid
impressively large amounts and has been as long as I've been watching
ICANN.  They seem to feel that their peer organizations for
compensation purposes are investment banks rather than other
non-profits.


I don't have access to the salaries of individual employees, and I  
doubt you do either.  In general, ICANN pays its staff competitively  
in order to attract and retain skilled people.  A very large number of  
people also participate in ICANN as volunteers, similar to the way the  
IETF, ISOC and other organizations work.



Instead they are currently looking to raise even more money through
the sale of TLDs but last time I heard were curiously uninterested in
providing any material support to the root operators who would be
bearing the expense of supporting these new domains.


If I were a root server operator, it would take an implausibly large
amount of money to be worth the strings that ICANN would attach.  A
key reason that the DNS still works is that there's no root server
contract, so the root operators can individually or jointly tell ICANN
to pound sand if they don't care for the root zone that ICANN offers
them. Hence ICANN is very cautions about changes.


This is multiple pieces of nonsense:

o ICANN is very cautious about changes to the root because that's the  
right thing to do.  A huge amount of work goes into vetting each and  
every requested change.  To suggest they are cautious only because of  
the root operators is both factually wrong and insulting.  It's really  
time to stop bashing the ICANN staff.  When they make a mistake,  
they'll admit it and fix it.  The competence level inside ICANN is  
surely as good as in the IETF and other organizations.


o The idea that the root operators would actually catch or stop errors  
in the root zone is more fantasy than reality.  The root operators are  
highly automated and don't generally look at the content of each  
update of the root zone.  At a recent meeting in the EU, a senior  
official at a major registry made the claim that the root operators  
were the last line of defense against malicious or capricious behavior  
by ICANN or the U.S. Government, and that DNSSEC would diminish the  
ability of the root operators to protect a registry from being removed  
from the root zone.  I took the opportunity ask if the root operators  
were, in fact, ready, willing and able to serve in such a capacity.   
If so, were there realistic plans and practice in place?  We're living  
in a post 9/11 world where organizations take such questions  
seriously.  They prepare plans and they practice dealing with  
contingencies.  I followed up with the root operators at a subsequent  
meeting.  No such plans exist, and the root operators do not seem  
inclined to organize themselves to act in such a capacity.  (I'm not  
taking a position pro or con as to whether they should have such a  
role.  I'm only saying there's no connection between the claim that  
they have this role and any realistic chance that they would actually  
do so today.)


o There's no basis at all for saying anything at all about what  
strings ICANN would attach to support for the root operators.  The  
root operators aren't asking for support, so the question simply  
hasn't come up.


Steve



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

Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF

[Steve Crocker]

Dave,

Are you suggesting the IETF is not mature enough to meet in China?   
After watching this thread for a while, I am beginning to be convinced.


Steve

On Oct 1, 2009, at 12:04 PM, Dave CROCKER wrote:


Hui,

Hui Deng wrote:
1) I personally have attended several standardization meetings such  
as

3GPP and 3GPP2 in China,


Many of us have attended meetings in China and we have found them  
productive and enjoyable.  However all of those other groups conduct  
their business in a way that is significantly different from the  
unruly style of the IETF.


3) IETF is doing technical stuff, I don't see why we need to be  
involved in political stuff.


This has been explained repeatedly.  First, there is legitimate  
technical work in the IETF that touches topics which are explicitly  
prohibited by the contract language.  Second, the style of IETF  
discussions often includes individual comments which are likely to  
violate the contract.  This unruly speech is a consequence of a core  
principle in the open style of IETF work.



4) China is one of the major member of United Nations, anyhow, come  
here and see


Hui, this really has little to do with "China".

Rather, the problem is with contract language that I believe we  
would never accept for any other venue.


   The only reason we have a debate about this because
   we are so /eager/ to have an IETF meeting in China!

Some folk say that we should ignore the language in the draft  
contract, because it will not be enforced, except under extreme  
circumstances.  First, it is never appropriate for people signing a  
contract to assume that it won't be enforced, especially when they  
cannot really know the exact conditions that will cause it to be  
enforced.  (The term "fiduciary responsibility" covers this.)  
Second, these assurances are coming from people who cannot speak for  
the hotel or the government.  Hence, they are merely guessing.


Let's be specific:


  "Should the contents of the Group's activities, visual or audio
  presentations at the conference,or printed materials used at the
  conference (which are within the control of the Client) contain


Note how extensive this is.  We are required to control material and  
speech by everyone, yet the IETF has never really controlled the  
material or speech of /anyone/.




  any defamation against the Government of the People's Republic


Defamation is really a rather vague word, especially among most of  
us do not know how it is actually used in China.  (Let's be fair.  I  
suspect most of us do not know how it is used as a legal term in the  
US, or any other country...)
So we need to be afraid of violating this, without really knowing  
what is permitted and what is prohibited.




  of China, or show any disrespect to the Chinese culture, or


Disrespect is an even more vague term and it is coupled with  
"culture" which could mean anything having to do with the country's  
government, history or population, and could even cover reference to  
Chinese people anywhere in the world.


Worse, comments made in the IETF are often disrespectful.  We wish  
they weren't, but again, this is a consequence of how the IETF  
conducts its business.  So the IETF really is being required to make  
guarantees that change its basic style of operation.




  violates any laws of the People's Republic of China or feature


Language that says that we won't violate the host country's laws is,  
of course, not necessary -- the laws are the laws and anyone  
violating them has a problem, no matter whether it is referenced in  
the contract -- but it probably doesn't hurt to include it.  Or  
rather, the only reason to include it is to set the stage for the  
financial consequences, specified later...




  any topics regarding human rights or religion without prior
  approval from the Government of the People's Republic of China,


As has been noted by several folks, the IETF does work that  
necessarily requires discussing topics that are relevant to human  
rights.  And again, we also have the problem of trying to restrict  
spontaneous comments that might violate these conditions; yet we  
have never done that.




  the Hotel reserves the right to terminate the event on the spot
  and/or ask the person(s) who initiates or participates in any or
  all of the above action to leave the hotel premises immediately.


This gives the Hotel complete freedom to shut the meeting down  
according to its own interpretation of conditions that are extremely  
vague.  That's not a reasonable contract condition for us to agree  
to.  (Here's where "fiduciary responsibility" becomes the real  
focus, when making an agreement.)




  The Client will support and assist the Hotel with the necessary
  actions to handle such situations. Should there be any financial
  loss incurred to the Hotel or damage caused to the Hotel's
  reputation as a result of any or all of the above acts, the Hotel
  will claim compe

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Steve Crocker]

I don't think the IETF, either as a whole, in any of its working  
groups, or as individuals, need feel inhibited about having the same  
sorts of discussions in Beijing that it would have anywhere else.


Run the experiment and get some data.  Survey attendees afterwards and  
find out what everyone felt.  (My prediction: There will be more  
discussion about the usual problems of not enough cookies, location of  
restaurants, connectivity, etc.)


Steve




On Sep 20, 2009, at 12:37 PM, Michael StJohns wrote:


Hi Steve -

To paraphrase, you believe we should accept constraints upon the  
topics that can be raised at the meeting (stick to the center) as  
the cost of doing business in China.  And the reason for that is to  
maintain the relevance of the IETF?


I'm finding this argument not well constructed.

I agree that engagement is good, but the IETF is about individuals  
and we engage better at a personal level than IETF to country.
That can be accomplished at any venue - and possibly better at a  
venue without excessive constraints on discussion.


I'd be happy to have a WG meeting in the PRC - on topics other than  
those common to the security area, but I remain concerned about  
prior restraint for the IETF as a whole as a price of holding a  
meeting there.



At 03:55 PM 9/19/2009, Steve Crocker wrote:

The choice is between engaging and not engaging.  Engaging is better.
Not engaging isn't constructive.  The Internet and the IETF are all
about engaging, expanding, communicating and being open.  Much of  
this

dialog has been worried about possible extreme situations.  Let's
focus on the center.  More than a billion people live in China and
their use of the Internet is expanding rapidly.  They are building
much of the technology and contributing technically.  It's to
everyone's advantage to have comfortable, constructive interaction.
Our first slogan was "Networks Bring People Together."

If you prefer to focus on the negatives, here's my analysis:

If we don't go to China, we have charted a downhill course and the
rest of the world will come together without us.  The IETF will lose
relevance.


This construction is black and white and somewhat irrelevant.  The  
IETF not meeting at this time in China is unlikely to make the rest  
of the world "come together without us".  Nor will us going to the  
meeting be the sole reason for the world coming together with us.



If we do go to China and something bad happens, the consequences will
be much worse for China than for the IETF.  The work of the IETF will
suffer a bit, but we'll recover quickly enough.  However, China's
quest for engagement with the rest of the world will be hurt more
seriously.


There's bad and there's BAD.  I'm mostly concerned not about the  
whole IETF being kicked out of the hotel/PRC, but in individuals  
being sequestered or removed for speech that in any other IETF venue  
would be relevant and on-topic for the technical discussion.  That  
(fear of) prior restraint has a strong possibility of adversely  
affecting the IETF by limiting discussion and constraining the free  
flow of ideas.  And that - free flow of ideas- not "engagement" - is  
the strength of the IETF.





Bottom line: We should go to China with a positive attitude.  We're
robust enough to deal with any consequences.  If we don't go to  
China,

however, we have weakened ourselves.


Bottom line - we should be the IETF and find venues that will accept  
us for ourselves.


___


Hmm.. I was going to stop there, but let's ask the meta question:   
What is the maximum set of constraints you think we should accept on  
the IETF as the price of holding a meeting?  For example, would it  
be acceptable to go somewhere where a class of IETF participant were  
treated as 2nd class citizens and possibly segregated?  Would it be  
acceptable to go somewhere where ALL presentations had to be vetted  
and approved by the local government?  Etc?


Its all about slippery slopes - if we accept constraints other than  
those we impose upon ourselves, we weaken ourselves.


Mike




Steve

___
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: Request for community guidance on issue concerning a future meeting of the IETF

[Steve Crocker]

The choice is between engaging and not engaging.  Engaging is better.   
Not engaging isn't constructive.  The Internet and the IETF are all  
about engaging, expanding, communicating and being open.  Much of this  
dialog has been worried about possible extreme situations.  Let's  
focus on the center.  More than a billion people live in China and  
their use of the Internet is expanding rapidly.  They are building  
much of the technology and contributing technically.  It's to  
everyone's advantage to have comfortable, constructive interaction.   
Our first slogan was "Networks Bring People Together."


If you prefer to focus on the negatives, here's my analysis:

If we don't go to China, we have charted a downhill course and the  
rest of the world will come together without us.  The IETF will lose  
relevance.


If we do go to China and something bad happens, the consequences will  
be much worse for China than for the IETF.  The work of the IETF will  
suffer a bit, but we'll recover quickly enough.  However, China's  
quest for engagement with the rest of the world will be hurt more  
seriously.


Bottom line: We should go to China with a positive attitude.  We're  
robust enough to deal with any consequences.  If we don't go to China,  
however, we have weakened ourselves.


Steve

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

Re: IPv6 standard?

[Steve Crocker]

gracefully long before the ability to maintain IPv4
became costly. Unfortunately that didn't happen, so now the world is  
looking

for IPv6-only to IPv4-only solutions to deal with the results of their
shortsightedness, and it will be the most costly confusing mess of a
deployment one could possibly imagine.

Either way, it is appropriate for the IETF to declare IPv4 to be  
historic,
and given how long it will take to decide what that means, we should  
start

now. I seriously doubt we could get consensus on that before 2015, but
waiting until then to start means it will be 2021 before we get past  
IPv4,
and the world will have long forgotten what the debate was about.  
IPv4 was a
fine experiment that escaped the lab, and now it is time to stand up  
and

tell the world that we need to move to a production version.

Tony



From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf  
Of

Steve Crocker
Sent: Thursday, September 17, 2009 6:30 AM
To: Olivier MJ Crepin-Leblond
Cc: IETF Discussion
Subject: Re: IPv6 standard?

There are hundreds of millions of IPv4 computers and perhaps  
millions of

individual IPv4 transport networks, large and small.

Here are some useful points along the way from pure IPv4 to pure IPv6.

A. Every new computer is able to talk IPv6

B. Every transport is able to talk IPv6, i.e. every network from  
tier 1 ISPs

down through wifi hot spots and every internal corporate network

C. Every major service, e.g. Google, CNN, Amazon, is reachable via  
IPv6


D. Every new computer is not able to talk IPv4

E. A substantial number of transports are unable to talk IPv4

F. A substantial number of major services are not directly  
accessible via

IPv4 (but, of course, will be accessible via gateways)

I haven't included supporting details like DNS and gateways between  
IPv4 and

IPv6.

We're basically at A.  Give some thought to the dates you'd assign  
to B
through F.  Feel free to disagree that these are significant steps  
along the
path, but if you do disagree, please propose other reasonable and  
measurable

mark points.

I didn't include the bitter end of this process, i.e. the complete
disappearances of IPv4.  If we get through steps A through F, the  
rest won't

matter much.

I have trouble believing this will all happen in less than 20  
years.  I do

not have trouble imagining it might take much longer.

I don't have any stake in the outcome.  It's fine with me if it  
happens
faster.  However, the mechanisms for interoperability between IPv4  
and IPv6
are still being worked out and the products to do the work, i.e.  
application
gateways, are not yet plentiful.  Moreover, even when the first  
products
appear, there's a long maturation cycle.  As one example, two years  
ago the

ICANN Security and Stability Advisory Committee (SSAC) looked at the
products in the security area -- firewalls, etc. -- to see whether the
feature sets for IPv6 were the same as for IPv4.  The good news was  
the
products did actually support IPv6.  The bad news was the feature  
sets were

noticeably poorer.

Our report, SAC 021, http://www.icann.org/committees/security/sac021.pdf 
 ,

concluded with:

IP version 6 (IPv6) transport is not broadly supported by commercial
firewalls. On average,
less than one in three products support IPv6 transport and security
features. Support among
the firewall market share leaders improves this figure somewhat.

Support for IPv6 transport and security services is available from
commercial firewalls for
all market segments, however, availability of advanced security  
features is

lagging in
SOHO and SMB segments and strongest in the LE/SP segment.

Overall, relatively little support for IPv6 transport and security  
features

exists. However,
some form of traffic inspection, event logging, and IP Security  
(IPsecv6)

are commonly
available among products that support IPv6 transport and security  
services.


Internet firewalls are the most widely employed infrastructure  
security

technology today.
With nearly two decades of deployment and evolution, firewalls are  
also the

most mature
security technology used in the Internet. They are, however, one of  
many

security
technologies commonly used by Internet-enabled and security-aware
organizations to
mitigate Internet attacks and threats. This survey cannot definitively
answer the question,
"Can an organization that uses IPv6 transport enforce a security  
policy at a

firewall that is
commensurate to a policy currently supported when IPv4 transport is  
used?"

The survey
results do suggest that an organization that adopts IPv6 today may  
not be

able duplicate
IPv4 security feature and policy support.

The observations and conclusions in this report are based on collected
survey results.
Future studies should consider additional and deeper analyses of  
security

technology
availability for IPv6. Such analyses are best performed by  
certific

Re: IPv6 standard?

[Steve Crocker]

27;s security policy.  As of two years ago, he  
couldn't buy products that would function at the same level.


IPv6 is definitely necessary and we should all do everything we can to  
move in that direction.  I'm just noting that even when IPv6 is widely  
available and in broad use, there will be a long tail before IPv4  
fades from the scene.


Steve






On Sep 17, 2009, at 2:36 AM, Olivier MJ Crepin-Leblond wrote:


"Steve Crocker"  wrote:

We're some distance away from deprecating IPv4.  Maybe 20 years,  
maybe  50 years.  For a very long time, IPv6 and IPv4 will co-exist.


I know you wrote those figures to be provocative, Steve. :-)
I mean, 50 years? That's like saying "computers will still run on  
valves in 50 years' time" in 1950.


Of course this is a matter of appreciation, and frankly, does it  
really matter how long IPv4 will be around?


Let's worry at the future, not the past.

Kindest regards,

Olivier

--
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html


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

Re: IPv6 standard?

[Steve Crocker]

We're some distance away from deprecating IPv4.  Maybe 20 years, maybe  
50 years.  For a very long time, IPv6 and IPv4 will co-exist.


Steve


On Sep 16, 2009, at 11:43 AM, Eliot Lear wrote:


Historic is appropriate when we want to make a statement about the
appropriateness of the technology.  However, we probably enter a huge
bureaucratic entanglement of what happens to all of the docs that
normatively reference 791, 792, and 793.  And that's another question,
what precisely DO we make Historic?

Eliot

On 9/16/09 5:36 PM, IETF Member Dave Aronson wrote:

David Harrington  wrote:


As part of declaring IPv6 a full standard, would we also declare  
IPv4

obsolete or Historic?


Given IPv6's rate of adoption so far, how soon do you think IPv4 will
*really* be in so little use as to be obsolete or historic?  With the
growth rate of the Internet and home/office networking, and IPv6's
adoption rate, I'd be willing to bet that the number of IPv4
installations is *growing* per year, not shrinking, and that that
trend will continue for at least the next several years, barring any
highly unusual events.

-Dave




___
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: Important Information about IETF 76 Meeting Registration

[Steve Crocker]

I won't be in Hiroshima and won't be able to participate nor will I be  
able to opt-out, so I don't have a personal stake in this and am  
commenting only as an interested observer.


As has been noted, this won't be an absolutely clean, seamless  
replacement of the blue sheets.  The list of possible downsides is  
already growing, e.g. privacy issues, inflexibility in choosing which  
email address to use for each working group, and I won't be surprised  
if the list grows a bit.  At the same time, the list of possible new  
capabilities is also growing, e.g. identifying the speaking at the  
microphone.


This sort of discussion is similar to other settings that are  
introducing electronic versions of previously manual processes, e.g.  
in the health care industry.  Let me offer a point of view and a  
suggestion.


Point of view: Rather than thinking of the RFID chips as serving to be  
simply a direct replacement of the blue sheets, take as a given that  
this will be a new and somewhat different technical foundation with  
some positives and some negatives.  The blue sheets also had positives  
and negatives, e.g. the cost and pain of storing them, the difficulty  
and cost of reading them, their legal status and retention policy,  
etc.  Look at the RFID chips from a fresh perspective, not solely as  
an automation of the blue sheets.


Suggestion: As noted above, similar issues apply in other settings.   
This community has an opportunity to tackle the interplay of  
technology and social policy issues that affect itself far more  
cogently and efficiently than most communities do.  Let's grasp the  
nettles and see if we can work through the issues in a sensible and  
rational way.  Do we need a privacy policy regarding the information  
collected?  If so, let's create one.  Do we need access controls on  
the information?  If so, let's create them.  Do we need an ability to  
edit information that's been collected if it's inaccurate?  If so,  
let's build it.  Do we need more flexibility in the information stored  
in the record, e.g. a distinct email address for each working group?   
If so, let's add it.


Steve







On Aug 31, 2009, at 12:27 PM, Paul Hoffman wrote:


At 5:55 AM -0700 8/31/09, Alexa Morris wrote:
The data collected consist solely of an individuals full name and  
company/organization affiliation. We are not collecting email  
address information on the e-blue sheets.


Please note that you are now also collecting information that *is  
not* on the current blue sheets, namely "company/organization  
affiliation". I have noted that some people I know who have signed a  
blue sheet before me have used personal email addresses while (I  
assume) their badge lists their actual "company/organization  
affiliation". As a person with multiple company/organization  
affiliations, I sometimes change the email address I put on the blue  
sheets to be the one most appropriate to the topic of the WG.


It is a bad idea to have this experiment create combined blue sheets  
that have data that differs depending on the collection method.  
There are probably a dozen WGs in the IETF who have had this problem  
come back and bite them on their collective backsides during  
protocol development or, unfortunately, after their protocols have  
deployed.


Please strongly consider having the readers record exactly what the  
current blue sheets record, or change the blue sheets to record what  
the readers are recording for this meeting. The first of these two  
will most likely cause less revolt.


--Paul Hoffman, Director
--VPN Consortium
___
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: Steve Coya

[Steve Crocker]

This is indeed sad news.  Steve was energetic and dedicated, and we  
all benefitted greatly from his contributions.


Steve

On Jun 6, 2009, at 2:32 PM, Fred Baker wrote:

Steve Coya, the IETF's Executive Director at CNRI during much of the  
1990's and early 2000's, has passed away. His wife, Mary Beth,  
wanted folks to know, as the IETF was a big part of his life.


http://www.legacy.com/washingtonpost/DeathNotices.asp?Page=Lifestory&PersonId=128055919
___
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: Status of the 16-bit AS Number space

[Steve Crocker]

I strongly advise against quick reallocation of returned AS numbers.   
Returned AS numbers should stay out of service for a substantial  
period of time.


The same should be true for other deactivated quantities such as  
addresses, but that's a larger discussion.


Steve


On Apr 23, 2009, at 11:41 AM, john heasley wrote:


Thu, Apr 23, 2009 at 11:13:12AM -0400, Russ Housley:
I thought that the whole community would like to be aware of this  
status.


Russ


My understanding is that the registries have not been reassigning ASNs
that are returns but were not allocated from IANA as part of a block.
AS1 for example, would not be reallocated if it were returned.  So, in
theory there are far more available than this lets on.




From: Michelle Cotton 
To: "i...@ietf.org" 
Date: Wed, 22 Apr 2009 20:52:18 -0700
Subject: Status of the 16-bit AS Number space

Dear IESG,

This is to let you know what we now have fewer than 10 blocks of
16-bit AS Numbers left in the IANA free pool.

Yesterday we allocated two blocks of 1,024 AS Numbers to ARIN, as  
per

the Global Policy for Allocation of ASN Blocks to Regional Internet
Registries, which was ratified by the ICANN board in July last year.

http://www.icann.org/en/general/global-policy-asn-blocks-31jul08-en.htm


The unallocated 16-bit AS Number space is now 54272-64511. The full
registry can be viewed at:

http://www.iana.org/assignments/as-numbers/as-numbers.xml

We agreed to notify the IESG when we got to this point in the AS
Numbers registry.  Please let me know if you have any questions or
comments.

Kind regards,

Michelle Cotton
IANA


___
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


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

Re: My resignation

[Steve Crocker]

LB,

I have been following much of this dialog and I am familiar with the  
general set of issues involved here.  I have also been around for a  
long time, and I do not work for Google nor do I depend on them for  
income.  I now serve on the Board of ICANN and I served on the Board  
of ISOC from 2003 to 2006.  I was heavily involved in creating the  
present financial support structure for the IETF, i.e. the creation of  
the IASA, its oversight board IAOC, and the funding arrangements now  
in place to support the IETF.


Your third paragraph, "I understand that the IETF've become a  
subsidiary of ISOC ... this is too much control in one place" is  
simply wrong.  The IETF is extremely sensitive about its independence  
and avoidance of capture by large interests.  All of the parties you  
named fully understand the need for independence and work carefully to  
preserve it.  Moreover, Vint Cerf, though he works for Google, is  
above reproach and contributes enormous amounts of his time to public  
service that are not controlled by or aligned with Google's interests.


The IETF is founded on the principle that participation is by  
individuals, not organizations.  No organization, no matter whether it  
is large or small, controls the IETF processes.


Restricting of posting privileges to a working group is done  
reluctantly, rarely, and only after very substantial effort has been  
expended to find useful ways to interact.  It is unfortunate such  
action was required in this case.  I know Vint and everyone wishes it  
had not been necessary.  However, after lengthy interaction and many  
attempts to keep the discussion focused on the topic, it was necessary.


Steve Crocker




On Apr 18, 2009, at 5:46 PM, LB wrote:


Dear IETF Members,
Sorry, I do not speak but I read Engslih. I use Google translation.

google translation:
JFC Morfin asked me to interface our working groups, france @ large,  
with the IETF. I was badly received by some. Then I had the chance  
to talk with serious people, respectful of my ignorance, mindful of  
my user inputs. I participated in the WG-IDNABIS and I could share  
here, with dedicated people, wishing to work for the common good.  
They were also subject to the problem of financing by sponsors  
described by the IAB in RFC 3869.


Today, two brilliant and dedicated contributors to the WG-IDNABIS  
have been banned, in a quarter of an hour. By decision and execution  
of members of Google.


I understand that the IETF've become a subsidiary of ISOC and the  
consortium of its biggest members. I understand that Google pays its  
expenses. I understand the enormous interests involved to control  
the global namespace (rather than just domain names, but the words  
of semantic processing). However, one root for the IPs, one root for  
the DNS, one root for languages, and now a root for the spelling of  
words, this is too much control in one place.


I'm too old for that. I quit after copying the mail of one of the  
deportees that you did not receive. It is important because it is  
very firm, but it also calls for reconciliation in a practical  
manner. I hope that the other expelled, will do the same.	


French text:
JFC Morfin m'avait demandé d'interfacer nos groupes de travail,  
fra...@large, avec l'IETF. J'ai d'abord été méchament accueilli par  
certains. Puis j'ai eu la chance de discuter avec des gens sérieux,  
respectueux de mes ignorances, soucieux de mes apports  
d'utilisateur. J'ai participé au WG-IDNABIS et j'ai pu échanger là,  
avec des gens dévoués, désirant travailler pour le bien commun. Ils  
étaient aussi soumis au problème du financement par les sponsors  
décrit par l'IAB dans la RFC 3869.


Aujourd'hui, deux membres brilants et dédiés contributeurs du WG- 
IDNABIS ont été bannis, en un quart d'heure. Par décision et  
exécution de Membres de Google.


Je comprends que l'IETF ai du devenir une filliale de l'ISOC et le  
consortium de ses plus gros membres. Je comprends que Google paie  
ses dépenses. Je comprends les énormes intérêts en jeu pour  
contrôler le nommage mondial (non plus seulement les noms de  
domaine, mais les mots des processeurs sémantiques). Cependant, une  
racine pour les IPs, une racine pour le DNS, une racine pour les  
langues, et maintenant une racine pour l'orthographe des termes,  
cela fait trop de contrôle dans un seul endroit.


Je suis trop vieux pour cela. Je démissionne après avoir copié le  
mail d'un des expulsés que vous n'avez pu recevoir. Il est important  
car il est trés ferme, mais il appelle aussi à la réconciliation de  
façon pratique. J'espère que l'autre expulsé, fera de même.


JFC je reste dans le groupe de travail et au comptoir. Enlève moi  
partout ailleurs. Explique mon départ. Je suis écoeuré pour  
l'instant. Je sais que tu comprendras. De tout coeur a

Re: [Fwd: How the Internet Got Its Rules ]

[Steve Crocker]

Brian,

Thanks.  Re did anyone comment on RFC 1, I don't recall but it should  
be easy to comb through the first several RFCs to see.


Steve

Sent from my iPhone

On Apr 7, 2009, at 5:28 PM, Brian E Carpenter > wrote:



Steve,

Thanks for writing such a nice piece. I especially liked
"As we rebuild our economy, I do hope we keep in mind the  value
of openness, especially in industries that have rarely had it."

Did you ever actually get any comments on RFC1?

  Brian

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

Re: Proposed DNSSEC Plenary Experiment for IETF 74

[Steve Crocker]

[As entertainment for the audience, I am sure everyone will enjoy  
seeing my brother and I take opposite sides in this discussion.   
Enjoy ;) ]


I too have been watching this thread but from the vantage of having  
been deeply involved in DNSSEC deployment and, more specifically, as  
one of the people urging deploying DNSSEC at the IETF meetings.  This  
thread began with Russ Housley sending a brief message yesterday:


I have been approached about a plenary experiment regarding  
DNSSEC.  The idea is for everyone to try using DNSSEC-enabled  
clients during the plenary session.  I like the idea.  What do  
others think?



There was actually considerably more context behind this note, and  
it's perhaps unfortunate the thread has lurched off in a negative  
direction.


I can't speak for the IAOC or others involved in the mechanics, so  
the following is my best understanding -- and also what I recommend  
-- of what's intended.


There are three distinct elements of what's being planned.

1. Signing of the ietf.org zone

2. Providing a DNSSEC-compliant recursive resolver as part of the  
IETF net at the next IETF meeting.


3. An experiment during the plenary.

Russ's note initiated discussion of this last piece without setting  
the context with the first two pieces.  Let me say a few words about  
each piece.


1. Signing ietf.org

Quite a few zones are already signed, and some top level domains,  
Sweden (.SE), Bulgaria (.BG), Peurto Rico (.PR), Brazil (.BR), The  
Czech Republic (.CZ), and .MUSEUM, are in full DNSSEC operation.   
Many of us are running signed zones below the top level, and there is  
already a decision and commitment for the key zones related to the  
IETF to be signed.


Based on the discussions I heard during the last IETF, the plan is to  
sign ietf.org immediately after the parent zone, .ORG, is signed.  I  
would prefer for the signing of ietf.org to be independent of whether  
the parent zone is signed, but that's a separate discussion.  In any  
case, it's my understanding that the people in charge of running  
ietf.org have been tasked with getting it signed.  Once signed, I  
would expect it will stay in operation.  That is, the timing and  
operation of the signed zone don't depend on the IETF meeting and  
have no direct relationship to the meeting's network.



2. Providing a DNSSEC-compliant recursive resolver as part of the  
IETF net at the next IETF meeting.


The other side of the DNSSEC equation is having software that checks  
the signatures.  This is done by a validating resolver, either a  
recursive resolver or the stub resolver.  A handful of organizations,  
notably Telia in Sweden, Comcast, University of California Berkeley,  
and OARC are running DNSSEC-compliant recursive resolvers.  I believe  
the ISPs, Telia and Comcast, are providing these resolvers as  
optional alternatives to the resolvers they regularly run and they  
are not including the addresses of these resolvers in the DHCP  
configuration parameters.  Presumably they will become part of the  
standard DHCP configuration at some future time.


The proposed action for the next IETF meeting is to do the same  
thing.  That is, the IETF network will include a DNSSEC-compliant  
recursive resolver as an additional service which is not included in  
the list of DNS servers returned during the DHCP process.



All of the above should invisible unless the end system explicitly  
invokes the DNSSEC-compliant recursive resolver AND asks for a signed  
response.



3. An experiment during the plenary

I have not been involved in a discussion of this third piece, but I  
presume the intent is to simply include the DNSSEC-compliant  
recursive resolver in the standard DHCP configuration during the  
plenary.  That is, during the plenary, DHCP responses will include  
the DNSSEC-compliant recursive resolver.  Even though the normal DNS  
requests will thus go through the DNSSEC-compliant recursive  
resolver, the end system will see no difference unless the end system  
asks for a a signed response.  I believe Russ was essentially asking  
what people think about this third piece of the plan.  (Apologies,  
Russ, if I have incorrectly channeled you.)


In line with David's note, there are indeed a lot of details to  
cover, including explanatory notes on how end systems need to be  
configured to ask for signed responses. measurements, etc., etc.  All  
normal stuff and all part of what we are more than capable of doing  
all the time.



Steve


On Nov 27, 2008, at 1:03 PM, Dave CROCKER wrote:




Peter Koch wrote:

On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote:
I agree with others' views that validation alone is not very  
helpful and
some frequently queried for domains' zones should be signed as  
part of that
experiment.  By IETF74, the IANA (I)TAR might also be available as  
one

source of TLD trust anchors.
Still that date might be too early to encourage end system  
validation,

Re: Proposed DNSSEC Plenary Experiment for IETF 74

[Steve Crocker]

[As entertainment for the audience, I am sure everyone will enjoy  
seeing my brother and I take opposite sides in this discussion.   
Enjoy ;) ]


I too have been watching this thread but from the vantage of having  
been deeply involved in DNSSEC deployment and, more specifically, as  
one of the people urging deploying DNSSEC at the IETF meetings.  This  
thread began with Russ Housley sending a brief message yesterday:


I have been approached about a plenary experiment regarding  
DNSSEC.  The idea is for everyone to try using DNSSEC-enabled  
clients during the plenary session.  I like the idea.  What do  
others think?



There was actually considerably more context behind this note, and  
it's perhaps unfortunate the thread has lurched off in a negative  
direction.


I can't speak for the IAOC or others involved in the mechanics, so  
the following is my best understanding -- and also what I recommend  
-- of what's intended.


There are three distinct elements of what's being planned.

1. Signing of the ietf.org zone

2. Providing a DNSSEC-compliant recursive resolver as part of the  
IETF net at the next IETF meeting.


3. An experiment during the plenary.

Russ's note initiated discussion of this last piece without setting  
the context with the first two pieces.  Let me say a few words about  
each piece.


1. Signing ietf.org

Quite a few zones are already signed, and some top level domains,  
Sweden (.SE), Bulgaria (.BG), Peurto Rico (.PR), Brazil (.BR), The  
Czech Republic (.CZ), and .MUSEUM, are in full DNSSEC operation.   
Many of us are running signed zones below the top level, and there is  
already a decision and commitment for the key zones related to the  
IETF to be signed.


Based on the discussions I heard during the last IETF, the plan is to  
sign ietf.org immediately after the parent zone, .ORG, is signed.  I  
would prefer for the signing of ietf.org to be independent of whether  
the parent zone is signed, but that's a separate discussion.  In any  
case, it's my understanding that the people in charge of running  
ietf.org have been tasked with getting it signed.  Once signed, I  
would expect it will stay in operation.  That is, the timing and  
operation of the signed zone don't depend on the IETF meeting and  
have no direct relationship to the meeting's network.



2. Providing a DNSSEC-compliant recursive resolver as part of the  
IETF net at the next IETF meeting.


The other side of the DNSSEC equation is having software that checks  
the signatures.  This is done by a validating resolver, either a  
recursive resolver or the stub resolver.  A handful of organizations,  
notably Telia in Sweden, Comcast, University of California Berkeley,  
and OARC are running DNSSEC-compliant recursive resolvers.  I believe  
the ISPs, Telia and Comcast, are providing these resolvers as  
optional alternatives to the resolvers they regularly run and they  
are not including the addresses of these resolvers in the DHCP  
configuration parameters.  Presumably they will become part of the  
standard DHCP configuration at some future time.


The proposed action for the next IETF meeting is to do the same  
thing.  That is, the IETF network will include a DNSSEC-compliant  
recursive resolver as an additional service which is not included in  
the list of DNS servers returned during the DHCP process.



All of the above should invisible unless the end system explicitly  
invokes the DNSSEC-compliant recursive resolver AND asks for a signed  
response.



3. An experiment during the plenary

I have not been involved in a discussion of this third piece, but I  
presume the intent is to simply include the DNSSEC-compliant  
recursive resolver in the standard DHCP configuration during the  
plenary.  That is, during the plenary, DHCP responses will include  
the DNSSEC-compliant recursive resolver.  Even though the normal DNS  
requests will thus go through the DNSSEC-compliant recursive  
resolver, the end system will see no difference unless the end system  
asks for a a signed response.  I believe Russ was essentially asking  
what people think about this third piece of the plan.  (Apologies,  
Russ, if I have incorrectly channeled you.)


In line with David's note, there are indeed a lot of details to  
cover, including explanatory notes on how end systems need to be  
configured to ask for signed responses. measurements, etc., etc.  All  
normal stuff and all part of what we are more than capable of doing  
all the time.



Steve


On Nov 27, 2008, at 1:03 PM, Dave CROCKER wrote:




Peter Koch wrote:

On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote:
I agree with others' views that validation alone is not very  
helpful and
some frequently queried for domains' zones should be signed as  
part of that
experiment.  By IETF74, the IANA (I)TAR might also be available as  
one

source of TLD trust anchors.
Still that date might be too early to encourage end system  
validation,

Re: Update of RFC 2606 based on the recent ICANN changes ?

[Steve Crocker]

While I appreciate the kind words and deference to SSAC, and while we  
would undoubtedly concur with recommendations to reserve names  
like .local, ICANN actually listens to the IETF more directly.   
Moreover, there is a specific slot on the Board of ICANN for a  
Liaison from the IETF.  Thomas Narten does a great job in that role,  
as John Klensin did before him.


Steve


On Jul 2, 2008, at 12:53 PM, John Levine wrote:

In article <[EMAIL PROTECTED]> you  
write:

Paul,

But it is still the case that an application for say .local would  
need

to go through some review process (regardless of price) which would
include input from the IETF ICANN rep.


More likely from the SSAC, which would be even better.

In any event, as I said before, although there's a lot not to like
about ICANN, the chances of them doing anything technically
destructive remains low.

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet  
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex- 
Mayor

"More Wiener schnitzel, please", said Tom, revealingly.
___
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: Update of RFC 2606 based on the recent ICANN changes?

[Steve Crocker]

Thanks!

Steve

On Jul 1, 2008, at 6:36 PM, John Levine wrote:


This does not mean that ICANN won't listen to the IETF; it means
that there will be voices more familiar to ICANN saying things
different than we are.


One of the few ICANN committees that actually works is the SSAC, the
Security and Stability Advisory Committee.  It includes a lot of
people we know, starting with Steve Crocker, the chair.  I cannot ever
recall a time when ICANN acted contrary to the advice of the SSAC.

So although I agree that there's a lot not to like about ICANN, the
chances that they will do technically dangerous things are low.

http://www.icann.org/committees/security/

R's,
John
___
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: ISSN for RFC Series under Consideration

[Steve Crocker]

Every so often someone suggests RFCs are not first class documents  
and hence not comparable to, say, "real" standards documents.   
Getting traditional identifiers attached to them might squelch some  
of this nonsense.

Steve

On May 22, 2008, at 9:12 AM, Melinda Shore wrote:

> On 5/22/08 8:51 AM, "John C Klensin" <[EMAIL PROTECTED]> wrote:
>> Indeed, another way of looking at this question is that deciding
>> to register an ISSN for the RFC series really does not preclude
>> anything else (including, were we so inclined, putting DOIs on
>> each RFC) and we should therefore be asking "ISSN or not ISSN"
>> with all questions about other sorts of identifiers and
>> cataloging being viewed as separate.
>
> I think the cataloging question is probably central to the
> question of whether or not to bother with an ISSN.  I don't
> think an ISSN has any practical value other than that it
> increases the likelihood that LC will catalog the series/
> serial and that libraries will then start sticking it into
> their electronic holdings.  Now, I'm not sure I see an
> advantage to getting libraries to pick up RFCs given how
> trivial it is to find them online, but that's another matter.
> Another advantage is discrimination in the event that some other
> serial publication is also called "Request for Comments," but
> again I'm not sure that's an actual problem.  But mainly,
> getting an ISSN gets the series into the library system.
>
> Melinda
>
> ___
> 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: ISSN for RFC Series under Consideration

[Steve Crocker]

Naw.  The ISSN has to be on the document itself.  As you point out,  
this isn't something to be done with Internet Drafts, so it falls  
naturally to the RFC Editor, not to the individual authors.

Steve


On May 22, 2008, at 3:14 AM, Paul Hoffman wrote:

> Mostly sounds fine, with one small glitch.
>
> At 1:52 PM -0400 5/21/08, Ray Pelletier wrote:
>> According to the Library of Congress, www.loc.gov/issn/, for serials
>> available only in online versions, the ISSN should appear on the  
>> title
>> screen or home page and/or in the masthead or other areas where
>> information about publisher, frequency, subscribing, copyright,  
>> etc. is
>> given.
>
> The value of adding "ISSN: 12345678" to each RFC seems small,
> particularly relative to the cost of everyone having to update their
> tools and so on. Also, we would have to tell people *not* to put the
> ISSN designation in their Internet Drafts (which are not part of the
> RFC series), but then switch it on for the RFC, and so on.
>
> The cost of putting "ISSN: 12345678" on a few pages at rfc-editor.org
> and ietf.org is tiny and hopefully sufficient for the statement above.
>
> --Paul Hoffman
> ___
> 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: Diagrams (Was RFCs should be distributed in XML)

[Steve Crocker]

Well, even if you choose your formalism first and then use that to  
guide the development and specification of the protocols, the  
challenge still stands.  The operative word in your description is  
"portions."  Does the technique cover enough of the protocol to be  
useful and does it wind up adding or saving time, work, errors, etc?


Steve


Steve Crocker
[EMAIL PROTECTED]


On Nov 17, 2005, at 11:56 AM, Hallam-Baker, Phillip wrote:


There is a way, develop a highly targetted formalism for the specific
problem.

This is hard to apply to existing specs because they tend to be
inconsistent. If you are required to apply a formalism you have to be
much more consistent in your design approach.

I did this for the finite state portions of FTP, NNTP and SMTP in 1993
when I was working on HTTP. With HTTP at the time there was not a  
lot of

state.


-Original Message-----
From: Steve Crocker [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 11:28 AM
To: Hallam-Baker, Phillip
Cc: Steve Crocker; Masataka Ohta; Yaakov Stein;
ietf@ietf.org; Stewart Bryant
Subject: Re: Diagrams (Was RFCs should be distributed in XML)

Phillip,

I spent a large fraction of my professional life in pursuit
of this alluring and seemingly simple goal.  Here's a small
challenge: Take
*any* IETF protocol and write down the formal specification.
Never mind the proof of correctness; that can come later.
(And with it an extended discussion of the underlying logical
system, the formal system for representing the protocol
specification, and the proof system you have in mind for
carrying out the proof.)  Of course, the formal specification
will have to be readable and understandable to the general
population, and there will have to ready agreement that
it does embody the desired properties.  Pick something simple.
Perhaps IP?  Feel free to leave out messy details like
performance issues if you wish.  Just something simple and
instructive to make your point.  And in light of the other
issues being discussed, don't feel constrained to use ASCII.
Use any notation and tools you like.

Steve



Steve Crocker
[EMAIL PROTECTED]


On Nov 17, 2005, at 10:09 AM, Hallam-Baker, Phillip wrote:


If we want to enforce simpler, more accurate design the

best way to do

this would be to require a formal proof of correctness before
accepting a specification.

Requiring people to use 1960s technology is not a way to achieve
simplicity.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

On Behalf

Of Masataka Ohta
Sent: Thursday, November 17, 2005 8:30 AM
To: Yaakov Stein
Cc: ietf@ietf.org; Stewart Bryant
Subject: Re: Diagrams (Was RFCs should be distributed in XML)

Yaakov Stein wrote:


It's good that protocols needing more than 72 ASCII

characters are

forbidden.



Just imagine what elegantly simple protocols we would have if we
required the descriptions to be in Morse code.


Good idea.

It's a better approach to enforce much simpler protocols.

Masataka Ohta


___
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: Diagrams (Was RFCs should be distributed in XML)

[Steve Crocker]

Phillip,

I spent a large fraction of my professional life in pursuit of this  
alluring and seemingly simple goal.  Here's a small challenge: Take  
*any* IETF protocol and write down the formal specification.  Never  
mind the proof of correctness; that can come later.  (And with it an  
extended discussion of the underlying logical system, the formal  
system for representing the protocol specification, and the proof  
system you have in mind for carrying out the proof.)  Of course, the  
formal specification will have to be readable and understandable to  
the general population, and there will have to ready agreement that  
it does embody the desired properties.  Pick something simple.   
Perhaps IP?  Feel free to leave out messy details like performance  
issues if you wish.  Just something simple and instructive to make  
your point.  And in light of the other issues being discussed, don't  
feel constrained to use ASCII.  Use any notation and tools you like.


Steve



Steve Crocker
[EMAIL PROTECTED]


On Nov 17, 2005, at 10:09 AM, Hallam-Baker, Phillip wrote:


If we want to enforce simpler, more accurate design the best way to do
this would be to require a formal proof of correctness before  
accepting

a specification.

Requiring people to use 1960s technology is not a way to achieve
simplicity.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Masataka Ohta
Sent: Thursday, November 17, 2005 8:30 AM
To: Yaakov Stein
Cc: ietf@ietf.org; Stewart Bryant
Subject: Re: Diagrams (Was RFCs should be distributed in XML)

Yaakov Stein wrote:


It's good that protocols needing more than 72 ASCII characters are
forbidden.



Just imagine what elegantly simple protocols we would have if we
required the descriptions to be in Morse code.


Good idea.

It's a better approach to enforce much simpler protocols.

Masataka Ohta


___
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

Diagrams (Was RFCs should be distributed in XML)

[Steve Crocker]

On Nov 14, 2005, at 8:56 AM, Stewart Bryant wrote:




BTW - one carrot that would tempt me away would be if the
result allowed the normative text to incorprate proper
diagrams - like ITU and IEEE - two name but two - have
use in their specifications for the last 20 or so years.



The issue of diagrams is entangled in the long-standing discussion of  
proprietary formats.  There is a huge benefit in having a format that  
*everyone* can access without difficulty or cost.  I can't begin to  
tell you the impact I felt when I walked into a university half way  
around the world in an underdeveloped country and had a graduate  
student show me some pretty sophisticated stuff he had done based on  
RFCs he had downloaded from the net.  ASCII is an enormous advantage  
from that respect.


At the same time, we have clearly hobbled ourselves in not moving  
forward with more advanced technology.  In a way, we have made  
ourselves a parody of our own success, staying locked into 1960s  
technology while we have created the technology for the twenty-first  
century.  The ITU and IEEE have progressed to PDF and other formats,  
partly because they still view paper as the primary medium.


I don't know whether this issue was covered in the TechSpec BoF  
(http://www3.ietf.org/proceedings/05nov/agenda/techspec.txt) but it  
definitely needs attention.  Perhaps this should be a separate thread  
in the discussions about publications.


Steve




Steve Crocker
[EMAIL PROTECTED]



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

Re: p2p dns (was: Re: UN plans to take over our job!)

[Steve Crocker]

I believe the system described in the cited paper does exactly the  
reverse of what's being discussed here.  CHORD and its relatives  
provide an alternative way of serving the data, but the hierarchical  
structure of domain names remains the same.  If I understand the  
intent of this thread, the desire is to create a P2P naming system,  
similar to a web of trust, that does not require a hierarchical  
naming system and the administrative machinery needed to maintain  
that naming system.  That is, I thought the thrust of this thread is  
how to create an alternative to the IANA, not how to how to create an  
alternative to the root servers.


Steve

Steve Crocker
[EMAIL PROTECTED]


On Sep 30, 2005, at 9:21 AM, Elwyn Davies wrote:

Johan: I imagine you have seen this paper on the subject of a p2p  
DNS substitute based on CHORD, but it is interesting reading for  
others.

http://www.cs.rice.edu/Conferences/IPTPS02/178.pdf

Regards,
Elwyn Davies

Johan Henriksson wrote:






On Fri, Sep 30, 2005 at 08:45:29AM +0200,
Johan Henriksson <[EMAIL PROTECTED]> wrote
a message of 25 lines which said:




a peer 2 peer replacement for DNS tops my internet wish list;


Is it a formal call to a new WG? Please provide a candidate  
charter :-)




I'd subscribe immediately :-)

is there an interest? I don't have much experience of IETF, much  
less in

taking care of a wg. but if more people would want to work on such a
thing, I could look into how to start up such an endeavor.

(although I doubt it would grow into a "substitute" in the end;  
rather a

complement)

- Johan Henriksson




___
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

Hawthorne Effect

[Steve Crocker]

 On Jun 23, 2005, at 12:45 PM, Ned Freed wrote: For anyone who was sleeping during the relevant Psych 101 lecture, this iscalled the Hawthorne effect. Damn. I knew there was a famous study that identified this effect, but Icouldn't remember the name.  Doing anything at all gets folk's attention.The name "Hawthorne Effect" comes from some early work (1927-1932) on organizational measurement done at the Western Electric plant in Hawthorne, Illinois, where management tried to determine optimum levels of factory-floor lighting. Because the employees knew about the study, they responded to each adjustment in light level by increasing productivity.Steve___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: WG management

[Steve Crocker]

One possible tool to consider is a "slip chart" which plots the  
estimated date of delivery against the date the estimate is made.  If  
successive estimates of when a milestone is going to be reached are  
all the same, then the project is on track.  If successive estimates  
keep sliding into the future, this shows up vividly.


I have to admit that whenever I've tried to impose this discipline on  
groups I've managed, what happens in practice is the people being  
measured try to change the game and argue the new estimates apply to  
completely different milestones than the original ones...


Steve




Steve Crocker
[EMAIL PROTECTED]


On Jun 16, 2005, at 11:33 AM, Brian E Carpenter wrote:


Theodore Ts'o wrote:


On Thu, Jun 16, 2005 at 03:43:25PM +0200, Brian E Carpenter wrote:

(1) It is hard to "fire" WG chairs - they are often friends and   
colleagues. Unfortunately, many stay on when their job   
responsibilities have changed and they can no longer dedicate  
the  necessary time.


Solution: Institute WG chair term limits of (say) one or two  
years.  That way, there is an expectation of change and the  
possibility for  more people to prove themselves. With two  
chairs, staggering terms  ensures continuity.




I hope you don't mean a term limit. Making chair appointments  
annually

renewable might work - but limiting the pool of talent by imposing
term limits would be self-inflicted damage, IMHO.


How about limiting the term of working groups, instead?  If a working
group stretches beyond about 2 years, there is a lot of value in
limiting its scope, shunting new work/extensions into a new working
group or groups, and trying to shut it down in the next 12-18 months.



Very much a case of YMMV, I think. But if a WG's milestones have to  
keep

being extended for no good reason, that should be a red flag.

   Brian



___
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: 'Process for the IAB and IESG selection of IAOC members' to BCP

[Steve Crocker]

Comments in line below...

On Jun 14, 2005, at 5:31 AM, Geoff Huston wrote:





It seems to me that what would be required to do so would be three
statements:

   ISOC's appointees do not represent ISOC, in the same way that IAB
   and IESG appointees do not represent the IAB or IESG. They serve
   the entire community.

   Nomcom appointees do not represent a subclass of all IETF
   participants, in the same way that IAB and IESG appointees do not
   represent the IAB or IESG. They serve the entire community.

   Since the IAOC manages the relationship between ISOC and the IETF,
   direct understanding of both IETF and ISOC is of value in all
   appointees.

Is there any reason the document shouldn't say that?



As one of the editors of this document I would note the following  
in response to your suggestions, by way of explanation as to why  
these statements are not in this draft:


- This document is a document that is limited to the definition of  
a procedure for the IAB and IESG to follow. It deliberately does  
not extend further than that quite limited brief, and did not  
intend to describe the accountabilities of the individuals that are  
selected through the application of this process.


Yes, this document, as written, is specifically limited to the  
definition of a procedure for the IAB and IESG to follow.  The  
question is whether to expand its scope and cover the ISOC and Nomcom  
appointments as well.  Are the criteria for selection the same or  
different?  In the spirit of establishing a cooperative framework,  
the suggestion on the table is to harmonize the criteria and create  
one document.


This is only of medium importance.  If the answer is no, the IAB and  
IESG want one document for their two appointments but don't want to  
enlarge it to cover the others, then ISOC can write its own and  
presumably someone will write one for the Nomcom appointments.




- More generally, this document does not define the role or  
accountabilities of the IAOC. This more general objective is part  
of the intention of RFC 4071. Accountabilities of IAOC members are  
described in section 3.3 of that document, and it is repeated again  
in section 4 of that document. In reading that and comparing it to  
the three statements above its my personal view that this covers  
the first two of the statements proposed above.


- It is my view that the third statement above is beyond the scope  
of this draft. From my understanding of the structure we (IETF and  
ISOC) are in, I would not share your view that the "IAOC manages  
the relationship between ISOC and the IETF". To my mind the IAOC  
manages one operational aspect of this relationship, but as far as  
I can tell there's more to the relationship than just the IAOC.


Ah, yes.  There are the pre-existing arrangements where ISOC is in  
the loop to approve the Nomcom's selection of IAB members, ISOC has a  
liaison to the Nomcom, and the IETF appoints members to the ISOC  
board.  None of these are intended to be covered by this document, so  
I agree we need to work on the wording a bit.




However, I would also note that this is an IAB and IESG document,  
and if the IAB and IESG want these statements edited into the  
draft, then, of course, its their call.


regards,

   Geoff


Steve

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

Re: New root cause problems?

[Steve Crocker]

In addition to choosing the right way to look at the distribution of 
total action times, I strongly recommend breaking down the transactions 
into component parts and looking at the details.  The exchange I had 
with Sam Hartman was a good example.  On 5/23. Sam wrote:



I'd think two months would be doing good for IESG processing.  That
includes AD review, IETf last call, telechat delays and a bit of slop
for interaction with the authors.  However that's time to travel
through the queue, not actually time spent on that document.

Because of the delays involved with telechats and last call, getting a
WG document done in less than a month of wall time or an individual
document done in less than 1.5 months is very unlikely.


What catches my attention -- and brings shudders as I remember my time 
as an AD -- is that he paints a picture that looks like


T[IESG] = T[AD] + T[last call] + T[telechat delay] + T[authors]

Now each of these terms has quite different characteristics.  The last 
call and telechat delays add up to a few weeks, to the overall time is 
at least a couple of months.  But those terms probably have moderately 
low variance.  On the other hand, the T[AD] and T[authors] terms have 
very low minimums but extremely high variance, and it's within those 
terms that the real issues emerge.


I suspect if you break those terms down even further, interesting and 
useful dynamics will emerge.


I'm certainly not picking on Sam but merely using his responses as a 
good clue for untangling the separate effects.


In a subsequent note, in regard to T[AD], Sam said


It depends a lot on a document.  I can often do a document in in two
hours if it is reasonably short and I understand the technology and
the document quality is good.  I have one document languishing
somewhat in my queue because I need to block out an entire day for it
and finding a full day to work on one document is hard.


Keep in mind that AD review can easily have round trips with the
authors.

Also, as you are well aware, finding the time among all the other
things is difficult.


To me, this suggests it would be useful to try to identify the issues 
that make it easy and quick to process some documents, but harder and 
longer to process other documents.


There may be some issues related to just the quantity of work, but I 
suspect the bigger issues are qualitative and we may learn something if 
we probe more deeply and not just study the distributions of the overall 
processing times.


Steve









Dave Crocker wrote:

o be slightly provocative, if the average
times are forced upwards by a long tail of WGs/drafts/RFCs that
take extremely long times to get done due to one-of-a-kind reasons,
it would seem fair to remove thoses cases from consideration.




use the median, rather than the mean.  



  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



___
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: Uneccesary slowness.

[Steve Crocker]

"I have one document languishing somewhat in my queue because I need to 
block out an entire day for it and finding a full day to work on one 
document is hard."


I'm guessing that this sort of situation arises when you have less 
familiarity with the work or the document is particularly troublesome. 
I wonder if there's a way to identify this in advance and treat it 
differently.  Lumping the well prepared and easy to process documents 
into the same bin as the ill prepared or difficult to process documents 
could be hiding some important factors that might benefit from closer 
analysis.


Steve





Sam Hartman wrote:

"Steve" == Steve Crocker <[EMAIL PROTECTED]> writes:



Steve> Sam, Thanks.  The IETF last call and scheduling of
Steve> telechats are visible and understandable.  What's the
Steve> figure for time for AD review?

I'm not the best person to ask; my sample set is small.

It depends a lot on a document.  I can often do a document in in two
hours if it is reasonably short and I understand the technology and
the document quality is good.  I have one document languishing
somewhat in my queue because I need to block out an entire day for it
and finding a full day to work on one document is hard.


Keep in mind that AD review can easily have round trips with the
authors.

Also, as you are well aware, finding the time among all the other
things is difficult.


I would say that accomplishing AD reviews in a week of real time would
be doing good; two weeks would be fine.  Some documents will take
longer.



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

Re: Uneccesary slowness.

[Steve Crocker]

Sam,

Thanks.  The IETF last call and scheduling of telechats are visible and 
understandable.  What's the figure for time for AD review?


Steve

Sam Hartman wrote:

"Steve" == Steve Crocker <[EMAIL PROTECTED]> writes:



Steve> Well, I'm probably living in a very old universe, which may
Steve> be out of date.  What numbers are more appropriate?


I'd think two months would be doing good for IESG processing.  That
includes AD review, IETf last call, telechat delays and a bit of slop
for interaction with the authors.  However that's time to travel
through the queue, not actually time spent on that document.

Because of the delays involved with telechats and last call, getting a
WG document done in less than a month of wall time or an individual
document done in less than 1.5 months is very unlikely.




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

Re: Uneccesary slowness.

[Steve Crocker]

Well, I'm probably living in a very old universe, which may be out of date.

What numbers are more appropriate?

Thanks,

Steve

Bob Braden wrote:
 
  *> time for vacations, sick leave and day job, etc.  (My intuition is that 
  *> it shouldn't take more than about 2 days to get through each part of the 
  *> process if nothing else were in the way.


Which universe are you living in?

Bob




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

Re: Uneccesary slowness.

[Steve Crocker]

Ted,

I like your queuing theory formulation.  A couple of easy things follow 
from looking at it that way.


1. Burstiness should result in temporary queuing, but it shouldn't 
result in continuously growing queues.  It's relatively easy to separate 
out the effects of insufficient capacity from burstiness.  I think these 
effects are usually given in terms of the first and second moments, i.e. 
average time to get through the queue and variance.


2. There's enough data available to allow someone -- not me -- to do a 
little parameter fitting to one of the standard queuing models.


3. It would be interesting to get some estimates from the relevant 
parties such as the RFC Editor, IESG ADs, et al as to how much time they 
think it should take to process an individual document through their 
part of the system, assuming no interference or queuing effects.  That 
would give the optimal time for processing a document and provide a 
baseline for understanding the queueing effects and/or other issues such 
as extra work for poor writing, waiting for normative references, down 
time for vacations, sick leave and day job, etc.  (My intuition is that 
it shouldn't take more than about 2 days to get through each part of the 
process if nothing else were in the way.  Except for burstiness and 
waiting for completion from authors, if the system were running 
smoothly, documents really should move that quickly.  All else is a 
symptom something is amiss.  And the numbers for the current system 
suggest (to me) that things are amiss big time.)



Steve





Ted Hardie wrote:

At 10:12 AM -0400 5/21/05, Dave Crocker wrote:


The only way to make sure deliveries of product -- in this case, IETF
documents -- are timely is to decide when they are needed by and set firm
deadlines.  The IETF currently does not do that.  Instead, we leave 
everything

open-ended.



This gives the unfortunate impression that setting firm deadlines is all 
it takes
to get product out.  This is contrary to my experience, and I suspect 
nearly
everyone else's.  I assume this is not what Dave meant, but that he is 
simply

pointing out the usefulness of having a deadline in planning, allocation of
resources, and setting up follow-on activity.

I'd like to suggest, though, that a better model for the problem is 
queuing.

At the moment, every "packet" (document) emitted by IETF working groups
and every document reviewed for the RFC Editor ultimately goes through the
same queue, which is not allowed to drop any item.  The traffic is bursty
and the resources used for processing the packets have priority interrupts
for other tasks (in the individuals: day jobs, family life; for the group:
appeals, other critical IETF business).

That the  queue depth gets longer should be no surprise.  That moving
things around in the queue starts to happen is no surprise, even though
moving them takes energy that could have been otherwise spent on 
throughput.

Making deadlines ever firmer creates priority interrupts or causes more
energy to be expended in queue management instead of throughput.

My personal belief is that we need to implement multiple queues instead.
If the IETF continues to believe that reviewing RFCs for end-runs is
valuable, okay; let's select individuals who can undertake that review,
and get it out of the "make standards" queue.  I've pushed that idea
before; I stopped because the simpler solution (ensure that there are
sufficiently different publication avenues for standards and RFC editor
documents) seemed to be gaining support and that pushed even
the development of the new queue to the RFC Editor.

The fundamental idea, though, remains:  important to the IETF does
not mean "needs to pass through the IESG".
regards,
Ted Hardie

PS.  I almost got through the whole email without saying
"functional differentiation".


___
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: Voting (again)

[Steve Crocker]

I'm not sure where these history questions come from.  The initial 
sequence for the Arpanet is documented pretty thoroughly.  The first 
four nodes were UCLA(1), SRI(2), UCSB(3) and Utah(4).  They were 
installed approximately one month apart starting Sept 1, 1969.  (The 
exact installation dates may have varied slightly.)

Doug Engelbart ran the lab at SRI. Vint, Jon and I were all at UCLA 
working in Len Kleinrock's lab.  Larry Roberts was the director of the 
Information Processing Techniques Office at ARPA.  He was the sponsor of 
the network, which means he paid for it and oversaw the contracts.  BBN 
built the IMPs, which was their name for what we would now call routers.

Over the next few years we all moved around.  I went to ARPA.  Vint went 
to Stanford University.  Jon went to work at MITRE in the Washington DC 
area and then moved back to California to work for Engelbart at SRI.  I 
finished at ARPA -- by then renamed to DARPA -- and went to USC-ISI. 
Jon left SRI and came down to USC-ISI in a different group and stayed 
there until he passed away.  Vint left Stanford and came to DARPA.  Etc.

Steve
JFC (Jefsey) Morfin wrote:
Dear Phillip,
I suggest you consult http://bootstrap.org <http://bootstrap.org/>. I 
think you will have a clearer picture of an underlaying culture of the 
IETF system. There is some work to do to fully evaluate that thinking, 
its cons and pros. Where it leads. What it implies.This is quite 
interesting. May be as much as the Plato's paradigm.

Doug Engelbart located node nr2 (first was Larry Roberts'). He created 
the NIC and if I am correct hired Steve Crocker and Jon Postel (if 
people here can confirm? I try to rebuild the links and dates. The 
history of the thinking/doctrine is very interesting to understand the 
design). You will see that in his story, he came to McDonnell Douglas 
where "seing no commercial value in his work, the company's executive 
fired him and his staff, and closed down his laboratory". I may be one 
of the first there who believed in the potentialities of his technology 
at McDD but  found his concepts did not commercialy fly because of the 
underlaying faith in "collective IQ augmentation" and activity A, B, C 
you may also think present in IETF. IMHO the world is not built that way.

Obviously time has flown. Many other contradictory influences were 
added. But for having related, studied and finaly 
technically/commercialy opposed in part these ideas, I am probably more 
sensible to them. I feel they found the IETF, IAB, IESG, ICANN, etc.
jfc

At 01:16 18/04/2005, Hallam-Baker, Phillip wrote:
> Why do you think a decent-sized, randomly-selected subset of
> the IETF (i.e. the NomComm) are taking actions that are
> substantially more conservative (in terms of keeping people)
> than the IETF as a whole would do?
Because they only get to do it once and have no expectation of
repeating.
> The *whole point* of the
> NomComm is for it to have roughly the same views as the IETF
> as a whole, except in a smaller body. So what makes you think
> that were the IETF as a whole making the decisions, they'd be
> any different?
The people whoe wrote the constitution certainly thought that there
would be a difference. Otherwise they would have done it the obvious
way.
> > Why do engineers believe that they are experts in innovating
> > organizations? Is the result an improvement over traditional
> > arrangements that have been incrementally improved over
> centuries?
>
> I find this comment particularly hilarious, in view of the
> fact that an important part of the inspiration for the whole
> NomComm process was the Athenian Constitution of 508 BC; in
> particular, the mechanism for the selection of the Boule (the
> Council of Five Hundred), which was the chief executive organ
> of the state.
As I said, ignoring the 2,500 years of experience since that date.
Moreover the Athenian constitution was not exactly a success, they
murdered Socrates, got whacked in the Peleponesian war and finaly got
whacked by the Romans.
Given the fragmentary nature of classical accounts I find it astonishing
that you would think that you could understand the dynamics of the
organizations at all, let alone whether they were satisfactory. Most of
the accounts were written by the people whose interests were served by
those arrangements. The one dissenting voice, Plato provides a critique
so devastating that the same experiment is not tried again for two
millenia.
> As you will perhaps recall, this constitution was in itself
> the result of several hundred years of tinkering with
> democratic systems for use in small societies with direct
> democracies (i.e. a very different environment from today's
> mass representative democracies, with their millions of members).
The only large scale organization I know of that has an

Metcalfe's Law challenged

[Steve Crocker]

Kevin Loch wrote:
As you know, the value of a network is roughly proportional to
the square of the participants.

Or maybe not. See Andrew Odlyzko's paper, _A refutation of Metcalfe’s 
Law, 
_www.dtc.umn.edu/~odlyzko/doc/metcalfe.pdf

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

Re: draft-ietf-iasa-bcp-06: ISOC Board of Trustee selection of IAOC member

[Steve Crocker]

John,
Thanks for your note.
Russ,
Let me add a comment, noting that I'm currently on the ISOC board and 
also on the IASA Transition Team.  Since the Transition Team is 
essentially an interim (and restricted) version of the IAOC, I'm roughly 
in the position of being the ISOC-appointed person to the IAOC.  (And I 
don't know whether I'll be appointed to the IAOC when it's 
constituted.)  Also, I'm speaking as an individual, not representing the 
rest of the ISOC board or anyone else.

With respect to your specific suggestions, my views are:
1. Yes, I agree it's desirable that the ISOC appointee should understand 
the IETF, its standards process, and the appointee should also have a 
general understanding of contracts and finances.  I don't think we'd 
want to cast this in concrete or use any present metric for measuring 
these qualities, but I think these are, indeed, desirable qualities.  I 
would expect the ISOC board would likely take these into consideration.

2. I am of mixed minds with respect to whether the ISOC appointee should 
or should not be a sitting ISOC board member.  On the one hand, it's 
important that the IASA operation get close attention and understanding 
from the board.  This will operate to the benefit of IASA.  That 
suggests a sitting board member may be more beneficial to the IASA than 
someone who's not.

On the other hand, everyone is very busy, and getting someone from 
outside the ISOC board is a way of increasing the labor pool, which is 
always a good thing.

3. With respect to choosing someone through an open process, I think 
we'll have to see how things work out.  In the early days, the key thing 
will be to get this operation up and going.  We already have so many 
levels of checks and balances and so many requirements for transparency 
that I don't think it's essential to subject each piece of this 
operation to yet another open process (YAOP).  Open processes are 
inherently slow and time-consuming.  But lest I sound biased against it, 
I don't have a problem with this sort of selection if others also want 
to do it.  But I think it falls squarely within the purview of the ISOC 
board to decide this.  The IAOC is already defined in terms of two seats 
from each of three constituencies -- IESG, IAB and ISOC -- plus two more 
chosen through a Nomcomm process, and I think it then falls within the 
purview of each of those constituencies to make their appointments.  
ISOC has just one appointment in addition to the pres/CEO, so there's 
not much risk the appointee will unbalance things greatly.  And, at 
least as I assess things at this point, our biggest problem is finding 
finding qualified people to fill the slot.

Steve
John C Klensin wrote:
Russ,
While this strikes me as mostly harmless, I don't think it
belongs in this document.  The document itself is an IETF
document.  It has gotten a good deal of useful input from ISOC
staff, Board members, and interested parties, and we expect ISOC
to sign off on it, but it remains an IETF document.  We could
have done it in other ways --which might have been either better
or worse-- but we didn't.
I think it would be good if ISOC made its procedures public once
they decide on them.  But, if the document starts dictating
procedures to them, it both constrains future evolution
unnecessarily and might constitute a barrier to getting swift
ISOC BoT signoff on the document as they debate their own
long-term procedures in this area.
Like others, I'm reconciled to the fact that we will probably
have to revise the BCP in a year or two.  But I still think we
should keep any specifics and details that don't strictly need
to be in the document out of it, lest those force early
revisions over issues that are ultimately not important.
best,
  john
--On Thursday, 03 February, 2005 11:23 -0500 Russ Housley
<[EMAIL PROTECTED]> wrote:
 

draft-ietf-iasa-bcp-06.txt
Structure of the IETF Administrative Support Activity (IASA)
(BCP)
COMMENT
  Section 4 includes a discussion of the process for
selection of
  IAOC members.  There is not a paragraph that covers the
member
  appointed by the ISOC Board of Trustees.  However, the
guidance
  provided to the IAB and the IESG seems appropriate for the
ISOC
  Board of Trustees as well:
- Appointees need not be current ISOC Board of Trustees
members
  (and probably should not be);
- The ISOC Board of Trustees should choose people with
some
  knowledge of contracts and financial procedures, who are
  familiar with the administrative support needs of the
IAB,
  the IESG, or the IETF standards process.
- The ISOC Board of Trustees should follow a fairly open
process,
  perhaps with an open call for nominations or a period
of public
  comment on the candidates.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
   



___
Ietf mailing list
Ietf@ietf.org
https:

Re: One last word on operational reserves

[Steve Crocker]

I'm glad we're drilling down into this level of specificity.  I sit on 
the ISOC board and also on the IASA Transition Team, so I'm reading this 
with both my ISOC hat and a "proto-IAOC" hat on.  (But I'm speaking just 
for myself, not others on the board or the transition team.)

We can try to tighten the words down, and it may be a good thing to do 
so, but I think there's already a fairly strong primary line of defense 
that will come into operation.  ISOC provides pretty strong visibility 
into its finances and will continue to do so.  It will establish, as a 
matter of practice, the necessary reserves, and it will label and manage 
those reserves in a fashion that makes it clear that there is enough 
money for IASA's operational needs.  And in the event there's a threat 
it cannot do so, it will raise the appropriate alarms fairly early.  But 
my saying so is not enough to create the level of comfort Ted and others 
are asking for.

Moving over to the IASA side of the operation, the IAOC will be strongly 
focused on making sure there's enough money available to run the 
operation.  This is where I think the primary line of defense is.  It 
will be the IAOC that is watching to make sure there is enough money, 
and if there isn't, or even if there isn't adequate visibility and 
assurance, the IAOC will raise the alarm on behalf of the IETF.  If it 
doesn't, it's failed one of its primary missions.  The mere creation of 
the IAOC is, in my mind, a strong implementation of the level of 
protection being asked for here.

As I said above, I'm not opposed to having words in the BCP that make 
all of this clear, but I think it's, at best, only added protection in a 
 scheme that already embodies a reasonably satisfactory level of 
protection.

Steve
Ted Hardie wrote:
At 5:12 PM +0100 1/19/05, Harald Tveit Alvestrand wrote:
I *think* this is a "not a problem" thing I believe the intent is 
that IETF can say "we think we need 6 months reserve for our stuff", 
and ISOC can say "that's no problem - we have general reserves that 
are larger than your 6 months + the reasonable risk on other stuff".

I agree that however it is ISOC can say "that's not a problem" is 
sufficient,
whether insurance, operational reserves, etc.  But I believe we need to
be very careful on saying that general reserves are equivalent to the
operational reserve we've requested.  I believe we are asking the ISOC
to ensure that they have this level of protection pretty much no matter
what happens to its other programs, and I believe that we need to be
very frank that this is what we're asking for.  If ISOC says "we can ensure
the following level of reserve, which covers 6 months of IETF activity 
assuming
all else is at least marginal and 3 months if every other program goes 
belly up",
then we need to know that's what they're saying.

Again, I don't have any concerns about how these issues are met, but
I want us to be very, very clear on what we are asking for from ISOC.
And if we need to change those requests to be a reasonable partner to ISOC,
okay.  But that clarity could save a lot of pain later on, and I think 
it is
important.  The smallest amount of hand-waiving here and now can result in
lots of wind later on.
regards,
Ted Hardie

___
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: Rough consensus? #425 3.5

[Steve Crocker]

I have not been paying close attention to the debate over this section 
of the BCP before, so I may be covering a point that's been made before.

I think there will necessarily be a mixture of formal and informal 
processes at work once the IASA is in operation.  The IAOC is intended 
to be at once both independent of the day to day operation of the IESG 
and IAB so it can relieve them of the burden of managing the details on 
a day to day basis and at the same time responsive to the community.  No 
matter what formal mechanisms are put in place, the IAOC needs to keep 
its eyes and ears open to understand how well it is serving the 
community's needs.  Inevitably, there will be some decisions or actions 
that some will complain about.  When things are working well, the IAOC 
will find useful ways of respoding to such complaints, either by 
explaining the situation more fully, adjusting its decisions and 
actions, or, when the complaints simply represent a small minority with 
an unresolvable difference of opinion, standing firm.

Formal means for resolving disputes do need to exist.  I haven't studied 
Margaret's formulation carefully, but on first glance it looks fine to 
me.  Other formulations will also work.  As we all know, if there are 
very many formal disputes, then something larger is probably broken and 
needs to be fixed.  I'm confident the community will raise the noise 
level in that case and we'll be re-engaged in a full, open, community 
review of the IASA, IAOC, etc.

The bottom line on this for me is that everyone should expect the IAOC 
to report regularly and substantively to the community and to listen 
carefully to the community, and that form of communication will be the 
primary safety valve.

Steve
Margaret Wasserman wrote:
Okay, Harald indicated to me privately that I should be more specific 
about my objections to the current wording and offer some alternative, 
so here goes...

I do not object to the use of the term "review" instead of "appeal".
However, I do object to the current wording proposed by Harald for two 
reasons:

(1) I think that there should be an effective way for members of the 
community (not just members of the I*) to question the decisions of the 
IAOC and receive some response.  If a wrong decision was made, it may 
not always be possible to reverse the decisions of the IAOC (contracts, 
etc.), but it could be possible to consider the situation and create new 
rules or guidelines to prevent a similar situation from occurring in the 
future.

(2) I don't think that the mechanism is appropriately specified.  If we 
used the appeals mechanism in 2026, there is already a definition and 
some practical history.  I understand there is some objection to using 
that mechanism, but if we want to invent a new one, then I think we need 
to specify it so that a member of he community (not just I* members) 
could actually use it.

Here is a stab at some alternative wording...
--
3.5 Decision review
In the case where someone believes that a decision of the IAD or the IAOC
he or she may ask for a formal review of the decision by sending e-mail
to the IAOC chair.  The request for review is addressed to the IAOC, and
should include details of the decision that is being reviewed, an 
explanation
of why the decision should be reviewed, and a suggestion for what action
should be taken to rectify the situation.  All requests for review will be
published publicly on the IAOC web site.

It is up to the IAOC to determine what level of formal review is required
based on the specifics of the request for review.  However, the IAOC is
expected to make some public response to a request for review within
90 days of the request, indicating the findings of the review.
If the IAOC finds that an incorrect or unfair decision was made, it will be
up to  the IAOC to decide what type of action, if any, makes sense as a
result.  In many cases, it may not be possible or practical to change the
decision (due to signed contracts or business implications), but the IAOC
may choose to make changes to its policies or practices to avoid similar
mistakes in the future or may simply wish to acknowledge that  a mistake
was made and learn from the error.
If a person believes that his or her request for review was not handled
properly or fairly by the IAOC, he or she may escalate the request to the
IESG by sending mail to the IETF chair.  The IESG will consider the IAOC's
response and may take one of three actions:  (1) indicate that the decision
was properly reviewed and the IAOC's response was fair, (2) state why
the review was improper or unfair and offer advice to the IAOC
regarding what type of response or action would be justified, or (3)
determine that there is a problem with the rules governing the IAOC and
propose changes to this document (or other BCPs) to the IETF
community.  In no case, may the IESG reverse or change a decision of
the IAOC or make

Re: Items where I think there is already a consensus, or which are covered by other tickets

[Steve Crocker]

Harald, et al,
It looks like the BCP process is moving along nicely.  Meanwhile, within 
ISOC, we're studying the draft and focusing on how best to provide the 
right procedures and support for the IETF.  Some  ISOC folks have 
offered up suggestions already.  We will try to provide a more 
comprehensive set of comments shortly.

In broad terms, the IETF runs the standards process and completely 
controls its procedures.  The administrative processes should be 
supportive of the volunteers in the IETF to help make the IETF 
efficient, effective and fulfilling.  ISOC's primary responsibility in 
this area is to raise the funds and provide the business support.  ISOC 
has been funding the IETF and providing business support for many years, 
so the current restructuring of the administrative processes is, from 
our perspective, an evolution of the existing relationship as opposed to 
the creation of a wholly new relation.

Steve
Harald Tveit Alvestrand wrote:
I think the following relations hold:
- Three of the "financial" tickets are covered by the text changes 
proposed in #778 (the "Finances" message I sent a few days ago). They 
are:
- #740: Reserves
- #748: Quarterly deposits
- #772: term "Accruied funds"

In addition:
- #770 (Compensation for IAOC members) has consensus on text
- #771 (Powers of IAOC chair) has consensus on text
- #778 ("Finances") has consensus on the text, as modified by #779
- #779 (IAOC role in separation ISOC/IETF) has consensus on text
- #752 ("ISOC bolt blowing") has not made the case for change, and can 
be closed with no change to text.

Unless someone insists, I won't recapitulate those.
OK?
   Harald
___
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

ISOC board meeting comes AFTER IETF meeting this time

[Steve Crocker]

> (2) Is it generally understood that the ISOC BoT already 
> usually meets on Saturday and/or Sunday before the IETF 
> meetings and that those meetings are open?

Usually yes, but in this particular case, I believe the ISOC Board of
Trustees meeting is Nov 12-13, after the IETF meeting.  If we want to
pursue using a piece of that time for this, I'm sure it can be arranged.
In any case, I expect there will be some time devoted to this as part of
the board's normal business.

Steve


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

RE: archives (was The other parts of the report....

[Steve Crocker]

Eric, you specified exactly the right answer:

> In a perfect system, someone would go to the IETF's official 
> I-D page, enter a draft name,  and get a prominent pointer to 
> the  most recent version (even if it  is now an RFC  or a 
> draft with  a different name), along  with a less prominent 
> pointer to the thing they actually asked for. 

This is very feasible and should be done.

Steve

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Eric Rosen
> Sent: Tuesday, September 14, 2004 10:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: archives (was The other parts of the report 
> 
> 
> 
> I've never  thought that  the IETF  was OBLIGATED to  "hide" 
> old  I-Ds; that seems a rather far-fetched interpretation of 
> anything in RFC 2026. 
> 
> However, I think  there is a real practical problem in  
> making the old i-d's
> be too  readily available.   I frequently get  messages 
> asking  me questions
> like "where  is draft-rosen-something-or-other-04.txt,  I 
> can't find  it" to which the answer is one of the following:
> 
> a. you want draft-rosen-something-or-other-23.txt, or
> 
> b. you want draft-ietf-somewg-something-or-other-05.txt, or
> 
> c. you want RFC 12345. 
> 
> What's happened is  that they have found some email  which 
> references a long outdated draft, and have no clue  how to 
> get to the most up-to-date version, which is what they really 
> want to see. 
> 
> If we make it  too easy to access the old drafts, a  lot of 
> people will just get the old drafts instead of being forced 
> to look for the more recent work.
> 
> Sure, people  who really want to  see the old  drafts should 
> be able  to get them,  but  people who  really  want to  see  
> the  most up-to-date  versions shouldn't get the old drafts 
> just because they only know an old draft name.
> 
> In a perfect system, someone would go to the IETF's official 
> I-D page, enter a draft name,  and get a prominent pointer to 
> the  most recent version (even if it  is now an RFC  or a 
> draft with  a different name), along  with a less prominent 
> pointer to the thing they actually asked for. 
> 
> If  that can't  be  done, it  might be  better  to keep  the 
> expired  drafts
> "officially  hidden".   Not  for  the   reasons  being  given 
>  by  our  more
> academically inclined  colleagues, but  for the practical  
> reasons described above.  Sure, the expired drafts might be 
> obtainable via Google, but getting something from  Google is  
> a bit  different than getting  it via  the IETF's official web page. 
> 
> 
> 
> ___
> Ietf mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

RE: first steps (was The other parts of the report...)

[Steve Crocker]

Agreed.  External Internet connectivity, internal Internet access and a
terminal room are all included in the envelope.

Steve



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 14, 2004 3:53 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: first steps (was The other parts of the report...)
> 
> 
> Umm, not so fast
> 
> When we hosted the London meeting, we were told which venue 
> was to be used.  It turned out that we had to install extra 
> network capacity to the hotel, especially for the meeting, 
> because the hotel didn't have what was required. ( So the 
> hotel did pretty well out of it. )
> 
> There's more to arranging an IETF venue than securing the 
> right number of meeting rooms.  We need to get the functional 
> requirements for these things specified properly.
> 
>   Regards,
> 
>   Graham Travers
> 
>   International Standards Manager
>   BT Group
> 
>   e-mail:   [EMAIL PROTECTED]
>   tel:  +44(0) 1359 235086
>   mobile:   +44(0) 7808 502536
>   HWB279, PO Box 200,London, N18 1ZF, UK
> 
> BT Group plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England and Wales no. 4190816 This electronic 
> message contains information from BT Group plc which may be 
> privileged or confidential. The information is intended to be 
> for the use of the
> individual(s) or entity named above. If you are not the 
> intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information is 
> prohibited. If you have received this electronic message in 
> error, please notify us by telephone or email (to the numbers 
> or address above) immediately. Activity and use of the BT 
> Group plc E-mail system is monitored to secure its effective 
> operation and for other lawful business purposes. 
> Communications using this system will also be monitored and 
> may be recorded to secure effective operation and for other 
> lawful business purposes. 
> 
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Wijnen, Bert (Bert)
> Sent: 12 September 2004 19:41
> To: Steve Crocker; [EMAIL PROTECTED]
> Subject: RE: first steps (was The other parts of the report...)
> 
> 
> Exactly, I agree with Steve here.
> 
> > -Original Message-
> > From: Steve Crocker [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, September 12, 2004 18:51
> > To: 'Margaret Wasserman'; 'scott bradner'; [EMAIL PROTECTED]
> > Subject: RE: first steps (was The other parts of the report...)
> > 
> > 
> > A brief comment on one specific aspect of meeting planning...
> > 
> > In broad terms, the planning for a meeting is partionable, rather
> > cleanly, into two pieces.  One is the "envelope" of 
> arranging for the 
> > hotel, an inventory of large and small meeting rooms, the terminal 
> > room, the external network connectivity, the food and perhaps a few 
> > other things I've left out.  This "envelope" is reasonably constant 
> > and reasonably easy to specify.
> > 
> > The other part of meeting planning is the assignment of 
> WGs, BOFs and
> > other events to the specific rooms.  This requires intimate 
> knowledge 
> > of the areas and other relationships to avoid scheduling conflicts, 
> > work out priorities and maintain communication with all the
> > relevant people.
> > 
> > I believe the former could be farmed out, if desired, although this 
> > gets a bit complicated because it includes finding sponsors 
> and making
> > arrangements for appropriate Internet service.  The latter is 
> > tied quite
> > closely, in my opinion, to the year round support of the 
> WGs and IESG.
> > 
> > I don't have an opinion as to whether the envelope part of 
> the meeting
> 
> > planning *should* be farmed out to a separate organization. 
>  I'm only
> > commenting here that the tasks divide reasonably cleanly.  
> That is, to
> 
> > first order, an IETF meeting needs a plenary room, about ten working
> > group rooms, a terminal room, and a handful of side rooms for 
> > auxiliary purposes.  That's a spec that can be sent out to 
> hotels and 
> > meeting planners around the world.
> > 
> > Steve
> > 
> > 
> > 
> > 
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> > > Of Margaret Wa

RE: first steps (was The other parts of the report...)

[Steve Crocker]

A brief comment on one specific aspect of meeting planning...

In broad terms, the planning for a meeting is partionable, rather
cleanly, into two pieces.  One is the "envelope" of arranging for the
hotel, an inventory of large and small meeting rooms, the terminal room,
the external network connectivity, the food and perhaps a few other
things I've left out.  This "envelope" is reasonably constant and
reasonably easy to specify.

The other part of meeting planning is the assignment of WGs, BOFs and
other events to the specific rooms.  This requires intimate knowledge of
the areas and other relationships to avoid scheduling conflicts, work
out priorities and maintain communication with all the relevant people.

I believe the former could be farmed out, if desired, although this gets
a bit complicated because it includes finding sponsors and making
arrangements for appropriate Internet service.  The latter is tied quite
closely, in my opinion, to the year round support of the WGs and IESG.

I don't have an opinion as to whether the envelope part of the meeting
planning *should* be farmed out to a separate organization.  I'm only
commenting here that the tasks divide reasonably cleanly.  That is, to
first order, an IETF meeting needs a plenary room, about ten working
group rooms, a terminal room, and a handful of side rooms for auxiliary
purposes.  That's a spec that can be sent out to hotels and meeting
planners around the world.

Steve





> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Margaret Wasserman
> Sent: Sunday, September 12, 2004 12:00 PM
> To: scott bradner; [EMAIL PROTECTED]
> Subject: Re: first steps (was The other parts of the report...)
> 
> 
> 
> Hi Scott,
> 
> At 5:06 PM -0400 9/11/04, scott bradner wrote:
> >imo it would least disruptive to follow option #3 (combo 
> path) and try 
> >to negotiate a sole source contract with Foretec/CNRI for what Carl 
> >called the clerk function and maybe some other functions 
> (imo it would 
> >be better to outsorce the management of the mailing lists and their 
> >archives to a company in that business)
> 
> Mailing list management and web hosting (not content) are two obvious 
> candidates for separate contracts if we choose to go with a 
> multi-part RFP process.  These items are quite independent and 
> non-IETF specific.
> 
> Meeting planning is another chunk that could be considered 
> separately, but the way we do it today has a lot of tie-ins to IETF 
> activities -- rules/notices about WG vs. BOF scheduling, proceedings, 
> network, terminal rooms, multicast, sponsorship, etc.  So, if we 
> outsource the meeting planning separately from the "clerk" function, 
> we would have to carefully define the line between the two,  and that 
> line may not be quite where it lies inside Foretec today.
> 
> Also, even if we somehow outsource a few of the more 
> separable/generic tasks independently, there is still a large amount 
> of IETF-specific work that needs to be done by someone -- I-D 
> handling, supporting the IESG review/approval process, handling IPR 
> notices, keeping track of WG charters, maintaining our web content, 
> etc.  It would not be easy to outsource these functions to multiple 
> groups.  It would require extensive effort to define the interfaces 
> between the different functions, and a lot of duplicate work to train 
> multiple groups in the details of the IETF processes and culture.
> 
> I have some concerns that if we try to break off a few of the simpler 
> chunks, the effort of coordinating between those chunks may be larger 
> than the benefits that would accrue from allowing competition in the 
> mailing list management, web hosting and meeting planning areas.  So, 
> this is something we should think about carefully.  A multi-part RFP 
> process that allows organizations to submit multi-part bids (i.e.  if 
> we run the clerk's office,  we will also do meeting planning for $XXX 
> ) might give us some insight into whether ecomomies of scale make it 
> cheaper to go with a single provider for all services, or if it 
> actually works out that it is cheaper/better for some functions to be 
> provided by people who specialize in them.
> 
> Margaret
> 
> ___
> Ietf mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

RE: Options for IETF administrative restructuring

[Steve Crocker]

Leslie,

Thanks.  Your basic point is well taken, but I think there are two
important additional layers.  As you said, the IETF's appointees to the
ISOC board function first and foremost as ISOC board members, not as
IETF's representatives.  This is the same for all the board members.
The IETF appointees to the board have functioned extremely well on
behalf of ISOC.  Indeed, Fred Baker, the chair, is an IETF appointee,
and his election as chair is a signal that the rest of the board values
his leadership across the full range of interests and responsibilities
we have to deal with.

Here's what I see as the additional layers.  First, in a very real
sense, the IETF is in the room whenever IETF related issues are
considered.  There is nearly complete information about the innermost
workings of ISOC available to the IETF and IAB chairs.  There is close
counsel and advice on any matter related to the IETF.  You, Harald, Fred
and Lynn can probably flesh this out better than I can.  There is no
distance and veil of separation between IETF and ISOC.  ISOC does not --
and I don't think it could -- make a decision that is related to the
IETF, much less adverse to the IETF, without close communication and
coordination.

Second, if there were some sort of persistent tension, the IETF would
necessarily take that into consideration when appointing the next set of
board members.  Thus, if something got out of hand, it wouldn't persist
year after year without the IETF taking the natural step of sending
appointees to the board with a strong brief to try to get the problem
fixed.  As you say, this would represent a change in the IETF's current
mode of selecting board members, but it would be entirely within the
IETF's purview to do so.  No approval would be needed from ISOC.  Of
course, if this were ever relevant, things would have gotten to a poor
state, but that's the kind of situation we're discussing.

When I said "the IETF already has a strong management role in ISOC," I
didn't mean that ISOC matters are routed to the IETF as a whole for
decisions.  That would be unwieldy and it would burden the IETF with
details usually unrelated to the standards process.  But I do mean that
IETF viewpoints and IETF active people are always present, and that all
matters related to the IETF involve close coordination with IETF
management.  And, as I said, if problems arise, the IETF has mulitple
modes of access built into the current relationship.

Steve





> -Original Message-
> From: Leslie Daigle [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 07, 2004 6:09 PM
> To: Steve Crocker
> Cc: 'Wijnen, Bert (Bert)'; 
> [EMAIL PROTECTED]'.cnri.reston.va.us; [EMAIL PROTECTED]
> Subject: Re: Options for IETF administrative restructuring
> 
> 
> 
> I'd like to provide one point of important clarification:
> the ISOC trustees appointed by the IETF do *not* represent 
> the IETF. So, while I agree firmly that the IETF's 
> relationship to ISOC is closer than the IETF's relationship 
> to any other organization, I disagree strongly that "the 
> IETF" has "a strong management role in ISOC" as it stands today.
> 
> The IETF, through the IAB (as outlined in RFC3677), selects 
> individuals to fill ISOC Board seats.  The IAB has 
> consistently sought individuals with management, leadership 
> and/or administrative backgrounds appropriate for helping 
> ISOC as a whole organization, to fill those seats.  We (the 
> IAB, the IETF) do not treat those trustees any differently 
> than any other trustees on the ISOC Board; there is no advice 
> given, no reporting sought.  The only time we (the IAB) have 
> sat down with that collection of trustees specifically was 
> when we were seeking input on whether or not there were 
> additional things we should have considered in our selection 
> process (that our original 3 appointees learned after we'd 
> dropped them in).
> 
> I can't speak to whether the folks appointed by the IETF 
> *feel* some obligation to represent IETF perspectives, but 
> there is no formal expectation or mechanism for them to do so.
> 
> While we *could* turn that into a representational 
> appointment, that would represent a change in the status quo, 
> probably would require different appointment procedures 
> within the IETF, and perhaps some additional reporting duties.
> 
> 
> Leslie.
> 
> 
> Steve Crocker wrote:
> > Bert, et al.,
> > 
> > Thanks for your note.  I too have watched the evolution of the 
> > relationship with CNRI for a long time.  I served on the IESG from 
> > 1989 to 1994 when Phill gross was the IETF chair, and I 
> served on the 
> > IAB for another two years.  I co-chaired the POISED working group 
&g

RE: Options for IETF administrative restructuring

[Steve Crocker]

Bert, et al.,

Thanks for your note.  I too have watched the evolution of the
relationship with CNRI for a long time.  I served on the IESG from 1989
to 1994 when Phill gross was the IETF chair, and I served on the IAB for
another two years.  I co-chaired the POISED working group which
reorganized the relationship between the IAB and the IETF and instituted
the nomcomm, so I empathize quite a lot with your concerns.  That said,
let me suggest three things, the last of which is, in my view, the most
important.

1. In my view, the relationship between the IETF and ISOC is not at all
similar to the relationship between the IETF and CRNI.  The IETF already
has a strong management role in ISOC.  The IETF has seats on the ISOC
board, it has complete visibility into the budget, and other specific
formal controls.  That is, it's not a distant, separated relationship,
but one where the IETF is already deep inside.  To a great extent, the
IETF has as much control over ISOC as it would have over a new
organization it might try to establish.  And speaking for myself, if the
IETF needs greater visibility and/or representation within ISOC, I'd
support whatever changes in ISOC governance are needed.  ISOC was
founded to be a home for the IETF and it has functioned in that role
since its inception.  And a large percentage of the ISOC members and
board are people who have grown up in the IETF.

2. I have trouble understanding option C.  It's a lot of mechanism that
doesn't have a clear purpose.  We can dig into the details as deeply as
desired, but I truly believe it's a quagmire.  Some people who advocate
it view it as merely a glitzier form of A or B.  Others view it as a
version of D dressed up so it doesn't seem quite so confrontational.  I
think it creates a whole series of problems and doesn't provide any real
protection.  If a real breach does develop between the IETF and ISOC in
a way that doesn't get addressed sensibly through the very strong
structures and protections that are already built in, then the IETF can
walk away and create another legal home, develop its own source of
funding, and take on the full load of being a separate and independent
organization.

3. As I understand it, the administrative restructuring effort was
stimulated by problems with the support functions.  The problems had
reached the point where the IETF's work was not getting done.
Discussions with the supporting organizations, particularly
CNRI/Foretec, didn't resolve the problems, at least in part because the
contractual and management relationship wasn't clear.  I believe there
is now clear agreement that much cleaner management and budget authority
is required.  One way or another, there will be unified management in
place to oversee the support functions.  That much is good.  What is not
so good, in my opinion, is the lack of focus on what needs to be fixed
in the support functions.  The IESG area directors are perhaps the most
affected and have the most knowledge in this regard, but I'm sure
working group chairs and many others have much to say.  Irrespective of
whether one chooses option A, B, C or D as the framework, the real work
will come in restructuring the support functions and working out the
details of who does what.  I've been surprised at how little discussion
there's been along this line.  If things were broken enough to bring the
relationship with the support functions to a head, then surely it's time
to lay out what needs to be fixed.

What aspects of the IETF's operation hasn't been served properly?  Some
possibilities that come to mind are:

O Turn around time in the Secretariat, IANA and/or RFC Editor hasn't
been fast enough.

O Information flow hasn't been timely or accurate.

O Coordination among the support functions and between the support
functions and the IETF hasn't been satisfactory.

O Automation has been weak and stovepiped.

I can't speak authoritatively about these, and perhaps I've missed some
important questions.  But it seems to me that this is where we need some
attention with constructive suggestions on how to proceed.

(I left out discussion of the meetings.  This is also important, and
there has been some specifics discussed on this list regarding meetings.
This is good.)


Steve



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Wijnen, Bert (Bert)
> Sent: Friday, September 03, 2004 6:07 PM
> To: [EMAIL PROTECTED]'.cnri.reston.va.us; [EMAIL PROTECTED]
> Subject: RE: Options for IETF administrative restructuring
> 
> 
> Scott writes:
> >
> ... snip ...
> >
> > I think that option C brings little useful to the table.  I fail to 
> > see that incorporating the organizer of the IETF admin functions 
> > solves any existing problem that is not better and more 
> easily solved 
> > by options A or B.  Option C mostly adds the complication  
> and expense 
> > of creating a corporation whose purpose almost no one 
> outside of the 
> > IETF, and I expect