Narrative Minutes
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the October 26, 2006 IESG Teleconference
Scribe: Spencer Dawkins <spencer@mcsr-labs.org>
With corrections from Magnus Westerlund, Dan Romascanu, Leslie Daigle, Dave Meyer, Ted Hardie, Jari Arkko, Cullen Jennings, Lars Eggert, Brian Carpenter.
1. Administrivia
1.1 Roll Call
1.2 Bash the Agenda
No additions, no changes.
1.3 Approval of the Minutes
October 12 minutes were approved with no discussion, October 12 narrative minutes are still being reviewed. David will send any comments.
1.4 Review of Action Items
IANA Multicast assignment expert job description - have a draft circulating among the action item assignees.
1.5 Review of Projects
http://www.unreason.com/jfp/iesg-projects
No updates for this meeting - Sam has updated status and will send this to Jon.
Brian asked people to check the WiKi contents (at least the interesting parts). Ted said he's having WiKi performance problem (4-5 minutes) but others did not report the same experience, and we're not sure what the problem is. Will discuss with Henrik.
Mark has updated the CableLabs relationship spec - what's the next step? Send to IAB? David says "yes", and Leslie agrees (please send bit of background as cover note).
Does Mark include a time limit? Or does this have to be published by IAB? Leslie suggested coordination, since this is a formal liaison.
Would this become an RFC? Leslie says "yes", but Leslie says IAB looks to IESG when there's a need for liaison - won't be pushback, could be suggestions for improvements.
Mark will state a requested time for response, but silence will not mean consent. Leslie says "don't get overwrought on formality" ("do the right thing").
2. Protocol Actions
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
2.1 WG Submissions
2.1.1 New Item
o draft-ietf-isis-wg-multi-topology-11.txt
M-ISIS: Multi Topology (MT) Routing in IS-IS (Proposed Standard) - 1 of 10
Token: Bill Fenner
Bill - previous versions said "you can use DSCP", but that's not what it's for. Is there any standard work going on to say how operators demux overlapping address space?
Brian - any kind of packet snooping has the same problem.
Mark - like L*VPN
Bill - but that's usually interface-based. In this draft, people want to have multiple topologies with overlapping addresses, and on the same interfaces. No way a standards document is going to mention "demux on DSCP" even though that's what people are going to do.
Brian - this isn't much value, it's out of scope. "Which kludge will you use?"
Bill - but anything we do will be a kludge, and the IESG isn't going to standardize a kludge.
Mark - should be Informational.
Bill - may be possible to get people to write down thinking,...
Brian - but you don't want an informational reference to a document that hasn't been written yet, right?
Mark - everyone else says "out of scope, we'll wash our hands..."
Sam - interface-based isn't a kludge
Brian - but no one has written that up yet.
Bill - would not be bad to bring this up as RTG area working group item - it's not an IS-IS topic
Brian - a lot of documents on this agenda, guys.
Mark - going NO-OBJ,
o draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt
RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery (Proposed Standard) - 2 of 10
Token: Ross Callon
No DISCUSSes, approved with no discussion on this call.
Yoshiko - for this document, IANA asked lots of questions - have IANA considerations been revised?
Michelle - can someone hold a DISCUSS for this?
Brian - we'll go "writeup needed", and this will let us figure it out.
o draft-ietf-ccamp-gmpls-segment-recovery-03.txt
GMPLS Based Segment Recovery (Proposed Standard) - 3 of 10
Token: Ross Callon
No DISCUSSes, approved?
Ross - Bill has a reference update as an RFC Editor Note.
Michelle - we just got author response on IANA questions - can you hold this one just like the previous document?
Bill - we'll update the RFC Editor note and make sure IANA questions have been answered.
Brian - tracker will point back to Ross for next step.
o draft-ietf-rddp-mpa-08.txt
Marker PDU Aligned Framing for TCP Specification (Proposed Standard) - 4 of 10
Note: PROTO Shepherd: David Black ( black_david@emc.com). Gen-ART Reviewer: Eric Gray (Eric.Gray@marconi.com)
Token: Lars Eggert
No DISCUSSes - approved with no discussion on this call.
o draft-ietf-idr-as4bytes-12.txt
BGP Support for Four-octet AS Number Space (Proposed Standard) - 5 of 10
Token: Bill Fenner
Brian stated NO-OBJ on the call.
Bill - There are no DISCUSSes, but a LOT of commentary. Not comfortable just approving this... What about all the 2119 language fixes that authors need to make?
David - not a DISCUSS because I don't want to block the document. More important to get it out, just that authors could have done a better job.
Sam - where are the code points defined that are required for this?
Bill - ASTRANS is already allocated, this was David's point, and it's very sensible to point that out in this in the document.
David - if authors are willing to make small changes, great, but it's important to publish. This document isn't actually WRONG, so don't want to hold it up.
Bill - will hold a DISCUSS to allow for a new ID, if that's the right way to address comments. Approving this ID makes getting a new ID work oddly.
o draft-ietf-midcom-mib-09.txt
Definitions of Managed Objects for Middlebox Communication (Proposed Standard) - 6 of 10
Note: SEC-DIR Reviewer: Radia Perlman (Radia.Perlman@sun.com). WG Shephard Melinda Shore
Token: Magnus Westerlund
Sam stated NO-OBJ because Magnus already has DISCUSS on the downref issue.
Cullen - would like to talk about this. Talking to Lars, the issue with this document is that no one intends to implement it. My concern is that we don't block other documents becoming PS, because we've already approved a PS. No problems with publishing THIS document. Experimental would also solve downrefs.
Dan - not sure I understand relation about protocol implemented or not. I have another document in the the same situation on this agenda. Does this make a difference?
Magnus - I don't think so, we've run the process in the working group and need to publish the output. We can go HISTORIC in three years.
Brian - this was a very complex decision process, but this is what the working group chose.
Cullen - but no one in the working group agrees.
Bill - maybe they thought it was the only answer the IESG would accept.
Cullen - don't go there, I don't care about publishing this, just don't want to block other things.
Sam - it is reasonable for the IESG to publish at a lower level, but I'm not saying anything about this document, and we have to use this right sparingly.
Brian - this is a MIB, not a protocol
Cullen - no, it is a protocol
Brian - but I don't see how publishing a MIB keeps us from publishing a protocol later
Bill- how serious are we about avoiding two standards-track solutions for the same problem?
Brian - that's actually a guideline, anyway (not a rule).
Sam- very uncomfortable about framework/architecture documents that are critical to understanding but published as IETF Informational documents - these documents just don't get the review that standards-track documents do. Frameworks that aren't normative references are fine at Informational.
Dan - is this saying you can write protocols based on bits without understanding requirements?
Sam - maybe we need a new document classifiication, but am sure I don't like WG INFO documents that weren't last called being normative references.
Brian - this is not a new idea.
Sam - but it's an unreasonable use of DOWNREF
Ted - we've cycled on this maybe half a dozen times, because you're talking about document that can't be advanced to DRAFT, so people say you shouldn't publish at PS, either. Sam's suggestion "Must Last Call INFORMATIONAL documents that will be normative references (e.g. architecture and framework docs)" may be good, but we can't do this ex post facto. Unless people include entire previously-published-as-INFO document as an appendix, there's no way to "Last Call" a document that's already been published.
Sam- Not what I'm saying - I'm saying this is not a reasonable downref.
Ted - but we need to get community agreement on how to handle this, and we haven't done that in the six tries I remember.
Magnus - Move requirements doc to informative, and keep the other two references at normative and do a new IETF last call.
Brian - should ask WG if these are really normative references.
Cullen - they are
Brian - very likely, but we still need to ask WG, it's their question to answer
Sam - I'll hold this DISCUSS because I feel stronger than Magnus
David - but in this case, the sponsoring AD should hold the DISCUSS because this was an oversight.
Brian - and we should talk about this in San Diego.
o draft-ietf-pmtud-method-10.txt
Packetization Layer Path MTU Discovery (Proposed Standard) - 7 of 10
Note: PROTO Document Shepherd: Matt Zekauskas (matt@internet2.edu)
Token: Lars Eggert
Do we need to DISCUSS?
Lars just saw David's DISCUSS, need to prepare.
David - do other ADs agree with my DISCUSS? It's pretty strong.
Brian - it's too long to understand.
David - I was trying to add context. Perhaps I failed.
Brian - did WG consider these issues?
David - this draft penalizes people with normal MTU sizes in favor of people with pathological MTUs - not good for routers or for Internet.
Brian - these authors are also from a very specialized corner of the Internet. WG needs to absorb this DISCUSS.
David - do other ADs have opinions?
Sam - I understand your concern, but this draft is a clear improvement and I don't see another solution.
David - OPS has suggestion to start probes at much larger value - 1500 bytes is most common case.
"1500 bytes, unless you have information about the local link" - but we don't have time to DISCUSS this further on this call.
Lars will follow up with WG chairs.
o draft-ietf-mpls-over-l2tpv3-01.txt
Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 (Proposed Standard) - 8 of 10
Token: Ross Callon
Two DISCUSSes - do we need to DISCUSS?
Ross - authors need to address Gen-ART issues, but e-mail is still flying around on the other DISCUSS
Sam - most of the e-mail is talking about the need for the text, not the text itself - most of the discussion is not required to resolve DISCUSS ballot
Brian - Ted Seely says no reason to add text, but no reason not to.
Dave Meyer - Ted seemed OK about this when he and I talked this morning.
Sam - when we change ADs, we change pet peeves. Yours are different from Allison's. They are valid, they are just a surprise to the working group.
Revised ID needed...
o draft-ietf-avt-compact-bundled-evrc-11.txt
Enhancements to RTP Payload Formats for EVRC Family Codecs (Proposed Standard) - 9 of 10
Note: Colin Perkins is PROTO Shepherd
Token: Cullen Jennings
No DISCUSSes - approved with no discussion on this call.
o draft-ietf-tls-psk-null-03.txt
Pre-Shared Key Cipher Suites with NULL Encryption for Transport Layer Security (TLS) (Proposed Standard) - 10 of 10
Note: PROTO Shepherd is Eric Rescorla < ekr@networkresonance.com>
Token: Russ Housley
No DISCUSSes - approved with no discussion on this call.
2.1.2 Returning Item
o draft-ietf-ipfix-protocol-23.txt
Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information (Proposed Standard) - 1 of 1
Token: Dan Romascanu
Russ declined to state a position.
Two DISCUSSes.
Dan - this is same issue as MIDCOM MIB - normative downref to informational architecture document.
Sam - could move to Informative reference, could implement this one without architecture document.
Cullen - I talked to the authors at the last IETF and they agreed that to implement SCTP-PR over DTLS, you need a document that defined more than just what's in DTLS. There is a draft that covers this, draft-tuexen-dtls-for-sctp-01, but it is still a draft. I'm not sure they agree that meant it should be a normative reference or in fact referenced at all.
Dan - waiting from response from authors and chairs to the new version of Cullen's DISCUSS, may have another session at this IETF.
2.2 Individual Submissions
2.2.1 New Item
o draft-orly-atommib-rfc3895bis-01.txt
Definitions of Managed Objects for the DS1, J1, E1, DS2 and E2 Interface Types (Proposed Standard) - 1 of 2
Token: Dan Romascanu
No DISCUSSes - document was approved with no discussion.
o draft-legg-ldap-gser-ei-02.txt
Encoding Instructions for the Generic String Encoding Rules (GSER) (Proposed Standard) - 2 of 2
Token: Ted Hardie
No DISCUSSes - document was approved with no discussion.
2.2.2 Returning Item
o draft-rja-ripv2-auth-06.txt
RIPv2 Cryptographic Authentication (Proposed Standard) - 1 of 1
Note: Back on the agenda to see if the latest update includes all of the points in the security considerations to clear Sam's DISCUSS position.
Token: Russ Housley
Russ - this DISCUSS needs to go back to the working group.
Brian - did the concerns come out during last call? Why did we pick out these particular points to DISCUSS?
Sam - can't believe OPS community would buy this text.
Brian - but no last call comments about it?
Sam - trying to discuss as consensus issue, instead of a "you must be kidding" issue. If people respond "this is what we meant", that will be a surprise to me.
Russ - author is on travel this week.
2.2.3 For Action
o draft-williams-on-channel-binding-00.txt
On the Use of Channel Bindings to Secure Channels (Proposed Standard) - 1 of 1
Token: Brian Carpenter
Was assigned last night, was not discussed on this call.
3. Document Actions
3.1 WG Submissions
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.1.1 New Item
o draft-ietf-v6ops-icmpv6-filtering-recs-02.txt
Recommendations for Filtering ICMPv6 Messages in Firewalls (Informational) - 1 of 3
Note: PROTO shepherd: Fred Baker. . This document is a late addition to the
agenda.. Feel free to defer if you need more time for review.
Token: David Kessens
Two DISCUSSes - need to discuss?
David - didn't see mail last night. Is Jari's DISCUSS simple?
Jari - think so, and Sam's is related - what to do with unallocated numbers? Obvious policy is "anything you don't know, drop it" from operators, but there are two equally plausible strategies. Magnus also asked - are we talking about operator firewalls or customer firewalls?
David - just need to so some more reading.
Sam - think security overview document used similar approach successfully.
David - will look at this based on Sam's suggestion. "Revised ID Needed."
Jari - what is intention about updating reference/blocking document in RFC Editor note?
Brian - two bis drafts have been around forever, wouldn't advise blocking and waiting on them to be published.
o draft-ietf-ltans-reqs-09.txt
Long-Term Archive Service Requirements (Informational) - 2 of 3
Note: PROTO Shepherd is Tobias Gondrom <tgondrom@opentext.com>
Token: Russ Housley
One DISCUSS - Russ thanked Ted for his DISCUSS and is working with WG.
Russ will also make sure WG looks at Elwyn's comments.
o draft-ietf-pki4ipsec-mgmt-profile-rqts-06.txt
Requirements for an IPsec Certificate Management Profile (Informational) - 3 of 3
Token: Russ Housley
Russ want Jari's Appendix E comment to be addressed - Approved, point raised, writeup needed.
3.1.2 Returning Item
o draft-ietf-ipfix-architecture-12.txt
Architecture for IP Flow Information Export (Informational) - 1 of 1
Token: Dan Romascanu
One DISCUSS - Dan will go back to the working group and get their answer.
Russ's DISCUSS is on text that wasn't modified?
Russ - wasn't on telechat where this was discussed previously, will clear if I'm blocking inappropriately
Dan - no, protocol doc is blocked, too, no problem.
Brian - for new ADs, remember, bad manners to DISCUSS text when you review unchanged text for the second time - usually, you should have caught this the first time. Russ wasn't on first-review telechat for this document, so no criticism. Just guidance for new ADs.
3.2 Individual Submissions Via AD
Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
3.2.1 New Item
o Two-document ballot: - 1 of 2
- draft-martini-l2circuit-encap-mpls-12.txt
Encapsulation Methods for Transport of Layer 2 Frames Over MPLS Networks (Historic)
- draft-martini-l2circuit-trans-mpls-19.txt
Transport of Layer 2 Frames Over MPLS (Historic)
Token: Mark Townsley
Brian - we got dinged for publishing media types as Historic because they were being used. Will people involved find this perjorative?
Mark - certainly are implementations, but consensus in the community is to move to standard solution.
Brian - but do you need to make a stronger statement than Informational? The boilerplate for Informational is "not a standard of any kind"
Mark - not entirely clear when we should use Historic
Sam - IETF feedback on media types experience was asking to explain what the rationale actually is.
Mark - there was text about this in my last call.
Jari - document says "don't do this if you're implementing now"
Sam - then we're met the request for this draft.
Jari - would be good to say the same thing in the abstract - abstract is distributed more widely than the rest of the document
Mark - fine, only pushing back on changes that alter the protocol.
Approved, with an RFC Editor note for the abstract.
o draft-goodwin-iso-urn-00.txt
A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) (Informational) - 2 of 2
Token: Ted Hardie
Can fix both DISCUSSes with RFC Editor notes, thanks for clear DISCUSSes.
Ted will discuss COMMENTs with authors.
3.2.2 Returning Item
o draft-fenner-obsolete-1264-03.txt
RFC 1264 is Obsolete (Informational) - 1 of 1
Token: Ross Callon
No DISCUSSes - document was approved with no discussions.
Brian - you get the prize for the most "yes" votes on a document ... do we abolish 1264 immediately, or when this is published as in RFC?
Bill - this was the right thing to do, so we'll abolish 1264 immediately, and will forward this notification to RTG area when it comes out (next week).
3.3 Individual Submissions Via RFC Editor
The IESG will use RFC 3932 responses: 1) The IESG has not
found any conflict between this document and IETF work; 2) The
IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing; 3) The IESG thinks
that publication is harmful to work in WG <X> and recommends
not publishing at this time; 4) The IESG thinks that this
document violates the IETF procedures for <X> and should
therefore not be published without IETF review and IESG
approval; 5) The IESG thinks that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG approval.
Other matters may be recorded in comments to be passed on
to the RFC Editor as community review of the document.
3.3.1 New Item
NONE
3.3.2 Returning Item
NONE
4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
NONE
4.1.2 Proposed for Approval
o Network Endpoint Assessment (nea) - 1 of 2
Token: Russ Housley
Ted - where we are is still not a good place, it's better with Harald/Vidya text, but still not good. If we approve this, should be noting at least one IESG objection.
Russ - they are willing to add this text, in order to get the working group.
Ted - I'll ABSTAIN, so I won't block this action.
Sam - did you see Bernard's comments? I wish they had come much earlier - about how this is inappropriate for mobile devices, and mobile devices won't know what network they are connecting to...
Ted ... so you can be providing posture assessments to an attacker that now knows what you are vulnerable. This makes sense in very limited environments, but if you're out in the world, you're very vulnerable. I'm only abstaining because the work is going to be done somewhere, and will be more likely to end up in inappropriate parts of the network.
Brian - the question is whether this is going to be done worse somewhere else
Ted - is group unwilling to charter for the security analysis first? Thought they were unwilling
Russ - I don't think I ever said this
Ted - that would be nice, but it's a delaying tactic at best
Russ - yes, and if work is done elsewhere while WG is working on securiity analysis, we'll be in the same place.
Sam - our mission statement is pretty clear that we aren't responsible for the entire Internet. Need to not worry about work being done worse somewhere else.
Brian - agree with you, but am concerned about press articicles about how the IETF is refusing to fix security problems
Cullen - is there no way to fix the security problems?
Ted - EKR is right. If you don't deal with lying endpoints, we end up with people trusting based on pixie dust and still not knowing what network they connect to.
Sam - AD made it very clear to the WG that they had to listen to the community.
Ted - but you can't tell the chairs that we're going to keep adding hoops for them to leap through.
Sam - is security analyisis at the front of their charter? If it is, I trust the chairs, and the AD (mumble NomCom). Just rip out the milestones until AD adds them back.
Cullen - could even have a list of "milesones to be added".
Sam - wouldn't object either way, but would be happier that way.
Russ - two items, enterprise limitation and narrowed milestones. Is that all I need to do for the announcement?
Ted - enterprise limitation is very important, and we're going to be creating a technology that is useful sometimes and dangerous other times.
Sam - question is, do we want WG to consider design features that make this easier to deploy? We have no control over how people deploy things.
Russ - I'm happy to make both changes. There has been significant discussion on enterprise limitaion, and milestone modifications are just how IESG is choosing to run the work.
Brian - anyone want to be listed as ABSTAIN?
Ted - I'd like to be listed as an ABSTAIN ... an active ABSTAIN.
WG creation approved pending edits to charter from Russ.
o Handover Keying (hokey) - 2 of 2
Token: Russ Housley
No objection on the call, creation is approved.
Russ - will send the chairs to the IESG list after the call.
Sam - this is stunning - we approved with no discussion.
Russ - the discussion will be when we post the charter with the chairs...
(discussion of selected chairs here was not minuted)
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Internet Emergency Preparedness (ieprep) - 1 of 1
Token: Jon Peterson
Sam - please send this out for external review so I can ask people to kill it - should be no surprise to anyone.
Jon - IEPREP started rechartering to work on requirements in their requirements documents, but people were concerned that scope was too big and let WG make bad decisions with no supervision. Resulting changes to charter are from negotiations with Sam. Charter is typical for RAI, showing initial submission, plus approvals, plus ... not doing protocol development as such, they can identify mechanisms without specifying them.
Brian - what does mechanism draft actually do?
Jon - it's structured as a BCP, and it's very likely this will follow the MLPP-that-works approach that was used successfully.
Brian - this is very close to operational stuff - not a criticism, just an observation.
Jon - look forward to this debate and have my own reservation, but we're in a difficult position based on the way we've treated these guys historically, with concerns about whether the work should be done under our watchful eye or sent off to some other SDO.
Ross - this is the "teenaged daughter" problem, any parent knows about that. The problem is clueless people who don't understand IP can do more damage in another forum.
Sam - but this is closer to architecture than protocol work, and we're not necessarily the best place to do architecture work. Maybe this is an opportunity for us to build bridges with ITU.
Cullen - all the participants in this work could make the work happen at ITU, if that was the right answer.
Ted - concern was that ITU work might not use the IETF building blocks...
Brian - ... or might use them inappropriately.
Dan - are they meeting in San Diego?
Jon - unlikely
Brian - but they will start to meet. This is going for wider review, and you'll see lively discussion.
Jon - that's fine. Anyone with strong views should express them.
Magnus - forward RSVP requirements to TSVWG?
Jon - does charter name TSVWG now?
Magnus - no, just a generic statement
Lars - concerned that IEPREP might think they have token for RSVP.
Jon - these guys aren't chartered to do anything on RSVP, of course.
Magnus - existing text says "provide protocol requirements to appropriate WG" - that's fine.
Brian - "good enough" to go for comments - going out for IETF review, with Jon's newest text (from today).
4.2.2 Proposed for Approval
o Host Identity Protocol (hip) - 1 of 1
Token: Mark Townsley
Cullen - what changed?
Mark - NAT traversal and HIP API
Brian - and formatting error in box that's not a box anymore
Mark - did change "working with legacy NATs" text from previous versions to avoid IRTF-land.
Will mark a bunch of milestones "DONE" and send recharter announcement.
5. IAB News We can use, from Dave Meyer
IAB has been mulling over architectural statement involving anycast, and preparing for IETF meeting (arranging for BOF coverage, etc.)
Reviewed IAOC RFC Editor proposal and provided input.
Continuing to discuss the current JFC Morfin appeal, and the Todd Glassey complaint re. ietf mailing list suspension.
Trying to get Routing and Addressing Workshop minutes out, planning to summarize at joint meeting in San Diego. One of the key takeaways from the workshop was a desire to put serious effort into ID/locator split, architecturally.
Related work in V6OPS on Multihoming, Fred Baker has asked for input here.
Leslie - joint lunch in San Diego, Brian's proposed agenda was just about disjoint with Phil's, Leslie will send Brian a note about Phil's agenda and Leslie and Brian will coordinate.
Dave Meyer - could IESG name a counterpart for coordination?
Ross - thought workshop was very effective. Can coordinate with IAB.
Jari - can also help, whatever people think.
Brian - just need to work on getting the points across to people who weren't at the workshop.
6. Management Issue
None discussed on this call.
7. Agenda Working Group News
Jari Arkko - two WGs in my area are duelling (NETLMM and MIP6). NETLMM is a completely new protocol, some people saying we should use Mobile IPv6 in "proxy mode". NETLMM rough consensus was to go ahead with what they had, but they are looking at the objections to understand them better. This will delay moving ahead with protocol for some time, but it makes no sense to delay for months -- otherwise the decision will effectively be taken by others outside the IETF.
Brian Carpenter - RFC 4748 requires a small change to IPR boilerplate, have to tell community to change boilerplate, fix XML2RFC, etc. during ID submission blackout
Lars Eggert - we just approved the last rddp document, they will consequently close soon. the ips documents are on their way, too, so the storage area in tsv
will be shrinking soon. also, bellovin has written a motivation for a tcp-md5 replacement that he'll present at tcpm, in case people want to attend (there was iesg interest in this earlier)
Sam Hartman - concerned about lack of discussion on SPKM, doesn't look like people want to solve an important problem for NFS. Otherwise, lots of work going on, and if people responded to AD comments, I'd have more documents on the telechat agendas...
Russ Housley - very close to closing PKI4IPSEC group
Dan Romascanu - closing RMONMIB, announcing today (successfully, celebrate in San Diego) Network Management Research Group last week plus follow-on discussion about next steps. Working on minutes, will forward when available.
Mark Townsley - Two working groups [L2VPN and L1VPN?] stepping on each other's charters about how we set up LSPs, will meet in San Diego to resolve. ANCP also has issues to work in San Diego.
8. ANYTHING ELSE?
* Cullen - where are we on agenda changes? Changes are happening, but were still happening Tuesday/Wednesday.
* Brian - need to have discussion with Marcia on procedures in San Diego.