IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2009-03-12. These are not an official record of the meeting.

Narrative scribe: John Leslie (The scribe was often uncertain who was speaking.)

Corrections from: Dan, Adrian, Pasi, Russ

1 Administrivia

  1. Roll Call 1134 EDT Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2 Protocol Actions

2.1 WG submission

2.1.1 - New Items

  1. IPsec Channels: Connection Latching (Proposed Standard)
    draft-ietf-btns-connection-latching-08
    Token: Tim Polk
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-02-25]: This is good stuff, but I had a number of issues relating to imprecise language to describe what exactly is required. Note that as I'm doing this review it is 2AM so it could be just that I'm too tired to understand.
      • "The REQUIRED set of parameters bound in IPsec channels is:..."
        Do you allow both normal IDs and the public key ID introduced in the BTNS core spec (which is an RFC by now, by the way)? See also below?
      • "The SAs that protect a given IPsec channel's packets may change over time in that they may expire and be replaced with equivalent SAs, or may be re-keyed. The set SAs that protect an IPsec channel's packets need not be related by anything other than the fact that they must be congruent to the channel (i.e, the SAs' parameters must match those that are latched into the channel)."
        RFC 4301 talks about partial and exact matches -- presumably you mean the latter above.
        Also, if non-BTNS IDs are allowed, is it OK for a channel to be bound to ID = IP 1.2.3.4 at one instant in time when the peer's cert is CE1 and the used CA was CA1, and then later again bind to ID = IP 1.2.3.4 but with *different* peer cert CE2 and possibly a different CA CA2? I.e., do you bind to the *name* or the key behind it in those non-BTNS cases?
      • "Implementations that provide such programming interfaces SHOULD make available to applications any available NAT-related information about the peer: whether it is behind a NAT and, if it is, the inner and outer tunnel addresses of the peer."
        I'm curious why this end's NAT data would also not be relevant for this. Or maybe it is not, but after thinking about this for a couple of minutes I can't decide which way it should be. Has the WG considered providing information about the implementation's own perceived status behind a NAT...
        What is "inner and outer tunnel address"? Since you are mentioning this in the context of NATs, do you really mean IPsec tunnel mode inner and outer addresses, or the peer's address inside and outside the NAT?
        Finally, even if NATs are not involved, wouldn't tunnel mode outer addresses be interesting anyway?
      • "Implementations SHOULD create IPsec channels automatically bydefault when the application does not explicitly request an IPsec channel."
        Really? Without no policy whatsoever... I think there should be a knob to enable BTNS, as there would likely be uses of a BTNS capable device where the small additional IKE negotiation delay for a large number of connections would be unacceptable.
      • "CLOSED (by the ULP, the application or administratively) and always have an associated owner, or holder, such as a ULP transmission control block (TCB)."
        Comment: As you mention below this state doesn't really exist any measurable time if the ULP closed it. And it couldn't either, because there would be no TCB to associate with. I wonder if the name of this state would be better as "CLOSING".
      • "informed except where the ownser caused the transition, in which case"
        Typo
      • "CREATE_LISTENER_LATCH(3-tuple, [type and quality of protection parameters]) -> latch handle If there is no conflicting connection latch object in the LISTENER state for the given 3-tuple (local address, protocol and local port number), and local policy permits it..."
        It is interesting that here you have "local policy permits" clause, but for CREATE_CONNECTION_LATCH you do not have one. Is this deliberate, or a mistake?
      • "If no connection latch exists in the ESTABLISHED states with the same 5-tuple, and if there exist no child SAs that match the given 5-tuple, then the system MUST initiate an IKE exchange to setup child SAs for this 5-tuple."
        .. a bit later ...
        "If there exist no child SAs matching the given 5-tuple then the key manager SHOULD try to create a pair of child SAs for that 5-tuple."
        Why the duplication? Or is there some subtle difference that I am not seeing?
      • "CREATE_CONNECTION_LATCH"
        This description does not tell me what happens in the different error cases, e.g., when the if clauses are not fulfilled. For instance, what if there is an existing latch for this 5-tuple and it would even match the required properties?
        When the key manager informs a ULP that a connection latch has been administratively transitioned to the CLOSED state then connection-oriented ULPs MUST act as though the connection has been reset by the peer. Implementations of ULPs which are not connection-oriented, and which have no API by which to simulate a reset, MUST drop all inbound packets for that connection and MUST NOT send any further packets -- the application is expected to detect timeouts and act accordingly.
        How does a "non-connection oriented ULP" "drop all inbound packets for that connection"?
        SA that protected it could expired before..."
        expire? could be expired?
      • "When a connection latch is broken a BITS/BITW/SG implementation may have to fake a connection reset by sending appropriate packets (e.g., TCP RST packets), for the affected connections."
        Is there a corresponding message that could be used with UDP? If not, please state early on that the BITS implementations can only support TCP.
    2. Lars Eggert: Discuss [2009-02-23]: [I-D.ietf-btns-prob-and-applic] has been published as Informational (RFC5387) and this is hence a DOWNREF. I believe it can simply move to the Informative References section, if the first reference to it in the introduction is changed to refer to [I-D.ietf-btns-core] instead (which has since been published as PS as RFC5386).
      Comment [2009-02-23]: I'd be better if Figure 4 and its explanatory text in Section 2.2.2 used the IP ranges set aside for documentation and dynamic port numbers (> 49152).
    3. Russ Housley: Discuss [2009-02-25]" The Gen-ART Review by Elwyn Davies on 24-Feb-2009 includes some very significant comments. Please respond to this review. The review can be found at: http://www.softarmor.com/rai/temp-gen-art/draft-ietf-btns-connection-latching-08-davies.txt
    4. Cullen Jennings: Discuss [2009-02-26]: Imagine the case where a an ULP has sent 30 k of data and stuffed it into a TCP connection but the kernel is still buffering that data and it has not been sent yet. At this point the flow transitions to the BROKEN state. Does the 30k of data sill get sent or not? I could not seem to find the answer to this.
      I would not be surprised if the answer is there and I just missed it so hopefully this can discuss can be resolved with no change to the document.
      Comment [2009-02-26]: I like the concept but wIthout the API's is nothing to standardize here - there no change on the wire, there's no change to anything else. How would a vendor even says they are or are not complaint with this? How would one move it to Draft etc. I think this should normatively depend on the API draft - it means nothing without it.
    5. Chris Newman: Comment [2009-02-25]: I support advancement of this technology, but believe it needs some revision to address comments from Elwyn Davies and IESG discuss positions.
      While I wouldn't necessarily hold up this work waiting for draft-ietf-btns-abstract-api, I will observe that the longer the gap between publication of this draft and the abstract API (or at least a subset of the abstract API necessary for an application to query channel binding and encryption strength), the less likely we'll get deployment of this technology by applications. Application developers have already invested time integrating with TLS stacks to get channel security. They will not spend time integrating with IPsec unless the extensions to the sockets API are the same across platforms that offer socket (Linux, Solaris, MacOS, WINSOCK). Even then, this will be a tough sell.
      Without the application API, this technology provides no useful services to _applications_ as the application can not know whether the channel is protected and thus can not indicate such to the end-user. Only a tiny group of power-users would be capable of configuring their IPsec stack to require IPsec to particular hosts/subnets and understand the security implications of doing so for applications. That's simply not a useful application service.
      It may be wise to design enough of the abstract API (and perhaps non-normatively suggest a sockets/WINSOCK style API extension) to make this useful to applications before publishing this. After all, the draft includes a "SHOULD" that can't be done in an interoperable fashion without such work.
    6. David Ward: Discuss [2009-02-24]: A few unrelated comments:
      - Once one can latch flows to an IPsec tunnel then one may want to latch flows to a backup tunnel so that in the event of a failure there is orderly migration of traffic
      - A reader/implementor has to derive the action to take if a tunnel goes down and there are other possible routing paths to the destination and what is supposed to happen. I suggest that there is a brief section on failure cases
      - How can this technology be used for IPsec VPNs? Can a router latch flows between two VPNs or AFBRs? How?

    Telechat:

  2. Netnews Architecture and Protocols (Proposed Standard)
    draft-ietf-usefor-usepro-14
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. (none)

    Telechat:

  3. NETCONF Over Transport Layer Security (TLS) (Proposed Standard)
    draft-ietf-netconf-tls-07
    Token: Dan Romascanu Note: Mehmet Ersue is the PROTO-shepherd
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-03-11]: I expected to ballot Yes on this but at the end I found I was missing some fundamental information. My understanding of RFC 4741 is that authentication/authorization is something left to the protocol that carries NETCONF messages. RFC 4742 (NETCONF over SSH) for instance says:
      "The identity of the server MUST be verified and authenticated by the client according to local policy ..."
      "The identity of the client MUST also be verified and authenticated by the server according to local policy ..."
      However, the current document has explicit guidance about server side authentication, but not much about clients:
      "The server may have no external knowledge on client's identity and identity checks might not be possible (unless the client has a certificate chain rooted in an appropriate CA). If a server has knowledge on client's identity (typically from some source external to NETCONF or TLS) it MUST check the identity as described above."
      This seems to be in violation of RFC 4741 thinking:
      "It is further expected that the identity of each end of a NETCONF session will be available to the other in order to determine authorization for any given request."
      But I can't think that the authors would have missed client side authentication; its so fundamental to configuration operations to network devices. What am I missing? Is there some other authentication layer for client/user side somewhere? If there is not, I cannot see how you can allow one-side TLS authentication except maybe for reading information.
    2. Pasi Eronen: Comment [2009-03-12]: Couple of minor comments/suggestions:
      Section 4 should explain what "third party authentication" means, since it's not obvious from the context, and the term is not used in any of the listed references either.
      To me, references RFC4642 and and RFC5277 don't look normative, so they probably should be in the Informative References section.
    3. Chris Newman: Comment [2009-03-11]: I support Jari and Tim's discuss positions.
      If there is a need for authentication mechanisms other than TLS client certificates for this transport, a simple protocol design pattern would be to write a SASL profile for netconf for use in conjunction with TLS. That's a rather simple project (a couple pages) and I'd be glad to assist if needed.
    4. Tim Polk: Discuss [2009-03-11]: I agree with Jari's discuss (and confusion) concerning client authentication.
      Specifically, I had expected to find that this specification required servers to check the clients identity by either (1) mutually authenticated TLS using certificates (with the same checks identified in 3.1) or (2) by some other mechanism that satisfied local policy. I had also expected to see that certificate-based client authentication was a MUST implement.
      Note that section 2.1 seems to limit implementations of this protocol to TLS cipher suites that provide certificate-based mutual authentication. This seems inconsistent with section 3.2 permitting connections without verifying the client identity at all...

    Telechat:

  4. The Lemonade Profile (Proposed Standard)
    draft-ietf-lemonade-profile-bis-12
    Token: Chris Newman Note: Glenn Parsons is the Document Shepherd
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-03-12]: Good work. Its nice to see an explanation how to use existing protocol components to deal with the limits of a particular environment.
      I would have voted Yes on this if it weren't for the fact that I'm not sufficiently familiar with all parts of the protocol set to say for sure that you didn't miss anything.
    2. Lars Eggert: Comment [2009-03-11]: INTRODUCTION, paragraph 2: "The Lemonade Profile"
      Title doesn't describe the content. Title of RFC4550 was much clearer. Suggest to use it.
    3. Pasi Eronen: Comment [2009-03-11]: Hannes Tschofenig's SecDir review identified a couple of places that would benefit from some clarification of the text, and provided editorial comments that should be taken into acccount.
    4. Russ Housley: Discuss [2009-03-11]: This document will obsolete RFC 4550. Please add a summary of the changes between this document and RFC 4550. (Section 12 does not provide what I am seeking, and it should be removed prior to publication as an RFC.)
      Comment [2009-03-11]: The 2nd paragraph of Section 7 says:
      "Note that the explicit usage of [SUBMIT] means that when opening a connection to the submission server, clients MUST do so using port 587 unless explicitly configured to use an alternate port [RFC5068]. If the TCP connection to the submission server fails to open using port 587, the client MAY then immediately retry using a different port, such as 25. See [SUBMIT] information on why using port 25 is likely to fail depending on the current location of the client, and may result in a failure code during the SMTP transaction."
      It is unclear to me if this is a new MUST requirement or if it is intended to be clarification od one that is already in [SUBMIT]. Please add text to clear this up.
    5. Tim Polk: Discuss [2009-03-12]: This is a discuss-discuss. I will clear or revise to make it actionable after the call.
      (1) I was wondering why the following SHOULD from 4550 was removed from the security considerations in this version:
      "Lemonade clients SHOULD use TLS-protected IMAP and mail submission channels when using BURL-based message submission to protect the URLAUTH token from interception."
      (2) The Lemonade Message Delivery Agent is optional, but seems to be a significant enhancement in the architecture. However, [SIEVE] is never referenced or discussed in the security considerations. Is this an oversight, or does the wg believe that introducing the message delivery agent does not impact the security considerations? (If it does have impact, a sentence or two and a pointer to [SIEVE] in section 10 would probably suffice.)
      Comment [2009-03-12]: Shouldn't this document update 4469 and 4467 since it adds a new capability (URL-PARTIAL) to the CATENATE and URLAUTH extensions?
      I also think the definition of the new URL-PARTIAL capability should be added to the replacement for section 12 (summary of changes wrt 4550).

    Telechat:

  5. Heartbeat Mechanism for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netlmm-pmipv6-heartbeat-05
    Token: Jari Arkko
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-03-11]:
      Section 3., paragraph 0: "3. Heartbeat Mechanism"
      DISCUSS: Most of the SHOULDs in this section can be upgraded to MUSTs. The "always respond" SHOULD actually needs to become a MUST, because otherwise the mechanism doesn't work. I'd also like for the HEARTBEAT_INTERVAL SHOULD to become a MUST, or else explain under which conditions it is OK to go lower.
      Section 3.2., paragraph 0: "3.2. Restart Detection"
      DISCUSS: Instead of relying on non-volatile memory for a restart counter (which is a pretty limiting requirement), why don't you simply create a random nonce at boot that you use until a restart? Peers can then simply detect that you rebooted because they see a different nonce. (Or am I missing something?)
    2. Pasi Eronen: Discuss [2009-03-12]: I have reviewed draft-ietf-netlmm-pmipv6-heartbeat-05. Overall, the document looks good, but there's one thing that should be fixed before the document is approved:
      The text about IPsec (in Section 6) says heartbeat messages are protected the same way as BU/Back in RFC 4877. But PMIPv6 itself does not use the RFC 4877 approach to IPsec -- the PMIPv6-IPsec interaction is much simpler, and is described in RFC 5213. Changing the text to say "the same way as BU/BAck in RFC 5213" should be sufficient.
    3. Tim Polk: Discuss [2009-03-12]: In section 3.2 there seems to be a requirement for non-volatile memory. This seems out of place in a protocol specification. I would prefer to see the section rewritten to explain what state needs to be preserved across restarts. I am interested in discussing this briefly on the call. If there is sufficient precedent/support for imposing these kinds of constraints in protocol specifications, I will clear on the call.
      Comment [2009-03-12]: In Section 3, paragraph 3:
      "The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than 30 seconds. Sending heartbeat messages too often may become an overhead on the path between the MAG and the LMA. The HEARTBEAT_INTERVAL can be set to a much larger value on the LMA, if required, to reduce the burden of sending periodic heartbeat messages."
      By omission, the last sentence implies that the HEARTBEAT_INTERVAL should not be set to a much larger value on the MAG. If there *are* reasons not to configure larger intervals on the MAG that should be noted here...
    4. Dan Romascanu: Comment [2009-03-12]: This is a calear and well-written document that could benefit from a few clarifications.
      1. I suppose that a future chartered work in this WG will add a management interface - MIB module or similar. It would be good to mention what information is configurable and may be important to be exposed for an operator: certainly configuration of the parameters described in Section 5, maybe notifications of the failuere and restarts detections, other?
      3. HEARTBEAT_INTERVAL
      "This variable is used to set the time interval in seconds between two consecutive Heartbeat Request messages. The default value is 60 seconds. It SHOULD NOT be set to less than 30 seconds."
      Would not it make sense to define a high limit here as well?
      3. MISSING_HEARTBEATS_ALLOWED
      "This variable indicates the maximum number of consecutive Heartbeat Request messages that a PMIPv6 node can miss before concluding that the peer PMIPv6 node is not reachable. The default value for this variable is 3."
      Should not rather be 'are not responded' than 'can miss'?
    5. David Ward: Discuss [2009-03-11]: Why isn't this based on BFD with large intervals?
    6. Magnus Westerlund: Comment [2009-03-11]: Supports Lars Eggert's Discuss.
      I think the document would be clearer if there where place holder text for making clear the cope points that are to be assigned to the MH type and the option. That way when reading the ready RFC one gets the numbers directly instead of having to go to the IANA section. In general the text is not formulated to make it clear what IANA assigns.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications (Proposed Standard)
    draft-farrel-rtg-common-bnf-08
    Token: Ross Callon
    Extracted from Balloting:
    1. Pasi Eronen: Comment [2009-03-05]: I think it would be useful to mention somewhere in Section 1 the biggest difference to ABNF: in ABNF (as defined in RFC 5234) the terminals are integers (characters/bytes), while in RBNF they're "objects" (some kind of message elements, but not individual bytes or characters).
      Thus, the two are not really interchangeable -- and it's not clear that talking about e.g. converting existing specs to use ABNF even makes sense (if the spec assumes that terminals are message elements, then RFC5234 ABNF just won't work).
      (Of course, it would be possible to specify RFC5234-like BNF notation that allowed other kinds of terminals than integers, but that would not be RFC5234 any more.)
    2. Magnus Westerlund: Discuss [2009-03-12]:
      Section 2.2.5:
      It is not clear that the repetition operator is postfix. Can you please make an explicit statement about that.
      Section 2.4: Concatenation has higher precedence than the Alternative operator. Thus, the text in [RFC2205] SHOULD be interpretted as shown in formulation a.
      Similarly (from the same section of [RFC2205]) 
                 <flow descriptor list> ::=
                            <FLOWSPEC>  <FILTER_SPEC>  |
                            <flow descriptor list> <FF flow descriptor>

     SHOULD be interpretted as

           <flow descriptor list> ::=
                         ( <FLOWSPEC> <FILTER_SPEC> ) |
                         ( <flow descriptor list> <FF flow descriptor> )
      The spec is fuzzily written here. It is clear from the definition which interpretation that is the correct one. Thus using SHOULD here is very confusing. If one has one correct interpretation then that needs to be used. So please change SHOULD to SHALL.
      Comment [2009-03-12]:
      Section 2.2.2: Meaning: The objects or constructs MUST be present in the order specified.
      This has an implicit assumption about reading left to right and upper line to lower line. Maybe one should be clearer on this.
      Section 2.2.5: Note 2:
      I think you should include paranthesis around the second alternative to make the recursive statement clear. Seems to be breaking the recommendation from earlier.

    Telechat:

  2. IMAP Response Codes (Proposed Standard)
    draft-gulbrandsen-imap-response-codes-07
    Token: Chris Newman
    (no Balloting link) Extracted from Balloting:
    1. Pasi Eronen: Discuss [2009-03-12]: I have reviewed draft-gulbrandsen-imap-response-codes-07. The draft looks good, but I have one question:
      Should the list in Section 6 contain NOTSAVED (RFC 5182), ANNOTATIONS (RFC 5257), TEMPFAIL (RFC 5259), MAXCONVERTMESSAGES (RFC 5259), MAXCONVERTPARTS (RFC 5259), NOUPDATE (RFC 5267), NOTIFICATIONOVERFLOW (RFC 5465), BADEVENT (RFC 5465), and UNDEFINED-FILTER (RFC 5466)? And perhaps also NEWNAME (RFC 2060), possibly marked as "obsolete"?
      (This was a result of simple "grep", so perhaps there are still more RFCs that have more response codes...)
    2. Tim Polk: Discuss [2009-03-12]: Arnt's March 12 email (8:01 AM EDT) suggests that collisions with proprietary response codes are a legitimate concern:
      "In that case, don't we also need to register SCAN and such things, which are often seen in deployed servers, but for which there will never be an RFC?"
      Alexey's response indicated that such response codes are "rare". I assume that means there are few of them, rather than "rarely seen" since that contradicts Arnt's statement.
      The IANA rules should allow the designated expert the flexibility to address this for legacy cases, but I don't think the proposed text supports this option. (I support requiring RFCs for any future assignments.)

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. (none)

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) (Informational)
    draft-jones-dime-3gpp-eps-command-codes-02
    Token: Dan Romascanu Note: IETF LC ends on 3/5. A new revised I-D will be available immediatly after the Last Call.
    Extracted from Balloting:
    1. (none)

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. Linguistic Guidelines for the Use of the Arabic Language in Internet Domains (Informational)
    draft-farah-adntf-ling-guidelines-04
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Cullen Jennings: Comment [2009-03-11]: I think this spec effectively overrules the advice the IDNA bis WG is providing on this topic and thus should not be published. However, the topic is very complex and and I if Lisa feels this needs to be published this way, I'm not blocking it.
    2. Chris Newman: Comment [2009-03-12]: I am very pleased to see a document like this show up at this stage in the IDNAbis process. One of the contentions behind IDNAbis is that the rigid approach IDNA took was not conducive to cultural variations and that more leeway should be left to language-centric domain registrar policy. To have an example set of such language-centric policy to reference during the IDNAbis debate improves that debate and supports the general direction IDNAbis has chosen to follow.
    3. Magnus Westerlund: Discuss [2009-03-12]: What is in the IESG note is what should be in the RFC-editor note. That is the response on how IESG views this document. In addtion we do usually select one of the IESG Notes from section 4 in RFC 3932 and that goes into the IESG note section.

    Telechat:

3.3.2 Returning Items

  1. (none)

1228 EDT break

1233 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Locator/ID Separation Protocol (lisp)
    Token: Jari

    Telechat:

  2. Session Initiation Protocol Core (sipcore)
    Token: Cullen

    Telechat:

  3. Dispatch (dispatch)
    Token: Cullen

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. Network File System Version 4 (nfsv4)
    Token: Lars

    Telechat:

  2. Ad-Hoc Network Autoconfiguration (autoconf)
    Token: Jari

    Telechat:

  3. Routing Over Low power and Lossy networks (roll)
    Token: David

    Telechat:

5. IAB News We can use

  1. DaveOran: sent an email, has everyone seen it? I'm not the liaison yet
  2. DaveOran: last meeting 4 march, settled on date/place for IAB retreat, DC area, detailed planning for plenary well along, three perspectives, reviewing drafts of those presentations
  3. DaveOran: planning lunch Thursday in SF, ITU liaison issues, maybe other liaison issues (not technical details)
  4. Lars?: what to do with flow-spec; we need to look carefully; what happens if we don't agree with them? how can we say no?
  5. ??: to ITU, saving one round-trip is the one thing that appeals to them
  6. Dave: the MPLS change process is a good model

6. Management Issues

  1. IESG Datatracker change (Dan Romascanu)

    Telechat:

  2. I-D submission cut-off dates (Russ Housley)

    Telechat:

  3. Proposal for revised IESG statement about copyright text in MIB and PIB modules (Dan Romascanu)

    Telechat:

7. Agenda Working Group News

Mark: thanks to Amy & co. for four years

1357 EDT Adjourned