Re: Last Call: (On Consensus and Humming in the IETF) to Informational RFC

[Eliot Lear]

Pete,

As usual, I really like your writing style, and I think you're
addressing a very important issue.  There are two aspects that I would
suggest require further exploration, both having to do with the role of
the chair (the whole document has to do with the role of the chair, I
suppose):

1.  No matter how you slice the definition of rough consensus, if the
chair does not act in a fair and balanced way, the outcome will be
incorrect.  This is what the appeals process is for, and I would suggest
mentioning it, perhaps in some detail.

2.  The case of Section 7 is, as you say, a mind bender.  I would
suggest adding another use case: what if those 100 people write their
own draft.  Can they use the exact same process to get the draft adopted
and approved, so long as they answer the technical issues that arise? 
In other words, if there are multiple valid alternatives, and one suits
one vendor group and another suits another, can there be just one
standard?  At the neck of the hourglass, perhaps so?  What happens in
this case, from your point of view?  What makes group (a) more special
than group (b)?

Eliot


On 10/7/13 12:48 PM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'On Consensus and Humming in the IETF'
>as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>The IETF has had a long tradition of doing its technical work through
>a consensus process, taking into account the different views among
>IETF participants and coming to (at least rough) consensus on
>technical matters.  In particular, the IETF is supposed not to be run
>by a "majority rule" philosophy.  This is why we engage in rituals
>like "humming" instead of voting.  However, more and more of our
>actions are now indistinguishable from voting, and quite often we are
>letting the majority win the day, without consideration of minority
>concerns.  This document is a collection of thoughts on what rough
>consensus is, how we have gotten away from it, and the things we can
>do in order to really achieve rough consensus.
>
>   Note (to be removed before publication): This document is quite
>   consciously being put forward as Informational.  It does not
>   propose to change any IETF processes and is therefore not a BCP.
>   It is simply a collection of principles, hopefully around which
>   the IETF can come to (at least rough) consensus.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-resnick-on-consensus/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-resnick-on-consensus/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Eliot Lear]

Ted,

What I like about this message is that you have demonstrated the
*potential* severability of these issues.  Things are set up as they are
for a matter of scaling.  Clearly it ain't perfect, and as one of my
mentors would say, that represents an opportunity.  It's also pretty
clear that we should be reviewing this stuff in consultation with
ICANN's SSAC committee.

Eliot

On 9/12/13 7:21 PM, Theodore Ts'o wrote:
> Fair enough, but if the goal is to prevent pervasive surveillance,
> simply using a key exchange which provides perfect forward secrecy
> will do that, even given the pathetic state of https security given
> the realities of the web and the CA's out there.
>
> Still, I agree with the general precept that perfect should not enemy
> of the better, and DNSSEC certainly adds value.  I just get worried
> about people who seem to think that DNSSEC is a panacea.
>
>  - Ted
>
>

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[Eliot Lear]

We're talking.

Eliot


On 9/9/13 10:20 AM, Ross Finlayson wrote:
> So, has Bruce Schneier actually been invited to speak at the Technical 
> Plenary (or elsewhere) during the Vancouver IETF?  I recall him giving an 
> informative talk at least one previous Tech Plenary, and in light of his 
> 'proposal', if would be interesting to hear what he believes to be broken, 
> and what the IETF might be able to do to help fix it.
>
>   Ross.
>
>
>

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[Eliot Lear]

On 9/6/13 3:04 PM, Martin Sustrik wrote:
> So, what if an NSA guys comes in and proposes backdoor to be added to
> a protocol? Is it even a valid interest? Does IETF as an organisation
> have anything to say about that or does it remain strictly neutral?
>
It's happened before and we as a community have said no.  See RFC 2804.

Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

[Eliot Lear]

On 9/6/13 5:11 AM, Phillip Hallam-Baker wrote:

> S/MIME is almost what we need to secure email. What is missing is an
> effective key discovery scheme. We could add that and add Ben Laurie's
> Certificate Transparency and have a pretty good start on a PRISM Proof
> email scheme.

Not when the keys reside with a service that can be coerced.

Eliot

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Eliot Lear]

So your point is that their conclusions that nobody has the record
installed is false?

Eliot

On 8/21/13 12:42 PM, Patrik Fältström wrote:
> On 21 aug 2013, at 12:26, Eliot Lear  wrote:
>
>> The easy part was supposed to be people actually using the SPF record, once 
>> it was out there.  And so your data doesn't indicate what sort of answers 
>> you're getting.
> These are logs on one of my authoritative servers, and the queries you see 
> are the queries sent _TO_ the server. So of course I also have the responses 
> I give to the one those queries.
>
>Patrik
>

Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Eliot Lear]

Patrik,

First, I appreciate that you and Dave are bringing data to the table. 
However, in this case, it is not in dispute that queries are happening. 
What *is* in dispute is whether there are answers.  I must admit I am
having a difficult time understanding the logic, even so.  The *hard*
part about this was supposed to be implementation of the record in the
application software.  Can the shepherd answer this question:

  * To what extent has that happened?

The easy part was supposed to be people actually using the SPF record,
once it was out there.  And so your data doesn't indicate what sort of
answers you're getting.

And another thing. Randy, is it your position that WGs shouldn't create
new TXT records due to transition issues?

Eliot


On 8/21/13 12:15 PM, Patrik Fältström wrote:
> On 21 aug 2013, at 09:17, David Conrad  wrote:
>
>> On Aug 20, 2013, at 9:00 PM, Andrew Sullivan  wrote:
>>> The WG had a hard time coming up with really good data about what 
>>> validators look for, ... If someone else with some busy nameservers wants 
>>> to provide different evidence now, it wouldn't hurt.
>> Out of morbid curiosity, I just looked at the logs from my name server 
>> (which has both TXT and SPF RRs but which is very, very far from being busy) 
>> with a quick perl hack:
> :
> :
> :
>> totals: spf: 1389, txt: 19435, 7.146900%
>>
>> (the numbers are queries since the name server last restarted/dumped stats)
>>
>> Will look for better data than my measly little name server.
> I have been looking at the queries to one of the nameservers that Frobbit 
> runs (which is authoritative for quite a number of zones, although not 
> GoDaddy), and a tcpdump for a while today gives the following data:
>
> $ /usr/sbin/tcpdump -nr dns.pcap | grep 'SPF?' | wc -l
> reading from file dns.pcap, link-type EN10MB (Ethernet)
> tcpdump: pcap_loop: truncated dump file; tried to read 271 captured bytes, 
> only got 95
> 1105
> $ /usr/sbin/tcpdump -nr dns.pcap | grep 'TXT?' | wc -l
> reading from file dns.pcap, link-type EN10MB (Ethernet)
> tcpdump: pcap_loop: truncated dump file; tried to read 94 captured bytes, 
> only got 18
> 2819
>
> I.e. 2819 queries for TXT while there was 1105 for SPF resource record.
>
> Now, I have no idea whether all of those queries for TXT was only for the SPF 
> usage of TXT of course, but this gives it was at least 28% of 
> (TXT+SPF)-queries that was for SPF.
>
> Deprecating something that is in use that much just does not make any sense.
>
>Patrik
>

Re: [IAB] Community Input Sought on SOWs for RFC Production Center and RFC Publisher

[Eliot Lear]

Hi Ray,

I have one question regarding 3:

> 3.Accountability
> The RPC is responsible to the RSE as regards to RFC Series consistency.


This is the entirety of a section called "accountability".  Can this be
clarified?  What about other than RFC Series consistency?  What is
example of how this statement might be relevant or operative?

Thanks,

Eliot

Re: Last Call:

[Eliot Lear]

On 8/10/13 5:00 PM, Dave Crocker wrote:
>
> One of the reasons we find groups choosing to avoid the IETF's
> standards process is its unpredictability.

Our processes must be stable, but people have different reasons for
articulating concern.  2026 is not meant to be the singular criteria. 
In fact we have for a long time accepted the additional questions that
form a working group, as well.  And unpredictability is part and parcel
of standards activity: you can't buy a standard at the IETF, which is
what predictability implies, if taken to extremes.  And people not
familiar with the IETF often take it to extremes.  A perfect example was
Tim Berners-Lee who wanted to standardize HTML, but didn't want to give
up control of the specification.  It just doesn't work that way.

Now that we're done with generalities, I'll just chime in and say that
the spec in question seems perfectly fine to advance as a Proposed
Standard.  I do wonder whether CBOR is better than compressed JSON, but
I understand that in this context CPU may be a limiting factor.

There is an architectural question hiding here: when we use CBOR in
various protocols, we may be optimizing for the wrong set of devices
overall.  Conversely, we may be optimizing for just the right devices
since the so-called Internet of Things that are low end devices will
outnumber other devices.  Which is it?  Either way, it seems to me we
can't answer without CBOR or something like it, so...  let's have it, then.

Eliot

Re: procedural question with remote participation

[Eliot Lear]

Hey Joe,

On 8/6/13 7:41 PM, Joe Abley wrote:
> An example of (2) can be found in 
>  where I 
> presented a one-slide problem statement that consisted entirely filled with 
> an xkcd cartoon. Once the room is suitably filled with hilarity, it's much 
> easier to enrage people with your stupid idea.
>
> I don't think that having slides available in advance helps significantly 
> with (1) in an ietf context (where we are continuing a conversation from a 
> list, and not generally introducing new material). (2) is not really 
> pertinent for a remote audience (if they've bothered to attend at all, you 
> can surely assume they are paying attention.)

What?  People remotely can't read email?  Heck we can do more than
that.  We can cook a meal.  Try that while an IETF is going on.

>
> Many people use slideware as a teleprompter so that they can remember what to 
> say at the mic. I've done that before. I'm not proud of it.

But if those lines contain *questions*, it gets you to the point where
there is discussion, which is just fine, as you point out here:
>
> The best outcome at a working group meeting is that, as a presenter, you 
> spend most of your time listening rather than talking. If the mic line is 
> empty, you probably should not have been on the agenda.
>

100% agree.

Eliot

Re: Appeal Response to [removed] regarding draft-ietf-manet-nhdp-sec-threats

[Eliot Lear]

No hat on and I'm not commenting on the specific case at hand.

On the general point, I think it's better to err a bit toward the
generous side.  As an author I use as a rule of thumb whether or not I
or the working group has taken someone's suggestion and put it into
text.  And it has to be more than editorial.  A missing "," doesn't get
you into acknowlegments, but highlighting confusion or clarifying
language probably does.

Eliot

Re: The Nominating Committee Process: Eligibility

[Eliot Lear]

Michael,

I think what you're getting at is that there are different types of
remote participation.  If one wants to listen in, that should only
require the appropriate software and a network connection.  If one
actually wants to participate, then one either has to get onto a WeBex
or Meetecho system.  The point of this is that there has should be some
demonstration that someone substantially participated in an IETF event.

Speaking of which, let me also raise another issue.  As those of you who
will be there in person will see in Berlin, we have a *vast* number of
BoFs planned, and this could lead to a vast number of additional new
working groups.  We won't have room for them all.  In addition, I myself
am co-chair of a working group who is not intended to meet – *ever*. 
Linked to the issue of NOMCOM is the idea that working groups actually
meet at IETFs.  Some certainly will continue to do so.  Others, on the
other hand, require more bandwidth.  Case and point: the httpbis working
group has held two interim meetings and two more are planned.  All off
site.  Should these people be counted?  If so, how?

And yes, it is possible to make this so complex that nobody would be
able to figure out who is eligible.

And so, as I said, I'm fine with SM's idea, modulo John's suggested
edit.  But I also think it would be useful to look beyond that change as
well.

Eliot

Re: The Nominating Committee Process: Eligibility

[Eliot Lear]

On 6/27/13 3:34 PM, Noel Chiappa wrote:
>
> Why not just say directly that 'to prevent "capture", no more than X% of
> the NomCom may work for a single organization' (where X is 15% or so, so
> that even if a couple collude, they still can't get control).
>

It's already in RFC 3777.  No more than 2 per company.

Re: The Nominating Committee Process: Eligibility

[Eliot Lear]

John,

I agree with everything you wrote.  I especially applaud SM for getting
out there with new ideas, and I like the idea of opening up eligibility
a bit more.  John's proposed change would reduce risk of capture.  I do
think that risk is also mitigated through other mechanisms (like
limiting the number of people with the same affiliation from joining the
NOMCOM), but Ted's point is also important, that people have some feel
for how the IETF operates, both in person and on mailing list.  John's
proposal seems to strike a good balance.

Eliot

On 6/27/13 2:36 PM, John Curran wrote:
> On Jun 27, 2013, at 5:50 AM, S Moonesamy  wrote:
>
>> Hello,
>>
>> RFC 3777 specifies the process by which members of the Internet Architecture 
>> Board, Internet Engineering Steering Group and IETF Administrative Oversight 
>> Committee are selected, confirmed, and recalled.
>>
>> draft-moonesamy-nomcom-eligibility proposes an update RFC 3777 to allow 
>> remote contributors to the IETF Standards Process to be eligible to serve on 
>> NomCom and sign a Recall petition ( 
>> http://tools.ietf.org/html/draft-moonesamy-nomcom-eligibility-00 ).
>>
>> Could you please read the draft and comment?
> SM - 
>
> I have read the draft, and believe that it moves the qualification to 
> serve on the NomCom in the right direction.  Long-term, it would be ideal 
> if remote IETF participation was equivalent (both as an experience and as 
> a NomCom qualification) to in-person IETF participation.
>
> Noting agreement in the direction, the reality of remote participation 
> today is somewhat different.  In recent years, I have been a frequent 
> remote participant and occasional on-site participant, and while it is
> possible to effectively contribute to working group efforts remotely, 
> such success is predicated on knowing quite a bit about IETF processes 
> and workflow, and it not clear to me that a remote participant picks 
> up the necessary background at anywhere near the same rate as on-site 
> participants.  As a result, I am concerned that the proposed language 
> in draft wouldn't necessarily provide for experienced IETF participants 
> in the NomCom, and/or those who have well-informed insight into what 
> makes for good IAB/IESG/IAOC members.
>
> Note also that the proposed language also increases the possibility of 
> "capture" (i.e. the ability of an single organization to inappropriately
> skew the outcome of the process) in that a relatively large pool of 
> remote participants could quickly be made NomCom-eligible by having them 
> attend the very next IETF meeting, and then all volunteered to serve on 
> the NomCom.  While this is not a particularly likely course for a party
> not happy with the IETF, it is an aspect to be considered in the NomCom
> processes.
>
> With an view towards finding a middle ground, would it be possible to
> change your proposed text from:
>
>   "Members of the IETF community must have attended at least 3 of
>   last 5 IETF meetings remotely or in person including at least 1 
>   of the 5 last IETF meetings in person in order to volunteer."
>
> to this:
>
>   "Members of the IETF community must have attended at least 3 of
>   last 5 IETF meetings remotely or in person including at least _2_ 
>   of the 5 last IETF meetings in person in order to volunteer."
>
> The change from 1 to 2 meetings being in-person significantly reduces the
> potential risk of capture while also increasing the exposure level of
> NomCom volunteers to dynamics that occur in the hallways and between the
> formal IETF working group sessions.  The net result recognizes the value
> of remote participation, moves in the right direction, but does so at a
> more moderate pace than you originally propose.
>
> Thoughts?
> /John
>
> Disclaimers:  My views alone.  NomCom '95 Chair (back before any NomCom
>   procedures existed... :-)
>
>
>

Re: Content-free Last Call comments

[Eliot Lear]

On 6/11/13 3:45 PM, Pete Resnick wrote:
> It's interesting to see that people are interpreting me to mean I want
> more text. I don't. I want less. Save your breath. There is no reason
> to send one line of support, and it only encourages the view that
> we're voting. Details below.

And a lot of details they were.  I will point out that circumstances
probably matter.  For a working group document that has already received
some scrutiny, you've already addressed many questions, like whether the
work is important, whether it's right for the IETF to do, and whether
the solution is correct.  For AD sponsored, I would expect you'd
actually like a bit more.  Yes, you've answered some of these questions
in principle, but the rest of us haven't had our say.  In these
circumstances, I'd have to say that affirmative support with an eye
toward answering those questions (as well as nits et al) would probably
be useful for me to see as an individual.

Eliot

Re: IETF Meeting in South America

[Eliot Lear]

Hi,

Actually it's not industry that I hear complaining, but individuals.

Eliot

On 5/27/13 10:08 AM, Jari Arkko wrote:
> Melinda wrote:
>> The industry sector bias in IETF participation is
>> possibly compounding the regional bias.
>
> Yes.
>
> Jari
>
>
>

Re: Last Call: (The Internet Numbers Registry System) to Informational RFC

[Eliot Lear]

Uch...  you can see where my head is:

On 5/11/13 2:14 PM, Eliot Lear wrote:
> It's probably worth saying that the various PDPs SHOULD address policy
> considerations. How they address them is a matter for them, individually.


s/policy considerations/privacy considerations/

Grr...

Eliot

Re: Last Call: (The Internet Numbers Registry System) to Informational RFC

[Eliot Lear]

Dave,

Just on this point:

On 5/11/13 2:36 AM, David Conrad wrote:

> > There isn't any mention of privacy [2] considerations in the draft.  
> True. The document is documenting current practices and policies. At this 
> point in time, I'm unaware of a global privacy practice or policy that is 
> applicable to all levels of the Internet Numbers Registry System.

It's probably worth saying that the various PDPs SHOULD address policy
considerations.  How they address them is a matter for them, individually.

Eliot

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

[Eliot Lear]

And here we come to a conflict between what we as a community would
like, versus what the market decides.  This leads to a few questions:

1.  Do we have to make a decision at any point from a protocol
standpoint that the market has in fact made a decision?  I ask this
question because I performed an experiment along these lines some years
ago, finding quite a number of proposed standards that were nowhere to
be seen on the 'net.  Earlier we saw discussion about simplifying code
bases, but generally a developer  makes that decision, not the IETF.

2.  What are the timescales involved?  Is it fair to treat IPv6 the same
as a new DHCP option or a DNS RR?  What are the parameters?  One could
reasonably argue with the benefit of hindsight that there was no way we
would see IPv6 adoption until we ran out of IPv4 addresses.  For DNS
RRs, there are some common inhibitors.

3.  What can be done by the IETF to improve likelihood of adoption, and
conversely what should we not bang our heads against?

Eliot



On 5/1/13 7:03 AM, Murray S. Kucherawy wrote:
> On Tue, Apr 30, 2013 at 12:52 PM, David Conrad  > wrote:
>
> SPF using TXT and hence, SPFBIS forces the uniquification of the
> DNS response into the application instead of in the DNS library.
> Given the ordering of individual TXT RRs within an RRset is not
> guaranteed, I suspect the chances that every application is going
> to do that parsing correctly is relatively low (btw, the example
> in 3.3 in spfbis-14 is a bit misleading: assuming "second string"
> is in a separate TXT RR (which is implied), the concatenation
> might be "second stringv=spf1 . first").  The more interesting
> bit is if/when another protocol uses TXT at the same ownername.
>
>
> Yes, I understand all of that, and I've written code to deal with it. 
> It's not rocket science.
>  
>
> The RR has been allocated and it is supported in most DNS servers
> and resolver libraries in one form or another.  Provisioning
> systems take much longer, but that isn't surprising and shouldn't
> be an argument to deprecate (if it is, we might as well close the
> RRtype registry for new entries).
>
>
> We're not only talking about provisioning systems here.  We're also
> talking about interference with queries and replies at the DNS
> protocol level.  The survey work done for RFC6686 showed that
> something on the order of thousands of domains in the sample set
> suffered from this.  It is a very real issue for a deployed protocol.
>  
>
> In the past, the IETF used to make decisions based on long-term
> technical/architectural correctness, even in the face of pragmatic
> complications (e.g., the choice to mandate strong crypto despite
> real world challenges some companies faced in exporting that
> crypto in products). In this particular case, there seems to be an
> argument to explicitly disallow the long-term
> technically/architecturally correct approach because some folks
> choose not to add an RR to their zone files or support that RR in
> their provisioning systems.  As I said in DNSEXT, this seems like
> the wrong approach to me.
>
>
> All things being equal, I would agree with you.  And if SPF were
> starting anew today, I suspect I might have a different opinion.  The
> question, then, is the weight of the mitigating circumstances, which
> obviously the two communities evaluate quite differently.
>
> -MSK

Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

[Eliot Lear]

H Fernando,

On 4/22/13 9:23 PM, Fernando Gont wrote:
>
> There seems to be a disconnect here:
>
> We want an algorithm that, roughly speaking, whenever you connect to the
> same network, gives you the same address. But such address should be
> different for each network you connect to.

Thank you, and yes there was a disconnect.  Indeed now I get it.  For
some reason I had assumed that you meant for some short period of time,
but the algorithm is clearly aimed at longer periods of time (e.g.,
across reboots).  Given that, the inputs the WG has stated seem
perfectly reasonable.


>> How would an IPv6 implementation employing this specification vary from
>> this specification in a way you or the working group would find
>> objectionable?  
> If, for the same interface you employ this algorithm *and* the
> traditional SLAAC algorithm, that's objectionable.

Right.  With you now.

Thanks again...

Eliot

Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

[Eliot Lear]

Hi Fernando,

Thanks very much for your response.

On 4/22/13 6:06 PM, Fernando Gont wrote:
> Hi, Eliot,
>
> On 04/22/2013 01:20 AM, Eliot Lear wrote:
>> In the process of doing the apps area review, I came across some points
>> that were not related to applications.  The basis for these comments is
>> precisely the sentiment that Russ Housley expressed, which is that the
>> specification is done when there is no more to remove.
> I'd probaby disagree with such statement. One thing is removing tuff
> from the mechanism or algorithm that you're standardizing, in the hopes
> of keeping it simple (this one I'd agree with). Another is removing text
> from specifications, which essentially means that the gut implementing
> the spec has more to figure out by himself, and hence more chances for
> failures.

Fair point, of course.

>
>
>>  With this
>> document, I wonder if quite a bit could be removed.
>>
>> Specifically, a great deal of discussion goes into the PRF involving DAD
>> counters, etc, when all that is needed is a suitable PRF.
> Not sure what you mean...What's thetext that you think could/should be
> removed?

Sorry I wasn't clear: what is the benefit of specifying the algorithm,
when simply popping out another PRF will in just about any instance do
the job (unless you are reinitializing the PRF with the same seed)?

>
>
>> The draft in
>> fact says this in Section 3 after an explanation of the inputs.  Any PRF
>> that follows the guidelines of RFC 4086 should do fine and not cause
>> interoperability OR security problems.
> If you're referring to the text that explains why we're not mandating
> any specific PRF, that text is there because the issue was raisen in the wg,

Ok.  So what I gather is that there was a negotiation within the WG and
that the algorithm is optional.  Ok.  From an outside point of view, I
didn't need to know that, and the question is what was the value of
still specifying the PRF.  I think Ran Atkinson answered that.  He feels
he wants a fully specified algorithm from which to start.  Ok.  My only
response is that I don't understand the need (generating 64 bits that
aren't the same shouldn't be that hard), but if the WG really believes
there is one, okay.


>
>
>> Also, the following text in section 3 Page 7 is contorted:
>>
>>   This means that this document does not formally obsolete or
>>   deprecate any of the existing algorithms to generate Interface IDs
>>   (e.g. such as that specified in [RFC2464]).  However, those IPv6
>>   implementations that employ this specification must generate all
>>   of their "stable" addresses as specified in this document.
>>
>> My suggestion is to simplify remove it as it is self-evident.
> What's the part that is evident? The one about not deprecating existing
> algorithms? -- Because the other ne certainly isn't: if you're going to
> use this algorithm for generating addresses *in addition* to those
> generated by traditional SLAAC, then this document wouldn't mitigate
> address-scanning attacks.

How would an IPv6 implementation employing this specification vary from
this specification in a way you or the working group would find
objectionable?  Also, did you mean "MUST"?  If not, this language is all
the more confusing and I don't know what you mean.

>> Finally, this algorithm requires that the resultant host portion be 64
>> bits.  Is that necessary?
> Well, yes- If the PRF produces a bit string larger than 64 bits,  and
> you say nothing about how you grab the IID, then the algorithm is
> underspecified.
>
> The easier it is for a developer to go through this document and come up
> with an implementation, the better. The more the open questions, the worse.
>

I think we are underestimating our developers but if the working group
feels differently, okay.  I asked the above question because it is at
least conceivable that at some point host portion != 64 bits and this is
the only place in the document where the requirement is stated.  Yes,
screwing with the 64 bit boundary today is bound to cause all sorts of
breakage.  I'm not thinking of today but the future.  And yes, another
argument would be that there isn't enough address space for this to be
effectively private.  Those are two different issues, but fixing the
boundary here reminds me of mistakes we made with IPv4 way back when. 
In this day and age we're talking about a lot more cleanup later.

Eliot

last call comments for draft-ietf-6man-stable-privacy-addresses-06

[Eliot Lear]

In the process of doing the apps area review, I came across some points
that were not related to applications.  The basis for these comments is
precisely the sentiment that Russ Housley expressed, which is that the
specification is done when there is no more to remove.  With this
document, I wonder if quite a bit could be removed.

Specifically, a great deal of discussion goes into the PRF involving DAD
counters, etc, when all that is needed is a suitable PRF.  The draft in
fact says this in Section 3 after an explanation of the inputs.  Any PRF
that follows the guidelines of RFC 4086 should do fine and not cause
interoperability OR security problems.  Put simply, you are
over-specifying the RID and derive no benefit from doing so.

Also, the following text in section 3 Page 7 is contorted:

  This means that this document does not formally obsolete or
  deprecate any of the existing algorithms to generate Interface IDs
  (e.g. such as that specified in [RFC2464]).  However, those IPv6
  implementations that employ this specification must generate all
  of their "stable" addresses as specified in this document.

My suggestion is to simplify remove it as it is self-evident.

Finally, this algorithm requires that the resultant host portion be 64
bits.  Is that necessary?

Eliot

Re: IETF Diversity Question on Berlin Registration?

[Eliot Lear]

Self inflicted confusion.  Please see below:

On 4/18/13 5:17 PM, Dan Harkins wrote:
>   Hi Eliot,
>
> On Wed, April 17, 2013 12:48 pm, Eliot Lear wrote:
> Pardon me, but that makes no sense. Asking about the gender make-up of
> those who elect to register for a future meeting is going to tell us
> little about who we are. It will be a snapshot in time and it will not
> representative of "who we are" because we are more than just the
> people who register to go to any particular meeting. 

And let's stop there.  The point of my originally muddled note was that
we shouldn't just ask about gender.  For that I apologize.  Also, I
wouldn't do this just one time.
>   The facts are already not in dispute. The I* leadership is predominantly
> white and male. The fallacy works like this:

We don't have facts in evidence, and as I wrote above, I'm not even sure
we know which facts we need.  I can say that gender is probably one,
country of residence is something we have, age is something we don't
ask, but we do ask how many meetings you've been to.  We don't ask why
you're at the IETF and we don't ask which groups are important to you. 
We don't ask whether you plan to attend other IETFs and we don't ask
anyone who has attended an IETF but isn't back, why they didn't show. 
We don't ask questions about the experience, in terms of how people are
able to find their way through the process.  There are many questions we
don't ask.  Now granted, some of this is more than who we are, but also
how easy are we to work with.  How does language and location play into
this?

Personally I'd love to survey people going to OTHER standards
organizations and find out why they chose those other organizations to
pursue work, but then I'm not footing the bill for all of this, so...

This is not just about one attribute.  You're ALMOST right in that a lot
of us know each other.  Perhaps that's even a problem, in that others
can't break in.

Much of this is what I would expect the diversity team to explore.

Eliot

Re: IETF Diversity Question on Berlin Registration?

[Eliot Lear]

Dan,

On 4/17/13 9:21 PM, Dan Harkins wrote:
>   We already know "who we are".

I disagree.  We make a whole lot of assumptions about who we are, but we
don't actually know, and that's why the question is being asked.  I
would clarify that IMHO the only reason this question should be asked is
for demographic purposes, along with others.

>  This question is trying to decide our
> gender make up and nothing good can come of it.
>
>   It will provide more "evidence" for people to make use of logical
> fallacies-- "if P implies Q then look we now have evidence of Q
> therefore P"-- which really have no place in an organization devoted
> to engineering.

This would be putting the cart before the horse.  We first need to
understand facts.  If we don't understand facts, then people will
continue on assumptions.

>
>   And it will be used as a baseline for doing work towards some goal
> that has not been justified, work whose very nature requires treating
> people according to what they are instead of who they are.
>
>Look, bias stinks and when it exists its stench is detectable. I don't
> recall seeing any evidence of bias being presented on this list. And I
> don't believe there is any problem has been mentioned that we had or
> have that is caused by this predominance of white men. It's just been
> stated as a problem itself. We must have less white men. Why? Because,
> that's why.

Nobody has proposed that, and I think you can put a bit more faith in
your peers to not make important decisions based on "because".

Eliot

Re: IETF Diversity Question on Berlin Registration?

[Eliot Lear]

Dan,

On 4/16/13 2:00 AM, Dan Harkins wrote:

> Under the belief of "garbage in, garbage out", I tend to lie on these
> sorts of repugnant questions. I invite others to join me. The more
> suspect the quality of the data, the less value it has. Dan. 

Please don't.  We are trying to understand who we are.  Is that SO
unreasonable?

Eliot

Re: IETF Diversity Question on Berlin Registration?

[Eliot Lear]

SM,

Since you asked,  the IAB spoke on this subject as one voice last year
when the OpenStand RFC was released. 

As a current IAB member, and speaking for myself...

On 4/13/13 1:32 AM, SM wrote:
>
> Thomas Narten mentioned that: "we have the tendency to pick the people
> we know and trust, which is understandable".  How many IAB members
> feel strongly about open standards, rough consensus and running code? 
> To know the answer I would have to actually know the IAB members.

Well, say what you will about whether you believe me, but all THREE of
those are important to me, personally.  No standards organization
produces perfect results, but you have far less chance of spotting a
problem if you hide your processes from the public, reduce the voice of
experts, and don't pay attention to operational experience.

Eliot

Re: IETF Diversity Question on Berlin Registration?

[Eliot Lear]

I struggle to engage in this debate because in general I'm not sure how
my voice helps advance the general discussion.  But I do want to make
two points:

On 4/12/13 8:33 PM, Melinda Shore wrote:
> I think it's unintentional [...]

 1. As others have said there are many forms of bias in play, which may
require different forms of redress.  I expect we can be more
successful in some areas than others.
 2. Let's be careful with using words like "unintentional".  For all we
know there may be very good reasons that led to the results of this
year.  This is not something I would expect to come out of a NOMCOM
report, by the way, due to their confidentiality requirements.  And
there is where I think we are most wrapped around the axle.

In any case, hard as it may be, we as a community have identified a huge
concern, and it would be regrettable if we didn't explore that concern
and try to find areas in which we could improve.  I claim  that doing so
will improve the IETF in the longer term.

Eliot

Re: Diversity of IETF Leadership

[Eliot Lear]

Let's not play Internet lawyers about this.  How Jari's design team
bring in real lawyers at the appropriate time?

Re: Getting rid of the dot

[Eliot Lear]

On 3/19/13 4:19 PM, Carsten Bormann wrote:
> I want my badge on a shiny embossed metal plate with the words
> "protocol police" on it. Where do I have to apply?

If memory serves, HP offered such a badge as Interop "schwag" in the
late '80s.  Another old timer, Erik Fair, actually kept his for a few
years and then wrote a little ditty for RISKS about an email failure due
to mishandling of SMTP.  Protocol police indeed!

Eliot
[1] http://catless.ncl.ac.uk/Risks/11.66.html#subj2

Re: Please review draft-housley-rfc2050bis-00.txt

[Eliot Lear]

While I appreciate the minimalist approach, can we please get one
*phrase* each on what is being referenced, so that people might have
some reason to actually read the reference:

> Internet Registries [ASOMOU] and documented in [ICANNv4],
>   [ICANNv6], and [ICANNASN].

Also, I note that the NRO is not mentioned at all.  Perhaps the NRO is
merely meant to support RIR activities, but no mention at all?

Re: Thoughts from a past experimental Nomcom selection for TSV Area Director

[Eliot Lear]

Dave,

Thank you for sharing your experiences in such an open way, and for your
long and dedicated service to the Internet community.

Eliot

On 3/12/13 4:41 PM, David Harrington wrote:
> Hi,
>
> Many suggestions have been made about ways to resolve the issue of finding
> suitable candidates for TSV Area Director, or adjusting the job to fit
> available candidates.
>
> In 2010, I started as TSV AD, after the Nomcom had serious trouble filling
> the TSV AD spot. I was encouraged to put my name in as a candidate since I
> had solid IETF experience, even though I had no experience with the TSV
> area. Interviewing for the position really confirmed for me how little I
> knew about transport, so I was very surprised when I was nominated. 
>
> After two years in that specific role, I have some insights I would like to
> impart to the Nomcom and the community, and especially to any candidates for
> the role who have never served on IESG. I'll repeat some of what has already
> been suggested, but I'll try to put these things together to help explain
> some contextual relationships that exist.
>
> I. the overall workload
>
> I found IESG/AD work to be a fulltime position, as in 100%. My first year, I
> worked anywhere from 60 to 90 hours per week. Of course, I had a lot of
> remedial learning to do; honestly, technical on-the-job training for a whole
> area while working to perform your IESG review work and other AD tasks is a
> tremendous burden. You won't do this in 50% of a normal work week. My second
> year, I cut back the number of hours to 50-60 hours a week and took some
> vacation time, so I could have a life beyond IESG, and the quality of my
> work and my queue management suffered seriously as a result. YMMV. My main
> concern is that a candidate with no area background can fall behind quickly,
> and possibly never catch up fully within a two-year term.
>
> The workload has two parts - the IESG/steering/approval part, and the area
> directing/managing part. I learned over time to split this generally by week
> - one week IESG, the next week AD. Otherwise it becomes hard to prioritize
> because it is very difficult to prioritize both (time-competing) parts
> simultaneously, without favoring one or the other. The job requires you to
> do both.
>
> II. workload - IESG 
>
> IESG work requires review of about 15 documents every two weeks; those
> documents come from anywhere in the IETF. Many of those documents require
> the reviewer to understand the normative references upon which the document
> is built. Internet standardization is now quite mature, and much of the new
> standards work is dependent on older standards. I came from the SEC area and
> the NM side of the OPS area, and those can be somewhat isolated from TSV,
> INT, RAI, and routing. If your background has been limited to working in one
> or two areas, you may need to learn a LOT about the technical developments
> and the existing standards in the other areas. If you have been an active
> reviewer in one or more directorates, and/or have previous IESG experience,
> that should help a lot, but I still found it a challenge even after
> experience in multiple directorates; when you do a security review of a
> congestion control document, you look for security issues, not congestion
> control issues.
>
> You'll need enough understanding of the TSV issues to be able to spot bad
> transport-related decisions in documents coming from elsewhere in the IETF.
> You (and your co-AD) are effectively the reviewer of last resort for TSV
> issues. If you don't understand control loops, congestion control
> techniques, etc., you will NEED to rely on your directorate for assistance
> in this role.
>
> If you pride yourself on the thoroughness of your reviews, as I did, get
> over it; you won't have time for thorough reviews.
>
> Some have commented on the "extra" stuff related to IESG work, such as
> cross-SDO coordination, process tweaking, and so on. These definitely take
> time, and they are important because that is part of the job. But other IESG
> members can handle the bulk of this extra work while you're still learning
> the area.
>
> III. workload - AD
>
> The AD for an area becomes the spokesman/shepherd for all documents coming
> from their area. When you bring it to the IESG, you will be asked about the
> quality of the document, the technical content, whether certain questions
> were considered, what impact this might have to existing networks, how well
> the document follows established guidelines for security, management,
> operations, IANA assignments, XML usage, and so on. You should know those
> guidelines exist and have already asked most of the relevant questions and
> had them addressed before you put a document on the telechat agenda. You can
> ask various directorates for help. Not knowing the technology will require
> you to go ask your experts and try again, possibly repeatedly (you don't get
> to bring experts with you to IESG telechats

Re: congestion control? - (was Re: Appointment of a Transport Area Director)

[Eliot Lear]

Roger,

On 3/4/13 7:20 PM, Roger Jørgensen wrote:
> I'll ask a rather basic question and hope someone will answer in an
> educational way - Why is congestion control so important? And where
> does it apply? ... :-) 

That basic question is a very important one to ask from time to time. 
Others have already answered, and I will simply add one addition: the
way one implements congestion control (or not) has impact not only on
the party or parties with whom your computer is speaking, but on every
communication that shares the links between your computer and those
parties.  So: get it wrong and you can hurt others.  And it's easy to
get wrong.

Eliot

Re: Appointment of a Transport Area Director

[Eliot Lear]

Sam,

On 3/4/13 6:34 PM, Sam Hartman wrote:
> I actually think expecting ADs to learn a fair bit on the IESG is part
> of coming up to speed on the IESG.  I'm aware of people who served on
> the IESG with me who had significant gaps in material their area
> covered.  In some cases, this was solved by splitting work load.  In
> some cases it was covered by having the AD learn a lot.  In one case the
> AD came in having huge gaps in half of the area in question. Today that
> person is considered an expert in one of the areas where he had the
> largest gaps and is focusing most of his effort there.

We're here because of the extremely specialized nature of transport. 
PhDs who specialize in it have gotten it wrong.  One such person drove
Van Jacobson into the field, as I recall. There are very few people who
get it right.  And yet it's so close to the waist of the hour glass that
it's critical to get right.  Security has a lot of visibility and so it
will never have this very same problem.

>
>
> IESG-level review of a document really is a skill that can be
> learned. It helps to have a lot to draw on, but I don't believe anyone
> can (or does) have coverage of all the areas they are reviewing. The
> huge part of the skill is to figure out how to do the technical job even
> given that.
> It involves trusting others sometimes, reading discussions, learning new
> things. Sometimes though, you do just have to spend the effort to
> understand some particular issue well enough to make an informed
> opinion.
>
> Having experts in areas doesn't escape this. When there's an appeal or a
> disagreement between areas it can be important for ADs to come up to
> speed on an issue outside their area and make an informed decision about
> it.
>
> So in conclusion, I strongly value technical contribution and
> demonstrated ability to pick up new knowledge in an AD. I do not highly
> value knowing all the things going on in a specific area at the time the
> AD joins the IESG.

Please let's not overgeneralize.  I'm not on the NOMCOM but I know it is
not every area we are having this problem, it's transport.

Eliot

Re: Appointment of a Transport Area Director

[Eliot Lear]

Mary:

On 3/4/13 6:51 PM, Mary Barnes wrote:

> [MB] I don't think anyone has said an AD could be a manager with
> little technical clue.  I think Sam said it extremely well in his
> email.  What some of us have been proposing is that someone with
> proven technical skills in another area that also is good at managing
> projects/people could do a reasonable job.  From what I have seen this
> has certainly been the case in other areas - i.e., ADs that don't have
> depth of knowledge in all the WGs in their areas, but are strong
> technical individuals in other areas. 
>

I am very sorry to have to say this, but we are all dancing around the
issue that we have experience of where the above has been shown to
simply not work well.  And this is why it is important for a NOMCOM that
gets into such a situation to do exactly what this NOMCOM did: consult
with the IESG to determine the need to "have a body" versus have the
right person.


>  The problem seems to be that
> folks value the technical expertise far more than they do project and
> people management skills.   The end result is that there are some
> really strong technical people in leadership roles that have little
> ability to manage things well and very poor people interaction skills.
>  The latter is certainly a very negative personality trait when it
> comes to motivating and managing volunteers. [/MB]

That happens from time to time, let's agree.  And maybe it is the price
we pay for the model we have.  And maybe that's a trade-off worth
having.  This is not to say that the IESG shouldn't evolve its working
methods, by the way.  But it is possible to get it wrong.

Eliot

Re: Appointment of a Transport Area Director

[Eliot Lear]

On 3/3/13 8:53 AM, Brian E Carpenter wrote:
> When there is a choice between nominating nobody, and nominating someone
> with excellent IETF experience and management skills, but who is not a
> recognised specialist in the narrow technical area concerned, I believe
> that standing advice to the NomCom should be to appoint such a candidate.
>

It seems to me that the standing advice should be to consult with the
IESG about the matter to determine an appropriate course of action.  The
result in this case was that the IESG wants to openly consult with the
transport area before moving forward.  I think that's quite wise.

Eliot

Re: Time zones in IETF agenda

[Eliot Lear]

On 3/1/13 9:41 PM, John R. Levine wrote:
>> I've said it before: just go back and forth between Iceland and
>> Hawaii. Oh, and maybe Minneapolis for old-time's sake. ;-)
>
> New Zealand, please, in easy to remember UTC+12

New Zealand would be quite appropriate, given it was the place that had
the first standardized offset in 1868.

Eliot

Re: Internet Draft Final Submission Cut-Off Today

[Eliot Lear]

On 2/26/13 9:28 PM, Martin Rex wrote:
> I have a recurring remote participation problem with the
> IETF Meeting Agendas, because it specifies the time of WG meeting slots
> in local time (local to the IETF Meeting), but does not give the
> local time zone *anywhere*.
>

Except for the ICS files that are generated by the agenda tool
(https://datatracker.ietf.org/meeting/86/agenda.html).  If you take the
URL that is generated after you select the sessions you are interested
in, you can import a series of EVENTs complete with VTIMEZONEs into any
modern calendar program (e.g., Outlook, iCalendar) and the Right Thing®
will happen.

Eliot

Re: [IETF] Showing support during IETF LC...

[Eliot Lear]

On 2/25/13 9:06 PM, Warren Kumari wrote:
> I suspect it is because it is very hard to know if someone replying with '+1' 
> has actually read / has a useful opinion on whatever they are replying to, or 
> is just going alone with the herd…

+1.

Re: Remote Participation Services

[Eliot Lear]

Hi Thomas,

On 2/7/13 3:46 PM, Thomas Narten wrote:
> It is good to document what we have been doing. But the text seems to
> focus on technology and tools...
>
> IMO, what is missing is operational Best Practices. We seem to be
> lacking them (are any written down?) And we don't follow them
> consistently, especially from one WG to another. Many of the problems
> I see with remote participation facilties have to do not with the
> technology per se, but with lack of proper training and advance
> testing. I get the general sense that getting the remote stuff to work
> is a volunteer effort where each person tries it themselves with no
> checklist of obvious things to do in advance, and no recourse if no
> one in the room can get something working.
>
> E.g., I was at an interim meeting last fall, where it looked like when
> the meeting started, that was the the first that folk actually looked
> at the facilities in the room (phone, microphones, etc.) to see how
> best to allow remote participants to speak. The quick conclusion was
> "can't be done". This should have been worked out (and tested) in
> advance, not at the start of the meeting.
>

I appreciate this point of view, but at what point do we mean that a
face to face is really intended to be that?  That is- if you can get the
facilities going, great.  If not, let's recall how many people are on
the IETF payroll in this process, especially when it comes to interims. 
That having been said, I think it would be great to have a best
practices guide or checklist as you suggest.  Forgive me if this sounds,
crass- it's not intended to be– but sending some text to kick things off
would be very helpful.

Eliot

Re: History of protocol discussion or process in WG

[Eliot Lear]

On 2/3/13 7:38 PM, Dave Crocker wrote:
>
>
> On 2/3/2013 10:28 AM, Sam Hartman wrote:
>> I'm not sure I've ever been involved with a WG where you could have
>> gotten consensus on any of the above enough to publish it.  Nor can I
>> think of many WGs that have the excess energy to do this work.  Even
>> getting consensus on a summary of where you ended up is quite
>> tricky.
>
>
> Getting consensus on the details of a history is much more difficult
> than on a technical spec...
>
> So don't try.

+1.  In fact in the ITU context they will sometimes spend half a day on
a meeting report.  I really don't think we want to go there.


What I would like not to have happen is that we spend any time bickering
over who said what, especially if it detracts from the business of
developing excellent standards.  I think your point, Dave, about
synthesis being left to historians is a good one, and I might go
farther, and say that the whole endeavor should be.  But having at least
a record from individauls about what *they* said or meant is, I suppose,
not unreasonable.

Eliot

Re: FW: Last Call: (A Fast-Track way toRFC with Running Code) to Experimental RFC

[Eliot Lear]

On 1/27/13 12:19 PM, t.p. wrote:
> The point that Thomas made and John endorsed is that when we want to
> speed things up, our current procedures allow us to do just that. We
> do not need a formal process (more complications, more work). And as
> John pointed out, having two independent Last Call discussions, on two
> different lists, on communities that may have little overlap, is not
> the way, IMO, to establish a clear consensus.

If we don't need a formal process, then I'd like it clarified in WG
training that this procedure already exists.  Furthermore, I don't buy
the notion about confusion.  In the cases where this is likely to be
done, either an emergency exists (which was the case with TLS, IMHO), or
the draft is likely not to elicit much in the way of objection.  This
DOES happen.  But that having been said, if both a WG chair and an AD
make a bad call, there are numerous opportunities to correct it in this
process, the NOMCOM process, appeal, etc.

Eliot

Re: FW: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC

[Eliot Lear]

John,

On 1/25/13 4:27 PM, John C Klensin wrote:
>>> a WG can
>>> skip WG LC if they think its not needed.
>> ???
>>
>> When was the last time that happened?  Did it require a
>> consensus call to determine?
> Chair discretion [... and five of paragraphs of text]

None of which answered my above questions.  When was the last time
chairs USED that discretion?!

Eliot

Re: FW: Last Call: (A Fast-Track way to RFC with Running Code) to Experimental RFC

[Eliot Lear]

On 1/22/13 10:31 PM, Thomas Narten wrote:
> a WG can
> skip WG LC if they think its not needed.

???

When was the last time that happened?  Did it require a consensus call
to determine?

Eliot

Mark Crispin: 1956 - 2012

[Eliot Lear]

It's probably escaped our notice because of the holidays, Mark Crispin
passed away on the 28th of December.  I didn't know Mark too well, but
he was a very important visionary. 

I first enjoyed his work as a user of the MM program on TOPS-20, upon
which he based the design of IMAP.  MM featured strong searching and
marking capabilities, as well as all the customization a person could
want.  It was through MM that people individualized there messages with
funny headers or a cute name.  And it was all so easy to use.  Mark was
constantly reminding us about that, and how UNIX's interface could
always stand improvement.  Mark was an unabashed TOPS-20 fan.

Before the world had fully converged on vt100 semantics, Mark worked to
standardize SUPDUP and the SUPDUP option.  He was also early to
recognize the limitations of a single host table.

Mark's sense of humor brought us RFC-748, the Telnet randomly-lose
option, which was the first April 1 RFC.  He also wrote another such RFC
for UTF-9 and UTF-10.

Most of us benefit from Mark's work today through our use of IMAP, which
followed Einstein's advice by having a protocol that was as simple as
possible to tackle the necessary problems, but no simpler.  We know this
because our first attempt was POP, which was too simple.  Mark knew he
had hit the balance right because he made benefited from his experience
with lots of running code and direct work with many end users.

I will miss his quirkiness, his cowboy boots, and his recommendations
for the best Japanese food in a town where the IETF would visit, and I
will miss the contributions he should have had more time to make.

Eliot

Re: WCIT outcome?

[Eliot Lear]

Hi,

At its core, the value of the IETF is technical.  We must always make
the best technical standards we can possibly make, adhering to the
values of rough consensus and running code.  Everything else is
secondary or nobody (government or otherwise) will want to implement
what we develop.  It's easy to lose sight of this in this conversation. 
It's an advantage we have over organizations who vote by country, and we
will always have it so long as such votes are allowed and where the
majority of expertise is found in a minority of countries, or where the
voice of expertise is silenced through "representation".  Because of
this approach, what happened at WCIT and at WTSA is likely to harm
developing countries more than anyone else, and that is truly unfortunate.

And so what do we need to do?

 1. Keep developing the best technical standards we can develop, based
on rough consensus and running code.
 2. Do not get overly consumed by palace intrigue in other
organizations.  It detracts from (1) above.
 3. While we cannot control others, we can and should occasionally
remind them when they're going to do something that when implemented
as specified would harm those who deploy the technology.
 4. Invite and encourage all to participate in our activities so that
the best ideas flourish and all ideas are tested.

The other thing we need to understand is that the IETF doesn't live
without friends or in a vacuum.  The RIRs, NOGs, other standards bodies,
and ISOC all are working at many different levels, as are vendors.  If
WCIT shows anything, it is that these organizations are being listened
to, at least by many in the developed world.  Why?  Because over 2.5
billion people are connected, thanks to the collaboration of these and
other organizations.  That's moral authority that should not be
underestimated.  Nor should it be taken for granted.  See (1) above. 
And we also shouldn't try to boil the ocean by ourselves or it will
surely impact (1) above.

Can we do a better job on outreach to governments?  Yes.  I'd even
venture to say that the IETF should be held – from time to time – in a
developing country, so that people can more clearly see who we are and
what we do.  But not too often, lest it interfere with (1) above.  If we
keep building the best stuff, they will continue to come, even if there
are bumps along the road.

Eliot

Re: "IETF work is done on the mailing lists"

[Eliot Lear]

[apologies to some for duplicates]

Hi Geoff,

On 11/29/12 3:56 AM, Geoff Huston wrote:

> It's nice to have reasonably well thought out ideas come in.
>
> Which then become highly defined precepts that become incredibly resistant to 
> IETF change on the basis that they have been well thought out already (and 
> probably are IPR-ridden) and at that stage the IETF process is functionally 
> reduced to rubber stamping. At that stage the value of the IETF imprimatur 
> becomes highly dubious to the industry its meant to serve.

In my experience, when the IETF has been offered work that the other
party felt was "complete" and would refuse to allow changes to, we've
demurred (c.f., html).  On the other hand, in the instances I'm aware,
when the IETF did accept the work, it was always made clear that the
IETF had change control (and used it).  A perfect current example of
this right now is scim.  There were numerous implementations of scim,
and it was brought to the IETF not only for the imprimatur but also to
improve the work.

A simpler explanation is that the authors and editors of work are more
immersed than others, and therefore project more authority.  Certainly
that has been the case in nearly all efforts I've been involved, with a
notable exception that also is illustrative: oauth, where an editor left
the IETF precisely because he could not agree with the results.  that's
a good indication that we're striking a balance.

Eliot

Re: "IETF work is done on the mailing lists"

[Eliot Lear]

On 11/28/12 12:57 PM, Randy Bush wrote:
>> I'm increasingly seeing a "paradigm" where the review happens _before_
>> adoption as a WG draft.
> and one consequence is that the design gets done outside of the ietf
> process.
>

But this isn't necessarily a bad thing.  It's nice to have reasonably
well thought out ideas come in.

Eliot

Re: Common sense, process, and the nature of change

[Eliot Lear]

On 11/9/12 1:12 AM, Randy Bush wrote:
>> I don't know if there are cases where we've recently disagreed about how
>> much latitude to grant our leadership.
> iaoc/marshall
>
>

Not only did we not trust the leadership, but we also didn't trust the
plenary!  THAT has to change.

Eliot

Re: Common sense, process, and the nature of change

[Eliot Lear]

On 11/8/12 10:34 PM, SM wrote:
>
> Frankly, I don't know what the IETF is.
>

You are not the only one, and this needs to be fixed.

Eliot

Re: Recall petition for Mr. Marshall Eubanks

[Eliot Lear]

+1.


On 11/1/12 5:32 PM, Olaf Kolkman wrote:
> I also offer my signature under the recall procedure, in case
> pragmatism doesn't prevail (see my other note).
>
> My offer of signature should in no way be interpreted as reflecting an
> opinion about Marshall's character.
>
>

Re: [RFC 3777 Update for Vacancies]

[Eliot Lear]

Bob, everyone,

As I've mentioned, I'd prefer an alternative to what the authors have
written.  Call this the "let's program ourselves out of a paper bag"
option, when we all agree.  This may be a rule we would wish to
generalize.  Here is the basis for what I propose:

 1. We have existing procedures to resolve contested removals – the
recall process.
 2. "Uncontested" essentially means that we as a community are in
unanimous agreement that the position is vacant.  That means that by
definition, any "no" votes from a body means it's contested.
 3. The least amount of power should be delegated to our bodies as is
necessary for the organization's smooth operation.
 4. Procedural arguments on the IETF list are tiresome, when we all
agree on the right outcome ;-)

With that in mind, I've attempted to reduce changes to a more simplified
form, as follows:

In draft-ietf-genarea-bcp10upd-00.txt, Section 3.3, 2nd and 3rd paragraphs,

OLD:

   For vacancies due to uncontested, sustained absence, the IETF body
   making that determination will issue an Extended Last Call to the
   community.  The Last Call will explain the basis for declaring the
   position vacant and include a summary of efforts to contact the
   member to resolve the issue.

   The results of the Last Call are assessed by the IETF body, with a
   two-thirds vote of the body.


NEW:

When an IETF body unanimously believes that a position on that
body has been vacated, they may request confirmation of this by
the community through an Extended Last Call with their reasoning.
Should no objections be received during that period, the position is
said to be vacant.


Eliot

Re: [RFC 3777 Update for Vacancies]

[Eliot Lear]

On 10/26/12 4:29 PM, Michael StJohns wrote:
> I'm using "expulsion" here the way its used in the US political system - a 
> legislative body may choose to expel one of its members for various reasons.  
> I propose that we define such a mechanism for the IETF bodies.
>

Why should bodies have this right?

Eliot

Re: [RFC 3777 Update for Vacancies]

[Eliot Lear]

Bob,

I've read through the draft, and would prefer a different approach. 
Since we already have a recall procedure for contested removals, this
draft should focus itself on uncontested removals, and really just
*absense*.  How do you test if something is uncontested?  Easy enough:
ask the IETF community.  If a single person objects, let's call that
"contested" and go with the other procedure.

Eliot

On 10/24/12 6:14 PM, Bob Hinden wrote:
> The draft that proposes changes to the RFC3777/BCP10 to deal with vacancies 
> is now available.
>
>   http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00
>
> Bob
>
> 
>
> From: internet-dra...@ietf.org 
> To: i-d-annou...@ietf.org 
> Reply-to: internet-dra...@ietf.org 
> Subject: I-D ACTION:draft-ietf-genarea-bcp10upd-00.txt 
> X-C5I-RSN: 1/0/935/46939/50333 
>  
> A new Internet-Draft is available from the on-line Internet-Drafts 
> directories. 
>  
> Title : RFC 3777 Update for Vacancies 
> Author(s) : D. Crocker, et al 
> Filename : draft-ietf-genarea-bcp10upd 
> Pages : 4  
> Date : Oct. 24, 2012  
>  
> BCP 10 (RFC 3777) specifies IETF processes for selection, 
> confirmation and recall of appointees to IETF positions. It also 
> refers to the mechanism of resignation as part of a sequence that 
> moves a sitting member to a new IETF position. However it does not 
> more generally deal with vacancies created by resignation, death or 
> uncontested, sustained absence from participation. This update to 
> BCP 10 specifies procedures for handling vacancies. 
>  
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-ietf-genarea-bcp10upd-00.txt 
>  
> Internet-Drafts are also available by anonymous FTP at: 
> ftp://ftp.ietf.org/internet-drafts/ 
>  
>

Re: Exceptional cases

[Eliot Lear]

Andrew,

On 10/25/12 9:52 PM, Andrew Sullivan wrote:
> Oh, for heaven's sake. This is nothing to do with punishment. This is
> a straightforward administrative problem. Turning this into an
> opportunity to exercise a heavyweight and in fact punitive process
> would be an injustice. If the IETF has wound itself into such
> bureaucratic knots that we can't just make an exceptional decision in
> exceptional circumstances, we are in much worse trouble than I thought. A 

And as of yet nobody has challenged the need to remove Marshall.  We've
just gone off the deep end on process.  Yes, let's close the process
problem as Brian said in due course.  Let's also not rush through the
changes for all the reasons that John Klensin wrote, plus another: I
don't like the proposed approach, but that's for another message.

Eliot

Re: Just so I'm clear

[Eliot Lear]

On 10/24/12 6:23 AM, Doug Barton wrote:
> With respect, you haven't spent much time with either the ITU or ICANN
> if you think that 3777 is rigidly bureaucratic by their standards.
> This is one of those situations where we have to take our medicine. Doug 

There are actually very few ITU rules, and very many guidelines.  The
latter are the exact opposite of rigid, but subject to overturning by
Member States at any time.  I had thought that we were roughly the same
in that regard, so as to avoid a perversity.  We've had any number of
debates on this list about not creating process without a reason. 
Fine.  The price for that is that you have to deal with these sorts of
circumstances as and when they arise, using rough consensus as your guide.

Eliot

Re: In Memoriam IETF web page

[Eliot Lear]

Henning,

I like what you are suggesting, but let me add two things:

  * The ITU does something interesting for notable individuals, which is
that they offer a space on a web page to collect condolences.  Such
a virtual book could be then presented to the family, to mark the
important contributions an individual made.  Often times family
members have no concept of just how important a person has been to
their profession, nor how many friends that person REALLY had.
  * On the other side of the coin, I do wish we'd do a better job
celebrating the achievements of those in our community who are ALIVE.

As Dave might say, these two points are not mutually exclusive.

Eliot

On 10/22/12 4:52 PM, Henning Schulzrinne wrote:
> It is quite common for technical societies (and, I assume, other professional 
> associations) to note the passing of their members and contributors to their 
> field. For many, the IETF is the closest thing they have to such a society 
> and it is a key part of their professional and sometimes personal life.
>
> We sometimes seem to worry too much about scaling problems that never 
> actually occur; the discussion here seems to reflect one of them. I doubt 
> that we'll be inundated with grieving relatives of one-time IETF attendees or 
> IETF list subscribers who want their loved ones to be put on a web page.
>
> If we want to keep this in the spirit of long-established (newspaper) 
> traditions rather than a web page, we could use the IETF Journal for 
> recording the passing of members of the community.
>
> I also think that a longer list serves as a useful reminder that while we all 
> are indebted to the pioneers, the Internet was built by a much larger number 
> of people over the years, just like most human institutions.
>
> As the first generation of contributors reaches zero on their time-to-live 
> counter, this seems like the humane and professional thing to do, whatever 
> precise form it takes.
>
> Henning
>
> On Oct 22, 2012, at 9:26 AM, Pelletier Ray wrote:
>
>> On Oct 21, 2012, at 4:59 PM, Randy Bush wrote:
>>
>>> i started the thread on nanog.  i am not sure abha or jon would want to
>>> be on such a list.  remember them and honor and carry on their work,
>>> don't memorialize them.
>> With all respect, it is not just about the person, it is about their work, 
>> its importance, the history of this Internet and providing role models to 
>> others.
>>
>> Ray
>>
>>
>>> randy
>>
>
>

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Eliot Lear]

Hi John,

On 9/9/12 8:43 PM, John Levine wrote:
> Let's say I write to the IESG and say this:
>
>   Due to a late night editing error, draft-foo-bar-42 which I
>   submitted yesterday contains several paragraphs of company
>   confidential information which you can easily see are irrelevant to
>   the draft.  My boss wants it taken down pronto, even though he
>   realizes that third parties may have made copies of it in the
>   meantime.  I will probably lose my job if it stays up for more than a
>   few days.  Thanks for your consideration.
>
> Is this the response?
>
>   You didn't make any legal threats, and now that we know the
>   situation, we wouldn't believe any legal threats you might make in the
>   future, so you better check out those burger flipping opportunities.

No, the response is that we refer you to our policy.  As an open
organization we do not remove information once posted, except under
extraordinary circumstances.

>
> What was wrong with the original version which gave the IESG the
> latitude to remove an I-D if they feel, for whatever reason, that it
> would be a good idea to do so?  

What original?  The draft policy states:

> An I-D will only be removed from the public I-D archive in compliance
> with a duly authorized court order.


> If the IESG were so screwed up that
> they started deleting I-Ds for bad reasons, no amount of process
> verbiage would help.

Certainly, but let's not start from the wrong place to begin with. 
Let's also set expectations that the IESG may be used to clean up after
other peoples' messes.  They have enough to do.

And again, this is best developed with counsel.

Regards,

Eliot

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Eliot Lear]

On 9/7/12 11:33 AM, Stewart Bryant wrote:
> On 07/09/2012 07:49, Eliot Lear wrote:
>> An I-D will only be removed from the public I-D archive in compliance
>> >with a duly authorized court order.
> Would
>
> "An I-D will only be removed from the public I-D archive if legally
> required to do so."

That is where I was aiming, albeit with s/will/may/.  Again, I recommend
that Jorge review.  Nothing in this policy should REQUIRE the IESG to
act, or set that expectation.

Eliot

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Eliot Lear]

Ned,

We are venturing into an area of rabid agreement on the premise but
disagreement on the conclusion, which I find astonishing.

On 9/7/12 9:29 AM, Ned Freed wrote:


> The only question that need concern us at present is whether or not the
> stated policy gives the IESG the necessary flexibility. It seems to me
> that it does. 

Glad you think so, but then please enlighten the rest of us about how
the text provides this flexibility.

Eliot

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Eliot Lear]

Randy,

> so the iesg will now spend their spring retreat in law school? we have
> a test for competent legal demand. it is called a court order.

In the case of DMCA, if you wait for a court order, you can lose your
liability shield, which has been the point that Sam and others have
raised.  There may be times when the IETF is willing to do that (had the
IETF been hosting the TZ database, perhaps it would have done so), but
it should be done consciously.

Eliot

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Eliot Lear]

Randy,
On 9/7/12 8:35 AM, Randy Bush wrote:
>> The IESG's initial thought on this matter was that the bar for
>> removing things from the archive ought to be set as high as we could
>> get it so as to avoid all sorts of silly requests and DoS attacks
>> (and, at least in my mind, so that the legal questions were near nil:
>> unless an appropriate court forced us to, our policy was "leave it in
>> there").
> please stick to it.  we have enough complexity creation already.  aside
> from at&t and verizon illegally giving all our packets to the nsa, the
> high bar is the best and simplest.

I agree with your point about complexity and "sticking to it".  I
recommend a small change to accommodate most of what has been discussed.

OLD:
> An I-D will only be removed from the public I-D archive in compliance
> with a duly authorized court order.  If possible, a removed I-D will be
> replaced with a tombstone file that describes the reason that the I-D
> was removed from the public I-D archive.

NEW:

> An I-D MAY be removed from the public I-D archive in compliance
> with a competent legal demand.  If possible, a removed I-D will be
> replaced with a tombstone file that describes the reason that the I-D
> was removed from the public I-D archive.

This leaves sufficient flexibility for the IESG to decide when a legal
demand requires the removal and when it's bogus, but otherwise leaves
the bar high.  I would suggest that Jorge review the above text for
appropriateness.

I'll also point out that if people start to game us for illegal content,
the IESG has the ability to update the policy.

Eliot

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Eliot Lear]

Sam,

On 9/4/12 3:29 AM, Sam Hartman wrote:
> I strongly urge  the IESG to be significantly more liberal in  the cases
> where an I-D will be removed from the archive.
>
> I can think of a number of cases where I'd hope that the IESg would be
> cooperative:
>
> 1) the IETF recieves a DMCA take-down notice or other instrument
> indicating that a third party believes an I-D infringes their copyright.
> Forcing such third parties to take the IETF to court does not seem to
> benefit the community.

This is knotty.

ANYONE can file a DMCA take-down notice.  Following it merely provides
safe harbor and is not always in the community interest.  The community
was disrupted because of what amounted to a bogus DMCA take-down notice
relating to the TZ database, when the NIH complied.  The IESG should
give the people who posted the draft an opportunity to respond to the
take-down notice prior to taking any action.  In the case of a WG I-D,
the IETF must take a more engaged role.

>
> 2) An author realizes that an I-D accidentally contains proprietary
> information, infringes someone else's copyright, failed to go through
> external release processes for the author/editor's organization, etc.
> Obviously factors like how long after the I-D is submitted might need to
> be considered.

It's difficult to codify policy like this in a group this large, but
except for the copyright issue in which a 3rd party may be exposed
through no fault of their own, I'd be concerned about abuse, and would
hate for us to sanction that sort of thing in text.

Eliot

Re: New Version Notification for draft-leiba-3777upd-eligibility-01.txt

[Eliot Lear]

On 8/17/12 4:21 PM, Russ Housley wrote:
> The document says:
>
>  o  Bullet 15 is replaced by these two bullets:   
>   
> 15.1.  Members of the Internet Society Board of Trustees and  
>  sitting members of the IAB, the IESG, and the IAOC, 
> including
>  members in ex-officio positions, and not including liaisons, 
>  may not volunteer to serve as voting members of the  
>  nominating committee.
>
> I find "liaison" confusing here.  You mean liaisons to the IESG, IAB, and 
> IAOC.  You do not mean liaisons to the NomCom.
>
Or do you mean liaison managers and representatives as defined in RFC-4052?

Eliot

Re: FW: Affirmation of the Modern Global Standards Paradigm

[Eliot Lear]

Hi John,

On 8/15/12 2:15 PM, John E Drake wrote:
>
>  
> To me (and I speak only for me here), the purpose of this document is
> to articulate principles that have made the Internet a success.
>
>  
>
> JD:  This seems a bit presumptuous to me.
>

It's an assertion.  I wouldn't claim, by the way, that this was the only
factor.  IMHO, it was a contributing factor.  Moore's Law and the
development of technology in general all contributed, but you had to
have a process that was open for the technology to flourish.  IMHO this
is why SNA, DECNET, Appletalk, XNS, OSI, and others did not win, where
IP did.

>  
>
> It is a means to invite others to subscribe to those same principles,
> and there are many standards organizations that do not.
>
>  
>
> JD:  I would be willing to bet that nearly every SDO would claim they
> embrace these same principles.
>

And that's a fair point.  The proof is in the pudding.  I believe, and I
know you do too, that the IETF itself can explain in clear indisputable
terms how it fulfills the principles of openness.  Anyone can join a WG
list.  Anyone can submit an Internet-Draft, anyone can comment on that
draft, anyone can request that draft's advancement, anyone can comment
on or contribute to or object to that draft's advancement, anyone can be
a part of the leadership (one needn't even have ever participated in the
IETF before!!).  Decisions are made through a consensus process.  That
process is designed to be transparent.  There are appellate avenues for
abuse of process.  They have worked and are working.  I am told for
instance that at this very moment there is an appeal before the
applications area director that seems to me particularly meaty.  That's
good.  It's important that people know that there is an appeals avenue
available.

The W3C is very similar.  The IEEE SA is also similar.  So are others,
and that's fine.  But there are many other organizations where it's just
not the case, and so...

>  
>
> Customers and society can demand better, and this is an avenue for that.
>
>  
>
> JD:  How, exactly?
>

How about a phone call?  A blog?  A press release?  Laws and regulations
requiring the use of standards based on those principles?

Eliot

Re: FW: Affirmation of the Modern Global Standards Paradigm

[Eliot Lear]

John,


On 8/15/12 12:03 AM, John E Drake wrote:
>
> Hi,
>
>  
>
> Does this document actually have a purpose, and if so, what is it?
>
>  
>
>

To me (and I speak only for me here), the purpose of this document is to
articulate principles that have made the Internet a success.  It is a
means to invite others to subscribe to those same principles, and there
are many standards organizations that do not.  Customers and society can
demand better, and this is an avenue for that.

Eliot

Re: Last Call: Modern Global Standards Paradigm

[Eliot Lear]

+1

On 8/11/12 8:10 PM, Paul Hoffman wrote:
> On Aug 11, 2012, at 5:05 AM, Randy Bush wrote:
>
>>> The IETF Chair and the IAB Chair intend to sign the Affirmation
>>> of the Modern Global Standards Paradigm, which can be found
>>> here:
>>>
>>> http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf
>> no brainer.
> Even with a brain, the document is obviously good. Please sign it.
>
> --Paul Hoffman
>
>

Re: Proposed IETF 95 Date Change

[Eliot Lear]

I'd support a date change for IETF 95 but it should be the week of the
14th to take into account Palm Sunday and Good Friday.  As to Ramadan, I
too would like to understand if there is a need to take this holiday
into account, and what would be the practical way to do that?

Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC

[Eliot Lear]

All,

Based on this explanation from Scott I withdraw my suggestion.  Text can
stay as it is.

Eliot

On 6/8/12 9:46 PM, Bradner, Scott wrote:
> On Jun 7, 2012, at 10:20 PM, Paul Hoffman wrote:
>
>> On Jun 7, 2012, at 6:13 PM, Bradner, Scott wrote:
>>
>>> On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote:
>>>
>>>> On May 30, 2012, at 11:22 PM, Eliot Lear wrote:
>>>>
>>>>>   • It's probably worth adding a word or two about the fact that the ISOC 
>>>>> Board is the final appellate avenue in the standardization process.  In 
>>>>> this way it may also make sense to move Section 3.2.1 further back behind 
>>>>> the IAB.
>>>> I have heard that as well, but cannot find it in RFC 2026 or any of the 
>>>> RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It 
>>>> should only be in the Tao if we can point to where the rule comes from.
>>>
>>> see RFC 2026 section 6.5.3
>>>
>>> 6.5.3 Questions of Applicable Procedure
>>>
>>>  Further recourse is available only in cases in which the procedures
>>>  themselves (i.e., the procedures described in this document) are
>>>  claimed to be inadequate or insufficient to the protection of the
>>>  rights of all parties in a fair and open Internet Standards Process.
>>>  Claims on this basis may be made to the Internet Society Board of
>>>  Trustees.  The President of the Internet Society shall acknowledge
>>>  such an appeal within two weeks, and shall at the time of
>>>  acknowledgment advise the petitioner of the expected duration of the
>>>  Trustees' review of the appeal.  The Trustees shall review the
>>>  situation in a manner of its own choosing and report to the IETF on
>>>  the outcome of its review.
>>>
>>>  The Trustees' decision upon completion of their review shall be final
>>>  with respect to all aspects of the dispute.
>>>
>>> note that the appeal to the ISOC BopT is only if the claim is that the 
>>> rules are broken 
>>> not the application of the rules
>> Exactly right. What Eliot said, and others have said, is that the ISOC board 
>> is the "final appellate avenue in the standardization process". That's quite 
>> different than "the rules are broken".
> just to be clear - saying "final appellate avenue in the standardization 
> process". could be read as meaning
> that a appeal of a technical decision could be made to the ISOC Board and 
> that is not the case - 
> this is why I used different language
>
> not sure which you were supporting
>
> Scott
>
>>> there has never been such an appeal
>>
>> Happily noted.
>>
>> --Paul Hoffman
>>
>
>

Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05

[Eliot Lear]

Document: draft-ietf-intarea-ipv4-id-update-05
Title: Updated Specification of the IPv4 ID Field
Reviewer: Eliot Lear
Review Date: 2 June 2012
IETF Last Call Date: 31 May  2012


Summary: This draft is quite well written, and is *very* nearly ready
for publication.

This draft is well written, and from the applications perspective
represents an important step to improving performance and error
reduction.  It uses a new requirements call-out style that I would class
as experimental, but not bad.  It is worth people reading this draft and
deciding if they agree with Joe's approach.

Major issues:

None (Yay!).

Minor issues:

Section 4 needs to be reconciled a bit with Section 6.1.  Specifically:

>  The IPv4 ID field can be useful for other purposes. 


And

  >> IPv4 ID field MUST NOT be used for purposes other than
   fragmentation and reassembly.


My suggestion is to drop the above sentence from Section 4.

In Section 6.1:


>Datagram de-duplication can be accomplished using hash-based
>duplicate detection for cases where the ID field is absent.

Under what circumstances would the ID field be absent?

>>> Sources of non-atomic IPv4 datagrams using strong integrity checks
>MAY reuse the ID within MSL values smaller than is typical.

Is the issue really the source using strong integrity checks or the
destination in this context?  What is typical?

Nit:

Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3?


Eliot

Re: Last Call: (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC

[Eliot Lear]

Hi,

I agree with much of what Peter Saint-Andre wrote.  In addition I
suggest the following changes:

  * I've been told by some that the Mission of the IETF is in some way
out of date.  I don't know whether this is true, but if it is, the
reference should be removed.
  * It's probably worth adding a word or two about the fact that the
ISOC Board is the final appellate avenue in the standardization
process.  In this way it may also make sense to move Section 3.2.1
further back behind the IAB.
  * I don't know about anyone else, but my experience has changed with
regard to there being a "fair amount of time for socializing".  I
would say there is a modest amount of time for socializing.
  * The Tao mentions that we meet once a year in each region.  I don't
think that's true for Asia at this point.  The text might call out
that we meet where there are participants, or words that the IAOC
might provide.
  * The last paragraph in Section 4 is outdated.  Everyone uses wireless
these days– everywhere at nearly every meeting.
  * 4.12 really should be a top level section (moved further back).
  * Section 5 (Working Groups) really should be moved forward (after
Section 3 but before what is now Section 4).
  * Move acknowledgments to the back.  As it stands that text forms a
disconnect between the Intro and later sections.

Finally I have been told that the Tao is meant to be a living document,
e.g., a wiki.  Is that now not to be the case?

Eliot


On 5/31/12 12:56 AM, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'The Tao of IETF: A Novice's Guide to the Internet Engineering Task
>Force'
>as Informational RFC
>
> The Tao of the IETF has grown a bit stale.  For example, many of the
> tasks that were requested by email are now done with online tools,
> completely avoiding manual intervention by the Secretariat.  This is
> an effort to refresh the document.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2012-06-27. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>This document describes the inner workings of IETF meetings and
>Working Groups, discusses organizations related to the IETF, and
>introduces the standards process.  It is not a formal IETF process
>document but instead an informational overview.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ballot/
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>

Re: RFC 2119 terms, ALL CAPS vs lower case

[Eliot Lear]

On 5/16/12 3:59 PM, Barry Leiba wrote:
>
> It's probably worth having a discussion of all of that

Did you envision THIS much discussion?

Re: Proposed IESG Statement on the Conclusion of Experiments

[Eliot Lear]

Hi Adrian,

I do not support such a view, and it is not supported in a plain reading
of RFC 2026.  What's more, it's not how researchers work.  Researchers
naturally move on.  If we are looking to further push researchers away
from the IRTF, this is a good way to do it.

Whether or not an experiment is active is also not how research works. 
Sometimes work is taken up after years of gaps.  ILNP is a good example
of this.  Had 8+8 been published in a timely fashion as an experimental
RFC, we would have had obsoleted it, only to then unobsolete it?

Eliot

On 4/19/12 10:31 PM, Adrian Farrel wrote:
> All,
>
> The IESG has been discussing how to tidy up after Experimental RFCs.
>
> We have developed the following draft IESG statement. This does not 
> represent a change in process, and continues to value Experimental RFCs
> as an important part of the IETF process. It does, however, seek to 
> encourage documentation of the conclusion of experiments.
>
> We are aware that there may be other discussion points around 
> Experimental RFCs, and we would like to discuss these, but we also
> believe that there is merit in making small, incremental improvements.
>
> The IESG would welcome your thoughts on this draft before they approve
> the final text on April 26th.
>
> Thanks,
> Adrian
>
> =
>
> IESG Statement on Conclusion of IETF Experiments
>
>
> Experiments are an established and valuable part of the IETF process.
> A number of core Internet protocols were first published as Experimental
> RFCs while the community gathered experience and carefully investigated
> the consequences of deploying new mechanisms within the Internet.
>
> In the case where an experiment leads on to the development of a  
> Standards Track RFC documenting a protocol, the new RFC obsoletes the 
> old Experimental RFC and there is a clear conclusion to the experiment.
>
> However, many experiments do not lead to the development of Standards
> Track RFCs. Instead, the work may be abandoned through lack of interest
> or because important lessons have been learned.
>
> It is currently hard to distinguish between an experiment that is still
> being investigated, and an old experiment that has ceased to be of
> interest to the community. In both cases an Experimental RFC exists in
> the repository and newcomers might easily be misled into thinking that
> it would be helpful to conduct more research into an abandoned
> experiment.
>
> In view of this, the original proponents of experiments (that is, 
> authors of Experimental RFCs, and Working Groups that requested the
> publication of Experimental RFCs) are strongly encouraged to document
> the termination of experiments that do not result in subsequent
> Standards Track work by publishing an Informational RFC that:
>
> - very briefly describes the results of the experiment
>
> - obsoletes the Experimental RFC
>
> - if appropriate, deprecate any IANA code points allocated for the 
>   experiment
>
> - may request that the Experimental RFC is moved to Historic status.
>
> If there is no energy in the community for the producing such an
> Informational RFC, if the authors have moved on to other things, or if
> the Working Group has been closed down, Area Directors should author or
> seek volunteers to author such an Informational RFC.
>
>

Re: Last Call: (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

[Eliot Lear]

Tom,

I've let this sit a while, but wanted to respond on the following point:

On 3/6/12 4:25 PM, t.petch wrote:
> -ur responsibility is to ourselves first and foremost, and to see that
> our process is followed.  That process exists to, amongst other things,
> insure safe use and interoperable use of our own protocols.
> Which, Eliot, is where we part company.  Given the interest in and uptake
> of MPLS outside the original definition, we have a wider responsibility,
> as we have in, say, managing the IP address or domain name space.

If our process is broken, we should change it.  Our processes should
take into account that which *we* can control.  Making the best
recommendations for the use of our protocols on the Internet addresses
your point about the "wider community".  The IETF exists to serve that
wider community, but when others attempt to use our works in a way that
might harm our work, we equally have a responsibility to hold a line.  I
am NOT saying that in this instance, by the way, G.8113.1 harms IETF
work if a proper code point is assigned.  It would harm our work if a
code point was simply expropriated.



>   As
> with the last two, if we do not consider the needs of all parties, and not 
> just
> ourselves, we may lose our influence in these matters.  Yes we must follow our
> processes but in the interests of a wider community than just ourselves.

Were this really true, then we must reject this request because of the
likelihood of fragmented solutions that do not interoperate.  Is that
what you are arguing?

Eliot

Re: Issues relating to managing a mailing list...

[Eliot Lear]

Hi Russ,

On 3/15/12 12:46 AM, Russ Housley wrote:
> Some suggestions have been made about the IETF mail lists.
> There is a way for mailman to strip attachments and put them
> in a place for downloading with a web browser.  This would be
> a significant change to current practice, so the community
> needs to consider this potential policy change.
>
> What do you think?
>
> Russ


-1.  Offline readers would find it difficult to deal with such messages.

Eliot

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Eliot Lear]

John,

On 3/13/12 8:23 PM, John Scudder wrote:
> Re cache management schemes, I think that depends on whether you mean "system 
> level behavior" of a small-scale system, or one operating at large scale or 
> under some kind of stress. The earlier discussion notwithstanding, for 
> practical purposes caching is central to LISP; as such, it's a little weird 
> to say it's architecturally unimportant.

I don't think Joel is saying that it is architecturally unimportant, but
rather that within the architecture it various caching schemes may work
better than others, and that experience may dictate the answer to this. 
What are system effects, by the way, is its own interesting question.

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

Re: Last Call: (Allocation of anAssociated Channel Code Point for Use by ITU-T Ethernet basedOAM) to Informational RFC

[Eliot Lear]

Hi,

I speak now as an individual and in no other capacity with no other hats on.


On 3/6/12 11:31 AM, t.petch wrote:
> I am finding myself with some unfamiliar bedfellows on this issue, but yes, it
> should be approved - see inline.
>
>
> We claim ownership of the name space on behalf of all parties, all SDOs
> governments, NGOs, anyone and anything, and this gives us a special
> responsibility to exercise that wisely.  We should beware of imposing
> our ideas of correctness of any kind on another SDO - that is up to
>  them to decide, not us.

Our responsibility is to ourselves first and foremost, and to see that
our process is followed.  That process exists to, amongst other things,
insure safe use and interoperable use of our own protocols.

Here the process for approval of a codepoint calls for IETF review. 
That is this.  IETF Review is defined as follows in RFC-5226:

IETF Review - (Formerly called "IETF Consensus" in
[IANA-CONSIDERATIONS]) New values are assigned only through
RFCs that have been shepherded through the IESG as AD-
Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
intention is that the document and proposed assignment will
be reviewed by the IESG and appropriate IETF WGs (or
experts, if suitable working groups no longer exist) to
ensure that the proposed assignment will not negatively
impact interoperability or otherwise extend IETF protocols
in an inappropriate or damaging manner.

In addition, we have spoken on what it means for other SDOs to request
code points in RFC-4775 Section 3.2, which says, in part:


   Experience shows that the importance of this is often underestimated
   during extension design; designers sometimes assume that a new
   codepoint is theirs for the asking, or even simply for the taking.
   This is hazardous; it is far too likely that someone just taking a
   protocol value will find that the same value will later be formally
   assigned to another function, thus guaranteeing an interoperability
   problem.


Our processes direct us to consider a codepoint assignment in this
light.  Finally:


>
> There is no reason not to approve the allocation of a code point

The purpose of this review is to determine whether or not there is
reason *not* to approve.  Others disagree with you.


Eliot

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

Fwd: Re: [tz] Astrolabe dismisses suit.

[Eliot Lear]

Russ, Michelle, Elise, Kim, Bernard, Rob,

I'm passing along a note from JHawk that contains a press release from
EFF regarding the dismissal of the lawsuit against TZ Database
maintainers Arthur David Olson and Paul Eggert.  This lawsuit was wrong
from the beginning and disruptive to the volunteers and the industry. 
I'm very glad that Astrolabe has withdrawn it, and I'm thankful to the
EFF for their full-throated defense of Arthur David Olson, to you and
the IESG and ICANN staff, and to Rob Elz for having taken an active hand
(in Rob's case a VERY active hand) in seeing that this good work continues.

Eliot

--- Begin Message ---
The EFF issued the below press release this afternoon
with statements from Astrolabe.

--jh...@mit.edu
  John Hawkinson


Subject: EFF Wins Protection for Time Zone Database
X-RSS-ID: https://www.eff.org/rss/69783 at https://www.eff.org
X-RSS-URL:

https://www.eff.org/press/releases/eff-wins-protection-time-zone-database
Date: Wed, 22 Feb 2012 23:41:37 -
From: "Deeplinks: rebecca"

Copyright Lawsuit Threatened Essential Tool for Engineers Around the World

San Francisco - The Electronic Frontier Foundation (EFF) is pleased to
announce that a copyright lawsuit threatening an important database of
time zone information has been dismissed. The astrology software
company that filed the lawsuit, Astrolabe, has also apologized and
agreed to a 'covenant not to sue' going forward, which will help
protect the database from future baseless legal actions and
disruptions.

Software engineers around the world depend on the time zone database
to make sure that time-stamps for email and other files work correctly
no matter where you are. However, last September, Astrolabe filed a
lawsuit against Arthur David Olson and Paul Eggert -- the researchers
who coordinated the database's development for decades -- because the
database includes information from an atlas in which Astrolabe claimed
to own copyright. But facts -- like what time the sun rises -- are
not copyrightable. EFF, along with co-counsel Adam Kessel and Olivia
Nguyen at the Boston office of Fish & Richardson P.C, promptly signed
on to defend Olson and Eggert and protect this essential tool. In
January, EFF advised Astrolabe that Olson and Eggert would move for
sanctions if Astrolabe did not withdraw its complaint. Today's
dismissal followed.

In a statement, Astrolabe said, "Astrolabe's lawsuit against Mr. Olson
and Mr. Eggert was based on a flawed understanding of the law. We now
recognize that historical facts are no one's property and,
accordingly, are withdrawing our Complaint. We deeply regret the
disruption that our lawsuit caused for the volunteers who maintain the
TZ database, and for Internet users."

"It's a fundamental principle of copyright law that facts are not
copyrightable, and Astrolabe should have known that," said EFF
Intellectual Property Director Corynne McSherry. "While the lawsuit
should never have been filed, we're pleased that the legal threat to
an important resource has been eliminated.

"We are grateful that EFF and its co-counsel at Fish & Richardson were
able to step in and assist us, so that we could help ensure the TZ
database would continue to be available," said Eggert and Olson.

For more on this case:  
[https://www.eff.org/cases/astrolabe-v-olson][1]

Contacts:

Corynne McSherry  
   Intellectual Property Director  
   Electronic Frontier Foundation  
   cory...@eff.org

Mitch Stoltz  
   Staff Attorney  
   Electronic Frontier Foundation  
   mi...@eff.org

   [1]: https://www.eff.org/cases/astrolabe-v-olson

URL: https://www.eff.org/press/releases/eff-wins-protection-time-zone-database

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

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Eliot Lear]

Damian, others,

On 2/23/12 11:15 AM, Damien Saucez wrote:
> Hello Eliot,
>
> May I ask you why you say that LISP+ALT relies on caching?
>
> LISP+ALT is just a BGP based overlay, where is the caching
> there (is the BGP RIB that you consider as a cache?).

An investigation I ran looked at the possibility of doing a "push"
versus "pull" of the mappings.  It's not where the main LISP group went,
but it is possible.  To be fair there is still caching of state, but the
performance profile.  See draft-lear-lisp-nerd.

Eliot

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

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Eliot Lear]

On 2/20/12 9:06 PM, John Scudder wrote:
> Jari,
>
>
> 2. LISP relies on caching,

LISP-ALT relies on caching.

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

Re: ITC copped out on UTC again

[Eliot Lear]

On 1/23/12 3:27 AM, Michael Richardson wrote:
>>>>>> "Eliot" == Eliot Lear  writes:
> >> Can you tell me which protocols use future timestamps in an
> >> moving form (not stored at rest in a certificate in a DANE RR,
> >> for instance), which care about discrepancies of less than 1
> >> minute?
>
> Eliot> iCal, for one, which can be used for recurring events that
> Eliot> have nothing to do with computers.  Also relevant, would be
>
> Forgive me for being dense, but I don't understand how this is relevant.

You're right, but you asked the wrong, though.  To begin with, protocols
don't care about anything.  It's the people running the applications and
services using the protocols that care.  We can't say how iCal is being
used everywhere.  It is entirely possible that someone is using the
format for something akin to cron(8).

And as to the example you mention, let's look carefully:
>
> iCal, as far as I can understand, stores start/end dates in human form.
> For instance, from RF2445:
>  BEGIN:VTIMEZONE
>  TZID:US-Eastern
>  LAST-MODIFIED:19870101T00Z
>  BEGIN:STANDARD
>  DTSTART:19971026T02
   MMDD HHMMSS



Note the "SS" at the end.

I'll also note that the TZ database handles leap seconds but can also be
used to adjust against UTC in some way.  Note I'm not suggesting this,
and I'm really glad we have a few years to think about it.  Good time to
have the dialog, however...

Eliot

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

Re: ITC copped out on UTC again

[Eliot Lear]

On 1/20/12 7:13 PM, Michael Richardson wrote:
> Can you tell me which protocols use future timestamps in an moving
> form (not stored at rest in a certificate in a DANE RR, for instance),
> which care about discrepancies of less than 1 minute? 

iCal, for one, which can be used for recurring events that have nothing
to do with computers.  Also relevant, would be the POSIX 1003.1 TZ
offset variable that takes into account seconds.  I mention it because
it can be used to correct for seconds, should the need ever arise.

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

Re: ITC copped out on UTC again

[Eliot Lear]

Hi Phillip,

For those who are interested in the proceedings, they took place
yesterday at the ITU's Radio Advisory Group (RAG).  The United States
introduced the proposal to do away with leap seconds.  They were not,
shall we say, universally supported.  Those in favor were largely in
line with what you wrote below, Phillip.  Those opposed were not clear
that there really was a problem to solve, and wanted more time to
consult.  The matter was referred back to the study group for further
consideration, as well as broader consultation, and will be taken up
again at the next RAG (approximately two years from now). 

If you have a TIES account at the ITU, you can listen to the proceedings
by going to the following link and moving to time index 1:43:15 or so.

http://www.itu.int/ibs/ITU-R/RA12/links/1-20120119-1400-en.smil

Regards,

Eliot

On 1/20/12 3:20 PM, Phillip Hallam-Baker wrote:
> If we are ever going to get a handle on Internet time we need to get
> rid of the arbitrary correction factors introduced by leap seconds.
>
> The problems caused by leap seconds are that they make it impossible
> for two machines to know if they are referring to the same point in
> future time and quite often introduce errors in the present.
>
> 1) No machine can determine the number of seconds between two
> arbitrary UTC dates in the future since there may be a leap second
> announced.
>
> 2) If Machine A is attempting to synchronize with machine B on a
> future point in time, they cannot do so unless they know that they
> have the same view of leap seconds. If a leap second is announced and
> only one makes the correction, an error is introduced.
>
> 3) In practice computer systems rarely apply leap seconds at the
> correct time in any case. There is thus a jitter introduced around the
> introduction of leap seconds as different machines get an NTP fix at
> different points in time.
>
> 4) Even though it is possible to represent leap seconds correctly in
> standard formats, doing so is almost certain to exercise code paths
> that should be avoided.
>
>
> Since the ITU does not look like sorting this out, I suggest we do so
> in the IETF. There is no functional reason that Internet protocols
> should need leap seconds. 
>
> I suggest that the IETF plan to move to Internet Time in 2015,
> immediately after the next ITU meeting. Internet time would be TAI
> plus the number of leap seconds that have accumulated up to the next
> ITU decision point. So if UTC drops leap seconds at the next meeting
> the two series will be in sync, otherwise there will be a divergence.
>
>
>
> -- 
> Website: http://hallambaker.com/
>
>
>
> ___
> 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: Story: "Next battle over Net ramps up worldwide"

[Eliot Lear]

What this story refers to is the World Conference on International
Telecommunications.

DID YOU KNOW?

... that the Internet currently runs through a loophole in these
international regulations that were last amended in the 1980s?

... that there are some countries who would like to exert more control
over what protocols run on the Internet?

If you didn't know, perhaps you might want to engage with ISOC to learn
more about this.  Check out http://www.internetsociety.org/regulation.

Eliot

On 1/19/12 5:04 PM, Noel Chiappa wrote:
> For those who haven't seen it, here:
>
>   Next battle over Net ramps up worldwide
>   http://www.politico.com/news/stories/0112/71625.html
>
> is an interesting story, one which is also fairly accurate (often not true
> of major media stories about the Internet).
>
>   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: "class E" (was: Consensus Call: draft-weil-shared-transition-space-request)

[Eliot Lear]

Mark,

On 12/5/11 10:38 PM, Mark Andrews wrote:
> It's not that the CPE's can't renumber. The ISP are already using RFC
> 1918, in good faith, internally to talk to the management interfaces
> of modems so using RFC 1918 is forcing the ISP's to renumber out of
> whichever RFC 1918 block that is choosen for this purpose. Customers
> that are using RFC 1918 addresses, in good faith, are being force to
> renumber because the IETF is changing the rules retrospectively.

This overstates the case, or at least shows confusion over what we meant
by the term "enterprise" in RFC-1918.  I don't know about the other
authors, but I meant an enterprise that was an end user, and
specifically *not* a service provider.   Nevertheless, SPs *are* using
the space today.  That is the world in which we live, no matter what
1918 says.  What, then, is the best approach to deal with the conflict
(if it exists– see Rob Elz's note)?

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

Re: Consensus Call: draft-weil-shared-transition-space-request

[Eliot Lear]

Ralph,

Where we ran into trouble the last time on this was that the OSS systems
themselves that manage the edge devices needed to be able to actually
communicate with those devices using the reserved space (reachability
testing, what-have-you).  All that stuff runs on a variety of h/w,
including Linux, Windows, and other.  But if ops want to use 240/4, I
say have at it!  It's just sitting there, after all...

Eliot

On 12/1/11 2:06 PM, Ralph Droms wrote:
> On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote:
>
>> Randy,
>>
>>
>> On 11/30/11 6:09 AM, Randy Bush wrote:
>>>> skype etc. will learn.  This does prevent the breakage it just makes
>>>> it more controlled.  What's the bet Skype has a patched released
>>>> within a week of this being made available?
>>> cool.  then, by that logic, let's use 240/4.  the apps will patch within
>>> a week.  ok, maybe two.
>> As someone who tried to "Go There", I agree with you that 240/4 is not
>> usable.  It would be fine in routers in short order, as it's fairly easy
>> for ISPs to exert influence and get that code changed, but general
>> purpose computing and all the OSS systems are a completely different
>> kettle of fish.
> Eliot - in the case of Shared CGN space, I think all that's needed is for the 
> ISP routers between the CPEs and the CGN to forward 240.0.0.0/10 traffic.  
> Those addresses will be hidden from the rest of the Internet by the CGN on 
> one side and the subscriber GWs on the other side.  If this address space 
> weren't hidden, RFC 1918 space (e.g., 10.64.0.0/10) or a /10 reserved from 
> public IPv4 space wouldn't work, either.
>
> Those subscriber GWs would have to handle 240.0.0.0/10 traffic correctly, and 
> there would likely have to be some small amount of parallel RFC 1918 space in 
> the ISP core network for servers, hosts, etc.  Of course, I'm not an 
> operator, so I'd be happy to hear why I'm confused.
>
> - Ralph
>
>> But that actually supports the notion that we need to use a different
>> block of address space.  So does the argument that 10/8 et al are well
>> deployed within SPs. 
>>
>> You wrote also that:
>>
>>> and all this is aside from the pnp, skype, ... and other breakage.
>>> and, imiho, we can screw ipv4 life support.
>> To keep this in the realm of the technical, perhaps you would say (a
>> lot) more on how you think this would break IPv4?
>>
>> For the record, I'm of two minds- I hate the idea that the SPs haven't
>> gotten farther along on transition, and I also wonder whether a rapider
>> deployment of something like 6rd would be better than renumbering all
>> edges into this space.  On the other hand, that speaks nothing about all
>> the content on v4 today, and that's where the pain point is.
>>
>> Thanks,
>>
>> Eliot
>> ___
>> 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: Consensus Call: draft-weil-shared-transition-space-request

[Eliot Lear]

Randy,


On 11/30/11 6:09 AM, Randy Bush wrote:
>> skype etc. will learn.  This does prevent the breakage it just makes
>> it more controlled.  What's the bet Skype has a patched released
>> within a week of this being made available?
> cool.  then, by that logic, let's use 240/4.  the apps will patch within
> a week.  ok, maybe two.

As someone who tried to "Go There", I agree with you that 240/4 is not
usable.  It would be fine in routers in short order, as it's fairly easy
for ISPs to exert influence and get that code changed, but general
purpose computing and all the OSS systems are a completely different
kettle of fish.

But that actually supports the notion that we need to use a different
block of address space.  So does the argument that 10/8 et al are well
deployed within SPs. 

You wrote also that:

> and all this is aside from the pnp, skype, ... and other breakage.
> and, imiho, we can screw ipv4 life support.

To keep this in the realm of the technical, perhaps you would say (a
lot) more on how you think this would break IPv4?

For the record, I'm of two minds- I hate the idea that the SPs haven't
gotten farther along on transition, and I also wonder whether a rapider
deployment of something like 6rd would be better than renumbering all
edges into this space.  On the other hand, that speaks nothing about all
the content on v4 today, and that's where the pain point is.

Thanks,

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

Re: The death John McCarthy

[Eliot Lear]

Bob,

First, I share your admiration for John McCarthy (after all, who does
not?).  In that spirit, my understanding was that LISP was an homage,
and as such should not be viewed in a negative light.  You're of course
right that we do stand on shoulders– many.

Eliot

On 10/27/11 11:08 PM, Bob Hinden wrote:
> John McCarthy died a few days ago.  I won't try to summarize his 
> accomplishments myself but thought that the obituary in the NY Times was very 
> good:
>
>   http://www.nytimes.com/2011/10/26/science/26mccarthy.html
>
> "John McCarthy, a computer scientist who helped design the foundation of 
> today’s Internet-based computing and who is widely credited with coining the 
> term for a frontier of research he helped pioneer, Artificial Intelligence, 
> or A.I., died on Monday at his home in Stanford, Calif. He was 84.
> 
> In 1958, Dr. McCarthy moved to the Massachusetts Institute of Technology, 
> where, with Marvin Minsky, he founded the Artificial Intelligence Laboratory. 
>  It was at M.I.T. that he began working on what he called List Processing 
> Language, or Lisp, a computer language that became the standard tool for 
> artificial intelligence research and design."
>
> With his death, I have a request.
>
> I request that the relevant authors and IETF working group rename what it 
> currently calls "LISP" to something else.  To put it politely, the IETF 
> should be standing on the shoulders of the giants who have laid the 
> groundwork of the Internet, not stepping on their toes. 
>
> Bob
>
>
> ___
> 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: Last Call: (Complaint Feedback Loop Operational Recommendations) to Informational RFC

[Eliot Lear]

For the record, I tend to dislike pollution of the RFC series with PR
blurbs as well.  This having been said, I would be far more interested
in a discussion about the actual substantive content of the document.

Eliot

On 10/5/11 2:23 AM, Douglas Otis wrote:
> On 10/4/11 9:09 AM, J.D. Falk wrote:
 "About MAAWG
 >>  >> MAAWG [1] is the largest global industry association
 working against
 >> Spam, viruses, denial-of-service attacks and other online
 >> exploitation.  Its' members include ISPs, network and mobile
 >> operators, key technology providers and volume sender
 organizations.
 >> It represents over one billion mailboxes worldwide and its
 membership
 >> contributed their expertise in developing this description
 of current
 >> Feedback Loop practices."
 >>  >>  Could the PR blurb be removed?
>>> >  >  I think it's useful in this document.  People reading IETF
>>> documents
>>> >  aren't likely to know what MAAWG is, and a short paragraph doesn't
>>> >  seem untoward.  I'd agree, if there were excessively long text for
>>> >  this, but it's brief.
>> MAAWG will insist on keeping this.  The primary purpose, in my mind,
>> is to show that even though this wasn't written within the IETF it
>> was still written by people who really do know what they're talking
>> about.
> I agree with Frank on this issue.  The PR blurb should not be
> included.  If MAAWG finds removal unacceptable, they are free to
> publish the document themselves among their other documents.  MAAWG
> has a closed membership heavily influenced by ISPs and high volume
> senders.  The IETF has normally resisted this type of influence by not
> referring to specific organizations.  Such influence is not always
> beneficial from the perspective of many IETF objectives.
>
> -Doug
> ___
> 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: 2119bis

[Eliot Lear]

Frank,


On 8/30/11 12:15 AM, Frank Ellermann wrote:
> On 29 August 2011 23:36, Peter Saint-Andre wrote:
>
>> staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
>> long enough, I finally decided to submit an I-D that is intended to
>> obsolete RFC 2119.
> There are literally thousands of documents (not only RFCs, also W3C
> standards, etc.) with normative references to RFC 2119 (sic!) instead
> of BCP 14, and I see no compelling reason to render these references
> as "historic".

On the basis of this logic we wouldn't be able to supercede any of our
key RFCs.

> [...]

> How about trying an "updates 2119" and status BCP, where BCP 14 then
> consists of 2119 and 2119bis, and old RFC 2119 references are still
> okay "as is".

What ends up happening, then, is that we need Internet lawyers to
traipse through references.  I challenge you or anyone else here to list
all the process RFCs that update RFC 2026.  Let's not repeat that fiasco
with 2119.


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

Re: https

[Eliot Lear]

Bert, Tom,


I don't see this as being a matter of encrypting, but rather providing
verifiable information the community.  What's more, in as much as the
IETF is a trusted site by many, it's probably a good idea to have at
least some confidence that when you click on a link, you're not going to
get hacked.  Finally, the IETF designed this system, and if we don't
like the fragility, perhaps we should fix it.  There's a saying about
eating one's own dogfood.  After all, if we won't eat ours, why should
anyone else?

By the way, Tom, you're not quite right.  Mail sent out from the IETF
list (including this one and the one you sent to the list) is signed by
the IETF with DKIM.  Again, eating our own dogfood.

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

Re: Experiment for different schedule for Friday

[Eliot Lear]

On 8/22/11 11:24 PM, IETF Chair wrote:
> The IESG is considering a different schedule for the Friday of IETF 82.  The 
> IESG is seeking your input on these potential changes.
>
> The IESG would like to try a schedule experiment on Friday, using this 
> schedule:
>
>  9:00 AM - 11:00 AM - Session I
> 11:00 AM - 11:20 AM - Room Change and Cookie Break
> 11:20 AM - 12:20 PM - Session II
> 12:10 PM - 12:30 PM - Room Change Break
> 12:30 PM - 13:30 PM - Session III
>
> The IESG has already consulted with the IAOC because of the cost associated 
> with the additional food and beverage break.  The IAOC believes that the 
> additional cost can be managed without raising the meeting fee.

I think this is a good experiment to run as proposed.

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

Re: Why the IESG needs to review everything...

[Eliot Lear]

I don't have too much to say on whether the IESG is effective.  Our
standards production rate and the market uptake of same seems to speak
for itself.  I also don't have the numbers Dave is looking for either.

However, I would like to contribute my own anecdotal experience,
involving at least one draft from the person who kicked off this debate
(not you Dave or Brian).  I reviewed on behalf of the apps-area one of
the drafts he wrote and found a serious concern, and reported it.  He
ignored my review at his peril, and then complained when he got slapped
with a DISCUSS.  I don't know whether the AD based his DISCUSS on my
review or not, but clearly there was, at the very least, a substantial
disagreement.  What's particular egregious is that here we had a
cross-area expert review process that identified a problem that could
have been resolved without him wasting IESG time.  Instead, we are all
incompetent, and don't know what we're talking about, and the process is
broken.  It has not occurred to this guy that he might have made an
error in judgment.  In fact he made many.

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

Re: whine, whine, whine

[Eliot Lear]

On 6/21/11 7:20 AM, John R. Levine wrote:
>> San Diego is much easier to get to than Quebec City, since multiple
>> air carriers serve it.
>
> You can't fool me.  I've been to both.  Quebec is a lot closer, and
> the food is better.
>

Hey!  Then you haven't been to DZ Akins!
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Eliot Lear]

Hi Barry,

On 6/17/11 6:01 AM, Barry Leiba wrote:
> Yes... I'm actually very confused about the point of this document.
> It's documenting a URI scheme that's used ONLY internally, and,
> therefore, has no interoperability requirements.

Indeed.  That's a good argument to stop right there.

>   As best I can tell,
> the issue here is to let browser makers know what other browsers do,
> so that maybe new browsers will decide to do the same things.  That's
> fine, and that helps users have a consistent experience across
> browsers.  But it strikes me as Informational, not Standards Track.
> MUSTs and MUST NOTs seem completely out of place here, to me.
It seems to me we could simply inform IANA that about: is reserved for
internal use by a browser, and not to be assigned for other purposes,
and not to be exchanged between hosts.  Do we really need an RFC to do that?

Eliot

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

Re: draft-housley-two-maturity-levels-06

[Eliot Lear]

Martin,

I think you may actually be arguing for a 1 step process.

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

Re: Last Call: (Reducing the Standards Track to Two Maturity Levels) to BCP

[Eliot Lear]

Jari, and others,

I support this draft with the caveat that we can establish a set of
significant metrics that provide us an understanding as to the impact of
the change.

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

Re: Gen-art review of draft-lear-iana-timezone-database-03

[Eliot Lear]

Hi Elwyn,

Thank you again for the review.  Please see below.

> Summary:
> Almost ready for the IESG.  This is my second review of the document.  
>
> I suggested in the previous review that it might make life easier, 
> particularly 
> if an appeal was ever entered, if the document didn't use the RFC 5226 
> Designated 
> Expert mechanism but defined the role separately.  This hasn't happened but 
> the 
> distinction is now clearer.  To make it quite clear I would be inclined to 
> add 
> 'except as regards appeals against decisions of the Designated Expert 
> (see Section 5)' after [RFC5226] in the definition of TZ Coordinator in 
> Section 2.

I've adopted your above suggested wording.

> Otherwise there are a couple of editorial nits.   
>
> .
> Nits/Editorial:
> s3: s/policy policy/policy/ (repeated word)

Corrected.
> s8, first para: s/filling/filling the role/ (maybe 'post')

This text changed based on another review.

> s8, last para: s/TZ Coordinators/TZ Coordinator/

Corrected.
> s10: s/Elwin/Elwyn/ (thanks for the ack!)

Corrected and apologies! I hate when that happens to me!

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

Re: Last Call: (IANA Procedures for Maintaining the Timezone Database) to BCP

[Eliot Lear]

Hi Barry,

Thanks VERY VERY much for your detailed review.  I have accepted ALL of
your changes modulo one.  And to your comment:

On 4/13/11 1:30 AM, Barry Leiba wrote:
> COMMENT
> Because you just mentioned "key", meaning "cryptographic key", in the
> previous paragraph, it needs to be clear that these are not those.
>
I've changed the term key to TZ name, as suggested by Tony Finch.

> OLD
>actually is, or in case of historical corrections, was.
> NEW
>actually is (or, in case of historical corrections, was).
>
This is the one I would prefer to leave alone.  I try my best to avoid
parentheticals in formal work.

Again, thanks for your review!

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

Re: Last Call: draft-lear-iana-timezone-database

[Eliot Lear]

Hi Tony,

Thank you for your comments.

On 4/12/11 2:47 PM, Tony Finch wrote:
> I support this document. I have a few suggestions:
>
> Section 1: Is it worth mentioning that the reference code includes an
> implementation of the ISO/IEC 9899 C and IEEE 1003.1 POSIX time functions?

Added.

> Section 3: The term "TZ name" should be used instead of "key" in the
> update criteria, to avoid confusion with the cryptographic key mentioned
> earlier in the section.

Changed.

> Criterion 1 could perhaps be clearer. Do I understand correctly that the
> intent is something like "New keys are only to be created when it is found
> that the region a TZ name was envisioned to cover does not all follow the
> same set of timezone rules between 1970 and the present day." That is, the
> thing that must be "accurately reflected" is the scope of the TZ rule, not
> its name or anything else.

Thank you.  That term "scope" does make things considerably clearer. 
I've adjusted the text as follows:
> New TZ names (e.g. locations) are only to be created when the
> scope of the region a name was envisioned to cover is no longer accurate.

> Is it worth documenting the naming scheme here, or would that be unhelpful?

I think that probably goes too far, but could be convinced otherwise.
> Typo: "policy policy".
>
> Section 5: Should the document explicitly mention that rough consensus of
> the TZ list should also be used when considering an appeal to the IESG?

I believe the rules are clear, but others should comment.
> Section 6 and 8: The term "identity" appears whereas section 3 used "well
> known key". Is "identity" supposed to imply something more complicated
> than a key, such as an x.509 certificate?

I am leaving that for IANA to decide.  Right now there's nothing, so
anything would be better ;-)

Thanks again,

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

Re: IETF and APIs

[Eliot Lear]

Bob, Joe,

Given this viewpoint, what guidance would you give, then, to protocol
designers who are writing specifications?

Eliot

On 3/30/11 8:09 PM, Bob Braden wrote:
> +1
>
> Bpb Braden
>
> On 3/30/2011 1:11 AM, Joe Touch wrote:
>> Hi, all,
>>
>> Perhaps we're not talking about an API, or even an abstract API, but
>> just the "application interface" (or just "upper layer service"
>> specification).
>>
>> RFC793 is a great example that a protocol provides a service, and
>> that service needs to be explained - and that explaining it does NOT
>> need to be done in a specific language.
>>
>> Joe
>> ___
>> 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