IESG Telechat 2008-03-27 (Narrative Minutes)

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the March 27, 2008 IESG Teleconference

Narrative Scribe: Spencer Dawkins <spencer@wonderhamster.org>

With corrections by Russ Housley.

1. Administrivia

1.1 Roll Call
1.2 Bash the Agenda

No changes to the agenda

1.3 Approval of the Minutes

2008 03 06 Minutes approved with no changes.

2008 03 06 Narrative minutes to be provided by Marc Blanchet.

1.4 Review of Action Items

o Sam Hartman to write a draft explanation of informational balloting. - done

o Lars Eggert to find primary and secondary experts for Port Numbers. - in progress

Lars - tied in with other port stuff - assign them now? or when we have guidelines documented?

Michelle - can assign them now.

o Cullen Jennings to develop a policy statement on how to handle errata. -

Cullen - still in progress, will send out a draft soon.

o Cullen Jennings to develop suggestions for tool changes for errata processing.

Cullen - still in progress, will send out a draft soon.

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o draft-ietf-mipshop-fmipv6-rfc4068bis-06.txt
    Mobile IPv6 Fast Handovers (Proposed Standard) - 1 of 4
    Note: Document Shepherd is Vijay Devarapalli
    Token: Jari Arkko

Jari - this is PS, do we have enough votes (with DISCUSSes resolved)? Yes. Expert reviews have been very helpful, have so many DISCUSSes because documents are so interesting. Changes from previous RFC from experiment is going to get documented.

Dan - more general issue here. This is my first Experimental -> PS draft as AD. Provide guidelines about how much information is present? Think Lisa had similar comment. Perhaps we should create shared knowledge.

Jari - wish I knew more about the results of the experiments. Have been implementations, think there have been interop tests, but security in previous RFC was impossible except for a toy network - that's what being fixed now.

Lisa - improvement may not be justification for PS - would we recommend this when people do MIP6?

Jari - fair amount of interest, people working on it, deserves to be PS based on scrutiny of this draft compared to other PSes. PS doesn't mean "always recommend you do this".

Lisa - if we always recommend it, should be PS. Not saying it should NOT be PS if we don't recommend it generally.

Jari - this is the only thing that makes you go really fast, if you want to go really fast.

Cullen - no one I'm aware of who's doing voice calls is hot to implement this.

Lisa - can applications do this?

Jari - sure, but then we're talking about doing mobility at a different layer.

Lisa - but then you wouldn't have to standardize this. Choice is unilateral, doesn't require interop testing. Not saying this should block the document, just something to understand.

Jari - this is particular approach at IP layer, helping handover. Will have words from the author on experiment results. Have three people holding essentially the same DISCUSS - could be simplified. Sent e-mail before the call on status. Lisa's DISCUSS would be handled when we get the text, Lars maybe the same. Russ's DISCUSS is mostly in RFC Editor notes now. Tim's DISCUSS is valid and should be addressed. Dave's DISCUSS will be addressed.

Tim - mandatory-to-implement, authors aren't convinced, and they haven't convinced me - no basis for interop with so many options. What's your view here?

Jari - had bigger reasons previously, IKEv2 solved a lot of these issues. How much should we be looking inside the IKEv2 spec? How much are we overriding? Would like recommendation, don't care what it is, would increase interop. But what if IKEv2 spec says something else?

Tim - will go back and look at this as well.

Jari - eager to resolve this. If we always use EAP, we'd make that MUST, but if it's one of the other two, we'd have to do something else. Should I be working on something besides experimental results?

(no answers)

o draft-ietf-netlmm-proxymip6-11.txt
    Proxy Mobile IPv6 (Proposed Standard) - 2 of 4
    Note: Document Shepherd is Jonne Soininen
    Token: Jari Arkko

Michelle - didn't get an evaluation note on this, either on IESG list or ticketing system.

Russ - automatically sent by the Tracker when the ballot is issued.

Document was DEFERred (minutes ago)

o draft-ietf-netconf-notification-12.txt
    NETCONF Event Notifications (Proposed Standard) - 3 of 4
    Token: Dan Romascanu

Dan - clarification question on Pasi's DISCUSS - no precedent for HTTP URL within IANA section?

Pasi - grepped over last 1000 RFCs, none had HTTP URLs.

Dan - is this an IANA problem?

Pasi - W3C has been using HTTP URLs instead of URNs and getting lots of attempts to retrieve DTDs (which they don't need).

Cullen - Chris and I have commented on this - it's a previous problem, previously discussed. Usually resolved by making it a URN (or something else).

Dan - agree there's no reason this has to be an HTTP URI, will check with authors about why they used HTTP URI.

Cullen - fair enough.

Dan - rest of comments are fine, Revised ID needed for another iteration.

o draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt
    RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite (Proposed Standard) - 4 of 4
    Token: Magnus Westerlund

Magnus - most of you have seen e-mails about this in last hour... starting with David. Framework is expected reading.

Dave - but it's mentioned in one place in the document. Is it that much work to add a clarifying sentence?

Magnus - framework document could have been clearer, this just isn't the right place to clarify.

Dave - but I wasted my time and there's only one sentence that clarifies what to do.

Magnus - will rev framework document anyway

Dave - let's handle it that way - I'll clear.

Jari - saw response 30 seconds ago, haven't read the previous e-mail on "supercedes vs obsoletes". May be making the right choice.

Magnus - working group has discussed, don't want to obsolete this.

Cullen - current v1 implementers (except one) don't expect to implement v2.

Jari - v6 headers are different. Realize that everything comes out zero lengths, but don't understand why you're treating these the same. They're different.

Magnus - realize, but field headers need to be there.

Jari - fields don't match - flow labels, etc.

Magnus - please respond to the author then.

Jari - didn't get inner/outer LIPID

Magnus - if you have tunneling, you don't know how many flows you have in the tunnel, inner headers will look random, so can't compress easily. Always assume it's random.

Jari - ah - assigning sequential behavior to outer header.

Magnus - inner flows will be sequential, outer flows will be random

Jari - what about multiple tunneling levels?

Magnus - would have different contexts

Jari - doesn't make sense to discuss on this call - will followup.

Magnus - authors have proposed text for Pasi's DISCUSS

Pasi - this came as a surprise to other people - start out secure but introduce security hole with RoHC.

Magnus - packet loss will give you similar behavior in extreme conditions.

Pasi - RoHC will change/break certain guarantees

Magnus - not sure how to fix this/if it can be fixed, just need to be aware of this

Pasi - did fix this in IPsec - did MAC on both compressed and uncompressed contents.

Magnus - layer below RoHC needs to handle this (if you have requirements).

Pasi - will reply to authors and make sure this gets handled.

Tim - I just cleared, explanation was fine. Was surprised that text had disappeared, but authors explained why.

2.1.2 Returning Item
o draft-ietf-imapext-sort-20.txt
    INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS (Proposed Standard) - 1 of 3
    Token: Lisa Dusseault

Lisa - author has 27 votes and has gone through 3 ADs, but would like Lars to hold his DISCUSS for IANA

Lars - weird that IANA note covered only half the information

Michelle - checking this now...

o draft-ietf-nsis-ntlp-15.txt
    GIST: General Internet Signalling Transport (Proposed Standard) - 2 of 3
    Note: WG Shepherd: John Loughney (john.loughney@nokia.com). Abstainers please re-review your motivations in regards to the updated version.
    Token: Magnus Westerlund

Pasi - wondering whether to ABSTAIN, no proposed objections to the document.

Magnus - need to launch this document somehow, hoped that ABSTAINers would check the new version.

Lisa - has document changed in last year?

Magnus - don't think new version will change RTG AD views, but can't remember Lisa's.

Lisa - was pretty general ABSTAIN because I didn't think the document could be fixed. Haven't refreshed state on this one.

Ron - this was a very big document in page count and content. Needed to address motivation for this.

Magnus - but this is why NSIS got chartered at all - would be used in contexts other than QoS. Was chartered to do RSVP-lite, but became heavier than most people wanted. Was to develop generalized solution - clear from the charter.

Ron - could document explain this? Also - machinery is big and complex and document has so many words that I couldn't build anything from the spec.

Magnus - then why do we have 6 interoperating implementations?

Ron - from the document or from talking to other implementers.

Magnus - at least some are from the document. Other protocols are much worse. Why-NSIS is in the architecture document, published several years go.

Cullen - have read the documents and played with the implementations, don't see how NAT traversal works as documented.

Ron - would it help to do an informal call (as SHIM6) and let you convince us?

Magnus - very similar to SHIM6.

Russ - yes, don't have time to do that on this call. Next week or three weeks.

Lars - working group and authors have done massive revision, it's not a quick edit. Not convinced ABSTAINing ADs have given this version enough review. Shouldn't have let WG spin their wheels if we weren't going to seriously look at it. Document is required for everything in NSIS. If we kill this, we kill NSIS. That's fine, but we should have said something six months ago. "Can't fix" is pretty general. Working group has outlived its chartered environment and charged on unsupervised for a couple of years, now has something that is great for the working group and the rest of us don't get it. If we kill NSIS, we should kill other stuff.

Pasi - would ballot NO-OBJ if it's experimental (several others said "me too")

Lars - what's the experiment? This is purely the transport part, not about the signaling applications.

o draft-ietf-mip6-hiopt-11.txt
    DHCP Options for Home Information Discovery in MIPv6 (Proposed Standard) - 3 of 3
    Note: Document Shepherd is Basavaraj Patil
    Token: Jari Arkko

Lars - pretty good chance new version would address my DISCUSS

Jari - agree with Dave's comment, you'll get an answer.

2.2 Individual Submissions
2.2.1 New Item
o draft-ellermann-news-nntp-uri-10.txt
    The 'news' and 'nntp' URI Schemes (Proposed Standard) - 1 of 1
    Token: Lisa Dusseault

Lisa - RFC 1738 isn't ready to go Historic yet, this is just one step.

Jari - I'll clear, I just wasn't sure.

Lisa - Frank is submitted text for Tim, also will address Chris

Pasi - document also uses real domain names.

Lisa - agree with Pasi

Chris - document is using example.com some places, but it's appropriate to point to real URLs if you're showing something on the Internet. It's in appendix, not normative, probably fairly stable since it's a large archive site.

Jari - if no one will resolve it, should be example TLD. If it is, should be asking site if it's going to be stable.

Chris - not needed to implement the spec.

Lisa - resolved by a person, not an automated program.

Cullen - heard that one before... could delete this and still implement. Didn't comment on this, don't care.

Chris - feel pretty strongly that we should be able to use URLs in specifications when it's appropriate. Understand threat of automated processes adding load, although I think that's overblown. Agree you could delete appendix.

Lisa - "example as of 2008?"

Chris - fine with me

Pasi - works for me

Cullen - if this had my domain name, I'd object. Works for me, don't care, we use URLs in references all the time.

Lisa - will mention getting approval from domain name holder to Frank.

2.2.2 Returning Item
o draft-narten-iana-considerations-rfc2434bis-09.txt
    Guidelines for Writing an IANA Considerations Section in RFCs (BCP) - 1 of 1
    Token: Russ Housley

Russ - Mark wasn't happy with Thomas' notes?

Mark - you have one RFC editor task. I responded, it's one word, but it's a cut-and-paste error and it's significant - just making sure it gets fixed.

(Mark cleared later in the telechat)

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
o draft-ietf-mipshop-3gfh-05.txt
    Mobile IPv6 Fast Handovers for 3G CDMA Networks (Informational) - 1 of 4
    Note: Document Shepherd is Vijay Devarapalli
    Token: Jari Arkko

Jari - Michelle, asking about informational document taking out two entries from standards-action registry, but this registry also allows Informational (neighbor discovery)

Michelle - review was looking at something that specified standards-track.

Jari - IANA actions were confusing (also to Gen-ART). Will fix in version 06.

Jari - Lars was concerned that other RFC will be PS and this is Informational. Have exchanged e-mail.

Lars - understand your point. WG has approved this, so it's not some random Informational, but we don't have guidance here. This was DISCUSS-DISCUSS. Document looks like specification, uses these bits, but it's Informational - why?

Jari - not on standards track because it started out as "using foo with bar" - added bits later, hasn't gotten enough review to justify standards track. Link layer guys aren't interested and aren't engaged.

Lars - then why are we using one of 8 bits for something that won't be used? Uncomfortable with casual allocation of 1 bit out of 8.

Jari - similar to other situations - neighbor discovery, did run out, recently defined extension option, don't see the problem, don't see lots of uses for remaining bits.

Cullen - why not have base spec reserve bit for informational document? they're going through at the same time ("informative reference to other document")

Jari - this is the document that's using the bit.

Cullen - we usually update the defining RFC - assume this would have to be PS to update a PS.

Lars - will put DISCUSS on behalf of IANA

Lars - need pointer to some 3GPP spec explaining use of these bits

o draft-ietf-ccamp-gmpls-mln-eval-05.txt
    Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) (Informational) - 2 of 4
    Token: Ross Callon

Ross - don't need to DISCUSS today, already in e-mail exchange with authors.

o draft-ietf-ccamp-gmpls-mln-reqs-08.txt
    Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) (Informational) - 3 of 4
    Token: Ross Callon

Ross - same as previous document, also revised ID needed.

o draft-ietf-l1vpn-applicability-basic-mode-04.txt
    Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode (Informational) - 4 of 4
    Token: David Ward

Dave - Tim is right, something needs to be cleared up in those sections.

Mark - revised ID needed, if you take the COMMENTs that I almost made into a DISCUSS :-)

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD

3.2.1 New Item
o draft-ogier-ospf-dbex-opt-03.txt
    OSPF Database Exchange Summary List Optimization (Informational) - 1 of 1
    Token: David Ward

Jari - Informational document that changes behavior of OSPF, which is a full standard. Very happy with document, why not PS?

David - no interest in the working group to actually write the code

Ross - no implications for bits on the wire, you just send fewer

Mark - decision to go PS isn't based on implementations

David - was discussed in WG

Magnus - procedural error

Jari - should be able to do this, but it should be noted

Ross - updating informative text in a full standard, that's why it's not standards-track

David - not sure how to proceed here. No change to bits on the wire....

Mark - why publish at all?

David - it's interesting information.

Jari - this changes what "Update" header means.

Ross - observes that there is some content in original specification that isn't required.

Tim - claim that it DOESN'T update, because change is invisible to peers? Peer can't tell if you've implemented the optimization. Complimentary, add-on, but not an update?

Magnus - but if I extend and require a PS extension, that's fine, if I require an informational extension, that's broken. That's why we shouldn't be mucking with standards track definitions.

Lari - what if it was a PS updating a full standard - same thing?

Magnus - but it's standards-track

Ross - can imagine Experimental extension to standards track

Magnus - but that isn't changing standards-track behavior, this would be

Dave - understand the concern, but now all implementations would interoperate fully.

Russ - then I don't see the problem

Mark - but I see the other point, if you change behavior that won't change anything, you don't have anyone writing the code, you don't know what's coming down the pike next, you're setting yourself up for trouble.

Ross - safer to write it down

Mark - if you have code for it

Ron - now we're discussing routing protocol document criteria

Mark - but they're the same as any other documents. If no one has interest in writing code, don't see compelling reason to document.

Magnus - and people would be fine publishing at PS - don't get the counterargument for Informational.

David - but we have requirement for implementation to publish OSPF documents at PS, and we don't have anyone planning to implement. Doesn't change table size, doesn't change time to converge. Just sends fewer bits and reduces CPU overhead during refresh.

Mark - getting yourself wrapped around dogma here. IETF consensus is that RTG area as a whole isn't "special". WGs can have special requirements on individual documents, but we've used exceptions before (4-byte AS). When you have significant changes to OSPF, require implementations for PS, but this is an insignificant change.

David - started out at EXP, went INFO.

Mark - that's broken, too.

David - protocol experts said no reason to experiment.

Mark - then make it PS. Whole point is to make sure you haven't broken anything - consensus is that you've already looked at this.

Ross - OK with PS or INFO. Leaning towards INFO because it's completely backwards-compatible.

Mark - at least two ADs are sticking Dave here. Fundamental problem is that WG thinks code is required and INFO is "get out of jail free".

David - but that's what Bill and Alex wrote.

Ross - they allowed WG-specific procedures.

Magnus - WG thought could update standards-track documents as INFO - broken.

Jari - what can I do to make this document go forward? If I remove, will someone else add one?

Magnus - seriously considering that....

Russ - Did you consider AD-sponsored individual submission on standards track?

David - let me talk to the WG chairs, we can probably go PS.

Russ - does need to be re-last called.

Mark - just looked at Bill/Alex document, OBSOLETEs previous requirement for implementation and INFO doesn't appear (except as document status) - anyway, we can go offline.

3.2.2 Returning Item
NONE
3.3 Independent Submissions Via RFC Editor

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
    NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Multiparty Multimedia Session Control (mmusic) - 1 of 1
    Token: Cullen Jennings

Cullen - changed text is mostly about ICE work concerns. Most other concerns have been resolved. Want to talk about getting the ICE stuff right. Are TSV ADs ok with current version of charter?

(Lars phone crashed - we talked later in the call)

Magnus - fine with that text.

Lars - for the time being, we leave ICE in MMUSIC.

Cullen - just to move forward. Remember, all we're doing is approving text going out for comments.

Lars - fine.

Cullen - we have an RTSP/SIP/IPTV thing coming up too, not dealing with this now.

Amy - Will go for external review with new text from Cullen.

4.2.2 Proposed for Approval
    NONE

5. IAB News We can use - Loa

We are preparing the retreat

We had a good tech chat yesterday (on time, by Peter Lothberg), it resulted in an action item, exchanging IETF contacts with people working with time (Peter to write a proposal).

Olaf - IETF has received strange request from UN via ISOC asking for annual report on improved cooperation. Quite unexpected, publicly viewable so you may get questions. ISOC looking at whether there are political considerations in play and what W3C and similar groups are doing in response. Most likely action is that ISOC will point to our liaison page in May or June, pointing out that we have an open process and play well with others.

http://wiki.tools.isoc.org/Policy_Activities/UN_report_request [http://wiki.tools.isoc.org/Policy_Activities/UN_report_request]

6. Management Issue

6.1 Updating media registration for audio/3gpp and video/3gpp (Magnus Westerlund)

Magnus - we're actually moving back change control to 3gpp, so moving registrations to historic.

Cullen - RFC 3839 was standards track - need this to be a draft?

Chris - if you move to Historic, you can do that with Last Call (but you do need a Last Call).

Cullen - this was very contentious and people thought it wasn't appropriate - it's a container type. That's why it got wider review - it didn't meet our guidelines. Totally agree we need this update, questioning whether this is the right way to do the update. Should be someone who can write the 3-page draft... Change control for some items stays with IESG, right? And this should be the APP ADs, not the TSV ADs... Just republish the old document pointing to the right place and you'd be done - consistent with what we did with 3GPP2, etc.

Magnus - goal was to have SDOs procedures in the same document.

Cullen - true. I hadn't thought about that.

Magnus - wasn't sure we required Last Call for Historic

Chris - stable reference?

Magnus - is to another SDO's specification.

Chris - to a dated version, guaranteer stable? as long as they don't re-release with the same name, that's what's needed.

Magnus - do need to talk about how we track their changes

Cullen - think this requires IESG approval of changing IANA considerations

Loa - have same issue with ITU-T - they re-use recommendation names.

Russ - we now point to recommendation-year.

Magnus - need to have a discussion about this.

Chris - can't approve this management item now. Would be OK if we replace the RFC, but if you look at IANA registry, the RFC IS the current template. You want IANA to put current 3GPP text in registry? Don't think we've done that before.

Magnus - yes, we have.

Michelle - if we have registration through a document, we point to the document.

Chris - I think we only use the template if there's no RFC

(some during-telechat poking around through the registries looking for templates and pointers in registries)

Chris - not insisting that this change goes through a new RFC - although that may be the quickest way.

6.2 TMDA (Russ Housley)

Russ - Working group chairs want this back, we never had a policy about TMDA in the IESG statements about spam, want to get this back quickly, should mention this in the policy.

Chris - don't see any rules that would prohibit this.

Russ - people working on mail think current spam policy prohibits TMDA - there's more than one policy statement, so figuring this out isn't as easy as it might be..

Cullen - think Sam was the one who had input about this, but we did it anyway. We had 10,000 messages in some queues, that would never be processed.

Chris - every queue I moderate has a different password, substandard

Cullen - tools are so poor they don't get used, knowlegeable e-mail people say TMDA is evil, chairs say they are drowning....

Russ - could Chris look at current spam policies to see what's needed to allow TMDA opt-in?

Chris - thought that might coming....

6.3 Expedited publishing for draft-ietf-rohc-rfc3095bis-rohcv2-profiles (Magnus Westerlund)

Magnus - Have 3GPP agreement to point to this specification if it's approved in time (and date is really short-timeframe). Draft wasn't approved today but expect approval in a few days.

(Several ADs said "works for me").

6.4 IESG Retreat Location (Russ Housley)

Two camps plus silent people re: downtown vs jersey shore.

Ross - prefer NJ and can go either way.

Ron - compromise in Jersey City, etc. so it's cheap to get around?

Jon - but they're pretty wretched.

Cullen - we need to decide pretty soon, people are making travel arrangements

Russ - hearing silence while trying to create a compromise. People said they didn't want to have to move far when changing meetings (to NANOG).

Dan - if I'm in the rough, I can adapt. Can't afford the rate for more than one night, but can stay with friends.

Jari - don't care where we are as long as we can get there from the airport in a reasonable way.

Alexa - nothing special about any locations, but we can definitely go to New Jersey - but we'll lose the Hilton if we don't commit.

Ross - does $350/night at the Hilton include everything?

Alexa - none of the Manhattan locations include food, ones in the suburbs would ...

Tim - we had distances but not travel information for these properties

Russ - does anyone object to going to the Hilton New York for the retreat? No objections

7. Agenda Working Group News

Jari Arkko

- Pasi's discuss suggested it would be appropriate to support multiple prefixes because that's the way IPv6 works, but there's WG pushback. Thinking we should do it - does anyone else have opinions? (Anyone left on the call?)

- Pasi - good to have document that provides requirements for access networks that use IPv6, and this really requires multiple addresses and prefixes. 3GPP fixed their specs, not completely. Other SDOs also specifying "IPv6-lite", and multiple prefixes gets left out often. Breaks SHIM6, breaks some parts of Mobile IP... Also IPv6 address allocation guidelines aren't clear on whether prefixes are /56 or /58, but other SDOs are doing just /64s, and this is getting hard-coded in lots of places - will be difficult to fix later.

- Jari - document name is rfc3177bis, lots of history you may not have seen with other address allocation bodies.

- Pasi - concern is that people will continue to NAT home networks because providers don't provide proper allocations, etc.

- Jari - also some IETF things we need to get right. Any comments on NetLMM question? None, so will require change to be done.

Lisa Dusseault

- IDN proposed working group - lots of discussion and changes, not happy because changes won't help working group move faster - important to scope the work, but other discussions aren't helping. Design team doesn't agree on everything, which is true but normal. Just send out for external review before telechat?

- Russ - makes sense given amount of change. External review and then telechat. Vint is still on board to chair and engaging the working group.

Pasi Eronen

- have received two charter proposals for IPsec maintenance group people want to set up.

- Jari - people were against this. Have they changed their minds?

Chris Newman

- LTRU - JFC has PR action, but everyone believes he's posting under another identity. BCP says you can block another e-mail address, but how to know it's the same person who is covered by the PR-action? Proposed ad hoc mechanism, chair has proposed on list and implemented, expecting appeal.

- Russ - LB says he won't do anything to prove his identity and won't appeal. Still might get ugly, but there you have it.

- Cullen - had similar situation where person wasn't willing to have a phone call, and postings ended.

- Ron - should probably mention phone calls as an option in BCP

- Russ - is purposely vague

- Chris - impressively vague - Marshall knew what he was doing

Magnus Westerlund

- closed MIDCOM (at least one "yahoo" happened here)