The offer from CNRI to pay for the retreat logistics was considered, but the sense of the room was that it was more in the spirit of the IETF community if each participant paid for his/her own meals and share of meeting rooms. Randy Bush offered to handle the collection of money.
Naming occurs at multiple levels of the stack, in very many different forms (MAC address, IP address, DNS name, URI.....)
When we want communication, we usually have issues with translation between the layers; we cannot use the identifiers from one layer directly to operate at another layer.
Example: SIP - two systems may be able to communicate using URIs, but unable to communicate using IP addresses (because they are in different NATed networks).
Allison: One tool to help stuff along is the "soft state" concept - keeping information in the least translated form, but caching the information from (expensive) translations for performance reasons as long as reasonable, instead of starting to use the translated information in the protocol exchanges ("hard state").
Thomas: Very real issue - problems when resolution at one end does not give the same result as resolution at the other end. We need to agree on which namespace we are using.
Steve: even when namespace is the same, one can get into situations where A can talk to B can talk to C - but A cannot talk to C.
Ted: The IRI proposal from W3C is an example - carrying identifiers between
naming contexts without any way to identify which context it belongs to.
The context in this case is figuring out which character repertoire an IRI
belongs to.
XML has a character repertoire identifier - but the side of a bus does not.
James: The example of the dancing turtle (which can be seen on IPv6 and not on IPv4) is an example of a referential integrity problem: the transport chosen shouldn't influence the resource identified.
Harald: The problems often pops up when we change or extend the semantics of namespaces - like Net-10, IDN or 4-byte AS numbers
Charlie: What's the goal of the discussion? A document? Awareness in this group?
Leslie: "Identify problems that fit into this category, and develop a shared awareness of them between us".
Bert: Example from SNMP - usage of ifIndex for indexing tables - which is not required to be stable across reboots. ACLs can point to them, even. Moral: Need to consider stability of identifiers when one designs references to them.
Randy: Example from ops - nic-handle integrity across registry databases
Steve: Warts & mutations occur because of real-world needs; we spend time inventing anycast addresses in any namespace that we invent.....
Rob: we should do better the second time around....one problem is that the applications are generally trying to ignore what they can get away with...
Leslie: inference of context is a game for everyone - we tend to do it a lot, and sometimes mess up.
Bert: SNMP ifIndex instability hasn't been a problem yet - but could be.
Charlie: at one point reversibility of the mapping DNS name <=> IP address was assumed. And then people found all the cool things you could do with the fact that the symmetry was not enforced.
Sally: When we are designing namespaces, we should try to anticipate the fact that people WILL abuse them.
Rob: We designed applications that assumed end-to-end connectivity - and then people created a world where things did not work that way.
James: The tussle of the real world should not be ignored - but we should be able to modularize the tussles and create a level playing field.
Mike: IDN - we are changing DNS because of the needs of the end user, not because of the needs of the technical infrastructure. That's a political decision - because what the requirements are varies hugely with the viewpoint of the person making the requirement.
Ned: Ignoring the first reason - once we decided we were going to do IDN, the question of exactly how we were going to it became hugely politicized.
Allison: Fred talked about classifying packets - how do we know "what" it is when port numbers are either hidden or not relevant? Fred - "it's related, but a bit far afield"
Ted: BGP communities are a locally scoped namespace where a few values have turned out to have global scope (....arrgh). In the IETF, a huge amount of effort is spent looking at backwards compatibility. We should think about whether that's always the Right Thing - example: internationalizing the "presentation element" while making the <protocol element> backwards compatible.
Mike: Using my definition of political, we don't mean that political = bad; it's an externally driven force for change that DOES need to be considered in the IETF process. (Leslie's reformulation)
Randy: Backwards compatibility - There's a difference between "the new has to interoperate with and extend the old" and "the new has to not break the old". IPv6 is an example of something that doesn't break IPv4, but doesn't interoperate (out of the box).
Aaron: there's no reason why protocols should be value neutral, even when it allows multiple ways to do things. (...more comments lost...)
Leslie: Backwards compatibility - if you translate from old to new, it's easy to get a situation where you can't map back to the old...and build systems based on the assumption that translations are reversible.
Erik: Different problems - 1 is you get there or not; 1 other is you can get to 2 different places based on where or when you start out. The last one is the dangerous one.
Rob: The dancing turtle is a special case - people WANT to know the transport they are using, and the turtle shows them that.
Patrik: An url saying "the weather here" is intentionally (geoloc) context dependent. An url saying "the weather in half moon bay" shouldn't be.
Erik: No matter what kind of referential integrity you have, you ARE going to get paradoxes. That's the bad news; we're going to have to be ad-hoc. And we're going to be surprised.
Leslie: How do we translate this into concrete advice for protocol developers?
Harald:
- Name (and understand) your namespaces
- Don't use more of them that you have to
- Expect people to mess up
Thomas: Understanding them is good too.
Erik: Should we try to limit the number of ways in which people try to translate between namespaces?
Rob: Communication depends on having the ends of the conversations having enough shared context to do sensible resolution of names. Don't surprise the user by creating context the user doesn't know about. And - are the contexts that we're using isomorphic, or do they overlap in messy ways?
Bert: Should we not be "liberal in what you accept"?
Erik: liberality and controlled evolution is NOT the same thing.
Steve: The criticality flags are a typical way to address this issue. The sender telling the recipient whether or not to be liberal.
Ned: That's another thing where it's very interesting to watch what happens..... often the result is implementations that ignore critical extensions.....
Ted: The choice of transport should not affect the context for the delivery of service at higher levels - the dancing turtle is a diagnostic tool to reveal the transport used.
Randy: This principle probably extends to mappings in other contexts.
Allison: OPES referential integrity (didn't catch that)
Sally: OPES doesn't say the same thing - wants to allow "regional intermediaries". If you do that, you have to make clear that this is happening, and where the "base" is.
Rob: OPES is then about being able to detect & validate your context? Sally: Yes....
Bert: Example - access control based on where you came from and what authentication you have done.
Mike: Perhaps we're starting to reduce this to two statements - "Referential integrity is good" and "If you need to violate it, you should explain the benefits". (As part of document creation process?)
Ned: And when you do violate referential integrity, consider how this may lead to violation of the principle of least surprise.
Leslie: Credentials are context. But an user should be able to get the same result twice. Intermediaries that are not under endpoint control can make it difficult to achieve this.
Randy: Lots of different factors seem to affect what I get - where, who, when, authentication provided....
Steve: Bert's entryport/protocol-based access control can be considered an optimization.
Harald: it's dark in webspace.....let's go back to designing protocol.
<<<silence>>>
Leslie: Example of problematic protocols is FTP - using both IP addresses and DNS names. Hardly a new problem.
Randy: What's the takeaway?
Leslie/Ned: naming context (as exemplified by IRIs) is important, and often hard to transmit
Eric: URIs carry a LOT of implicit context in them. Example: https: URIs depend on TLS mechanisms to not be pushed below a certain security - and when that's not high enough, we have a real problem.
Allison: Apps namespace has a lot of established practice - and a lot of things (SRV, URN, E164....) that are under development. Would be good to capture some good practices in IAB guidelines - including common mistakes made.
Steve: Protocol design is going to be tough engineering decisions between competing imperatives - sometimes the ideal naming system is going to lose out.
Leslie:
Followup from this section:
- Revisit the i18n document
- Support Patrik & Fred's short "naming" document
- Potentially follow on with a longer "guidelines &
considerations" IAB document
---------------------
Some advice for protocol designers....
- Name (and understand) your namespaces, and the nature of the context that
qualifies them
- Define the necessary context, and consider the possibility of transferring
information about them
- Document how to translate between namespaces in this context
- Don't use more of them that you have to
- Don't use them for multiple incompatible purposes at the same time (FTP IP
addr example)
- Consider the inevitability of namespace properties changing
- Expect people to mess up
The last point is a tautology. It is, however, necessary to consider.
Allison Mankin introducing. <<<<presentation link should go here>>>>
A lot of participants, many of them "young" - both from the IETF and the "telephant" side.
"The downturn has probably eased off somewhat on the pressure on the area"
"Most of the technology in IP Telephony is IETF technology."
Some discussion of the number of things inside, for instance, H.323 - it's
overlapping functionality with "SIP + a little", says Allison.
"We should firmly standardize our protocols' telephony uses, like any
other use".
There are national variants (ITU, ANSI) doing "national versions" of
SDP - horror! - "I didn't think it was easy to get that wrong - it's a more
disciplined protocol than SIP".
Example: "Network Asserted Identity" - Authentication based on
connectivity - "Trust Domains" - necessary for
"telephony-like" trust models. 3GPP people were quite surprised at
what the IETF people were surprised at in their proposals.
A discussion of "authentication" meaning "cryptographic
authentication" or "verification of identity" - Mike/Steve don't
think it is necessary to force the "authentication" word out of the
document. "They have a surprising lack of documentation of the risk model
in their document."
Not trusting the end-user at all. "Not a node in the network".
AAA is a problem because of the end-user problem.
Some discussion of proxies and redirects. Proxies cause big security problems.
They have a certain business model; we will need to show how to support "their" business model using "our" technology. We have gotten to talk to the equipment providers, but far less to the service providers. 3GPP, ITU SG11 are in movement towards making requirements that are more compatible with the Internet way (but don't always want to admit it). Need to spend more time with them to continue the process.
Intercept is a problem. They want to reject the use of S/MIME encrypted setup because placing wiretaps is a requirement. Belief in the use of laws rather than technology to protect the end-user against unlawful intercepts. "Suggestion: bring Bill to the meeting with dsniff"....
Fred: "Could we stick to reality, please? They're not going to reject
encrypted data - they'll go back and ask the user to decrypt it."
Allison: "3GPP are adamant that they won't allow S/MIME encrypted setup
objects"
Rob: Two separate issues - what the law will do (Fred's) and what the vendors
want to not risk not having it available if the police asks for it.
Fred: US/rest of world difference: In US, tap phone & data under different
laws; in rest of world, taps are on people.
Randy: "The LEA agencies, service providers and their vendors will gain clues at varying rates. That doesn't mean we should find the worst of them and satisfy their goals."
Michael: Important phrase of the law is "reasonably available".
Voice switches are required to have taps. Not yet on data.
Allison: We seem to have little to do wrt changing the protocols - others are
coping with the protocols as they are.
Fred: Cisco is going to release its wiretap MIBs & protocols as info RFCs.
Michael: PacketCable mess: "VoIP is fine as long as you don't apply QoS to
it". Duh!
Use of IP telephony is also getting to be done inside the PSTN. That's one reason why "they" think that it's natural to move SIP development inside the telephone-standardization community.
A nice picture of the relationship between the Internet and the PSTN with different examples of calls originated and terminated in various domains - see presentation.
also dragging in ICANN.
Has been talking to a number of people - Scott Bradner, Toshiro Kawahara,
Martin Harris, Hirokie-san (Docomo).
Mostly ISP/operator kind of people.
Quotes:
Docomo: "IETF is the only standardization body for technical standards that require market acceptance and competition".
Kawahara: "Cooperative development only works if the ITU Rapporteur and the IETF WG chair are the same or work closely together - even then, the revision process is really problematic".
Harris: Was feeding requirements through 3GPP into the process - "want to meet IETF half way". Not good?
Steve: Mobile IPv6 with route optimization scares the mobile-phone people. They want to see all our packets so they can bill for them....
Allison: Some want to enforce bandwidth usage by manipulating the codec strings in the SDP messages......CLUELESS!
Randy: The case of Diameter and 3GPP is a sad case - we were not clear enough early enough, and the 3GPP people drove into the weeds reading them.
"Sadly, enthusiasm seems inversely proportional to maturity".
Rob: We use "clueless" too much - the term "differently clued" is often quite a bit closer to reality, not just an euphemism.
James: Japanese people don't like ICANN being US-centric. Would prefer
heavier ITU involvement.
Harris says: Very different stuff btw FR and GB ENUM pilots. "Not a long
term solution".
Fred: "Don't believe ENUM is short-term until all the 10-button phones are going away."
Rob: Consistent with 2000 Interop showfloor impression - "now is H.323, future is SIP".
Sally: "Given that SIP is what is being taken up - is it the Right Thing?"
Allison: RTP and SDP were OK components. SIP is far better now than it was 2
years ago. And if we want mobility, we somehow have to have proxies or the moral
equivalent thereof.
Lots of our systems can have more or fewer intermediaries - it's possible to be
very complex, but you don't really have to.
Want to do a simplifying rewrite @Proposed to get a smaller SIP.
Sally: Personal input or architectural clue?
Allison: IESG has helped a lot in forcing it to be a well-behaved Internet protocol.
Randy: Success is detectable when people start using it for what it's not intended for.
James: Compare IS41 - DIAMETER + SIP +++ - huge mess. SIP is simple. Our spec design is far more modular than the traditional telco standards way.
Harald: SIP has managed to unseat an incumbent (H.323) - that's unusual in protocols.
Allison: STUN (firewall bypass) coming up for IESG review - really took UNSAF seriously.
Allison: "I don't think we want to do the hardcore telephony protocols.
But we should keep on doing our own thing - clean and reasonable...."
Maybe it helped that we were talking to them - for instance about threat
models..... we understand about vulnerabilities. We should continue working in
this arena.
James: Educating 3GPP about Internet architecture. Root out hidden assumptions that underlie their "weird requirements" - get back to the business requirements.
Eric: feeling that in 3GPP, there are assumptions deliberately hidden, not just unrealized.
Rob: telco quote - "it really hadn't occured to us that you don't trust your ISP".
Harald: Don't want to create standards that require the old business models.
Randy: Do we want to help ICANN not get taken over by the ITU?
Allison: ITU still is unbelievably difficult about releasing information. Cautionism!
Rob: ITU has very carefully established procedures for screwing up - ICANN is inventing them on the fly.
Ted: How to tease apart the resource allocation part of IANA from the protocol stuff?
Harald: IANA and ICANN should be split apart.
Randy: The IP address shortage in Japan is specifically and deliberately created by the policies of the JPNIC, and is not related to either ICANN or ARIN.
No resolution.
<<<presentation>>>
threats of going to other fora are hollow. Let them go!
We can't save them from going over the cliff. But that doesn't mean we shouldn't
talk to them!
Allison: we should encourage interoperability & testing...
Sally: Real end-to-end QoS?
are we getting the wrong things into the IETF?
Fred: cops didn't do what they promised. Someone should have been fired long
before cops-pr.
"The hourglass is proliferation at all levels that I'm not responsible
for" (Steve D & Randy)
The Thousand Flowers culture has not yet turned to serious review of whether
to pursue objectives.
Has the IESG turned much further than the IETF community?
Discussion focuses on COPS as an example.
Ted: One answer to whether something coming in is right or wrong is "experienced IETF person says so". Other answers?
Randy: Winnowing /funnelling should be a part of the community function. The IESG is (far) ahead of the community in starting this.
Ted: Is getting the stuff in at this late stage in their development non-optimal? Randy: Yes - and the way they come in is bad too.
Eric: They are coming in with a lot of inertia & community behind them. That's harder for us to deal with.
Allison: Even worse is the closed groups that work in the dark & throw stuff over the wall. RDMA, Bluetooth for instance.
James: The issue is about needing interoperability for the market - PWE3.
Leslie: They're coming in without us understanding how or if they fit in.
Ned: Very worried about the judgmental attitude - choose not to believe people who are saying the "right thing". (JXTA, Jabber)
Eric: Different kinds
- opensource inertia, finished & fine - we have to come to terms with that
& decide what to do.
- inertia & not finished - need to figure out what to do & how to do it.
- horrible messes to be avoided.
Harald: Have to make a judgment based on facts - and IESG has a bandwidth problem with it.
Ted: What does it mean to "come to the IETF"? A meeting slot &
IESG review?
The question we SHOULD be asking is what the process is to get to a sensible
result - whether that involves being "here" or not?
Allison: Why do they do it? Sometimes I wonder why they go through the pain they go through to get that RFC number....?
Leslie: It's not just "how do we become a machine" - there is a
theory that some architecture is involved here.
It's scary that we say "we have milestones, but who cares about
milestones"....
Ted: "Acting as if some of the members of the IETF aren't full members"
Allison: Are there things (Peer-to-peer, grid) that we should be doing that
we haven't gathered in?
Would like to commission a BOF that focuses on the "selector" thing.
Aaron: The investment of time early in the process will save time & workload late in the process.
Steve: Opposite problem - ending up blocking stuff because "we don't
like it" - and missing Good Stuff?????
We should chop off huge areas of the IETF and instead concentrate on letting 3
flowers bloom in the areas we know well.
Ned: Top-down WGs in Apps haven't worked very well. Examples are DRUMS (which
worked) and RESCAP (which didn't).
The problem is that when you start from the top you don't have member buy-in. We
work best at bottom-up - and that means we're at the mercy of what trickles
up...
Rob: We could have been better off if we had used Experimental more than Standards-track; letting A6 dwell briefly on standards-track made it much more painful to get it moved there in the end, for instance.
Ned: Typical case of exhaustion of WG & work left to do - moving to Experimental would have been better. Example: Notifications in IPP - 3 proposals that aren't going to get agreement.
Thomas: Stds-track means that people make checkmarks - people will then want
ALL of them, which hurts.
WGs go off assuming stds-track - and they NEVER review that idea. And they
consider Exp a "kiss of death". Bad.
Steve D: We need to learn to be able to have more than one.
Requirements documents.....
Eric: Working on req doc is a tool to discuss the problem - that's OK even if the req doc produced is unpublishable.
James: Not useful. Pushing conflicts down the chain.
Ted: Checkbox - active drafts. Should we have reqs docs there?
Mike: Requirements docs are very different - some have architectures that won't work.
Ned: IDN had a requirements doc that turned out to be hugely divisive near the END of the process - "have requirements been met?"
Leslie: 3 examples - CRISP, IMPP - fairly useful.
URI - was being used as a tool against the IDN group.
Randy: AAA had a real good experience with req docs - merged 4 groups' input, and produced something that was useful for evaluation.
James: Problem statement, and possibly a framework, much more important than the requirements.
Eric: Competing proposals are bad for reqdocs - they turned into battlegrounds. I wish people would produce a 3-page document saying "what does this WG want to do"?
"Don't just do something, stand there!"
Eric: Cars are different. Why shouldn't protocols be? Should we stop stuff just because we find them distasteful?
Sally: More like designing a global transportation system - railroad gauges that don't fit - differently colored lights..... Coherence is important.
James: Taste judgments are often the cover for a worry on interoperability.
Rob: The flipside to the "cars" argument is having to implement all of them.
Patrik: We are the ones who have to differentiate between railroad gauges and color of the car. And we have to tease that out of every new proposal that comes along.
Ted: Quoth Sally - It's valuable to have review at many levels. And we need the ability to say "great stuff - go work on it over there".
Thomas: The clue input is orthogonal to the need for interoperable specifications. It's the standards and the interoperability that is our focus. GGF came to us and wanted to be us - but chose to copy our process and do their work somewhere else. That worked.
Ted: Disagree. We're an engineering body that uses standards as a tool to get engineering done.
Randy: We're the INTERNET ENGINEERING task force. We're doing prudent
engineering to make the Internet work, not in the business of providing a home
for any stray cat.
Part of operations is to get consistent stuff from my vendors - which requires -
preferably - ONE way to do stuff, done properly.
Allison: Would be more sympathetic to the "you're suppressing" argument if there were more different ideas that we had suppressed - most of the stuff is minor variations on MPLS/SIP/XXX. A lot of the time, we're looking for new ideas.
Harald: We're TRYING to focus on what we need to do for interoperability
only.
But our process (BOF tomato party + heckling the IESG) doesn't seem optimal.
Mike: In the old days, we were doing lots of tech transfer from research to
standards.
We're not doing that much any more. Vendor-generated ideas?
Stuff came in with the research done, and wanting to wrap engineering around it.
With (for instance) IM, the game is (also) about getting to control the
resulting space.
Allison: Some of the stuff we're doing is from Darpa PI meetings.
Fred: In 1988, there weren't any vendors to generate stuff.... now, it's natural that a lot of things are generated by vendors.
Leslie: This may point to a need for process change.....
Listing areas of topics with large impact - how do we feel that we have done on these?
Going through a number of things on the "did we get this right" axis.
Steve: Questions the value of assigning "right" judgments - all of these are engineering tradeoffs.
Sally: Inherently a value judgment. Clearly not a 0/1 value - "could we have done better" is a better formulation.
Allison: We should focus on the assessment process and the result thereof, not on the particular technology. What was the nature of the evaluation of OPES - not whether we got a specific technology right. Otherwise we risk having a rather fragmented discussion.
Randy: Whatever the process was, we have to judge it by its results, not by the nature of the process. Need to backtrack from results to process.
Harald: Not worth it spending time discussing what the result was - should focus on cases where we agree on the result.
Sally: Example - Ipv6 community input @start, much less after the first 2 years. Diffserv - not looking at the whole picture. What was the forum that was appropriate for talking about the overall picture?
Charlie: Important topics - not only the quality of the result, but whether it got adopted in the marketplace, whether the result was timely.
Alex: Would like also to focus on the emerging technologies (PPVPN). Stuff that the ADs would like help on guiding evaluation of.
Erik: Judgment in the marketplace takes time - 5 years down the road, we might know.
When searching for "something that we blew totally", PEM (and MOSS) was suggested - "so long dead that everyone agrees it's gone".
Allison: What about timeliness? Conspiracy theories abound - about "us" delaying stuff and working on "the opposite of Internet time".
Ned: Problem is not just that we use too much time, but that we use the wrong time. OPES is a classic case of too slow. Other cases are too fast - shipping without adequate review.
Steve: The IETF is so large, it's hard to see it all. Without limiting the scope of the IETF, I don't know how we can get the people cycles to get the community review including background study we need. How can we chop up the scope?
Randy: Scope narrowing is a natural thing. Unless we have things we think shouldn't be done in the IETF, throwing things out just means that we have to watch it elsewhere. We do tradeoffs across a large amount of the stack - and that may be an important part of our strength. Rock and a hard place.
Sally: Cross community 1-hour review sessions? Going into a WG means jumping into the middle of a deep-down details discussion; a slot set aside to do "high level review" might be a Good Thing.
Leslie: Focus on the tools and whether they have applicability to particular situations.
James: The WG chair is important, and hasn't been mentioned. Important as bogosity filter & reviewer & contact with the IESG:
Erik: BOF as mechanism - PANA - was nebolous before BOF, and still is. Needed
more cycles before &
- crisp problem statement
- strong chair
- BOF charter
Patrik: Want non-BOF meeting - people think that "BOF" means "you have to try to create a WG".
Allison: Triggers - had a pre-BOF bar BOF - with beer, which actually helped
a lot.
Scheduling interim reviews is very hard when people are going to
everything else. Perhaps schedule it outside the IETF? In clusters?
James: WGs don't want strong WG chairs - they want process minders, not direction setters. MobileIP chairs have been process minders.
Thomas: Problem with training BOF leaders - lots of people don't have a clue about what it means to have a successful BOF.
Randy: Underlying theme - and why we come back to BOFs - is
that the tree grows from its roots. Strong chairs are criticial.
Straw proposals: - BOFs do not discuss the charter (about the substance of the
work, not the charter). - IAB people to chair BOFs.
Erik: Is relaxation on small group or on beer? Unclear - the meeting was open, but with no chance of making a WG.
Eric: Many chairs feel that they have no right to exercise control - and the IESG doesn't back them up when they try.
Leslie: Having something formally part of the process, but not focused on WG formation, might be a Good Thing.
Steve: Chairing - from my background - have WG approval -
allow people to speak, AND guide the process. If we insist chairs be neutral,
the pool is quite limited. Second: IESG needs to delegate responsibility, set
goals, and not micromanage. Intense micromanagement from the IESG leads to the
WG chair abandoning responsibility for quality of WG output.
"The WG chair does not have the authority to block stuff the way the AD
has."
Rob: There's a difference between allowing the person to fail and allowing the project to fail.
Mike: Maybe we should require at least 1 BOF chair to be an
IAB member.
- q: scope of the IAB?
----break----
Sally: Reviews - the important thing is the x-area review. The
core team is talking anyway; the ones you need to hear from is the others. And
this does not happen on mailing lists.
Specific example of QoS/Diffserv - not a process failure, but a vision failure -
looking at the building blocks and having nowhere to focus on the big picture.
Randy: BOF - suggest just leaving 2 evenings with empty rooms.
Mailing lists are less useful the bigger they are - exponentially so, which is
worse than face-to-face meetings.
Panels of reviewers - difference between "grunge" review,
"technology" review and "inter-area/global" review.
Ted: Review might be able to happen on mailing lists that are
not WG mailing lists.
We can deal with big # of participants who play fair, but the mechanisms for
dealing with "Flemings" are not terribly effective.
Allison: WG Chair - charter state varies between WGs. Working as a team with your AD is very important; stuff outside charter or low quality creates friction. They ARE empowered to make sure things are right.
Erik: Should think about what we need to do at meetings. In-depth problemsolving might not need the x-area input that an IETF meeting can provide; is this better done at dedicated interims, leaving the IETF for review and x-area?
Fred: Diffserv case - disconnect between business plans and WG technology. DWDM dropped the cost of adding bandwidth dramatically - changing from 20% packet drop to 10% utilization. When diffserv was done, problem had gone away. "Not something we could have predicted?"
Trying to focus on other suggestions.....
Roadmap working groups?
Sally, channeling Brian Carpenter: IPv6 had a roadmap, Diffserv didn't. That might have been a good idea (looking at end-to-end, not hop-by-hop).
Thomas: Roadmap sounds like a good idea - having a WG might not be relevant.
Randy: JXTA is an example of something where an overview/roadmap is hard to find.
James: Example of 3GPP is not encouraging - different groups in charge of roadmap & technology - nonconstructive political dynamic. Better sequentialize within a WG?
Fred: We are adding impediments wrt requirements docs -
charter says 6 months, fact is 2-3 years. Adding another "nominal 6
months" - does that help?
Example is ROAD - took a year, even when closed & important.
Erik: Not precursor - parallel. In some cases, directorates. Specifications or gap analysis?
Steve: Difference between building solutions and tools - Diffserv was on components, "we're not smart enough to build end-to-end systems". Making the minimal pieces to make it possible to experiment with solutions.
Bert: Sub-IP is a warning example - we had a roadmap, but were unable to deliver. People went right on working on their own stuff.
Leslie: Roadmaps - Making a map is not a terraforming
exercise. A necessary component of doing work. How to get it produced may vary;
best handled as a tactical decision.
We have several workable mechanisms. We should refresh some of them (like WG
chair, making sure BOFs work).
Success requirements include a well understood problem statement, and a roadmap
that tells us how it fits into the general scheme of things.
Allison: If we make sure documents say what the work is supposed to be, the need for radical surgery might go down.
Harald: Working groups are good for making tools. We need roadmaps. Need to think about other ways to produce them.
Sally: Problem statement is a good tool for cross-community review. Make people understand the problem enough to give useful feedback.
James: Sometimes it's necessary for the IESG to command the WG to do things in order to get them started.
Allison: We have to get away from the idea that top-down never works.
Erik: Requirements docs too are examples of things where the WG has to learn why it is useful in order to make them write the document that the process needs.
Randy: The socratic method (tease out by asking questions) doesn't seem to work well. Other mechanisms?
Eric: A WG can mostly get something good enough to fool the
IESG. OTOH, the WG has internalized the thing they want to work on - that's why
they think it's a "checkbox".
On the third hand, people are saying "hoop jumping".
Steve: Socratic method can backfire. Yakov-style "I have a zinger of a remark waiting when you respond to this question" doesn't encourage communication.
Rob: What works best is asking "what am I missing" - but requires more patience and humility than most pepole are able to muster.
Eric: Yes, but has to be taken in good faith. Or it backfires.
Leslie (summary): At this point in the IETF history, we don't
have unity of mindset about why we need the process we think we need
(requirements, roadmaps, problem statements). Should we try to capture our
beliefs in "what makes successful work" in a document?
Leaving what to require and what to consider good enough up to the ADs?
Randy: "If they can't say what the problem is in a single page, something's horribly broken".
Leslie: "The problem statement has to be sharable."
Leslie: One reason why IESG/IAB is considered closed is that we have some degree of common mindset - but have not shared that out.
Rob: "What you think the problem is, and how you are going to solve the problem".
Harald: Remember - some WGs are doing well as small operations!
Randy: Roadmap is something that fits the terrain....
Steve: What about timeliness?
Allison: For the IESG process, the tracker is actually an important tool.
Thomas: Timeliness within WG - getting the basis right - is
important. And serious.
Example of groups with -03 drafts where the *basis* is still junk.
Steve: Other end - work that is basically done, but it's being dragged out because "there's always another nit to fix". "the right to criticize should time out at some point." - the marginal improvement in getting your particular fix accepted is not worth the delay in getting the product out the door.
Erik: Tools needed for raising the bar? WG Chair training should probably be more than an hour at lunch.
James: Dates are often treated as a joke - but often, they were set with an idea of a market window. Rather than just timing them out, we could need to do drastic surgery.
Alex: Serializing enforcement - "you need to do the boring stuff before you are allowed to finish the stuff you think of as fun".
Mike: Should have updates on milestone dates with every post-IETF working group report.
Randy: Bad problem - DISCUSS comment delays.
(a brief digression into the milestone tracking)
Leslie: Substance and process - there's a chance that if you update your milestones, you have thought about what you are doing and should be doing.
Randy: We have not pushed away too much stuff that we have
regretted. We should, as an experiment, try to turn away more.
"In DNSEXT, as chair, I let crap come in that I should have turned
away."
Harald: "A working group that is unable to communicate the things that it is doing should be killed."
Steve: How can we reduce the number of things we standardize to the minimum number of things we have to standardize?
Sally: Not at all obvious that this is the case. Several things in Apps are either standardized here or somewhere else - and doing it better here than elsewhere.
Randy: X-area stuff is "hug here". If it's isolatable, let it drift off.
Eric: Overwork solutions - loadshedding, expand the capacity,
and do a crappy job.
If we don't do either of the first 2, the default is number 3.
(There are known organizational tools for expanding the
size of organizations.)
Allison: Steve thinks we focused in the old days. (Steve denies that - "we were always all over the map"). We could probably do better with a better organization. "We spend an awful lot of time on really pathological messes". We should spend more time on cultivating our organization.
Leslie: Organizational growth - at some point we need to evolve to "do the right thing for the company"; sometimes that involves being ruthless.
Steve: We should encourage more interim meetings, and encourage x-community work at the IETF. That might mean scheduling a lot fewer slots!
Eric: Small, unorganized teams work well < 8, and work
really bad > 12.
Hierarchical organizations work at scale, but productivity drops dead.
A lot of the time, reorganization requires replacing the leadership.
Management spans of > 5-10 are currently actively discouraged.
Randy: Increasing the depth of management when a large part of the problem is a lack of good management skill will increase the lack of management. This is a problem.
HIGHLIGHTS
Two concrete areas to explore are the role of interim meetings and the role of IETF meetings, and whether we want to revisit those.
A major possible piece of leverage is directorates and review groups. They need focus. And management.
----- lunch -----
Collection of individuals mythos seen as being weakened by company-based players; the mythos is still important, and strong, however.
Eric: "The person who speaks for Cisco can't possibly have equal weight with the guy writing an implementation in his garage."
"The change process needs to acknowledge the perceptions of the IETF while addressing the underlying realities of the IETF - this can get tricky."
Skepticism to the idea of external consultants - "they understand as much about the process as the time you spend explaining it to them will allow".
Allison: Big change vs incremental improvement is one question to ask.
Trying to make a problem statement.... (black & white slides inserted here)
Ted: "The IETF is a place where hard engineering
decisions are made for the Internet".
This is a different property than making clear standards. Is the problem that
our decisions are wrong (or untimely), or that the result of the standards
process is not good enough?
Sally: "I think the important one is the engineering one, and we're not too bad at that".
Thomas: We don't make good engineering tradeoffs when we don't
come to closure.
Documenting what we agreed on is a critical part of the engineering decision
process.
Erik: Sometimes, we need agreement on the big picture, but disagree on the details.
(notes were lost here while projecting sildes)
Ned: IESG is not good at communicating mandates and the reasoning behind them.
Allison: Some stuff is supposed to happen in the back room - we're nerdy engineers who don't talk, we write code...?
Eric: Comparing the IESG with the NSA export rules - "you don't know the rules, and we're not going to tell you". Example of separate-port issue for TLS.
Bill: Requirements based on the mood of the AD is not good.
Thomas: We're bad at communicating....?
Harald: Any process seen as IESG/IAB-directed is going to be a failure by definition.
Thomas: Afraid of having change for change's sake.
James: ....and the proposals for change are going to be approved by who????
Steve: The leadership of the process should not be one of us.
Sally: Do we have consensus that such a process is needed?
Ted: A core of people have asked for change, and we're duty
bound to consider it.
Some things that we can do - draft-tracker - are not part of this process, but
will affect it.
Leslie: I don't think we in this room can decide what the
problem is either.
But we can't abdicate the responsibility for enabling the process for the
problem statement.
"We can't get away from managing the process".
Randy: What, apart from openness of the process, are the problems?
James: List of problems sent out in March (specific suggestions for changes).
Steve: Step one of the process is getting consensus that there
is a need for change.
It's been a long time since we've done a major rethink.
Eric: Problem set -
- just the authors read the document
- multiple competing proposals and no way to reach consensus
- IESG blocks documents, doesn't say why, and doesn't talk to me
- the IESG approves documents that are crap and should have been stopped.
Averaging the two last bullets is not an option....
Thomas: Are the IETF processes not working to the degree that we have to make changes to the IETF?
Allison: Just encouraging focus on problems is not good; we have to continue to get protocols out. Let's not have a process that involves breaking everything - we have work to do.
Alex: We will have unhappy souls - saying no is part of our job. But we HAVE managed to do a good job - the Internet is running. I'd be really careful of pushing the malcontents into working in a WG and get something done.
Randy: We haven't talked about solving the unhappiness WE feel - we've switched to talking about the unhappiness the community feels.
Rob: Focus on "broken" will cause people to say
things are broken. Focus on "improve" will focus people on that.
Negative pattern - WGs behave as if the IESG will catch all their mistakes,
which means that the IESG has to.
If we don't set the stage for where success is possible, we won't get it.
James: We've had 1 1/2 days of problem statement. We could write this up and get feedback.
Bill: Careful of the perception that we are doing reorg by I* fiat.
Steve: There is a conflict between the bottom-up process and the fact that we've put people over us to make sure of the quality of the product. One engineer's value judgment is being allowed to override the consensus of all the others. And that's a problem.
Sally: Need to be able to have the negative feedback come as a community input - while a WG may be happy, the rest of the IETF may not be.
Steve: after Kobe, the IAB has been trying to find a way to help get quality and architectural vision without being perceived as trying to control the process.
Allison: What looks like an override might be a cross-area review. Would be better if the input could be seen as cross-area review to the WG - giving a perspective that the WG wouldn't have done. Our inability to talk is making trouble again.
Ted: Problem - "AD comments are no longer considered participant problems". Many of the problems we have are with getting cross-area review into the WG in time.
Randy: "It's obligatory for an AD to be present and active on all the WGs in his area and the relevant cross-area lists."
Ted: "That doesn't scale."
Charlie: Ironic parallels between here and the WGs we're criticizing - everyone agrees that there is a problem, but no single change that we all agree on would be better. Starting a WG to find solutions we don't know the existence of is "just asking for trouble".
Randy: Some things are "obvious" and have been suggested - directorates, review teams and midterm reviews.
Rob: Slide going on - face to face meetings are getting more
important relative to mailing lists. Directorates etc all work by advising the
AD - and it all has to happen during IETF week, which limits the bandwidth
available for getting the AD into the right WG with the right info.
The power of the DISCUSS seems to be the only tool that can get stuff dealt with
a lot of the time. And that's painful.
Allison: If WG chairs really bought into their charters, they would be able to apply more power.
Eric: Most common problem - star performer overloading, but refusing to shed load because the alternates would do a "slightly less good job". The reason people respect ADs is 30% respect and 70% that they can block a document. We need to delegate power too.
Randy: "You can delegate authority - you can't delegate responsibility."
Steve: In some areas, pan-IETF agreement just won't happen.
Example: v6 fixed/variable addresses. That's where the IETF gets into real
trouble.
The buck stops here...
Rob: "Sometimes, making a decision is more important than what the decision is."
Harald:
There is a problem set. The enumerability of the set has not been demonstrated; it's not clear that we know what the problem set is.
Handing the problem set to a WG and telling them to come up with a solution is not prudent engineering.
Dictates from on high are not going to work either.
Leslie:
Handing a question to a WG or WG-like object:
"What, if anything, is the IETF not achieving that it should, or vice
versa?"
(Randy: "....and what it's doing that it should be doing, or is not and should not").
Getting consensus on the problem, WITHOUT proposing solutions, could work.
Example of process working fine & defusing a problem: NOMCOM WG.
James: "We should take the stuff to the plenary and ask for feedback".
Randy: My problem list - Scaling. Tension between x-area vertical view and bottom-up spot consensus. Dealing with exogenous inputs (ICANN). Openness of process. Mechanical management of process (datatracker). Managerial processing of new projects.
Thomas: WGs have dangers. But the most important signal to send to the community is to say that there's a place to discuss and have a dialogue. Have a reasonable discourse about what is a problem and what is not a problem.
Leslie: Scaling, for instance is perceived to be a problem. But define it, focus it?
Allison: One reason why IPR is so quiet is resignation by the people who are worked up - they don't think there will be any fundamental change. So they've shut up.
Rob: The free-for-all in the IPR had a few pepole arguing for complete "no patents" policy changes; the other proposals for change were very small.
Allison: Still worried - it's scheduled against other WGs (including SIP) in Atlanta.
Erik: We should get some feedback from the WG Chairs. They are the ones who are "between" us and the rest. And IPR did work before going WG - perhaps we should do the same on this issue?
---- Break ----
Roundtable
Ned: "A fair amount of tactical minutiae". Not clear that we've made progress on our strategic issues; not even willing to commit to a problem statement yet.
Bert:
Thomas: Not clear problem statement. Some things we need to and can do - but not enough.
Sally: Liked Randy's list of problems. Liked Leslie's board statement, which is a good way to start a WG.
Allison: Liked Randy's problem statement. Might have improvement groups that work between the IESG and IAB.
Eric: Not sure we have the strategic vision (yet). Good to bring this out in the open.
Charlie: Benefit from hearing the way people view the problem sets. Security area's AD-support/advisory "directorate" seems to work. But solutions not obvious.
Erik: Useful to have us all together.
Fred: IETF fundamentally changed from 15 years ago.
Organization hasn't really changed.
We're going to have to figure out what the IETF needs to be when it grows up.
Could imagine discarding plenary meetings and only doing interims, for instance.
Steve: Started out with serious doubts. Seemed like making the
smoky back room bigger. Needs to be judged on what happens next.
Growing awareness of deep problems, but still some resistance to it.
Hopes for the datatracker sound like we're in denial that the problems are
deeper than that.
Ned: Datatracker is, among other things, a tool for figuring out what we are actually doing. A tool for generating insight, so that we can figure out what is going on.
Bill: Good to be all together. More relaxed than the breakfasts in a horribly busy week. Skeptical that we've accomplished something - but heard more points of view.
Randy: Lots of pieces - no coherent whole - no generic solutions. Progress & change is happening, but individual, not group. Two goals - process & getting IAB/IESG to play together. This can change future work in a major way. Leslie & Harald doing good.
Alex: What worked best was actually getting together. For a
beginning, it was very good.
We should perhaps allocate time equally to problems that we don't know and the
problems that we know, and need to find a solution to now. Takeout: Talk more
with the community!
James: At some point we're going to have to look at some deeper changes. List of problems a lot like Randy's problems. Need to take the question of what the problem is to the community. IAB & IESG together was good.
Rob: Talking together has allowed us to converge our problem views greatly.
Patrik: Had no hope of resolving any problem - since we did
not know what it was. Given no hope of solutions, the meeting was good!
A little worried about panicking. Worried about Atlanta - not time enough to
meet face to face.
Mike: Evident that we're a structure that was designed for a much smaller IETF. We've tried evolving our current structure - (2 ADs/area) - workload goes up. We don't say no (enough). We should start by figuring out what to say no to, and then work on the rest. Useful to see the guy from the other end of the phonelines.
Ted: Thanks for putting technical content on the agenda. That
helped greatly in not starting out deep in the mud of "Process stuff".
Worried that we're still thinking that small fixes will solve the problems -
"there's no tea in the Boston Harbor yet, but we're a lot closer than some
of us in this room seem to think".
What we have to do is changing from under us. And we have to adapt with it.
More radical changes that need to be done if we're to remain an engineering
body, and not just a standard body with some engineering clue.
Patrik: Don't panic does not mean don't change!!!!
Randy: How you state the question really frames what you get for an answer. Important to phrase the question so that you get a constructive answer, so that the IETF proceeds to get closer to the IETF goals. Reference to London principles. Careful!
(the discussion of the last slide show was not included because this screen was used for other things)