============================================================
Minutes of the IETF66 Thursday Technical Plenary
July 13, 2006.
============================================================

IRTF 
----------------------------------------

Aaron Falk, IRTF Chair, provided the IRTF report (see slides).

Charlie Perkins asks about IRTF RFC publication.
Aaron: they will be experimental publications.  There is a track for 
these not unlike IAB publications.


John Buford, SAM RG co-chair, provided an overview of Scalable Adaptive 
Mutlicast (SAM)

Marshall Rose: What about AMT [Automatic Multicast Tunneling]
and now does it fit in?
John:  Was brought up this AM and was mentioned in the mbone.  We need
to make sure we don't duplicate effort.


IAB
----------------------------------------

The IAB came up to the front of the room.

Leslie Daigle, IAB Chair, provided an IAB update (see slides).
Particular attention was paid to the recently approved 
IAB document on next steps for considering Internationalized
Domain Names (draft-iab-idn-nextsteps).


Phillip Hallam-Baker: on idn names, the real basic problem is 
understanding what the DNS is for; we already have attacks against 
the DNS with the attack against the registered names.  We spend a lot 
of time whacking down the names similar to existing names 
security-(whatever) where whatever is legitimate.  The problem is
already there and idn just puts a teaspoon full of hot water into 
a bath that's already too hot.

Leslie: this doesn't solve all of them, and a lot of the problems 
stem from conflation
Patrik Faltstrom: exactly what you are bringing up is something we 
have covered, intention is to cover exactly what you are saying.
John Klensin: we could spend a long time quibbling about the 
fraction of the help, all of these things are overloading DNS with 
things DNS will never do well.  None are new but bigger or more.  
There are a lot of decisions in the user community that a lot of 
us deeply regret, but that will never go away.  Some of this will
make things slightly better.  Looking at what the idn things are 
doing to us have uncovered other things that are crawling out from 
other the rocks? How do we migrate more smoothly from one version of 
unicode to another.  There's a problem area here and we could look 
at it as how we revisit internationalized carriers.
Patrik: agrees with Phillip, hope we've covered.

Stewart Bryant:  re: RFC editor doc.  The text is far less liberal 
than RFC2233.  Since the SOW will end up as the basis of a contract, we 
need to guarantee that the nature of that contract doesn't make 
things financially excruciating.
Leslie: draft SOW available;  it is the SOW that will be in effect for 
the duration of the contract.  The contract in place for
a couple of years will not be the defining character for the RFC editor.
Stewart: it needs to be at least as liberal as 2233
Brian Carpenter: SOW will be updated dynamically in the coming days.  
It's levering off the techspec doc.  The latest version, the text 
has been changed, but there is a sneaky little etc. intended to not by 
any means limit the scope.
Eric Rescorla: there is standard procedure to bid it out and set aside 
some slush in the budget to publish

Ted Hardie: one of the issues was appeals.  IESG is the first line of appeals 
because we're the ones that made the mistake.  Are appeals taking up too 
much of your time?  Would you consider moving to an appeals board.
Eric: they take up a lot of time, but it's an important responsibility.  
Part of the nomcom process is a recognition that the IAB handles appeals.  
Not the right time to think about that yet.
Kurtis Lindqvist: having nomcom select yet another group of people, it's just 
extra work and doesn't help
Brian: IAB has oversight of standards process and it's hard for the 
IAB to be off the hook for appeals.
Leslie: in my experience there hasn't yet been one that wasn't instructive 
at some level, reviewing process, and helps us learn
Patrik: if we have so many appeals we have something considerably broken
Lisa Dusseault: perhaps the IAB should be the first line of appeals.  
Since IESG is the group that most often makes the decision getting an 
appeal, it doesn't appear as fair to people knowing the IESG as it 
could be.
Olaf Kolkman: the whole structure of the appeals is always based on peers 
judging peers.  If we did another board it would be peers also.
Leslie: sometimes appeals get resolved in the IESG and they don't always 
come to the IAB.  Process is focussed to be on the constructive.
John Klensin: two observations.  Focus is not to be on judging.  An appeal 
to the IESG about an IESG action is to get the IESG to look at an 
issue in another way.  That's the way things are supposed to be 
working.  2)The last several months have demonstrated the potential 
for people who are not active participants in the process of
getting things done around here (although they are participants in 
hanging around) launching attacks on the process.  Maybe we should 
consider applying a damper to such actions.
Eric: very reasonable; discourage appeals for substantially the same 
cause, find balance
Brian: dislikes appeal, maybe call it dispute resolution.  We need to 
keep people from appealing over and over again.
Bernard Aboba: one of the things you learn is that you have to read 
and hope to understand what our standards process is and it's not 
as easy as you might think.  DoS may be caused by one or more of 
our rules.
Scott Bradner: it's not always the IESG that is being appealed.  We 
have had appeals for WG chair actions.  As the editor of the doc, 
the reason that a process was in RFC2026 was without it, we 
weren't going to be insured.  All SDOs require an appeals process.  
A single stage appeals process would be frowned on not only by
other SDOs but also by insurers.  We need an escape valve because 
otherwise we're seen as unfair.
Phillip HB: concern similar to Scott's but not insurance but litigation.  
An external lawsuit would suck up a heck of a long time.  A single 
stage appeal would not be viable.  Upper level courts have met the 
challenge by having smaller subcommittees to hear a specific appeal.  
And think about vexatious litigants, if you appeal too many times 
you can get kicked out.
Leslie: subcommittees can help but the whole IAB has to achieve 
consensus support.
Dave Crocker: no one has challenged whether we should have a process; 
if you don't like appeals, maybe you could call it the DISCUSS process.  
The nature of how these things always get handled has always impressed me.
Have been worried about abuses of the appeals process.  Klensin has a 
handle on a control mechanism that makes an enormous amount of sense in 
the context of IETF models of rough consensus.  No one of us that 
important, but a lot of us are very important.  If an appeal is worthy 
of being made, then relying on one person making the appeal doesn't 
make sense.  If the appeal is worth making they should be able to 
convince someone else to make it.
Olafur Gudmundsson: anything that can be done to slow down appeals, 
(suggestions) it should be done.  People have figured out you can 
slow down the process a lot through threatening or executing an appeal.
Eric: we have filibuster options, but it's better than the alternative
Lixia Zhang: I think we've spent enough time on appeal, I'd like to spend 
some time on a different topic.
Steve Bellovin: I've been appealed against, I'm likely to be
appealed against.  I'm very concerned about the fairness of the process
especially at the IESG level.  There might be a fair amount of truth
in an accusation of cronyism.
There is a perception and arguably a reality of unfairness and it's broken.
Leslie: the IESG has been beating us up for going off and considering
appeals in our own dark closet.  Go through the appeal in some depth on
our own.  We do overturn IESG appeals.  The concern about possible cronyism
is fair; but there isn't a lot of actual problem evidenced to date. 

Henning: Given that the IAB had a workshop I'd like to hear some sampling 
what members of the IAB thinks the 5 years out most pressing problem this 
organization needs to solve.  Net neutrality, ....
Eric: internet is rising in importance at an incredible rate, so 
organizations and governments pay a lot more attention to us; trying to 
make the case that the kind of interent we've always thought was 
attractive is the kind of internet that should continue to exist for 
the next 5 years 
Lixia: scalability of today's routing system is a fundamental challenge.  
Not a new problem.  At the first IETF we had two hard problems - 
congestion and routing.  Congestion solved itself, but the routing 
problem is still there and getting even much more difficult.  The 
network has changed and changed substantially.  We now have a
new problem - security.  And to solve that requires a good understanding 
of the naming system.  Routing scalability, naming, and security.
Bernard: we had an unwanted traffic workshop.  Came in thinking the internet 
had a serious security problem and came away saying I'd underestimated 
the problem.  Something simple like ingress filtering is good, but 
in many of these things you need 100% coverage to prevent attacks from 
one part of the network against other.  What do we do with backup plans to 
cover that.
Sam Weiler: a premise that is disturbing - this organization or others have 
a particular responsibility for solving problems.  This organization is 
more of a place to add value.  How can we make this a better place to
bring your work.
Dave Oran: challenges for the next 5 years.  Over the last 20 years we've 
seen a few fairly dramatic shifts.  Email, then shift to web, then 
VoIP (got people nervous), and now we're seeing a phenomenon that would 
be better to understand.  We have apps now that have no known upperbound 
on their traffic generation capability.  This is not throttled by any 
human interaction time.  Adding bandwidth doesn't make the problem 
better, and arguably makes the problem worse.  This is a very big 
challenge for the future.
Dave Thaler: wrt edge challenges.  Problems that start from naming/addressing 
that are caused by firewalls, etc.  There are other issues related to 
mobility and multihoming.  There are also problems with a lot more 
people doing different things now than we had years ago.
Brian: yes, we need to make the IETF a good place to come and do work.  
Isn't the IAB the place where people are thinking about longer term 
issues?  Yes, there is the old question of transparency.  Things can talk to
things despite the need for security/firewalls/etc.
Lixia: what lessons have we learned from our past mistakes?  It would be 
worthwhile to look back and see which ones are good and got widely deployed.  
One of our protocols hasn't gone anywhere.  Network management is very 
important.  How can we prioritize all of these seemingly important.
Scott Bradner: at the last IAB plenary, should the IAB look at some of the 
kinds of issues that Eric just brought up, along the lines of RFC 1984.  
There are important issues that aren't concrete.  Not sure that 
routing is going to be important if the FBI succeeds in rearchitecting 
the internet.  Think the iAB is being a bit derelict.
Leslie: when we figure out how to say something useful on this, we will 
say it.  How can we engage in this debate in ways that are not covered by 
people who are dedicated to it, and avoid the trap on particular nation's
policies.  
Scott: Not just net neutrality, Eric's topics are all important, need IAB to 
look at them
Eric: We're better equipped to handle some than others.  1984 is a good 
example of what we are well equipped to do, if things are fundamentally 
technical.  When it drifts into economics and society it's a lot 
harder to do.
Bernard: certainly there is a concern that the IETF should be more 
concerned about privacy.  Some of the protocols that we have designed 
do not take privacy into account.
Aaron: the Internet has grown up in size, usage, and value; and so it 
has attracted the interest of money and governments, and it has taken 
the interest of criminals also

Spencer Dawkins: remember Steve Deering's talk on the IP layer being 
the waist of the Internet.  Does the IAB see any end to the increasing 
complexity to the network protocol stack.
Lixia: motivation to examine all the protocolss so far.
Kevin Fall: infocomm presentation on widening waist.  It seems like things 
are getting taller, with 7, 8, or 9 levels of encapsulation.
Elwyn Davies: utlimately it's a challenge to you in the community to 
work smarter.  Complexity could be a sign of laziness.  Some interesting 
things in securing routing that are clever suggestions.

Michael Richardson: what I'm expecting the IAB to say about net neutrality.  
My impression of the whole problem is that if the protocols in '98-'00 for 
QoS had been successful then none of these problems would be coming up.  
Policy control would be in the hands of the right people.  We had a 
failure of deployment to QoS to the end user, and that's what
it's all about.  Expects the IAB to explain publicly this is how you 
ought to do this and this is how you should expose these to the end nodes.
Kurtis: it is far more than technical, very little about technology much 
more about money flows.  No previous technical model would stop the net 
neutrality debate.
Michael: users don't get the feeling that they are involved in the control 
of their own neutrality
Kurtis: 98% of end users don't care.
Dave Oran: agree with both Michael and Kurtis.  Much of the Internet model 
was providing bandwidth services to organization that then doled it out.  
Roll out to consumers at interesting amounts of bandwidth is a reasonably
new phenomenon.  They were sold things the SPs didn't actually have.  
Since they don't actually have that the SP's have to take draconian 
measures against the users who think they can have what they thought 
they bought.
Eric: SPs want to leverage their monopoly on the wire, and none of the 
technical things will help.
Dave Crocker: reasonable role the IAB might play in policy.  EKR 
characterized things extremely well, a compelling and necessary role for 
the IAB.  We've seen the way public discussion can be swayed by folks 
who are extremely clueless.  The IAB being proactive would be a very 
significant community contribution.  An example on neutrality
(distinguishing senders or receivers), where someone lives isn't tech, 
whether some kinds of service requires more is worth noting.
Pete Resnick: agree with worry that NN are layer 8 and 9.  These folks 
also make layer violations and they travel down into the technical layers.  
It would be perfectly okay for the IAB to write a big financially messy 
document and gave it to the ISOC, let them trim it of financial and 
political and then send it to the world.
Tony Hain: think about the failure of the QoS technologies to the end user.  
We need to step back and think about it so we're on the right track.  
We think about it as piece parts, not a whole system.  Would be good 
for the IAB to think about the systemic problem and see if there's a 
common value and move forward.
Mark Baugher: re: we should architect our protocols for privacy.  That's 
probably not the right approach.  Encryption or technical measures is not 
going to protect us from governments that want to surveil us.  We should
engage in policy.
Bernard: it's not only governmentt though.  It's amazing how much you can 
find out about people just on traffic just in this room.  Everytime you 
log into a network info is leaked into your location.  In the mid 90s 
we weren't thinking about that.  Service discovery protocols are similar.  
That wasn't a concern at the design.
Eric: not an I* role to take a position on the activity of the FBI.  We 
can say that if you design a system to do something, these are the 
implications, and do you really want to do that.
Spencer: IAB was doing some work going to NANOG talking to people about 
shim6.  Did that morph into the routing and addressing workshop?
Dave Meyer: We had planned to do routing and addressing the whole time.  
While I thought we were getting good info, there were conflicts between the 
IAB and the shim6 working group chairs and it turned out to be controversial.
Leslie: it did inform the IABs decision to undertake the topic for the
workshop.
Dave Meyer: we got positive feedback from the operator community.
Phillip HB: on the issue of policy, the IAB should be very careful not to 
make policy statements unless there is a really overwhelming consensus of 
the organization behind them.  Internet crime is bad.  It's hard to do
anything like that with NN.  If a person is paying $$ for 1mb/s and they 
need 20mb/s for some time at a higher cost, there should be a means.


Independent Submissions Community
Discussion
----------------------------------------

Olaf Kolkman presented an overview of the current discussion,
being held on independent@ietf.org.  (See slides).

Allison Mankin: it seems like you are not treating RFC3932 as a process 
document; we as a comnunity generated that doc too 
Olaf: the goal is not to generate something different, in conflict; but
rather to find a way to progress and make the changes to 3932
to accommodate independent; make sure that the doc now and the process 
which we change those goes forward
Leslie Daigle: it's important to keep in mind, there is no intention to 
disrespect 3932, the reality when you look across the community, may not 
match with what's in 3932 
John Klensin: draft-klensin-rfc-independent does not reflect what is being 
done today; proposes changes that bring things into line with what we are 
trying to achieve
- the editorial board process is a little bit different than it exists today
- some fine calibrations
- some minor differences in the way reviews get accomplished
- some issues with 3932 on how much control you give the IESG
Ted Hardie: didn't say that SDOs outside the IETF care much what status 
the RFCs carry.  Why don't we create a short document for the RFCs, do you 
make a distinction between IDs and RFCs, what about within RFCs?  And see 
whether you get back from that community.  Recommendation to address issue 5.
Scott Bradner: The ITU took this into consideration in their doc.
Donald Eastlake III: a user of independent, it has varied and all the 
variations have been accessible and extremely useful.  Always agreed when the 
IESG has felt a review was needed.
Thomas Narten: the discussion is a bit more nuanced;  one example of 3gpp 
- wanted an RFC, no working group, but did want IETF review of the doc, 
ended as informational.  Many want an RFC they can cite, but often want 
some review.
Rohan Mahy: if it's through RFC last call it should be called an RFC, if not 
propose the name PUB.
Olaf: this is for later.  Important, related, but we are working on 
process now.  

Referred to independent@ietf.org for further discussion.