IESG Narrative Minutes

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

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

Corrections from:

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. Transmission of IP over Ethernet over IEEE 802.16 Networks (Proposed Standard)
    draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-11
    Token: Ralph Droms; Note: Gabriel Montenegro <gmonte@microsoft.com> is the Document Shepherd for this document
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-09-10]: The document is now in quite good shape -- there's been progress since the previous versions! I did have a few issues, though:
      Here the conclusion is right but the rationale needs a bit work:
      "According to [RFC4861], a link is defined as a communication facility or medium over which IP devices can communicate at the link layer, i.e. the layer immediately below IP. Ethernet fully satisfies the definition of the link. IEEE 802.16, however, has limitations on its transitive connectivity, i.e. IEEE 802.16 provides point-to-point connections between SSs and the BS but does not enable any direct SS to SS connectivity. Hence, it is required to bridge each of the point-to-point connections between SSs and the BS so that Ethernet is realized over IEEE 802.16 access network."
      Here's a piece of Ethernet technology that has the same limitations as 802.16:
      - it is point to point
      - it doesn't do multicast
      - it has limitations with regards to host - host connectivity unless your nic supports either straight and twisted cables
      http://www.ccrane.com/images/medium/cat-5e-ethernet-cable.jpg
      But I do agree, of course, that bridging is required. I would suggest however that the paragraph be reworded to:
      "Like in today's wired Ethernet networks, bridging is required to implement connectivity between more than two devices. In 802.16, the point-to-point connections between SSs and the BS can be bridged so that Ethernet is realized over IEEE 802.16 access network."
      The network-side bridging function SHOULD create a new radio side port whenever a new SS attaches to any of the BSs of the network or SHOULD remove a radio side port when an associated SS detaches from the BSs."
      Wouldn't this be more of a case for a MUST than a SHOULD? This is basic functionality for 802.16 Ethernet.
      "The generic IP over Ethernet network scenario assumes that all hosts are residing on the same link with trust relationship between all of them."
      I'm not sure why we need to assume a trust relationship here. I would suggest deleting everything from word "link" onwards.
      "All multicast and multicast control messages SHOULD be processed in the network-side bridging function according to [RFC4541]."
      This is a fine requirement, except for 4541 being an informational document and this spec being proposed standard. I would like to change this and similar recommendations in Section 7 to a different wording. Say, "can" instead of "SHOULD". Alternatively, we could call out this downref in a Last Call, but AFAICT this was not done in the last call we just had.
      Same for RFC 4562 references.
    2. Russ Housley: Comment [2009-09-04]: The Gen-ART Review by Miguel Garcia on 27-Aug-2009 says:
      The document is clear and well written. If possible, abbreviations should be expanded a first occurrence (e.g., QoS, MAC, CID, AR, DHCP, IGMP, etc.).
    3. Magnus Westerlund: Comment [2009-09-08]: Section 5.2, 7.1:
      I wonder why these section puts the requirement level on SHOULD and not a MUST? And what are the reasons/motivation for when it is allowable to not do the action?

    Telechat:

  2. Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message (BCP)
    draft-ietf-mpls-3209-patherr-05
    Token: Adrian Farrel; Note: This document should be processed in a batch with draft-ietf-mpls-gmpls-lsp-reroute and draft-ietf-mpls-soft-preemption. draft-ietf-mpls-soft-preemption should be read as the last of the batch
    Extracted from Balloting:
    1. Jari Arkko:Comment [2009-09-09]:I agree with Robert's discuss.
    2. Russ Housley: Discuss [2009-09-04]: In the Gen-ART Review ny Elwyn Davies on 3-Sep-2009, it says:
      "I think it would be helpful to be more precise about the exact sections of RFC 3209 etc that are being clarified. I couldn't actually locate the sections addressed on a cursory inspection."
      I think that this would be very helpful to a reader. If for some reason this is difficult, an alternative is to summarize the behaviors that have become common practice in terms of the RFCs that specify the protocols. For example, section 3 talks about the error codes that can be used to report a preempted TE LSP, but it does not tell the reader if this is a subset of the error codes that might seem to apply in this situation based on the protocol specification.
    3. Cullen Jennings: Comment [2009-09-09]: agree this should not be BCP
    4. Tim Polk: Discuss [2009-09-09]:
      There is only one instance of RFC 2119 requirements language in this draft: a MUST in section 2.3. There are a number of instances of lower case must and should in sections 2.1 and 2.2 that would seem to merit requirements language.
      Comment [2009-09-09]:
      (a) Section 2.2 seems internally inconsistent: in accordance with 2205, a node receiving a PathErr message takes no action; in accordance with 3473, a node receiving a PathErr message with Path_State_Removed in the ERROR_SPEC should take action, but is not required to.
      IMHO the 3473 exception is too important to bury halfway through the paragraph with a mild sentence beginning with "Note that..."
      Perhaps the the Path_State_Removed processing merits a new paragraph beginning with:
      "There is one exception where the receiving node MAY change the state.", or something along that line.
      (b) It might be good to append the references [RFC3209] [RFC3473] to the first sentence in the Security Considerations, so the readers don't have to guess where those "security considerations are already specified."
    5. Robert Sparks: Discuss [2009-09-08]: I have one point to discuss with the IESG. I expect to clear this discuss once that conversation happens.
      Given the discussion we had about BCPs in Stockholm, why is this a BCP? It explicitly says it "is a clarification and re-statement of the procedures set out in [RFC3209]", so why isn't this PS/Updates?

    Telechat:

  3. MPLS Traffic Engineering Soft Preemption (Proposed Standard)
    draft-ietf-mpls-soft-preemption-18
    Token: Adrian Farrel; Note: This document should be processed in a batch with draft-ietf-mpls-gmpls-lsp-reroute and draft-ietf-mpls-3209-patherr. draft-ietf-mpls-soft-preemption should be read as the last of the batch
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-09-08]: Missing right paren somewhere in this sentence from the first para of section 1?
      "Without an alternative, network operators either accept this limitation, or remove functionality by using only one preemption priority or using invalid bandwidth reservation values. Understandably desirable features like ingress (Label Edge Router) LER automated (Traffic Engineering (TE) reservation adjustments are less palatable when preemption is intrusive and high network stability levels are a concern."
    2. Tim Polk: Comment [2009-09-09]:
      Section 1:
      s/ingress (Label Edge Router) LER/ingress Label Edge Router (LER)/
      s/(Traffic Engineering (TE)/Traffic Engineering (TE)/
    3. Magnus Westerlund: Comment [2009-09-08]: Regarding the "Soft preemption timer", the interoperability section has some recommendations on its value. However, I would guess that for small values larger than 0 there would still be useless. Any desire to have a minimal usable value? And what unit is this timer in? The text talks all about seconds, but wouldn't values of the magnitude of some RTTs potentially useful, thus milliseconds may be appropriate here.

    Telechat:

  4. PathErr Message Triggered MPLS and GMPLS LSP Reroute (Proposed Standard)
    draft-ietf-mpls-gmpls-lsp-reroute-05
    Token: Adrian Farrel; Note: This document should be processed in a batch with draft-ietf-mpls-soft-preemption and draft-ietf-mpls-3209-patherr. draft-ietf-mpls-soft-preemption should be read as the last of the batch
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-09-09]: To the extent that I understand this specification, its ready to move forward. However, I did notice the following things which appear to be errors. Please consider fixing them before approving the document:
      "the impacted interface MUST be indicated in the ERROR_SPEC object and the IF_IF [RFC3473] ERROR_SPEC object formats SHOULD be used to indicate the impacted interface."
      RFC 3473 does not define IF_IF, nor does any other RFC for that matter. Did you mean IF_ID?
      "The IF_ID [RFC3473] ERROR_SPEC object format MUST be used to indicate a reroute request that is more specific than an interface. The TLVs defined in [RFC3471], as updated by [RFC3477] and [RFC4201], and [RFC4920] MAY be used to provide specific additional reroute request information, e.g., reroute around a specific label."
      I don't understand... I thought that IF_ID provided the interface information, so it could also be about a request that is exactly specific to an interface. Did you mean "... that is specific to an interface"? Or maybe the entire paragraph is only about the case wen you have a more specific request. But if so, why is the use of additional TLVs optional, i.e., only a MAY?
      But I could be missing something.
      Comment [2009-09-09]:
      "the ERO received in the LSP's incoming Path message does not preclude"
      Term ERO not yet defined
      "A transit node MAY act on a reroute request locally when the ERO received in the LSP's incoming Path message does not precluded the reroute."
      ... does not preclude ?
    2. Robert Sparks: Discuss [2009-09-09]: I strongly considered entering this as a Comment instead of a Discuss and expect to move it to a Comment after a short discussion which may or may not result in changes to the text.
      I'm a little concerned by this language in the Security Considerations section:
      "This document does introduce a new error code value, but this value is functionally equivalent to existing semantics."
      If the semantics are the same, why have a new error code at all? Is the sentence really trying to say the semantics are similar enough to other things that the security impacts are already well understood?

    Telechat:

  5. Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (Proposed Standard)
    draft-ietf-dime-pmip6-03
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Pasi Eronen: Discuss [2009-09-07]: I have reviewed draft-ietf-dime-pmip6-03, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document:
      First, a question: specifying just AVPs (but no Diameter application or other details) for the MAG-to-HAAA interaction probably makes sense, since the MAG and HAAA most likely have some Diameter interaction already (where these AVPs can be added). But why did the WG choose not to define all the Diameter details for LMA-to-HAAA interaction? (Just defining AVPs means there is no interoperability between LMAs and HAAAs based on this spec...)
      Couple of minor questions/nits:
      According to RFC 5447, the MIP6-Agent-Info group must include either MIP-Home-Agent-Address AVP, the MIP-Home-Agent-Host AVP, or both AVPs. What are the semantics of these AVPs in the HAAA-to-LMA answer message?
      How is the link-layer identifier from Mobile Node Link-Layer Identifier Option stored in the Calling-Station-Id AVP?
      Comment [2009-09-07]: The section references in Figure 1 are wrong.

    Telechat:

  6. Diameter User-Name and Realm Based Request Routing Clarifications (Proposed Standard)
    draft-ietf-dime-nai-routing-03
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-09-10]: This document should move forward, but I have a couple of concerns:
      1. History
      "At the time of publication of the Diameter Base Protocol [RFC3588], the NAI definition was based on [RFC2486] in which a NAI could only contain a single realm. The NAI definition has since been updated in [RFC4282] to define Decorated NAIs that contain multiple realms."
      As far as I can remember, this was not the exact history. First of all, RFC 2486 had examples employing the bang notation, and there were several implementations and proposals that took benefit of schemes like this. RFC 4282 expanded and clarified this usage, and was published at the same time as RFC 4284 came out, which was a very specific usage of the bang syntax and other things.
      I would suggest a rewrite: "While the use multiple realms is generally discouraged, RFC 4282 does allow multiple realms. The use of this facility appears in, for instance, RFC 4284.
      2. RFC 4284
      And add RC 4284 as an informational reference.
      3. Use of example domain names
      "decorate its NAI as Realm-H!username@Realm-X. The roaming terminal"
      I understand that you've used Realm-X in the sense of a variable here, but the realm parts are supposed to be DNS names. I'd like to see these examples reverted to (a) the use of example.com domain names or (b) use some syntactic notation that makes it clear that Realm-X is not a domain name but a conceptual variable.
      4. Interoperability
      "Implementations compliant to this specification MUST define a new Diameter application."
      While this is a theoretically a nice way to avoid a problem, it also seems at odds with real world deployment. Diameter applications already exists and implementations already use decoration. I don't understand how this requirement improves the situation. It may hurt, in fact, if the result is further proliferation of separate diameter applications, reducing the likelihood of interoperability in a situation where both endpoints would like to use the same conceptual application (but different App IDs) and both are decoration capable.
      5. Track
      Finally, we need to understand that NAI decoration has throughout its history been frowned upon. RFC 4282 documented its use as a part of known industry designs and RFC 4284. However, as pointed out in RFC 5113, it is not believed to be a long term solution, and has a number of issues. I'm uncomfortable with the idea publishing further Standards Track specifications building additional features around it. However, Informational seems like an appropriate classification, and I support the publication of this document as such.
    2. Adrian Farrel: Discuss [2009-09-10]: This Discuss is to raise an issue with the IESG during the telechat. I will clear the Discuss during the telechat and no action is required form the authors.
      Every time I see an I-D with "routing" in the title my nerves get even further shattered! Is there an easy way we can introduce some differentiation between routing as seen in the Routing Area, and the selection of a sequence of domains or servers that we see in other Areas? (Or am I just being too nervous?)
    3. Alexey Melnikov: Comment [2009-09-07]:
      4.2. Ensuring Backwards Compatibility
      "Implementations compliant to this specification MUST define a new Diameter application. This requirement is set to guarantee backwards compatibility with existing Diameter implementations, applications and deployments. Diameter agents not compliant with this specification will not advertise support for these new applications that implement the enhanced routing solution based on Decorated NAIs and will therefore be bypassed."
      Excuse my ignorance, but how can this be achived?

    Telechat:

  7. Generic Notification Message for Mobile IPv4 (Proposed Standard)
    draft-ietf-mip4-generic-notification-message-11
    Token: Jari Arkko; Note: Pete McCann (pete.mccann@motorola.com) is the document shepherd
    Extracted from Balloting:
    1. Ralph Droms: Discuss [2009-09-09]: Discuss-discuss: I'd like to see more motivation for the notification message and more fleshed out examples so we can judge the utility of the messages as well as the efficacy and correctness of the protocol.
    2. Lars Eggert: Comment [2009-09-08]: This is turning MIP into a reliable signaling protocol, which I think is a bad idea. I also don't understand how RFC3115 and RFC4917 aren't sufficient already.
    3. Adrian Farrel: Comment [2009-09-09]:
      There are plenty of usage scenarios listed in Section 3. But the document is very short of examples of what the notification might be used for (just a little in Seciton 5). I don't see any I-Ds in the working group proposing uses of this extension, and there is nothing referenced from this I-D. Are you sure that you haven't invented a protocol mechanism without any specific requirements? Will you be cluttering the protocol implementations with support for messages that will never be used?
      I note that the protocol write-up does not mention any implementations or plans for implementaiton.
      idnits says ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086)
      Section 2
      /terms are/term is/
      Section 4.3 needs to say when to give up retransmitting, and what to do with a GNAM that arrives for a GNM that was transmitted several retransmissions ago.
    4. Russ Housley: Comment [2009-09-09]: The authors have agreed to make several changes based on the Gen-ART Review by Sean Turner that was posted on 7-Sep-2009.
    5. Cullen Jennings: Comment [2009-09-09]: This protocol defines a semantic free messaging protocol. The problem with this is the semantics are derived from the payloads that it caries. This will result in several issues.
      1) Lack of Interoperability: Different vendors will do different things. There is way for one vendor to find out what other vendors extensions or how they work as there is no requirement to register them in a standardized way.
      2) Inappropriateness: Many of the things vendors do will not be and appropriate use of mip4.
      3) Incorrectness: Many of the extensions will suffer from errors, security problems, race conditions, and other problems. This happens due to lack of review of payloads and constrains implied by the transport.
      These issues could be resolved with significant rework of the draft that moved it to have a way to negotiate payloads each side supported and preferred, a way of indicating if the payload was mandatory to understand or optional to understand. A way of upgrading from an early version of an extension to a later way. And finally a way of registering payloads that used IANA and was specification required.
    6. Alexey Melnikov: Discuss [2009-09-10]: Updated as per revision -11:
      1). 4.3.1. Receiving Generic Notification Messages
      "When the MN is using FA-CoA and receives a Notification message, if the "MD" value is 0, it means that the notification message came from the HA. If the "MD" value is 4, the notification came from the FA."
      "If this notification message came from a FA and the MN accepts the FA's GNM, it will process the notification extension according to the specific rules for that extension."
      "After that, the MN MAY reply GNAM back to the FA. If the "A" flag is set in the GNM, then the MN MUST send the acknowledgement."
      "The MN MUST check for the presence of an authorization-enabling extension, and perform the indicated authentication. Exactly one authorization-enabling extension MUST be present in the GNM, if this message came from a FA, MN-FA AE MUST be present, If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the MN MUST reject the GNM and MAY send a GNAM to the FA with Code 195, including an Identification field computed in accordance with the rules specified in Section 7.1.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception."
      "The MN MUST check that the Identification field is correct using the context selected by the SPI within mandatory authentication extension like MN-FA AE or MN-HA AE. See Section 7.1.1 for a description of how this is performed. If incorrect, the MN MUST reject the GNM and MAY send a GNAM to the initiator with Code 197, including an Identification field computed in accordance with the rules specified in Section 7.1.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception."
      The order of paragraphs in this section seems wrong to me. I think the "A" flag needs to be checked after checking MN-FA AE or MN-HA AE, and also after checking the Identification field.
      There might be a similar problem in other sections.
      Comment [2009-09-10]:
      6. IANA Considerations
      "This document describes two new messages, the GNM in section 4.1 and the GNAM in section 4.2. These two messages SHOULD be allocated from the same address space used by the Registration Request and Registration Reply messages in [RFC3344]. The subtype of these two messages indicate what kind of information is carried and will be under assigned by IANA namespace."
      This sentence doesn't read well.
    7. Tim Polk: Discuss [2009-09-09]:
      (1) Sections 4.1 and 4.2, the description of SubType ends with:
      "The value 0 is reserved and SHOULD NOT be used. The value 1 indicates that the actual information is carried in vendor specific extensions. Other values are reserved for future extensions."
      However, the value 2 is also defined in this text. Is there a reason it is omitted from the list?
      (2) Section 8.1, second paragraph:
      "The style of replay protection in effect between any two peer nodes among MN, FA and HA. A sending node and its receiving node MUST agree on which method of replay protection will be used."
      Is there a negotiation mechanism or is this an out-of-band agreement?
      (3) A number of issues were raised in the secdir review, and the authors have graciously agreed to resolve them. (Thanks!) Since text was not proposed, this part of my discuss is just a placeholder for a review of -12 when it appears.
    8. Dan Romascanu: Discuss [2009-09-10]:
      1. I do not believe that the way Vendor/Organization specific extensions are currently defined allow for any level of interoperability or are for any use in a multi-vendor deployment. Even for mobile nodes and agents belonging to the same vendor, how do these recognize each other and the level of vendor extenstions that they support? It looks like this needs some more wor to design capability advertising and/or negotiation mechanism.
      2. If Generic String Extensions MUST be strictly defined as mentioned in section 5.1 should not an IANA register for these extensions be created together with the subtype field registries defined in Section 6?
      3. The specification is completely mute about the management aspects of the notifications capability. At a minimum I would expect that nodes and agennts expose a list of the supported notifications be accessible to operators via some management interface, that there would be switches to enable / disable notifications, and the capability to tune timers of retransmission.
    9. Robert Sparks: Discuss [2009-09-10]: I have many of the same reservations and concerns expressed in Cullen and Lars' comments and support Dan's discuss.
      Some additional treatment either adding mechanics for agreeing on semantics, the creation of a very limited scope for those semantics that would make those mechanics unnecessary, and/or additional motivation and discussion of architectural impact is needed.
      Comment [2009-09-10]: The v6 Mobile IP work seems to be taking a very different approach to this kind of problem. Please look to see if there's an opportunity for some alignment here?
    10. Magnus Westerlund: Comment [2009-09-09]: The also wonder what the motivation for this generic mechanism is. Especially why does it need to be generic? Can't it purpose be expressed more clearly?

    Telechat:

  8. Baseline Encoding and Transport of Pre-Congestion Information (Proposed Standard)
    draft-ietf-pcn-baseline-encoding-06
    Token: Lars Eggert; Note: Steven Blake (sblake@petri-meat.com) is the document shepherd
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-09-09]: Well-written and clear. Thank you.
      It might be over-cooking the text, but I would welcome additions to section 6 that clarify that the edges of the PCN domain are assumed to be hard. That is, it is a prerequisite of operating these PCN procedures that ECN packets cannot leak into the PCEN domain, and that PCN packets cannot excape. (Yes, I know this is implicit and explicit in various other places in the draft.)
    2. Russ Housley: Discuss [2009-09-09]: Based on the discussion that followed Gen-ART-Review by Spencer Dawkins posted on 21-Aug-2009, I expected an RFC Editor note to resolve the comment about "Outermost IP".
    3. Magnus Westerlund: Discuss [2009-09-10]: Section 4:
      " o Any packet that is not-PCN but which shares the same Diffserv codepoint as PCN-enabled traffic MUST have its ECN field set to 00."
      I agree that you must do something here. However, isn't what to do depending on the incomming ECN semantics? IF it is RFC 3168 resetting the ECN does not appear to be correct action. Instead other actions are need.
      I think a reformulation is needed, saying that not-PCN packets MUST NOT be forwarded within the PCN domain with the PCN-enabled DSCP and with ECN field values other than 00. Instead some other action must be taken. I don't think this document can mandate the erasing of ECN marking ECT or CE on incoming packets. Instead some other action must be taken.

    Telechat:

  9. Segmented Pseudowire (Proposed Standard)
    draft-ietf-pwe3-segmented-pw-13
    Token: Ralph Droms; Note: Stewart Bryant (stbryant@cisco.com) is the document shepherd
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-09-08]: DISCUSS: RFC3985 describes some mandatory congestion control functions that PWEs operating in a single PSN domain must adhere to. I'm missing a section in this document that describes how similar functions are provided for a segmented PWE. It may well be the case that the functions that each PSN employs for each PWE segment are already resulting in the correct behavior for the entire segmented PSN. It may also be the case that some additional functionality is needed - the document should discuss this.
    2. Adrian Farrel: Discuss [2009-09-10]: Sorry for a very lengthy Discuss. I think this work has significant merit and is in line with the requirements and architecture documents that have been previously approved. Nevertheless, I think this document is in need of some considerable work before it should be published as an RFC. I have tried to separate important points as Discusses, and smaller points as Comments.
      [book-length, go read it yourself!]
      Comment [2009-09-10]: The Gen-ART Review by Sean Turner on 31-Aug-2009 raises a few questions:
      - Do you really want 7 authors? The RFC Editor prefers 5 or less.
      - Should the Introduction be Section 1?
      - Sec 7.4.1: Indicates the PW Switching Point description string is 80 characters long. Should it say more about the character set?
      - Sec 8.4.1: Figure shows both AC "Up" and AC "UP". Should they all be "Up"?
      - Sec 16: s/Author's/Authors'
      - There are a couple of places where " , " should be changed to ", "
    3. Russ Housley: Comment [2009-09-04]: The Gen-ART Review by Sean Turner on 31-Aug-2009 raises a few questions:
      - Do you really want 7 authors? The RFC Editor prefers 5 or less.
      - Should the Introduction be Section 1?
      - Sec 7.4.1: Indicates the PW Switching Point description string is 80 characters long. Should it say more about the character set?
      - Sec 8.4.1: Figure shows both AC "Up" and AC "UP". Should they all be "Up"?
      - Sec 16: s/Author's/Authors'
      - There are a couple of places where " , " should be changed to ", "
    4. Magnus Westerlund: Discuss [2009-09-10]:
      Section 8.7:
      "There are some situations where an additional amount of interworking must be provided between the two data planes at the S-PE, however this is outside the scope of this document."
      Why isn't the situations that aren't explicitly supported not enumerated if you know about them. This appears to me to be saying: Yes, there are some cases where thinks doesn't work. But we are not going to tell you when. Have fun finding your self. I do believe the document should be clear when it works or not. I don't have a problem with them not being solved, but you need to inform when it does fail.
      Section 9.5.2.4:
      "-iii. T-PE1 builds a second VCCV echo request based on the infomation obtained from the control plane (S-PE TLV). It then increments the TTL and sends it out to T-PE2. Note that the VCCV echo request packet is switched at the S-PE datapath and forwarded to the next downstream segment without any involvement from the control plane."
      The above text seems to assume that the MS-PW only has two segments. My impression was that MS-PWs could consist of more than 2 segments.
      Also section 9.5.2.5 seems to lack appropriate wording for more than 2 segments.
      Comment [2009-09-10]: I also support Lars Eggerts discuss regarding congestion control. It seems that multi-segment in its various combinations have many potential ways of breaking the congestion control loop. Thus that fact and what can be done on the signalling plane by the S-PE is important.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Sub-Types (Proposed Standard)
    draft-rosenberg-sip-app-media-tag-03
    Token: Robert Sparks
    Extracted from Balloting:
    1. Alexey Melnikov: Discuss [2009-08-29]: While I agree with the motivation behind this document, I have a couple of minor concerns about how the new Media Feature Tag is defined:
      In Section 3:
      "The 'sip.app-subtype' media feature tag is of type token with a case-sensitive equality relationship."
      Why is equality case-sensitive? RFC 2045 is quite clear that MIME subtypes are case insensitive, see Section 5.1 of RFC 2045.
      If you really want this to be case sensitive, you need to define which case is valid. For example RFC 2913 defines that only lowercased version is used.
      "Its value can be any registered or private MIME application sub-type."
      I think you need a pointer to RFC 4288 (and it should be a normative reference), Section 4.2. And please point to "subtype-name" ABNF production.
      6. IANA Considerations
      "Values appropriate for use with this feature tag: Token."
      I think this should be "Token (equality relationship)", as per RFC 2506.

    Telechat:

  2. Nominating Committee Process: Open Disclosure of Willing Nominees (BCP)
    draft-dawkins-nomcom-openlist-06
    Token: Russ Housley
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-09-08]:
      INTRODUCTION, paragraph 14:
      "Nominating and Recall Commitee to disclose the list of nominees who"
      Nit: s/Commitee/Committee/
      Section 3., paragraph 4:
      "ringers are, consciencious IETF participants also provide feedback on"
      Nit: s/consciencious/conscientious/
    2. Cullen Jennings: Discuss [2009-09-10]: On the call, I would like to DISCUSS DISCUSS where someone explains to me who has expressed support for this. I'm trying to determine if anyone that is from the cultures that have close to zero representation on current IETF leadership positions support this and general level of support for it.
      I think the draft needs to make it clear when it comes into effect - ie. if the current nomcom will operate under the old rules or these new rules.
    3. Alexey Melnikov: Comment [2009-09-07]: Can NomCom openly state that there are extra candidates not included in the list, or does it have to silently omit them?

    Telechat:

2.2.2 Returning Items

  1. IESG Procedures for Handling of Independent and IRTF Stream Submissions (BCP)
    draft-housley-iesg-rfc3932bis-08
    Token: Jari Arkko; Note: There is no document shepherd
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-08-13]: Holding a Discuss until -08 is posted and the IESG (including Cullen) has had a chance to look at the document.
    2. Ross Callon: Comment [2008-12-04]: I agree with the DISCUSS comments by Cullen and Dan, but will let them hold the DISCUSS votes.
    3. Adrian Farrel: Comment [2009-04-23]: A bunch of comments. The RFC Editor might catch some of these, but not all. Check carefully because some of them have a subtle effect on the meaning.
      1. Abstract
      The Abstract contains an unnecessary note to the RFC Editor
      "{{{ RFC Editor: Please change "RFC XXXX" to the number assigned to this document prior to publication. }}}"
      There is no reference to "RFC XXXX" in the document.
      2. Section 1
      "Documents published in streams other than the IETF Stream may not" s/may/might/
      3. Section 1
      "Once these procedures are fully adopted, the IESG will continue to be responsible only for checking for conflicts between the work of the"
      s/will continue to be responsible only/will be responsible only/
      4. Section 2
      s/IRTF stream/IRTF Stream/
      5. Section 3
      s/publications as RFC/publication as RFCs/
      6. Section 3
      s/types of conclusions/types of conclusion/
      7. Section 3
      s/for <X>/for WG <X>/
      8. General
      Would be nice to consistent about "Independent Stream" or "Independent Submission Stream"
    4. Dan Romascanu: Comment [2008-12-04]:
      The current combination of rfc3932bis and 'IAB Headers and Boilerplate' leaves out an important message that was included in the IESG Note.
      Let us take the text for IRTF stream documents. The text in draft-iab-streams-headers-boilerplates-04.txt
      IRTF Stream: "This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This document has been approved for publication by the IRSG. It is not a product of the IETF and is therefore not a candidate for any level of Internet Standard; see section Section 2 of RFCXXXX."
      is much weaker IMO than the text in the RFC 3932 IESG note:
      "This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols."
      Missing to say 'is not based on IETF review' is essential IMO.
      I sent a note to the IAB, as the fix should be in the IAB document.

    Telechat:

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Identification of Communications Services in the Session Initiation Protocol (SIP) (Informational)
    draft-ietf-sipping-service-identification-03
    Token: Robert Sparks
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-09-10]: Well written and easy to read, thanks.
      To me, the recommendations in Section 7 are very important. I was hoping I would find them. I think you could usefully note in the Abstract and the Introduction that the document does make recommendations, and possibly you could include a "management summary" of those recommendations in the Introduction. (Note that the final paragraph of the Introduction lists the other sections but is too shy to mention the recommendations!)
    2. Russ Housley: Discuss [2009-09-09]: The Gen-ART Review by Elwyn Davies on 10-Jul-2009 has not received a response. Generally the document is well-written. Please consider the major two points of the review:
      1. Be more explicit about the 'considered harmful' thesis up front.
      2. Bring out the negotiative nature of SIP signaling in the recommendations, requiring elements to take account of the whole signling exchange when deriving the service identity.
    3. Alexey Melnikov: Comment [2009-09-04]: 4.3. Network Quality of Service Authorization
      "The IP network can provide differing levels of Quality of Service (QoS) to IP packets. This service can include guaranteed throughput, latency, or loss characteristics. Typically, the user agent will make some kind of QoS request, either using explicit signaling protocols (such as RSVP) or through marking of Diffserv value in"
      I think this needs an informative reference to RSVP RFC.

    Telechat:

  2. Basic HIP Extensions for Traversal of Network Address Translators (Experimental)
    draft-ietf-hip-nat-traversal-08
    Token: Ralph Droms; Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-09-10]: This is overall nice document, and believe it should be published as an RFC. However, I had two question marks that I wanted to talk about before recommending approval. The document says:
      "If a host is going to use ICE, it needs to gather a set of address candidates. The candidate gathering SHOULD be done as defined in Section 4.1 of [I-D.ietf-mmusic-ice]. Candidates need to be gathered for only one media stream and component."
      I'm troubled by the use of the term media stream. Is this a term defined in ICE, and if so, how does it translate to general purpose IP layer operation, such as what HIP is doing? Or is this merely a matter of saying that media stream = the UDP encapsulated flow that HIP is using to go through NATs?
      The document says:
      "For this purpose, during the base exchange, hosts can negotiate a transaction pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 packets. The parameter contains the minimum time (expressed in milliseconds) the host would wait between two NAT traversal transactions, such as starting a new connectivity check or retrying a previous check. If a host does not include this parameter in the base exchange, a Ta value of 500ms MUST be used as that host's minimum value. The value that is used by both of the hosts is the higher out of the two offered values."
      "Hosts SHOULD NOT use values smaller than 20ms for the minimum Ta, since such values may not work well with some NATs, as explained in [I-D.ietf-mmusic-ice]. The Initiator MUST NOT propose a smaller value than what the Responder offered."
      "The minimum Ta value SHOULD be configurable."
      The connectivity check storms are not just an issue for the hosts themselves, they are also an issue for the network as well as those other hosts that failed probes may end up with. Given this, I believe it would be useful to make a slightly stronger statement above about the configuration. For instance, that Ta 500 ms MUST be the default unless there's explicit configuration that says otherwise. (The current text says something slightly different, namely that lack of the value in the protocol exchange implies 500 ms. But it does not say anything about what the default config needs to be.)
    2. Lars Eggert: Comment [2009-09-08]: Section 50500, paragraph 0:
      "Upon publication of this document, IANA is requested to register a UDP port and the RFC editor is requested to change all occurrences of port HIPPORT to the port IANA has registered. The HIPPORT number 50500 should be used for initial experimentation."
      I believe you want to remove the sentence about port 50500, because that was only intended to be used while there was no registered port. (Also, I assume you want a Registered port > 1024 and not a Well Known port, correct?)
    3. Adrian Farrel: Comment [2009-09-10]: I'm happy to see this work progress, and I welcome it being published as Experimental.
      Please consider adding some text to the document to discuss the scope of the experiment. What concerns are there about releasing this into the Internet (i.e., why the Experiment)? How is the experiment limited (i.e., what rules ensure that this is operating within some kind of wall)? How will you determine if the experiment is a success?
    4. Dan Romascanu: Comment [2009-09-10]: I support the last issue raised by Jari in his DISCUSS concerning the need for a default value for the transaction pacing value parameter.
    5. Magnus Westerlund: Comment [2009-09-10]: Section 4.7:
      "HIP relay servers MAY refrain from sending keepalives if it's known that they are not behind a middlebox that requires keepalives."
      As it appears to be an assumption that the Relay server is not behind a NAT I don't see any meaning in the relay sending keep-alives. That as NATs normally only do keep-alive from their inside. And as that is mandated their are no point in the server on the external side to initiate keep-alive messages.

    Telechat:

  3. IMAP Support for UTF-8 (Experimental)
    draft-ietf-eai-imap-utf8-08
    Token: Alexey Melnikov; Note: Harald Alvestrand <harald@alvestrand.no> has agreed to shepherd the document. Note that the normative reference to obsolete RFC 1341 is intentional. The name parameter was defined in RFC 1341 across all media types. The subsequent version of MIME (2045/2046) deprecated it.
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-09-08]: Why is this going for Experimental instead of PS?
      Section 3.1., paragraph 7:
      "would be the same as if other syntacticly valid but semantically"
      Nit: s/syntacticly/syntactically/
      Section 3.4., paragraph 1:
      "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the
      Nit: s/"LIST-EXTENEDED"/"LIST-EXTENDED"/
    2. Adrian Farrel: Comment [2009-09-10]: Nit at the level of an observation: Would be bice if the first section in the document was the Introduction, and if the Introduction was a little less terse.
    3. Russ Housley: Discuss [2009-09-09]: Most of the comments from the Gen-ART Review by David Black on 31-Aug-2009 have been addressed. However the WG is still discussing one:
      Section 2 ought to introduce what's being added to the protocol. Adaptations of the first two sentences in Section 10 (IANA Considerations) would suffice.
    4. Alexey Melnikov: Comment [2009-09-10]: David Black suggested in GenArt review:
      While not strictly a security consideration, it would be useful for section 11 to point out the potential for user confusion caused by SEARCH command match strings that have different UTF-8 representations but display identically or similarly (strings that look like they should match don't).
      Barry Leiba suggested:
      "The UTF8=ONLY capability implies the UTF8 base capability, the UTF8=ALL capability and the UTF8=APPEND capability. A server which advertises UTF8=ONLY need not advertise the three implicit capabilities."
      Oy. This makes parsing the capability string complicated, and should be earlier in the document. It'd be good to make this clear at the beginning, when the UTF8 capability is first mentioned.
    5. Robert Sparks: Comment [2009-09-08]: Appendix B (Acknowledgments) still says TBD.

    Telechat:

  4. Application-Layer Traffic Optimization (ALTO) Problem Statement (Informational)
    draft-ietf-alto-problem-statement-02
    Token: Lisa Dusseault; Note: Jon Peterson (jon.peterson@neustar.biz) is the document shepherd
    Extracted from Balloting:
    1. Jari Arkko:Discuss [2009-09-10]: This is a much needed document and I support its publication. There was one aspect missing from the document and I believe it would be important to note that before moving forward.
      Specifically, the document casts the peer selection problem as merely a network layer selection issue. However, this is just one of the criteria from the perspective of, say, a P2P application. It is also concerned with things like
      - balancing load across participating nodes, not just load across network links, to avoid disturbing any individual user too much
      - fetching a rare piece of a file before other parts, whether or not that piece is in a congested network part or not
      And sometimes different factors can point to different "correct" selections.
      In short, I would like to see the document acknowledge that network layer peer selection is just one of the factors that a P2P node needs to consider when selecting peers.
      Here's a suggested edit:
      OLD: Selection of a good host from an overlay topological proximity has a large impact on the overall traffic generated.
      NEW: Selection of a good host from an overlay topological proximity has a large impact on the overall traffic generated. Note that while topological considerations are important, they are still just one factor among many for typical applications. Applications also need to consider other issues, such as avoiding overload of individual nodes, fetching rare pieces of information before others, and so on. However, better information about topological conditions improves the overall selection algorithm on one important aspect.
    2. Lars Eggert:Comment [2009-09-08]:
      This isn't a blocking discuss, but please give these comments some serious consideration. The document touches on lots of important points, but misses one issue which I consider to be of key importance: what kinds of information can and will be provided using ALTO. Right now, the document is very generic on this, talking about "network-layer information" that will enable "better-than-random selection" of peers. I'd very much like the document to become more concrete, and discuss what kinds of network-layer information could reasonably be provided by an ALTO box, what kinds could be provided but are useless (because the peers can obtain it as easily by themselves) and what kinds of infomation is out of scope (for example, because it changes on timescales that make it impossible to provide via an out-of-band service like ALTO).
      INTRODUCTION, paragraph 14:
      "This document describes problems related to improving traffic generated by peer-to-peer applications. In particular, this document discusses issues which better-than-random peer selection based on network-layer information may raise."
      Please be more clear in the abstract. This document discusses issues related to an information-sharing *service* to *enable* BTR peer selection; it's not about BTR selection or improving traffic itself (that will depend on whatever the applications using this service will do with the information.)"
      Section 1.1., paragraph 4:
      "Recent studies [ACM.ispp2p] [WWW.p4p.overview] [ACM.ono] show a possible solution to this problem. Internet Service Providers (ISP), network operators or third parties can collect more reliable network information. This information includes relevant information such as topology or bandwidth available. Normally, such information changes on a much longer time scale than information used for congestion control on the transport layer."
      "Bandwidth available" to a specific peer and congestion are intrinsically linked. It's not accurate to say that one changes on slower timescales than the other. "Bandwidth available" information is likely something that an ALTO box cannot provide with useful precision. I'd pick a different example here.
      Section 1.1., paragraph 5:
      "This document gives the problem statement of improving traffic generated by P2P applications using information provided by a separate party."
      See my comment about the abstract. I believe that this paragraph doesn't quite capture what this document is about.
      Section 2., paragraph 2:
      "Application: A distributed communication system (e.g., file sharing) that uses the ALTO service to improve its performance or quality of experience while improving resource consumption in the underlying network infrastructure. Applications may use the P2P model to organize themselves, use the client-server model, or use a hybrid of both (i.e., a mixture between the P2P model and the client-server model)."
      Up until know, the document was all about P2P. Now the documents talks about including hybrid applications, which presumably can degenerate into traditional client/server behavior. Please be very clear what the scope of ALTO is, P2P only or also client/server. If the latter, you need to make this clear in the abstract and introduction.
      Section 3., paragraph 1:
      "Network engineers have been facing the problem of traffic optimization for a long time and have designed mechanisms like MPLS [RFC3031] and DiffServ [RFC3260] to deal with it. The problem these protocols address consists in finding (or setting) optimal routes for packets traveling between specific source and destination addresses and based on requirements such as low latency, high reliability, and priority. Such solutions are usually implemented at the link and network layers, and tend to be almost transparent. At best, applications can only "mark" the traffic they generate with the corresponding properties."
      This paragraph is confused on what DiffServ is.
      Section 3., paragraph 4:
      "Addressing the Application-Layer Traffic Optimization (ALTO) problem means, on the one hand, deploying an ALTO service to provide applications with information regarding the underlying network and, on the other hand, enhancing applications in order to use such information to perform better-than-random selection of the endpoints they establish connections with."
      Again, please be clear about the scope. The ALTO WG is only chartered to look at some aspects of the former (providing a service to share network information - actually, only the query protocol towards that service). "Enhancing applications" (defining how applicaitons should or may use the information) is not in scope.
      Section 6., paragraph 2:
      "The approach proposed in this document asks P2P applications to delegate a portion of their routing capability to third parties. This gives the third party a significant role in P2P systems."
      I think this paragraph is highly inaccurate. ALTO is about sharing topology-related information with P2P peers, and not about delegation of functions.
    3. Adrian Farrel:Comment [2009-09-09]: Thanks for this document.Possibly a bit of a terminology hicough...
      In Section 1 you have:
      "Peer-to-peer (P2P) applications, such as file sharing, real-time communication, and live and on-demand media streaming use a significant amount of Internet resources"
      But in Section 2
      "Resource: Content (such as a file or a chunk of a file), or a server process (for example to relay a media stream or perform a computation), which applications can access. In the ALTO context, a resource is often available in several equivalent replicas. In addition, different peers share these resources, often simultaneously."
      Maybe you can solve this by adding another term to Section 2 to define "Internet Resource."
    4. Tim Polk: Discuss [2009-09-10]:
      Section 6., paragraph 2:
      "The approach proposed in this document asks P2P applications to delegate a portion of their routing capability to third parties. This gives the third party a significant role in P2P systems."
      As Lars has noted in his comment, this paragraph does not not accurately describe the approach. ALTO is about sharing topology-related information with P2P peers, and not about delegation of functions.
      The important point that the authors may be alluding to is the introduction of new trusted parties (the ALTO server) into the peer selection process. In some cases, such as an ALTO service offered by the network operator, the peer already has a business relationship with the peer. Where a third party offers this service, this may entail new relationships for network operators and the peer. Managing and authenticating these trust relationships is likely to create new security requirements for all parties.
    5. Dan Romascanu: Comment [2009-09-10]: I am confused by section 4.5 and by DHTs being listed as part of the use cases. I percieve DHTs as a piece of technology that allow running P2P applications, so while it may be true that 'An ALTO solution can provide valuable information for DHT algorithms' on the other hand ALTO also is based on DHTs in order ro run on a P2P overlay.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. A Session Initiation Protocol (SIP) Extension for the Identification of Services (Informational)
    draft-drage-sipping-service-identification-03
    Token: Robert Sparks
    Extracted from Balloting:
    1. Alexey Melnikov: Discuss [2009-09-06]: I am thinking about voting Abstain on this document. However before I decide I think the following minor issues needs to be fixed (as RFC Editor notes or otherwise):
      1). 4.2. The P-Preferred-Service Header
      "There may be multiple P-Preferred-Service header fields. The semantics of multiple P-Preferred-Service header fields appearing in the same request is not defined."
      What is the reason for allowing multiple header fields and not specifying their handling? Lack of clarity here might affect interoperability.
      2). 4.4. Registration Template
      "Declared registrant of the namespace: TBD"
      Who is the registrant of the namespace?
      Comment [2009-09-06]:
      4. Syntax of the Header Fields
      "The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC 4234 [RFC5234]."
      Typo: RFC 5234
      4.2. The P-Preferred-Service Header
      "Table 2 extends the headers defined in this document to Table 2 in"
      I think you mean "adds the headers defined ...".
      6. Examples of Usage
          * F4   proxy.example.com -> proxy.pstn.example (trusted)
      
          INVITE sip:+14085551212@proxy. pstn.example SIP/2.0
          Via: SIP/2.0/TCP useragent.example.com;branch=z9hG4bK-124
          Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4bK-abc
          To: <sip:+14085551212@example.com>
          From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
          Call-ID: 245780247857024504
          CSeq: 2 INVITE
          Max-Forwards: 69
          P-Asserted-Service: urn:urn-7:3gpp-service.exampletelephony.version1
      

      Should there be a Service-ID reserved for use in examples?
    2. Tim Polk: Discuss [2009-09-10]: This is a discuss-discuss. I will move to Abstain if the sponsoring AD prefers to proceed with publication as Informational.
      draft-ietf-sipping-service-identification makes a strong argument that derived service identification is safe, and declarative service identification is perilous. This document includes both forms of service identification, although there are some constraints regarding the applicability of declarative service identification.
      Given the disconnect, would it be better to publish this document as experimental? (Or are there IANA considerations that preclude publishing as experimental?)
      I do not feel strongly enough to block publication, but it does seem a bit odd that we could approve two conflicting specifications on the same telechat...

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. Unintended Consequence of two NAT deployments with Overlapping Address Space (Informational)
    draft-ford-behave-top-07.html
    Token: Magnus Westerlund
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-02]: I'm confused by the example in section 3.2.4. Does the example discuss hijacking inbound mail, outbound mail or IMAP/POP access?
      Does this sentence from the second paragraph in 3.2.4 refer to NAT-2 in figure 1.1:
      "Ideally, ISPs should not use NAT devices to provide connectivity to their customers."
      LSNs (large scale NATs) seem to be an inevitable example of deployments like NAT-2. Perhaps section 3.2.4 could be expanded to explain how NAT-2 and NAT-3 would be configured to accommodate inbound mail to a mail server on Host G?
    2. Cullen Jennings: Comment [2009-09-09]: Thank you to the authors and RFC Ed for the changes made to this document.

    Telechat:

1256 EDT break

1300 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Virtual World Region Agent Protocol (vwrap)
    Token: Alexey

    Telechat:

4.1.2 Proposed for Approval

  1. SIP Common Log Format (sipclf)
    Token: Robert

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. IP Flow Information Export (ipfix)
    Token: Dan

    Telechat:

  2. Security Issues in Network Event Logging (syslog)
    Token: Pasi

    Telechat:

  3. Network Endpoint Assessment (nea)
    Token: Tim

    Telechat:

4.2.2 Proposed for Approval

  1. DNS Extensions (dnsext)
    Token: Ralph

    Telechat:

5. IAB News We can use

  1. Dave: nothing of import this week

6. Management Issues

  1. Appointment of Language Tag expert reviewer as per draft-ietf-ltru-4646bis-23 (Alexey Melnikov)

    Telechat:

  2. Link Relations Request [IANA #259813] (Michelle Cotton)

    Telechat:

  3. Approve Mark Nottingham as secondary expert for HTTP (Lisa Dusseault)

    Telechat:

  4. Expert for LCT Header Extensions [IANA #264752] (Michelle Cotton)

    Telechat:

  5. Order of boilerplate stuff in IDs (Cullen)

    Telechat:

7. Agenda Working Group News

1342 EDT Adjourned